MicrosoftのAzure SRE Agentチームが、インタラクティブCLIよりも先にMCPサーバーをリリースする設計判断の背景と、人間とAIエージェントの両方を同時に相手にするインターフェース設計の原則を公開した。

なぜMCPサーバーが最初なのか

Azure SRE Agentには、設計当初から3種類のインターフェースが想定されている。

  • インタラクティブCLI — 深夜2時のインシデント対応中にターミナルを叩く人間向け。簡潔で障害対応に最適化
  • エージェントモード — Copilot CLIのようなコーディングエージェントがサブプロセスとして起動するモード
  • MCPサーバー — コーディングエージェントの中にいる人間、および他のエコシステムで動くリモートエージェント向け

CLIとエージェントモードには共通点がある。呼び出し側が「Azure SRE Agentの存在を知っていて、意図的に呼び出す」必要がある点だ。人間がコマンドを打つ、あるいはエージェントがサブプロセスを起動する——いずれも能動的な呼び出しだ。

MCPサーバーはまったく異なる動作原理を持つ。ツールとして呼び出し側がすでにいる環境の中に自分を露出する。SREエンジニアがCopilot CLI上で「APIゲートウェイの何が問題か」と尋ねると、モデルがツール説明を読んで適切なツールを発火させる。別のターミナルを開く必要はない。PagerDutyのSREエージェントがトリアージループを回す際も、サブプロセスを起動せずプロトコルで直接応答を得る。

この違いを一言でまとめると：CLIは意図を要求し、MCPサーバーは呼び出し側の居場所に出向く。

MCPサーバーが相手にする2種類の呼び出し元

MCPサーフェスには、同じプロトコルを使いながらまったく異なる文脈の2種類の呼び出し元がいる。

コーディングエージェントの中にいる人間：VS Code CopilotやClaude Desktop、Cursor上でデプロイスクリプトを書いたりRunbookを読んでいるSREエンジニアだ。コンテキストスイッチを望まず、今やっている作業の傍らにSREの能力が自然に存在してほしい。MCPサーバーを一度接続すれば、それは常にそこにある。

他のエコシステムのリモートエージェント：クロスクラウドインシデントを処理するAWS DevOpsエージェント、トリアージループを回すPagerDutyのSREエージェント、あるいは別のAzure SRE Agentインスタンスがサブタスクを委譲する場合などだ。カスタム統合なしに、プロトコルで合意するだけで相互運用できる。

呼び出し元 文脈 必要なもの

Copilot CLI / VS Code Copilot上の人間 コーディングセッション中 読みやすい要約、最小限のオーバーヘッド

Claude Desktop / Cursor上の人間 エージェンティックセッション 会話内でSREツールが使える状態

AWS DevOpsエージェント 自動インシデントループ 定義されたスキーマ、安定したフィールド

PagerDuty SREエージェント トリアージパイプライン パーサブル、疎、ナラティブ不要

別のAzure SRE Agentインスタンス 委譲されたサブタスク エージェント間コントラクト

ツール説明文はプロダクト意思決定そのもの

MCPツールには名前、自然言語の説明、JSONスキーマが付く。この説明文がモデルのツール選択を直接左右するという点は、見落とされがちながら極めて重要だ。

「Azureリソースのヘルス状態を返す」と書かれたツールと、「VMやゲートウェイ、データベース、コンテナが正常・劣化・到達不能のいずれかを確認する。アクティブな障害の診断やデプロイ後の状態確認に使う」と書かれたツールでは、モデルの呼び出し精度が大きく変わる。

後者は「何をするか」だけでなく「いつ使うか」を伝える。チームはツール説明をシステムプロンプトと同様にイテレーションした——テスト中に誤った呼び出しが発生したとき、修正箇所はほぼ常にスキーマではなく説明文だったという。

人間とエージェント、なぜ同じ出力形式を使うのか

人間は読みやすいレスポンスを求め、リモートエージェントはパース可能な構造を求める。「呼び出し元に応じて出力形式を切り替えるべきでは？」という発想は自然だが、チームはあえて単一の出力形式を選んだ。

すべてのツールレスポンスは、定義されたフィールドと安定したセマンティクス、そして1つの summary フィールド（平文の1文）で構成される。人間は summary を読み、リモートエージェントはそれを無視して構造化フィールドをパースする。オーバーヘッドはどちらの方向でも無視できる程度だ。

リクエストヘッダーに呼び出し元タイプのヒントを乗せる案も検討されたが、ヒントが誤っていたり欠落した場合の失敗モードが増える問題があった。「常に単一形式」という判断は、表面積を最小化し保守コストを下げる。

ステートレス設計の罠

MCPツールは設計上ステートレスだ。各呼び出しは独立している。リモートエージェントにとってこれは利点だが、インタラクティブに作業する人間にとっては摩擦になる。

チームの解決策は「全レスポンスを自己完結させる」こと。ツールが返すデータは、モデルが前のコンテキストなしに自然な次の呼び出しを構築できるだけの情報を含む。ツールは記憶しない——記憶は安価に再構築できる形で情報を返すことで対応する。

実務への影響

Azure・マルチクラウド環境を持つ日本のエンタープライズにとって、このアーキテクチャは実装方針の参考になる。

  • MCPサーバーをAPIの「共通窓口」として設計する発想：カスタム統合を積み重ねるのではなく、MCPプロトコルで合意すればAWS側のエージェントもAzure側のツールを叩ける設計は、マルチクラウド統合の煩雑さを大幅に減らす
  • ツール説明文の品質管理を開発プロセスに組み込む：AIエージェントが正しくツールを選ぶかどうかは説明文の質に依存する。PMとエンジニアとコンテンツデザイナーが共同でレビューする体制は参考にする価値がある
  • 自動化パイプラインのAPIには「人間が読んでも機械が読んでも意味がわかる」出力形式：人間用と機械用で別エンドポイントを切るよりも、summary フィールドを1つ添えた単一スキーマの方が長期的な保守コストが低い

筆者の見解

Azure SRE Agentの設計方針として興味深いのは、MCPというプロトコルに賭けたことだ。「両側がプロトコルに合意すれば、お互いの内部実装を知らなくていい」という原則は、非常に正しい。カスタム統合を積み重ねてきた結果、蜘蛛の巣のような依存関係に苦しんでいるエンタープライズは多い。標準プロトコルで疎結合を保つアプローチは、長期的なメンテナンスコストを大きく下げる。

エージェントが実際に「使えるツール」を選ぶのはツール説明文——という知見も実装者として覚えておきたい。プロンプトエンジニアリングの重要性はよく語られるが、ツール説明文の質を同列に扱う文化は日本ではまだ浸透していない。

Azureのインフラ管理・SRE領域に特化したエージェント基盤をMicrosoftが育てているという事実は、「エージェントが安全に動作するプラットフォーム」という長期戦略の文脈で見ると一貫性がある。個々のモデルの優劣ではなく、エージェントが集まるプラットフォームを押さえるという方向性だ。この競争においてMicrosoftには確かに強みがある。今後のCLIとエージェントモードの実装も注視したい。

出典: この記事は Who’s Calling Your Service? Designing for Humans and Agents at the Same Time の内容をもとに、筆者の見解を加えて独自に執筆したものです。