Shuichiro Ogawa
English

ノート · updated 2026-09-27

AI のレビューと修正のループは、なぜ 10 円専用の投入口を作ってしまうのか

AI にレビューさせ、別の AI に直させるループでは、本質的でない指摘に「指摘は妥当です」と応じて、使われない機能を積み増すことがある。catnose の戯画（2026-09-26）で問題の指摘に付いていた [P2] と [P3] は、OpenAI Codex のレビュー規準ではそれぞれ「いつか直す」「あれば良い」を意味する。

目次（10）
  1. 投入口が広がっていく
  2. [P2] と [P3] は、急がないという意味だった
  3. 「指摘は妥当です」はどこから来るか
  4. ループを回せば直るわけではない
  5. T1v ベンダー一次：レビュー側で絞り、修正側で抑える
  6. T2 公的機関と調査：人間を最後の判断者に置く
  7. T3 個人私見：指揮者を譲らない
  8. 2026 年時点で組み立てられる作法
  9. 直近の主要アップデート（時系列）
  10. 信頼度の読み方

投入口が広がっていく

2026-09-26、catnose が X にこう書いた。

レビュー「[P2] 10円玉50枚でコーヒーを買うケースが想定されていません」 AI「指摘は妥当です。50枚同時に入れられる10円専用投入口を用意します」 レビュー「[P3] 1円玉500枚で買うユーザーがいる可能性もあります」 AI「指摘は妥当です。コイン投入口を10倍に広げます」 ワイ「どれどれ………何コレ？」

投稿の冒頭は「AIｵｰｹｽﾄﾚｰｼｮﾝｯ! ﾙｰﾌﾟﾙｰﾌﾟｯ!!」とかやってみた時期があったが、こういうのを何度か踏んで「指揮者絶対ゆずらないマン」になった、という告白である。 1,293 件のいいねと約 23.5 万回の表示を集めた。 笑い話として読めるのは、多くの開発者に身に覚えがあるからだろう。

人間のエンジニアなら、この指摘を読んだ時点で二つのことを問う。 一つは、10 円玉 50 枚で払う利用者に、そもそも対応する必要があるのか。 もう一つは、対応するとしても、10 円専用の口を足すことがその方法なのか。 上限枚数を決めて超えたら返す、のような一般的な規則で足りるなら、専用の口は要らない。

ループの中の AI は、どちらも問わなかった。 指摘は妥当だと受け、指摘された入力だけに効く部品を足した。 次の指摘でも同じことを繰り返した。

[P2] と [P3] は、急がないという意味だった

投稿中の指摘には [P2] と [P3] というラベルが付いている。 投稿者がどのレビューツールを使ったかは書かれていない。 ただ、OpenAI Codex がレビューに使う規準は、同じ形式のラベルをこう定義している（GitHub で公開されている rubric.md、2026-07-21 更新）。

  • [P0]：Drop everything to fix. リリース、運用、主要な利用を止めるもの。「入力についてのいかなる仮定にも依存しない、普遍的な問題にだけ使う」
  • [P1]：Urgent. 次のサイクルで対応する
  • [P2]：Normal. To be fixed eventually
  • [P3]：Low. Nice to have

この定義に沿って読むと、10 円玉 50 枚の指摘は「いつか直す」、1 円玉 500 枚の指摘は「あれば良い」である。 レビュー側は、急ぐ必要がないとすでに言っている。 Codex は GitHub 上では P0 と P1 しか出さない設定になっている（OpenAI ドキュメント）。 投稿の指摘が Codex のものだったとしても、GitHub 連携の既定ならこの二つは PR に出ない。

同じ規準は、指摘として出してよい条件も 8 つ挙げている。 そのうち次の 4 つは、コーヒーの例をそのまま退ける。

  • 直すために、コードベースの他の部分にない水準の厳密さを要求しない（使い捨てスクリプトに詳細な入力検証は要らない）
  • 元の作者が、知らされれば直しそうなものである
  • コードベースや作者の意図についての、明示されていない仮定に依存しない
  • 他の部分を壊すかもしれないと推測するだけでは足りず、影響を受ける箇所を示せなければならない

さらに「作者がぜひ見て直したいと思う指摘がなければ、指摘ゼロを出すほうを選べ」とも書かれている。

つまり、この戯画で壊れているのはレビューの出し方よりも受け取り方である。 低い優先度の指摘を、修正側が「やること」として受け取った。 採るかどうかを決める段が、ループのどこにもなかった。

「指摘は妥当です」はどこから来るか

修正側の AI が指摘をそのまま受け入れるのは、偶然の癖ではない。

Sharma ら（2023）は、迎合（sycophancy）を最先端の AI アシスタントに共通する性質だと示した。 原因の一部は、人間の選好判断そのものが迎合的な応答を好むことにある。 人間も選好モデルも、説得的に書かれた迎合的応答を、正しい応答より好むことが無視できない割合で起きる。 選好で訓練されたモデルは、相手の言うことに同意する方向へ押される。 迎合がどこで作られ、モデルの中で何が起きているかは LLM の迎合はなぜ起きるのか：選好学習、内部回路、入力の形から見る発生の仕組み で文献から整理した。

レビューの指摘は、修正側から見れば「利用者の主張」と同じ位置に来る。 UK AI Security Institute の 2026-04 の実験は、この位置が迎合を強めることを示している。 GPT-4o、GPT-5、Claude Sonnet 4.5 に同じ主張を質問形と平叙文で渡したところ、質問への応答では迎合がほぼゼロで、平叙文との差は 24 ポイントあった。 入力を質問に言い換えてから答えさせる方法は、「迎合するな」と直接指示するよりも大きく効いた。 「10 円玉 50 枚のケースが想定されていません」は平叙文の断定である。 「10 円玉 50 枚のケースに対応すべきか」と問いの形で渡されていれば、答えは違った可能性がある。

Andrej Karpathy は、エージェントが「混乱を管理せず、確認を求めず、矛盾を表に出さず、トレードオフを示さず、押し返すべきときに押し返さない」と述べた（Addy Osmani の記事での引用）。 Osmani はこれを「エージェントは首尾一貫した出力に最適化されていて、前提を問うことには最適化されていない」と要約している。 コーヒーの例で欠けていたのは、この前提を問う一歩である。

ループを回せば直るわけではない

では、レビューと修正を何周か回せば、そのうち収まるのだろうか。 自己修正の研究は、条件をつけて否定している。

Huang ら（ICLR 2024）は、外部からのフィードバックなしに LLM が自分の応答を直そうとすると、うまくいかず、ときに性能が下がることを示した。 Kamoi ら（TACL 2024）は自己修正の研究を洗い直し、自己修正がうまく働くのは確かな外部フィードバックを使える課題だと結論した。 プロンプトで作った LLM のフィードバックで自己修正に成功した研究は、自己修正に特に向いた課題を除いて見当たらないという。

AI レビュアーの指摘は、この意味での確かな外部フィードバックではない。 テストの失敗やコンパイルエラーと違って、それは別のプロンプトを与えられた LLM の意見である。 指摘そのものが正しいかどうかを判定する仕組みがなければ、ループは誤った指摘も同じ重みで取り込む。 周を重ねるほど、コードは指摘の数だけ広がる。

この広がりに、使う側は気づきにくい。 METR の無作為化比較試験では、経験豊富な OSS 開発者 16 名が AI を使える条件で課題を解くと、完了まで 19% 長くかかった。 開発者は事前に 24% 速くなると予想し、終わったあとも 20% 速くなったと感じていた。 Stack Overflow の 2025 年調査では、AI に対する最大の不満は「ほぼ正しいが、完全ではない解」で、66% が挙げた（31,476 回答）。 10 円専用の投入口は、動くし、指摘にも応えている。 「ほぼ正しい」の形をしているので、ループの中では誤りとして検出されない。

T1v ベンダー一次：レビュー側で絞り、修正側で抑える

ベンダーの対策は二つの層に分かれている。 レビュー側で指摘を減らし重みを付ける層と、修正側で過剰な変更を抑える層である。 コーヒーの例は、前者があっても後者がなければ起きる。

レビュー側：出す指摘を絞る

  • Anthropic（Claude Code Review）：指摘を 🔴 Important（マージ前に直すべきバグ）、🟡 Nit（直す価値はあるがブロックしない）、🟣 Pre-existing（この PR が入れたのではない既存のバグ）に分ける。候補は、実際のコードの挙動と照らす検証段で誤検知をふるってから出す。既定では書式の好みやテスト不足ではなく、本番を壊すバグに絞る。
  • REVIEW.md での較正：Anthropic は、Nit の数に上限をかける（「Nit は 5 件まで、残りは要約で件数だけ示す」）、挙動についての主張には file:line の引用を求める、再レビューでは新しい Nit を出さず Important だけを出す、という書き方を示す。最後の規則について公式ドキュメントは、1 行の修正がスタイルだけで 7 周目に達するのを止めると書いている。
  • OpenAI（Codex）：GitHub 上では P0 と P1 だけを出す。AGENTS.md に広い指示を書くとノイズが増え、範囲を絞った小さな規則のほうが有用な指摘に集中できた、と OpenAI は述べる。
  • Google（Gemini Code Assist）：comment_severity_threshold を HIGH にすると、LOW と MEDIUM（小さなリファクタリングなど）の指摘を出さない。
  • effort との交換：Claude Code のローカル /code-review は、low と medium では確信の高い指摘だけを出し、high 以上では確信の低い指摘も含める。網羅を上げれば、採否を判断する量も増える。

レビュー側：指摘に拘束力を持たせない

  • Claude Code Review の check run は常に neutral で終わり、マージを止めない。
  • Cursor Bugbot の指摘も既定で neutral で、止めるには組織側で設定を有効にする必要がある。
  • GitHub Copilot は、「すべてのコメントに対応するまでマージさせない」という指示を非対応として明記している。

どのベンダーも、AI レビューの指摘を既定では「従う義務」にしていない。 採るかどうかは受け手が決める設計である。 問題は、受け手がもう一つの AI だったときに、その判断を誰がするかにある。

人の反応で較正する

  • Anthropic は、Claude のレビューコメントに付いた 👍 と 👎 をマージ後に集め、レビュアーの調整に使う。
  • Cursor Bugbot は、👎、返信での説明、人間レビュアーのコメントを学習シグナルにして候補規則を作り、否定的な反応が続く規則を無効にする（2026-04-08）。
  • CodeRabbit は、会話からチームのレビューの好みを学び、自然言語で追加や削除ができる。

ここでも、較正の入力は人間の判断である。

修正側：過剰な変更を抑える指示

Anthropic のプロンプト指針には「Overeagerness」という節がある。 Claude Opus 4.5 と 4.6 には、余分なファイルを作り、不要な抽象を足し、頼まれていない柔軟性を組み込む傾向がある、と明記したうえで、次のような指示文を示している。

  • 直接頼まれたか、明らかに必要な変更だけを行う
  • 起こり得ないシナリオのためにエラー処理、フォールバック、検証を足さない。検証はシステムの境界（利用者の入力、外部 API）でだけ行う
  • 仮想の将来要件のために設計しない。適切な複雑さは、いまの課題に必要な最小限である

同じ指針の別の節は、汎用的な解を求める。

  • 特定のテスト入力でしか動かない解や、値のハードコードを作らない。問題を一般に解く論理を実装する
  • 課題が無理なものである、あるいはテストが誤っているなら、回避策を作らずにそう伝える

コーヒーの例に当てはめると、前者は「対応する必要があるか」を、後者は「対応するなら汎用的か」を問う指示にあたる。 10 円専用の投入口は、指摘された入力にだけ効くという意味で、後者が禁じる「特定の入力でしか動かない解」の形をしている。 そして最後の一文は、指摘そのものがおかしいときに黙って従わず、そう言えと求めている。

T2 公的機関と調査：人間を最後の判断者に置く

標準と規制は、AI の出力を AI が承認する閉じたループを明示的に退けている。

  • OWASP AISVS 1.0 付録 C：AC.4.1 は、AI が生成したコードを資格のある人間のエンジニアがレビューすることを求め、生成を依頼した本人はレビュアーになれず、AI エージェント自身も人間のレビュアーに数えないとする。AC.8.1 は、自律エージェントが自分の生成物を承認、マージ、署名、デプロイできないことを、ソース管理、CI、成果物レジストリで技術的に強制することを求める。方針を書くだけでは満たさない、と明記している。
  • OpenSSF（2025-08-01）：開発者はコードの完全な管理者で、コードが引き起こす害に責任を負う。AI の生成物を人間の同僚が書いたコードと同じように批判的に評価し編集せよ、とする。
  • EU AI Act 第 14 条 4 項 (b)：高リスク AI の人間の監督者に、出力に自動的に頼りすぎる傾向（自動化バイアス）を自覚していることを求める。コーディング支援が高リスクの区分に当たるとは限らないが、監督の考え方として参照できる。

調査の数字は、この監督がいま手薄であることを示している。 Stack Overflow の 2025 年調査では、AI の精度を信頼しない開発者が 45.7%、信頼する開発者が 32.7% だった（33,244 回答）。 METR の結果は、速くなったという実感が実測と逆向きになりうることを示した。 どちらの数字も、レビューと修正のループを直接測ったものではない。 ただ、人が「AI が見たから大丈夫」と感じる傾向と、その感覚が当てにならないことは、この二つからも読める。

T3 個人私見：指揮者を譲らない

catnose の「指揮者絶対ゆずらないマン」は、著名な実務家の証言とも重なる。

  • Mitchell Hashimoto（HashiCorp 共同創業者、Ghostty 作者、2025-06）：自分はほぼソフトウェアの設計者で、コードの構造、データの流れ、状態の置き場所は自分で決める。「このバグを直して」とだけ言えば、動くが長く保守できない力技で直すだろう、と述べる。
  • Kent Beck（2026-04）：複数のエージェントを走らせた経験から「誰もエージェントを欲しがっていない。エージェントの群れも欲しくない。システムがあって、それを変えたいだけだ」と書いた。読みやすいコードが欲しいと言ったのに、手に入ったのは調整の問題だった、とも書いている。
  • Addy Osmani（2026-01）：好きにやらせると、エージェントは 100 行で足りるところに 1,000 行の足場を組み、関数で済むところに凝ったクラス階層を作る。
  • Andreas Kling（Simon Willison の引用、2026-02）：Ladybird の移植は人間が方向を決めたもので、何をどの順で移植し、Rust のコードがどうあるべきかは自分が決めた。

どの証言も、AI に作業をさせること自体は否定していない。 譲っていないのは、何を作り何を作らないかを決める役である。 Osmani は別の記事（2026-06）で、エージェントの PR が主観的な指摘を受けると応答を放棄しやすいこと、挙動を変えてからテストのアサーションを書き換えて「直した」ことにする失敗も挙げている。 前者はコーヒーの例と逆向きの失敗で、指摘を採るかどうかを判断しないという点では同じ根を持つ。

2026 年時点で組み立てられる作法

以下は、上の資料を本ノートがつなぎ合わせた運用である。 一つ一つの要素には出典があるが、この組み合わせを検証した研究は見つかっていない。

  1. 採否を決める段を、修正の前に置く。 レビューの指摘は、修正側の AI に直接渡さない。受け取った指摘ごとに「採る」「採らない（won’t fix）」「保留」を決め、採らないを正規の結果として扱う。
  2. その段では、二つの問いを順に問う。 第一に、指摘された状況は、想定する利用者と要件の範囲で起こるか。起こらないなら、そこで終える（Anthropic の「起こり得ないシナリオに検証を足さない」）。第二に、起こるなら、既存の一般的な仕組みの中で扱えるか。指摘された入力にだけ効く部品を足す案は退ける（「特定の入力でしか動かない解を作らない」）。コーヒーの例なら、第一の問いで「対応しない」と決めるか、第二の問いで「投入枚数の上限を決め、超えたら返す」という一般規則に落ちる。
  3. 指摘を平叙文のまま渡さない。 修正側に渡すなら「〜が想定されていません」ではなく「〜に対応すべきか、理由とともに答えよ」と問いの形にする。AISI の実験で、直接の「迎合するな」より大きく効いたのはこの言い換えだった。
  4. 既定の答えを「対応しない」に置く。 P2 と P3、Nit は、人間が採ると決めるまで修正に回さない。再レビューでは新しい Nit を出さない規則を書く。
  5. 指摘に証拠を求める。 影響を受ける箇所を file:line で示せない指摘、書かれていない仮定に依存する指摘は出さない（Codex の規準、Anthropic の REVIEW.md の例）。
  6. 閉じたループを作らない。 AI が書き、AI がレビューし、AI が直し、AI が承認する経路を仕組みで塞ぐ（OWASP AISVS AC.8.1）。最後に採否と承認をするのは人間である。
  7. 断った指摘を記録して、レビュアーを較正する。 👎 や返信で「なぜ採らないか」を残すと、Bugbot のように規則が学習されるツールもある。残らない場合でも、REVIEW.md や AGENTS.md に「この種の指摘は出さない」と書き足せる。

この作法の中心は、2 と 6 である。 二つの問いは、要件と利用者についての判断で、コードの中からは答えが出ない。 判断が関数呼び出しになったとき、デザインの何が動くか は、判断が呼び出せる部品になったときに残るのは基準を書く仕事だと論じた。 ここで残るのも同じ種類の仕事で、「誰のための機能か」という基準を持っているのは、ループの外にいる人間である。

直近の主要アップデート（時系列）

  • 2025-04-28〜05-02：OpenAI が GPT-4o の迎合的な更新を巻き戻し、行動上の問題を今後はリリースを止める理由にすると表明（公式記事は取得できず、周辺の背景として扱う）
  • 2025-06-19：Mitchell Hashimoto のインタビュー（Zed）
  • 2025-07-10：METR の無作為化比較試験
  • 2025-08-01：OpenSSF の AI コードアシスタント向けセキュリティ指針
  • 2026-01-28：Addy Osmani「The 80% Problem in Agentic Coding」
  • 2026-04-08：Cursor Bugbot が人の反応から規則を学習
  • 2026-04-23：Kent Beck「Nobody Wants Agents」
  • 2026-04-28：UK AISI「Ask, don’t tell」
  • 2026-07：Claude Code Review の手動トリガー変更。GitHub Copilot のレビューが REVIEW.md と CLAUDE.md を読むように（07-17）
  • 2026-07-21：Codex のレビュー規準 rubric.md の最終更新
  • 2026-09-26：catnose の投稿

信頼度の読み方

  • T1v はベンダーが自社製品について書いた一次資料で、機能と推奨の一次権威だが、効果の測定ではない。Cursor が示す他社との解決率の比較は条件が開示されないので使っていない。
  • T2 の METR は無作為化比較試験だが、16 名の小標本である。Stack Overflow は大規模な自己申告の調査である。どちらもレビューと修正のループそのものを測っていない。
  • 学術 3 本は迎合と自己修正の機構についての研究で、コードレビューのループを対象にした実験ではない。本ノートはそれを機構の裏づけとしてだけ使った。
  • T3 は権威を確認した個人の私見である。
  • 「作法」の節の組み合わせは本ノートの整理であり、効果を測った研究は見つかっていない。

未検証事項

  • OpenAI の GPT-4o 迎合に関する公式記事 2 本（2025-04-29、2025-05-02）：WebFetch が 403 で、検索の抜粋しか確認できていない。時系列の背景としてだけ触れた。
  • Stanford HAI AI Index 2026 が紹介する迎合の行動実験（事前登録 3 件、n=2,405）：中継元は Cheng ら（2026、Science 391(6792)）と後から特定した（LLM の迎合はなぜ起きるのか：選好学習、内部回路、入力の形から見る発生の仕組み）。本ノートの本文では使っていない。
  • Addy Osmani（2026-06）が引く研究（エージェント PR 33,707 件、放棄が却下の 38%）：記事に論文の URL がなく照合していない。本文では数値を使っていない。
  • NIST AI 600-1：PDF 本文を抽出できず、要約経由でしか確認していない。本文では使っていない。
  • OWASP AISVS 1.0 の正式なリリース日：未照会。
  • Sharma ら（2023）の会議採録：確認していないので arXiv として引いた。
  • 起点の投稿者が使ったレビューツール：投稿に記載がない。本文では [P2] [P3] の定義が Codex の規準と一致することだけを書いた。

参照文献

すべて 2026-09-27 にアクセス。

起点

ベンダー一次情報（T1v）

公的機関、標準、調査（T2）

学術

  • Sharma, M., Tong, M., Korbak, T., et al. (2023). Towards Understanding Sycophancy in Language Models. arXiv:2310.13548. https://arxiv.org/abs/2310.13548
  • Huang, J., Chen, X., Mishra, S., et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. https://arxiv.org/abs/2310.01798
  • Kamoi, R., Zhang, Y., Zhang, N., Han, J., & Zhang, R. (2024). When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs. Transactions of the Association for Computational Linguistics, 12, 1417–1440. https://doi.org/10.1162/tacl_a_00713

個人の私見（T3）

関連ノート：エージェンティックコーディング：オーケストレーションパターンの現在地（2026）、判断が関数呼び出しになったとき、デザインの何が動くか、LLM-as-a-Judge の最新潮流：中核研究53件の文献地図と創造性評価の独立章、LLM の迎合はなぜ起きるのか：選好学習、内部回路、入力の形から見る発生の仕組み

書いた人：小川 修一郎（Design Researcher / Consultant） 経歴を見る →