社内業務にAIエージェント（人間の指示なしに複数の手順を自律的にこなすAIシステム）を導入しようとして、デモは動いたのに本番稼働まで進まない。そんな状況に心当たりがあるなら、この記事の内容が参考になるかもしれません。
海外の技術コミュニティdev.toに投稿された分析では、エンタープライズ向けAIエージェントの95%が本番環境に到達しないと指摘されています。原因はモデルの性能ではなく、オーケストレーション（複数の処理やシステムを調整・連携させる設計）にあるという見立てです。この記事では、その3つの境界線を業務システム開発の視点から読み解きます。
プロトタイプと本番の間にある溝
社内向けのAIエージェントは、たいてい小規模なデモでは問題なく動きます。
たとえば「10件の文書から回答を探す」程度のタスクなら、既存のフレームワークでも十分な精度が出ます。
ところが対象データが1万件を超えたり、複数の業務システムと連携し始めたりすると、途端に破綻します。これは技術の限界というより、設計段階で想定していなかった負荷が原因です。
分析では、この破綻パターンを3つに整理しています。コンテキスト（AIが参照する会話履歴や関連情報のかたまり）の爆発、状態（これまでのやり取りや処理結果）のずれ、そして既存システムとの連携の複雑さです。
境界線1: コンテキスト管理
1つ目は、参照する情報量が増えたときにAIが混乱する問題です。
多くのフレームワークは、コンテキストを単純に「プロンプトに詰め込む」方式で扱っています。これは数件の文書なら機能しますが、数千件規模になるとトークン数（AIモデルが一度に処理できる文字量の単位）の上限に達し、古い情報が失われたり、無関係な情報に埋もれたりします。
対策として挙げられているのは、ベクトルデータベース（文章の意味的な近さで検索できるデータベース）を使った意味検索や、重要度と鮮度に応じてコンテキストを絞り込む仕組みです。RAG（Retrieval-Augmented Generation、検索した情報をもとに回答を生成する手法）を導入している現場なら、この部分はすでに一部実装している可能性があります。
確認ポイントとしては、自社のエージェントが「何件までの文書なら安定して動くか」を実測しているかどうかです。デモ環境の件数と本番想定の件数に10倍以上の差があるなら、この境界線でつまずく可能性が高いと考えられます。
境界線2: 状態の永続化
2つ目は、AIエージェントが本来ステートレス（前回のやり取りを記憶しない状態）であることに起因する問題です。
業務システムでは、数日から数週間にわたる複数回のやり取りや、監査ログの保存、失敗した処理を巻き戻す機能が求められます。ところがAIエージェントの多くは、会話が終わるとメモリ上の情報が消えてしまいます。
これは既存のエンタープライズシステムでは馴染み深い話です。トランザクション管理やイベントソーシング（状態変化を1件ずつ記録し、後から再現できるようにする設計手法）は、金融系や基幹システムの開発では標準的な技術です。AIエージェントの世界では、こうした基本的な設計がまだ徹底されていないケースが目立ちます。
実務での確認方法としては、エージェントの処理結果をデータベースなど永続化層に記録しているか、それとも実行中のプロセスのメモリだけに保持しているかを確認することです。後者であれば、サーバー再起動やタイムアウトで処理履歴が消える設計になっている可能性があります。
境界線3: 統合の複雑さ
3つ目は、既存システムとの連携部分です。
エンタープライズ環境では、メインフレームのような古いシステム、SaaSやマイクロサービスといった新しいAPI、リアルタイムのデータストリームが混在しています。分析では、統合フレームワークが「特定システムにしか対応しない硬直型」か「毎回カスタムコードが必要な柔軟すぎる型」のどちらかに偏りがちだと指摘しています。
対策として挙げられているのは、共通のアダプターパターン（異なるシステムの差異を吸収する設計）、非同期処理、そしてサーキットブレーカー（障害が起きたシステムへの呼び出しを一時的に遮断する仕組み）とリトライ処理です。これらはマイクロサービスアーキテクチャの世界ではおなじみの技術で、目新しさはありません。むしろ「AIエージェントだから特別」ではなく、既存の分散システム設計の知見をそのまま持ち込めば解決できる領域だと考えられます。
既存の設計知見との重なりと相違点
ここまでの3つの境界線を見ると、実はどれも新しい問題ではないことに気づきます。
コンテキスト管理はキャッシュ設計と検索エンジンの話に近く、状態の永続化はワークフローエンジンや業務プロセス管理（BPM）の話に近く、統合の複雑さはESB（エンタープライズサービスバス）やAPIゲートウェイの設計と重なります。
違いがあるとすれば、AIエージェントの出力が確率的である点です。同じ入力でも毎回微妙に異なる応答が返るため、従来の決定的な処理を前提にしたテストや監査の手法をそのまま適用しにくいという課題が残ります。
この点は、分析でも触れられていない部分ですが、本番導入を検討するなら「出力のばらつきをどう許容するか」という基準を業務要件側で先に決めておく必要があります。
今日確認できること
実際に社内でAIエージェントの導入を検討している、あるいはすでにプロトタイプを動かしている場合、以下の点を棚卸ししてみると現状把握に役立ちます。
- コンテキストに渡すデータ量が、デモ時と本番想定時でどれだけ違うか
- エージェントの処理結果や会話履歴が、メモリではなくデータベース等に記録されているか
- 障害時に処理を巻き戻す（ロールバックする）手段が用意されているか
- 連携先システムごとに個別のコードを書いているか、共通のアダプター層があるか
- 出力のばらつきを許容する基準を、業務側と合意できているか
これらはいずれも、フレームワークやモデルを変える前に、設計図の上で確認できる項目です。
まとめ
AIエージェントが本番に届かない理由は、多くの場合モデルの性能不足ではなく、オーケストレーション設計の抜け漏れにあります。
コンテキスト管理、状態の永続化、統合の複雑さという3つの境界線は、既存のエンタープライズ開発で培われてきた設計知見と重なる部分が多くあります。ベクトル検索、イベントソーシング、サーキットブレーカーといった技術は、すでに自社のシステムのどこかで使われているかもしれません。
まず着手するなら、3つすべてを同時に解決しようとせず、自社の業務で最も影響が大きい境界線を1つ選んで検証してみることが現実的な一歩になります。