Clean Codeの著者として知られるUncle BobことRobert C. Martin氏が、2026年7月23日にX（旧Twitter）へ投稿した一文が世界中の開発者を騒がせています。いわく「My current strategy is to not read any of the code written by my agents（私の現在の戦略は、エージェントが書いたコードを一切読まないことだ）」。この投稿はHacker Newsにも転載され、46ポイント・43コメント（参照日: 2026-07-28時点）を集めて議論が続いています。
先に要点をまとめると、次の3点です。
- Martin氏は「コードを読まない」代わりに、ユニットテスト・Gherkinテスト・QA手順・品質メトリクス・ミューテーションテスト・カバレッジ計測という多重の制約でエージェントを包囲する戦略を取っている
- 「読まないこと」自体が目的ではなく、エージェントの生産性を引き出すには人間のレビューがボトルネックになるという認識が出発点
- 日本企業のエージェント運用にそのまま輸入するのは危険。ただし「レビュー工数を検証パイプラインへ移す」という発想は、今日から段階的に検証を始める価値がある
「Clean Codeの人が、コードを読むのをやめた」——このコントラストの強さだけが独り歩きしがちですが、実際の投稿を読むと、単なる挑発ではなく一貫した品質戦略が語られています。この記事では一次ソースの全文を確認したうえで、発言の中身、コミュニティの賛否、そして日本のAIエージェント実務者が何をどこまで真似できるのかを整理してみましょう。
何が起きたのか：発言の全文と文脈
まず事実関係から確認します。今回の発言は単独ポストではなく、Ori Pomerantz氏の投稿への返信でした。Pomerantz氏は2026年7月22日、「Claudeに文章を書く手伝いをさせようとしているが、自分のファイルを編集させることにどうしても抵抗がある。コードに責任を持つ以上、心理的にも中身を理解する必要がある。1983年からプログラミングをしている自分は古いのか？」という趣旨の問いを投げかけていました。
これに対するMartin氏の返信の全文（筆者訳）は次の通りです。
私は君よりかなり年上だ。1960年代後半からコードを書いている。私の現在の戦略は、エージェントが書いたコードを一切読まないこと。それが、エージェントの生産性を活かせる唯一の方法だからだ。代わりに私がやっているのは、エージェントを極端な制約で包囲することだ。ユニットテスト、Gherkinテスト、QA手順、品質メトリクス、ミューテーションテスト、テストカバレッジ、その他大量の制約。最終的に、彼らの生成するコードには非常に高い確信を持てる。私のすべての制約とテストという「ガントレット（試練の関門）」をくぐり抜けてきたのだから。
投稿のリアクションは参照日時点で表示回数約470万回、いいね約1.8万件、リポスト1,800件超と、開発者コミュニティの投稿としてはかなり大きな反響です。
| 項目 | 内容 |
|---|---|
| 発言者 | Robert C. Martin氏（@unclebobmartin、通称Uncle Bob） |
| 投稿日時 | 2026年7月23日 11:44 UTC |
| 形式 | Ori Pomerantz氏への返信（長文ポスト） |
| 反響 | 表示約470万回・いいね約1.8万・リポスト1,841・引用827（2026-07-28参照時点） |
| Hacker News | 46ポイント・43コメント（2026-07-28参照時点） |
Martin氏は『Clean Code』の著者であり、アジャイルソフトウェア開発宣言の起草メンバーの一人でもあります。「人間が読みやすいコード」を四半世紀にわたり説き続けてきた人物が「読まない」と宣言した点に、このニュースの本質的な面白さがあります。
「読まない」を支える6つの制約を分解する
ポイントは、Martin氏が「読まない」と「検証しない」を明確に区別していることです。彼が挙げた制約を1つずつ見ていきましょう。
| 制約 | 役割 | 代表的なツール例 |
|---|---|---|
| ユニットテスト | 関数・クラス単位の振る舞いを固定する | pytest、JUnit、Vitest |
| Gherkinテスト | 自然言語に近い形式で受け入れ条件を記述し、仕様と実装のズレを検出する | Cucumber、Behave |
| QA手順 | リリース前の手動・半自動の品質確認プロセス | チェックリスト、E2Eテスト |
| 品質メトリクス | 複雑度・重複率などをしきい値で監視する | SonarQube等の静的解析 |
| ミューテーションテスト | コードを意図的に改変し、テストが改変を検出できるか＝テスト自体の品質を測る | PIT（Java）、mutmut（Python）、Stryker（JS/TS） |
| テストカバレッジ | テストが実行したコードの割合を計測し、下限をゲート化する | pytest-cov、JaCoCo |
注目すべきはミューテーションテストが入っていることです。カバレッジは「テストがコードを通過したか」しか見ませんが、ミューテーションテストは「テストがバグを検出できるか」を測ります。エージェントが「通るだけのテスト」を書いてしまう問題（後述）への直接的な対抗手段であり、この一語が入っているだけで、単なる「AIに丸投げ」宣言とは設計思想がまったく違うことが分かります。
Gherkinテストとは何か
Gherkinは、Cucumberなどの BDD（振る舞い駆動開発）ツールで使われる仕様記述形式です。Given/When/Thenの構造化された自然言語で書くため、非エンジニアのステークホルダーもレビューに参加できます。次のようなイメージです。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# features/refund.feature — 返金処理の受け入れ条件
Feature: 注文の返金
Scenario: 発送前の注文はキャンセルで全額返金される
Given 顧客が未発送の注文を持っている
When 顧客がキャンセルをリクエストする
Then 注文金額の全額が返金される
And 顧客に返金完了メールが送信される
ポイントは、実装コードは読まなくても、この仕様は人間が読むという点です。Martin氏の戦略は「人間の読む対象をコードから仕様とテストへ引き上げる」ことだと言い換えられます。
「テストの量」は片手間では済まない
ただし、この戦略のコストも直視する必要があります。テストで品質を担保しきる先行事例としてよく引き合いに出されるSQLiteは、公式ドキュメントによると、バージョン3.42.0時点でライブラリ本体が約155.8 KSLOCなのに対し、テストコード・テストスクリプトはその590倍にあたる約92,053 KSLOCに達します。「読まない代わりにテストで固める」を極限までやると、これだけの投資になるという実例です。Hacker Newsのコメント欄でも、この規模感を根拠に「制約で包囲するのは言うほど簡単ではない」という指摘が出ていました。
コミュニティの反応：賛否はきれいに割れた
Hacker Newsのスレッド（参照日: 2026-07-28）では、支持と懐疑がほぼ拮抗していました。以下は筆者がスレッドを通読して整理した論点です（個々のコメントはコミュニティの意見であり、検証された事実ではない点に注意してください）。
支持派の論点
- 読む方が遅い：他人（やAI）のコードを読んで理解する時間は、書く時間より長くかかることが多い。自動検証で信頼を積み上げる方が現実的という意見
- 信頼度は積算できる：エージェントによるレビューパスとテストを重ねれば実用上十分な確信に達する、という段階的信頼のモデル
- 短中期では合理的：テストカバレッジが堅牢なら、少なくとも短期〜中期の生産性戦略としては筋が通っているという条件付き賛成
懐疑派の論点
- 「通るテスト」問題：エージェントが機能を根本的に間違って実装したのに、その間違った実装に合わせた「パスするテスト」を書いてしまった、という実体験の報告。テストが実装と同じ誤解を共有していると、制約は機能しない
- Potemkinテスト：モックを多用して見かけ上は正しく見えるが、実体を検証していないテストが混入するリスク
- 長期の保守性：誰も読んでいないコードベースの技術的負債は、障害発生時や大規模改修時に一気に顕在化するのではないかという懸念
- ポジショントーク疑惑：クリーンコードで名を成した人物がAI時代に合わせて主張を転換したことへの皮肉も見られた
筆者の見立てでは、両者は実は矛盾していません。支持派は「検証パイプラインが十分に強い場合」の話をしており、懐疑派は「検証パイプラインが弱い・偽装され得る場合」の話をしています。つまり争点は「読むか読まないか」ではなく、「読まなくて済むだけの検証基盤を、自分のチームは本当に持っているか」です。
日本企業のエージェント運用にどう関係するか
では、この議論は日本のAIエージェント実務にどう効いてくるのでしょうか。100社以上のAI導入支援に関わってきた経験から、3つの視点で整理します。
視点1：開発現場 — レビュー工数がボトルネック化し始めている
Claude CodeやCursorのようなコーディングエージェントを導入した組織で次に起きるのは、「生成速度にレビューが追いつかない」問題です。エージェントが1日に出すPull Requestの量を人間が全行精読していては、導入前より遅くなることさえあります。Martin氏の戦略は、この構造問題への一つの回答です。ただし彼の前提には数十年のテスト設計経験があり、「制約を設計する能力」がない状態で「読まない」だけ真似するのは最悪の選択です。
視点2：品質保証 — 「テストの品質」を測る文化が薄い
日本の開発組織ではカバレッジ計測までは普及しつつありますが、ミューテーションテストの導入率はまだ低いのが実感です。エージェント時代には「テストを書いたのもAI」というケースが増えるため、テスト自体を検証する仕組みの重要性が跳ね上がります。詳しくはAIエージェントの品質テスト自動化ガイドも参照してください。
視点3：マネジメント — 監査要件と「読まない」は衝突し得る
金融・医療など規制産業では「コードレビューの実施記録」自体が監査項目になっている場合があります。「人間は読まない」を採用するなら、代わりに何を検証記録として残すのか（テスト結果、カバレッジレポート、ミューテーションスコア、エージェントによるレビューログ等)を先に定義しておく必要があります。人間の承認をどこに残すかという設計はHuman-in-the-Loop承認パターンの記事で詳しく扱っています。
導入・検証の始め方：3段階で「読まない」に近づく
いきなり全面的に「読まない」へ移行するのは無謀です。検証パイプラインの強度を測りながら、段階的に人間レビューの範囲を絞っていくアプローチを推奨します。
| 段階 | 人間が読む範囲 | 必要な基盤 |
|---|---|---|
| 段階1: 全読 | エージェントの全出力 | 従来のコードレビュー体制のみ |
| 段階2: 選択読 | 仕様・テスト・重要モジュールのみ精読、他は流し読み | カバレッジゲート＋CI必須化 |
| 段階3: 制約読 | 仕様（Gherkin等）とテストのみ。実装は原則読まない | ミューテーションテスト＋品質メトリクス＋実装とテストの分離生成 |
ステップ1：カバレッジをCIのゲートにする
まず「テストが通らない・カバレッジが下がるコードはマージできない」状態を作ります。Pythonならpytest-covで下限を強制できます。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, pytest, pytest-cov
pip install pytest pytest-cov
# カバレッジ90%未満なら失敗させる
pytest --cov=src --cov-fail-under=90
ポイントは、しきい値を最初から高くしすぎないこと。既存コードの現状値から始めて、下げることだけを禁止する「ラチェット方式」が現実的です。
ステップ2：ミューテーションテストで「テストの品質」を測る
Pythonではmutmut（2026年7月時点の最新版は3.6.0）が使えます。ソースコードを機械的に改変（ミューテーション）し、テストがその改変を検出できるかを測定します。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, mutmut 3.x
pip install mutmut
# ミューテーションを生成してテストを実行
mutmut run
# 生き残ったミュータント（=テストが検出できなかった改変）を確認
mutmut results
「生き残ったミュータント」が多いモジュールは、カバレッジが高くてもテストがザルだということです。エージェントに追加テストを書かせる際の具体的な指示材料になります。Java系ならPIT、JavaScript/TypeScriptならStrykerが同種のツールです。
ステップ3：仕様を人間の管轄に残す
Martin氏の戦略の核心は「人間は仕様とテスト戦略を書き、実装は読まない」という分業です。エージェントへの指示を仕様として構造化し、実装を書くエージェントとテストを書くエージェントを分離すると、「実装の誤解に合わせたテスト」が生まれにくくなります。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 運用例: 実装エージェントとテストエージェントを分離するプロンプト設計
#
# テスト担当エージェントへの指示（実装コードを見せない）:
「以下のGherkin仕様だけを読んで、pytestの受け入れテストを書いてください。
既存の実装コードは参照禁止です。仕様に曖昧な点があれば、
コードを推測で埋めずに、最初に質問を返してください。」
この「実装を見せずにテストを書かせる」分離は、前述の「通るだけのテスト」問題への実務的な緩和策です。
【要注意】よくある失敗パターンと回避策
失敗1：制約なしで「読まない」だけ真似する
❌ テスト基盤が弱いまま、レビューを省略して生産性だけ上げようとする
⭕ 段階1→2→3の順で、検証ゲートを整備してからレビュー範囲を絞る
なぜ重要か：Martin氏の発言は「制約で包囲しているから読まなくてよい」という条件付きの主張です。条件を外して結論だけ輸入すると、単なる無検証デプロイになります。
失敗2：カバレッジ数値だけで安心する
❌ 「カバレッジ95%だから品質は大丈夫」と判断する
⭕ ミューテーションテストで「テストがバグを検出できるか」まで確認する
なぜ重要か：アサーションのないテストでもカバレッジは上がります。エージェントは指標を「満たしに来る」ため、指標自体の頑健性が問われます。
失敗3：実装エージェントに自分のテストを書かせて完結させる
❌ 同一セッションのエージェントに実装とテストの両方を任せる
⭕ 仕様だけを渡した別エージェント（または人間）がテストを書く
なぜ重要か：HNで報告されていた「間違った実装に合わせたパスするテスト」は、実装とテストが同じ文脈（同じ誤解）を共有することで起きます。文脈を分離することが最も安価な対策です。
よくある質問
Q. Uncle Bobは「テストも読まない」と言っているのですか？
A. いいえ。読まないと明言しているのは「エージェントが書いたコード」であり、ユニットテスト・Gherkinテスト・QA手順などの制約群は自身で整備していると述べています。仕様とテスト戦略は人間の管轄に残すという分業構造です。
Q. 小規模チームでも真似できますか？
A. 段階2（カバレッジゲート＋CI必須化）までは数人のチームでも今週から始められます。段階3（ミューテーションテスト常時運用＋実装非読）は、テスト実行時間やCIコストが増えるため、重要モジュールに絞って試験導入するのが現実的です。
Q. コードレビューを完全に廃止してよいという意味ですか？
A. 本記事の立場としては推奨しません。特に規制産業では監査要件との整合を先に確認すべきです。また、レビューには品質検証以外の機能（知識共有・設計統一）もあり、それらをテストだけで代替できるかはチームごとの判断になります。
まとめ：今日から始める3つのアクション
- 今日やること：自分のリポジトリで
pytest --cov（相当）を実行し、現状のカバレッジを数値で把握する - 今週中：CIにカバレッジ下限ゲートを入れ、「下げるマージ」を機械的に止める。チームでMartin氏の投稿とHNスレッドを読み、どの段階を目指すか議論する
- 今月中：重要モジュール1つにミューテーションテストを試験導入し、「生き残ったミュータント数」をエージェントへのテスト追加指示に使ってみる
あわせて読みたい：
- AIエージェントの品質テスト自動化ガイド — エージェント出力の検証パイプライン設計を詳しく解説
- AIコードレビューエージェントのツール比較 — 「人間が読まない」場合の代役候補となるレビューエージェントの選定
- AIエージェントのHuman-in-the-Loop承認パターン — 人間の承認をどこに残すかの設計論
参考・出典
- Robert C. Martin氏の当該ポスト（X） — 一次ソース（参照日: 2026-07-28）
- Hacker News: My current strategy is to not read any of the code written by my agents — コミュニティの反応（参照日: 2026-07-28）
- How SQLite Is Tested — SQLite公式。テストコードが本体の590倍という記述の出典（参照日: 2026-07-28）
- Gherkin Reference — Cucumber公式ドキュメント（参照日: 2026-07-28）
- PIT Mutation Testing 公式サイト（参照日: 2026-07-28）
- mutmut — PyPI — Python用ミューテーションテストツール（参照日: 2026-07-28）
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
