AIエージェントを本番運用するための基盤設計｜観測・コスト・権限の3点セット【2026年8月版】

執筆: 武石幸之助（x3d株式会社 代表取締役）
公開日: 2026年7月28日
最終更新日: 2026年8月5日

【結論】AIエージェントの本番運用基盤とは、エージェントの挙動・費用・権限を継続的に把握し制御する仕組みです。

• PoCと本番を分けるのは精度ではなく観測・コスト・権限の3点セットが整っているか
• 観測の標準はOpenTelemetryのGenAI規約。2026年8月時点でもステータスは Development（安定版ではない）ため、属性名に依存しない設計にする
• コストは事後の請求書で管理できない。ツール定義の量・取得データ量・再試行回数を設計時点で抑える

この記事では、AIエージェントをPoCから本番へ移そうとしている開発者・PM向けに、運用基盤として整えるべき要素と判断基準を解説します。

---

※本記事は本番運用の「観測・コスト・権限」に焦点を当てています。MCPの基礎はMCPサーバーとは？（x3d 公式ガイド）、接続先選定はMCP連携のユースケースと選定基準、自作設計はMCPサーバー自作ガイドを参照してください。

AIエージェントの本番運用基盤とは — PoCから本番への壁

AIエージェントの本番運用基盤とは、エージェントの挙動・費用・権限を継続的に把握し制御する仕組みです。PoCで「動いた」エージェントが本番で止まる原因は、多くの場合モデルの精度ではありません。

x3dの支援現場で繰り返し見られるのは、次のパターンです。PoCでは開発者が目の前で結果を確認するため、失敗しても即座に気づけます。ところが本番では利用者が分散し、誰も全体を見ていない状態になります。その結果、「おかしな挙動に気づけない」「費用が読めない」「誰の権限で動いているか説明できない」の3つが同時に発生します。

この3つに対応するのが、観測・コスト・権限の3点セットです。

加えて、この3つを継続的に守るための品質ゲート（評価の自動化）が必要になります。以下、順に整理します。

観測：エージェントの何をトレースするか

AIエージェントの観測が難しいのは、1回の処理が「モデル呼び出し」と「ツール呼び出し」の連鎖になるためです。単発のAPIログでは、なぜその結論に至ったかを再構成できません。

この領域の標準化を進めているのがOpenTelemetryのGenAI関連の意味規約（semantic conventions）です。2026年8月時点での実態を正確に押さえておく必要があります。

• GenAI関連の規約はDevelopment ステータスで、安定版（Stable）ではありません。属性名は今後変わる可能性があります
• 2026年6月12日リリースの semantic-conventions v1.42.0 で、GenAI とMCPの規約が本体リポジトリから専用リポジトリ（open-telemetry/semantic-conventions-genai）へ分離されました
• 既存の計装は既定では従来の属性形式を出力し続けます。最新の実験的形式に切り替えるには環境変数 OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental を設定します

実務上の結論は、「スパンの構造」に依存し、「属性名」に依存しない設計にすることです。トレースの木構造は比較的安定しており、上位に invoke_agent、その下にモデル呼び出しごとの chat、ツール呼び出しごとの execute_tool が並ぶ形が標準です。この構造はフレームワークが変わっても共通するため、ダッシュボードやアラートは構造とトークン数・所要時間を軸に組み、属性名を直接ハードコードしないようにします。

最後の行は特に注意が必要です。OpenTelemetryのGenAI規約では、プロンプト本文やツール引数は既定では記録しません。機微情報を含む可能性があるためで、記録するには明示的な設定が必要です。デバッグ目的で内容取得を有効にする場合は、保存期間・アクセス権限・マスキングを先に決めます。

MCPサーバーを経由する構成では、トレースの連結が課題になります。現行仕様 2026-07-28 では、W3C Trace Context（traceparent / tracestate / baggage）を _meta で伝搬する方式が仕様に明記されています（出典: The 2026-07-28 Specification）。これにより、ホストアプリケーションで始まったトレースがクライアントSDK、MCPサーバー、その先の下流システムまで1本の木としてつながります。同リビジョンでは MCP の Logging 機能が非推奨化され、構造化された可観測性の手段としてOpenTelemetryが位置づけられています。これから作る構成では、MCPサーバー側にもOpenTelemetryの計装を入れるのが前提になります。

コスト管理：トークン消費を設計で抑える

AIエージェントの費用は、事後の請求書では管理できません。エージェントは1つの依頼に対して複数回モデルを呼ぶため、利用量が利用者の使い方に比例して増えます。

コストを押し上げる要因は、実装上の判断に集約されます。

4つのうち最も効果が大きいのは「取得データ量」です。ツールが返す結果は、そのまま次のモデル呼び出しの入力になります。「とりあえず全件返す」実装は、精度を下げながら費用を増やします。件数上限と必要な列だけを返す設計を、ツール定義の段階で決めます。

運用面では、モデル呼び出しごとの入力／出力トークン数をトレースで取得し、機能別・利用者別に按分できる状態を作ります。「どの機能が費用の大半を占めているか」が分かれば、改善の優先順位を判断できます。逆にこれがないと、費用が増えたときに全体の利用を止める以外の手が打てません。

なお、現行仕様 2026-07-28 では tools/list などの一覧結果に有効期限（ttlMs）とキャッシュ範囲（cacheScope）が付与され、クライアント側でツール一覧をキャッシュできます。ツール定義の再送を減らせるため、コスト面でも意味があります。

権限とアイデンティティ：エージェントは「誰」として動くか

本番運用で必ず問われるのが「そのエージェントは誰の権限で動いているのか」です。ここが曖昧なままだと、監査に答えられません。

設計の選択肢は2つに整理できます。

最も避けるべきは、広い権限を持つ単一のサービスアカウントで全機能を動かす構成です。利用者全員が同じ権限を持つことになり、参照権限のない情報がAI経由で見えてしまいます。導入時は問題にならなくても、扱うデータが増えた段階で必ず問題になります。

権限設計に加えて、次の3点を運用ルールとして決めます。

• 監査ログの粒度：いつ・誰が・どのツールを・どの引数で呼び、何が返ったかまで残す。「呼ばれた」だけでは再現できません
• 不可逆な操作のガード：削除・送金・外部送信は人の承認を挟むかを決める。設計はHuman in the Loop（HITL）が出発点になります
• 権限の定期棚卸し：人事異動・退職時にエージェント側の権限も見直す対象に含める

組織としてのルール整備では、総務省・経済産業省の「AI事業者ガイドライン」が参照点になります。2026年3月31日に第1.2版が公表され、AIエージェントに関する定義とリスクの記述が追記されました。法的拘束力のないソフトローですが、国内で事実上の標準として機能しています。社内規程への落とし込みでは、無料で使えるx3d-AI規程アドバイザーで現状のギャップを診断してから着手すると、論点を絞れます。攻撃面の対策はAIエージェント導入企業が備えるべきセキュリティとプロンプトインジェクションで扱っています。

品質ゲート：評価を自動化してリリース判断に組み込む

観測・コスト・権限を整えても、変更のたびに品質が落ちないことを確認する仕組みがなければ運用は続きません。AIエージェントはプロンプト・モデル・ツール定義のどれを変えても挙動が変わるため、変更の影響を人手で毎回確認するのは現実的ではありません。

品質ゲートとして最低限そろえるのは3つです。

• 代表ケースの回帰テスト：実際の依頼から代表例を20〜50件集め、変更前後で結果を比較する。完全一致ではなく「意図したツールが呼ばれたか」「必要な情報が含まれるか」で判定します
• 失敗パターンの固定化：本番で起きた失敗をテストケースに追加し、再発を検知できる状態にします
• リリース判断の基準：ツール選択の成功率・所要時間・トークン消費のうち、どこまでの悪化を許容するかを事前に決めます

ここで重要なのは、評価指標を「正解率」に一本化しないことです。AIエージェントの本番運用では、正しく答えられるかと同じくらい「安全に止まるか」が重要です。判断できないときに勝手に進めず、人にエスカレーションできるかを評価対象に含めます。

本番運用チェックリスト

PoCから本番へ移す前に確認する項目を、3点セット＋品質ゲートの観点で整理しました。

接続先となるMCPサーバー側の設計は社内システムをAIエージェントにつなぐMCPサーバー自作ガイド、既製と自作の使い分けはMCP連携で何ができるのかで解説しています。エージェント本体の設計はAIエージェントの作り方、複数エージェント構成はマルチエージェント、検索基盤の運用はRAG構築を参照してください。

運用基盤の設計は、技術だけでも組織だけでも完結しません。x3dでは4層理論を用いて技術・業務・組織・経営の各層を切り分けて設計し、AI時代のエンジニア・PM育成研修のRAGOps／運用保守マスターおよびAIエージェント開発マスターで、本番運用に必要な観測・コスト・権限の設計スキルを扱っています。

よくある質問（FAQ）

---

参考文献・出典

• OpenTelemetry — Semantic Conventions for Generative AI
• OpenTelemetry Blog — GenAI Observability（スパン構造・内容取得の既定挙動）
• open-telemetry/semantic-conventions — Releases（v1.42.0：2026年6月12日）
• open-telemetry/semantic-conventions-genai（GenAI／MCP 規約の分離先リポジトリ）
• The 2026-07-28 Specification（W3C Trace Context 伝搬・Logging の非推奨化）
• 総務省「AI事業者ガイドライン」掲載ページ（第1.2版・令和8年3月31日公表）

本記事は2026年8月時点の公開情報に基づいています。OpenTelemetryのGenAI規約およびMCP仕様はいずれも更新が続いているため、最新情報は各公式サイトをご確認ください。

---

武石幸之助
x3d株式会社 代表取締役。2017年より企業のAI導入支援に従事し、これまで1,800社超の法人支援、5,000名超の研修登壇実績を持つ（受講満足度99%／2024年度研修アンケート）。AIエージェントのPoC設計から本番運用の定着までを一貫して支援し、技術実装と組織設計の両面から企業のAI活用を伴走している。

---

x3d株式会社では、本記事で解説したAIエージェントの本番運用基盤に関する企業研修・導入支援を提供しています。
まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら