← ブログに戻る

午後3時、あなたのコードレビュー承認率はほぼ0%になる:決断疲労の科学とAIエージェント時代の処方箋

認知科学コードレビューAIエージェント

先に結論を言います。午後3時の私が押す Approve は、午前10時の私が押す Approve と同じ重みを持っていないかもしれません。コードは1文字も変わっていないのに、私の判断のほうが先に劣化しているからです。そして AI コード提案の洪水は、その劣化を早送りで進めている可能性があります。

これは「だから午前中に重い判断を集める」という運用設計の話なのですが、その前に、私がなぜこの話を信じかけて、同時に半分疑っているのかを書かせてください。科学のほうが、実は揺れているからです。

朝65パーセントから午後ほぼ0パーセントへ落ち、休憩後に65パーセントへ回復する承認率の折れ線グラフ

判事は午後、ほぼ全員を却下していた

きっかけは、自分の Approve 履歴を眺めていたときの違和感でした。午後遅くの私は、コメントが妙に短い。「LGTM」とだけ書いて通すか、逆に「いったん保留で」と却下するか、その二択に寄っている気がする。中間がない。コードを丁寧に読んで条件付きで通す、という一番頭を使う選択肢が、午後には消えているように見えたのです。

そこで思い出したのが、Danziger らが 2011 年に PNAS で出した研究でした。イスラエルの仮釈放委員会、ベテラン判事8名が50日間で下した1,000件超の判断を分析したものです。結果が強烈でした。セッション開始直後の仮釈放承認率はおよそ65%。ところがセッションが進むにつれて単調に下がり、休憩の直前には**ほぼ0%**まで落ちます。そして食事休憩を挟んだ直後、承認率はまた65%付近へ跳ね上がる。

つまり、同じ判事が、同じ法律で、似たような案件を裁いているのに、その人がいつ昼飯を食べたかで囚人の運命が変わっていた、という話です。「法の前の平等」という言葉が、急に胃袋の話に聞こえてきます。

私はこれを読んで、自分の Approve も同じことをやっているのではと青くなりました。午後3時の私は、コードの中身ではなく、自分の燃料残量に応じて Approve か却下かを決めているだけなのではないか。

「燃料が減る」という説明は、たぶん盛りすぎ

ここで誠実に書かなければいけないことがあります。この話、science として相当に揺れています。

まず Danziger 論文そのものに、すぐ反論が出ました。Weinshall-Margel と Shapard が 2011 年に指摘したのは、案件の並び順が交絡しているのではないか、という点です。同じ刑務所の囚人はまとめて休憩前に審理される、弁護人のいない囚人はセッション末尾に回される、といった運用上の偏りがあり、それが「時間が進むと却下が増える」ように見せているだけかもしれない、と。Danziger らは「それを考慮しても効果は残る」と反論していますが、2016 年に Glöckner がシミュレーションで「効果は本物だとしても、その大きさはかなり過大評価されている」と示しています。完全な決着はついていません。

そして背景にある ego depletion(自我消耗)の理論自体が、心理学の再現性危機のど真ん中にいます。Vohs らが 2008 年に「選択を強いられた群は、後続の課題の成績が落ちる」と報告し、これが「自己制御は使うと減る燃料だ」というモデルの根拠になりました。ところが 2016 年前後の大規模な再現研究で、効果量は小さい、あるいはほとんど見えない、という結果が相次ぎます。「意志力はガソリンのように物理的に枯渇する」という強い主張は、いまかなり旗色が悪い。

だから私は、この記事で燃料メーターの絵を信じてくださいとは言いません。私が支持しているのは、もっと弱い形のほうです。判断の列が長く続くと、後続の自己制御が下がる傾向がある。メカニズムが代謝なのか動機づけなのか注意配分なのかは、2025 年の総説でもまだ議論が続いていて、最近は単純な直線モデルではなく、動機・注意・資源配分を含む非線形のモデルへ移ろうとしています。

要するに、グラフの形には自信が持てないけれど、午後の自分がポンコツになる感触のほうは、たぶん本物。そのくらいの温度です。期待させておいて燃料の話をしぼませてすみません。ただ、しぼんだ後に残るものこそ運用に使えます。

AI 提案は、判事より速く決断列を伸ばす

ここからが、私が本当に気にしている部分です。

仮釈放判事は、50日で1,000件、つまり1日あたり20件強の重い判断を下していました。では、AI アシスタントを使う今の私たちは、1日に何件の判断を下しているでしょうか。

2025 年の arXiv 論文 “Towards Decoding Developer Cognition in the Age of AI Assistants” が指摘しているのは、AI 提案を受け入れるかどうかの判断は、ただのイエス/ノーではない、という点です。AI の出した差分を読むには、まず AI がどういう論理でそれを書いたかを逆引きし、それを自分のメンタルモデルに再マッピングし、整合するか検証する。この検証サイクルが1日に数十回から数百回回ります。判事の20件強と並べると、桁が違います。

しかもこの負荷は最近きれいに数値化されはじめました。METR が 2025 年に出したランダム化比較試験では、熟練 OSS コントリビュータが AI ツールを使うと、未使用時より作業がむしろ19%遅くなったのに、本人たちは20%速くなったと感じていた。報告書はこれを「効率の錯覚」と呼び、隠れたコストとして「もっともらしいが間違っているコードを検証する負担」を挙げています。2026 年時点で AI 出力を信頼している開発者はおよそ3〜5割にとどまり、半数前後が品質の問題を経験している、という調査もあります。

整理すると、AI は私たちの代わりに決断してくれているのではなく、私たちに渡す決断の数を爆増させているわけです。アシスタントというより、決断を高速で配給してくる係。判事が休憩前に到達した「ほぼ0%」の状態に、私は判事よりずっと早い時刻に着いているのかもしれません。

レビューの段階ごとに AI と人間の責任をどう分けるかは コードレビューを6段階に切った記事 で別途書きました。今日の話はそのもう一段手前、そもそも私の判断装置が何時まで動くのかという話です。

処方箋:コードではなく、時間割を直す

ここで提案するのは、レビューを頑張れという話ではありません。頑張りは、まさに今しぼんでいる資源だからです。直すのは時間割のほうです。

重い判断を午前に寄せる。 アーキテクチャの可否、設計レビュー、後戻りの効かないマージ。これらは「自分が一番マシな時刻」に置きます。多くの人にとってそれは午前ですが、夜型なら自分の朝に当たる時間でかまいません。逆に午後遅くは、Format や Lint のような、判断というより確認に近い軽いレビューを置く。

レビュー枠を時間で区切る。 通知が来るたびにレビューするのではなく、午前と午後に枠を決めて、そこでまとめて見る。これは Dev.to で紹介されている「3PM ルール」のような運用とも重なります。割り込みごとに判断装置を起動するのをやめて、起動回数そのものを減らす発想です。

AI 提案はバッチ化する。 1行ごとに Tab で受け入れるのをやめて、ある程度まとめて差分にしてから一度に検証する。検証サイクルの起動コストが毎回かかるなら、起動の回数を減らすのが効きます。判事が休憩で承認率を回復させたのと同じで、連続した決断列を、意図的に区切る。

そして休憩を、サボりではなく工程として扱う。 仮釈放判事のグラフで唯一の救いは、休憩後に承認率が戻った点でした。再現性は揺れていても、決断列をいったん切ること自体は、害になりにくい安い投資です。長時間ノンストップで判断し続けると別の劣化も起きる、という話は 9時間ノンストップで Claude Code を回した記事 にも書きました。腐るのは AI のコンテキストだけではなく、こちら側の判断列も腐ります。

まとめ

  • Danziger ら(2011)は、仮釈放の承認率がセッション開始時の約65%から休憩直前のほぼ0%へ落ち、休憩後に回復したと報告した。ただし案件の並び順の交絡を指摘する反論(Weinshall-Margel & Shapard, 2011)があり、効果量の過大評価も指摘されている。
  • 背景の ego depletion 理論は再現性危機の渦中で、「意志力が物理的に枯渇する」という強い主張は支持が弱い。本記事は「決断列が続くと後続の自己制御が下がる傾向」という弱い形でのみ扱った。
  • それでも実務上は無視できない。AI 提案の検証は1日数十〜数百回の判断を生み(arXiv 2501.02684)、METR(2025)は熟練者でも19%遅くなるのに速くなったと錯覚する「効率の錯覚」を示した。決断の供給量だけは確実に増えている。
  • 処方箋はコードを直すのではなく時間割を直すこと。重い判断を午前へ寄せる、レビュー枠を時間で区切る、AI 提案をバッチ化する、休憩を工程として扱う。

科学のグラフが揺れているうちは、私はせめて自分のカレンダーのほうを動かしておきます。承認率がいつ底を打つか確信が持てないなら、底に当たる時刻に重い判断を置かない。それだけで、午後3時の私が午前10時の私のふりをして Approve を押す事故は、少し減るはずです。

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev