Anthropicの男がコードを読むなと言った日
俺はコードを全行読む男だった。
PRが飛んでくる。差分を開く。500行。目を細める。変数名を追う。型を確認する。ロジックの分岐を脳内でシミュレートする。「ここ、なんでこの書き方にしたの？」とコメントを残す。2時間経つ。次のPRが来る。また500行。目がかすむ。コーヒーを淹れる。淹れたコーヒーが冷める頃に、やっと半分。
これが俺の日常だった。コードレビューという名の苦行。いや、苦行なんて言ったら修行僧に失礼か。修行僧は悟りがある。俺にはない。あるのは「LGTM」と書いた後の虚無感だけだ。😮💨
そんな日々に、ある言葉が降ってきた。
Vibe Coding。
🎤 Anthropicの男
2025年のことだ。AnthropicのErik Schluntzが講演で言い放った。
もともとの言葉はAndrej Karpathyのものだ。OpenAIの創設メンバーで、テスラのAI部門長だった男。彼がVibe Codingを定義した。
「完全にvibesに身を委ねろ。指数関数的成長を受け入れろ。コードの存在すら忘れろ」 🌊
最初に聞いたとき、正直に言う。何を言ってるんだこの人は、と思った。コードの存在を忘れる？それ、仕事放棄じゃないの？
でもErikはさらに踏み込んだ。
CursorやCopilotを使ってコードを書く。AIの提案をチェックして、修正して、またAIに投げる。この密なフィードバックループ——これはまだVibe Codingじゃない、と。
「完全にコードから離れること。それが核心だ」 😳
そしてこう続けた。
「コードの存在を忘れろ。でもプロダクトの存在は忘れるな」
ここで俺の脳内に電流が走った。コンパイラの話をしたんだ、Erikは。昔、プログラマーはコンパイラが吐くアセンブリを全行チェックしていた。コンパイラを信用していなかったから。今、アセンブリ出力を確認するプログラマーがどれだけいる？ ゼロだ。コンパイラを信頼するようになった。同じことがコード生成で起ころうとしている。
🌙 22,000行の夜
Erikが語った話で、俺の椅子から落ちそうになったのはこれだ。
Anthropic社内で実際に起きた話。ある強化学習のコードベースに、22,000行の変更を加える必要があった。従来なら2週間かかる作業だ。2週間。10営業日。毎日コードを読んで、書いて、テストして、レビューして、直して、また書いて。想像するだけで目が乾く。👁️
それを1日でやった。
1日だ。朝はじめて、夜には終わっていた。22,000行。 🚀
種明かしはこうだ。
まず、数日間かけて人間が要件を定義した。「何をしたいか」を徹底的に詰めた。ここに手を抜かなかった。15分とか20分じゃない。数日だ。Claudeのために包括的なガイダンスを書いた。
次に、リーフノード戦略。これが味噌だ。🍖
コードベースを木に例える。幹があって、枝があって、葉がある。幹や太い枝——コアアーキテクチャ——に手を出すのは危険だ。他のすべてがそこに依存している。だから葉っぱを狙う。末端のコード。他のコンポーネントが依存していない部分。ここなら、多少のヘマをしても爆発半径が小さい。
そしてレビュー。22,000行を全部読んだか？ 読んでない。 拡張性が重要な部分だけ、人間が重点的にレビューした。あとはテストで担保した。ストレステストを設計して、長時間回して、安定性を確認した。
| 従来のやり方 | Vibe Codingのやり方 |
|---|---|
| ⏰ 2週間 | ⚡ 1日 |
| 📖 全行レビュー | 🎯 戦略的ポイントレビュー |
| 🐢 段階的実装 | 🚀 大規模一括変更 |
| 😰 保守的 | 💪 野心的 |
俺はこの話を聞いて思った。待てよ、これ、CTOが専門外のチームを管理するのと同じ構造じゃないか。 🤔
そう、Erikもそこに触れた。
CTOは自分の専門外の分野のエキスパートを管理する。コードを全行読めなくても、受け入れテストで検証する。プロダクトマネージャーはコードを1行も読めなくても、プロダクトを実際に使って品質をチェックする。CEOは会計のプロじゃなくても、重要な数字のスポットチェックで財務を監督する。
実装の詳細を理解せずに検証できる抽象化レイヤー——これは文明と同じくらい古い問題だった。 そしてソフトウェアエンジニアリングにも、ついにその波が来た。
🔧 俺もやってみた
聞いただけじゃダメだ。やらなきゃ。
Erikの話を参考に、俺も試した。小さいプロジェクトからだ。いきなり22,000行は怖いから。😅
ClaudeのPMになれ 📋
まず意識を変えた。「Claudeが何をしてくれるか」じゃなくて、**「俺がClaudeのために何ができるか」**を考える。Claudeは新入社員だ。優秀だけど、文脈を知らない新入社員。
プロンプトに15分かけた。いや、20分。何を作りたいか。既存のコードベースのどこを見ればいいか。どんなパターンに従ってほしいか。どんなテストが必要か。全部書いた。
最初は面倒くさいと思った。でも、この20分が後の数時間を消し飛ばした。
リーフノードを狙え 🍃
コードベースの依存関係を眺めた。どこが葉っぱか。他のモジュールが依存していない部分はどこか。そこから攻めた。
結果、多少変な実装があっても影響範囲が限定的だった。直すのも楽だった。最初に幹を触ろうとして事故った過去の自分に教えてやりたい。末端からやれ、と。
テストは3つでいい 🧪
Erikが言っていた。テストは処方的にこう要求しろ。
- ハッピーパス（正常系が通ること）
- エラーケース1つ（壊れたときに適切に壊れること）
- もう1つエラーケース（別の角度から壊れてみること）
エンドツーエンドテスト。実装に密結合したユニットテストじゃなくて、入力と出力だけ見るテスト。Claudeは放っておくと実装の中身にべったり張り付くテストを書く。それを矯正してやるのが俺の仕事だった。
Claude Code + Cursorのハイブリッド 🔀
大きい実装はClaude Codeでやる。ターミナルからファイルを探索して、計画を立てて、一気に書く。
細かい修正はCursorでやる。特定の行をピンポイントで直したいとき、VS Codeの中でCursorに指示を出す。
真のVibe Codingではないかもしれない。Erikの定義からすれば、まだコードに触りすぎだ。でもこれが俺にとっての現実的な妥協点だった。完全にコードから離れる勇気は、まだない。まだ。 😶
📈 指数関数の話をさせてくれ
ここからが怖い話だ。
AIが処理できるタスクの長さは、7ヶ月ごとに倍増している。📊
- 今：約1時間のタスクが限界
- 来年：1日分の作業がいける
- 再来年：1週間分の作業が可能
Erikはこうも言った。20年後を「モデルが2倍良くなる」と考えるな。「百万倍賢く速くなる」と考えろ、と。1990年代のコンピュータと今のコンピュータの差だ。あの頃のPCで何ができた？ ソリティアか？ 今は？ リアルタイムで4K動画を編集しながらSlackとZoomを同時に回してる。
同じ桁の変化が、コード生成に起きる。 🌊
Erikはこうも言った。今日、Vibe Codingをしなくても問題ない。今の仕事は今のやり方でこなせる。でも1〜2年後に「俺は全部の行を自分で書く/読む」と言い張っていたら、新しいモデルの恩恵を受けられない。チームのボトルネックになる。
適応する開発者と、しない開発者の生産性格差が指数関数的に開く。 📐
学習の話もした。従来、アーキテクチャの良し悪しを学ぶには2年かかった。プロジェクトを回して、失敗して、また回して。AIで高速イテレーションすれば、6ヶ月で同じ学びが得られる。同じ期間で4倍多くの「試行」が可能になる。
これは怠け者には最悪のニュースだ。表面的な作業で満足する人と、AIを使って深い理解を得ようとする人の差が、これまで以上に開く。個人の学習姿勢がすべてを決める時代。 🎓
🎸 余韻
俺はまだ全行読む癖が抜けない。PRの差分を開くと、つい目が追ってしまう。
でも知ってしまった。22,000行を1日でやった人間がいることを。アセンブリ出力を誰もチェックしなくなったことを。CTOが専門外のコードを読まずに組織を回していることを。
「全行読む」時代は終わる。 たぶん、思っているより早く。
でも「プロダクトを理解する」時代は終わらない。 むしろ、それしか残らない。
コードは読まなくていい。でもプロダクトは見ろ。ユーザーの声は聞け。何を作っているかは忘れるな。
Anthropicの男はそう言っていた。 🎸
Discussion