Date
2026/05/24
Category
Hermes Agent
Title
Hermes Agent を Claude Desktop / Cursor に MCP 公開する — @buray 氏の interop 事例
株式会社FyveでAI活用顧問サービスを提供する田嶋です。Hermes Agent を「単体で動かす自律エージェント」として紹介する記事は増えてきましたが、実務で本当に効いてくる使い方は別の所にあります。今回紹介する @buray 氏の事例は、Hermes Agent を MCP サーバーとして外に開き、Claude Desktop や Cursor から呼び出せるようにするというものです。エージェント同士の interop(相互運用)を実現する構造で、私たちが企業案件で考えているエージェント連携設計と直結する内容でした。
本事例の発信は 2026-04-18、X 上の @buray 氏によるものです。海外 Hermes Agent コミュニティの中でも、開発支援文脈で特に注目された一次情報でした。awesome-hermes-usecases にも掲載されている取り組みです。
やっていることをひと言でまとめると、こうなります。
このつなぎ方が成立すると、何が変わるか。Claude Desktop や Cursor の利用者は、エディタ・チャットの UI を離れずに、Hermes Agent 側に蓄積された記憶やスキル、long-running 実行能力を活用できるようになります。逆に Hermes Agent 側は、UI を自前で持たなくても、既存の UI 資産(Claude Desktop / Cursor)に乗っかってユーザーに価値を届けられます。
MCP(Model Context Protocol)は Anthropic が提唱した、LLM クライアントと外部ツール/データソースをつなぐ標準プロトコルです。サーバー側は「自分が提供できるツール一覧」と「各ツールの呼び出し方法」を MCP の形式で公開すれば、Claude Desktop・Cursor・その他 MCP 対応クライアントから等しく利用してもらえます。
普段 MCP サーバーとして公開されるのは、Notion・GitHub・Supabase・Slack のような「データを持っている側」です。@buray 氏の事例が面白いのは、ここに 自律エージェントである Hermes Agent そのもの を MCP サーバーとして差し込んだ点です。
つまり、Claude Desktop から見ると、Hermes Agent は「いつもの MCP サーバーのひとつ」に見えます。しかし呼び出した先には、単なる API ではなく、記憶を持ち、スキルが自己改善し、cron で動き続ける別のエージェントが待っている。これが従来の MCP サーバーとは決定的に違う構造です。
9 個のツールという数も意味があります。MCP サーバーは公開する関数を増やしすぎるとクライアント側の選択精度が落ちることが知られていますが、9 という規模は「Hermes Agent の中核機能を絞って外に出した」サイズ感に近い。記憶への読み書き、長時間ジョブの起動、スキル実行など、Hermes Agent でしかできない動作を厳選して公開しているという読み方ができます。

私たちはこの事例を、単なる Hermes Agent の便利な使い方として捉えていません。「自律エージェントを MCP で公開する」という設計パターンの一例として、相当インパクトのある先行事例だと見ています。理由を 3 点に整理します。
1. エージェント間に上流/下流関係が生まれる
Claude Desktop / Cursor は「対話・編集の手元 UI」、Hermes Agent は「裏で動き続けるサーバー的存在」という分業が成立します。これは私たちが企業案件で何度か繰り返し設計したパターンに近い。顧客に近い側に軽量な UI、奥に重い処理と長期記憶を持つランタイム、という二層構造です。
2. ユーザーの学習コストを下げる
Hermes Agent をフロントで触らせると、TUI に慣れる必要があり導入ハードルが上がります。Claude Desktop や Cursor で受けるなら、ユーザーは既存の操作感のままで済む。裏にいるエージェントの存在を意識させないという設計は、企業内利用で特に効きます。
3. ベンダーロックインの分散
Claude のモデルでも、自前で立てた OSS モデルでも、MCP に対応してさえいれば手元のクライアントが何であれ Hermes Agent につながります。モデルとランタイムを分けて持てる構造は、AI を内製化したい企業にとって魅力的なオプションです。
私たちがこの事例から取り出して、お客様の現場に転用できると考えている設計を 3 つ紹介します。
たとえば社内向けに、過去議事録・契約書・顧客対応履歴を扱う「業務知識エージェント」を構築したとします。これを MCP サーバーとして公開すれば、社員は普段使っている Claude Desktop / Cursor / Claude Code から、いつもの会話画面で社内ナレッジを引けるようになります。専用 UI を作る必要はなく、認可制御だけ MCP サーバー側で厳格にやればよい。
「エージェントを作る」ではなく「社内 SaaS 的なエージェント API を作る」と捉え直すと、開発工数も学習コストも大きく下がります。
Claude Desktop が「ユーザーの問いを受ける窓口」、Hermes Agent が「重い処理を捌くバックエンド」という @buray 氏のパターンは、そのまま業務システムに転写できます。
機密データに触る処理を奥に閉じ込められるので、セキュリティ設計の見通しが良くなる利点もあります。

社内に複数のエージェントが乱立し始めると、必ず interop の問題が出てきます。MCP を共通言語にして全部のエージェントを MCP サーバー化しておけば、後から「営業エージェント」「経理エージェント」「カスタマーサポートエージェント」を連結するときに、追加実装をほぼ書かずに済みます。
これは将来の話に聞こえますが、私たちの顧問契約のお客様の中でも、すでに 2 つ以上のエージェントを同時運用しているケースが出てきました。早い企業では「どう連結するか」の議論を 2026 年内に始める可能性が十分あります。
同時期の海外事例から、近い構造を持つ取り組みをいくつか紹介します。
いずれのケースも、共通点は「Hermes Agent を直接触らせず、既存 UI 経由で利用させる」ことです。@buray 氏の MCP サーバー化は、その中でも最もポータビリティが高い実装パターンと言えます。
@buray 氏が 2026-04-18 に公開した hermes-mcp-server は、Hermes Agent の 9 つのツールを MCP として外部公開する取り組みでした。Claude Desktop や Cursor といった既存 MCP クライアントから、Hermes Agent の記憶・スキル・長時間実行能力を直接活用できるようにする、エージェント間の interop 事例です。
私たちがこの事例から学ぶべきは、「エージェントは作るものではなく、社内 API として公開するもの」という発想転換です。MCP を共通プロトコルとして据えれば、社員の手元 UI は普段使いのまま、奥のエージェントだけを差し替えていける。これは AI 活用の内製化を考えている企業にとって、極めて筋の良い設計です。
株式会社Fyveでは、Hermes Agent や Claude Code を含む複数エージェントを企業環境にどう組み合わせるか、要件整理から構成設計まで伴走しています。社内に AI を入れる際の「最初の一歩」で迷っている方は、ぜひ参考にしてみてください。
出典
Company
株式会社Fyve
Address
〒810-0001
福岡県福岡市中央区天神4丁目6-28
天神ファーストビル7階
Tel
080-1460-2728
info@fyve.co.jp