すべてを内蔵しないからこそ強い
Hermes Agent は多機能ですが、すべてを本体へ抱え込む設計ではありません。MCP によって外部ツールや既存システムとつながる拡張余地を持っています。
新しい統合先が現れるたびに本体を改造しなくても、MCPサーバー経由で接続できるのが強みです。
企業活用に向く理由
MCP はローカル stdio サーバーにもリモート HTTP エンドポイントにも対応しています。個人のローカル環境にも、企業の社内APIにも、同じ概念で接続できます。
既存資産を生かしながらAIだけを前面へ出せるため、企業導入との相性が良いです。
ツールを見せすぎないフィルタリング
MCP では include / exclude によってツールを絞り込めます。これは安全性だけでなく、エージェントの判断精度にも効きます。
つなぐだけではなく、何を使わせるかを運用目線で制御できる点が重要です。
拡張可能なAI基盤としての Hermes
標準機能で始め、必要に応じてMCPで広げていく。Hermes Agent は完成済みアプリというより、拡張可能なAI基盤として捉えた方が実態に近い存在です。
MCP とは何か、もう少し詳しく
MCP は Model Context Protocol の略で、AI エージェントと外部ツールを橋渡しする共通の通信仕様です。Hermes Agent の内側にすべてのツールを抱え込むのではなく、外部のサーバーに「このツール一覧を提供します」と宣言してもらい、必要なときに呼び出す構造になっています。これは Web における REST や GraphQL のような位置づけで、どんな言語で実装された外部サービスでも、MCP の規約さえ満たしていれば Hermes から利用できます。
MCP サーバーには大きく分けて二種類あります。一つは stdio 型で、ローカルプロセスとして動き、標準入出力でやり取りします。これは個人の開発環境で気軽に動かすのに向いています。もう一つは HTTP 型で、ネットワーク越しに接続できるため、社内 API や SaaS 連携に向いています。どちらを選ぶかは、接続したいシステムの場所と、認証の要件によって決まります。
Hermes Agent の面白いところは、両方を混ぜて使えることです。ローカルのファイルシステム系ツールは stdio で、クラウドにある社内在庫管理 API は HTTP で、というように、エージェントから見れば同じツール集合の一部に見えるようにまとめられます。
運用事例: 小売業での在庫 API 連携
ある小売チェーンでは、数千 SKU の在庫を毎日照会する業務がありました。従来は担当者が基幹システムの Web UI からいくつもの画面を開いて確認していました。この企業では、社内の在庫 API を MCP サーバー経由で Hermes Agent から叩けるようにし、店舗ごとの発注判断を自然言語で問いかけられるようにしました。
「今週の○○店の赤字リスク品目を三つ挙げて」と尋ねるだけで、エージェントが裏で複数の API を組み合わせて呼び、在庫、売上、発注リードタイムの情報を統合して答えを返します。担当者は結果を見て「この品目は翌週に回す」といった判断だけに集中できるようになり、発注会議の所要時間が半分以下になったそうです。ここで効いたのは、MCP によって既存の社内 API を作り直さずそのまま活かせたことでした。
運用事例: 法律事務所でのドキュメント検索
別の事例では、中規模の法律事務所が判例検索システムを MCP 経由で Hermes Agent と接続しました。この事務所は過去二十年分の案件資料を独自のインデックスで管理していて、それは有料の法律データベースとは別の資産でした。MCP サーバーを一つ立てて、社内インデックスへの検索インターフェースを公開するだけで、エージェントが自然言語クエリから過去案件を引けるようになりました。
弁護士は「この事案に似た先例を三件ほど教えて」と話すだけで、関連資料の要約と参照元リンクが返ってきます。既存のインデックスシステムには一切手を入れずに済んだため、法務部門のセキュリティレビューもスムーズに通り、導入がスピーディに進んだと聞きました。
運用事例: DevOps 現場でのツールチェーン統合
ソフトウェア開発の運用側では、GitHub、Jira、Datadog、PagerDuty など複数の SaaS を横断するシーンが日常茶飯事です。ある DevOps チームは、それぞれに MCP アダプターを用意し、Hermes Agent から横断的に操作できるようにしました。障害発生時には、Datadog から異常指標を拾い、Jira でインシデントチケットを自動起票し、関連する GitHub PR を絞り込み、PagerDuty のオンコール担当に通知する、という一連の流れが自然言語で走ります。
これを一つの大きなワークフローエンジンで書こうとすると、どのツールのアップデートにも追随する必要があって大変です。MCP のよいところは、それぞれの SaaS 側で API 変更があっても、該当の MCP サーバーだけ更新すればよい点です。エージェント本体には変更が波及しません。
設定例: MCP サーバーの登録
Hermes Agent への MCP サーバー登録は、設定ファイルに追記するだけのシンプルな手順です。代表的な構造を示します。ローカル stdio サーバーとリモート HTTP サーバーの両方が混ざっている例です。
mcp_servers:
- name: fs-local
type: stdio
command: "hermes-mcp-fs"
args: ["--root", "/home/user/projects"]
include_tools: ["read_file", "list_dir", "search"]
exclude_tools: ["write_file", "delete_file"]
- name: inventory-api
type: http
endpoint: "https://api.internal.example.com/mcp"
auth:
type: bearer
token_env: INVENTORY_API_TOKEN
include_tools: ["get_stock", "get_sales_history"]
- name: github-readonly
type: http
endpoint: "https://mcp.example.com/github"
auth:
type: oauth
include_tools: ["list_repos", "get_pr", "search_code"]
exclude_tools: ["merge_pr", "close_issue", "delete_branch"]exclude_tools の指定を徹底することで、エージェントが意図しない破壊的操作を行う余地を事前に消せます。権限を絞るのは面倒に感じるかもしれませんが、事故を防ぐためには欠かせません。
設定例: ツールフィルタリングの CLI 操作
運用途中でツールの許可範囲を変えたいとき、CLI で即座に反映できます。読み取り専用モードにする、特定ツールだけを一時的に封じる、といった操作が短いコマンドで済みます。
# 現在登録されている MCP サーバーとツール一覧を表示
hermes mcp list
# 特定サーバーを一時停止(プロセスは残したまま)
hermes mcp disable --name github-readonly
# 特定ツールだけをブロック
hermes mcp block --server inventory-api --tool get_sales_history
# 読み取り専用モードに切替(書き込み系ツールを全停止)
hermes mcp safe-mode on特に safe-mode は、監査や本番デプロイ直前など「今は何も触ってほしくない」瞬間に便利です。僕も最終確認フェーズでは必ずこれを入れる習慣にしています。
MCP 導入パターンの比較表
導入方式を選ぶとき、どういう基準で考えればよいかを比較表にまとめます。現場の事情によって最適解が変わるので、まずは項目を並べて検討するのがおすすめです。
| 項目 | stdio 型 MCP | HTTP 型 MCP |
|----------------|------------------------|------------------------|
| 主な用途 | ローカル開発、個人利用 | 社内API、SaaS連携 |
| 起動コスト | 低い(プロセス起動のみ) | やや高い(サーバー運用) |
| 認証の柔軟性 | 簡易(環境変数等) | 高い(OAuth, mTLS等) |
| 監査ログ | エージェント側に集中 | サーバー側にも残る |
| 障害切り分け | ローカルで完結 | ネットワーク要因も考慮 |
| スケーリング | 単一マシンに依存 | 複数ユーザーで共有可能 |
| 適した規模 | 個人〜小チーム | 部門〜全社 |
| 変更影響範囲 | 本人の設定変更で済む | 中央更新で全員に波及 |個人で試すなら stdio、組織で共有するなら HTTP、というのが基本方針です。混在させても動くので、最初は stdio で手触りを掴んでから、必要に応じて HTTP に置き換えていく段階導入も効果的です。
導入ステップのチェックリスト
MCP を組織に入れるとき、技術面だけでなくガバナンス面の整備が同じくらい重要です。導入フェーズごとに押さえるべき項目を並べておきます。
[ ] 1. 接続したい既存システムを棚卸しし、重要度で優先順位付け
[ ] 2. 各システムで「エージェントに触らせたくない操作」を洗い出す
[ ] 3. 最初の接続先を一つに絞り、読み取り専用で接続してみる
[ ] 4. include_tools を必要最小限に絞り込む
[ ] 5. 監査ログ収集の仕組みを先に作っておく
[ ] 6. 社内ユーザー向けの運用ガイドを一枚にまとめる
[ ] 7. 二つ目のシステムを接続し、クロス検索の挙動を確認
[ ] 8. 書き込み系ツールは段階的に解禁する
[ ] 9. 月次で「使われていないツール」を棚卸しして削る
[ ] 10. サーバー側の API 変更に追随するレビューサイクルを設ける特に 5 番目のログ収集は、後から整えようとすると手戻りが大きいため、最初の接続時点で仕込んでおくのがおすすめです。
僕の体験談: ツールを見せすぎて失敗した話
MCP を最初に現場に入れたとき、正直に言うと「とりあえず全部つないでしまえ」という雑な判断をしてしまいました。社内の在庫 API、勤怠 API、顧客管理 API、メール送信 API と、十を超える MCP サーバーを全部有効にして、ツール数は百を優に超える状態でした。結果として何が起きたかというと、エージェントの判断がぶれ始めたのです。
気づいたのは、ツールは多ければ便利なのではなく、多すぎると「どれを使うべきか」で迷いが生まれ、かえって答えが遅く不安定になるということ。
この失敗のあと、僕は include_tools を徹底的に絞り、一つのタスクには最大でも十五程度のツールしか見えないように制限しました。そこからはエージェントの応答が安定し、ツール選択ミスもほぼ消えました。「必要十分の情報だけを渡す」という原則は人間相手にもAI相手にも共通なのだな、と痛感した出来事でした。
もう一つ失敗があります。書き込み系ツールを無邪気に解禁したことです。エージェントが検索結果を「ついでに」カレンダーに予定登録したり、顧客リストを勝手に更新したりしてしまったことがありました。悪意なくやっているので質が悪く、利用者が気づかないうちに状態が変わっていたのです。そこから僕は、書き込み系は必ず確認プロンプトを挟むよう、MCP サーバー側の実装で承認フローを仕込むようにしました。これは後から足すと大変なので、最初から入れておくのが絶対に楽です。
ベストプラクティスと注意点
MCP を使いこなすうえで、現場で身につけた実務的なポイントを整理しておきます。どれも大きな設計ではなく、日々の運用で効いてくる小さなコツです。
第一に、ツール名は「動詞_目的語」形式で統一することです。get_stock、create_ticket、send_notification のように名前を揃えておくと、エージェントが意図を推測しやすくなります。英語と日本語が混ざっていたり、動詞が省略されていたりすると、判断のブレが出やすいです。
第二に、エラーメッセージは「AI が理解しやすい形」で返すことです。ツール側が「Internal Server Error」とだけ返すと、エージェントは次に何をすべきか判断できません。「在庫データは取得できましたが、一部の SKU が廃番で空でした」のように、次のアクションを示唆する情報を添えると、エージェントがリトライやフォールバックを賢く判断できます。
第三に、タイムアウト値を保守的に設定することです。ネットワーク越しの MCP サーバーで予想外の遅延が起きたとき、デフォルトの長いタイムアウトのまま放置すると、親エージェントが延々と待ち続けてしまいます。十秒、三十秒、六十秒のような現実的な上限を、ツールの性質ごとに決めておくのがよいです。
第四に、接続先の数が増えてきたら「ツールレジストリ」を用意することです。どのチームのどのツールが、どういう目的で、誰の責任で動いているのかを一覧化しておくと、棚卸しがしやすくなります。接続だけは増えるが誰も面倒を見ていない、という状態は MCP 運用で一番危険な兆候です。
よくある質問
Q. 社内 API に接続するとき、認証はどう設計すれば良いですか?
A. まず読み取り専用のトークンを用意し、それを MCP サーバーに渡す形が無難です。エージェント個人に API キーを直接持たせるのは、ログ監査の観点でおすすめしません。MCP サーバーを中継点にすることで、誰がどのツールを呼んだかをサーバー側でまとめて記録できます。
Q. MCP サーバーの障害時、エージェントはどう振る舞いますか?
A. Hermes Agent は MCP サーバーの応答がタイムアウトしたりエラーになったりした場合、そのツールを一時的に利用不可として扱い、代替手段を探そうとします。ただし、代替が見つからない場合はそのまま失敗を報告します。クリティカルなツールについては、冗長構成や再接続ロジックを MCP サーバー側で持っておくことをおすすめします。
Q. MCP サーバーは自作すべきですか、既製品を探すべきですか?
A. 一般的なサービス(GitHub、Slack、Notion など)は既製の MCP サーバーがコミュニティから出ていることが多いので、まずそれを使うのが早いです。社内独自の業務システムは、アダプタを自作する必要があります。幸い MCP の仕様はシンプルなので、最小構成のサーバーなら数日で作れます。
Q. ツールを大量に登録しても性能は落ちませんか?
A. 落ちます。ツール選択は LLM の判断タスクの一部なので、候補が増えるほど判断の難度が上がります。目安として、一つのエージェントに見せるツールは二十以下に抑えるのがおすすめです。役割が違うエージェントを複数用意し、それぞれに必要なツールだけ見せる方が、結果的に安定します。
Q. MCP サーバーのログはどこまで取るべき?
A. 最低限、呼び出し元、ツール名、引数のハッシュ、実行時間、成否を残してください。引数そのものを平文で残すと機密情報が漏れるリスクがあるため、ハッシュ化や伏字処理を併用します。これがあると、事後の監査やチューニングが格段にやりやすくなります。