【AIの恐怖】15本の異なるコードが「全く同じバグ」を埋め込む？LLMが共有する『相関的死角』を異種AI監査で暴いたハッカー精神溢れる大検証

【事象の全貌と背景】

AIによるコード自動生成は、CursorやGitHub Copilot、そしてClaudeやGPTの進化によって「書けないコードはない」と思わせるほどの領域に達しています。開発者が自然言語で指示を出し、AIが即座にコードを書き下す。一見すると完璧なこのワークフローの裏で、今、極めて静かで、かつ破壊的な脆弱性がソフトウェア業界を震撼させています。それが「相関的死角（Correlation Blindspot）」と呼ばれる現象です。

これまで、AI生成コードの不具合は、開発者がコードの意味を理解せずにマージしてしまう「Vibe Coding（雰囲気開発）」や、生成された低品質なコードが積み重なる「Workslop（ワークスロップ）」といった、主に人間側のモラルやプロセスの問題として片付けられてきました。しかし、2026年6月に浮上したあるエンジニアによる大検証は、問題が「AI自体の本質的な統計的限界」にあることを白日の下に晒しました。

その検証とは、同一の厳密な仕様書から、異なるプロンプト、異なるアプローチ、さらには異なるモデルを用いて生成された「15本の独立したスクリプト」を詳細に監査するというものです。驚くべきことに、これらの異なる15本のコードは、統計的なバイアスによって「全く同じ死角」に陥り、同一のサイレントバグを寸分違わず埋め込んでいました。さらに恐怖をあおる事実として、このコードを生成した本人であるAIにセルフレビュー（自己コード監査）をさせても、テストをパスしたことのみを根拠に「問題なし」と太鼓判を押してしまったのです。この人間に見えない、そしてAI自身にも見えない「統計的死角」はいかにして生まれ、どのようにして暴かれたのでしょうか。

【技術的ディープダイブ】

「相関的死角」が発生する技術的メカニズムは、LLMの「トークン予測における確率的収束」に起因します。LLMは、膨大なオープンソースコードやWeb上のテキストを学習した統計的モデルであり、特定のコンテキストに対して「最もありそう（Highly Probable）」なトークン列を返します。この「確率的に最も美しいイディオム」を選択するという性質こそが、同時に「確率的に最も見落とされやすい盲点」を固定化させる罠となるのです。

実際に検証された具体的な事例を見てみましょう。TypeScriptにおけるAPIエンドポイントのインプットバリデーションの実装において、仕様書には「空文字列（””）の入力を厳格に禁止する」という要件が明記されていました。しかし、AIが生成した15本のスクリプトは、異なるライブラリ（Zod、Yup、あるいはネイティブの条件分岐など）を使用していたにもかかわらず、そのすべてが「空文字列をサイレントに通過させてしまう」という共通のセキュリティホールを抱えていました。JavaScript/TypeScriptにおいて、よく使われるイディオムである `if (!input)` や、特定のスキーマ定義の暗黙のデフォルト挙動に引きずられ、LLMは「統計的に最も頻出するパターン」を記述した結果、特定の境界値条件のテストをすべてのバリエーションにおいて漏洩させたのです。

さらに致命的なのが「相関的自己監査の崩壊」です。コードを書いた同一系統のLLMにその差分（diff）を渡し、「このコードに仕様漏れやバグがないか監査してください」と指示しても、AIは自信満々に承認（Approve）を与えます。なぜなら、レビューを担当するAIモデルも、コードを生成したモデルと同じ「統計的確率分布（バイアス）」を共有しているため、同じコードを「正しい、美しい」と認識する認知の死角までもが相関してしまうからです。テストコード自体もAIに書かせていた場合、そのテストスイートすら同じ死角を前提に構築されるため、カバレッジ100%を維持しながら致命的なバグが本番環境へデプロイされるという最悪のシナリオが完成します。

このハッカー精神あふれる大検証を行った開発者は、この膠着状態を打破するために「ヘテロジニアス・オーディット（異種AI監査）」を導入しました。生成側のLLMとは全く異なる強化学習アルゴリズムや、ルールベースの静的解析器、さらには内部構造が異なる他社製LLMを組み合わせた「マルチアングル・ピア・レビュー」を実行。これにより、15本のスクリプトすべてが共通して抱えていた「相関的死角」を瞬時にあぶり出すことに成功しました。統計の歪みを、別の統計の歪みで相殺するという、極めてハッカー的なアプローチがこの発見を可能にしたのです。

【コミュニティの生々しい熱量と議論】

この検証結果がRedditやDEV Communityにポストされるや否や、世界中のシニアエンジニアたちから悲鳴混じりの共感が殺到しました。DEV Communityの人気投稿「I stopped letting AI review its own code（AIに自身のコードをレビューさせるのをやめた）」では、数多くの実務家が「全く同じ体験をした」と告白しています。「ClaudeにTypeScriptのAPIバリデーションを書かせ、自分でレビューさせたら承認したのに、2日後に同僚から空文字が通る脆弱性を指摘された。AIによる自己承認は完全なオナニーだった」というリアルな怒りの声には、多くの賛同（Upvote）が寄せられています。

コミュニティでの議論は、「テスト、実装、レビューをすべて単一のAI（あるいは同じプロバイダーのAI）に依存することの危険性」に集中しています。「これは単なるWorkslop（ずさんなコード）の問題ではない。統計モデルが本質的に持つ『共通の盲点』による集団思考（Groupthink）だ」と指摘する声や、「開発速度が10倍になったと喜んでいる裏で、チーム全体が『AIが作った完璧に見えるが同じ箇所で必ず壊れる砂の城』をビルドしている」という警鐘も鳴らされています。

一方で、この相関的死角をクラッキング、あるいは回避するための「変態的ハック」も次々と提案されています。その一つが、LLMに実装コードを生成させる際、あえてプロンプトで「この言語のジュニア開発者が最も犯しやすい10の致命的なバグと、その裏に潜む暗黙の言語仕様をリストアップした上で、それらを意図的に破壊・回避する防衛的コードを書け」と指示する「ネガティブ・スペース・プロンプティング（消極空間プロンプト）」です。また、生成AI（Generator）と対立するテストAI（Validator）の2つのエージェントに、それぞれ完全に異なるシステムプロンプトと、異なる量子化モデルを適用して競わせる「二重盲検マルチエージェントCI」をローカル環境で自作するエンジニアも現れており、AI時代の品質管理手法は急速に武装化しています。

【今後の展望とエコシステムへの影響】

「相関的死角」の実証は、今後のAI駆動型開発（AI-driven development）のエコシステムに決定的な一石を投じることになります。まず、「AIが生成したコードを、AI自身（または同じモデルのファミリー）にレビューさせる」という安易なセキュリティ・ワークフローは完全にオワコン化するでしょう。今後、エンタープライズ向けのCI/CDツールや開発環境（IDE）は、決定論的な静的解析器（LinterやASTパーサー）と、生成側とは「異なる系統」のAI監査エンジンを並列で走らせる二重・三重のセキュリティ構造の義務化へと舵を切らざるを得なくなります。

さらに、この問題は「異種混合（Heterogeneous）AIツール」の需要を劇的に高めます。例えば、プログラミング開発にClaudeを使用しているなら、コードレビューや脆弱性スキャンにはOpenAIの推論モデルや、セキュリティ特化型のローカルLLMを配置するというように、モデルの「マルチベンダー化」が品質担保の標準レイヤーとなります。これは、特定の巨大AI企業による開発パイプラインの独占に対する強力なカウンターとなるでしょう。

統計的な「確率」に依存してコードを書く時代だからこそ、その確率の裏側に潜む「相関的な盲点」をいかにして疑い、決定論的なルールや異種の知性で補うか。ハッカーたちが示したこの検証は、AIに使われる側からAIを飼い慣らす側へとエンジニアが立ち上がるための、極めて実践的な教訓に満ちています。