ホームHermesとは記憶スキルマルチプラットフォーム自動化コマンド一覧ブログDelegationMCP人格設定導入と移行活用シナリオ
どこでも使えるAI — CLI・Slack・Telegram・Discord・Emailまで のイメージ
MULTI-PLATFORM

どこでも使えるAI — CLI・Slack・Telegram・Discord・Emailまで

Hermes Agent が CLI に閉じず、複数のメッセージング基盤へ広がる理由と運用上の価値を整理します。

AIは専用画面から解放される

Hermes Agent の価値は、単に会話ができることではなく、どこから呼び出せるかにもあります。CLIだけでなく、スマートフォンやチームチャットからも自然に利用できます。

精度の高いAIでも、呼び出し導線が遠いと定着しません。Hermes はここを重視しています。

Slack連携が示す企業実装のしやすさ

Slack連携は Socket Mode を採用しており、公開HTTPエンドポイントなしで接続できます。社内ネットワークやローカルサーバーでも導入しやすい構成です。

Bot Token、App-Level Token、イベント購読を整えれば、DMでもチャンネルでも Hermes を運用できます。

Telegram・Discord・WhatsApp・Signal への展開

Hermes Agent は Telegram、Discord、WhatsApp、Signal などにも対応しています。個人利用、チーム利用、モバイル中心運用など、現場に応じて配置できます。

同じエージェントを複数導線から呼べることが、AIを実務に定着させるうえで重要です。

Messaging Gateway は常駐AI基盤である

Hermes Gateway は単なる中継ではなく、プラットフォーム接続、セッション管理、cron結果配送などを担う常駐基盤です。

これにより Hermes は、その場限りのCLIツールではなく、待ち受けて働くAIへと変わります。

運用事例: カスタマーサポートのSlack常駐アシスタント

あるSaaS企業では、カスタマーサポートチームの Slack に Hermes Agent を常駐させ、問い合わせの一次仕分けと過去事例の検索を任せています。チャンネルで顧客名と問い合わせ内容を投稿するだけで、Hermes が関連する過去チケット、関係するドキュメント、担当者の候補をまとめて返してくれる設計です。

  • 課題: 深夜や休日の問い合わせに対して、過去に似た事例があったかを調べるのに時間がかかり、担当者の負担が偏っていた。
  • 解決策: Slack の専用チャンネルに Hermes を招待し、メンションで呼び出すと過去チケットと参考URLをまとめて返す運用に変更。
  • 成果: 一次回答までの平均時間が大幅に短縮され、熟練メンバーでなくても一次対応の品質が一定以上に揃うようになった。

ポイントは、Hermes が「Slack で動いている」ことを意識させない設計にできたことです。メンバーにとっては、チャンネル内の優秀な同僚がひとり増えたような感覚で使えます。

運用事例: 個人開発者のTelegram秘書

個人で複数のプロダクトを運用しているエンジニアが、Telegram 経由で Hermes Agent を自分の秘書として使っている例もあります。外出先でふと思いついたタスクや、障害通知の初動対応を、スマートフォンからそのまま Hermes に投げて処理する運用です。

  • 課題: PC の前にいない時間帯の通知を、あとでまとめて処理するしかなく、対応が後手に回っていた。
  • 解決策: Telegram Bot を Hermes Gateway に接続し、監視アラートも個人のやり取りも同じエージェントに集約。
  • 成果: 通知の見落としが激減し、移動中でも主要な判断をその場で返せるようになった。

メッセージング基盤を使うと、「PC を開かないと AI に頼めない」という壁がなくなります。これが定着の決め手になったと本人は語っています。

Slack連携の設定例

Slack 連携を始めるときに最低限必要になる設定は、環境変数として書いておくと他メンバーと共有しやすくなります。Socket Mode を使うので、公開URLの用意は不要です。

# .env.hermes (サンプル)
HERMES_SLACK_BOT_TOKEN=xoxb-****************
HERMES_SLACK_APP_TOKEN=xapp-****************
HERMES_SLACK_SIGNING_SECRET=****************
HERMES_SLACK_DEFAULT_CHANNEL=#hermes-lab
HERMES_GATEWAY_MODE=socket

トークンの種類が2つあるのがポイントで、Bot Token は投稿用、App-Level Token は Socket Mode の常時接続用です。どちらもイベント購読権限を合わせて設定してください。

CLI からのメッセージング設定コマンド

Hermes Gateway の起動や接続先の確認は、CLI からまとめて扱えます。よく使うコマンドを並べておきます。

# Gateway を起動する(常駐)
hermes gateway start --profile default

# 接続先プラットフォームの一覧を確認
hermes gateway list-adapters

# Slack アダプタの接続テスト
hermes gateway test slack --channel "#hermes-lab"

# Telegram Bot の登録
hermes gateway add telegram --bot-token "$TELEGRAM_BOT_TOKEN"

アダプタという単位で各プラットフォームを扱うので、Slack と Telegram と Email を同じ Gateway に並べて運用することもできます。ひとつの Hermes に複数の顔を持たせるイメージです。

対応プラットフォーム比較

どのプラットフォームをどう使い分けるかは、現場の事情によって変わります。参考までに、主要な接続先の特徴を簡単に比較しておきます。

  • Slack: 社内利用の王道。Socket Mode で導入しやすく、チャンネルごとの権限管理がしやすい。
  • Telegram: 個人秘書用途に相性が良い。Bot の立ち上げが早く、モバイル中心でも扱いやすい。
  • Discord: コミュニティ運営や開発者チームで強い。スレッドやフォーラムとの組み合わせが便利。
  • WhatsApp: 顧客接点としての利用が増えている。API 側の規約確認が必須。
  • Signal: セキュリティ重視の用途向け。通信の秘匿性が求められる業界で使われる。
  • Email: 既存業務に混ぜやすく、相手側の環境を問わない。レポート配送の出口として優秀。

プラットフォームごとに強みが違うので、「誰がどこから呼ぶか」をまず決めてから接続先を選ぶと、ムダが出にくくなります。

お金の作り方を学ぶオンライン講座【Finorie|フィノリー】

企業導入でよく検討される論点

メッセージング基盤と AI をつなげる設計は、セキュリティ・監査・権限管理の観点で論点が多くなります。検討の初期に押さえておくと後戻りが少ない項目をまとめました。

  • 会話ログの保存範囲と保管期間を、情報システム部と早めに合意する。
  • Bot が読める情報と書ける情報のスコープを、プラットフォーム側の権限で縛る。
  • 秘匿情報を含むチャンネルには Bot を入れず、専用チャンネルに限定する。
  • DM 利用と チャンネル利用で、Hermes に渡す人格設定を切り替える運用にする。
  • Gateway が落ちたときの検知と自動再起動の仕組みを用意する。

ここを丁寧に詰めておくと、セキュリティ部門からの質問にも落ち着いて答えられる状態になります。

よくある質問

Q. Slack と Telegram を同時に使うことはできますか?

A. はい、Hermes Gateway は複数のアダプタを同時に起動できます。同じセッションを別プラットフォームから共有することも、アダプタごとに独立運用することも選べます。

Q. 社内ネットワークから外に出られない環境でも使えますか?

A. Slack は Socket Mode、Telegram は HTTPS 送信のみで接続できるため、公開 HTTP エンドポイントを用意できない環境でも導入しやすい構成です。プロキシ経由の運用もドキュメントで案内されています。

Q. メッセージの送信にはどのくらいのレイテンシがありますか?

A. 一次応答は数百ミリ秒から数秒、本文生成を含む応答は内容次第ですが、通常のチャット操作で不自然にならない範囲に収まります。急ぎの業務でもストレスなく使える速度感です。

Q. 誤送信が起きたときの取り消しはできますか?

A. プラットフォーム側のメッセージ編集・削除 API を Hermes から呼び出す運用が可能です。ただし監査の観点で、誤送信は「訂正メッセージを追記する」運用にしているチームも多いです。

Q. エンドユーザーが直接操作できるチャットに使えますか?

A. 技術的には可能ですが、その場合はガードレール(プロンプトインジェクション対策、応答制限、ログ保存)をしっかり設計する必要があります。まずは社内利用から始めて、運用ノウハウを貯めてから外向きに展開するのが一般的です。

僕の体験談

最初に Hermes を Slack に入れたとき、正直なところ「CLI でいいのでは?」と思っていました。ターミナルから直接呼んだほうが速いし、コマンドも覚えているしで、Slack 経由の一手間が面倒に感じていたんです。ところが実際に一週間使ってみると、考え方がひっくり返りました。

CLI のときは自分しか Hermes を使わなかったのに、Slack に入れた瞬間、チームのメンバーが勝手に呼び始めた。導線は、思っていたより何倍も大事だった。

特に驚いたのは、それまで AI にあまり積極的でなかったメンバーが、Slack のスレッドの中で自然に Hermes と会話を始めたことでした。専用の画面を開く必要がないだけで、心理的なハードルがここまで下がるのかと実感しました。

一方で失敗もありました。最初は全チャンネルに Hermes を入れてしまい、発言量が多いチャンネルで意図しないメンションを拾ってしまったんです。以降は、導入チャンネルを絞ってから順番に広げるスタイルに変えました。小さく始めて、定着したら広げる。これは Hermes のメッセージング展開においても同じだと痛感しています。

いまはモバイルからも Telegram 経由で呼べるようにしていて、移動中に思いついた依頼をそのまま投げておくのが習慣になりました。同じエージェントが、PC・Slack・Telegram のどこから呼んでも記憶を共有している。この一貫性が、Hermes をただのツールではなく「いつもそこにいる存在」にしてくれています。

導入ステップのチェックリスト

メッセージング連携を始めるときの最短手順を、チェックリスト形式でまとめました。いきなり全プラットフォームをつなぐより、ひとつずつ確実に立ち上げるほうが結果として早く本運用に入れます。

  • ステップ1: Hermes Gateway を個人環境で起動し、CLI から疎通確認する。
  • ステップ2: Slack App を作成し、Bot Token と App-Level Token を取得する。
  • ステップ3: 試験用チャンネルに Bot を招待し、DM とチャンネル両方で応答を確認する。
  • ステップ4: チーム数人に試用してもらい、人格設定と応答長のデフォルトを調整する。
  • ステップ5: 利用ガイドラインを整えてから、対象チャンネルを段階的に広げる。
  • ステップ6: 必要に応じて Telegram や Email アダプタを追加し、呼び出し導線を増やす。

全部で半日もあれば Slack 運用は始められます。大事なのはガイドラインで、技術的な設定よりも、「どんな依頼をしてよいか」を最初に明文化しておくと定着が早くなります。

注意点と運用の勘所

メッセージング経由の AI 運用で、見落とされがちなポイントをまとめておきます。ちょっとした配慮で、定着度も安全性もぐっと高まります。

  • Bot の表示名と人格を一致させる。ふざけた名前は便利さを下げる。
  • 返答の冒頭に「誰が何のために動いたか」を示すと、あとで履歴を追いやすい。
  • 長文の返答はスレッド化して、元チャンネルのノイズを減らす。
  • 失敗時のメッセージを優しく書く。エラーは人を責めない。
  • 監査ログを月次でエクスポートし、利用傾向を定期的に振り返る。

メッセージング連携は、技術的な設定よりも文化的な定着のほうが大変です。焦らず、小さく、毎日触れる場所に置くこと。これに尽きます。