2026年5月18日：AI時代のハインリッヒの法則と「静かなるミス」

「1：29：300」。

失敗学や安全管理の世界で有名な「ハインリッヒの法則」だ。 1つの重大事故の背後には29の軽微な事故があり、そのさらに下には300の「ヒヤリハット」が存在する。

システム開発を長くやっていると、この数字の意味を嫌というほど理解する。本番障害という「1」は、ある日突然空から降ってくるわけじゃない。大抵は、その前に大量の小さな違和感がある。

ログの警告。レビュー時の「まあいいか」。仕様の読み違い。テストケース漏れ。

そういう小さなノイズが積み重なって、最後に事故になる。

だからこそ、我々はCI/CDを整備し、自動テストを書き、レビューを標準化し、「人間の不注意」を仕組みで潰そうとしてきた。

しかし最近、少し感覚が変わってきた。

AIが、これまでとは違う種類の「300」を大量生産し始めている。

AIは、とにかく速い。

コードを書く。設計書を作る。 SQLを書く。テストコードを書く。リファクタリングもする。

昔なら数日かかっていた作業を数分で終わらせる。

ただ、その代償として、「ほぼ正しいミス」を大量に混ぜてくる。

これが厄介だ。

昔の新人のコードは、見れば明らかに変だった。コンパイルも通らないし、設計も崩壊している。

でもAIのミスは違う。

動く。テストも一部通る。コードもそれっぽい。コメントも丁寧。

しかし、よく見ると境界条件が抜けていたり、認証の考慮が甘かったり、ライブラリの仕様を微妙に誤解していたりする。

しかも、最近はその「微妙な間違い」の密度が異様に高い。

AIによって開発速度が上がった結果、人間側のレビュー能力が追いつかなくなり始めている。

最近の海外記事でも、同じような話がかなり増えてきた。

AIによるコード生成が普及したことで、逆にCI/CDやレビュー工程の重要性が上がっている、という話だ。 (note（ノート）)

特に面白かったのが、「AI時代はコードを書く速度ではなく、“AIがばら撒いたノイズを除去する能力” が競争力になる」という指摘。

これはかなり本質的だと思う。

実際、今のトレンドは「AIに全部やらせる」ではなく、「AIを監視するAI」を作る方向に進み始めている。

例えば最近よく見るのは、こんなアプローチ。

1. LLMによるコードレビューの二重化

生成AIとは別のモデルにレビューさせる。

「コードを書くAI」と「疑うAI」を分離する発想。

しかも最近は、レビュー時にPRコメントや説明文を隠す研究まで出てきている。理由は、人間と同じでAIも「これは安全な変更です」と書かれると騙されやすいから。 (arXiv)

これ、かなり人間っぽくて面白い。

2. “LLM-as-Judge” という考え方

AIの出力を別AIが採点する。

最近は「LLM-as-Judge」という言葉をよく見る。

hallucination（もっともらしい嘘）検知専用の仕組みで、「このレビューコメント、本当にコード根拠ある？」を検査する研究も進んでいる。 (arXiv)

昔の静的解析ツールに近いが、対象が「自然言語」になった感じ。

3. ガードレール前提の設計

最近のAI開発では、「AIは必ず間違える」が前提になり始めている。

なので、

権限を制限する
本番操作は禁止
危険操作は必ず人間承認
外部通信を制限
依存パッケージを検証
Sandbox内だけで動かす

みたいな「壊れても致命傷にならない設計」が重視されている。 (DEV Community)

要するに、“賢さ” ではなく “暴走前提の設計” に思想が変わってきている。

あと個人的にかなり重要だと思っているのが、「本番観測」の比重が増えていること。

AIはコード単体だとかなり優秀に見える。でも、本当に危険なのは「本番環境で何をしたか」。

最近は「コードレビューよりRuntime監視の方が重要になる」という話も増えている。 (LinkedIn)

これは、昔の「静的解析だけでは障害は防げない」に少し似ている。

結局、本番での振る舞いを見るしかない。

便利になった。

それは間違いない。

でも最近、「AIで効率化された開発現場」は、同時に「AI由来の微細なミスが常時注入され続ける環境」でもあると感じる。

しかも怖いのは、そのミスが静かすぎることだ。

コンパイルエラーのように叫ばない。クラッシュもしない。ただ、静かに潜伏する。

昔の「300」は人間の疲労や不注意だった。今の「300」は、“高速化された正しそうなノイズ” なのかもしれない。

AI時代のエンジニアリングって、結局は「生成能力」より「検知能力」の勝負になっていくのだろうな、と最近よく思う。