AIによるリスク先読み：「マーフィーの法則」をハックする
はじめに
「デプロイに限ってDBのマイグレーションを忘れる」
「重要なデモの直前に限ってステージング環境が落ちる」
「『この修正は影響範囲小さいです』というPRに限って、思わぬバグを生む」
エンジニアなら一度は経験する、こんな「あるある」。
もはや笑い話で済ませていますが、これらはただの不運ではなく、かの有名なマーフィーの法則が働いているのかもしれません。
そもそも「マーフィーの法則」って？
若い世代には少し馴染みが薄いかもしれませんが、日本でも書籍が大ヒットした経験則です。「起こってほしくないことは、なぜか必ず起こる」という、あの感覚を体系化したもの、と言えば分かりやすいでしょうか。
有名な例をいくつかご紹介します。
- バターを塗ったトーストは、必ずバターを塗った面を下にして落ちる
- 急いでいる時に限って、信号がすべて赤になる
- スーパーのレジは、隣の列の方が必ず早く進む
これらは科学的根拠のないジンクスですが、多くの人が「あるある」と頷いてしまう不思議な説得力があります。
この法則の起源は1949年、米空軍のエンジニア、エドワード・A・マーフィー Jr.の発言がきっかけとされ、後に「If anything can go wrong, it will.（失敗する可能性があるなら必ず失敗する）」という形で広まりました。
その本質は 「人間は必ずミスをする。だからこそ、ミスの余地を残さないフェイルセーフな思想が不可欠だ」 という、我々エンジニアにとって非常に重要な教訓なのです。
法則を逆手に取り、AIで「未来のリスク」を炙り出す
では、私たちは「どうせ失敗するのだから」と、この法則にただ甘んじるしかないのでしょうか。いいえ、違います。
かつてはベテランの経験と勘、あるいは膨大なチェックリストによって、この「起こりうる失敗」に立ち向かってきました。しかし現代において、私たちにはAIという強力な武器があります。
AIを使えば、この法則をネガティブなジンクスとして恐れるのではなく、 「システムやプロセスに潜む弱点をあぶり出すための、優秀な診断ツール」 として活用し、法則を逆手に取り、「どうせ起きる失敗」をAIに予測させ、先回りして対策を打てるのではないでしょうか。
ここから、AIを使ってマーフィーの法則をハックするための具体的な5つのアイデアを紹介します。
- 1. Jira/GitHubのデータで「組織の失敗パターン」を抽出する
- 2. 皮肉屋AIで「プロジェクトのリスク」を強制可視化する
- 3. AIで「実用的な逆引きチェックリスト」を作成する
- 4. ベテランエンジニアAIと「コードレビュー壁打ち」を行う
- 5. AIに「失敗した未来」のプリモーテムレポートを作成させる
各活用法に、コピーしてすぐに使えるプロンプト例と、AIによる出力例を添えました。
1. Jira/GitHubのデータで「組織の失敗パターン」を抽出する
「AIに学習させる」と言うと大袈裟に聞こえますが、要は 「生データをAIに食わせて、パターンを分析させる」 だけです。完全自動化は大変ですが、手動なら10分でできます。
実践方法:
直近3ヶ月分のJiraのバグチケットや、GitHubの revert / hotfix commit のタイトルを50件ほどリストアップし、以下のプロンプトに貼り付けます。
プロンプト例:
あなたは、長年の経験を持つシニアな品質保証（QA）エンジニアです。
以下のリストは、私たちのチームが直近3ヶ月で対応したバグチケットのタイトルです。
これらのデータから、「マーフィーの法則」と言えるような、私たちのチームに特有の「繰り返される失敗パターン」や「特定条件下で必ず発生する問題」を3〜5個、具体的な根拠と共に分析・抽出してください。
# 分析対象データ
- [バグチケットのタイトルをここに貼り付け]
- (例) 「決済処理のタイムアウトエラー（月末のバッチ処理と競合）」
- (例) 「新商品の画像が表示されない（CDNのキャッシュ更新漏れ）」
- (例) 「特定のAPIからのレスポンスがnilになりクラッシュ（外部APIの仕様変更追随漏れ）」
- ...
AIによる出力例:
分析した結果、貴チームには以下の様な「マーフィーの法則」的パターンが見受けられます。
- 「月末になると、必ず決済・バッチ処理周りで障害が起きる」: チケットの約20%が月末の5営業日以内に集中しています。「タイムアウト」「ロック競合」といったキーワードが多く、高負荷時のテストやリソース設計に課題がある可能性が示唆されます。
- 「外部APIの仕様変更は、必ず誰かが見落とす」: 「nilクラッシュ」「予期せぬレスポンス」といったチケットが散見されます。外部APIの変更通知をチーム内で確実に同期し、依存箇所をテストする仕組みが形骸化している可能性があります。
- 「CDNやキャッシュの更新は、必ず誰かが忘れる」: 特に静的コンテンツ（画像、CSS）の更新時にキャッシュパージ漏れによる「表示されない」系のバグが繰り返し起きています。リリース手順書に具体的な確認ステップを追加するか、自動化を検討すべきかもしれません。
2. 皮肉屋AIで「プロジェクトのリスク」を強制可視化する
通常のレビューでは見落とす、あるいは遠慮して言えない「構造的なリスク」を、AIに悪魔の代弁者を演じさせて炙り出します。
実践方法:
新しいプロジェクトの企画書や、機能の設計概要をAIに入力します。
プロンプト例:
あなたは「マーフィーの法則を熟知した、超絶皮肉屋なテックリード」です。
これから提示する計画について、「どうせ失敗する」「絶対に問題が起きる」であろう技術的・構造的な欠陥を、その理由と対策案と共に、遠慮なく皮肉を交えて指摘してください。
指摘には「確度（高/中/低）」を付け、どの記述からそう判断したか、根拠箇所を引用してください。
# 計画概要
[ここにプロジェクトの企画書や設計概要を貼り付け]
（例：顧客データを活用したレコメンドエンジンを、Pythonとサーバーレスアーキテクチャで3ヶ月で開発する計画）
AIによる出力例:
なるほど、またキラキラした計画ですね。どうせこうなる未来が見えますよ。
- 確度：高「『データが綺麗』という壮大な勘違い」: 根拠は「顧客データを活用」という一文です。そのデータ、本当に使えるんですか？どうせデータのクレンジングと前処理だけで開発期間の半分を使い果たし、「当初の目論見と違う」とか言い出すパターンでしょう。まずデータサイエンティストを巻き込んで1週間、データ品質の実現性評価だけをやるべきですね。
- 確度：中「サーバーレスの甘い罠」: 根拠は「サーバーレスアーキテクチャで」の部分。流行りだからって使えばいいものじゃないですよ。どうせローカルでのデバッグが地獄のように面倒くさくなって、開発効率がガタ落ちするに決まってます。おまけに、特定の処理でタイムアウト頻発。最初からコンテナで普通に作った方がマシだった、ってなるのがオチです。
- 確度：高「『3ヶ月』というファンタジー」: 根拠は「3ヶ月で開発する計画」です。レコメンドの精度検証、どうするんですか？まさか「作って終わり」じゃないでしょうね。ABテストの基盤もないのに、どうせ「効果が出てるかわからない」謎機能が一つ増えるだけ。リリースはゴールじゃなくてスタートだって、誰か教えてあげたらどうです？
3. AIで「実用的な逆引きチェックリスト」を作成する
「失敗は必ず起きる」という前提からスタートし、それを防ぐための具体的なチェックリストをAIに作らせます。
プロンプト例:
あなたは、障害対応とSREの経験が豊富なエンジニアです。
私たちのチームでは、リリース作業において以下の失敗が頻繁に起こります。
- DBのマイグレーションスクリプトの適用漏れ
- 環境変数の設定ミス
- ロールバック手順の不備で、障害時に戻せない
これらの「必ず起きる失敗」を前提として、これらを防ぐための、具体的で実行可能な「リリース前・最終確認チェックリスト」をテーブル形式で作成してください。
属人性を排除するため、各項目に「担当（誰が）」「証跡（どこで確認）」「自動化（はい/いいえ）」の列を必ず付けてください。
4. ベテランエンジニアAIと「コードレビュー壁打ち」を行う
自分の書いたコードに潜む「未来のバグ」の種を、ベテランエンジニアAIに指摘してもらいましょう。
プロンプト例:
あなたは、20年間インフラからアプリケーションまで見てきた、超ベテランのエンジニアです。口癖は「こういうコードは3年後に必ず問題を起こす」。
以下のコードスニペットをレビューし、マーフィーの法則に基づき、将来必ず問題を引き起こすであろう潜在的なリスクを指摘してください。
特に、設計のアンチパターン（命名規則、循環依存、設定値の分散、マジックナンバー、例外の握りつぶし等）の観点も重視してください。
# レビュー対象コード
[ここにレビューしてほしいコードを貼り付け]
（例：エラーハンドリング、設定値のハードコーディング、複雑なループ処理など）
5. AIに「失敗した未来」のプリモーテムレポートを作成させる
プロジェクトが始まる「前」に、AIに「失敗した未来」を具体的に描かせることで、先回りしてリスクを潰します。これは「プリモーテム（事前検死）」と呼ばれる手法です。
プロンプト例:
私たちは、これから「[プロジェクト名]」を開始します。
あなたは未来を見通せるリスク管理コンサルタントです。このプロジェクトが半年後、歴史的な大失敗に終わったと仮定し、その顛末を記述する「プロジェクト失敗報告書（プリモーテム・レポート）」を作成してください。
報告書には以下の要素を含めてください。
- **失敗の概要**: プロジェクトがどのように失敗したか
- **失敗に至ったタイムライン**: 重要な意思決定ミスや見落としの時系列
- **根本原因**: 技術、チーム体制、コミュニケーションなど、失敗の真因
- **失敗を象徴するKPIの変化**: (例: MTTR / 重大インシデント件数 / ロールバック率 / リリース前検出率)
- **教訓**: 本来どうすべきだったか
現実的な制約と注意点
もちろん、AIは銀の弾丸ではありません。
安全かつ効果的にAIを「武器」として使うために、以下の3つの点をぜひ意識してください。
1. セキュリティとプライバシー：会社の機密情報は絶対に貼り付けない
これが最も重要です。「便利だから」と、うっかり会社のソースコードや顧客データ、未公開のAPI仕様書などをパブリックなAIサービスに入力してしまうのが、まさに新たなマーフィーの法則です。
- NGな例: 生のソースコード、顧客データ、社外秘の設計書
-
OKな例: データを抽象化・匿名化する、変数名を
user_idのような一般的な名前に置き換える、処理のロジックのみを抜き出して質問する
セキュリティが担保された法人向けプラン（ChatGPT Enterprise, Claude Businessなど）の利用も、必ず検討しましょう。
2. AIの出力は鵜呑みにしない：最終判断は必ず人間が
AIは、驚くほどもっともらしい嘘（ハルシネーション）をつくことがあります。特に「皮肉屋テックリード」のようなペルソナを与えると、自信満々に、しかし微妙に間違った指摘をしてくることもあります。
AIはあくまで 「優秀な壁打ち相手」 であり、 「最終責任者」 ではありません。AIの指摘は思考のきっかけとして活用し、技術的な妥当性の最終判断は、必ずあなた自身とチームで行ってください。
3. インプットの質と量がすべて：コンテキストを伝えきる
AIは、与えられた情報（コンテキスト）の中からしか答えを見つけられません。「 Garbage In, Garbage Out」の原則は、AI相手にこそ強く働きます。
コードの一部だけを渡して「レビューして」と頼んでも、プロジェクト全体の設計思想やビジネス上の制約を知らないため、的外れな回答になりがちです。質の高いフィードバックを引き出すには、 「このプロジェクトの目的は〇〇で、技術スタックは△△です」 といった背景情報を、可能な範囲で（もちろん機密情報を除いて）提供することが極めて重要です。
まとめ
マーフィーの法則は、ただのネガティブなジンクスではありません。AIという強力な壁打ち相手を得た今、それは 「システムの弱点を教えてくれる優秀な診断ツール」 に変わります。
今回紹介したプロンプトは、あくまで出発点です。ぜひ皆さんのチームやプロジェクトに合わせてカスタマイズし、"転ばぬ先の杖"として活用してみてください。
この記事を読んだことで、「対策を打った時に限って、新たな問題が起きる」という法則が発動しないことを祈るばかりです。
Discussion