94件のインシデントを全数分析して、設計思想ごとひっくり返った話

前回の記事では、影響範囲調査の自動化について、Soundy なアプローチを軸にエージェント設計の骨格を書いた。あの時点では「9件のインシデントを代表サンプルとして分析した」という前提で設計を進めていた。

その後、もっと多くのインシデントデータを入手できたので、全数分析してみた。そしたら、設計の前提がいくつかひっくり返った。今回はその話を書く。

9件から94件へ

前回まで使っていたサンプルは9件だった。今回、過去2年超にわたる94件のインシデントデータを取得して、同じフレームワークで分類し直した。

分析対象は、インフルエンサーマーケティング向けの2プロダクト（以下、プロダクト A・プロダクト B）。プロダクト A が約90件、プロダクト B が4件。

まず「在来知」の確認：A=0は揺らがなかった

前回の9件で「静的解析で防げる A パターンが0件」という発見があった。94件でもこれは変わらなかった。

コード静的解析ツールの投資は、引き続き優先度が低い。 この判断の根拠が、サンプル9件から全数94件に格上げされた。

想定外だった：D パターンの比重が大きい

前回「B（暗黙的な依存の見落とし）中心」という認識で設計していた。が、94件全体を見ると様相が変わってきた。

影響範囲調査で何らかの形で発見できる可能性がある「該当」インシデントは29件（31%）。その内訳はこうなった。

D パターンが11件。9件分析では2件しかいなかったので、数字の印象がだいぶ違う。

D パターンを具体的に見ると、「カラムの桁数が実際のデータ量を超えた」「環境変数が更新されずにリリースされた」「Intel/ARM の実行環境差でライブラリが動かなかった」といった類の問題だ。いずれもコードの diff だけ追っても気づけない。DB 側や AWS 側の実態を見に行かないと、問題が見えてこない。

これが「コードだけでなく DB・AWS を調べる設計にした理由」を、9件の根拠から94件の根拠に格上げした形になった。

「仕様/実装漏れ」という分類に潜む罠

94件中54件（60%）が「仕様/実装漏れ」というカテゴリに入っている。これが最大カテゴリだったので、最初は「仕様/実装漏れを減らす施策を考えよう」と思いかけた。

ただ、中身を見てみると3つの性質に分解できた。

「仕様/実装漏れ」というラベルは、原因の性質を区別していない。ひとまとめに扱うと、打ち手の議論がブレる。今回の仕組みで防げるのは「約15件」の部分だけ、という切り分けが大事だった。

繰り返しパターンが見えてきた

94件のデータを整理していると、同じ構造の問題が複数件発生しているパターンがいくつか見えてきた。

たとえば「DB のカラム定義が実際のデータ範囲を超えた」系の問題が複数。「外部認証サービスと DB の間でユーザー情報の同期がズレた」系が複数。「リニューアル期間中に新旧テーブルが並走していて、片方の更新漏れ」系が複数。

これらはルール（もしくはナラティブ）として言語化できる。単発の発見ではなく、「このパターンが出たら次はここを確認せよ」という知識になる。

設計がひっくり返った：YAML 構造化ルールをやめた

前回まで「ルール」を trigger / question / scope / depth の YAML 形式で定義する方針で進めていた。エージェントはそのルールを読んで調査範囲を決める設計だ。

ただ、この方針に違和感が出てきた。94件を全部見ると、繰り返しパターン（R1〜R5）に当たる件数は約10件。残りの19件は毎回違うパターンだった。

毎回違うパターンを事前にルール化するのは難しい。一方で、現代の LLM エージェント（Coding エージェント CLI）は、ゴールを与えると自律的にツールを呼び出しながら探索し、ゴールに達するまで動き続ける。この自律性が活きるのは、まさに「毎回違うパターン」を探索する場面だ。

そこで方針を転換した。

YAML 構造化ルール → Markdown ナラティブ（プレイブック）

具体的には .care/ というディレクトリを作り、こんな構成にする。

.care/
├── README.md              # エージェント向けの指示
├── incidents/             # 過去インシデントのナラティブ
│   ├── 2024-xx-incident.md
│   └── ...
├── patterns/              # 繰り返しパターンの抽象化
│   ├── R1_DB_column_overflow.md
│   └── ...
└── focus-areas.md         # 特に注意すべきリソース一覧

incidents/ の各ファイルには、「何が起きたか」「直接的な原因」「構造的な原因」「気づきどころ」を書く。「気づきどころ」の節が肝で、ここがエージェントにとっての「次にどこを見るか」のヒントになる。

YAML のフォーマットに沿って書くより、ポストモーテムのダイジェストを書き留める方が負担が少ない。そして、既存の障害対応フローでやることと自然に重なる。

エージェントの自律性を活かすなら「後段ガードレール」で制御する

YAML 構造化ルールの役割のひとつは「エージェントの探索範囲を厳密に制御する」ことだった。scope / depth でどこまで調べるかを事前定義する。

でも、自律エージェントの強みは自分で次の行動を決めるところにある。事前にスコープを厳密に絞りすぎると、その強みが消える。

そこで「事前制約」ではなく「後段ガードレール」に切り替えた。

- 最大ツール呼び出し回数: 30回/PR
- 最大トークン消費: 100k/PR
- タイムアウト: 5分/PR

ガードレールに達したら「調査途中で終了した」とレポートに明記する。不完全でも報告する。これで「暴走を防ぎながら自律性を活かす」バランスを取る。

ステージ分割という考え方

1つのエージェントに「プレイブック照合・仮説生成・証拠収集・評価・レポート整形」を全部やらせると、指示がぼやける。

そこで役割別にステージを分けた。

Investigator にだけ強力モデル＋自律ループを使い、最も価値の高い部分に集中投資する設計だ。

ステージ間の情報受け渡しについては「正直ここで詰まった」部分がある。JSON で構造化して渡せば綺麗に見えるが、LLM が持つニュアンスや推論の経緯が落ちる。対策として4つの原則を置いた。

MCP は不要だった

最初「MCP（Model Context Protocol）で DB・AWS にアクセスする設計にしよう」と考えていた。ただ、Jenkins 環境でエージェントを動かすなら、IAM ロール＋ DB 接続情報＋ Git 認証をエージェントに付与するだけで、直接ツール呼び出しができる。MCP の抽象層は不要だった。

「MCP を使うと疎結合になる」という利点は、複数 LLM で同じツールを共用したい場合などに効く。Jenkins 環境の固定ツール群には当てはまらない。

CTO 視点で正直に評価した

設計が固まってきたところで、一歩引いて ROI 計算をしてみた。

収支の中央値で計算すると：

直接工数の削減だけでは、運用コストを賄えない。

「ビジネス影響込みで計算すると投資に値する」という論拠もあるが、過去94件を見ると大半が数時間で復旧しており、明確にブランド・売上インパクトがあった事案は限られていた。

正直に言うと、現時点では「nice to have」の水準だと判断した。

現時点の結論：保留、ただし検討終了ではない

この仕組みの Phase 1 着手は、現時点では保留にした。ただし「検討終了」ではなく「とりあえずの結論」。以下のトリガー条件が満たされた時点で問い直す。

実装しなくても手に入った価値がある

仕組みを作らなくても、今回の検討からは確実な成果が手に入っている。

即 Go 可能な派生施策：

α: 障害報告テンプレートに「気づきどころ」「類似事例」欄を追加

フォーマット変更のみ（数時間）。将来の再検討用データが自然に蓄積される。

β: 繰り返しパターンを PR レビューチェックリストに追記

DB のカラム変更時は実データの範囲を確認、新旧並行テーブルの片方を触るなら両方確認、といったチェック項目を人間レビューに組み込む。1〜2日の作業で実装できる。

γ: 静的解析投資の優先度判断を組織的に共有

「94件中 A パターンが0件」という事実は、ツールベンダーとの商談などで判断根拠になる。

94件の分析データ自体も、テスト戦略・監視戦略の見直しに使える根拠として残る。

振り返って

9件から始まった分析が94件まで広がって、設計が2回ひっくり返った。

1回目は「YAML 構造化ルール → Markdown ナラティブ」。エージェントの自律性を活かすには、事前制約より後段ガードレールの方が合っていた。

2回目は「構築 → 保留」。ROI を正直に計算したら、現時点では見合わないという結論になった。

この「保留」という判断も、15時間ほどの分析と検討から導いたものだ。着手しないことを着手前に判断できたなら、それはそれで価値がある、と思っている。

次のステップは、α と β の派生施策を動かしながら、データを積み上げること。トリガー条件が満たされた時点でまた問い直す。

参考

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