「デモは動くが本番に乗らない」——AIエージェントの本番化は、いま欧米で最も熱い運用テーマです。MCPの標準化、評価、権限、コスト、観測という5つの壁を、一次情報を追いながら日本のエンタープライズ目線で整理します。
01「デモは動く、本番に乗らない」の正体
2025年から2026年にかけて、シリコンバレーの技術者コミュニティの関心は「AIエージェントをどう作るか」から「どう本番で運用し続けるか」へ、はっきりと移りました。プロトタイプは驚くほど簡単に動きます。ところが、それを社内の基幹システムにつなぎ、監査に耐え、コストが読め、壊れたときに原因を追えるかたちにしようとした瞬間、多くのチームが足を止めます。
背景には数字もあります。ある調査では、すでに57%の組織が何らかのAIエージェントを本番に投入している一方で、観測性(オブザーバビリティ)はAIスタックの中で最も評価の低い領域と報告されています。品質を本番化の最大の障壁に挙げる声も根強く、AIによる判断の多くはいまだ人間の確認を必要としています。「作れる」と「運用できる」の間には、依然として深い谷があるということです。
本稿では、欧米で交わされている本番化の議論を、標準化(MCP)・評価・権限・コスト・観測という5つの壁に整理し、それぞれについて一次情報を追いながら、日本のエンタープライズが取れる現実的な打ち手を考えます。誇張抜きで、いま押さえておくべき論点だけをまとめます。
02MCPという「つなぎ方」の標準化が進んだ
エージェントが価値を出すのは、社内API・データベース・SaaSといった「外の世界」に手を伸ばせるからです。その接続方法を標準化しようとしているのがModel Context Protocol(MCP)です。当初は同期的なツール呼び出しを標準化する軽量プロトコルでしたが、2025年11月の仕様改訂で、エンタープライズの本番運用を強く意識した内容へと踏み込みました。
公式ブログが挙げる主な変更点は、実務者から見て示唆的です。
- 認可の実務化：MCPサーバーをOAuthのリソースサーバーとして正式に位置づけ。URLベースのクライアント登録(Client ID Metadata Documents)により、無数のクライアントを事前登録なしに扱える設計へ。動的クライアント登録(DCR)の運用負荷という積年の痛点に手を入れています。
- 非同期実行(Task)：SEP-1686で、working / input_required / completed / failed / cancelled といった状態を持つ長時間タスクの抽象化を導入。数秒で終わらない業務処理を、状態をポーリングしながら扱えるようになりました。
- エンタープライズ統制：企業が自前のMCPレジストリを持ち、ガバナンスを自己管理するという方向性。IdP連携(Cross App Access)で一度のサインインで許可済みサーバーへアクセスできる設計。APIキーやパスワードがMCPクライアントを経由しない「URLモードのエリシテーション」も明記されました。
ポイントは、MCPが「便利な接続規格」から「統制された接続規格」へと性格を変えつつあることです。仕様書自体も、ツールの説明(アノテーション)は信頼できるサーバー由来でない限り信用してはならない、ツール実行前にユーザーの明示的な同意を得るべきだ、と繰り返し釘を刺しています。エージェントに与える「手」の一本一本を、認証・認可・同意で締めるという発想です。
03評価(Eval)という一番地味で一番効く壁
欧米の議論で「本番化の最難関」として繰り返し挙がるのが評価です。従来のソフトウェアは、入力に対して出力が決まっていました。エージェントは非決定的で、同じ指示でも通るパスが毎回変わります。そのため「正しく動いているか」を、システムメトリクス(レイテンシやエラー率)だけでは測れません。
本番で本当に見たいのは、タスクの完了率、事実性(ハルシネーションの有無)、ツール選択の妥当性、そして業務目的との整合です。これらを継続的に測る評価データセットと採点ロジックを、機能実装と同じ重みで設計する必要があります。ここを飛ばすと、「なんとなく動いているが、なぜ良いのか悪いのか説明できない」システムが本番に居座ることになります。
ベンダーもこの領域を製品化し始めました。AWSはre:Invent 2025で、正確性・安全性・ツール選択精度などを監視する13種の組み込み評価を持つAgentCore Evaluationsを発表しています。ただし、こうした汎用評価は出発点にすぎません。自社の業務でエージェントが「合格」と言える条件は、自社にしか定義できないからです。
04権限と境界 — 「善意のエージェント」を前提にしない
エージェントは、人間より速く、休まず、大量にツールを呼びます。そこに過剰な権限を与えると、事故もインシデントもスケールします。欧米の設計論が一致しているのは、「エージェントは信頼できるものとして扱わず、権限と境界で囲う」という点です。
AWS AgentCoreはこの発想を製品構成に落とし込んでいます。公式ブログによれば、AgentCore IdentityがAWSサービスや外部ツールへの安全なアクセスを担い、AgentCore Runtimeがセッション単位で隔離されたサーバーレス実行環境を提供します。生成コードは隔離されたCode Interpreterで走らせ、Web操作はマネージドなBrowserに閉じ込める。さらにre:Invent 2025では、自然言語で書いた統制ルールに違反する行動を自動的に止める「Policy」機能も追加されました。
これは、クラウドのマルチアカウント統制やIAM最小権限の考え方と地続きです。エージェントを「新しい種類のワークロード」と捉えれば、既存のガバナンス設計の延長線上で守れます。特にセッション隔離・最小権限・行動の事前チェックという三点は、エンタープライズなら馴染みのある発想でしょう。
05コスト — トークンは「見えない従量課金」
エージェントは、一度の依頼で内部的に何度もLLMを呼びます。推論のたびにトークンを消費し、ツール呼び出しやリトライが重なると、費用は静かに膨らみます。従来のインフラコストと違い、トークン消費は「利用パターン次第で桁が変わる従量課金」であり、設計を誤ると本番投入後に請求書で気づくことになります。
ここはクラウドのFinOpsとまったく同じ規律で臨めます。まず可視化、次に単位あたりコストの把握、そして最適化です。具体的には、リクエストあたりの平均トークン数・ツール呼び出し回数・リトライ率を継続的に測り、「どのユースケースが割に合っているか」を金額で語れる状態にします。モデルの使い分け(重い判断だけ上位モデル、定型処理は軽量モデル)やキャッシュの活用は、その可視化があって初めて意味を持ちます。
06観測(オブザーバビリティ) — 標準化はOpenTelemetryへ
エージェントが誤った行動を取ったとき、「なぜそうしたのか」を後から追えなければ、改善も説明責任も果たせません。ところがエージェントの挙動は、複数のLLM呼び出し・ツール実行・検索・分岐が絡み合う非決定的なチェーンです。従来のAPM(アプリ性能監視)の発想では捉えきれません。
この領域でいま標準化の中心にあるのが、OpenTelemetryのGenAIセマンティック規約です。トップレベルのinvoke_agentスパンの下に、LLM呼び出しごとのchatスパン、ツール実行ごとのexecute_toolスパンがぶら下がる木構造を標準化し、gen_ai.usage.input_tokens/output_tokensといった属性でトークン消費まで一貫して追えるようにしています。フレームワーク横断・ベンダー横断で「同じ語彙」でエージェントを観測できることが狙いです。
注意点として、これらの規約の多くは2026年時点でまだ実験的(experimental)ステータスです。とはいえDatadogをはじめ主要ベンダーが対応を進め、LangChainやCrewAIなどのフレームワークがOTel準拠のスパンを出し始めています。AWS AgentCoreも、エージェント実行をステップ単位で可視化するObservabilityを構成要素に含みます。方向性は明確で、「OTel準拠で計装しておけば、監視基盤を後から選び直せる」状態が現実的な選択肢になりつつあります。
07日本のエンタープライズの現実解
ここまでの5つの壁を踏まえ、日本の情シス・SIer・エンタープライズが取るべき現実解を整理します。派手な全社展開を急ぐより、統制を効かせた小さな本番を確実に積むことが、結局は最短距離です。
- ユースケースを1つに絞って本番化する：横断的な「万能エージェント」ではなく、問い合わせ一次対応や社内文書検索など、成否を金額と件数で語れる業務から。評価データセットもコスト試算も、範囲が狭いほど正確に組めます。
- 接続と権限を先に台帳化する：MCPを使うにせよ独自実装にせよ、「どのツールを・誰の権限で・どのスコープで」を接続前に決める。IdP連携と監査ログの出口を最初に設計しておく。
- 評価・観測を機能と同時に実装する：ゴールデンセットによる回帰テストと、OTel準拠のトレースを初日から入れる。後付けは必ず高くつきます。
- 規制と説明責任を織り込む：EU AI Actのように、海外では規制が先行しています。監査に耐えるログと人間の承認ポイントを設計に含めておけば、国内の統制要件にも自然に対応できます。
欧米で先に起きているのは、「エージェントを作る競争」から「エージェントを統制して運用する競争」への移行です。そしてその統制の作法は、クラウドのマルチアカウント統制・最小権限・FinOps・オブザーバビリティといった、日本のエンタープライズがこの10年で積み上げてきた規律の延長線上にあります。新しい魔法ではなく、慣れた規律の応用として臨むのが、最も堅実な本番化の道です。
—まとめ
AIエージェントの本番化は、モデルの賢さより「運用の設計」で決まります。MCPによる接続の標準化、評価による品質の担保、権限と境界による安全性、コストの可視化、そしてOpenTelemetryに収斂しつつある観測。この5つを、既存のクラウドガバナンスの延長として設計できれば、PoC止まりの谷は越えられます。欧米の先行事例は、奇抜な発想ではなく地道な規律が効くことを示しています。EMWは、この橋渡しと実装を現場で手を動かして支援します。