エージェントがスケールしない理由：それはAIの問題ではなく、エンジニアリングの問題

AIエージェントの拡張問題は、大規模言語モデル（LLM）の能力不足ではなく、システムエンジニアリングの課題です。デモ段階から実際のユーザー環境に移行すると、インフラの複雑さが顕在化します。

まず、ユーザー行動の予測不可能性が第一の障壁です。LLMを直接消費者に提供すると、ユーザーは予期せぬ操作を行うため、実行経路を制約するプランナーレイヤーが必要です。Claude Code、Cursor、Windsurfなどのツールは「計画・実行」パターンを採用し、エージェントは自由に振る舞うのではなく、事前に承認された計画内で動作します。この決定論的ガードレールにより、ユーザーの「クレイジーな行動」による障害を防止できます。

次に、データアクセスが真のボトルネックです。エンタープライズデータの90％以上は非構造化データ（契約書、PDF、電子メール、トランスクリプト）であり、現在の生成AIプロジェクトでは企業データの1％未満しか利用されていません。エージェントが優れた推論能力を持っていても、必要なデータにアクセスできなければ「感覚」に基づいた誤った回答を出力します。そのため、非構造化データをチャンク化、ベクトル化、管理、提供するパイプラインの構築が最優先課題です。これはモデル問題ではなくデータエンジニアリング問題です。

第三に、マルチエージェント連携によるエラー伝播の課題があります。5つのエージェントを直列に接続すると、各エージェントの失敗率が5％でも全体の信頼性は約77％に低下します。エージェントBが幻覚を起こせば、そのエラーが連鎖的に増幅されます。解決策として、エージェント間の各ホップに決定論的検証を追加し、フォールバックパスを設定し、エージェントの存在と能力を把握するレジストリを構築する必要があります。

第四に、企業固有知識の組込みは重要な課題です。LLMは初期状態ではビジネスに関する知識を一切持ちません。ファインチューニングは高コストで時間がかかり、RAGはコストが低いものの第2の壁で述べたデータパイプラインに依存します。多くの企業はこの段階で停滞します——エージェントは公開知識ではうまく機能するものの、内部プロセスでは失敗します。

最後に、監視面に大きなギャップがあります。従来のAPMツール（Datadog、Grafana）はレイテンシとエラーのみを監視しますが、エージェント監視では決定品質を追跡する必要があります：エージェントは適切なツールを選択したか？計画は妥当か？出力は事実に基づいているか？現在、この可観測性レイヤーを提供するツールはほとんど存在しません。

これらの課題に対処するため、記事はプランナー/ルーター、バリデーター、アグリゲーター、および可観測性ループを含むアーキテクチャを提案しています。プランナーはユーザー要求をサブタスクに分解し専門エージェントを選択します。各エージェントの後にはバリデーターが決定論的チェックを行います。アグリゲーターは結果を統合して矛盾を検出します。可観測性ループは決定の監査証跡と品質スコアリングを提供します。

最終的に、チームはAIエージェントを純粋なAI問題としてではなく、分散システムの問題として扱うべきです。決定論的システムが非決定論的モデルを包み込むべきであり、その逆ではありません。LLMが提案し、決定論的コードが実行を決定します。これによってのみ、エージェントはプロトタイプから本番スケールへ移行できるのです。