7月24日、Techstrong.AIが「From Demos to Durable Agents: What Production AI Really Requires」と題した記事を公開した。著者はウェルスマネジメント・不動産アナリティクス・暗号資産市場インテリジェンスといった金融ドメインでAIシステムを複数構築・デプロイしてきた実務家で、「デモで動くものが本番で生き残らない」というパターンを繰り返し目撃してきた経験から、何が壊れるのかを具体的に整理している。AIエージェントの普及が加速する今、週末のハッカソンで動くプロトタイプと、本番環境で耐え続けるシステムの間には、依然として大きな断絶がある。

LLMにベクターDBを繋ぎ、軽量なワークフローでラップすれば、それらしいエージェントは2日でできる。問題は、それが本番環境に触れた瞬間から崩れ始めることだ。

根本にある不都合な真実：非決定性

個別の課題に入る前に押さえるべき前提がある。AIエージェントはすべて、非決定的なLLMの上に乗っているという事実だ。同じ入力が、実行ごとに異なる出力を生む。Temperatureやseedパラメータで分散は減らせるが、ゼロにはできない。モデルのマイナーアップデート一つで、システム全体の挙動が変わりうる。

従来のソフトウェアには「同じ入力→同じ出力」という契約がある。AIエージェントはその契約を設計上破っている。本番運用とは、この根本的な不安定性を前提にエンジニアリングすることだ。

最初に壊れるもの

本番環境でまず崩れるのは以下の4点だ。

①検索の陳腐化：ベクターDBはインデックス作成時点のスナップショットで動く。ユーザーはその後のデータを聞いてくる。ConnexAI（エンタープライズ向けAIプラットフォームの一つ）でのRAGシステムは、厳選されたナレッジベースに対しては良好に動いたが、本番のクエリ多様性（曖昧な言い回し、マルチターン、複数ドメインを跨ぐ質問）にさらされると検索精度が大幅に低下した。リランキングレイヤーの追加と、会話データのチャンキング戦略の再設計が必要だった。

②ハルシネーションの累積：2%のハルシネーション率は、1日数千インタラクションでは「1日あたり数十件の誤答」を意味する。Nansen（オンチェーンデータ分析プラットフォーム）では、ハルシネーションがランダムではなく、クロスチェーン比較などモデルの根拠が弱いクエリタイプに集中するパターンを発見した。対策はプロンプト改善だけでは不十分で、LLM出力をオンチェーンの実データとクロスチェックするバリデーションレイヤー、信頼度スコアリング、低信頼クエリを人間レビューにルーティングするフォールバックパスというシステムレベルの設計が必要だった。

③レイテンシの非交渉性：Nansenではウォレットの動きをニアリアルタイムで捉える必要があり、3秒の遅延が意思決定の機会損失に直結した。連続するLLMコール・検索・ツール呼び出しを含むエージェントシステムのレイテンシ最適化は、単純なチャットボットの高速化とは質的に異なるエンジニアリング問題だ。

④エラーのカスケード：ある1ステップが微妙に誤った出力を返すと、後続ステップがそれを正として扱う。検索ステップが誤文書を返し、生成ステップが自信満々にその内容を要約し、それが意思決定ワークフローに流れ込む。各ステップは単独では「合理的」に見えるため、デバッグが極めて難しい。

最大の見落とし：評価（Eval）

筆者が最も強調するのが、体系的な評価の欠如が本番AIシステムの失敗の最大要因だという点だ。プロトタイプ段階の「評価」は、開発者が数件クエリを流して「良さそう」と判断するだけで終わる。これはスケールしない。

筆者はこれを「Eval駆動開発」と呼んでいる。TDDがコードを書く前にテストを書くように、最初のプロンプトを書く前に成功をどう測るかを定義する。評価スイートは後付けの品質チェックではなく、システムが約束することと実際に提供するものの間の「契約」だ。この考え方は、LangSmithやPromptfooといったLLMアプリケーション向け評価ツールが普及しつつある流れとも合致している。

ジャッジ・ルーブリック・失敗モードの列挙

評価フレームワークの中核は「ジャッジ」——システムの出力を定義された基準に照らして採点する自動評価器だ。LLMベースのジャッジ（応答品質・事実的根拠・関連性を評価）と、決定論的チェック（構造の正しさ・ツールコール精度・引用の有無）を組み合わせる。

Nansenでの具体例：オンチェーンデータの事実精度（正しいトークン残高を返したか）、ツール選択の正しさ（クエリタイプに対して適切なAPIを呼んだか）、ハルシネーション検知（存在しない指標を作り上げていないか）、応答の完全性（複数部分の質問に全て答えたか）——それぞれに独立したルーブリックと、明確な合否基準・重大度レベルを定義した。

重要な見落とし：ジャッジ自体もドリフトする。先月ハルシネーション検知に有効だったLLMベースのジャッジが、モデルアップデート後に精度が落ちることがある。Nansenでは月次キャリブレーションサイクルを実施し、50〜75件のインタラクションをサンプリングして独立採点し、一致率が85%を下回った時点でジャッジを再トレーニング・書き直ししていた。

実際に追跡すべきメトリクス

• ジャッジスコア（ハルシネーション率・検索関連性・ツール選択精度等、クエリタイプ別に時系列追跡）
• TTFT（Time to First Token）：ユーザーは最初の1秒で印象を形成する。4秒待たされると出力の質に関わらず「壊れている」と感じる
• TTFAT（Time to First Answer Token）：エージェントシステム固有の指標で、最初のトークンではなく、意味のある最初の回答（残高・価格変動・リスクフラグ等）が出るまでの時間を計測する。推論・計画レイヤーのレイテンシを露わにする指標であり、著者がNansenでの実務の中で定義したものだ
• 各レイヤーのエラー率（LLMエラー・ツールエラー・全体効率）
• 評価バリアンス・リグレッション率・カバレッジギャップ

ガバナンスと可観測性

金融システムでは技術的なパフォーマンスは前提条件に過ぎない。システムは説明可能・監査可能・コンプライアントでなければならない。ウェルスマネジメントプラットフォームでは、アドバイザーへのすべての提案に「何のデータを使い、どのロジックを適用し、どう出力を生成したか」の追跡可能なパスが必要だった。これは要望ではなく、コンプライアンス要件だった。

ガバナンスを本番後に組み込もうとすると、後付けの苦痛か、デプロイを阻むコンプライアンスレビューになる。追跡可能性とアカウンタビリティのインフラは、エージェントロジックと並行して最初から構築すべきだ。

可観測性についても同様で、デモでは開発者がシステムを直接観察できるが、本番ではその可視性が消える。インフラ監視（死活・レイテンシ・エラー率）に加え、出力レベルの品質シグナル・ユーザーフィードバックパターン・スコアのドリフトを追跡する仕組みが不可欠だ。

レジリエンス：壊れることを前提に設計する

評価・ガバナンス・可観測性と並んで、筆者が本番要件として挙げるのがレジリエンスだ。AIエージェントは「壊れない」ように設計することはできない。非決定性・外部APIへの依存・モデルのアップデートが重なる本番環境では、何らかの障害は必ず起きる。問題は障害の有無ではなく、障害が起きたときにシステムがどう振る舞うかだ。

具体的には、ツール呼び出しの失敗時に自動でリトライするか、安全なフォールバック応答に切り替えるか。信頼度が低い出力を人間レビューにルーティングするパスがあるか。一部ステップの失敗がシステム全体の停止に連鎖しないよう、エラーの伝播を局所化する設計になっているか。これらは「あれば望ましい機能」ではなく、金融ドメインのような高リスク環境では設計上の必須要件と筆者は位置づけている。

※編集部の考察：レジリエンス設計の重要性は金融に限らず広く認識されつつある。AIエージェントが業務の中核に組み込まれる場面が増えるにつれ、障害時の挙動を明示的に設計・テストする「カオスエンジニアリング的アプローチ」をLLMシステムに適用する議論も広がっている。

詳細はFrom Demos to Durable Agents: What Production AI Really Requiresを参照していただきたい。