バウミク氏によれば、多くの企業はAIプロジェクトを始める際、まず「どのモデルを採用するか」という議論からスタートする。GPTやClaudeといったモデルを選定し、限られたデータや想定シナリオを使って機能を実装する。そして、制御された環境で高い精度を示した段階でPoCを成功と判断し、本番環境へ展開する。

　しかし、本番環境ではユーザーが想定外の質問を投げ掛けるだけでなく、参照するデータも日々変化する。その結果、PoCでは問題なく動いていたAIが期待通りの回答を返せなくなり、ユーザーから不満の声が上がるケースが少なくない。

　銀行のプロジェクトでも同様の問題が発生した。銀行のケースを基に、バウミク氏はPoCが失敗に至った3つの原因を挙げる。

　1つ目は可観測性の欠如だ。AIがどのようなデータを参照し、どのような判断を経て回答を生成したのかを追跡できなかったため、誤回答が発生しても原因を特定できなかった。

　2つ目は評価の欠如である。回答精度について漠然と議論していたものの、「何をもって成功とするのか」を数値で定義していなかった。そのため、本番環境で成果を客観的に測定する仕組みが存在しなかった。

　3つ目はガバナンスの欠如だ。問題が発生した際に誰が責任を負うのか、利用するデータは誰が管理するのかといった運用ルールが整備されていなかった。

　つまり、AIモデルそのものに問題があったのではなく、本番運用を支える仕組みが存在していなかったことが失敗の本質だったのである。

AI構築を支える「5つの柱」

　こうした経験を踏まえ、バウミク氏はAIエージェントを本番環境で運用するためには、モデル選定より先に“5つの基盤”を整備すべきだと説明する。

　1つ目の基盤が「評価」（Evaluation）だ。

　多くの企業はAI導入時にモデル選定から議論を始めるが、同氏は「コードを書く前に成功を定義するべきだ」と強調する。重要なのは、どのモデルを採用するかではなく、AI導入によってどのような成果を得たいのかを数値で定義することだ。

　例えばチャットbotであれば、問い合わせの自動化率や回答精度、応答時間、顧客満足度（CSAT）などを事前に定める必要がある。その上で、人間のオペレーターが実際に顧客に返している回答を収集し、評価用データセットを構築する。

　評価は単なる正誤判定ではない。同氏は3層構造の評価基盤を推奨している。

　第1層は「決定的評価」である。メールアドレスや電話番号の形式確認、個人情報（PII）の検出など、従来利用されてきた正規表現や機械学習によるチェックを実施する。

　第2層は「意味的評価」だ。ここでは「LLM-as-a-Judge」と呼ばれる仕組みを利用する。回答を生成したAIとは別のLLMを“審査員”として使い、回答の関連性や正確性、ハルシネーションの有無などを評価する。

　そして第3層が「行動的評価」である。AIエージェントが適切なツールを利用しているか、不要なAPI呼び出しを繰り返していないか、無限ループに陥っていないかといった振る舞いを評価する。

　バウミク氏によれば、この第3層を見落とす企業は少なくない。しかし本番環境では、不要なAPI呼び出しが大量発生するだけで大きなコスト増加につながるため、極めて重要な評価項目になるという。

　2つ目は「可観測性」（Observability）だ。

　AIエージェントが本番環境でどのような判断をしたのかを追跡できなければ、問題が発生しても改善できない。

　例えば顧客が「口座手数料を返金してほしい」と問い合わせた場合、AIはまず問い合わせ内容を分類し、顧客情報を取得し、関連する規定文書を検索し、それらを基に回答を生成する。この一連の処理を全て記録するのが可観測性の役割だ。

　バウミク氏は、顧客からクレームが寄せられた際に「なぜその回答になったのか」を説明できなければ、本番運用は成立しないと指摘する。特に金融業界や公共分野など規制の厳しい業界では、AIの判断経路を追跡できることが導入条件になりつつある。

　また、トレース情報を活用することで、API呼び出しの失敗や異常な挙動を検知し、自動的に再試行したり、人間の担当者へ引き継いだりするフォールバック処理も実現できる。

　3つ目は「データ基盤」（Data Foundation）だ。バウミク氏は、「AIプロジェクトの60％はデータ基盤に費やすべきだ」と説明する。

　従来のシステムでは、人間が誤ったデータに気付き修正することができた。しかしAIエージェントは違う。データが間違っていても、そのまま利用して回答を生成してしまう。

　バウミク氏によると、データ基盤には大きく2種類のデータが存在する。

　1つは、AIが回答を生成するために利用する「質問用データ」だ。社内文書やFAQ、ベクトルデータベース、業務システムのデータなどが該当する。

　もう1つは「トラッキング用データ」である。AIがどのような判断をしたのか、どのツールを利用したのかといったトレース情報だ。この情報は監査や継続的改善のために不可欠であり、組織全体で一元管理できる仕組みが求められる。

　実際に銀行の事例では、金利に関するポリシー変更後、新しい文書が検索基盤へ反映されていなかったため、AIが古い情報を基に回答していた。顧客満足度の低下を検知し、トレースデータから原因を特定できたことで問題解決につながったという。

　4つ目の基盤は「オーケストレーション」（Orchestration）だ。

　単一のAIエージェントであれば比較的管理しやすい。しかし、複数のAIエージェントが連携し始めると状況は大きく変わる。

　代表的な構成の1つが「オーケストレーターワーカーパターン」だ。中央の管理エージェントが複数の専門エージェントへタスクを割り振る方式であり、全体の制御や障害対応が容易になる。

　一方、「コレオグラフィパターン」では中央管理者を置かず、各AIエージェントが独立して動作する。イベントやメッセージを共有しながら並列処理できるため、遅延を抑えやすい。

　さらに、人間をワークフローに組み込む「ヒューマンインザループ」（人間が介在する仕組み）も重要な選択肢だ。AIの回答に対する信頼度が一定以下になった場合、自動的に人間のオペレーターへ引き継ぐことで、安全性と品質を高められる。

　そして5つ目が「ガバナンス」（Governance）だ。AIを本番環境で利用する場合、規制対応や監査証跡の管理、個人情報保護など従来以上に厳格な管理が求められる。

　特にバウミク氏が重要視しているのが、プロンプトの変更管理だ。多くの企業ではプロンプトを単なるテキストとして扱いがちだが、同氏は「プロンプトはコードとして扱うべきだ」と指摘する。いつ、誰が、どのような理由で変更したのかを記録し、ソフトウェア開発と同様の変更管理プロセスを適用する必要があるという。

　また、モデルの更新管理も重要だ。モデルベンダーが新バージョンを公開したとしても、それが自社の業務に適しているとは限らない。評価データセットを利用して検証し、安全性や精度を確認した上で導入する仕組みが求められる。

モデル選びは最後でよい

　バウミク氏によると、銀行の再挑戦プロジェクトでは、最初の2週間を評価基盤の整備に費やしたという。実際のオペレーターによる回答を約200件収集し、テストデータセットを構築した。その後、数週間かけてデータ基盤やトレース基盤を整備し、モデル選定を実施したのは7週目だったという。

　評価基盤が存在すれば、複数のモデルを同じ条件で比較し、自社の業務に最適なものを客観的に選択できる。モデル選定に何週間も費やす必要はなくなる。

　さらにバウミク氏は、本番運用向けの「インシデントプレイブック」を事前に用意しておくべきだと説明する。顧客満足度の低下や異常な回答を検知した際には、まず評価ダッシュボードで問題を検知し、トレース情報から原因を特定する。その後、問題のあるプロンプトやワークフローを切り離し、人間へ引き継ぐなどの封じ込めを実施する。修正後は、その事例を評価データセットへ追加し、再発防止につなげる。

　バウミク氏は、テストデータセットは一度作って終わりではなく、「生き物」のように成長させ続けるべきだと語る。新たな失敗事例や例外パターンを継続的に追加することで、AIシステムは本番環境の変化に適応し続けられる。

　PoCから本番運用への壁を越えるために必要なのは、最新モデルの採用ではない。評価、可観測性、データ基盤、オーケストレーション、ガバナンスという5つの基盤を先に整備することこそが、AIエージェントを実運用へ定着させるための条件だといえる。

本稿は、AI Engineerが2026年6月18日に公開した動画「￡85K Burned on a Failed PoC：What Actually Gets Agents to Production－Sandipan Bhaumik, Databricks」を基に作成しました。