AI でより良く、しかしより遅く — Nolan Lawson が壊した '生産性グラフ' の前提
AI でより良く、しかしより遅く — Nolan Lawson が壊した ‘生産性グラフ’ の前提
2026 年 5 月 25 日、Nolan Lawson の短いブログ記事が HN 最上位に上がり 1167 点・433 コメントを集めた。タイトルは率直だ — “Using AI to write better code more slowly”。「AI はコードをより速く書かせてくれる」という通念を真正面から否定する第一文で始まり、「私のコードの品質は上がったが、私の作業速度は上がらなかった」という率直な自己報告で本論を開く。なぜこの一行がその週の最も重いエンジニアリング記事になったのか。
導入 — ‘生産性’ という単一変数の罠
AI コーディングツールの評価は、過去 2 年間ほぼ単一変数に収束してきた — 速度。「何分で作ったか」「1 時間で何行書いたか」「バグを何秒で捕まえたか」。ツール会社の宣伝資料、ユーザーのデモ動画、企業導入発表の報道資料がすべて同じ変数を変奏する。その単一変数のグラフ上でツールの優劣が決まり、採択意思決定が起き、次世代ツールのデザイン方向が定まる。
Nolan Lawson の記事が重い理由は、この単一変数の前提そのものに亀裂を入れるという点にある。記事の冒頭はほぼ挑発に近い — “I haven’t necessarily seen my velocity go up” (私の速度が上がったわけではない)。この一文は Lawson 本人 — Microsoft Edge の元シニアエンジニア、Pinafore の開発者、ウェブ標準コミュニティの活発な貢献者 — の口から出たという点でさらに重い。AI ツールに懐疑的な外部者ではなく、複数の AI ツールを使いこなすシニアエンジニアが 「私の速度は上がらなかった」と報告しているのだ。
そしてその報告に即座に続くもう一行が記事の骨格だ — “But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do” (しかしこの方式のコーディングは、私が元々やろうとしていた種類のプログラミングをより強力にしたバージョンだと感じる)。つまり、AI が速度を上げたのではないが 「より良く」 する次元 では明確な変化があった、という陳述だ。
本稿が解こうとするのは、この二行の診断を受け止めて、Lawson が描く実際のワークフローがどんな種類の「良くする」なのか、そしてその「良くする」がツール評価の基準そのものをどう変えるべきかを見ることだ。
本文 1 — マルチエージェントレビューの実際の動作
Lawson の記事が最初から最後まで具体的なのは、彼が自身の作業ワークフローをほぼコマンド一行単位で書き残しているからだ。中心は一行 — “Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low” (Claude サブエージェント、Codex、Cursor Bugbot を同時に走らせ、この PR のバグを critical/high/medium/low でランキングしてくれ) — にある。
この一行の意味をほどくと、彼がコードを書く方法は次の四段階の反復だ。
第一段階で自分自身がコードの一塊を書く (人 ↔ エージェントのペアでも人単独でも可)。第二段階でその塊に対して 三つの独立したエージェント — Claude サブエージェント、OpenAI Codex、Cursor の Bugbot — を同時に走らせ、バグ・設計問題・テスト欠落をレポートさせる。第三段階で三つのレポートの共通集合と和集合を自分で直接読み、critical / high 等級の項目を再びエージェントに直させる。第四段階でその修正が意図した変化を起こしたかを自分で確認し、意図と異なる副作用があれば最初に戻る。
このサイクルが一周するのに通常、数十分から数時間かかる。もし自分一人でコードを書いていれば数分で終わっていた可能性もある。つまりワークフロー単位の時間で見ると — Lawson の報告どおり — 速度は明らかに遅くなる。
しかしこの遅さの代償が何かを見ると評価の基準が変わる。Lawson は記事の中盤で「発見」の副次効果を描く。エージェントレポートが頻繁に指摘するのは、彼が今書いたコードのバグではなく、そのコードが呼び出す周辺コードに既に存在したバグ だ。1 つの PR のレビューが 5 つの無関係な既存バグを発見させ、その発見が 5 つの「タンジェンシャルサイドクエスト (tangential side-quests)」 — 新しいユニットテストの作成、呼び出しパターンのリファクタリング、ドキュメント補強 — につながる。1 つの PR のレビューが 5 つの新しい PR を生む。
このサイドクエストの時間がグローバル速度の測定値を引き下げる。しかしその時間の産出物はコードベース全体の品質向上だ。「1 つの PR をマージするのに要する時間」で測れば遅くなったが、「3 ヶ月後のコードベース欠陥密度」で測れば明確に改善された。Lawson が指摘するのはこの二つの測定値の分離だ。
本文 2 — ‘意図された遅さ’ の二種類のトレードオフ
このワークフローが単なる自己満足ではなく一般化可能な評価変化のシグナルである理由は、二つの明確なトレードオフを明示化するからだ。
第一のトレードオフは 「トークンコスト ↔ コード品質」 だ。三つのエージェントを同時に走らせるワークフローは、単一エージェントだけのワークフローよりも 3 ~ 5 倍多くのトークンを消費する。Claude / Codex / Bugbot のそれぞれが PR の全コンテキストを再ロードして再推論するからだ。同じ作業のトークンコストが 5 倍になることは、会社の請求書の観点では無視できない数字だ。Lawson のワークフローを会社単位で標準化すれば、前回の記事で扱った Microsoft の「12 ヶ月 AI 予算を数ヶ月で使い切った」事件の直接原因となる。
しかしこのトークンコストの代償が「発見された既存バグの数」だとすれば比較の意味が変わる。1 つの PR のトークンコストが $5 増えたが 5 つの既存バグを発見したなら、その発見一件あたりの追加コストは $1 だ。同じ既存バグを社内 QA が発見する単価はそれよりも一桁大きいケースが普通だ。トークンコストを ROI の分子ではなく分母として見ると、Lawson のワークフローは高くない。
第二のトレードオフは 「開発者の認知負荷 ↔ コード検証の深さ」 だ。マルチエージェントレポートを自分で読んで判断する作業は決して軽くない。Lawson の記事の一段 — HN コメントで Ashton Antony が指摘した部分 — が正確にこの点を強調する。“this approach still requires enough domain knowledge to triage what the agents surface” (このアプローチはエージェントが浮かび上がらせた項目をトリアージできるだけのドメイン知識を要求する)。つまりマルチエージェントレポートはドメイン知識が深いシニアの手でのみ価値を生み、ジュニアが同じワークフローを使えばむしろノイズに埋もれてコード品質が落ちることもある。
この二番目のトレードオフの意味が重い。AI コーディングツールの普遍的約束 — 「ジュニアもシニアのように作業できる」 — が、このワークフロー上では正反対に作用する。シニアはより良くなり、ジュニアは同じツールで遅くなる可能性もある。同じツールが人の既存能力に応じて正反対の方向に作用するということは、ツール評価の基準を ‘tool intrinsic’ ではなく ‘tool ↔ user fit’ に移していく。
別の HN コメンタ Spencer Karenbauer が指す一行 — 情緒の要約 — がこの移行の重みを整理する。“enablement and governance need to be occurring simultaneously” (能力拡張とガバナンスは同時に起きる必要がある)。つまりツールを与えるだけでは足りず、ツールをうまく使うワークフローのベストプラクティスと、そのワークフローがコードベースに生む変化を制御するガバナンスが一緒に敷かれなければならない、という診断だ。
本文 3 — ツール評価基準の再整列
この二つのトレードオフを受け入れれば、AI コーディングツールの評価基準が再整列される。以前の単一変数 (速度) から、少なくとも四つの変数が同時に測定される多変数評価に移っていく。
第一変数は依然として 速度 だ。消えはしない。しかし単独変数ではない。
第二変数は 品質の時間微分 だ。同じツールを 3 ヶ月使ったコードベースの欠陥密度がどう変わるか。静的解析の警告数、テストカバレッジの流れ、プロダクションバグ発生頻度などで測定される。Lawson のワークフローは第一変数で損をして第二変数で得をする。ツール導入決定はこの二つの合算を見る。
第三変数は トークン単価あたりの発見数 だ。同じ 100 万トークンを消費するときに発見される既存バグの数、あるいは作成されるユニットテストの数はいくらか。この変数がツールの効率性 (efficiency, 速度ではない) を測定する。トークン価格が外部変動変数であることを踏まえれば、この変数の測定値が同じツールの価値を時点に応じて異なるものにする。
第四変数は ユーザー能力分布上の効果曲線 だ。シニア / ミドル / ジュニアのそれぞれのコード品質変化がどう分布するか。Lawson のワークフローが示唆するように、同じツールがシニアには +30 % の品質向上を、ジュニアには −10 % の品質低下をもたらすなら、そのツールの会社単位の効果はユーザー構成に大きく依存する。評価段階でこの分布を測らないことは、ツール導入意思決定の最大の死角だ。
四つの変数が同時に測定されれば、ツールの優劣は単純な順位ではなく「どんな種類の使用シナリオでどんな種類のユーザーにどんな種類の価値を生むか」のマトリクスで表現される。Lawson の記事が投げかける最大の含意がこれだ。ツール評価の単純さが終わり、評価の多層化が始まる。
結論 — ‘遅さ’ を意図するエンジニアの新しいアイデンティティ
Lawson の記事が HN の 1167 点を集めた本当の理由は、この記事が単なるワークフロー報告ではなく エンジニアの新しいアイデンティティ宣言 だからだ。「AI が私をより速くしなければならない」という外部の期待を、「AI は私をより良くする、より速くするとは限らない」と再定義する宣言だ。433 件のコメントのうち多数が自身の経験で同じ宣言を変奏したことが、そのアイデンティティ宣言が広く共鳴した証拠だ。
このアイデンティティ宣言が産業に投げかける重みは二つに分かれる。第一に、ツール会社のマーケティング言語が多層化される圧力 が生まれる。「5 倍速い開発」という単一の約束は、シニアエンジニアのユーザー層ではもはや魅力的なメッセージではない。「同じ時間で 5 倍深いレビュー」または「1 つの PR の 5 つの既存バグ自動発見」のような、より精密なメッセージが必要だ。既に一部のツール会社 (Cursor, Cognition) はこの方向へメッセージを調整し始めている。
第二に、会社のエンジニア評価指標が再編される圧力 が生まれる。「PR 処理速度」だけでエンジニアを評価する会社では、Lawson のワークフローに従うエンジニアは罰せられる。そのワークフローが生むコードベース品質の向上が、エンジニア一人の評価指標に反映されないからだ。評価指標が「コードベース欠陥密度の時間微分」のようなチーム単位指標で補完されなければ、会社はより良いツールを使う人をより悪く評価する矛盾に陥る。
最後に一つの問いを読者に投げかけて閉じる。我々が AI ツールを評価するとき、我々は本当に我々のワークフローがどの方向へ移っているかを測っているか。「速度」という単一変数のグラフ上だけで見れば、Lawson のワークフローは後退だ。しかしそのグラフの隣に「品質の時間微分」のグラフを置けば、同じワークフローは前進だ。我々は二つのグラフを並べて描いてみたことがあるか、それとも一つだけ描いているか。その答えが次の 6 ヶ月のツール導入意思決定の正確さを決める。
出典: