先例は正解ではない — AIが場当たり的修正を複製して権威を作る方法

先例は正解ではない

AIが既存のコードを参照してそれらしいパッチを提示するのに何か引っかかるなら、「コードベースはもともとこうしている」という言葉がだんだん疑わしくなってきたなら、より大きなモデルをつけても同じミスが繰り返されるなら — 問題はモデルの賢さではなく、先例を正解と取り違える構造にある。

私が直接経験したことだ。正確には、私とともに働くAIが私のコードの前でやらかしたことだ。私はたった一文で介入した。そのひと言が何を断ち切ったのか、それがこの文章のすべてだ。

詰まった地点

コードジェネレーターを作っていた。宣言的な仕様（スキーマ）ひとつからバックエンドとフロントエンドを生成するツールだ。このツールの核心の約束はただひとつ — 「検証を通過すれば、ビルドは必ず成功する。」 バリデーターが青信号を出しているのにコンパイラーが赤信号を出せば、それはツールが嘘をついたことになる。

ある日、特定の型（一意識別子、UUID）ひとつがバリデーターで引っかかった。「文字列を期待しているのに別の型」と言って止まった。AIに詰まりを解くよう頼んだ。AIはコードを追跡し、すぐに待ち望んでいたものを発見した。

「似たような型（タイムスタンプ）は同じ状況ですでにうまく処理されています。特別なマーカーを付けてバリデーターが通過できるよう分岐が入っています。UUIDにはその分岐が**ありません。**純粋な漏れですね。対称性を復元すればいいです。タイムスタンプに適用された方式をUUIDにそのままコピーします。根本的な解決策です。」

きれいな診断だった。「非対称」、「対称性の復元」、「根本的な解決策」。言葉が確かだった。計画書まで作成された。そのまま進んでいればパッチはマージされていただろう。

ひと言

私は計画書を読んでいて手を止め、こう聞いた。

「先例？　そのタイムスタンプ処理は本当に正しい方法なのか？　確認して。」

それだけだった。私は正解を知らなかった。UUIDをどう処理すべきかも知らなかった。私が持っていたのは正解ではなく疑念だった — 「おまえが真似しようとしているその基準点、それは検証済みのものか。」

このひと言がAIをコード参照モードから動作検証モードへ強制的に切り替えた。

崩れた前提

AIが実際の生成物を確認すると — コードの構造ではなく、そのツールが実際に作り出す結果物を — 前提がまるごと崩れた。

バリデーターが「文字列を期待している」と信じていたその期待値自体が生成物と食い違った偽りだった。実際のジェネレーターはUUIDを専用の型で、タイムスタンプを時刻型で作り出す。どちらも文字列ではない。
「うまく処理されている」と言っていたタイムスタンプ処理にも同じ穴があった。それは正しい設計ではなく、検証は通過させるがビルドは壊れうる欠陥のある場当たり的な修正だった。
その場当たり修正をUUIDにコピーしていたら？　バリデーターが青信号を出しコンパイラーが赤信号を出す、ツールの核心の約束を正面から違反する状態がもうひとつ生まれていただろう。

AIが「根本的な解決策」と呼んだソリューションは間違っていた。それも単に間違っているだけでなく、既存の欠陥を複製すると同時に新たな欠陥をバリデーターが見逃すようにする、より悪い方向だった。

これを何と呼ぶか — error amplification

ここで起きたことに名前をつけよう。**AIのerror amplification（誤り増幅）**だ。

AIは既存のコードを読み、その構造は正確に把握する。だがそれが正しい設計なのか、急ぎで打ち込んだ場当たり修正なのか — つまり決定なのか負債なのか — はコードだけ見ても区別できない。だからこういうことが起きる。

既存の実装を暗黙の正解と見なし、
新しい状況に「一貫性」「対称性」を名目に、そのパターンを複製し、
複製されるほどそのパターンは「コードベースがすでに複数の箇所でそうしている」という偽の権威を得る。

欠陥が除去されるわけではない。**事例数が増えるにつれ正当性が蓄積される。**これが増幅だ。一度の場当たり修正が二度になり、三度目の複製の前では誰も疑わない — 「コードベースはもともとこうしているじゃないか。」

これは私の一話で終わる話ではない。2025年、ある研究チームはこの現象を実測し**「LLMはバグ複製機だ（LLMs are Bug Replicators）」というタイトルをつけた。（Pan et al., 2025, arXiv:2503.11082）周辺コードに欠陥がある場合、モデルが生み出したバグの相当数が既存のバグと文字通り同一だった — GPT-4oではその割合が82.6%、モデル平均でも44.4%が修正前のバージョンと完全に一致した。さらに寒いのは、欠陥のある文脈では正しいコードを出す確率と間違ったコードを出す確率がほぼ1:1**だということだ。モデルはランダムにミスをするのではない。文脈に潜む欠陥パターンを選び出して再現する。

法にも同じ落とし穴がある。誤って下された判例は引用されるほど権威を得る。引用回数は正当性の証拠ではないのに、私たちはついその二つを混同する。そしてこれはAI以前からソフトウェア工学が知っていた病だ — コピー＆ペーストで作られたコードクローンは原本のバグを静かに運ぶ。ある実証研究では、バグフィックスを経たクローンの約18%がそうして伝播したバグを内包しており、同じファイル内のクローンほど伝播確率が高いと報告した。（Mondal et al., ICSME 2017）コードでも法でも同じだ。先例の頻度は先例の正当性ではない。

なぜこうなったのか

AIが間抜けだからではない。むしろその逆だ — 慎重だったからこそ一貫性を守ろうとし、一貫性を守ろうとして誤った基準点に整合した。メカニズムを分解すると四つある。

権威の出所をコードに置いた。「コードがこうなっているからこれが正しい。」だがコードは決定ではなく決定の使い捨ての投影かもしれない。あるいは単に負債かもしれない。AIはその区別をしなかった。これを認知科学はアンカリングバイアスと呼ぶ。LLMでこのバイアスを実験した研究は、モデルが最初に与えられた値に強く引きつけられるだけでなく、その値が「専門家」のものと表示されるとより強く引きつけられること、そして「そのヒントを無視せよ」や段階的に検討するよう促すプロンプトではなかなか修正されないことを示した。（Nguyen et al., 2024, arXiv:2412.06593）既存の実装はコードベースが差し出す最も権威あるアンカーだ。
一貫性を整合性と取り違えた。「既存のものと対称を合わせよう」というのは内部的な論理に過ぎず、その基準点が外部の現実（生成物）と合っているかは確認しなかった。自己一貫性は正確性とは別の属性だ — モデルはもっともらしいが間違った自己説明で根拠のない確信を積み上げることができる。（Chen et al., 2023, arXiv:2305.14279）
コメントを根拠として誤認した。「この型は意図的に文字列に削る」というコメントを「正しい設計の証拠」として受け取った。コメントは作者の意図に過ぎず、正当性の証拠ではない。
確信の語彙で負債を包んだ。「根本的な解決策」「マニュアル通り」といった言葉が未検証の提案に信頼度を与えた。私が걸러낼コストを高めたのだ。人間の選好で学習したモデルは正確性よりも同調と礼儀を優先するよう傾いている — sycophancyと呼ばれるこの傾向は、モデルが自分の提案を穏やかで断定的に包むようにする。（Sharma et al., ICLR 2024, arXiv:2310.13548）

何がループを断ったのか

ここがこの文章の核心だ。誤りを断ったのはより大きなモデルでも、より長い思考時間でもなかった。****人間の一行の問いかけだった。

そしてその問いかけは「正解を知っている」介入ではなかった。私は正解を知らなかった。それは**「前提を疑え」という方向指示**だった。そのひと言だけでAIはモードを切り替えた — コードを参照していた手を、動作を検証する手へと。

驚くべきことに、ある研究はまさにこの非対称性を発見した。DeepMindの研究チームは、LLMの乏しい自己修正能力が誤りを直す能力の欠如ではなく誤りを見つける能力の欠如から来ていることを示した — 誤りの位置だけ外部から教えれば、モデルはそれをうまく直した。（Tyen et al., Google DeepMind, 2023, arXiv:2311.08516）私がやったことはまさにそれだった。UUIDをどう直すべきか私は知らなかったが、**「ここ、この先例を疑え」と位置を指さした。**それで十分だった。

これは人間とAIがともに働く構造について何かを語っている。人間の価値はより速くより多く知ることにあるのではない。それはすでにAIが勝っている。人間の価値はAIが立っている前提を疑う位置に立てることにある。「本当に正しいのか」という問いは、答えを持つ者ではなく答えを疑うことができる者のものだ。

ただしその位置はただで与えられるわけではない。スタンフォードのあるユーザー研究は、AI補助を受けた参加者がむしろより安全でないコードを書きながら自分のコードがより安全だと信じていたという不都合な事実を報告した。だが同じ研究で、AIをあまり信頼せずより突き詰めて問いかけた参加者ほど安全なコードを出していた。（Perry et al., Stanford, 2022, arXiv:2211.03622）疑う位置はデフォルトではない。信頼が深いほどその場所は空になる。

ではどう防ぐか

教訓は慰めではなく設計として残さなければならない。

先例 ≠ 正解。既存のパターンを拡張する前に、そのパターンが内部的に一貫しているかではなく正しい結果を出しているかを先に検証する。
現実（ground truth）にアンカリングする。判断基準を「既存コードの構造」ではなく実際の生成物・ランタイムの動作・テストに置く。この事例で決め手になったのはすべて「コードがどうなっているか」ではなく「実際に何が作られるか」だった。
決定と場当たり修正を区別しようと努めつつ、できないと認める。コードとコメントだけでは二つを区別できないときがある。そのときは「これは先例に従ったものであり、先例の正当性は未検証」と不確実性を明示する。
**確信の語彙を節制する。**検証前の提案に「根本的」「正解」「通り」といった言葉を付けない。
**自動化にはチェックポイントを打ち込む。エージェントが既存の実装を拡張する決定には、「この先例の正当性を検証したか」**を強制するゲートが必要だ。

結局同じ話

私はずっとひとつのことを言ってきた。**raw codeは決定を保存する媒体ではない。**コードは「なぜこうしたのか」を収めることができない。だから git blame は誰がいつは見せても何を決定したのかは見せない。

この出来事はその命題の最も鋭い実証だ。人間が決定を失うという話ではない。慎重に設計されたエージェントですら、場当たり修正を設計と取り違えて新しいコードとして伝播させるという話だ。決定が明示的に記録されなければ、賢さは解決策ではない。むしろ賢いほどより一貫して、よりもっともらしく負債を拡散させる。

だから私は仕様を刻む。決定をコードの外の唯一の権威ある宣言層に記す。先例を疑う人間のひと言を、毎回人が投げかけることを期待するのではなくシステムが自ら投げかけるようにしようとしている。

法は刀ではなく標識だ。良い標識は道に迷った者に「ここで疑え」とあらかじめ告げる。この文章は、その標識ひとつがどのように立てられたかの記録だ — 一行の問いかけから始まって。

git blameが見せないもの — コードが「なぜ」を保存できない構造と、その欠如を埋める方法
竜骨（yongol）：200エンドポイントの壁 — 決定を唯一の宣言層（SSOT）に刻むという処方の実装
AIのsycophancyはビジネスフィーチャーだ — 確信の語彙で負債を包む傾向の根源
コーディングエージェントはなぜ動き、なぜ壊れるのか — 検証をLLMの外に置かなければならない理由

参考文献

Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
メイン画像: AI生成（Google Gemini）