Anthropic の責任者が教える Vibe Coding マスタークラス

·Toolin 編集部

Anthropic のリサーチャー Erik Schluntz が、本番環境で責任を持って Vibe Coding を使う実戦経験を紹介。22000 行のコードマージ事例、リーフノード戦略、上級テクニックを網羅します。

Anthropic の責任者が教える Vibe Coding マスタークラス

Anthropic のリサーチャー Erik Schluntz(『Building Effective Agents』の共著者)は、手を骨折して2か月ギプス生活を強いられ、すべてのプログラミング作業を Claude に丸ごと任せざるを得なくなりました。この経験から、彼は本番環境で責任を持って Vibe Coding を行うための方法論をまとめ上げました。この方法は X 上で複数の開発者から「有料講座100本分より上」と評価されています。

本物の Vibe Coding とは

多くの人は Cursor や Copilot でコードを生成することを Vibe Coding と同一視していますが、Schluntz はこれは正確ではないと言います。AI が生成したコードをまだ行単位でレビューし修正しているうちは、それは Vibe Coding ではありません。

Karpathy の定義のほうが的確です。「雰囲気に完全に浸かり、テクノロジーの指数関数的な成長を歓迎し、コードの存在を完全に忘れる」こと。

つまり、あなたは「コードを書く人」から「AI を管理するプロダクトマネージャー」へと変わらなければなりません。

なぜ指数関数的な成長を受け入れるのか

AI が自律的に処理できるタスクの長さは、およそ 7 か月ごとに倍増しています。今日の AI でも 1 時間のコーディングタスクなら安定してこなせるので、あなたにはまだ行単位レビューの余力があります。しかし来年、AI が 1 日分、さらには 1 週間分の作業量に相当するコードを一気に生成するようになれば、行単位のレビューは不可能になります。

コンパイラの発展史がそうです。初期の開発者はコンパイラを信頼せず、アセンブリコードを確認していました。システムの規模が拡大するにつれ、より高レベルの抽象を信頼することを学ばざるを得なくなったのです。

核心の方法論:検証可能な抽象レイヤーを見つける

Vibe Coding の核となる理念はこうです。コードの存在を忘れる。しかし、プロダクトの存在だけは常に見失わない。

CTO は受け入れテストで技術エキスパートを管理し、プロダクトマネージャーは体験によって機能設計を検証し、CEO はデータのスライスで財務を確認します。彼らは下層の詳細を見ません。ソフトウェアエンジニアにも、コードを読まなくても検証できる、同じような抽象レイヤーが必要なのです。

「リーフノード」戦略

コードベースの中で、他のモジュールから依存されていない末端の機能や追加コンポーネントが「リーフノード」です。こうした領域では技術的負債が生まれても許容できます。ほとんど変更されないからです。一方、システムの幹と下層アーキテクチャの部分については、エンジニアが依然として深く理解し、厳重に守る必要があります。

実践:AI のプロダクトマネージャーを務める

AI は入社1日目の新人として指導するつもりで向き合います。「この機能を実装して」と投げるだけでは、失敗は目に見えています。

標準的な事前ワークフロー

Schluntz は Claude にコードを書かせる前に、次のことを 15-20 分かけて行います:

  1. AI にコードベースを探索させ、関連ファイルを見つけさせる
  2. AI と一緒に明確な実行計画を立てる
  3. すべてのコンテキストと仕様を1本の独立したプロンプトに集約する
  4. それから Claude に実行させる

このフローのもとでは、タスクの成功率は桁違いに跳ね上がります。

22000 行のコード、その極限事例

Anthropic 内部では最近、強化学習コードベースの本番環境において、22000 行のコード変更をマージしました。その大半は Claude が書いたものです。4つの核心戦略:

  1. プロダクトマネージャー視点の深い指導:事前の計画策定と要件整理に数日を費やす
  2. 変更範囲を厳格に区切る:技術的負債の存在を許容するリーフノードに限定する
  3. 核心領域への人工的な介入:中核ロジックには厳格な人間レビューを実施する
  4. 検証可能なチェックポイントの構築:長時間のストレステストを設計し、システムに明確な入出力基準があることを保証する

もともと2週間かかるはずだった作業は、1 日以内に完了しました。

22000 行のコードをマージした事例

上級テクニック

テスト駆動開発(TDD)について

TDD は Vibe Coding において極めて有用です。テストコードが読めなくても、Claude をより自己整合的にする助けになります。ただし、Claude は特定の実装に過度に依存したテストを書きがちな点には注意が必要です。

推奨されるやり方:Claude に対し、エンドツーエンドのテストは3つだけと強制します -- ハッピーパス+2つのエラーシナリオ。Schluntz はこう言います。「Vibe Coding 中に私が唯一目を通すコードは、たいていテストコードです。テストが通って初めて、信用できると感じます」

コンテキスト管理について

「人間のプログラマーなら昼食に立ち上がる」ような区切りに達したと感じたら、コンテキスト圧縮(Compact)を1回実行します。

おすすめの始め方:まず Claude に関連ファイルをすべて見つけさせ、計画を立てさせます。それらを1つのドキュメントに書き込ませたうえで、すぐに圧縮します。これで、計画策定に費やした 10 万個の Token を、数千個のきれいな Token へと圧縮できます。

複数ツールの併用について

Schluntz は Claude Code と VS Code/Cursor を同時に使っています:

  • Claude Code:主要な変更と大きなタスクを担当
  • VS Code/Cursor:移動しながらコードをレビューしたり、正確な小さな修正を行ったりする

見知らぬコードベースに向き合うときは、まず Claude に探索を任せます。「Auth を処理しているコードはどこ?」「どの機能がこれと似ている?」と聞き、全体像を把握してから手を動かしましょう。

ワークフローのイメージ