Microsoftの公式ブログ記事「The AX stack: what’s fixed, where you can win」は、AIコーディングエージェントを「どう使えばよいか」ではなく、企業や開発チームがどこを改善すれば生成コードの品質を上げられるのかを整理した内容です。結論から言うと、開発者や管理者が今すぐ見直すべきなのは、モデルそのものではなく、MCPサーバー、カスタム指示、スキル、カスタムエージェントなどのAgent extensionsです。ここを適切に設計・測定しないと、GitHub CopilotなどのAI coding agentsは「古いSDKを使う」「意図しないサービスを選ぶ」「コンパイルできないコードを出す」といった失敗を繰り返します。(Microsoft for Developers)
この記事では、Microsoftが示したAX stackの考え方をもとに、何が固定要素で、どこが改善可能なのかを整理します。管理者・開発者が確認すべき設定、MCPやカスタム指示の展開時に起きやすい失敗、導入後に効果を測るための実務ポイントまで解説します。
Microsoftの「The AX stack: what’s fixed, where you can win」は何を示した情報か
「The AX stack: what’s fixed, where you can win」は、Microsoftの開発者向けブログで公開された、Agent Experience（AX）に関するシリーズの初回記事です。AXとは、AIコーディングエージェントが特定の技術スタックを正しく使えるようにするための設計・改善の考え方です。(Microsoft for Developers)
ここで重要なのは、Microsoftが「AIエージェントの失敗原因」を単純にモデル性能だけで説明していない点です。AI coding agentsが期待通りに動かない原因は、モデル、エージェント本体、拡張機能、SDK/API、ワークスペース設定などが重なって発生します。
たとえば、次のような失敗は現場でも起きやすい問題です。
- 生成されたコードがコンパイルできない
- 非推奨になったSDKや古いAPIの書き方を使う
- Azure、Microsoft 365、GitHubなどのサービス選択を誤る
- 社内標準の認証方式やログ設計に従わない
- MCPサーバーを導入したのに、エージェントが使ってくれない
- カスタム指示を書いたのに、生成結果があまり変わらない
Microsoftの記事が示している実務上の結論は明確です。モデルやエージェント本体は多くの組織にとって直接変更できない固定要素であり、改善余地が大きいのはAgent extensionsの設計・設定・測定であるということです。
AX stackの全体像：固定されている層と改善できる層
Microsoftは、開発者のプロンプトから生成コードに至るまでの流れを、複数の層に分けて説明しています。大きく見ると、開発者の指示はエージェントを通り、モデルへ渡され、必要に応じてMCPサーバーやスキルなどの拡張機能が使われ、最終的にSDK/API/CLIを利用したコードが生成されます。(Microsoft for Developers)
実務では、各層を次のように整理すると判断しやすくなります。
| 層 | 代表例 | 組織が直接制御しやすいか | 確認すべきポイント |
|---|---|---|---|
| モデル | LLM本体 | 低い | 古い知識や偏りがある前提で補正する |
| ハーネス | GitHub Copilot、Cursor、Claude Code CLIなどのエージェント環境 | 低〜中 | ツール呼び出し、コンテキスト構成、対応機能の違いを確認する |
| Agent extensions | MCPサーバー、カスタム指示、スキル、カスタムエージェント | 高い | 小さく、明確に、測定可能に設計する |
| 技術サーフェス | CLI、SDK、API、社内ライブラリ | 中〜高 | 最新の推奨パターン、サンプル、移行方針を整備する |
| 生成コード | 実装、テスト、設定ファイル | 高い | ビルド、テスト、静的解析で検証する |
この中で、短期的に最も効果を出しやすいのはAgent extensionsです。モデルを再学習させることはできなくても、推論時に与える情報を整理すれば、古い知識や誤った選択をある程度補正できます。
変更点の要点：AIエージェント活用の評価軸が「プロンプト」から「AX設計」に広がった
今回の情報は、特定のMicrosoft製品に対する強制的な仕様変更や、すぐに移行が必要な破壊的変更を告知するものではありません。むしろ、GitHub Copilotを含むAI coding agentsを業務で使ううえで、開発者体験をどう設計すべきかを示す考え方の更新です。
従来、AIエージェントの精度が低いときは「プロンプトの書き方が悪い」「モデルが弱い」と捉えられがちでした。しかし、Microsoftの記事では、改善対象をより具体的に分解しています。
| 観点 | 従来ありがちな捉え方 | AX stackでの見方 |
|---|---|---|
| 生成コードが古い | モデルが古い | 最新情報をAgent extensionsで補う |
| ツールを使わない | プロンプトが悪い | ツール説明・名前・登録方法に問題がある可能性 |
| MCP導入後も品質が上がらない | MCPが役に立たない | 発見、選択、品質、共存性を個別に測る |
| あるIDEでは成功し、別の環境では失敗する | 利用者の操作差 | ハーネスごとのツール解釈差を評価する |
| 拡張を増やすほど賢くなる | 機能追加が正義 | コンテキスト競合により逆効果になる場合がある |
特に重要なのは、拡張機能を増やせば必ず良くなるわけではないという指摘です。エージェントが参照できるコンテキストには上限があり、MCPサーバー、ツール説明、カスタム指示、スキル定義が増えすぎると、必要な情報が省略・要約・無視される可能性があります。(Microsoft for Developers)
影響範囲：誰が確認すべきか
この情報の影響を受けるのは、単にGitHub Copilotを使ってコードを書く個人開発者だけではありません。むしろ、社内標準、開発基盤、SDK、API、MCPサーバーを提供する側に大きく関係します。
開発者への影響
開発者にとってのポイントは、AIエージェントの出力を「モデルの気分」として片付けないことです。生成結果が不安定な場合は、次の順で確認すると原因を切り分けやすくなります。
| 症状 | 疑うべき原因 | 最初に確認すること |
|---|---|---|
| 古いSDKを使う | モデルの学習済み知識が古い | カスタム指示やMCPで最新の推奨実装を渡しているか |
| 社内標準に従わない | プロジェクト文脈が不足 | .github/copilot-instructions.mdなどに規約が書かれているか |
| ツールを呼び出さない | Discovery failureまたはSelection failure | MCPサーバーが有効化され、説明文が自然な語彙になっているか |
| 出力が長いが使えない | Quality failure | 返却する情報が多すぎないか、指示が矛盾していないか |
| 別のIDEでは結果が違う | ハーネス差 | 同じモデル・同じプロンプト・同じ拡張で比較しているか |
GitHub Copilotでは、リポジトリのカスタム指示を使って、プロジェクトの理解方法やビルド・テスト・検証方法をCopilotに伝えられます。GitHub公式ドキュメントでも、リポジトリカスタム指示はプロジェクト固有の文脈を提供するための仕組みとして説明されています。(GitHub Docs)
管理者への影響
管理者にとって重要なのは、AIエージェントを「個人の便利ツール」として放置しないことです。MCPサーバーは外部サービスや社内システムと接続するため、権限管理、データ取り扱い、ツール承認、展開範囲を整理する必要があります。
VS Codeでは、企業環境向けにAI関連設定を集中管理でき、MCPサーバー、エージェントモード、チャットツールなどの利用をポリシーで制御できます。MCPサーバーのインストール元制限や、承認済みサーバーのレジストリ運用も管理対象になります。(Visual Studio Code)
Visual Studioでも、MCPサーバーの利用はGitHub側のポリシーや許可リストと関係します。組織管理者は、どのMCPサーバーを許可するか、エージェントモードやMCP接続を許可するかを確認する必要があります。(Microsoft Learn)
SDK・API提供者への影響
社内SDK、CLI、API、テンプレートを提供しているチームは、AX stackの考え方を特に重視すべきです。AIエージェントは、公開ドキュメントや過去のコード例に引っ張られます。古いサンプルが残っていると、非推奨の実装をもっともらしく生成する原因になります。
確認すべきことは、次の3つです。
- 最新の推奨実装が、短く明確な形で提示されているか
- 非推奨パターンと移行先が、AIにも人間にも分かる形で整理されているか
- MCPサーバーやカスタム指示が、実際の開発者の言葉で説明されているか
たとえば、ツール名が configure-identity-provider だけだと、開発者が「ログイン機能を追加して」と依頼したときにエージェントが関連付けられない可能性があります。説明文には「authentication」「login」「sign-in」「SSO」など、開発者が実際に使う言葉を自然に含める必要があります。
Microsoftが示した3つの失敗モード
Microsoftの記事では、Agent extensionsが失敗する代表的なパターンとして、Discovery failure、Selection failure、Quality failureの3つが示されています。(Microsoft for Developers)
Discovery failure：拡張機能が見つからない
Discovery failureは、拡張機能が存在していても、エージェントのコンテキストに入らない状態です。MCPサーバーをインストールしたつもりでも、設定ファイルの場所が違う、ワークスペースで有効になっていない、他の拡張が多すぎて優先されない、といった理由で発生します。
確認すべきポイントは次の通りです。
| 確認項目 | 実務での見方 |
|---|---|
| MCP設定ファイルの場所 | ユーザー単位、ワークスペース単位、リポジトリ単位のどこに置くべきかを決める |
| エージェントモードの有効化 | IDEや組織ポリシーで無効化されていないか確認する |
| ツール一覧への表示 | チャット画面やツールピッカーで認識されているか確認する |
| 権限承認 | 初回利用時の許可ダイアログでブロックされていないか確認する |
| 拡張の数 | 使わないMCPやスキルを入れすぎていないか確認する |
VS Codeでは、MCPサーバーをユーザープロファイルまたはワークスペースにインストールでき、ワークスペースに入れる場合は .vscode/mcp.json が更新されます。ローカルMCPサーバーは任意のコードを実行できるため、信頼できる提供元かどうかの確認も必要です。(Visual Studio Code)
Selection failure：見えているのに選ばれない
Selection failureは、エージェントが拡張機能を認識しているにもかかわらず、ユーザーの依頼と結び付けられない状態です。Microsoftの記事では、この失敗が特に多く、かつ修正しやすいものとして扱われています。(Microsoft for Developers)
よくある原因は、ツール名や説明文が提供者目線になっていることです。
| 悪い例 | 改善例 |
|---|---|
configure-identity-provider | 「ログイン、認証、SSO、OAuth設定に使う」ことを説明に含める |
provision-resource | 「Azureリソース作成、環境構築、初期セットアップ」に対応すると明記する |
generate-client | 「APIクライアント生成、SDK利用、型付きクライアント作成」に使うと書く |
validate-policy | 「セキュリティ規約、社内ルール、デプロイ前チェック」に関連付ける |
開発者は必ずしも製品内部の正式名称を使いません。「認証を入れて」「APIを呼びたい」「本番に出せる形にして」といった自然文の依頼が多くなります。Agent extensionsの説明は、正式名称だけでなく、開発者が入力しそうな言葉に合わせる必要があります。
Quality failure：使われたのに結果を悪くする
Quality failureは、エージェントが拡張機能を見つけ、選択し、呼び出したにもかかわらず、最終的な成果物が悪くなる状態です。これは最も気づきにくい失敗です。
原因として多いのは、情報の出しすぎです。MCPサーバーが大量のドキュメントを返す、カスタム指示が長すぎる、複数の指示が矛盾する、といった状態では、エージェントの判断がぶれます。
避けるべき例は次の通りです。
- SDK全体の長大なリファレンスを毎回返す
- 古い実装例と新しい実装例を区別せずに並べる
- 「必ずAを使う」と「Bを推奨する」が同じ指示内に混在する
- 社内ルールをすべて1つのカスタム指示に詰め込む
- テスト方法や検証コマンドを書かず、実装方針だけを渡す
実務では、エージェントに渡す情報を「短く、判断可能で、検証可能」にすることが重要です。たとえば認証実装の指示なら、思想の説明よりも「使用するライブラリ」「禁止する古いAPI」「最小サンプル」「実行すべきテストコマンド」を優先します。
管理者が確認すべき設定と展開ポイント
管理者は、AI coding agentsの利用範囲を広げる前に、MCP、カスタム指示、ツール承認、組織ポリシーを棚卸しする必要があります。特にMicrosoft系の開発環境では、Visual Studio、VS Code、GitHub Copilotの設定が分散しやすいため、どこで何を制御するかを明確にしておくことが重要です。
MCPサーバーの許可範囲を決める
MCPは、AIエージェントが外部ツールやデータソースを利用するための仕組みです。GitHub公式ドキュメントでも、MCPはGitHub Copilotを既存のツールやサービスと統合して機能拡張するためのプロトコルとして説明されています。(GitHub Docs)
便利な一方で、MCPサーバーには次のリスクがあります。
| リスク | 具体例 | 対策 |
|---|---|---|
| データ漏えい | ソースコードやチケット情報を外部サービスへ送る | 許可リスト、社内MCPレジストリ、データ分類ルールを整備する |
| 任意コード実行 | ローカルMCPサーバーがコマンドを実行する | 提供元確認、レビュー、承認プロセスを設ける |
| 権限過多 | PR作成、Issue変更、クラウド操作を広く許可する | 読み取り専用から始め、必要な操作だけ許可する |
| 設定の属人化 | 個人プロファイルにだけMCP設定がある | ワークスペース設定とリポジトリ管理方針を決める |
| バージョン差異 | 開発者ごとに異なるMCPサーバーを使う | 推奨バージョン、更新タイミング、検証環境を決める |
MCPサーバーは、最初から全開放するのではなく、利用目的ごとに段階展開するのが安全です。たとえば、最初はMicrosoft Learn MCP Serverのように公式ドキュメント参照を目的とするものから始め、次にIssue参照やPR確認、最後に変更系操作を許可する、といった順序が現実的です。
Microsoft Learn MCP Serverは、GitHub CopilotなどのAIエージェントがMicrosoftの公式ドキュメントやコードサンプルを検索・取得するためのリモートMCPサーバーとして提供されています。Microsoft関連技術の古い情報を補正する用途では、検討しやすい選択肢です。(Microsoft Learn)
カスタム指示を組織・リポジトリ・パス単位で分ける
カスタム指示は、AIエージェントにプロジェクトの前提や開発ルールを伝えるための基本的な手段です。ただし、すべてを1つのファイルに書くと、長くなりすぎて効果が落ちます。
おすすめは、次のように責務を分けることです。
| 単位 | 書く内容 | 例 |
|---|---|---|
| 組織レベル | 全社共通のセキュリティ、命名、レビュー方針 | 機密情報をコードに埋め込まない、承認済みライブラリを使う |
| リポジトリレベル | プロジェクト固有の構成、ビルド、テスト方法 | npm test、dotnet test、特定ディレクトリの責務 |
| パス単位 | フロントエンド、API、IaCなど領域別の規約 | Reactコンポーネント規約、Bicep/Terraformの命名ルール |
| タスク単位 | 繰り返し作業の手順 | リファクタリング、テスト追加、PRレビュー観点 |
VS Codeでは、.github/copilot-instructions.mdを使った基本的なカスタム指示に加え、プロンプトファイル、カスタムエージェント、スキル、MCPサーバーなどを段階的に追加する考え方が示されています。最初から複雑な構成にせず、基本ルールから増やすのが安全です。(Visual Studio Code)
ツール承認と自動実行の範囲を管理する
AIエージェントがツールを使えるようになると、ファイル編集、コマンド実行、外部サービス操作が自動化されます。便利ですが、管理者は「どの操作を自動承認してよいか」を慎重に決める必要があります。
特に注意すべき操作は次の通りです。
- ファイルの一括変更
- シェルコマンド実行
- パッケージのインストール
- データベース操作
- クラウドリソース作成・削除
- GitHub Issue、PR、リポジトリ設定の変更
- 社内APIや顧客データへのアクセス
VS Codeの企業向けAI設定では、ツール承認や自動承認に関する管理項目が用意されています。組織では、開発者の利便性だけでなく、セキュリティと監査可能性を基準に設定する必要があります。(Visual Studio Code)
開発者が確認すべき移行・設定ポイント
開発者は、AIエージェントの出力を改善するために、まず自分の開発環境とリポジトリに「正しい情報が渡っているか」を確認しましょう。特に、既存プロジェクトへAIエージェントを導入する場合は、移行作業というより開発文脈の棚卸しが重要になります。
まずは最小構成でベースラインを取る
Agent extensionsを追加する前に、同じタスクを拡張なしで実行し、結果を記録します。これがベースラインです。
たとえば、次のようなタスクを用意します。
| タスク | 評価観点 |
|---|---|
| 新しいAPIエンドポイントを追加する | 既存のルーティング、認証、テスト規約に従うか |
| Azure SDKを使う処理を追加する | 最新のSDK・認証方式を使うか |
| バグ修正を依頼する | 原因調査、修正、テスト追加まで行うか |
| READMEを更新する | 実際のコマンドや構成と矛盾しないか |
| 単体テストを追加する | 既存のテストフレームワークに合わせるか |
その後、カスタム指示やMCPサーバーを追加し、同じタスクを再実行します。Microsoftの記事でも、同じシナリオを拡張あり・なしで比較することが、liftとdragを見分ける方法として説明されています。(Microsoft for Developers)
カスタム指示には「禁止事項」と「検証方法」まで書く
カスタム指示には、単に「きれいなコードを書いてください」と書いても効果は限定的です。実務で役立つ指示は、判断基準が具体的です。
悪い例です。
品質の高いコードを書いてください。
セキュリティに注意してください。
既存のスタイルに合わせてください。改善例です。
## 実装ルール
- 認証には社内共通のAuthClientを使用し、独自のJWT検証処理を追加しない
- 新規APIには必ず正常系と認可エラーのテストを追加する
- 外部APIキーをコード、テスト、READMEに直接書かない
## 検証コマンド
- 変更後に `npm run lint` と `npm test` を実行する
- API層を変更した場合は `npm run test:api` も実行するポイントは、AIエージェントが「何をすれば合格か」を判断できる形にすることです。禁止事項、推奨ライブラリ、テストコマンド、レビュー観点を短く書くと、生成結果の確認もしやすくなります。
MCPサーバーは「何でも接続」ではなく用途別に選ぶ
MCPサーバーを増やしすぎると、コンテキストウィンドウの競合が起きます。Microsoftの記事では、複数の拡張が同じコンテキストを奪い合い、単体では有効だった拡張が他の拡張と組み合わさることで効果を落とす可能性が指摘されています。(Microsoft for Developers)
開発者は、MCPサーバーを次の基準で選ぶと失敗しにくくなります。
| 目的 | MCP導入の判断 |
|---|---|
| 公式ドキュメントを参照したい | 有効。Microsoft Learn MCP Serverなどを検討する |
| リポジトリ情報やIssueを参照したい | 有効。ただし権限範囲を限定する |
| 社内API仕様を参照したい | 有効。返す情報を短く構造化する |
| たまにしか使わないツールを追加したい | 慎重に判断。手動プロンプトで足りる場合がある |
| 便利そうなMCPを全部入れたい | 非推奨。選択失敗や品質低下の原因になる |
MCPは「多機能化」ではなく「必要な文脈を必要なときに渡す」ための仕組みとして扱うべきです。
Agent extensionsを設計するときの実務チェックリスト
Agent extensionsを導入する際は、Microsoftが示した4つの評価軸で確認すると整理しやすくなります。すなわち、Discovery、Selection、Quality、Compositionです。(Microsoft for Developers)
| 評価軸 | 確認質問 | 改善アクション |
|---|---|---|
| Discovery | エージェントは拡張を認識しているか | 設定ファイルの場所、ポリシー、ツール表示を確認する |
| Selection | 適切なタスクで選ばれているか | ツール名と説明文を開発者の自然な言葉に合わせる |
| Quality | 使われた結果、成果物は良くなったか | 返却情報を短くし、最新の推奨例と検証手順を含める |
| Composition | 他の拡張と併用しても効果が落ちないか | よく使う拡張との組み合わせでテストする |
特に見落としやすいのはCompositionです。社内では、GitHub、Azure、Playwright、データベース、チケット管理、社内ドキュメントなど、複数のMCPサーバーを同時に使うケースが増えます。単体テストだけで「このMCPは有効」と判断すると、本番利用時に期待した効果が出ない可能性があります。
liftとdragで効果を測る
Microsoftの記事では、Agent extensionsが成果を良くする状態を「lift」、同じか悪くする状態を「drag」として説明しています。導入した拡張が本当に役立っているかは、感覚ではなく比較で判断する必要があります。(Microsoft for Developers)
実務では、次のような簡易評価表を作ると運用しやすくなります。
| 評価項目 | 拡張なし | 拡張あり | 判定 |
|---|---|---|---|
| ビルド成功 | 失敗 | 成功 | lift |
| テスト追加 | なし | あり | lift |
| 非推奨APIの使用 | あり | なし | lift |
| 生成コード量 | 適切 | 過剰 | dragの可能性 |
| 実行時間・トークン消費 | 小 | 大幅増 | 高コストliftまたはdrag |
| セキュリティ違反 | なし | あり | drag |
重要なのは、単に「MCPが呼ばれたか」ではなく「成果物が改善したか」を見ることです。呼び出し回数が増えても、コード品質や検証結果が改善しないなら、それは効果ではなくノイズかもしれません。
展開時に失敗しやすいポイント
AI coding agentsの展開で失敗しやすいのは、技術そのものよりも運用設計です。特に次のパターンは避けるべきです。
いきなり全社展開する
カスタム指示やMCPサーバーは、プロジェクトごとに効果が異なります。全社共通設定だけで解決しようとすると、あるチームには有効でも、別のチームでは余計な制約になることがあります。
最初は代表的な2〜3リポジトリで検証し、ベースライン比較を行ってから展開範囲を広げるのが安全です。
古いドキュメントをそのままAIに渡す
社内WikiやREADMEに古い手順が残っていると、AIエージェントはそれを正しい情報として扱う可能性があります。特に、認証、SDK、デプロイ、IaC、セキュリティ設定は古い情報の影響が大きくなります。
AI向けに整備するドキュメントでは、次のような表記が有効です。
## 非推奨
- v1 SDKの `OldClient` は新規実装で使用しない
- 接続文字列をコードに直接書かない
## 推奨
- v2 SDKの `NewClient` を使用する
- 認証にはManaged Identityを使用する
- 変更後は `dotnet test` を実行する「何が古いか」と「何を使うべきか」を同じ場所に短く書くことで、AIエージェントが判断しやすくなります。
ツール説明を製品名中心にしてしまう
MCPツールやスキルの説明文が製品名・内部用語中心だと、Selection failureが起きやすくなります。説明文には、開発者がプロンプトで使う言葉を入れるべきです。
たとえば、社内の「Resource Orchestrator」というツールがある場合、説明文にそれだけを書いても選ばれにくい可能性があります。次のように、用途の言葉を入れます。
Azure環境の作成、検証環境の払い出し、リソース初期設定、開発用インフラ構築に使うツール。AIエージェント向けの説明文は、ブランドコピーではなく、検索クエリに近い実用的な説明にするのが効果的です。
成功例だけで評価する
一度成功したプロンプトだけを見て「使える」と判断するのは危険です。AIエージェントは、入力、ワークスペース、併用ツール、ハーネスによって結果が変わります。
評価では、最低限次のパターンを試しましょう。
- 新規実装
- 既存コード修正
- テスト追加
- ドキュメント更新
- エラー修正
- セキュリティに関わる変更
- 他のMCPサーバーと併用した状態
1つの成功例ではなく、複数シナリオで平均的にliftが出ているかを確認することが重要です。
既存環境から見直すための実践手順
すでにGitHub CopilotやMCPサーバーを使っている場合は、次の順で見直すと効率的です。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | よく使うAI開発タスクを5〜10個選ぶ | 評価シナリオ |
| 2 | 拡張なし、または現状設定で実行する | ベースライン |
| 3 | カスタム指示を短く整理する | copilot-instructions.mdなど |
| 4 | 必要なMCPサーバーだけを有効にする | 最小構成のMCP設定 |
| 5 | 同じシナリオを再実行する | 比較結果 |
| 6 | liftとdragを分類する | 改善リスト |
| 7 | 効果がある設定だけをチームに展開する | 標準設定・運用ルール |
最初から完璧なAX設計を目指す必要はありません。むしろ、効果が測れない大きな設定を作るより、小さく変更して比較できる状態を保つことが重要です。
Microsoft関連技術で特に確認したいポイント
Microsoft関連の開発では、Azure、Microsoft 365、GitHub、Visual Studio、VS Code、Power Platformなど、サービスやツールが多岐にわたります。そのため、AIエージェントが「似ているが違うサービス」を選んでしまうリスクがあります。
特に確認したいのは次の項目です。
| 領域 | 確認ポイント |
|---|---|
| Azure SDK | 使用言語ごとの推奨SDK、認証方式、非推奨API |
| Microsoft Graph | 権限スコープ、委任/アプリケーション権限、ページング処理 |
| GitHub Copilot | 組織ポリシー、カスタム指示、MCP許可範囲 |
| Visual Studio / VS Code | エージェントモード、MCP設定、ツール承認 |
| Dev Containers | コンテナ内でMCP設定が期待通り読み込まれるか |
| CI/CD | AIが生成した変更をビルド・テスト・静的解析で止められるか |
| セキュリティ | 秘密情報、接続文字列、個人情報をプロンプトやログに含めない設計 |
Microsoft Learn MCP Serverのように、公式ドキュメントへ接続できる仕組みを使う場合でも、最終的な判断はビルド、テスト、レビュー、セキュリティチェックで確認する必要があります。AIエージェントへの入力を改善しても、検証プロセスを省略してよいわけではありません。
まとめ：AX stackでは「変えられる層」に集中する
「The AX stack: what’s fixed, where you can win」でMicrosoftが伝えている核心は、AI coding agentsの改善をモデル任せにしないことです。モデルとハーネスには制御しにくい部分があります。一方で、MCPサーバー、カスタム指示、スキル、カスタムエージェントといったAgent extensionsは、組織や開発チームが設計・改善できます。
管理者は、MCPの許可範囲、ツール承認、組織ポリシー、データ取り扱いを確認しましょう。開発者は、カスタム指示を短く具体的にし、拡張を増やす前にベースラインを取ることが重要です。SDKやAPIを提供するチームは、最新の推奨実装、非推奨パターン、検証方法をAIにも伝わる形で整備する必要があります。
次に取るべき行動は、現在のAI開発環境で「拡張なし」と「拡張あり」の結果を比較することです。生成コードが良くなっていればlift、変わらないか悪化していればdragです。この比較を繰り返すことで、AIエージェントを単なる補助ツールではなく、実務で信頼できる開発基盤に近づけられます。
コメント