Anthropicのコーディングエージェント研究者が「本番環境でのVibe Coding」という、一見矛盾するテーマに正面から向き合った。2025年5月22日、サンフランシスコで開催された「Code w/ Claude」イベントで、Erik Schulntz（Anthropic Member of Technical Staff）が語った内容は、ゲームや趣味アプリの話ではなく、実際にAnthropicの強化学習本番コードベースに2.2万行のPRをClaudeで実現した実体験に基づくものだった。
この記事では本番環境でのVibe Coding実践に特化して解説します。Vibe Coding全般の入門・ツール選定は Vibe Codingとは？2026年完全ガイド｜AIコーディングの始め方・ツール比較・実践ワークフロー をご覧ください。
Vibe Codingとは何か——Karpathyの定義とAnthropicの解釈
「多くの人がVibe CodingをAIでコードを大量生成することだと勘違いしている。でもそれは正確ではない」
ErikはCursorやGitHub Copilotの使い方と、真のVibe Codingを明確に区別した。Cursorでコードを生成しながらレビューして修正する——このタイトなフィードバックループを維持している限り、それはVibe Codingではないと言う。
本当のVibe Codingは、元Tesla AIディレクターのAndrej Karpathyによる定義に立ち返る必要がある。
「バイブに完全に身を委ね、指数関数を受け入れ、コードが存在することすら忘れる」 — Andrej Karpathy（2025年2月）
キーワードは「コードが存在することすら忘れる」だ。これがなぜ重要かというと、Vibe Codingは初めてエンジニアリング業界外の人々がコード生成に興奮したタイミングだったからだ。CopilotやCursorはエンジニア向けのツールだったが、Vibe Codingによってコーディングをしたことのないデザイナーやビジネスオーナーが、会話だけでアプリを作れるようになった。
ただし、初期のVibe Codingが成功したのは「ゲーム」「サイドプロジェクト」「バグがあっても問題ない低リスクなもの」に限られていた。APIキーのexpose、サブスクリプション迂回、DBへの無許可書き込み——Vibe Codingのダウンサイドはまさに本番環境の話だった。
では、なぜ本番でのVibe Codingを考えるのか。Erikの答えは「指数関数」にある。
なぜ今、本番でVibe Codingを考えるべきか——7ヶ月で2倍の能力拡張
「AIが処理できるタスクの長さは7ヶ月ごとに2倍になっている。現在は約1時間分。」
1時間分のタスクであれば、今はまだ人間がレビューできる。Cursorにフィーチャーを書かせて、全コードを確認しながら進める。それは十分に機能する。
問題は、1年後、2年後に何が起きるかだ。
- 現在（2025年）: AIが1時間のタスクを処理
- 1年後: AIが1日分の作業を処理
- 2年後: AIが1週間分の作業を処理
1週間分のコードを人間が逐行レビューするのは不可能だ。Erikはここでコンパイラのアナロジーを持ち出す。
コンパイラが登場した当初、多くの開発者はアセンブリ出力を手動で確認していた。しかし規模が大きくなると、それはスケールしなかった。今や誰もコンパイラが生成したアセンブリを読まない。抽象化レイヤーを信頼するように進化したのだ。
AIコーディングも同じ道を歩む。問題は「どうやって安全に信頼するか」だ。
1時間のタスク
逐行レビュー可"] -->|7ヶ月で2倍| B["1年後
1日のタスク
部分レビューが限界"] B -->|7ヶ月で2倍| C["2年後
1週間のタスク
ボトルネック化"] C -->|適応できれば| D["Vibe Coding in Prod
検証可能な抽象化
レイヤーで管理"] C -->|適応できなければ| E["ボトルネック
競合に取り残される"] style D fill:#22c55e,color:#fff style E fill:#ef4444,color:#fff
Erikのメッセージはこうだ。「今日Vibe Codingしなくても大丈夫。でも1〜2年後には、新しいモデルが大量のコードを一度に生成できるようになったとき、全行を自分でレビューするという姿勢が巨大な不利益になる。」
「コードを忘れても製品を忘れるな」——抽象化レイヤーを通じた検証
「実装を理解せずに管理するという問題は、文明と同じくらい古い問題だ」
Erikはここで鋭い指摘をする。エンジニアは自分たちが直面しているこの問題を「新しい問題」だと思いがちだが、実は管理職が日々やっていることと同じだ。
| 役割 | 実装を理解しなくても | どうやって検証するか |
|---|---|---|
| CTO | 部下の専門ドメインを全部理解しない | 受け入れテストを書いて検証 |
| PM | エンジニアの書いたコードを全部読まない | 製品を実際に使って確認 |
| CEO | 経理の全仕訳を自分では処理できない | 重要な数値のサンプルチェックで信頼度を構築 |
| 今後のエンジニア | AIが書いたコード全行を読まない | 検証可能な抽象化レイヤーで確認 |
「エンジニアはこれに慣れていない。個人貢献者としてスタックの最下層まで全部理解するのが当たり前だった。でも最も生産性を上げるためには、マネージャーが細部を手放すように、エンジニアも手放す必要がある。」
ただしErikは一つの重要な注意点を挙げた。技術的負債だけは現時点で検証が難しい。CFOの例や製品マネージャーの例と違い、技術的負債は「コードを読まずに検証する手段」がまだ整っていない。これが、Vibe Codingをどこにでも無制限に適用できない理由だ。
リーフノード戦略——技術的負債を封じ込める設計思想
「技術的負債の問題を克服するためのアドバイスは：コードベースのリーフノードに集中すること」
リーフノードとは、ツリー構造のコードベースにおいて何も依存していないコードの部分だ。エンドフィーチャー、最終的な機能の実装がこれにあたる。
（人間が守る）"] --> Branch1["ブランチ1
（人間レビュー）"] Core --> Branch2["ブランチ2
（人間レビュー）"] Branch1 --> Leaf1["🍂 リーフノード
Vibe Coding OK"] Branch1 --> Leaf2["🍂 リーフノード
Vibe Coding OK"] Branch2 --> Leaf3["🍂 リーフノード
Vibe Coding OK"] Branch2 --> Leaf4["🍂 リーフノード
Vibe Coding OK"] style Core fill:#1e40af,color:#fff style Branch1 fill:#1e40af,color:#fff style Branch2 fill:#1e40af,color:#fff style Leaf1 fill:#f97316,color:#fff style Leaf2 fill:#f97316,color:#fff style Leaf3 fill:#f97316,color:#fff style Leaf4 fill:#f97316,color:#fff
リーフノードに技術的負債があっても、それほど問題ではない理由が2つある：
- 何も依存していない。リーフノードのコードが汚くても、他のコードに影響しない
- 変更頻度が低い。最終機能の実装は、コアアーキテクチャほど頻繁に変更されない
対照的に、コアアーキテクチャ（幹と枝）は：
- 他の多くのコードが依存している
- 将来的にさらにコードが積み重なる
- 拡張性・理解容易性・柔軟性が致命的に重要
「コアアーキテクチャだけは、エンジニアが深く理解し続けなければならない。なぜならそこに次の変更が積み重なるからだ。」
ErikはClaude 4モデルについても言及している。「過去1〜2週間でClaude 4モデルを使った結果、3.7よりはるかに高い信頼を置けるようになった。今後、モデルの品質向上に伴って、このリーフノード/コアの境界はさらに押し下げられていく」と語った。
ClaudeのPMになれ——事前準備15〜20分が成否を分ける
「Ask not what Claude can do for you, but what you can do for Claude.（クロードに何をしてもらえるかを問うな、クロードのために自分が何をできるかを問え）」
これがErikのVibe Coding成功の核心だ。Vibe Codingにおいて、あなたの役割はClaudeのプロダクトマネージャーだ。
多くの人はAIに「このフィーチャーを実装して」「このバグを直して」と短いプロンプトを送る。しかし、それは新入社員の初日に何の説明もなく「このフィーチャーを実装して」と言うようなものだ。人間の新入社員なら絶対に成功しない。
Claudeが成功するために何が必要か、Erikが提示したチェックリスト：
【Claudeに渡す事前コンテキスト】
1. コードベースのツアー
- 関連するディレクトリ構造
- 類似フィーチャーの実装例
- 従うべきコーディングパターン
2. 要件と仕様
- 変更したいものの具体的な要件
- 何が「完了」の定義か
- パフォーマンス・セキュリティ制約
3. 変更するファイルの候補
- Claudeと別会話でコードベースを探索
- どのクラス・ファイルを変更するか特定
4. 制約事項
- 変えてはいけない部分
- 依存しているインターフェース
- 後方互換性の要件
「このプランを作るために、別の会話でClaudeと一緒に15〜20分かけてコードベースを探索し、計画を立てる。そのアーティファクト（文書）ができたら、新しいコンテキストでClaudeに実行させる。この準備をすると、Claudeの成功率が劇的に上がる。」
具体的なプロンプトの例：
# Claude Codeでの事前探索プロンプト例
"""
このコードベースで認証（auth）がどこで実装されているか教えてください。
1. 認証に関連するファイル名をリストアップ
2. 使用しているクラス・関数名を特定
3. 似たフィーチャー（例：ユーザーセッション管理）の実装パターンを確認
4. この変更で影響を受けそうなテストファイルを特定
最終的に、新しい認証プロバイダーを追加するためのPRを作成したいです。
何を変更する必要があるか、計画を立ててください。
"""
もう一つ重要な点：「Vibe Codingは誰もがやれるわけではない。全く技術を知らない人が一から本番プロダクトを作ろうとするのは危険だ。なぜなら、彼らはClaudeを正しい方向に導くための正しい質問をする能力がない。」
非技術者がVibe Codingできる範囲は、ゲームやサイドプロジェクトなど低リスクなものに留めるべきというのがErikの見解だ。
2.2万行の本番PRをどう実現したか——Anthropicの実例
「実際にAnthropicの強化学習本番コードベースに2.2万行の変更を加えるPRを、Claudeによって書いた。」
これは、Vibe Codingが「おもちゃプロジェクト」だけのものではないことを示す強力な実例だ。Erikは実際のGitHub PRのスクリーンショットをスライドで見せながら、どうやって実現したかを5つのポイントで説明した。
成功要因1：Claudeの”PM”としての事前作業
「これは単一のプロンプトで作ったものではない。何日もの人間の作業が入っている。要件を定義し、システムの設計を決め、Claudeを誘導し続けた。」
大量のコードをAIに書かせたとしても、その前後に十分な人間の思考が必要だ。
成功要因2：リーフノードへの集中
変更の大部分を、コードベースのリーフノード部分に集中させた。「近い将来変わらないと分かっていた部分にVibe Codingを適用した。」
成功要因3：コアアーキテクチャの人間レビュー
拡張性が重要な部分——他から依存される、将来変更が加わる——については重点的な人間レビューを行った。リーフノードとコアの区別が重要だ。
成功要因4：ストレステストの設計
「安定性への最大の懸念事項は、コードを読まずにストレステストを作って長時間実行することで検証できるように設計した。」
# ストレステストの設計思想（擬似コード）
def stress_test_new_rl_system():
"""
コードを読まなくても「正しく動いているか」を
外部から検証できるテスト設計
"""
# 入力と出力を明確に定義
for scenario in edge_case_scenarios:
result = new_system.process(scenario.input)
assert result.matches_expected_behavior(scenario.expected_output)
# 長時間の安定性テスト
for _ in range(10000):
result = new_system.process(random_valid_input())
assert result.is_stable() # クラッシュ・メモリリーク等がない
成功要因5：検証可能なI/Oの設計
「システム全体を、コードを読まなくても正しいかどうか確認できる入出力で設計した。」
これは重要な設計原則だ。コードの内部を知らなくても、入力に対して期待通りの出力が出るか確認できるように、最初からシステムを設計する。
この結果として何が起きたか：
セキュリティ・TDD・ワークフロー——Q&Aが明かした実践ノウハウ
「Code w/ Claude」セッションのQ&Aは、実際に現場でVibe Codingを実践している参加者からの鋭い質問が集まった。Erikの回答から実践的なノウハウを整理する。
セキュリティ問題への対処法
「Vibe Codingされたアプリのトップ10が脆弱性まみれだという報告がある。リーフノードレベルでも安全性と効率性をどうバランスするか？」
Erikの回答：「これはClaudeのPMになることに全て集中する。何が危険で何が安全かを知っていれば、Claudeを正しい方向に誘導できる。Vibe Codingで問題になるのは、そもそも本番でコードを書くべきでない人が書いてしまうケースだ。」
Anthropicの2.2万行PRが安全だった理由は具体的だった：「完全オフラインで動作するシステムだった。だからセキュリティ問題が発生し得ないことを確信できた。」
今後については、「バックエンドの重要部分（決済、認証）が証明済み・安全な既製品として提供され、フロントエンドのUI層だけをVibe Codingで作れる、プロバブルコレクトなフレームワークが出てくることを期待している。Claude Artifactsはその方向性の一例だ。」と語った。
TDDとVibe Codingの統合
「Claudeが実装を全部書いてからテストを書くパターンになりがちで、テストが失敗することも多い。テスト駆動開発をどうVibe Codingに組み込むか？」
Erikの推奨アプローチ：
# Claude Codeに渡すTDD指示の例
まずテストを書いてください。実装はまだ書かないでください。
テストの要件：
- エンドツーエンドのテストを3本のみ書く
1. ハッピーパス（正常な入力と期待される出力）
2. エラーケース1（不正な入力）
3. エラーケース2（エッジケース）
- 実装の詳細に依存しすぎない汎用的なテストにする
- テストファイルを見せてください。内容を確認してからGoを出します
テストを確認・承認した後、実装を書いてください。
「テスト駆動開発はVibe Codingと非常に相性がいい。たとえ自分でテストを全部確認しなくても、Claudeが多少なりとも自己一貫性を保つのに役立つ。コード全体を読む前にまずテストを読むのが良い。テストが正しければ、コードもかなり正しい可能性が高い。」
学習への影響
「これまではライブラリの使い方を覚えたり、コンポーネント間の接続でつまずいたりする中で学んでいた。Vibe Codingで学習の機会が減らないか？」
Erikは「心配な面と楽観的な面の両方がある」と答えた。
懸念点: 「泥臭い実装経験」が減る可能性がある。かつての教授が「アセンブリを手で書かないから今の開発者は弱い」と言ったように。
楽観的な面: 「Claudeと一緒にコードをレビューしながら、知らないライブラリに出会ったら『これは何？なぜ別のものではなくこれを使ったの？』と聞ける。常にいるペアプログラマーが学習を加速する。」
さらに重要な点：「アーキテクチャの良し悪し・PMFにつながるフィーチャーかどうかといった高レベルな判断力を、従来より4倍速く学べるようになる。今まで大きなアーキテクチャ変更の結果を見るのに2年かかっていたのが、6ヶ月に縮まれば、同じ時間で4倍の経験が積める。」
事前プランニングの適切な量
「全く実装詳細を渡すのか、完全な要件定義書を渡すのか、バランスは？」
「ケースバイケース。何を気にするかによる：
- 実装方法を気にしない場合：要件だけ渡す
- コードベースをよく知っている場合：具体的なクラスや実装パターンまで指示する
重要なポイントはモデルを過度に制約しないこと。厳格なフォーマットや細かすぎる仕様は逆効果になることが多い。ジュニアエンジニアが成功するために何が必要か、と考えるのが良い目安。」
Claude Code + Cursorのワークフロー
「ターミナルとVS Code/Cursor、どちらのワークフローをメインに使っているか？Claude Codeをどの頻度でコンパクトするか？」
Erikのワークフロー：
# 典型的なVibe Codingワークフロー
# フェーズ1: Claude Codeで計画を立てる
# → コードベース探索・ファイル特定・計画文書作成
# フェーズ2: コンパクト（計画作成の10万トークンを数千トークンに圧縮）
# → /compact または新規セッション開始
# フェーズ3: Claude Codeでメイン実装
# → VS Codeのサイドバーでコードをレビューしながら進行
# フェーズ4: Cursorで微調整
# → 「この特定の行だけ変えたい」という具体的な変更はCursorで
「コンパクトのタイミングは『人間のプログラマーなら昼食に行くような自然な区切り』。計画を立て終えてドキュメントに書き出した後、コンパクトして新たに実装フェーズに入るのが典型的なパターン。」
「複数のClaude Codeを並列で走らせてgit worktreeでマージする方法もある。私は通常はClaude Codeで始めて、具体的な変更はCursorを使う。使い分けが自然にできてきた。」
新しいコードベースへの入り方については：「フィーチャーを書こうとする前に、まずClaude Codeにコードベースを探索させる。『この認証はコードベースのどこで実装されているか教えて』『この機能と似たフィーチャーを教えて、ファイル名とクラス名も』というプロンプトで、メンタルマップを構築してから作業に入る。」
Vibe Codingの未来——「機械の愛の恩寵は製品ロードマップ」
「指数関数を受け入れる」というKarpathyのフレーズについて、参加者から「具体的に何を意味するのか」という質問が飛んだ。
Erikはこう答えた：「モデルが良くなり続けるということだけではなく、想像もできないくらい速く良くなるということ。」
コンピュータの歴史との対比が鮮明だ。1990年代にコンピュータを触っていた人は、「ちょっとずつRAMが増える」程度の進歩しか想像できなかった。しかし実際には、数十年でテラバイト級になった——数百万倍の性能向上だ。
「Dario AmodeiとMike KriegerのトークからQuoteすれば、『機械の愛の恩寵（Machines of Loving Grace）はSFではなく、製品ロードマップだ』。それくらい、指数関数は予想より野生的に動く。」
20年後にモデルが「今の2倍良くなった」ではなく「今の100万倍速く賢くなった」と仮定した時に何が起きるかを考えるのが、正しい指数関数の受け入れ方だとErikは言う。
Erikはセッションの締めくくりとして5つのポイントを残した：
1. ClaudeのPMになれ：「Claudeに何をしてもらえるか」ではなく「Claudeのために何ができるか」を問う
2. リーフノードに集中する：コアアーキテクチャと基盤システムには人間の目を向け続ける
3. 検証可能性を設計する：コードを読まなくても正しいと確認できる入出力とテストを設計する
4. 指数関数を忘れない：今日は問題なくても、1〜2年後に適応しない姿勢は大きなハンデになる
5. ボトルネックを避ける：全行のコードを自分で書き・読むという姿勢を手放す準備をする
「ソフトウェアエンジニアリング業界にとってこれが今後数年で最大の課題になる。本番でのVibe Coding——これが次の大きなテーマだ。」
まとめ：Vibe Coding in Prodの現実
Erikの発表を通じて見えてくるのは、Vibe Codingが「全部AIに任せる」ではなく「人間の判断力を高位の抽象層に集中させる」という戦略だという点だ。
| 従来のエンジニアリング | Vibe Coding in Prod | |
|---|---|---|
| コードの所有 | 全行を読んで理解 | リーフノード以外は深く理解 |
| 品質保証 | コードレビュー | ストレステスト＋I/O検証 |
| 人間の役割 | 実装者 | PM・設計者・検証者 |
| 学習速度 | 2年で1サイクル | 6ヶ月で1サイクル |
| 制約 | 個人の速度が上限 | AIの速度が上限 |
| リスク | バグ・レビュー漏れ | 技術的負債の蓄積（リーフノード内） |
「コンパイラを信頼してアセンブリを読まなくなった歴史が繰り返される。今度は、AIが書いたコードを信頼するための抽象化レイヤーを私たちが構築していく番だ。」
Vibe Codingに対して「おもちゃの話だ」「本番では使えない」と言い続けることは、1990年代に「アセンブリを確認しないコンパイラなんて信用できない」と言い続けることと同じになっていく——Erikの発表はそれを真剣に考えさせてくれる内容だった。
TDD×Vibe Codingの組み合わせをさらに深掘りしたい場合は Superpowers徹底解説2026｜TDD強制×7段階ワークフローでAIコーディングが激変する が参考になる。AIコーディングツールの選定については Continue vs Cursor徹底比較：無料OSSのAIコーディング拡張は$20の代替になるか も合わせて確認してほしい。
参照ソース
-
[Vibe coding in prod Code w/ Claude — YouTube (Anthropic公式)](https://youtu.be/fHWFF_pnqDk) — 本記事のベースとなった発表動画。Erik Schulntz（Anthropic MTS）が2025年5月22日に行ったセッション - Building effective agents — Anthropic Research Blog — Erik Schulntz / Barry Zangが執筆したエージェント設計のベストプラクティス
- Andrej Karpathy on vibe coding — X.com (2025年2月) — Vibe Codingの概念を定義したKarpathyの元ポスト
- Claude Code — Anthropic公式ドキュメント — Claude Codeのコンパクト機能・セッション管理等の公式仕様
