本番環境でエージェントAIを運用するための5つの教訓 — ファイヤーサイドチャットより

現在、ほとんどの企業は、エージェントが何をしているかを確認する手段がないまま、本番環境でエージェントを運用しています。このギャップこそが、コスト超過、追跡不能な障害、シャドーAIの発生源となっています。 私たちは、18の業界にわたる200社のエンタープライズAIリーダーから同じ話を聞きました。また、Viaのエンジニアリング担当副社長であるダニエル氏と、SurveyMonkeyでデータおよびエンタープライズAIを統括するミーナル氏とのライブセッションでも、同様の意見が聞かれました。

誰もその言葉を使わなかったとしても、ほとんどすべての回答に共通していたのは、AIゲートウェイが必要だという考えでした。後付けのオブザーバビリティツールではなく、モデルを管理する単一の制御レイヤーとして、 MCPサーバー、そしてエージェントが経由することで、コスト、ロギング、アクセスがすべてのコードベースではなく一箇所で処理されます。私たちが話を聞いたリーダーたちが、そこにたどり着くまでに学んだことは次のとおりです。

詳細なファイアサイドチャットはこちらでご覧ください - 

大規模運用においてエージェントAIガバナンスが重要な理由

私たちのレポートで最も明らかになった発見は、逆説的なものでした。リーダーたちに2026年と2027年の予算がどこに使われるかを尋ねたところ、AIユースケースの拡大が第一位でした。別途、彼らが最も大きなリスクとして認識し、それに対処するために資金を投入すべきだと考えたのは何かと尋ねたところ、その同じ拡大におけるセキュリティとガバナンスが同程度に高く評価されました。この2つの項目は、ほとんど重なり合っています。

その緊張関係こそが、このゲームのすべてです。拡大を急ぎすぎると、コストとリスクが手に負えなくなります。慎重になりすぎると、後れを取ってしまいます。私たちが話を聞いたすべてのリーダーは、両方を同時に推進しようとしており、それをうまく行っているリーダーは、ガバナンスを拡大を加速させるものと捉え、減速させるものとは考えていません。ミーナル氏が言うように、適切なリスクとセキュリティ体制に費やす1ドルはすべて、より速いペースで拡大に資金を投入するためのテコとなるのです。

教訓1：推論コストは全体のコストのごく一部に過ぎない

UberがAI予算を早期に使い果たしたという報道が話題になりましたが、それを推論価格の問題と捉えがちです。しかし、通常はそうではありません。コストがかさむのは、トークンあたりの料金ではなく、モデルに与えるコンテキストが原因なのです。

ミーナル氏は、これを組織が何かをスケールさせる前にやるべき宿題だと表現しました。コンテキストは3つの場所から生まれます。データベース内のデータ、チームが適用する意思決定ロジック、そして人々の頭の中にある組織的・部族的な知識です。これらをうまくまとめれば、エージェントは最小限のトークンで必要なものを得られます。これを怠ると、同じモデルが同じ問題に対して繰り返し推測するために費用を支払うことになります。

彼女はまた、私たちに印象的な例え話をしました。これは、オンプレミスからクラウドへの移行の話と似ています。企業はクラウドに移行しましたが、結局コストが膨れ上がり、その後にようやく管理方法を学びました。AIも同じ曲線を描いていますが、それが圧縮されています。AIの価格設定方法が確立され、基盤となるコンピューティングコストが高くなるにつれて、コストは上昇し続けるでしょう。そのため、今回はより早期に規律を確立する必要があります。

複数の企業と協力する中で、共同創設者のアヌラグは、コスト管理が3つの層に分かれていると見ています。そして、AIゲートウェイはこれら3つすべてが適用される場所です。

• 可視性。 Bedrock、OpenAI、Anthropicのモデルを許可する場合、ユーザー、チーム、アプリケーションごとに、どこに費用が使われているかを一元的に把握する必要があります。見えないものは管理できません。
• 制御。 可視性を確保したら、制限を設定します。ユーザー、チーム、またはアプリケーションレベルでの予算とレート制限を、各アプリケーションの価値のROIに合わせて設定するのです。
• ルーティング。 最も賢いレイヤー。大規模なフロンティアモデルに送られたリクエストでも、より小規模なモデルで同じ結果が得られることがよくあります。中央レイヤーはすべてのトラフィックを把握しているため、各リクエストを適切なモデルにルーティングでき、オブザーバビリティログから学習することで、ルーティングロジックは時間とともに改善されます。

そのレイヤーなしでエージェントを実行する場合と、そのレイヤーを介して実行する場合の違いは次のとおりです。

教訓2：追跡するように設計されていないものは追跡できません

当社が調査した企業の半数以上が、本番環境で稼働しているエージェントを完全に追跡できていませんでした。それらのエージェントの一部は承認されていました。一部はシャドーAIであり、IT部門や経営陣の知らないうちにデプロイされていました。

ダニエルは、その重要性を最も的確に表現していました。従業員に、何でもインストールでき、完全なネットワークアクセスがあり、監視のないノートパソコンを渡すことを想像してみてください。現代の企業でそのようなことをする会社はありません。エージェントにも同じガードレールが必要であり、それらは最初から必要です。なぜなら、非決定論的なシステムを後から追跡することはほぼ不可能だからです。エージェントは同じことを二度しないため、監査証跡が設計段階で組み込まれていなければ、後から探しても見つかりません。

Viaでは、それを当然のことと捉えています。エージェントを実行するための優れたインフラストラクチャは、同時に2つのことを実現します。デプロイメントをより安全にし、デプロイメントを容易にします。つまり、より多くのエージェントがデプロイされることになります。だからこそ、 エージェントのオブザーバビリティ は、後回しにするプロジェクトではなく、プラットフォームの一部である必要があります。彼らにとって効果的だった実用的なテクニックの1つは、エージェントのプロンプトをチェックポイントごとに分割することでした。これにより、チェーン内の各応答を検査し、どこで問題が発生したかを特定できました。

教訓3：76%が統合されたロギングを欠いており、これはガバナンスの問題です

当社のレポートによると、組織の76%が、すべてのモデルとワークフローにわたる完全に統合されたロギングを欠いていました。これは、コストの問題と制御の問題を同時に引き起こします。どのモデルが、誰によって、どの部署で使われているかが見えなければ、コスト構造を把握することも、それらを制御することもできません。

SurveyMonkeyは LLMのオブザーバビリティ をスケーリングよりも先に導入しました。なぜなら、それがなければこれらのシステムは制御不能になるからです。彼らのロギングは現在、コストだけでなく品質にも及んでいます。彼らはハルシネーションを監視し、評価やLLMを審査員として使用して出力をチェックしています。ダニエルは、多くのチームが不意を突かれるような問題点を指摘しました。通常ログには決して含まれない場合でも、エージェントの出力にはユーザーのPII（個人識別情報）が含まれる可能性があります。そのため、デフォルトですべてをログに記録するのではなく、何をログに記録し、何を削除するかを設計する必要があります。

両者とも、オブザーバビリティが最初に構築すべきものだと感じられることはめったにない、という不都合な点に同意しました。何かをリリースして価値を示すことに惹かれがちです。それはもっともですが、後から追加されるガバナンスは、設計段階で組み込まれたガバナンスよりもはるかにコストがかかります。そして、AIゲートウェイは、すべての開発者が覚えておくべきことではなく、ロギングが自動化される場所です。

教訓4：内部か外部かでリスク姿勢が決まる

拡張とリスクのどちらを優先するかは、主に1つのことにかかっています。AIが内部向けか外部向けか、ということです。これは、当社が協力している企業全体に対するアヌラグの見解であり、両方の実務家がそれを確認しました。

内部向けの生産性ツールは、多少の問題が発生してもコストが低いため、迅速に進めることができます。Viaは、非技術系スタッフを含む自社の従業員が、既製のテンプレートからダッシュボード、小規模なサイト、または自動化を迅速に立ち上げられるように、内部インフラストラクチャを構築しました。顧客向けのものは話が別です。ミーナルは率直に述べました。外部向けAIは、顧客が自分のデータがどのように使用されているかを知りたがるため、より厳しい精査に直面し、内部向けのものよりも厳しいレビューサイクルを経ます。両者のバランスをうまく取っている企業は、まずリスク姿勢に投資し、その余裕を利用して拡張する企業です。

教訓5：200ではなく、ROIの高い8〜10のユースケースから始める

セッションで最も強調されたアドバイスは、抑制することでした。すべてを一度にやろうとしないこと。ミーナルのルールは、テクノロジーではなくユースケースを優先することでした。なぜなら、問題から始めることが、適切なツールと真のROIへと導くからです。ダニエルのルールは、目標を賢く選ぶことでした。小さすぎると意味がなく、遠すぎると現実的ではない。そして、アジャイルなPOCとして実行し、ガードレールを構築し、それが機能するようになったらリリースする、というものです。

アヌラグはこの変化を間近で見てきました。数年前、チームはAIで解決したい200ものユースケースのリストを持ってやってきましたが、そのほとんどは、節約できるコストと同じくらい構築に費用がかかるものでした。今日、最先端を行く組織は、それぞれ確かなROIを持つ8〜10のユースケースを持ち込み、コスト管理、ガバナンス、可観測性を最初から導入しています。最後の部分が重要です。これを怠るチームは、本番環境にデプロイした後、一度失敗すると、すべてを元に戻して再構築しなければなりません。制御レイヤーを早期に導入すれば、優れたユースケースは成長する余地を得られます。

TrueFoundryが単一のコントロールプレーンでエージェントAIガバナンスを運用する方法

TrueFoundryは、エージェントAI向けのエンタープライズAIコントロールプレーンとして構築されています。この考え方は、上記の6つの教訓に直接当てはまります。モデル、MCP、エージェントを単一のレイヤーに統合し、その上にコスト、ガバナンス、可観測性を配置するのです。

「 AIゲートウェイ」 がエントリーポイントです。これにより、プロバイダーをまたがる1,000以上のLLMに対してOpenAI互換の単一APIが提供されるため、モデルの切り替えは書き換えではなくリクエスト内の名前変更で済みます。約3〜4ミリ秒のオーバーヘッドを追加し、単一のvCPUで350以上のRPSを処理できるため、ボトルネックになることなくホットパスに留まります。すべてのリクエストがこれを通るため、支出追跡、予算、レート制限、モデルルーティングは、各サービスで再実装されるのではなく、一元的に適用されます。

MCPゲートウェイとエージェントレジストリは、教訓3のN対M問題を解決します。MCPサーバーとエージェントは、ツールレベルのアクセス制御とともに一箇所に登録されるため、残りの部分を公開することなく、特定のユーザーに特定のツールを付与でき、すべての呼び出しが認証および追跡されます。ガードレールはこのレイヤーでポリシーとして適用されます。これは、SurveyMonkeyが事前承認済みエージェントテンプレートで説明したパターンです。データ、コンテキスト、可観測性制御はテンプレートに組み込まれているため、チームはデフォルトでそれらを継承します。

可観測性については、ゲートウェイはOpenTelemetryに準拠しており、プロンプトからツール、モデル実行までのすべてのリクエストをトレースし、Grafana、Datadog、またはPrometheusに接続します。もしCTOが30のエージェント、3つのモデルプロバイダー、そして制御レイヤーなしで現れたとしても、最初の一手は書き換えではありません。それらのエージェントが消費するすべてを一箇所に登録し、そのエンドポイントを中央レイヤーに向けることで、開発者がコードに触れることなく、統合されたロギングとコスト管理が実現します。

関連資料

• LLMゲートウェイとは？ 本稿の背景にあるアーキテクチャの基礎
• 最高のMCPゲートウェイ MCPサーバーを管理するレイヤーを評価する方法
• LLMコスト追跡ソリューション 支出の可視化をさらに掘り下げる
• MCPとRAGの比較 エージェントにコンテキストを与える2つの方法の比較

まとめ

6つの教訓、1つの共通点。コスト、トレーシング、MCPアクセス、ロギング、リスク姿勢、ユースケースの選択はすべて、エージェントの動作を監視し制御するための単一の場所があるかどうかに帰結します。AIゲートウェイがその場所であり、それを早期に導入することで、チームは最初の失敗後に元に戻すのではなく、本番環境でエージェントAIを拡張できるようになります。

TrueFoundryの AIゲートウェイ コスト、MCPガバナンス、オブザーバビリティを単一のコントロールプレーンで管理します。または、デモを予約して、ご自身のスタックでその機能をご確認ください。