AIエージェントにいこう：フィールドレポート

この記事は、しばらく前から書きたかった投稿です。何かを見つけ出したからではありません。同じ反応が何度も返ってくるからです——スタックについて話すと、「えっ、Goでエージェントのことやってるの？」って。というわけで、長い答えです。

エージェント型AIのエコシステムはPythonで動いています。LangChain、CrewAI、AutoGen、Semantic Kernel、LlamaIndex、すべてPythonです。SDKもPythonを第一に作られています。チュートリアルはPythonを前提としています。AIエージェント向けに何かを作るなら、抵抗が最も少ない道はpip installです。

私は逆の道を選びました。ここ数週間で、Goでエージェント関連のプロジェクトを5つ作りました。ガバナンス用プロキシ、メモリサーバー、Ollama向けのMCPブリッジ、自律リサーチエージェント、そしてマネジメントダッシュボードのバックエンドです。これは慎重に計画して決めたわけではありません。最初に1つのプロジェクトを始めて、それがうまくいきました。Claudeのおかげです。そして、そのまま作り続けました。良いとも悪いとも言える、当時の現場レポートです。

The projects

目立つパターンがあります：agent-meshには外部依存が1つだけです。MCPクライアント/サーバー、ポリシーエンジン、レートリミッター、承認フロー、トレースストア、OTELエクスポーター、HTTPプロキシ、そしてCLI——それらをGoの1万1千行あまりでカバーしています。すべて標準ライブラリに加えてYAMLパーサーだけです。ollama-mcp-goは外部依存がゼロです。計画してこうなったわけではありません。追加のパッケージを引き込まなくても動き続けたので、私はずっとそのままにしました。

Why Go for this layer

AIエージェントを動かすには2つ必要です。考えるLLMと、LLMと外部世界の間でデータを運ぶためのインフラです。前者はモデルの重みやテンソル計算で、Pythonがその分野を押さえているのには理由があります。後者はネットワーキング、並行性、シリアライズ、プロセス管理です。つまり配管です。Goは配管のために設計されています。

MCPは並行性の問題です。 MCPプロキシは複数のstdioサブプロセスを管理します（上流サーバーごとに1つ）。各サブプロセスにはそれぞれstdin/stdoutの組があります。さらに、HTTPまたはstdio経由で複数のエージェントからの着信リクエストも扱います。agent-meshは起動時にすべてのMCPサーバーを並列に起動し、チャネルを使うgoroutineのおかげで自然に実装できます。Pythonの同等コードはasyncioのタスクとサブプロセスのパイプになるはずですが、動くことはあっても、適切に実装するのは難しくなりがちです。

単一バイナリ配布が重要です。 curl | tar xzで動きます。ランタイム不要、仮想環境不要、node_modules不要です。ユーザーがClaude Codeのセットアップをする開発者だとしたら、「ファイル1つをダウンロード」が「Python 3.11+をインストールして、venvを作って、6つのパッケージをpip installして、システムPythonと競合しないことを祈る」より強いです。クロスコンパイルも無料です：GOOS=darwin GOARCH=arm64 go buildで、LinuxマシンからmacOS ARMのバイナリが作れます。

起動時間は軽視できません。 agent-meshはClaude Codeのサブプロセスとして起動します（MCPのstdio経由）。最初のツール呼び出しでユーザーが感じるのは、起動時間の遅延が積み重なったものです。Goのバイナリは数ミリ秒台で起動します。importを含むPythonプロセスは、アプリケーションのコードを1行実行し始めるまでにだいたい~200〜500msかかります。

メモリ使用量は予測可能です。 agent-meshはアイドル時でRSSが約14MBです。同等のPythonプロセス（FastAPI、uvicorn、いくつかのimport）なら、リクエスト処理を始めるまでに80〜120MBあたりになります。開発者のノートPCで、MCPサーバーを5つ＋プロキシを動かすと、それが積み上がります。

The cost

エージェント向けインフラとしてGoを選ぶことには、現実のコストがあります。全部がスムーズだったと言うなら嘘になりますし、正直にそこを話す方がセールストークより役に立つと思っています。

エコシステムが存在しません。 Go向けのLangChainはありません。公式のMCP SDKもありません（私は自分でクライアントとサーバーを書きました。学びにはなりましたが、決して速いわけではありません）。MCPを話せるOllama Goクライアントもありません（私はollama-mcp-goを書きました）。統合ポイントはすべて手作りです。Pythonなら1行のimportで済むものが、Goでは週末単位でかかります。

LLMとのやり取りは冗長です。 Pythonで公式SDKを使ってOllamaのチャットAPIを呼ぶのは3行です。GoではHTTPリクエスト、JSONのマーシャリング、レスポンス解析、そしてエラーハンドリングを明示的に書きます。同じ結果で約30行です。そして、Goのインターフェースがどう動くのかを理解するのがどれだけ頭痛の種かについて、私は触れませんが……。

プロトタイピングは遅いです。 Pythonなら、20行でアイデアをスケッチして反復できます。Goの型システムと、明示的なエラーハンドリングは、より早い段階で構造を要求します。scout7（Webリサーチエージェント）では、最初の動くバージョンはPythonならかかるであろう時間より長くなりました。ただし2作目は、適切なエラーハンドリング、タイムアウト、そして丁寧なシャットダウンを含めていたにもかかわらず、ほとんど追加コストなしで済みました。Goがすでにそういったケースを扱うように私を強制していたからです。

採用と貢献。 もしこれらのプロジェクトが成長するなら、Goのエージェント用ツールの貢献者プールはPythonより小さいでしょう。この領域で作っている多くの人はPythonで考えます。これは現実の制約です。

私は今もGoを学んでいます。 たぶんそれは言っておくべきです。私はGoのバックグラウンド出身ではありません。主言語はPythonです（専門家ではなくても）。そして、Goを書いているのは数週間であって、何年もではありません。コンパイラが怒っている理由をいつも理解できるわけではありません。自分が誇りに思っていたパターンが、Goでは実はアンチパターンだったと気づくこともあります。

これらのプロジェクトの半分はClaudeとペアプログラミングしました。つまり、AIエージェントが、AIエージェントのためのガバナンスツールを作るのを手伝ってくれたということです。そこにはどこかで冗談が成立しています。でも要点はこうです：どんな言語でも、役に立つものを出すにはその言語を習得する必要はありません。必要なのは良いフィードバックループです。コンパイラは愚かなミスを見つけてくれます。AIはアーキテクチャ上のものを見つけてくれて、理解できていないことについても質問し続けることになります。あとの分は私が拾っていきます……いずれ。

Where Python wins

私も、理にかなっているところではPythonを使っています。event7（スキーマレジストリのガバナンス）はFastAPIバックエンドです。これはデータベースを備えたWebアプリであって、システムプロキシではないからです。agent-meshのLangChainデモはPythonです。Pythonのエージェント上でガバナンスが動くことを示しているからです。もしRAGパイプラインを作るか、モデルをファインチューニングするなら、ためらいなくPythonを使うでしょう。

分かれ目は単純です。モデルの重みに触れる、または素早いMLプロトタイピングが必要ならPython。データを運ぶインフラ、ポリシーの強制、プロセス管理を担うならGo。

What the ecosystem is missing

エージェント型AI向けのGoエコシステムには、現実のギャップがあります：

• Go 向けの公式 MCP SDK はありません。 Anthropic は Python と TypeScript を提供しています。コミュニティによる Go 実装はまだ若く、不完全です。既存のどの選択肢も stdio と SSE の両方のトランスポートを確実に扱えなかったため、私は agent-mesh の中で独自の MCP クライアントとサーバを書きました。
• 構造化出力ライブラリがありません。 Python には Instructor、Outlines、Marvin があり、LLM の出力を型付きスキーマに押し込むことができます。Go では JSON をパースして、あとは祈るしかありません。たとえば scout7 はフォールバックとして、LLM の応答に対して正規表現による抽出を行います。動きはしますが、エレガントではありません。
• エージェント・フレームワークがありません。 必ずしも悪いことではありません。というのも、私の意見では、フレームワークは価値よりも多くの抽象化を追加しがちだからです。しかしそれは、すべての Go エージェントが最初から作り直すことを意味します。

こうしたギャップもまた、チャンスです。最初の堅実な Go 用 MCP SDK が登場すれば採用が進むでしょう。なぜなら、エージェント向けのツールを作る Go 開発者にとって、現状では良い選択肢がないからです。

The real argument

エージェント基盤における Go の是非という「本当の主張」は、「Go は Python より優れている」ということではありません。エージェントはモノリスではない、という点です。エージェント・システムには層があります。推論層（LLM）、オーケストレーション層（フレームワーク）、そしてインフラ層（トランスポート、ポリシー、メモリ、トレーシング）です。Python は最初の 2 層を支配しています。3 層目はシステムプログラミングであり、Go はシステム言語です。

サービスメッシュが Java で書かれなかったのは、マイクロサービスが Java だったからではありません。Envoy は C++ です。Linkerd は Rust です。これらはインフラです。アプリケーションの下に位置し、速く、小さく、そして信頼性が必要です。エージェントのガバナンス、メモリサーバ、MCP プロキシも同じ種類のものです。それらにはシステム言語がふさわしいのです。

5 つのプロジェクトを作った今でも、選択を後悔していません。バイナリは小さく、デプロイは簡単で、並行性のモデルは問題に完全に合っています。そして依存関係の数はほぼゼロのままです。エコシステムのコストは現実のものですが、管理可能です。最終的にはもっと多くのコードを書くことになりますが、すべてを理解できます。

この種の仕事で Go を検討していて、迷っているなら、小さなプロジェクトを 1 つだけ試してください。単一の MCP サーバでもいいでしょう。最悪の場合、何かを学べるだけです。私のこの一連の取り組みも、だいたいそんな始まり方でした。

言及したすべてのプロジェクトはオープンソースです：agent-mesh、mem7、scout7、ollama-mcp-go。