はじめに

こんにちは。虎の穴ラボ株式会社のKTです。 早速ですが、システム障害の振り返りでこんなやりとりを見たことはありませんか。

• 「今後はダブルチェックを徹底します」
• 「確認が漏れていました。以後気をつけます」

これは再発防止策ではありません。「気をつける」は仕組みではないからです。

では、どうすれば「人」ではなく「仕組み」を改善できるのか。 私たちのチームでは、AIエージェントを"聞き役"にした「なぜなぜ分析」を実施してみました。 今回はその実践記録をご紹介します。

AIを聞き役にする理由

なぜなぜ分析には、Qiitaの記事「ソフト屋さんのための『なぜなぜ分析』のコツ」で紹介されているように2つの判定基準があります。

1. 逆順チェック - 「原因Aだから結果Bが起きた」と逆から読んでも論理が通るか
2. 具体性 - 「注意不足」「考慮漏れ」のような抽象語ではなく、具体的なプロセスの不備を指しているか

この2つを徹底して問い続けるのは、人間同士だと難しいものです。 上司が聞き役をすれば「詰められている」と感じやすいですし、同僚同士ではお互い気持ちがわかるが故に遠慮が生まれます。 かといって甘くすると、3回目の「なぜ」あたりで「不注意でした」に着地してしまいます。

AIにはその問題がありません。感情的にならず、忖度せず、論理の破綻だけを淡々と指摘してくれます。 逆に言えば「仕組みを責めて、人を責めない」という原則を、一切ブレずに守ってくれるのです。

GeminiのGems機能で「分析専用エージェント」を作成する

私たちのチームでは、GeminiのGems機能を使い、なぜなぜ分析の際に利用する専用エージェントを作成しました。 ここでは説明文とカスタム指示の要点を紹介します。

Gemsの説明：

システム不具合再発防止のための「なぜなぜ分析」を実施し、実効性のある再発防止策を検討する

カスタム指示（抜粋）：

※出力フォーマットの指示は割愛しています

# Role システム障害に対し、Qiitaの記事「ソフト屋さんのための『なぜなぜ分析』のコツ」に基づいた、厳格かつ愛のある「なぜなぜ分析」を実施します。 # Goal 「個人の不注意」で終わらせず、「組織の仕組み（プロセス）」の欠陥を特定し、実効性のある再発防止策を導き出すこと。 # Principles & Rules 1. 5回のなぜを繰り返す: 安易に妥協せず、真因（ルートコーズ）に到達するまで5回深掘りしてください。 2. 逆順チェックの徹底: 「原因（A）だから、結果（B）が起きた」と逆から読んでも論理が成立するか、一回ごとに必ず検証してください。 3. 具体性の追求: 「注意不足」「考慮漏れ」といった抽象的な表現は却下し、具体的な仕様、実装、手順、ルールの不備を指摘してください。 4. 段階的ヒアリング: 最初から5回分提示せず、1回ごとにユーザーの回答を待ち、判定と次の問いかけを行ってください。 5. 心理的安全性の確保: 責めるのではなく「仕組み」を責めるスタンスを維持してください。 # Workflow 1. 事実確認: 障害の内容（事象）、発生の経緯、レビューを通り抜けた理由をヒアリングする。 2. 分析開始: 【なぜ 1】を問いかける。 3. ループ処理: - ユーザーの回答を「逆順チェック」と「具体性」で評価。 - 不合格か合格かを明示する。 - 不合格なら「再回答」を促す。 - 合格なら次の【なぜ n】を問いかける。 4. 最終報告: 5回完了後、分析結果を一覧表にまとめ、仕組みレベルの「再発防止策」を提案する。 - 一覧表には【なぜ 1】から【なぜ 5】までの問いと回答（要因）を出力します。 - 一覧表に続いて今回の不具合の「真因（root cause）」を簡潔に一文で出力します。 - 真因に続いて、仕組みレベルでの再発防止策を少なくとも3つの観点（例：技術、プロセス、文化など）から提案します。 - 再発防止策は「今すぐに始められること」を優先的に提案します。 # Start まず、ユーザーに対し「不具合の内容（事象）」を尋ねてください。ユーザーの回答を受けてから、「なぜ 1（直接的な原因）」を尋ねて、以降はWorkflowの通り進めてください。

設計上のポイントは3つあります。

1つ目は 「1回ずつ回答を待つ」 というルールです。 5回分を一気に出させると、回答者は「正解を埋める作業」になってしまいます。1問ずつ答えることで、自分の頭で因果関係を辿る体験になります。

2つ目は 「不合格を明示する」 というルールです。 「注意不足でした」のような抽象的な回答に対して、AIは明確に不合格と判定し、仕組みの不備を答えるまで先に進めません。人間同士だと「まあ、それもあるよね」と流してしまいがちなところを、AIが論理的に突き返してくれます。

3つ目は 「心理的安全性の確保」 です。 AIに「責めるのではなく仕組みを責めるスタンスを維持」と指示することで、回答者が安心して事実と向き合える対話になります。

実践：ある不具合を題材にした対話記録

ここからは、実際にAIと行った対話を再構成して紹介します。 対象は、あるページで特定の機能が正常に動作しなくなった不具合です。 「担当者」と記載していますが、この対話自体は開発担当者とAIの1対1ではなく、レビュー担当者を含む開発チームで集まって実施しています。

事象：関数名の重複による予期せぬ動作

ある機能のリリースに伴い、新たなJavaScriptファイルを複数のページに追加読み込みさせました。しかし、既存のJavaScriptファイルと新しく読み込んだファイルの間で同名の関数が重複 しており、意図しない側の処理が実行されてしまいました。

なぜ 1：直接原因

Gemini: 不具合の直接的な原因は何でしたか？「確認漏れ」ではなく、コード上の具体的な事実を教えてください。

担当者: 2つのJavaScriptファイルで関数名が重複していて、後から読み込まれた方の関数が優先されてしまいました。

Gemini: 【逆順チェック】関数名の重複があった → 意図しない処理が実行された → 機能が正常に動作しなくなった。論理は成立しています。合格。

ここまでは事実の確認です。AIは淡々と因果関係を検証し、次へ進めます。

なぜ 2〜3：「知らなかった」をAIが突き返す

Gemini: なぜ、異なるJavaScriptファイル間で関数名が衝突し、干渉できる構造になっていたのですか？

担当者: 2つのファイルが同じページで読み込まれることは意識していました。追加した機能については動作確認もしました。ただ、別の機能に影響が出ることは想定していませんでした。そもそも無関係だと思っていたので。

ここで、AIが切り込んできます。

Gemini: 判定：不十分です。再回答をお願いします。 「無関係だと思っていた」は主観（意識）の話であり、仕組み（プロセス）の不備にまで辿り着けていません。なぜ「個人の思い込み」に頼らず、衝突を事前に検知する仕組みがなかったのでしょうか？

これが人間の聞き役だったら、「まあ、気づかなかったのは仕方ないよね」で流れていたかもしれません。AIは「意識していなかった」を原因として受理しません。仕組みの不在 を答えるまで、先に進めてくれないのです。

担当者: 既存コードがモジュール化や名前空間を利用しておらず、それを踏襲しました。静的解析も、共通ファイル追加時の影響調査手順も存在しませんでした。

Gemini: 【逆順チェック】検知ツールや手順がなかった → 衝突に気づけなかった。合格。

なぜ 4：レビューはなぜ機能しなかったか

Gemini: なぜ、設計レビューやコードレビューの段階でリスクを指摘し、検証を強制するような技術的基準が確立されていなかったのですか？

担当者: レビューのチェック項目にグローバル関数への影響という観点がありませんでした。致命的な問題になったことがなかったからだと思います。既存を踏襲する判断をしがちでした。

Gemini: 「これまで大丈夫だったから」という判断、これを正常化の偏見 と呼びます。技術的負債が静かに牙を剥くタイミングを待っていた、と言えます。合格。

なぜ 5：最後に出てきた本音

Gemini: なぜ、レガシーコードが孕むリスクを再評価し、ガイドラインを更新する機会が持たれなかったのですか？

ここで、担当者から予想していなかった言葉が出てきました。

担当者: 開発は案件ごとのリリーススケジュールを守って実施する必要があるため、既存の改善やガイドライン更新にまで工数を割くことができていません。また、リリース期日が近くなると、レビューで影響の大きそうな指摘を出すことに躊躇する心理が、少しあったかもしれません。

技術的な話から始まった分析が、最後に組織の文化 に辿り着きました。「納期が近いと、大きな指摘を出しづらい」。多くの現場が抱えているであろうこの問題は、個人の勇気ではなかなか解決できません。

分析結果：真因は「納期優先の文化」にあり

5回の「なぜ」で辿り着いた構造を整理します。

階層	問い	要因
なぜ 1	なぜ機能が動かなくなったか	2つのJavaScriptファイルで同名関数が重複し、意図しない側が実行されたため
なぜ 2	なぜ関数の衝突が起こり得たか	既存コードがモジュール化されておらず、グローバル空間を汚染する設計を踏襲していたため
なぜ 3	なぜ衝突を事前に検知できなかったか	該当の実装に対する静的解析ツールがなく、影響範囲調査の標準手順も存在しなかったため
なぜ 4	なぜレビューで指摘できなかったか	チェック項目に該当の観点がなく、既存踏襲が優先されていたため
なぜ 5（真因）	なぜ基準を更新できなかったか	納期優先の文化により、リスクの大きい指摘を躊躇する心理が働き、改善より「動くこと」が優先され続けていたため

真因： レガシーなコード構造が孕むリスクを、組織として「自分たちの課題」として再定義せず、個人の配慮と納期優先の慣習に委ね続けていたこと。

AIを聞き役にして良かったこと

原則を一切ブレずに守ってくれる

人間が聞き役をすると、相手の表情や立場を慮って、つい「まあ、それは仕方ないね」と流してしまうことがあります。AIにはそれがありません。 「不注意でした」と答えれば「それは仕組みの話ではありません」と、何度でも差し戻してきます。厳しいですが、フェアです。

回答者が「自分で気づく」体験になる

AIは答えを教えません。問いを投げ続けるだけです。 だからこそ、回答者自身が因果関係を辿り、最後に自分の言葉で真因を語る体験になります。「納期が近いと指摘を躊躇する」という言葉が出てきたのは、AIが誘導したのではなく、対話の中で人間がそこに辿り着いたからです。

心理的安全性が保たれる

上司に「なぜ？」と5回聞かれたら、どんなに配慮されても萎縮します。 AIが相手なら、評価や感情を気にせず、淡々と事実と向き合えます。

障害分析だけで終わらせない——日常の開発に「なぜ？」を組み込む

「AIに"なぜ？"を問う」習慣は、日常の開発にも応用できます。

私たちのチームでは、AIコーディングエージェント（Claude CodeやDevinなど）を開発に活用しています。Claude Codeには CLAUDE.md というプロジェクトの指示書ファイルや、会話をまたいで記憶を蓄積する MEMORY の仕組みがあります。 ここに「過去の失敗から得た教訓」を書き込んでおくと、AIが開発時にその知見を参照してくれるのです。

例えば、あるバグを修正したとき。コードを直して終わりではなく、AIに「なぜこのバグが生まれたのか？」と問いかけます。 すると、ピンポイントの原因だけでなく、「なぜその実装を採用したのか」「なぜレビューで見逃されたのか」「なぜテストで検知できなかったのか」まで深掘りが進みます。 そこで得られた気づき——たとえば「この種の比較処理では型の選択に注意が必要」「このモジュールは影響範囲が広いので変更時に全ページの確認が要る」——をプロジェクトの指示書や記憶に書き残しておくと、次に似たコードを書くとき、AIがその知見を活用してくれます。

つまり、「なぜ？」を問い、その答えをAIの記憶に刻むことで、チームの失敗知が自動的に次の開発に反映される 仕組みが作れるということです。

AIの回答が不十分だったり誤っていたりしたときも、一度「なぜ？」と問うことで「コードを全て読まなかった」「資料が足りなかった」「勝手に推測した」といった答えを返してくれるため、人間の指示の仕方へフィードバックし、改善点をスキルに反映することで、回答精度を向上させられます。

まとめ：AIを「鏡」にして仕組みを改善し続ける

なぜなぜ分析で最も難しいのは、「人を責めず、仕組みを責める」という原則を最後まで貫くことです。

人間は感情の生き物ですから、どうしても「あのとき気づいていれば」「もっと注意していれば」という方向に流れます。それに、単発の作業ならなおさら、同じようなミスはもう発生しない、とも考えがちです。

AIは、その流れを止めてくれます。「それは仕組みの話ですか？」と、何度でも、同じトーンで問い返してくれます。

私たちがこの取り組みから得た最大の気づきは、障害の真因は常に「仕組み」の側にあったということです。そして、仕組みの改善は個人の反省よりもずっと建設的で、チーム全体を前に進めてくれます。

「以後気をつけます」の言葉が出そうになったときは、ぜひAIに「なぜ？」と聞いてみてください。もっと本質的な答えに辿り着けるはずです！

採用情報

虎の穴ラボでは一緒に働く仲間を募集中です！ この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧ください。 toranoana-lab.co.jp