- 小橋昌明
- 約 4,500 文字
目次
夏休み自由研究連載 2026 の6本目です。
はじめに
AI戦略推進G（AI Transformation Group）の小橋です。いまはめぐりめぐって最適化の業務を担当しています。
私がCursorによるAI駆動開発入門 を書いたのは2025年4月のこと。その後、AI駆動開発の波がフューチャーにも完全に到達しました。私が会社内で最初に使っていたのはGitHub Copilotですが、料金体系が従量課金制に移行した際にツールの移行を推奨さ、8月からClaude Codeを使い始めたところです（ツール選択は全社一律というわけでは無く、私自身の移行は遅い方でした。人によってはその前からClaude Codeでゴリゴリ開発している人もいます）。
そんな中、私や周囲ではコードレビューをするのがしんどいという話が出てきました。コードを書くのが主業務になっているエンジニアは、生成AIの力を借りて今までよりも遥かに速くコードを書くことができますが、レビュワーはそうもいきません。この問題について、Technology Radar の中で見つけた「認知的負債」と絡めつつ考えてみたいと思います。
レビューをするのがつらい原因
開発のボトルネックがコーディングからレビューに移行し、レビュワーの負担が増しているという話は、今年に入って多く見かけるものです。そのような記事の中から原因を見てみましょう。
原因1：コード変更量が多い
LinearB の記事では、1つのPull Requestの行数が、AI不使用だと157行、AI支援ありだと408行、AIエージェントだとその間の293行となっています（p75 = 小さい方から並べて75%の値）。上がってきたPRを見ようとしたときに、コードの変更規模が2倍以上だと、単純に労力がかかりますね。
原因2：PR本文の説明が冗長
コード自体に加えてPR本文にもレビューがつらい原因がありそうです。個人的には、ちょっとPRを開いて内容を確認しようとしたら、説明文の文章量に圧倒されて怖気づくことがありました。
GitHubの「エージェントが生成したPRをレビューする際のガイド」という記事 は主にレビュワー向けのことが書いてありますが、PRを提出する開発者に向けてもアドバイスが書いてあります。曰く、エージェントが作成したプルリクエストをオープンする前に、PRの本文を自分自身で編集しなさい。エージェントは自分が書いた変更内容を微に入り細を穿ち、詳細に全部説明してくる傾向があります。コードを見たほうが良く分かることでもPR本文に書いてきがちです。背景や文脈が必要な箇所に限って、diffにインラインコメントを付けるべきである……と。
今までコードレビューしてきた経験から言うと、AIは変更内容をよく記憶しているので、全ての変更をPRに載せてきます。さらにメリハリをつけず、すべてが同じ重要度であるかのように書きがちです。結果として、要点が分からない無駄に長いPR説明文になりがちという印象があります。思い切ってバッサリ内容を削るか、一旦担当者が自分で書いて（そうすれば自然と要点だけになる）その下にAIの長大コメントを添えるとかにするのが良いのかなと思います。
原因3：間違っているコードが間違っていそうに見えない
AIが一見綺麗で整ったコードを書いてくるせいで、間違っていることがすぐには発見できず苦労するという話です。AI製のコードには明白な間違いや不適切な命名が少なく、レビュワーは表面的な間違いではなく奥深くに潜んだ間違いを探す必要があるため、同じ量のコードをレビューする場合でもより注意深く見る必要があるでしょう。単純な量（行数）だけではなく、質的にもレビューはしんどいものに変化しているのでしょう。The AI Code Review Bottleneck, By the 2026 NumbersやCognitive Load in the AI Eraに記載があります。
Technology Radar の「Codebase cognitive debt」を見る
AIのパワーにより、コードが桁違いの勢いで生成されるようになりました。その結果の1つが、今まで見てきたレビュワー側のしんどさです。そしてもう1つの帰結が、人間が本当に中身を理解しないうちに、コードだけがどんどん積み上がっていくという事態です。これがすなわち、認知的負債と呼ばれるものです。それでは、Technology Radar を見ていきましょう。
定義
本文では、定義は次のように書かれています。「コードの認知負債というのは、システムの実際の実装と、それがどのようになぜ機能しているのかというチームの共通理解との間に生じるギャップが増え続けることである」。これがあまりにも悪化し、ある限界に達すると、小さな変更を加えただけで予期しない障害が発生したり、バグ修正をしたつもりが他の部分でリグレッション（デグレ）を起こし始めたりする、そういう恐ろしい事態が起こると書かれています。
日本語による説明は例えば t_wada さんの「Agentic Software Engineering」のスライド などが良いと思います。
この問題がとりわけ色濃く出るのは、バグの検出の場面だと感じます。たとえば「この部分はバグではないか」とClaude Codeが指摘してくることがありますが、その指摘が正しいのかどうか、こちらには判断がつきません。人間の側にその挙動に関するメンタルモデルがないため、Claude Codeの言い分が正しいかどうかを判定できない、という問題です。
もし仮に、私たちが作っているソフトウェアの仕様や処理が、自分たちの脳みそのキャパシティに収まるものであれば、全く問題ありません。そのキャパシティの範囲でコードを認知し、把握すればよいだけの話になります。ただ実際には、私たちが作っているものは、脳みそのキャパシティに収まりきらないほど大きな規模であることがほとんどです。そうするとしっかりと腰を据えて、コードの中身についての理解を自分の中に育てていかなければいけません。
Cognitive Debt という概念が最初に提案されたのは、おそらく Margaret-Anne Storey という大学教授の記事でしょう。これは今年の2月に書かれた記事で、学生のチームが開発を進めていく途中で陥った事態について記載しています。
しかし、7～8週目になると、あるチームが壁にぶち当たりました。単純な変更を加えるだけでも、予想外の不具合が発生しました。私が彼らと面談したとき、学生チームは技術的負債が問題の原因だと考えていました。汚いコード、下手なアーキテクチャ、性急な実装。しかしよく調べてみると、本当の問題が現れました。ある設計上の決定が何故なされたか、あるいはシステムの異なる部分がどうやって連携して動作しているのか、チームの誰も説明できなかったのです。コードは汚かったかもしれませんが、それ以上に問題だったのは、システムの中の理論やチームの共通理解が、完全にバラバラになってしまったことでした。
この最初の記事がネット上で議論を巻き起こしたらしく、Storey教授は1週間ほど後に2番目の記事を書いています。技術的負債がコードの中の問題であるのに対して、認知的負債は人々の理解の中の問題であり、開発者の痛みとなって現れます。コードに変更を加えるときに自信が無くなる、レビューの負担増加、ストレスや疲労といった影響を引き起こします。あれ、レビューの話に戻ってきましたね。
対策
Technology Radar の記事内では、対策として次の3つが挙げられています。
- コーディングエージェント向けのフィードバックセンサーの設置
- チームの認知負荷のトラッキング（Team Cognitive Load）
- アーキテクチャ適合度関数（Architecture Fitness Function）の活用
「コーディングエージェント向けのフィードバックセンサー」とは持って回った言い方ですが、要するに、AIエージェントの結果を人間が見て軌道修正する、いわゆるhuman in the loopを少なくしたい、ということのようです。そのために、レビュー用のエージェントを導入して整備したり、コーディングエージェント自身が型チェックやリンターを呼び出してチェックできるようにしたりする、という話です。自動コーディングが回っている最中に、人間ではなく機械によるチェック機構を組み込むことで、人間が介入しなければならない箇所を減らそうという発想であり、これは納得感があります。
チームの認知負荷のトラッキングについては、正直なところこの概念が提唱された書籍『Team Topologies』を買ったきりで積んだままの状態なので、あまりよく分かっていません。Technology Radar からリンクをたどっていくと、開発者へのアセスメント、つまりアンケートを取ろうという話に見えます。開発やテスト、デプロイがどれくらい簡単にできるか、あるいは準備がどれくらい困難か、といった内容のアンケートのようです。ただ、こうしたアンケートで認知負荷が増大したことを検知できたとして、その後どう対処すべきかという部分こそ知りたいところだと感じます。
最後のアーキテクチャ適合度関数については、調べてもよく分かりませんでした。この語を提案したのが（Technology Radarを発行しているThoughtworks社のメンバーが書いた）「進化的アーキテクチャ」という本の中らしいので、バイアスがかかっている気がしなくもありません。
ドキュメント
ここまでの議論から抜け落ちている重要な観点があると思っていて、それはドキュメンテーションです。私自身、ドキュメンテーション好き人間としては、人間がコードの実装を把握するための一番良い手段は適切なドキュメンテーションなのではないか、という疑問が湧いてきます。もちろん、そのドキュメントはAIが読んだり書いたりしやすいものであるべきでしょう。理想的なのはコードと同じリポジトリ内でmarkdownなどで管理する方式、すなわちDocs as Codeという話になるはずです。しかし、不思議なことにこのキーワードで検索してもあまり記事が出てきません。出てくるのは以下の記事くらいです。
https://www.m3tech.blog/entry/2026/03/12/115110
おわりに
先ほどのGitHubの記事 でも、「レビュー用のCopilotを最初に実行して、明らかな誤りが無いかチェックしてもらいましょう」「クリティカルパスに絞って、入力から出力までを辿ってチェックしましょう」とのアドバイスがありました。人手によるレビューを極力減らして、AIにやってもらうこと、その精度を向上させることが大事なのでしょう。避けられない流れの中でソフトウェア品質をどう担保するか、もうしばらく考えてみたいと思います。