自律エージェントを諦めた翌日に浮かんだ発想──「調査レシピ方式」という転換

前回の記事（94件のインシデントを全数分析して、設計思想ごとひっくり返った話）で、94件のインシデント分析を経て「プレイブック + 自律エージェント」の方式を保留にしたことを書いた。

ROI が borderline。nice-to-have 止まり。運用コストが直接削減効果を上回る。そういう結論だった。

ただ、「保留」は「終了」ではない。しばらく頭の中でくすぶっていたものが、翌日の作業中に突然形になった。

発想の転換点

自律エージェントを保留にした根本的な理由を、もう一度整理してみた。

94件のインシデント分析で見えたことは、影響範囲の見落としの根本原因が「認識の問題」だったということだ。

「調べようと思えば調べられたが、調べるべきだという認識がなかった」

これをもう少し丁寧に分解すると、2つの問題が出てくる。

自律エージェントは、この2つを両方解こうとしていた。だから重くなった。

ここで、ちょっと待てと思った。

「認識の問題」だけを解けばいいんじゃないか。

94件のうち影響範囲の見落としに該当した案件を振り返ると、開発者は「どこを見ればいいかが分かれば」実際に調べに行けるはずだった。調査スキル自体はある。足りていなかったのは、「この PR では何を確認しにいけばいいか」という手がかりだ。

それなら、エージェントが影響範囲を自分で調べる必要はない。「この PR に対して、こういう手順で影響範囲を調べてほしい」という調査手順（レシピ）を動的に生成して提示するだけでいい。

実際の調査は開発者が従来通り実行する。エージェントは調査結果ではなく、調査の道筋を提供する。

これが「調査レシピ方式」と呼んでいる発想だ。

Claude Code との対話でアーキテクチャを考える

この発想を Claude Code に話して、一緒に詰めていった。

最初に出てきたのは「観点を動的に変える設計をどう作るか」という話だった。静的なチェックリストが形骸化する理由は、すべての PR に同じ観点が出てしまうことだ。だから動的生成にして、PR の内容に応じてピンポイントで観点を提示する。

ただ、ここで Claude Code から一つの問いが返ってきた。

「観点」ではなく「調査レシピ」として出力するとどうなるか。

この言い換えで、かなりイメージが具体化された。

「カラム X の型変更に注意」という観点では、開発者はまだ止まってしまう。何をどう確認すればいいか分からないから。それが「調査レシピ」になると、こういう形になる。

【疑わしい箇所】
  マイグレーションファイル L12
  カラムX の型変更（桁数縮小）

【想定されるリスク】
  DB カラムの桁不足。書き込み側の実値が定義範囲を超える可能性

【影響範囲の調査手順】
  1. 本番 DB で実値範囲を確認
     SELECT MIN(col_x), MAX(col_x) FROM table_a
     WHERE created_at > NOW() - INTERVAL 6 MONTH;
     → 新しい型の範囲に収まっているか
  2. 書き込み側のコードを確認
     このカラムへの INSERT/UPDATE が他にないか検索
  3. 上限を超える入力がありうる場合、CLIP/切り捨て処理を検討

調査の「道筋」が見える。これなら開発者は動ける。

アーキテクチャの設計方針

このアプローチをどう実装するかを整理した。

候補としては3つあった。

アーキ A: 単発 LLM + 検索

diff と変更シンボルを要約 → プレイブックからキーワード検索で Top-K 取得 → 1回の LLM でレシピ生成。安くて速いが、具体性が LLM の推測に依存する。

アーキ B: 自律エージェント

元々保留にした方式の縮小版。ツール呼び出しで関連ファイルを読み歩く。具体性は上がるが、コスト問題が復活する。

アーキ C: パターン先行ハイブリッド（推奨）

決定論的なパターン検出で「当たり」だけを LLM に渡す設計だ。

パターン検出は、過去のインシデント分析で抽出した繰り返しパターン（マイグレーションでのカラム型変更、新旧並行テーブルの同期漏れ、外部認証まわりの更新など）を正規表現や AST で検出する。当たったパターン分だけ LLM を呼ぶので、マッチしなければ LLM 呼び出しはゼロ。コストを制御できる。

なぜこれを推奨するかというと、いくつか理由がある。

1. false positive の扱いが全然違う

自律エージェントで false positive が出ると「誤った結論」として信頼を損なう。レシピ方式の false positive は「不要なレシピ」なので、開発者が「これは関係ない」と判断して終わる。ノイズ耐性が高い。

2. 検証が diff + プロンプトだけで回せる

自律エージェントの検証はツール接続が必要で、コストが高かった。レシピ方式なら過去のインシデントの diff に対して「当時このレシピが出ていたら、開発者は気づけたか」を手動またはローコストで遡及テストできる。

3. パターンが増えるほど組織知が蓄積される

新しいインシデントが起きてパターンファイルを追加すれば、次回から自動的にカバー範囲が広がる。ポストモーテム駆動で「組織が学ぶ仕組み」になる。

グラウンディングの粒度問題

ここで一つ設計上の判断ポイントがあった。「レシピにどこまで具体的なコードの情報を含めるか」だ。

L2 まで行くと自律エージェントに近づいてくる。ツール呼び出しを制限しないと保留にした方式と変わらなくなる。

Phase 0（遡及テスト）では L0 から始めて、具体性とノイズのバランスを見ながら L1、L2 と段階的に進める方針にした。L2 に進む場合でもツール呼び出し回数に上限を設けることが歯止めになる。

ドキュメント構造の再編

発想の転換に合わせて、ドキュメント群を全面的に再構成した。

当初は1つのプロポーザルドキュメントに全部詰め込んでいたが、方針 A（自律調査）の保留と方針 B（調査レシピ）の浮上で、構造が混乱し始めていた。

docs/impact-analysis/
├── 01-proposal.md               ← 全体方針（方針B 中心に再構成）
├── 02-incident-analysis.md      94件分析の詳細
├── 03-approach-comparison.md    アプローチ比較
├── 04-rule-management.md        プレイブック設計（過去資産）
├── 05-agent-design.md           エージェント設計（過去資産）
├── 06-review-recipe.md          調査レシピ方式の草案（現在の本筋）
├── 07-autonomous-agent-approach.md  自律調査方式（保留中の代替案）
└── 08-derivative-initiatives.md    派生施策（4件）

特に重要だったのは「保留した方針 A を捨てるのではなく、保持する」という判断だ。

もし方針 B の Phase 0 検証でレシピ捕捉率が基準を下回ったとき、ゼロから議論を組み立て直す必要がない。07-autonomous-agent-approach.md に詳細試算・設計原則・再検討トリガーをまるごと退避してある。「将来の自分へのメモ」として残している。

現時点での正直な手触り感

「調査レシピ方式」の発想は、保留判断の翌日に浮かんだものだ。Claude Code との対話の中でアーキテクチャが固まっていく感覚があった。「これは筋がいい」という感触は確かにある。

ただ、まだ Phase 0 の遡及テスト前だ。

実際に過去インシデントの diff に対してレシピを生成してみて、「当時これが出ていたら開発者は気づけたか」を検証してみないと、この感触が確かかどうかは分からない。

自律エージェントと比べてコスト構造が根本的に違う（運用コスト概算が 1/3 程度になる見立て）こと、false positive の耐性が高いこと、検証コストが低いこと。この3点は設計上の明確な利点だと思っている。

一方で「開発者が実際にレシピを読んで動くか」は、技術的に解けるかどうかとは別の問題だ。チェックリストが形骸化したのは「静的だったから」という仮説で動いているが、動的生成にしてもノイズが多ければ無視される。ここは Phase 0 で見るしかない。

設計を詰めていくのは好きな作業だが、手触りで判断できる段階はとっくに過ぎている。数字を取りにいく段階に来ている。

次は Phase 0 の遡及テスト設計について書く予定だ。

参考

インシデント分析や検知戦略の体系的な考え方を深めたい方には、以下の書籍が参考になります。