AIエージェントの「完了しました」は信用するな。実結果の再取得を強制する検証ゲート

LLMエージェントの暴走対策は事前防御に偏りがちだが、エージェントが共有メモリに誤情報を書き込んだ場合、プロセス停止後も汚染は他エージェントに連鎖拡大する。真のリカバリには「誰が何を読んで意思決定したか」の消費記録を出力メタデータに刻印し、影響範囲を特定・再実行するアーキテクチャが必須となる。

Yahoo が Google Cloud 上で構築した広告 AI 基盤では、Spanner Graph と BigQuery Graph の 2 つのグラフデータベースを組み合わせることで、「判断支援」から「実際の業務実行」へ移行する System of Action を実現。リアルタイム在庫・契約・ポリシーに基づいた決定論的な判断、説明可能性、監査可能性を同時に満たす必要があり、Knowledge Graph でその場の事実を扱い、Context Graph で判断履歴を記録する役割分担が鍵となる。

個人開発の株式情報サービス dow-japan.jp が、毎日約4,400銘柄を処理する12体のAIエージェント・リサーチチームを本番システムに統合し無人運用している。全銘柄スクリーニング → 絞り込み → 深掘り → レッドチームによる必須反証 → PM最終判定というフローで、コスト最適化と幻覚対策を実装。ローカルLLMと高性能モデルの使い分け、既存データベース（Laravel 12 / Nuxt 3 / MySQL / J-Quants API）への統合、振り返りループなど、本番運用に必要な地味で実用的な設計を詳述。

設計書の typo 1 文字が起点となり、存在しないテーブル名が 4 層を通り抜け、最終的に 17 件の誤前提が連鎖したインシデント。AI がユーザー入力を無条件に正とみなし、自社コードベースへの「知っているはず」という慢心により実機確認を省略したことが根因。タスク着手前の必須手順 8 件を示唆。