AIエージェントの標準化と、見えなくなる低レイヤーのリスク

インシデント対応でMCPとAPIを使い分ける意味

Model Context Protocol（MCP）が注目され始めてから一年半ほどが経つ。

（MCPは、AIモデルが外部データソースやツールにアクセスするためのオープン標準プロトコルである）「APIの終わり」といった過剰なフレーズが飛び交った時期もあった。しかし現実はもっと地味で、もっと実用的だ。MCPはAPIを置き換えるものではなく、並んで動くものとして設計されている。この記事が主に論じているのは、インシデント管理という現場でその補完関係がどう機能するか。

インシデント対応の現場では、ツールの乱立が慢性問題になっている。監視、アラート、チャット、変更履歴、サービスオーナー情報がバラバラの場所に散らばっている。オブザーバビリティのツールだけでもDatadog、PagerDuty、Slack、GitHubと複数をまたぐのが普通だ。MCPが有望なのは、この断片化を解消する標準化された経路を提供する点にある。AIエージェントが複数のツールやベンダーから必要なコンテキストに一貫した方法でアクセスできる仕組みだ。

一方でAPIの強みは、決定論的な制御にある。インシデントの復旧フェーズで「確実にロールバックを実行する」といった操作は、AIの解釈の余地を残したくない。高速かつ確実に、何度実行しても同じ結果を返す必要がある。認証フロー、監査ログ、きめ細かい権限制御という観点でも、APIはSOC2準拠の要件を満たしやすい。

（SOC2は、セキュリティ、可用性、機密性などの基準を満たしていることを証明する監査レポートの規格）MCPも既存のAPIと同じ認可・権限を利用できるが、AIエージェントが何を実行するかを選ぶ以上、人間の承認を挟む追加の安全層が求められる。

ではMCPはどこで輝くのか。トリアージ、診断、調査のフェーズだ。「EUリージョンでチェックアウトエラーが急増しているのはなぜか」と自然言語で問いかけると、MCP経由のエージェントはインシデント管理プラットフォームから現在のインシデント詳細を、監視ツールからイベントデータを、SlackやMicrosoft Teamsから関係者の更新情報をまとめて引き寄せられる。原因仮説の提示や次の検証ステップの提案まで含めて、一箇所で俯瞰できる。手順が事前に決まっていない、探索的で動的なシナリオではMCPの柔軟性が生きる。

自分の感覚としてしっくりくるのは、この「決定論的か否か」の切り口だ。普段書いているマイクロサービス間の通信は、ほぼすべて決定論的なワークフローに該当する。CI/CDパイプラインがデプロイサービスにロールアウトを指示する、監視ツールがメトリクスを問い合わせる、これらはAPIの領分でしかない。MCPの出番は、人間が自然言語でシステムに問いかけ、文脈をまたいで情報を編集したい場面だ。インシデント対応の初期段階、まさに「何が起きているかを把握する」時間帯こそが、MCPの真価を発揮するシーンになる。

気になる論点が一つ。MCPが標準化層として機能するには、各ツールがMCPサーバーを提供しなければならない。現状、主要なSaaSがどこまでMCP対応を進めているのか、エコシステムの成熟度がまだ見えない。APIは長年の蓄積がある。MCPがインシデント管理で真の戦略的価値を出すには、ツール間の相互運用性が前提になる。そこが整うまでの過渡期には、APIとMCPの混在をどう運用に落とし込むかが実際の課題になるだろう。

エンタープライズAIスタックの標準化が始まった

AnthropicがUSTを2番目のGlobal Premier Partnerとして迎えた。USTは20,000人の開発者と技術専門家をClaudeで訓練・認定する。単なる販路拡大じゃない。ここにあるのは、AIモデルの選択権が開発者個人の手からプラットフォームチームの手へ移るという構図だ。

PoCから本番運用への移行でつまずく企業は多い。開発チームごとに別のLLMを使っていると、属地的な構成が散らばるだけだ。USTはClaudeを自社のエンジニアリングプラットフォームに組み込み、半導体や通信、製造業の顧客に提供する。モデル選択がアーキテクチャの決定事項になる。プラットフォームレベルで一度選ばれ、その上で動く全チームが継承する。こういう未来が来るかもしれない。

具体的なユースケースとしてUST-iDECがある。ハードウェアとシリコンの検証プラットフォームで、サイクルタイムを最大70%短縮し、ターンアラウンドを半分にしているという。Claudeがチップのピンアウトや回路図を読み取り、回帰テストを自動で書いて実行する。デジタルツインとエッジデータを照合してファームウェアのデグレを検出する。AIをスタンドアロンのアシスタントとしてではなく、パイプラインの一部に組み込む方向性は明確だ。

標準化の恩恵は大きい。共有ワークフローが再利用可能になり、ガバナンスポリシーを中央で強制できる。内部システムとの統合もプロジェクトごとに作り直さなくて済む。ただし開発者は、自分の好みのモデルを選ぶ自由を手放すことになる。Kubernetesのランタイムを各チームが自由に選べないのと同じような制約だ。

Anthropicのパートナーネットワークでは既に10,000人以上のコンサルタントがClaude認定を取得している。USTの20,000人が加われば、合計で30,000人規模の認定人材が動くことになる。SIerが特定モデルをプラットフォームに埋め込む流れが加速すれば、モデルの調達判断は調達・プラットフォーム部門の仕事になる。現場のエンジニアが「このタスクにはこっちのモデルが適している」と差し替える余地はどこまで残るのか。そこが次の論点になるはずだ。

HTTP 200でデータが欠けるバグを6週間追った話

CloudflareのImagesサービスで、奇妙な不具合が起きていた。画像変換リクエストのレスポンスが断続的に途切れる。それも、HTTP 200 OKを返しているのに、である。期待される3.3 MBのうち200 KBしか届かないケースがあった。Content-Lengthは正しいのに、本体が切れている。アプリケーションのログにはエラーが出ない。モニタリングも正常を示す。顧客からの報告でようやく異常に気づいたという。

原因は、RustのHTTPライブラリhyperに潜んでいた。HTTP/1のディスパッチループで、バッファのフラッシュが完了する前に接続を閉じてしまうレースコンディション。バッファに残ったデータが、数ミリ秒のタイミングのズレで捨てられる。Cloudflareのチームは6週間かけてこのバグを追い詰め、最終的に4行の修正で解決した。修正とテストはすでにhyperにマージされている。

デバッグの過程が興味深い。アプリケーションレベルのトレースやログには何も出なかった。突破口はstraceだった。

（straceは、プロセスが発行するシステムコールを追跡し、カーネルレベルの挙動を可視化するデバッグツール）カーネルのシステムコールを直接観察して、ようやくhyperがソケットを过早に閉じていることを突き止めた。「ソケットで実際に何が起きたかを記録する唯一のレイヤー」とチームは振り返っている。分散トレースで原因を絞り込む手法はよく聞くが、最後の詰めでstraceに戻ったというのは地味だが実戦的だ。

このバグは、async Rustの構造的な問題と関係しているかもしれない。RustコンパイラのコントリビューターであるMartin Nordholtsは、「sync Rustではコンパイルが通れば動くが、async Rustではそうではない」と指摘し、サイレントキャンセルという問題クラスを挙げている。非同期コンテキストでFutureがドロップされると、途中の処理が黙って消える。

（RustにおけるFutureは、完了予定の計算を表すオブジェクトであり、これが破棄（drop）されると実行中のタスクが中断される特性を持つ）今回のバグも、その一例と読める。またHacker Newsでは、Clippyのリントlet_underscore_untypedやlet_underscore_must_useを有効にしていれば検出できたはずだという指摘が出ている。デフォルトでないリントを見落としていたこと自体が、また別の教訓だろう。

気になるのは、Cloudflareが顧客の報告まで壊れたレスポンスに気づかなかった点だ。「スケールで壊れたレスポンスを送っていることに気づかないのか」という疑問はもっともだ。レスポンス本体のサイズとContent-Lengthを照合する監視を入れていれば、もっと早く検知できたはずだ。私がマイクロサービスを書いている立場で考えると、この手のサイレントなデータ欠損は一番怖い。ステータスコードは正常、メタデータも正常、中身だけ壊れている。モニタリングの前提そのものを見直す必要がある。

もう一点、hyperのメンテナーであるSean McArthurへの支援の薄さも指摘されている。年間20億ドルの収益を上げる企業が、収益のクリティカルパスにあるライブラリのメンテナーを直接支援していない。オープンソースの持続可能性という古くて新しい問題が、また顔を出した形だ。

GoでAIエージェントを書く選択肢がようやく増えた

MicrosoftがAgent FrameworkのGo向けSDKをパブリックプレビューで公開した。もともと.NETとPythonだけだったAgent Frameworkに、Goが加わった形だ。対応するモデルはMicrosoft Foundry、Azure OpenAI、Anthropic、Gemini。ツール呼び出し、MCPサポート、複数エージェントの協調まで揃っている。ただし、handoffオーケストレーションとCodeActという機能はまだ.NETのみで、Goには来ていない。プレビュー段階だから仕方がないにしても、ここは要注目だろう。

なぜこれが気になるか。Goはクラウドインフラの共通語だからだ。Kubernetes、Docker、Terraform、どれもGoで書かれている。普段のマイクロサービスやバッチジョブをGoで書いているチームは少なくない。そういう現場でAIエージェントを組み込みたいとき、これまではPythonのSDKを使うために別言語のサービスを立てるか、非公式のラッパーに頼るしかなかった。Agent FrameworkがGoに届いたことで、既存のGoサービス内でエージェントを動かす道が開けた。実務で何が変わるかといえば、インフラ回りのツールにAIの判断を仕込むハードルが下がる、ということだ。

Googleの動きも見逃せない。GoogleはAgent Development Kit（ADK）を2025年4月にPythonだけで出し、11月にGo対応を追加、今年3月に1.0をリリースした。GoはもともとGoogle生まれの言語で、KubernetesやDockerを通じてクラウドネイティブのデファクトになった経緯がある。だからGoogleがGoを押すのは自然だし、Microsoftが追従するのも筋が通る。クラウドインフラを支える言語でエージェントを書けるようにしないと、実務での採用が進まないという判断が読み取れる。

一方で気になるのが、OpenAIとAnthropicの不在だ。この2社はまだGo向けの公式SDKを出していない。Azure OpenAIやGeminiのモデルはMicrosoftのフレームワーク経由でGoから叩けるが、OpenAIのAPIを直接Goで呼ぶ公式手段がない。現場では非公式ライブラリを使い回しているケースが多いはずで、ここが埋まらないと結局Pythonに頼る場面が残る。

「プロダクション級のオーケストレーションであって、チャットループのラッパーではない」という評価がコミュニティから出ている。条件分岐やサブワークフロー、チェックポイント、ヒューマンインザループあたりが押さえられているからだ。ただ、機能の取りこぼしがある以上、どこで使うかは慎重に見極める必要がある。Goで書けること自体は嬉しいが、足りないものは足りない。

まとめ

AIエージェントを実務に組み込む標準化が、複数のレイヤーで動いている。MCPがツール間の標準化経路として期待され、エンタープライズではモデル選択がプラットフォームチームに集約されつつある。Go向けのエージェントSDKも出始め、インフラ周りのツールにAIの判断を仕込むハードルは下がった。

ただし、標準化や抽象化が進む裏で、足元の制約は残る。MCPのエコシステムの成熟度、OpenAIやAnthropicの公式SDK不在、開発者がモデルを選ぶ自由度の喪失。ここが整わない限り、従来のAPIやPythonに頼る場面は残る。

高レイヤーの抽象化が進むと、低レイヤーの挙動が見えなくなるリスクもある。Cloudflareの事例は、ステータスコードやメタデータが正常でも中身が壊れているケースを示している。MCP経由でエージェントが複数ツールからコンテキストを引き寄せる未来において、こうしたサイレントなデータ欠損がどう影響するか。見えない部分の監視をどう設計するか。そこが次の課題だ。

参照記事

記録日: 2026-07-13