コードを読むべきか、読まざるべきか？Vibe Engineering 時代における難題
Vibe engineering とは、人間が意図、制約、検証ループを定義し、coding agent が実装を大量に実行する開発スタイルです。それがもたらす新たな難題は、AI がコードを生成する速度が人間の読解能力を遙かに超える中、私たちが配信成果に責任を持つためには、一体どれだけのコードを読む必要があるのか、という点です。
ここ数日、『Clean Code』の著者である Uncle Bob（Robert C. Martin）の投稿を目にしたとき、私の最初の反応は「ちょっと待って、Clean Code の大家ですらコードを読むなと言っているの？」というものでした。実にセンセーショナルな見出しですが、議論の全体像と背景資料を読み込むと、本当の課題は別の場所にあると気づきました。「読むか読まないか」という一度限りの固定的な信仰に拘泥するよりも問うべきは、かつて人間の目が果たしていた役割を、どんな「エビデンス」で置き換える覚悟があるのか、ということです。
『Clean Code』の著者が「コードを読まない」と言った日
事の発端は 2026 年 7 月、Uncle Bob が Ori Pomerantz の X 投稿 の下に寄せた 返信 でした。彼は、coding agent が書いた実装コードを今では意図的に読まないようにしていると明かしました。1 行ずつ手動でチェックしていては、agent がもたらす生産性向上のメリットが相殺されてしまうからです。
ちなみに、大先輩二人のオープニングは業界歴の張り合いから始まりました。一人が「1983 年入行だけど年寄りかな？」と問いかけると、もう一人が 1960 年代後半の経歴を持ち出してマウントを返すという展開でした。（最高です。このやり取りだけでスクリーンショットを保存する価値があります。）
コードの美しさを数十年唱え続けてきた大家の口からこの言葉が出たことで、ドラマチックなインパクトを与えました。しかし、ここで記事を読むのをやめて『Clean Code』をゴミ箱に投げ捨てたら、見出し詐欺の罠に嵌まることになります。彼は同じ返信の中で、コードを読まないでいられるのは、agent の周囲に極めて厳格なチェックポイント群を構築しているからだと強調しています。単体テスト、Gherkin 受入テスト、QA 手順、カバー率および複雑度指標、さらには mutation testing（変異テスト）まで含めた制約です。すべての検査をパスするまで agent に自動修正を繰り返させるこのプロセスを、彼は run the gauntlet（試練を潜り抜ける）と表現しました。
彼はその後の補足で、単体テストや QA 手順自体も agent によって生成されていると述べています。単体テストは審査しませんが、タスクの重要度（criticality）に応じて Gherkin や QA 手順をサンプリング検査または全件検査し、定期的に自身で手動テストを行っています。(注：一部の返信は X 上で独立リンクが見つからないため、上記詳細は ExplainX のまとめ と Rapha Moura の記事 をクロスリファレンスして意訳しています。)
実際、2026 年 4 月には、Uncle Bob は Wookash Podcast の質問 に対して 同様の宣言 をしていました。当時彼は直球で「Humans are slow at code」と書き、AI 時代の人間は高次元の管理にシフトし、テストカバー率、モジュール結合度、循環複雑度（cyclomatic complexity）、mutation score に注力すべきだと主張しました。
この違いがお分かりでしょうか？Uncle Bob は品質を諦めたわけではありません。彼が実際に行っているのは、かつて人間の目が担っていたチェックを、機械的な自動化制約へと変換することなのです。
しかし、すべての希望をテストのハードルに賭けることは、本当に万全なのでしょうか？コードレビューをゴミ箱に放り込む前に、私たちが日常的に使っているいくつかの用語を整理しておく必要があります。
Vibe Coding、Agentic Programming、Vibe Engineering の3つを整理する
現在、コミュニティで AI によるプログラミングが話題になると、多くの人が安易に「vibe coding」というラベルを貼りがちです。しかし、すべての AI 補助開発を同一視してしまうと、その後の技術的な議論はすれ違いに終わってしまいます。
1つ目の用語は Vibe Coding です。Andrej Karpathy が 2025 年 2 月の投稿 で初めて提唱した概念です。彼が当時説明したのは、コードの存在を完全に「忘れる」状態です。常に Accept All を押し、diff を見ず、エラーメッセージが出たらそのままモデルに貼り付け、プログラムが動くまで AI にランダムな修正を行わせるというものです。Karpathy 自身も明言しているように、この極端な放任スタイルは、週末の使い捨てプロジェクト（throwaway projects）に最適です。
2つ目の用語は Agentic Programming です。Martin Fowler が自身のコラム記事 でこの区別を提示しました。agentic programming モードでは、人間が自らコードを打ち込むことはほとんどなくなりますが、エンジニアはシステムのアーキテクチャやコード品質に深く関心を持ち続けます。人間はタイピストから監督者へと役割を変え、コードレビュー、テスト結果、各種モニタリング指標を監視し続けます。
3つ目の用語は Vibe Engineering です。Simon Willison が 2025 年 10 月に vibe engineering という名称を提唱し、vibe coding の反対側にあるプロフェッショナルな領域の空白を埋めました。彼は、シニアエンジニアが LLM を使って高速に開発を行う際も、本番環境（production）のソフトウェアに対して引き続き責任を負わなければならないと強調しました。これには自動テスト、事前計画、ドキュメント作成、バージョン管理、プレビュー環境、コードレビューが含まれます。Willison は 2026 年の更新で、将来的に Agentic Engineering がより一般的な名称になるかもしれないと認めています。
日常の出前注文に例えるなら、vibe coding は料理の写真だけを見て注文し、厨房がどうなっているかは気にしないスタイルです。agentic programming はレストランの衛生評価や食材成分を確認するスタイルです。そして vibe engineering は、包括的な食品安全検査やプロセス管理を計画し、顧客が体調を崩した際にはトレーサビリティと補償を行える体制を整えるスタイルです。
本文において、私が定義する vibe engineering には具体的な作業定義があります。人間のエンジニアが主に意図、境界、リスク、検証ループを定義し、agent が大量の実装を実行します。人間はエビデンスの強度に応じて、コードを精査する深さを決定します。
ここで重要な問いが生じます。私たちが引き続き本番環境に責任を負うのであれば、なぜ「1 行ずつコードを読む」という従来の防衛線が揺らぎ始めているのでしょうか？
私たちはなぜ、かつてコードを読んでいたのか
AI が普及する前、私たちのチームがなぜコードレビューを義務付けていたのかを思い出してみましょう。
多くの人はコードレビューが単に「バグを見つけるため」だと思っていますが、それは機能のほんの一部に過ぎません。従来のコードレビューは、チームの健全性を維持するための多機能なメカニズムであり、5つの異なる役割を同時に担っていました。
- 正確性とセキュリティ（Correctness & Security）：論理的欠陥、境界条件の抜け漏れ、メモリリーク、潜在的なセキュリティリスクの探知。
- アーキテクチャと保守性（Architecture & Maintainability）：モジュールの結合度、命名の明瞭さ、将来の維持者が理解できるかの確認。
- 共有メンタルモデル（Shared Mental Model）：他のメンバーが最近何を修正したかを把握し、コードベース全体の理解を維持する。
- ナレッジ継承とメンタリング（Knowledge Transfer & Mentoring）：シニアエンジニアがコメントを通じて経験を伝え、ジュニアエンジニアがコードを読むことでチームのプラクティスを学ぶ。
- 責任帰属と意思決定の記録（Accountability & Decision Log）：バージョン管理履歴に記録を残し、変更が人間によって検討され承認されたことを証明する。
これは空港の保安検査に似ています。X 線検査機（自動テスト）は禁止金属を迅速にスキャンできますが、現場の保安検査員は依然として本人確認を行い、例外状況を処理し、異常行動を評価し、事故発生時に責任を負う必要があります。
自動テストが主に提供するのは「振る舞いが正しい」というエビデンスです。ナレッジの継承、アーキテクチャの美観、チームの暗黙知形成といった社会的な機能を自動的に引き継ぐことは困難です。著名なコンピュータ学者である Grady Booch は Uncle Bob に対する議論の中で、カバー率などの指標は機能への信頼を高めるものの、潜在的な脆弱性、死んだコード（dead code）、将来の可読性の喪失、不適切なアーキテクチャの解体を単独で排除することはできないと指摘しました。
コードレビューがこれほど多くの重要な機能を担っているにもかかわらず、なぜ今、人々は代替手段を切実に求めているのでしょうか？
なぜ「1行ずつのコードレビュー」が限界を迎えているのか
答えは非常に現実的です。AI がコードを生成する速度が、人間の脳の読解帯域幅を完全に押し潰してしまったからです。
工場で生産ラインのベルトコンベアの速度が突然 10 倍になったものの、品質検査員には目が 2 つしかない状況を想像してみてください。何が起きるでしょうか？
agent が数秒の間に数千行の変更を吐き出すようになると、従来の Pull Request や非同期コードレビューのプロセスは、即座に開発サイクル全体の最大のボトルネックと化します。Thoughtworks は AI 時代のコード品質に関する探求 の中で、大量に押し寄せる AI の変更によって、従来の PR レビューが深刻な疲労（review fatigue）に陥っていると観察しています。
膨大な diff を前にして、人間のエンジニアが「より注意深く読む」ようになるでしょうか？現実的によく見られる反応は、精神的に疲弊した後にページを素早くスクロールし、最終的に「LGTM」を適当に押してしまうことです。
このような「見たフリをする」コードレビューは、「実装は読んでいないが、テストを信頼する」と潔く認めるよりも遙かに危険です。誰かがチェックしたという偽りの安心感を生み出し、実質的には単なる儀式と化してしまうからです。
これこそが Uncle Bob の解決しようとした困惑です。疲労の中で品質が劣化する偽の審査を行うくらいなら、コードの詳細から注意を逸らし、極めて厳格な自動テストのハードルを構築した方が良いという判断です。
Uncle Bob はどこに「信頼」をシフトしたのか
では、Uncle Bob が人間の目に代わり得ると主張する Test Gauntlet には、具体的に何が含まれているのでしょうか？それぞれのチェックポイントが何を証明し、どんな盲点を持っているのかを分解してみましょう。
| ゲート / ツール | 主に回答する問い | 単独では回答できない問い |
|---|---|---|
| Unit tests | 小さな単位の機能動作は、想定されたケースに適合しているか？ | 全体的なビジネス要件が正しく理解されているか？ |
| Gherkin tests | 外部から観察可能な高レベルの動作は、仕様の記述と一致しているか？ | 仕様自体に重要な境界ケースが漏れていないか？ |
| QA / Manual test | 実際の操作時のフローや体感は期待通りか？ | ロングテールな異常シナリオや非機能的リスク。 |
| Test Coverage | テスト実行時にどのコードブランチが通過したか？ | テスト内の Assertion が実際に有効な検証力を持っているか？ |
| Mutation testing | テストスイートは意図的に注入されたバグ（変異）を検出できるか？ | パフォーマンス劣化、メモリリーク、並行性（Concurrency）の問題。 |
| Metrics 検出 | 循環複雑度、モジュールサイズ、依存構造は基準内か？ | 抽象化設計がビジネスドメインに適しているか？ |
この手法の価値は絶大です。AI に対する期待を「agent がコードを書くときに自発的に注意すること」から、「機械的検証を通過しない限りマージを許可しないこと」へと転換させます。
しかし、すべての信頼をこのテストハードルに移行させたとき、最も厄介な問いが浮上します。
最難関の課題：Agent が「選手兼審判」になるとき
単体テスト、Gherkin 仕様、さらには QA 手順までもがすべて同一の AI Agent によって自動生成されている場合、ソフトウェア工学における古典的な オラクル問題（Oracle Problem） に直面します。「検証者を誰が検証するのか？」という問いです。
ぶっちゃけて言えば、これは選手兼審判です。学生が自分で試験問題を作成し、自分で回答を書き、最後に自分の解答集で採点するようなものです。
この選手兼審判の構造は、実際にどのように失敗するのでしょうか？代表的なシナリオは3つあります。
最も一般的なのは、提示された要件自体に曖昧さがあるケースです。agent は実装を書く際に意図を誤解し、テストを書く際にもまったく同じ誤解を持ち込みます。実装が間違っており、テストも間違っているため、両者を突き合わせると全ランプがグリーンになります。これは 相関失敗（Correlated Failure） と呼ばれ、事後検査で最も発見しにくいパターンです。
2つ目は、KPI に追われる職場ドラマでおなじみの光景です。「カバー率 90%」が agent の絶対条件になると、LLM はすべての行を通過しつつも assert がスカスカで検証能力がほぼゼロのテストを喜んで生成します。数字は綺麗ですが保護効果はゼロに等しく、まさに グッドハートの法則（Goodhart's Law） の典型例です。
最後のパターンはより潜在的です。モデルは自身の産出物を評価する際、過度に楽観的になる傾向があります。コード作成時に気づかなかった論理的盲点は、テスト作成時にも同様に見落とされます。これが 自己採点バイアス（Self-grading Bias） です。
したがって、検証の独立性にはグラデーションが存在します。最も信頼性が低いものから最も信頼性が高いものへと並べると以下のようになります。 Agent による自己採点 < コンテキストを隔離した Reviewer Agent < 確定的なツール（Linter / コンパイラ） < ドメインエキスパート / リアルな本番環境からのフィードバック
テストと実装が同一の手から生まれるとき、リスクが消滅したわけではありません。リスクは「コードの書き間違い」から「テストも一緒に間違える」へと隠蔽された形で移行しただけなのです。
では、この二極化された困惑をどのように打破すればよいのでしょうか？
コードレビューは二元論ではない：注意力を「ファネル」として扱う
多くの議論は問題を「コードを読むのは保守的、読まないのは先進的」という二分法に押し込めがちです。しかし、そのような単純化は実際の開発現場では通用しません。
私はレビューの注意力を「ファネル（漏斗）」として捉えることを好みます。すべての変更は上から入ってきますが、すべての変更が一番下まで沈む価値があるわけではありません。
ファネルの最も広い開口部は、すべての変更を受け止めます。この階層では、人間は機能デモ、ログの可観測性、Rollback メカニズムのみを確認し、実装の読解は完全にスキップします。第一段階のフィルタリングは自動化されたハードルに委ねます。一段狭くなると、テストスイートのサンプリング検査に入ります。Gherkin 仕様とテストケースの網羅性を確認し、テストが意味のある箇所をカバーしているかを検証します。さらに下に行くと、契約層が開かれます。Public API、データベースの Schema Migration、モジュールの境界を確認し、具体的関数内の実装にはまだ触れません。
深くなるほどファネルは狭まり、ここまで沈んでくる変更も少なくなります。信頼境界（Trust Boundaries）、認証、決済、複雑なアルゴリズムといった高リスクなパスこそが、人間の目によって 1 行ずつ精読される価値を持ちます。ファネルの最下部にある狭い出口こそが、従来のコードレビューの標準姿勢であり、構文、詳細、スタイルを diff で精読する場所です。人間の注意力を下層に割くほどコストが高くなるため、最下部まで到達する変更は本来ごく一部であるべきです。
ファネルの中段には例外駆動のバルブが設けられています。普段は変更を上層に留めておき、自動化ハードルがエラーを報告した際や、複数の agent の結論が衝突した際にのみ、より深い階層に引き込んで人間による介入を行います。
チームが「コード読む派」か「読まない派」かを宣言する必要はありません。成熟した vibe engineering とは、個々の変更の特性に応じて、どの階層まで沈めるべきかを決定すること なのです。
いつ「軽く見る」べきで、いつ「深く読む」べきか
では、日常の開発において、目の前の PR をファネルのどの階層まで沈めるべきかをどのように判断すればよいでしょうか？
チームには以下の4つの次元からリスク評価を行うことを推奨します。
- 損害範囲（Blast Radius）：壊れた場合、誰に影響するか？ローカルの開発ツールか、会社の中核データベースか？
- 可観測性（Observability）：壊れた際、発見しやすいか？UI の崩れは一目瞭然ですが、Silent Data Corruption や Race Condition は極めて発見が困難です。
- 可逆性（Reversibility）：壊れた際、復旧は容易か？Feature Flag で即座に無効化できるか、不可逆な DB Migration が必要か？
- 検証独立性（Verification Independence）：テストや仕様はドメインエキスパートが書いたものか、モデルがテンプレートに従って自動生成したものか？
これら4つの軸に基づき、開発シナリオを3段階の介入ガイドに整理することができます。
| レビュー階層 | 適用シナリオ例 | 人間エンジニアの主な確認対象 | 深層レビューへの昇格条件 |
|---|---|---|---|
| グリーン：Outcome-first (極力読まない) | 使い捨てのスクリプト、プロトタイプ、低リスクな内部 Admin UI、CSS スタイルの微調整。 | 仕様要件、操作デモ、基本的な自動テストのステータス。 | テスト結果の異常、Agent の修正無限ループ、変更範囲の予期せぬ拡大。 |
| イエロー：Selective Review (重点抽出検査) | 一般的な製品の新機能、既存モジュールのリファクタリング、テストが健全なビジネスロジック。 | インターフェース契約（API Contract）、データフロー、高リスク分岐の Diff。 | 新規サードパーティ依存の追加、Data Schema の変更、パフォーマンス指標の低下。 |
| レッド：Deep Review (精読必須) | ユーザー認証（Auth）、決済フロー、権限管理、データ移行、セキュリティ境界。 | 1 行ごとの実装コード、脅威モデル（Threat Model）、アーキテクチャ設計。 | 長期的な本番環境のエビデンスがない限り、原則として降格を厳禁とする。 |
この表の核心的な精神は次の通りです。コードレビューとはリスクコントロールのツールであり、それを職業倫理のテストとして扱うのは方向性が間違っています。
変更がグリーン領域にあるときは、大胆に自動化ハードルに委ねることで生産性を得られます。しかしレッド領域に達したとき、適当に Accept All を押すのは未来の自分に地雷を埋めているのと同じです。
エンジニアの新しい役割：エビデンスを管理し、理解を維持する
大量のタイピングや 1 行ずつの審査を外部に委託したとき、エンジニアの仕事はなくなってしまうのでしょうか？
正反対です。エンジニアの役割は過去の「コード産出者」から、「境界の定義者およびエビデンスの管理者」 へと変化しています。
この変化によって、重要な新しい能力が浮き彫りになりました。それが Context Engineering（コンテキスト工学） です。
Claude Code チームの Thariq Shihipar は 2026 年 7 月に興味深い観察を共有しました。新しい世代のモデルをテストした際、Claude Code 内のシステムプロンプト（System Prompt）の 80% 以上を削除したにもかかわらず、コーディング評価ベンチマークのスコアは全く低下しませんでした。
Anthropic は技術記事の中でその理由を説明しています。過剰なプロンプト、重複したルール、細大漏らさぬサンプルは、モデルに「過剰制約（overconstraint）」を引き起こし、LLM がどのルールに従うべきかの判断に無駄な注意力を消費させてしまいます。より優れたアプローチは、クリーンなツールインターフェース、段階的開示（progressive disclosure）、明確な検証ループを提供することです。
この発見は私たちに深刻な示唆を与えてくれます。エンジニアの新しい仕事とは、シンプルで強力な検証環境（ハーネス / Harness）を設計することです。曖昧なビジネスの意図を仕様として書き起こし、超えてはならない境界を実行環境に組み込み、適切なタイミングでテストおよび評価ツールを介入させることです。
同時に、私たちは新しい形の技術的負債にも警戒しなければなりません。それが Cognitive Debt（認知負債） です。
チームの誰もシステムの内部実装を読まず、理解しない状態が長期化すると、短期的には機能がデリバリーされ続けるものの、システムに対するチームの掌握力は急速に衰退します。本番環境で障害が発生した際や、モデルが解決不能な論理のデッドロックに陥った際、底にあるコードがどのように動いているのか誰も分からなくなってしまいます。
エンジニアがタイピストから現場監督に昇格するのは一見スマートに見えますが、設計図すら読めず、進捗ランプを見つめるだけの現場監督が、自動的に建築家になれるわけではないのです。
レビューを着工前へとシフトする：sdd-workflow
理論を語ってきましたが、私自身の回答も提示しておきたいと思います。
私が最近開発した sdd-workflow は、自分が意図を明確にする前に AI Agent が焦って大量のコードを変更し始めてしまうことに気づいたのが出発点でした。
sdd-workflow（Spec-Driven Development）の核心的ロジックは、人間の注意力を「事後に数千行の diff を眺める」ことから「事前審査と段階的承認」へとシフトさせることです。Agent は着工前に、問題定義、変更範囲、受入条件を含む Proposal（提案書）を作成しなければなりません。人間がこの提案を読み、承認するまで、Agent には実装コードを変更する権限が一切与えられません。実装に入った後も、承認されたタスクを一度に1つずつ実行し、1ステップ完了ごとに状態とエビデンスを更新します。
プロセスは変更に対しても防衛線を設けています。開発中に要件の変更が発覚した場合、提案の修正と再承認を強制的に行い、Agent が以前の承認に新しい要件をこっそり混ぜ込むことを防ぎます。状態やエビデンスに曖昧さが生じた場合、ツールは fail closed を選択し、自動的に停止して人間へ判断を委ねます。
この記事の作成プロセス自体も、自己参照的（self-referential）なケーススタディと言えます。
私はまず Agent にこの記事の提案アウトラインを作成させ、論理の脈絡、Uncle Bob の立場検証、リスク表の設計を確認した上で、情報整理と執筆の開始を承認しました。
ただし、誠実に伝える必要があります。sdd-workflow が解決するのは 制御フロー、権限、エビデンスの規律 の問題であり、それ自体がコードの完全な正確性を証明するわけではありません。 提案書がどれほど美しく書かれていても、内部のビジネスロジックが間違っている可能性は残ります。それは、いつ立ち止まるべきか、どのエビデンスを見るべきか、誰が続行を許可したのかを明確にするプロセスの骨組みを提供してくれます。
すべてのコードの正確性問題を解決するわけではありませんが、「1 行ずつ読まないこと」が「目を瞑って盲信すること」と同義になるのを防いでくれます。
結論：最も確信を生む場所に、厳密さを配置する
最初の問いに戻りましょう。Vibe Engineering の時代において、エンジニアはまだコードを読むべきでしょうか？
私の回答は次の通りです。「読むか読まないか」は一度決めれば済む固定的な信仰ではなく、変更ごとに回答を更新すべきリスクの決断である。
要件が明確で、判定ツールが独立し、実行結果が容易に観察でき、いつでも数秒で Rollback できる状態であれば、1 行ずつ読む割合を大胆に減らし、より創造的なアーキテクチャ設計にエネルギーを注ぐべきです。しかし、セキュリティ、決済、個人情報、あるいは失敗の代償が極めて高い高リスク領域に踏み込む際は、コードを開いて深く精査する必要があります。
AI はコードの産出コストを極めて安価にしましたが、エンジニアリングの確信（confidence）の価格は下落していません。
コードを読む量を減らすと決めたなら、手元に真に信頼できる Gauntlet が構築されているかをまず確認すべきです。そして、いずれかのゲートが機能しなくなったとき、迷わず立ち止まり、そのコードを凝視できる準備を整えておくことが重要です。