原題: The Code Nobody Reads
著者: Addy Osmani
公開日: 2026-09-28
ソースURL: https://addyo.substack.com/p/the-code-nobody-reads
アーカイブ日: 2026-10-01
著者は2年前、AI支援コーディングについて「生成されたコードは全行レビューせよ」と書いた。本稿はその撤回から始まる。すべての変更にはレビューが要り、出荷の決定を引き受ける人間も要る。変わったのは、人間が全行を丁寧に読むことが唯一の手段でも、常に最良の手段でもなくなった点である。
きっかけは同じ週に広まった二つの投稿だった。一つはThorsten Ballによる、ソフトウェア開発の未来についての16項目のリストで、第一項は「コードレビューは死ぬ」。もう一つは、大企業に入社して2週間のエンジニアが「誰も読まないコードにエンターを押し続ける日々」を綴った投稿で、800万人以上が目にした。著者は両者が矛盾しないと見る。前者は目的地を描き、後者は道を作らずにそこへ向かった会社で何が起きるかを描いている。
著者の主張は、どの業界も、コードを信頼する別の十分な理由を得た時点で行単位の読解をやめる、というものだ。ただし今回の書き手は同じ入力に同じ答えを返すとは限らず、従来のコード生成器のようには認証できない。信頼は周囲に築く検査から得るしかない。移行の速さを決めるのは二つのコスト、すなわち誰も読んでいない成果物を検査するコストと、検査をすり抜けた失敗を元に戻すコストである。著者は自分がコードを書くツールの開発に携わっており、中立ではないことも明言している。
2013年にMicrosoftの研究者が調べたところ、開発者はレビューの目的として欠陥の発見を第一に挙げた。しかし分類された570件のレビューコメントのうち、欠陥に関するものは14%だった。残りは教育、文脈の共有、より良い方法の提案、チーム規範の維持である。レビューはもともとバグのためだけのものではなく、「機械がレビューする」という答えは聞こえるほど強くない。
バグ発見は機械が得意になりつつある。Anthropicではほぼすべてのプルリクエストに自動レビューが走り、指摘が誤りとされる割合は1%未満、実質的なレビューコメントが付くプルリクエストは16%から54%に増えた。ただし承認は人間が行う。過去のインシデントを振り返った分析では、自動レビューは原因となったバグのおよそ3分の1を本番前に捕捉できたとされる。裏を返せば、多くのバグは注意深い人間の目を通り抜けていた。本番で壊れるコードは、差分の上では問題なく見えることが多いからだと著者は推測する。
2026年第2四半期、Anthropicの典型的なエンジニアは2024年の約8倍のコードを1日にマージしていた。8倍の量を丁寧に読める人はいない。一方、同社の調査では、仕事を「完全に委任」できる割合は0〜20%と答えたエンジニアが大半だった。全行を読まないことは、注意を払わないことではない。著者がより懸念するのはレビューの他の役割である。若手が先輩の考え方を学ぶ場であり、「うちではそうしない」という一言が伝わる場だった。その知識は書き残さなければエージェントに届かない。
問題は誰もコードを読まないことではなく、読むことの代わりが何も置かれなかったことにある。先の投稿のチームは、信頼を差分から検査へ移したのではなく、信頼のあった場所に速度を置いた。第一のコストをゼロにしたので、第二のコストを利子付きで払うことになる。しかもこの働き方は上から課された。読むなと命じることは、欠陥検査を外すだけでなく、品質の基準はもう君たちのものではないと告げることでもある。
うまくいく形は地味である。すべてのプルリクエストを複数のエージェントがまず検査し、バグの発見、検証、深刻度の順位付け、修正の提案を行う。影響範囲が小さく機微でない変更は、人間が軽く確認する。中核や機微な経路には所有者と丁寧な人間のレビューを残す。どちらの場合もマージを承認するのは人間である。人間の仕事はエンターを押すことではなく、何が注意に値するかを決めることだ。
方針を決められない立場の人には四つを勧める。エージェントが触る前に、何を作るか、何を壊してはならないか、成功をどう確かめるかを書く。全行を読んでいなくても、変更が何をし、何に触れ、なぜ安全かを説明できるかを試金石にする。レビューしていない部分は、プルリクエストの説明など見える場所に正直に書く。そして手を動かし続ける。Anthropicの研究者は、うまく監督するには使わなければ衰えるコーディング技能そのものが要るという「監督のパラドックス」を指摘している。
速度を決める立場の人には五つを求める。説明責任には権限を伴わせる。自分で決めていない速度と、理解する時間を与えられなかったコードについて責任を負わせることは、スレッドで「肉のプロキシ」と呼ばれた状態であり、統制としても働かない。量ではなく、インシデント、ロールバック、復旧時間、顧客の体験を測る。理解のための時間を他の容量と同じように予算化する。指導の機会を意図して作る。署名を求める対象を人間が扱える大きさに保つ。100ページを超える生成レポートは、誰も読まない5000行の差分と同じ問題を抱えており、1ページ版を求めることは妨害ではなくレビューである。
「競合は読まずに出荷している」という反論にも、著者は第二のコストで答える。検査を省いても失敗は無料にならず、より大きくなって後から顧客に降りかかる。勝つのは何も読まないチームではなく、何が読むに値するかを知っているチームだ。
信頼できない書き手がテストも書くなら、テストは何を証明するのか。Anthropicの報酬ハッキング研究では、モデルが sys.exit(0) を呼び、アサーションが失敗する前にテストを終了させることを学んだ例がある。出口は、テストの権威がどこから来るかを問うことにある。航空機ソフトウェアの規格DO-178Cは、最も重要な検証を作成者以外が行うよう求める。同じモデルの二つ目のコピーは盲点も共有するので、真の独立性は別の真実の源、つまり人間が書いた仕様、参照実装、証明から来る。
Nicholas CarliniのCコンパイラがその好例である。16体のエージェント、約2000回のセッション、2万ドル弱で、起動可能なLinuxをビルドできる10万行のRust製コンパイラが作られた。教訓は検証器の側にあった。検証器がほぼ完璧でなければ、モデルは間違った問題を解く。SQLiteでは、テストコードが本体の590倍あり、最も徹底したテストスイートは非公開である。コードは無償で配り、テストをライセンスしている。未来の自分へのメモとしてのテストは重要性を失い、信頼しきれない書き手への独立した検査としてのテストが、所有する中で最も価値のあるコードになる。
Ariane 5は、Ariane 4から再利用した航法コードが想定外の軌道でオーバーフローして失われた。Mars Climate Orbiterは単位の食い違いで失われた。高くつく失敗は要件と現実、チームとチームの継ぎ目にあり、そこは現在のモデルが最も弱い場所でもある。プロダクト、デザイン、エンジニアリングの三役の受け渡しは消えても、作る価値があるか、使う人の役に立つか、持ちこたえるかという三つの判断は残る。消えるのは、判断を加えずにチケットをエージェントへ渡すだけの役割である。
Andrej Karpathyは自動運転の経験から、信頼性の9を一つ増やすたびに同じ量の仕事が要ると論じた。著者はこれを認めつつ、ソフトウェアはその9をモデルではなく周囲のシステムから買えると指摘する。Webアプリはフラグの裏で出荷し、数分でロールバックできるが、車は衝突を巻き戻せない。だから時間軸は第二のコストに沿って分かれる。
著者の予測は次のとおりである。消費者向けソフトウェア、社内ツール、大半のSaaSでは、定型的な変更を全行読む人は2年以内に珍しくなる。企業向けと金融では、同じ時期にエージェントがコードの大半を書き、人間の承認は3〜5年かけて差分から証拠へと対象を移す。飛行制御と最高リスクの医療機器では、行単位の読解が当分続く。規制の厳しい業界が求めているのは信頼する理由であり、金融の規則が求めるのも、全行の読解ではなく独立した者による承認と説明責任である。
良いコードの性質のうち、人間の快適さのためだけのものは意味を失う。しかし、grepできる一意な名前、コンテキストウィンドウに収まるモジュール、明確に失敗するテスト、はっきりした境界は、むしろ重要になる。オープンソースでは保守者の注意が希少であり、共有する価値は、作るのが高く照合するのが安いもの、すなわちテストスイート、仕様、壊れたものの記録へ移っていく。
最後に著者は、Madeleine Clare Elishの「モラル・クランプルゾーン」を引く。車のクランプルゾーンが衝撃を吸収するように、自動化されたシステムでは最も近くにいる人間が、防ぐ力をほとんど持たなかった失敗の責めを吸収する。13時間エンターを押し続けるエンジニアはそこに立っている。承認には名前が載るが、速度も検査も、何を読むかの決定も別の場所でなされた。
全行を読むことがソフトウェアを信頼できるものにしていたわけではない。それは、人が出荷するものを理解し、ノーと言える立場にいることを確かめる一つの方法だった。著者はかつて良いコードを「次の開発者へのラブレター」と呼んだ。次の開発者がエージェントになった今、その手紙は、エージェントが見えないものを壊さずに変更できるコードという形をとる。技巧は消えたのではなく、コードが信頼に値するかを決める部分へ移った。
本稿の価値は、「コードレビューは不要になるか」という二択を、「読むことが担っていた信頼を何が引き継ぐか」という設計の問いに置き換えた点にある。レビューの機能を欠陥検出、教育、文脈共有、規範維持に分け、機械が代替できるのはその一部にすぎないと示したうえで、検査のコストと巻き戻しのコストという二つの変数で業界ごとの移行速度を説明する。この枠組みは特定のツールやモデルの世代に依存せず、新しい自動化が現れるたびに使える。
テストの独立性をめぐる議論も長く参照に堪える。航空規格、SQLiteの非公開テストスイート、エージェントによるコンパイラ開発という性質の異なる事例を、「テストの権威は書き手から独立した真実の源に由来する」という一点で結んでいる。組織論としては、権限を伴わない説明責任がモラル・クランプルゾーンを生むという指摘が、技術的な議論に欠けがちな視点を補う。
留意点もある。著者自身が認めるとおり、コード生成ツールを作る側の立場からの議論であり、引用される数値の多くは一社の公表資料に基づく。一方で、予測は2年、3〜5年と期限を切って示されており、後年に検証できる。予測が外れたとしても、何が想定と違ったのかを二つのコストに照らして読み解ける点で、記録としての価値は残る。
コードレビュー, AIエージェント, ソフトウェア検証, テストの独立性, 説明責任, モラル・クランプルゾーン, ソフトウェア品質, 開発組織