優れた AI エージェントが本番環境で失敗する理由：インフラストラクチャ層の欠落

最初のアラートが発生したのは午前 6 時でした。そして 2 つ目が発生しました。さらに 3 つ目が発生しました。

当直のエンジニアがノートパソコンを開くと、1 つのAIエージェントから、互いに関連性のない 3 件の障害が報告されていました。そのエージェントはサポートチケットの処理、請求額の調整、顧客からの質問への回答を行っていました。それは LangChain 上で動作していました。ステージング環境でのすべてのテストに合格し、動かなくなるまでは、正常に機能していました 。

多くのチームがプロンプトエンジニアリングやモデル選定に何カ月も注ぎ込んだにもかかわらず、そのどちらとも関係のないインシデントの収拾に週末を費やす姿を私は何度も見てきました。その後に続く障害は、仮定の話ではありません。これらは、適切にサポートするために必要なインフラストラクチャがない状態で、エージェントを初めて本番環境に投入したときに起こる典型的な問題です。本番環境へのデプロイに不可欠なインフラ、アイデンティティの境界、安全性の確保、運用ガバナンスを標準で備えているフレームワークには、まだ出会ったことがありません。

43 件の重複したサポートチケット

そのエージェント、つまり 目標について推論し、ツールを選択し、自律的に複数のステップを実行する AI システム は、サポートのキューを監視していました。顧客が問い合わせを送信しました。エージェントがチケット発行 API を呼び出してレコードを作成し、API はリクエストを受け入れてチケットを作成しました。しかし、その後に応答がタイムアウトしました。

エージェントから見ると、呼び出しは失敗したことになります。LangChain は、適切に設計されたフレームワークがツール呼び出しの失敗時に行う動作を実行しました。つまり、再試行したのです。再試行により、2 つ目のチケットが作成されました。応答が再びタイムアウトしました。再度、再試行が行われました。また別のチケットが作成されました。

午前 6 時までに、システム内には 43 件の重複チケットが存在していました。それぞれが自動確認 E メールをトリガーし、その結果、顧客の受信トレイに 43 通のメッセージが届くことになりました。サポートチームは午前中、本来の業務を行う代わりに、手作業で重複チケットをクローズし、謝罪メッセージを送信することに追われました。

これは重要な点であるため、ここで何が問題だったのかを正確に説明したいと思います。LangChain はこれを正しく処理しました。フレームワークが応答の失敗を検出し、呼び出しを再試行しました。それはまさに再試行ロジックが設計された通りの動作です。問題は再試行そのものではなく、元のリクエストが成功していたかどうかを追跡する仕組みがインフラストラクチャ内に存在しなかったことです。べき等性エンベロープ (リクエストが繰り返されても元のリクエストと同じ結果を生成し、重複を防止するメカニズム) が存在しませんでした。重複排除レイヤーもありませんでした。これがすでに完了した操作の再試行であることを、プラットフォームレベルで認識する仕組みもありませんでした。

損益を計算する意思決定者にとって、ここでのコストは単に気まずい思いをした午前中だけにとどまりません。サポートスタッフの工数が事後処理に奪われ、機械的な重複 E メールによって顧客の信頼が損なわれ、誰かがすべてのオープンチケットを手作業で監査するまで信頼できなくなったシステムそのものが損失となります。再試行ロジックを確認する開発者にとって、コード自体は正しかったのです。ギャップはその下にありました。

フレームワークはその役目を果たしました。しかし、それを取り巻くインフラストラクチャが存在しなかっただけです。

誤ったアカウントに請求された 4,000 ドル

インフラストラクチャのギャップは、43 件のチケットのように騒がしい場合もあれば、静かに進行する場合もあります。同じ AI エージェントが請求額の調整を処理していました。そのエージェントには、デプロイメント時にサービスアカウントでプロビジョニングされた請求 API へのアクセスがありました。そのサービスアカウントは複数の請求先アカウントにアクセスできました。それが開発環境でエージェントを動かす最も手っ取り早い方法だったからです。エージェントを本番環境に昇格させる前に認証情報のスコープを設定した人はいませんでした。それは、単なる設定ではなく検証されたアイデンティティに基づいて特定のワークロードがアクセスできるリソースを制御するインフラストラクチャ層である「アイデンティティ境界」を誰も構築していなかったからです。

エージェントはアカウント A に対する請求を処理する必要がありました。そのプロンプトにはアカウント識別子が含まれていました。モデルはアカウント B を選択しました。これは大規模言語モデル (LLM) について起こり得るエラーです。請求 API は呼び出しを受け入れ、誤った顧客に 4,000 ドルが請求されました。

これはモデルの不具合ではありません。LLM はもっともらしい出力を生成しますが、時には間違えることもあります。考えられる原因は、同じ請求 API に誤ったアカウントパラメーターが渡されたことであり、これは十分にあり得る選択エラーでした。

従来のソフトウェアでは、誤ってルーティングされた API 呼び出しが及ぼしうる影響は、2 つの層によって制限されています。1 つは、認証情報のスコープによってワークロードがアクセスできるサービスが制限されること、もう 1 つは、ダウンストリームの API によって、特定の呼び出し元に対して有効なパラメーターが強制されることです。開発者なら、単一の認証情報セットですべての顧客の請求レコードに書き込みができる Web アプリケーションをリリースすることは決してないはずですが、ここではまさにそれが起きていました。

エージェントにはシステム内のすべてのアカウントにアクセスできるほど広範な認証情報が提供されており、スタック内のプラットフォームもダウンストリーム API も、そのスコープを制限していませんでした。現在、認証情報のスコープ設定機能を標準で提供しているフレームワークはありません。暗号化されたワークロードのアイデンティティを提供したり、プロンプトの内容ではなくインフラストラクチャレベルのポリシーに基づいてエージェントがアクセスできるサービスを制限したりするフレームワークは存在しません。

翌週の月曜日に誰かが請求書を確認するまで、誰も気づきませんでした。私はあらゆる規模でこの種の障害を目にしてきました。それぞれの詳細は異なっても、根本的な原因は常に同じです。それは、エージェントが持つべきではない認証情報を保持しており、スタック内にその境界を強制実行するものがないという点です。

会社が定めていない返金ポリシー

境界が強制実行されていなかったことでその夜 4,000 ドルのエラーが発生しましたが、3 つ目の障害はさらに数値化しにくいコストをもたらしました。ある顧客がエージェントに対し、購入した製品の返品期間について問い合わせました。モデルは自信に満ちた明確な回答を生成しました。それは、返金ポリシーでは 90 日以内の返品が認められている、という内容でした。実際のポリシーは 30 日間でした。その回答は明瞭で親切でしたが、完全に誤っていました。

LangChain はモデルの出力を顧客向け応答チャネルに渡しました。ここでもフレームワークは、設計された通りの動作を行いました。つまり、モデルの出力をチェーンの次のステップへとルーティングしたのです。推論の境界 (顧客への送信、データベースへの書き込み、アクションのトリガーなど、モデルの出力が現実世界に入る接点) にガードレールが存在しませんでした。文書化されたポリシーと出力を照合する検証レイヤーはありませんでした。エージェントの応答が顧客に届く前に、既知の事実と矛盾していないかをチェックするメカニズムはありませんでした。モデルの出力はその間に何の介在もなく、一直線に顧客へと渡されました。

顧客はエージェントの回答を引用し、47 日目に 280 ドルの製品を返品しました。チームはその返品を受け入れました。そのコストは返金金額そのものにとどまらず、法的なリスクにも及びました。AI エージェントが顧客に対して権限のない契約上の表明を行い、企業にはそれを防止するためにどのような制御が講じられていたかを示す監査証跡がなかったのです。

請求エラーには具体的な金額があります。重複したチケットには件数があります。しかし、顧客に送信された捏造されたポリシーは定量化が難しく、封じ込めることも困難です。これは雪だるま式に膨らむリスクです。エージェントが検証なしに送信するすべての応答が、法務チームが承認していない潜在的な契約上の約束事になり得ます。顧客と対話するエージェントを運用しているすべての組織がこのリスクに直面しており、その大半はそれに気づいていません。

正常だったエージェント

開発環境では完璧に動作していたエージェントが、一晩で 3 件の障害を引き起こしました。

そのパターンを見てみましょう。いずれの場合も、フレームワークは正しく機能しました。LangChain はツール呼び出しをオーケストレーションし、出力をルーティングし、失敗時には再試行を実行しました。エージェントループ - 推論、計画、ツール呼び出し、オーケストレーション - は、設計どおりに機能していました。

すべての障害は、本番環境のインフラストラクチャが存在しなかったために発生しました。1 つ目の障害では、プラットフォームレベルでのべき等性と重複排除が必要でした。2 つ目の障害では、スコープ設定された認証情報と暗号化されたワークロードのアイデンティティを備えたアイデンティティ境界が必要でした。3 つ目の障害では、推論の境界におけるガードレール、つまり応答が顧客に届く前に、文書化された事実と照合する出力検証 が必要でした。

これらはフレームワークが担うべき領域ではありません。アイデンティティ、ツールガバナンス (エージェントがどのツールにどのような条件でアクセスできるかの制御)、可観測性 (監査やデバッグができるようエージェントのすべてのアクションを追跡できること)、安全性の強制実行はプラットフォームの責務であり、これらを解決するように設計されたフレームワークは存在しません。

私は LangChain、CrewAI、LangGraph、カスタムフレームワーク上でエージェントを運用しているチームと話をしてきました。選択されるフレームワークは様々です。しかし、ギャップは変わりません。彼らは皆、同じ壁にぶつかっています。「開発環境で動く」ことと「本番環境で稼働する」ことのギャップはフレームワークの問題ではなくインフラストラクチャの問題であり、未解決のままであれば、実際の金銭的コスト、顧客の信頼の損失、またエンジニアの実際の工数を奪い続けます。

ギャップを埋めるもの

このインフラストラクチャの問題には明確な特徴があります。エージェントのフレームワークはエージェントのループを解決します。それらは本番環境のインフラストラクチャを解決するために設計されたものではなく、そうあるべきでもありません。Web フレームワークに独自の Transport Layer Security (TLS) 認証局が標準搭載されていることを期待する人はいないでしょう。これらはエンジニアリングの異なるカテゴリーです。

Red Hat AI は、フレームワークにはない本番環境インフラストラクチャを提供します。 Red Hat OpenShift AI が基盤として機能します。その運用原則は BYOA (Bring Your Own Agent) です。ここでプラットフォームは、LangChain、CrewAI、LangGraph、カスタムコードであれ、エージェントに変更を加えることなく、あらゆるエージェントランタイムを本番運用可能にします。フレームワークへの投資はそのまま活かされます。エージェントのコードを変更する必要もありません。プラットフォームがその基盤として、アイデンティティ、安全性、ガバナンス、可観測性のレイヤーを組み込みます。

すでに抱えているギャップ

午前 6 時に障害を起こしたエージェントは、決して粗悪なエージェントではありませんでした。それは足場となる土台がない状態で動作していた、優れたエージェントだったのです。どのフレームワークも、推論ループ、ツール呼び出し、オーケストレーションを提供します。しかし、それらの機能が実環境で安全に実行できるかどうかを判別するインフラストラクチャを提供するフレームワークはありません。フレームワークが処理するものと、プラットフォームが処理しなければならないものとの間のこの違いこそが、「本番環境のギャップ」です。これは、利用しているフレームワークが埋めるように設計されたギャップではありません。

現在開発中のエージェントがあるなら、それらも同じように土台が存在しない足場の上に立っているはずです。それはエージェントの構築方法が間違っているからではなく、その土台がフレームワークには同梱されていないからです。次の記事では、その土台を構成する具体的な要素と、それらを導入するために何が必要かを解説します。

今すぐ始める

本番環境に対応したエージェントのインフラストラクチャがどのようなものか、確認してみませんか？ここから始めましょう：

• 開発者サンドボックスで OpenShift AI を無料で試す：AI ワークロードを試すための事前構成済み環境
• Red Hat AI のインタラクティブデモを見る：Red Hat AI の実践的な紹介
• BYO Agent スターターキットから始める：LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK などの事前構成済みテンプレート
• Red Hat AI のドキュメントを読む：プラットフォームの詳細なドキュメント
• Red Hat AI での BYOA の運用化：OpenClaw エディション：プラットフォームに実際のエージェントをデプロイするための実践的な記事