AI エージェントフレームワークだけでは不十分な理由本番環境に欠けている 7 つのプラットフォーム機能

エージェントは機能します。実際に機能しているはずです。エージェントを LangChain や CrewAI、またはカスタム環境で構築し、実際のシナリオでテストし、利用できるようにしていることでしょう。問題はエージェントではなく、その周囲にあるすべての要素が問題となる可能性があります。

「優れた AI エージェントが本番環境で失敗する理由：欠落しているインフラストラクチャ層」では、一夜にして、1 つの AI エージェントの導入で 3 つの不具合が発生しました。重複したサポートチケットが 43 件、誤った請求アカウントに 4,000 ドルが請求され、さらに架空の返金ポリシーが原因で、同社は 280 ドルの返金を認めざるを得なくなりました。 そのエージェントは開発環境では完全に機能しましたが、本番環境のインフラストラクチャが不十分であったため、本番環境で不具合が生じました。開発環境で機能するエージェントと本番環境対応のデプロイメントとのギャップは、フレームワークの問題ではなく、インフラストラクチャの問題です。

この記事ではそのギャップとは何かを明らかにします。以下について説明します。

• 現在のフレームワークには備わっていない 7 つの特定の機能
• フレームワークの限界
• 3 つの一般的な回避策が失敗する理由
• エージェントを書き直すことなく実際にギャップを解消するために役立つもの

フレームワークに含まれていない 7 つの要素

午前 6 時のインシデントでは、3 つの障害が明らかになりました。しかし、これら 3 つは、より広範なインフラの不足がもたらす症状にすぎません。組織全体で本番環境のエージェントの障害をマッピングすると、毎回同じ 7 つのギャップが確認されます。

1.暗号的アイデンティティ

暗号的アイデンティティは、到達できるサービスを決定する ID 属性により、どのワークロードがリクエストを行っているかについての検証可能な証明を提供します。4,000 ドルの誤ったアカウントへの請求は、エージェントが本番環境での使用範囲が明確に定義されていない広範な権限で操作を行ったために発生しました。大規模言語モデル (LLM) が誤ったアカウント識別子を選択しましたが、インフラストラクチャにはそれを阻止するものがありませんでした。暗号的アイデンティティを使用すると、プラットフォームはエージェントが到達できるサービスを制限し、適切に設定されたダウンストリーム API が特定の呼び出し元に対してどのパラメーターが有効であるかについて強制的に実行します。モデルが依然として誤った識別子を選択する可能性はありますが、潜在的な影響は限定されます。 被害はエージェントの承認された範囲内のリソースに限定され、システム内のすべてのアカウントに及ぶことはありません。意思決定者にとって、これは「1つのアカウントが影響を受けた」という状況と「すべてのアカウントが危険にさらされた」という状況との違いです。

2.実行サンドボックス

実行サンドボックスは、ハードウェアおよびアプリケーション・レベルの分離を提供するため、侵害されたワークロードや誤動作するワークロードがホスト・オペレーティングシステムに到達したり、他のワークロードに影響を与えたりすることはありません。これはエージェントに限ったことではありません。あらゆるワークロードに分離が必要ですが、エージェントは自律的に動作し、API の呼び出しやツールアクションの実行をマシンスピードで行うため、その必要性は緊急を要します。サンドボックス化されていない場合、1 つのワークロードの障害が同じマシン上のすべてのワークロードの障害につながります。自らの承認されている範囲を越えてファイルシステムに書き込んだり、ネットワーク接続を開始したりできるエージェントはリスク要因であり、セキュリティチームが本番環境用として承認することはありません。

3.ツールガバナンス

ツールガバナンスは、エージェントが呼び出すことができるツールを決定するインフラストラクチャレベルのポリシーであり、プロンプトインジェクション (悪意のある入力によってエージェントに意図しないアクションを実行させる手法) によって回避されないよう、ネットワークレイヤーで適用されます。プロンプトエンジニアリングを通じてツールへのアクセスを制限しようとするチームをいくつか見てきましたが、それはうまくいきません。執拗な攻撃者、あるいは十分に独創的なモデルは、プロンプトレベルの制約を迂回してしまいます。ガバナンスはプロンプトではなく、インフラストラクチャの一部であるべきです。

4.可観測性とトレース

可観測性とトレースには、すべてのプロンプト、ツール呼び出し、中間結果をキャプチャする完全な実行トレースが含まれます。午前 6 時のインシデントにおける 3 つの障害はすべて、顧客や請求書によって表面化するまで検出されませんでした。完全な実行トレースを利用できれば、顧客から報告される前に各障害を把握できたはずです。開発者にとって、これは分散型マイクロサービスの呼び出しをデバッグするのと同じ方法で、多段階にわたるエージェント間のやり取りをデバッグすることを意味します。企業にとっては、コンプライアンス審査担当者を納得させる監査証跡が確保されることを意味します。

5.継続的な評価

継続的な評価により、エージェントの出力をポリシーや実際の結果と照らし合わせて本番環境での評価を行うことで、顧客から報告される前に回帰現象を早期に発見することができます。返品ポリシーに関する誤った情報、たとえば、実際の返品期限は 30 日であるにもかかわらず、担当者が顧客に 90 日だと伝えた件が顧客に伝わってしまったのは、実際のポリシーと出力を照合する評価レイヤーが欠落していたためです。静的テストスイートは予測できた問題を捉え、継続的な評価は予測できなかった問題を捉えることができます。

6.安全対策

安全対策の徹底により、顧客、データベース、またはダウンストリームのエージェントに到達する前に出力をインターセプトする推論境界のガードレールが提供されます。エージェントが 1 日に 3 回失敗した事例では、このフレームワークは、モデルの生成した応答を何のチェックもせずに直接顧客に送信してしまいました。安全対策の徹底することにより、推論境界は単なる通過点ではなくチェックポイントになります。

7.ライフサイクル管理

ライフサイクル管理には、一貫した運用およびセキュリティ体制を維持しながら、フリート全体でエージェントのデプロイ、更新、スケーリング、廃止を行うことが含まれます。1 つのエージェントであればプロジェクトとして扱えますが、3 つのチームにわたる 10 のエージェントとなると運用上の課題となります。ライフサイクル管理がなければ、各チームが独自のデプロイプロセス、セキュリティモデル、更新頻度を作り出すことになります。その結果、一貫性が失われます。

フレームワークの限界

これら 7 つの機能にわたる一貫性こそが、本番環境で求められるものです。では、すでに使用しているフレームワークでは、実際にはどのような状況をもたらすのでしょうか。LangChain と LangGraph は、チェーン、エージェント、ツール呼び出し、構造化出力、グラフベースのオーケストレーション、セッションメモリ、検索の統合を提供します。その組み合わせの柔軟性は、実に優れています。CrewAI は、マルチエージェント間の連携、ロールベースのエージェント設計、タスクの委任、クルーのオーケストレーションを提供しており、そのマルチエージェントのパターンも綿密に設計されています。Google ADK は Google エコシステムと緊密に統合されています。Claude エージェントは推論に深みをもたらします。Strands (AWS) は AWS ネイティブのワークフロー統合を提供します。

各フレームワークは、エージェントをエージェントたらしめる「認識・推論・行動」のサイクルであるエージェント・ループにおいて、それぞれ優れた性能を発揮します。暗号的アイデンティティや実行サンドボックスを提供するものは 1 つもありません。ネットワークレイヤーでのツールガバナンスは存在しません。プロダクショングレードの分散トレース、継続的な評価、推論境界での安全対策、フリートのライフサイクル管理は、そのどれにも存在しません。

これは批判ではなく、単にカテゴリー上の区別です。フレームワークはアプリケーションレイヤーのツールですが、リストアップした 7 つの機能はプラットフォームレイヤーに関する機能です。フレームワークにこれらが備わっていることを期待するのは、Django に Kubernetes が備わっていることを期待するようなものです。コンテナオーケストレーションはアプリケーションロジックではなくインフラストラクチャであり、Web フレームワークにそれが含まれることを期待するのは合理的ではありません。これと同じことがここでも当てはまります。レイヤーが異なるだけです。

適切な ID、トレース、ガバナンスを備えた LangChain エージェントをデプロイしようとしたことがあれば、すでにこれを実感されていることでしょう。結局、エージェントのコードよりもプラットフォーム統合のコードを多く書くことになります。エージェントの作成は簡単な部分です。

スケーリングしない 3 つのアプローチ

エージェントの作成が簡単な部分であったとしても、チームは依然として難しい部分を解決する必要があります。私が話を聞いたすべてのチームは、プラットフォームによる解決策を探す前に、これらのアプローチの少なくとも 1 つを試していました。

自社での構築チームは独自の ID インジェクション、トレース統合、デプロイメント・スクリプトを作成します。1 つのエージェントであれば、これでうまくいきます。すべての要素を把握できるため、満足感さえ得られるかもしれません。しかし、3 つのチームにわたって 10 のエージェントが存在するようになると、各チームが独自のセキュリティモデル、トレース形式、デプロイプロセスを持つことになります。一貫性もガバナンスもなく、メンテナンスの負担が増大するだけで、シニアエンジニアがエージェント自体の開発から遠ざけられてしまいます。チームがエージェント機能の構築よりも、自社開発のプラットフォーム連携機能の維持に多くの時間を費やしているのを見てきました。

ホスト型エージェントプラットフォーム (Salesforce Agentforce、AWS Bedrock Agents、Azure AI Agent Service など) は、スタック全体を所有することで本番環境とのギャップを解消します。トレードオフは、データパスもそれらが所有することになる点です。すべてのプロンプト、ツール呼び出し、推論の成果物がサードパーティ・サービスを経由します。データがネットワーク外に出てはならない規制の厳しい業界では、これは論外です。また、プラットフォームが価格を変更したり、機能を廃止したりすると、エージェントもそれに合わせて変更する必要があります。

フレームワーク固有の拡張機能は、単一のエコシステム内で本番環境向けのアドオンを提供します。トレース用の LangSmith はその良い例であり、非常に有用です。しかし、LangChain、CrewAI、カスタムエージェントを運用している組織では、3 つの異なる本番環境のストーリーが必要になります。つまり、チームが学習すべき 3 つのトレース形式、3 つのセキュリティモデル、3 つのツールセットが存在することになります。本番環境のインフラストラクチャは、特定のベンダーのエコシステムにロックインされるのではなく、フレームワークに依存しないものであるべきです。

各アプローチは問題の一部を解決しますが、同時に新しい制約を導入します。1 つ目のアプローチはスケーリングしません。2 つ目は、主権と引き換えに利便性を得るものです。3 つ目は、フレームワークの境界を越えて本番環境のストーリーを断片化させます。

お客様のエージェントと Red Hat のプラットフォーム

すべてのアプローチに共通する制約は、本番環境のインフラストラクチャはエージェントフレームワークと同じ場所から提供されるか、あるいはゼロから構築する必要があるという前提です。私はその前提が間違っていると考えています。BYOA (Bring Your Own Agent) は、コードを変更することなく、プラットフォームがあらゆるエージェントフレームワークに本番環境のインフラストラクチャを提供するという Red Hat AI のアプローチであり、これとは正反対の前提から始まります。

Red Hat はフレームワークレイヤーで競合することはありません。エージェントが LangChain、CrewAI、Claude Agents、Google ADK、Strands、またはカスタム Python のいずれで動作していても、 Red Hat AI はそれを運用可能にします。チームが開発環境で記述したエージェントコードは、本番環境で実行されるコードと同じです。ID、サンドボックス、ツールガバナンス、トレース、評価、ライフサイクル管理は、エージェント開発者が記述するのではなく、プラットフォームによって注入されます。そして、本番環境のインフラストラクチャは、組織内のあらゆるフレームワークで一貫しています。

意思決定者にとって、これは組織が選択したフレームワークへの投資が無駄にならないことを意味します。チームは、それぞれの好みのフレームワークか、直面する規制上の制限へのコンプライアンスをサポートする本番環境のインフラストラクチャかのどちらかを選択する必要はありません。その両方を手に入れることができます。プラットフォームが本番環境のインフラストラクチャをフレームワークにもたらすのであり、その逆ではありません。

BYOA は、AI インフラストラクチャをレンタルする形態から所有する形態への移行でもあります。Red Hat は、デジタル主権の 4 つの柱として、データ主権、テクノロジー主権、運用主権、および保証主権を定義しています。BYOA プラットフォームはこれら 4 つすべてに対応しており、これについては今後の記事で説明します。

自律型のサイト信頼性エンジニア (SRE) エージェントを支えるのと同じプラットフォームインフラストラクチャで、人事 (HR) のオンボーディングアシスタント、調達承認ワークフロー、カスタマーサービスのエスカレーションボットなどをサポートできます。ユースケースが異なっても、インフラストラクチャはドメインに依存しません。

Red Hat は、LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK などのスターターキットを提供しており、認証、Model Context Protocol (MCP) 接続、トレースの初期化といったプラットフォーム統合がすでに行われています。チームは、何週間も統合作業を行うのではなく、Day 0 から構築を開始できます。

すでにどう決断すべきか分かっている決断

数週間ではなく Day 0 - この表現には聞き覚えがあるはずです。10 年前、組織はコンテナに関して同じ問題に直面していました。どのチームもコンテナを構築できましたが、組織全体で一貫したセキュリティ、ネットワーク、ライフサイクル管理を維持しながら、本番環境でコンテナを実行できる人はいませんでした。その答えは「より優れたコンテナランタイムを選ぶ」ことではなく、 Red Hat OpenShift を選ぶことでした。これは、ランタイム自体には備わっていないインフラストラクチャを使用して、あらゆるコンテナランタイムを運用可能にするプラットフォームでした。ここで議論している内容は、Red Hat AI がそれを基盤として動作しているため、聞き覚えがあるでしょう。

エージェントのギャップも同様の形状をしています。問いは「どのフレームワークを使用すべきか」ではありません。あなたはその決断をすでに下していますし、おそらくそれが正しい選択だったでしょう。問題は、「フレームワークには含まれていない本番環境のインフラを誰が提供するのか」ということであり、まず解消すべきギャップは、開発と本番環境の間の隔たりが最も大きい部分です。これこそがセキュリティであり、次の記事ではその点について掘り下げます。

今すぐ始める

エージェントの本番環境とのギャップを解消する準備はできていますか？

• 開発者サンドボックスで OpenShift AI を無料で試す：事前構成済みの環境で、エージェントを無料で構築し、テストできます。
• BYO Agent スターターキットの詳細： LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK などの事前構成済みテンプレート。
• 無料の Red Hat AI Foundations コースを受講する： Red Hat AI を活用した開発の基礎を学ぶ実践的な実習。
• Red Hat AI についての詳細： プラットフォームの概要と本番環境のインフラストラクチャ機能。
• Red Hat AI での BYOA の運用化：OpenClaw エディション： 実際のエージェントのデプロイにおける BYOA の実践例。