エージェントの主導権と、システムが「直そうとする」罠

GoでAIエージェントを書く選択肢が増えた——Microsoft Agent Frameworkのパブリックプレビュー

MicrosoftがAgent Framework for Goをパブリックプレビューで公開した。2025年10月に.NETとPython向けに導入されたAgent Framework——AutoGenとSemantic Kernelを統合したオープンソースツールキット——に、Goが加わった形だ。

なぜこれが気になるか。Goで書かれたインフラの層は厚い。Kubernetes、Docker、Terraform。全部Goだ。クラウドネイティブの現場でGoを使わない日はないと言っても過言じゃない。そのGoでAIエージェントを書けるというのは、既存のマイクロサービスやバックグラウンドワーカーにAI機能を組み込むハードルが下がることを意味する。

これまでの選択肢は限られていた。Goでエージェントサービスを立てたい、インフラツールに自律的な判断機能を載せたい——そういうチームは、公式SDKがないなかで自前のラッパーを書くか、PythonのSDKを呼ぶためのグルーコードを挟むかだった。どちらも本番運用で悩ましい。

Googleはすでに動いている。2025年4月にPython限定でAgent Development Kit（ADK）を出し、同年11月にGo対応を追加。2026年3月には1.0をローンチした。Goの生みの親がGoogleであることを考えれば、自然な流れだろう。一方で、OpenAIとAnthropicはGo向けの公式SDKを出していない。基盤モデルの最大手2社がここに穴を開けている。

MicrosoftのGo SDKで何ができるか。Azure OpenAI、Anthropic、Geminiのモデル呼び出し。ツール呼び出しとMCPサポート。

（MCP: Model Context Protocol。AIモデルが外部データやツールに標準化された形式でアクセスするためのオープンプロトコル）複数エージェントの協調。グラフベースのワークフローで条件分岐やサブワークフロー、チェックポイント、人間の承認ステップを組み込める。「プロダクションレベルのオーケストレーションであって、チャットループのラッパーではない」という評価がある通り、単発のプロンプト呼び出しから脱却するための構造が揃っている。

ただし、できないこともある。handoff orchestrationとCodeActは.NET版にあるが、

（CodeActとは、AIがコードを生成して直接実行し、その結果をループに組み込むことで複雑なタスクを完遂する手法）Go版にはまだ来ていない。パブリックプレビューであることを考えれば当然だが、.NET版との機能差をプロダクションでどう扱うかは課題になる。

実務への影響を考える。Kubernetesのオペレーターにエージェント機能を載せたい、Terraformプロバイダーに自律的な修復ロジックを組み込みたい——こういう要件に、Goで一貫して書ける道が開けた。Pythonで書かれたエージェント層とGoのインフラ層の間でコンテキストを行き来させるアーキテクチャから、Go内で完結する設計に移れる可能性がある。

どこまで実務で使えるかは、まだ分からない。パブリックプレビューだし、機能差もある。ただ、GoでAIエージェントを書く選択肢がMicrosoftとGoogleの両方から出たこと自体が、エコシステムの重心を動かすかもしれない。インフラの言語とエージェントの言語が同じになる——そこには、運用や監視の設計をシンプルにする余地がある。

ツールを良くしたらレビューが悪くなった話

GitHubがCopilot code reviewの内部ツールを入れ替えた。独自のコード探索ツールから、Copilot CLIと共通のUnixスタイルツール（grep、glob、view）に移行した。保守性の観点では正しい判断だ。共通基盤にすれば改善が複数製品に波及する。ところがベンチマークを見ると、レビューのコストが上がり、検出できる問題数は減っていた。

原因はツールじゃなかった。指示だった。

古い独自ツールは、1回の呼び出しで一致行と周辺コンテキストをまとめて返す設計だった。昔のモデルはツール呼び出しの回数が少なく、文脈を自力で引きに行かない。だから最初から多めの情報を載せておく方が結果が良かった。一方、新しい共通ツールは薄いラッパーで、必要な分だけを返す。この差が、エージェントの挙動を変えてしまった。

トレースを見ると、移行後のエージェントが「リポジトリをブラウズする」ような動きを繰り返していた。広く検索し、推測でパスを当て、広く読み、さらに検索対象を見つけていく。これは「リポジトリを理解する」タスクなら正しい振る舞いだ。でもPRレビューはそうじゃない。

自分がPRをレビューするときを思い出すと、diffから始まって的を絞った質問に答えていく。「この関数はどこで呼ばれているか」「この設定キーは他に使われているか」。最小限の文脈で質問に答えたいのであって、関連ありそうなファイルを片っ端から開きたいわけじゃない。

エージェントにとってツールの戻り値は使い捨てのprintではない。コンテキストウィンドウに残り続けるトークンだ。広く探索すればするほど、後段の推論にノイズが積み上がる。コストも上がるし、焦点もぼやける。

GitHubチームは指示を書き直すことでこの問題を解決した。結果としてレビューの平均コストが約20%低下し、品質は維持された。ツールの移行自体はうまくいかなかったが、ワークフローをPRレビューの実態に合わせて再設計したことで逆転した。

この話から読み取れる教訓は、エージェントの設計においてツールの機能と指示は不可分だということだ。同じツールでも、どう動かすかで結果が変わる。エージェントフレームワークのツールをそのまま使うと、そのツールが想定したユースケースに暗黙に引きずられる。今回はCLI向けの指示が「広く探索せよ」という方向を暗に含んでいて、それがレビューには合わなかった。

自分がエージェントを組むときも、ツールのインターフェースだけ見て「機能は同じだからそのまま移行できる」と考えがちだ。でもツールが返す情報の粒度と、その情報がエージェントの推論にどう影響するかはセットで考える必要がある。そこを外すと、一見合理的な移行が静かに効率を削ることになる。

グレーゾーン障害が地域全体を落とす話と、EKSが取った静的安定性のアプローチ

AWSが数百万のEKSクラスタを運用して学んだ教訓は、想像していたのと少し違った。サーバが死んで別のものを立ち上げる、そんな分かりやすい障害は簡単な方だ。実際にリージョン全体を落とすのは、ゾーンが「遅いだけで死んでいない」状態だ。ヘルスチェックの一部だけ落ちて、まだ生きているふりをする。この微妙な状態で、多くの自動化システムのデフォルト動作が裏目に出る。不健康を検知して置き換える、この正しいはずの振る舞いが、単一ゾーンの問題をリージョン障害に変えてしまう。

EKSの制御プレーンはAPIサーバとetcdで構成され、複数のアベイラビリティゾーンに分散されている。あるゾーンが到達不能になれば、他のゾーンのインスタンスが処理を続ける。図面上はこれで問題ない。だが、ゾーンがきれいに死ぬことは稀だ。AWSが初期によく遭遇した障害モードは、ヘルスチェックとAuto Scalingの組み合わせによるカスケード障害だった。制御プレーンのインスタンスはネットワークロードバランサの背後にあり、Auto Scalingグループがヘルスチェックを監視している。30秒間に何度かチェックに失敗したら不健康とみなし、インスタンスを置き換える。普段なら正しい動きだ。しかしゾーンのネットワークが部分的に劣化している最中は、インスタンス自体は壊れていないのに手前のネットワークが原因でヘルスチェックに落ちる。そしてスケーリンググループがそのインスタンスを終了させる。置き換えのプロビジョニングも同じ障害ゾーンで失敗し、最大30分間のバックオフに入る。ロードバランサのヘルスチェックも、APIサーバがetcdに到達できるかを含むため、ゾーン間のネットワークが一瞬切れただけで健康なインスタンスが失敗扱いになる。結果として、30秒のネットワークの瞬断がフリートの大部分を終了させ、ウォームキャッシュを捨て、すでに苦しい依存先に負荷をかけ、根本原因が解決した後も30分間復旧を拒む。

ここでAWSが至った原則が「静的安定性」だ。

（静的安定性/Static Stability：外部の依存関係や制御系に障害が発生しても、システムが現在の状態を維持し、即座に不安定な挙動（再起動の連鎖など）に陥らない設計思想）ゾーンの劣化時において、システムが最も価値ある行動とは、反応を止め、既存のキャパシティを維持し、悪いゾーンを迂回し、待つことだ。この原則に基づいてEKSが構築した自動ゾーンシフト機構が、約2分で制御プレーンのアクティビティを劣化ゾーンから移動させる。並列で複数のシステムに働きかける。DNSレイヤでは、パブリックエンドポイントのクラスタに対し、劣化ゾーンのヘルスチェックを失敗させ、そのゾーンのレコードを返さなくする。スケーリンググループレイヤでは、劣化ゾーンのヘルスチェック失敗への反応を停止させ、終了のカスケードを終わらせる。Kubernetesレイヤでは、リーダー選出されるスケジューラやコントローラマネージャ等のリーダーが劣化ゾーンにいる場合、健康なゾーンへリーダーシップを移す。さらに劣化ゾーンのAPIサーバは自身のIPアドレスの広告を止め、Podからのリクエストが健康なAPIサーバに向かうようにする。

この設計の根底にある原則は、健全なゾーンが修正アクションを実行するということだ。劣化ゾーンに何かを判断させるのではなく、動いている側で迂回と保持を決める。自分が普段組んでいるマイクロサービスのヘルスチェックやオートスケーリングでも、同じ罠が潜んでいるはずだ。部分劣化のときに「直そう」とする動きが全体を壊す。静的安定性という考え方は、Kubernetesに限らず、分散システム全般で意識すべき筋の良さを感じる。

Claudeの「reflection」が浮き彆りにした、AI利用分析の筋の悪さ

AnthropicがClaudeの新機能「reflection」をベータリリースした。Free、Pro、Maxユーザーでメモリ機能をオンにしていれば利用できる。過去1、3、6、12ヶ月のアクティビティを振り返り、何にClaudeを使ったか、どんなパターンがあるかをダッシュボードで確認できる仕組みだ。Anthropicの説明では、メールの推敲を自分の声でよくやっているとか、戦略を決めてからタスクを委譲しているとか、そういう使い方の傾向を可視化するという。

しかし、これだけでは開発者の実務に役立つ洞察にならないと、複数のエンジニアリングリーダーが指摘している。GoGlobyのCTO、Sergey Matikaynenは「使い方を考えさせるツールが、判断力を向上させるわけではない」と一刀両断。Columbia大学の助教でもあるTraversalのCEO、Anish Agarwalも「コーディングの80%をAIでやったと知っても、働き方は変わらない」と語る。

彼らが求めているのは、もっと成果に直結する信号だ。Agarwalは「どのAI生成変更がインシデントにつながったか」「どれが大幅な人間のレビューを必要としたか」「エンジニアが数秒で承認したコードのデバッグに何時間費やしたか」といった問いを挙げる。つまり、AIアシストのPRレビューにどれだけ時間がかかっているかといった配送指標（delivery signal）であり、活動量（engagement signal）ではない。Matikaynenも同様で、今のreflectionは「出荷に値するものを生み出したかと無関係な活動カウント」に過ぎないと批判する。

自分のワークフローで考えると、この指摘は腑に落ちる。KubernetesのマニフェストやTerraformのコードをClaudeに書かせた回数が増えたと知って、どうなるのか。本当に知りたいのは、その生成コードが本番環境でどう振る舞ったか、レビューでどれだけ手戻りがあったかだ。AIの利用頻度が高いことと、それが良い結果を出していることは別物なのに、reflectionは前者しか映さない。

さらに構造的な問題もある。AIにAIの使い方を判断させるという皮肉だ。Claudeが知っているのは、自分との会話だけ。組織の長年の生産履歴、アーキテクチャの文脈、インシデントの知見は持っていない。そのための判断は、各組織のエンジニアリングやセキュリティのリーダーが担うべきだと、VeracodeのChris Wysopalは指摘する。加えて、Anthropicのビジネスモデルは使用量の増加に依存している。利用を控えるよう促すインセンティブが構造的に乏しい中で、ベンダーが出す「効果的な使い方」の提案をどこまで信じるか。

AI利用の自己評価という需要自体は本物だと思う。ただ、それを満たすには、エディタやCI/CDパイプライン、インシデント管理といった、開発の実際の成果と結びついたデータが必要になる。会話ログの集計だけでなく、その先のアウトカムまで繋がる分析基盤が出てこないと、自己満足の振り返りで終わるだろう。

AIエージェントの主戦場はペルソナではなく制御平面にある

OpenAIが7月9日にChatGPT Workを発表した。新しいGPT-5.6上で動き、ローカルファイルの参照、Google WorkspaceやMicrosoft 365ドキュメントの編集、複数ステップのタスクを最終成果物まで完遂する。ReutersはこれをAnthropicのClaude Coworkとの直接対決と位置づけている。どちらもターミナルを使わずにコーディングエージェントの力を求める非開発者を狙っている。ここ数ヶ月で、OpenAI、Microsoft、Anthropic、Perplexity、Amazonという5つの主要ラボが同種のエージェントを投入した。面白いのは、機能の差よりもターゲットユーザーで整理されている点だ。

記事は4つのアーキタイプを提示している。知識労働者向け、セルフホストするパワーユーザー向け、開発者向け、エンタープライズ向け。ChatGPT WorkやClaude Cowork、MicrosoftのCopilot Cowork、Perplexity Computer、Amazon Quickが知識労働者向け。OpenClawやHermesのようなオープンソースはパワーユーザー向け。Claude CodeやOpenAI Codex、GitHub Copilotのエージェントモードは開発者向け。LangGraphやCrewAIをマネージドランタイムで動かすADKやStrands、Agent Frameworkはエンタープライズ向け。一人の人間が複数のペルソナを兼ねることもあるし、Claude Codeのように個人開発者とプラットフォームチームの両方に使われる製品もある。

ここからが本題だ。ペルソナの背後には、各ラボがほぼ一貫して決めている4つの事項がある。誰がランタイムを所有し、メモリを永続化し、認証情報を管理し、ポリシーを施行するか。Kubernetesでいうコントロールプレーンに相当する部分だ。Anthropicは自社の設計を「脳と手を分離する」と表現している。Claudeを呼ぶハーネスとコードを実行するサンドボックスは別物。セッションはモデル呼び出し・ツール呼び出し・結果の追記専用ログで、コンテナが存在する前に推論を開始でき、開発者の認証情報からは遠い場所でコードが動く。他のベンダーでも同じ4つのプレーンが姿を現す。AWSのAgentCore Runtimeは各セッションに専用のmicroVMを割り当て、CPU・メモリ・ファイルシステムを分離し、コンピュート使用量をメータリングする。

私が気になるのは、この4つのプレーンを誰が握るかが、そのままベンダーロックインの強さになる点だ。ランタイムも状態もポリシーもベンダーが管理するアーキタイプでは、乗り換えコストが単なるデータ移行では済まなくなる。セッションログや認証情報の持ち出しをどこまで許すか。記事タイトルの「何を取り戻せるか」は、まさにここを指している。Terraformでインフラをコード化するのは、状態を自分で管理するためだった。エージェントでも同じ判断が迫る。ハーネスを自前で持つか、ベンダーのサンドボックスに委ねるか。開発者のワークフローで言えば、CIパイプラインの実行環境をどこに置くかという古い問いの最新版かもしれない。

まとめ

GoでAIエージェントを書く選択肢が増え、インフラ層にAI機能を組み込むハードルは下がった。だが、選択肢が増えただけでは上手く回らない。

エージェントの振る舞いも、クラウドの障害対応も、AIの利用分析も、デフォルトの動きに任せると裏目に出る。

ツールの戻り値の粒度が推論にノイズを積み上げる。部分劣化への自動修復がリージョン全体を落とす。AIの利用頻度は成果の代わりにならない。どれも「動いているように見えて、本当に解決したい課題から目を逸らす」罠だ。

システムが勝手に回す振る舞いに、そのまま乗せていいのだろうか。

通底するのは、制御の主導権をどこに置くかだ。エージェントの指示をタスクに合わせて書き直すのか。健全なゾーンで迂回を決めるのか。成果に直結する配送指標を自分で追うのか。ランタイムやポリシーを自前で持つのか。便利な抽象化の裏で、誰がコントロールプレーンを握っているかを意識しないと、ただの消費者に終わる。

自分の現場で何を制御し、何を委ねるのか。その線を引くのがエンジニアの仕事になる。ベンダーのサンドボックスに認証やポリシーを預けるのか、Goで一貫して書くのか。静的安定性のように、悪い状態のときにこそ「動かない」選択肢を持てる設計にしておきたい。

参照記事

記録日: 2026-07-12