マスティカルツ氏によると、多くの企業では「どのLLM（大規模言語モデル）を使うか」に注目が集まりがちだ。だが実際には、エージェントの精度は、モデル単体では決まらないと同氏は強調する。

　開発者がプロンプトを入力してからコードが生成されるまでのスタックには、3つのレイヤーが存在するとマスティカルツ氏は説明する。

• モデル（LLM）
• ハーネス（Copilot、Cursor、Claude Codeなど）
• エージェント拡張（MCP、Skill、Instructionなど）

モデル（The Model）

　LLMは、過去の学習データを基にコード生成を実施する。古いSDKや過去の設計パターンを学習している場合、既に非推奨となった実装を提案する可能性がある。学習データに十分な情報が存在しない場合は、ハルシネーションが発生することもある。

ハーネス（The Harness）

　ハーネスは「どの情報をエージェントへ渡すか」を制御する。例えば、同じLLMでも、GitHub CopilotとCursorではツール呼び出しやコンテキスト管理の方式が異なるため、生成結果が変わる場合がある。MCPサーバやSkillの説明文が同じでも、ハーネス側の実装によって、AIの解釈やツール選択結果が変化する可能性があるという。

エージェント拡張（Agent Extensions）

　人間が唯一コントロールでき、即座に最適化できる層だ。つまり人間側が実際に改善可能なのは、この層だ。

　例えば、以下の情報をMCPやagent.mdとしてAIへ渡すことで、LLMの誤学習を補正できる可能性があるとマスティカルツ氏は指摘する。

• SDKの最新の利用方法
• 社内のコーディング規約
• セキュリティポリシー
• APIの利用ルール
• 推奨アーキテクチャ

拡張機能が陥る「3つの失敗モード」

　一方マスティカルツ氏は、エージェントが一度に処理できるトークン量（コンテキストウィンドウ）には限界があると指摘する。つまり、エージェントが一度に読める情報量には上限がある。

　そのため、MCPやSkillといった拡張機能を大量に追加すると、「限られたコンテキストウィンドウの席を奪い合う『ゼロサムゲーム』が発生する」とマスティカルツ氏は指摘する。

　同氏がセッションを数百回にわたって分析した結果、エージェント拡張が失敗するパターンは以下の3つに集約されることが分かった。

発見の失敗（Discovery failure）：「MCPを増やすほど賢くなる」は誤解

　企業の中には、「とにかく社内の情報をAIへ渡せば精度が上がる」と考え、MCPやRAG（検索拡張生成）の導入を急ぐところがある。

　しかし、複数のMCPが「データベース操作用ツール」という趣旨で存在している場合、エージェントはどちらを使うべきか判断できなくなる可能性がある。あるいは、膨大な社内ナレッジを読み込ませた結果、本来必要だった設計ルールやSDK情報がコンテキストから押し出されるケースも考えられる。

　実際には、「拡張機能を増やすほど賢くなる」とは限らず、むしろ競合やノイズによって全体精度が低下する可能性があるという。

　これは、企業でSaaSやセキュリティ製品を乱立導入した結果、運用が複雑化する問題に近い。AI時代には、「AIへ何を見せるか」だけでなく、「何を見せないか」まで含めた情報整理が必要になる可能性がある。

選択の失敗（Selection failure）：AIが「社内ツール」を認識しない

　これは、AIのコンテキスト内にはツールが存在していても、エージェントがその存在を認識できない状態だ。例えば、開発者が「認証を設定して」と指示しているにもかかわらず、ツール側の説明文が「Identity Provider Configuration」のような専門用語中心で書かれている場合、エージェントが適切なツールとして認識できない可能性がある。

　マスティカルツ氏はこの問題を「最も修正しやすい失敗」と説明する。つまり、エージェント向けの説明文やツール名を、人間だけでなく“エージェントが理解しやすい語彙”へ最適化する必要があるということだ。

品質の失敗（Quality failure）：「AIが使った」のに質が下がる

　最も厄介なのが、品質の失敗だ。これは、「エージェントがMCPを発見した」→「正しく呼び出した」→「拡張機能が返した中身が長過ぎてノイズになり、むしろ出力コードの品質が悪化した」という状態を指す。ツールが動いている（呼び出されている）からといって、成果が良くなっているとは限らないというわなだ。

　つまり、「社内情報をAIへ接続する」だけでは不十分であり、以下に留意することが大切だということをマスティカルツ氏は説明している。

• エージェントが理解しやすい形式になっているか
• 情報は最新か
• 不要な情報が混在していないか
• 他のMCPと競合していないか

　これは、従来の「ナレッジ管理」とは異なる課題だ。人間向けには理解しやすい長文資料でも、AIにとっては“ノイズ”になる可能性がある。

AXにおいて最適化すべき「4つの指標」

　マスティカルツ氏は、AXをブラッシュアップしていく上で、以下の4つの問いに沿って拡張機能を最適化していく必要があると指摘する。

発見（Discovery）

　そのエージェントは、他のツールと混在した環境でも自社の拡張機能を見つけられているか？

選択（Selection）

　開発者の曖昧な意図に対して、そのエージェントは適切な拡張機能を選択できているか？

品質（Quality）

　適切な拡張機能が使われた結果、生成されたコードの品質は本当に向上しているか？

合成（Composition）

　拡張機能が単体で動くだけでなく、他の一般的な拡張機能と共存したときにも問題なく機能するか？

LiftとDragを測定する

　AXにおいて重要なのは、拡張機能が成果を向上させる「Lift」（浮力）になっているのか、それとも精度低下やコスト増加を招く「Drag」（空気抵抗）になっているのかを測定することだとマスティカルツ氏は強調する。

　例えば、MCPを追加したことでコードの品質は「多少改善した」ものの、消費トークン量やAPIコストは3倍に増加した場合、それは「高コストなリフト」であり、本当に費用対効果があるのかを検証しなければならない。

　LiftとDragを正しく評価するためには、LLMやハーネス、開発者のプロンプトといった固定条件を一定に保ったまま、

• MCPがない状態
• MCPがある状態

を比較し、コードの品質やトークンの消費量などをA／Bテスト的に評価する必要があるとマスティカルツ氏は説明する。