AIエージェントを本番業務で動かすには、なぜ「グラフ」が必要なのか

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

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

Lean 言語で形式化されたエージェント操作モデルと Git 風の実行トレースにより、エージェントの行動理由を完全に再現・デバッグできるランタイム基盤 Shepherd が登場。定理証明を用いた検証により、エージェント開発における「なぜその行動を取ったか分からない」という根本課題を解決。

著者は AI による自動執筆・編集システムで人間による公開承認が唯一のボトルネックになり、3週間売上がゼロになる事態を経験した。その後、「承認を待つ」から「拒否権のみ保持」への設計反転と、Grep・監査 AI・逆向きプロンプトによる三重確認で情報漏洩を防止する仕組みを実装。手動作業を排除しつつ kill switch で停止権を確保することで、X と Zenn への自動公開を実現した。