本番でバイブコーディングを責任を持ってやる方法 — Erik Schluntz (Anthropic Code with Claude)

Code with Claude (Anthropic) 2026/04/20

エリック・シュランツ / Erik Schluntz · 00:38 「自転車事故で手を骨折して 2 ヶ月ギブス生活、その間 Claude が私のコードを全部書いていた」

Code with Claude (Anthropic、 2025 開催) のテクニカルトーク、約 31 分。発表者: エリック・シュランツ (Erik Schluntz、 Anthropic Programming Agents 担当、 Building Effective Agents 共著者)。「本番でバイブコーディングを責任を持ってやる方法」を Anthropic 内部の実体験から語る

エリック・シュランツは Anthropic のリサーチャーで、 Claude Code をはじめとするコーディングエージェント (Programming Agents) を担当する。 Building Effective Agents (Anthropic 公式ブログ、 2024/12) の共著者の 1 人 (Barry Zhang と共同)、業界で最もよく引用されるエージェント設計指針を作った人物。この 31 分のトークは、 Code with Claude (Anthropic、 2025 開催) でのテクニカルセッション。

講演冒頭の個人エピソードが強烈: 「昨年、通勤中の自転車で手を骨折し、 2 ヶ月ギブスをしていました。その 2 ヶ月間、 Claude が私のコードを全部書いていました」 (00:38 - 00:46)。怪我による偶発的な制約から、「本番環境で AI に責任を持ってコードを書かせる方法」を実体験で確立し、それを Anthropic 内部の AI 駆動開発文化に持ち込んだ — という個人史が、講演全体の信頼性の源泉になっている。

講演の核心は「 Karpathy の vibe coding 定義を真面目に受け止めて本番に持ち込む」という発想。「Cursor や Copilot で AI とタイトなフィードバックループを回している人は、厳密にはバイブコーディングしていない」 (01:21)。真のバイブコーディングは「コードが存在することすら忘れる」完全自動状態。そして「コードの存在は忘れるが、プロダクトの存在は忘れない」 (04:55) という Schluntz 独自の拡張で、本番運用への橋渡しを設計する。

31 分で扱われる中心テーマは 5 つ。 (1) 指数関数 — AI が扱えるタスクの長さは 7 ヶ月ごとに倍増、今は 1 時間、 1-2 年後は 1 日、 1 週間に。ロックステップで追いつくのは不可能。 (2) 古い問題の新しい姿 — CTO が技術専門家を、 PM がエンジニアを、 CEO が会計士を管理する問題と同じ。自分が理解していない実装を管理するのは文明と同じくらい古い課題。 (3) 葉ノード戦略 — 他の何にも依存されていないコード部分にバイブコーディングを集中。コアアーキテクチャは人間が深く理解する。 (4) Claude の PM になれ — JFK 風の「Claude が君のために何ができるか、ではなく、君が Claude のために何ができるかを尋ねよ」、 15-20 分のコンテキスト構築投資。 (5) 実証 — 22,000 行 PR を 1 日でマージ — Anthropic 内部での本番強化学習コードベースへの大規模変更を、葉ノード集中 + 検証可能チェックポイント設計で達成。

着眼点

「2 ヶ月ギブス生活 + Claude が私のコードを全部書く」という個人体験 (00:38 - 01:02)

Schluntz の主張全体の信頼性の源泉。「昨年、通勤中の自転車で手を骨折し、 2 ヶ月ギブスをしていました。その 2 ヶ月間、 Claude が私のコードを全部書いていました」 (00:38 - 00:46)。

「これを効果的に実現する方法を見つけ出すことは、私にとって本当に重要でした」 (00:46 - 00:51)。物理的に書けない、という外部制約が、「AI 駆動開発のベストプラクティス」を自然な実験室にした、という構造。そして得られた知見を Anthropic の他のチームや、モデル訓練に取り込んだ — 個人体験が組織知識化される経路の好例。

この個人エピソードは講演を貫く。「Claude の PM になる」「葉ノード戦略」「コンテキスト構築投資」のすべてが、 2 ヶ月間の実地検証から出た実用主義。抽象的フレームワークではなく、「コードを書けない研究者が必要に迫られて編み出した」という制約駆動の発想として読むと、講演全体の説得力が上がる。

真のバイブコーディング定義 — 「コードが存在することすら忘れる」 (01:00 - 04:00)

Schluntz の整理: 「多くの人がバイブコーディングを『AI でコード生成を大量にやること』と混同しがち。でもそれは正確じゃない」 (01:00)。 Cursor や Copilot で AI とタイトなフィードバックループを回している人は、厳密にはバイブコーディングしていない。

Karpathy の定義を引用: 「『完全にバイブに身を委ね、指数関数を受け入れ、コードが存在することすら忘れる』。ここで重要なのは『コードが存在することすら忘れる』という部分」 (01:34 - 01:48)。これは Karpathy の AI Ascent 2026 講演と完全に整合する。

バイブコーディングのマイナス面とプラス面の整理。マイナス: 「初めてコーディングする人が、何をしているか分からない状態で、 API キーの上限超過、サブスクリプションのバイパス、 DB に変なデータ」 (02:18 - 02:33)。プラス: 「ビデオゲーム、楽しいサイドプロジェクト、バグがあっても OK な領域」 (02:42 - 02:49)。 Schluntz の課題提起: 「成功例がトイみたいな賭け金の低い領域に限られているなら、なぜバイブコーディングを気にすべきなのか?」 (02:54 - 03:09)。答えは次の節で。

指数関数 — 7 ヶ月ごとに 2 倍、来年は 1 日、再来年は 1 週間 (03:09 - 04:30)

Schluntz が提示する最も具体的な数字: 「 AI が扱えるタスク長の指数関数。 AI ができるタスクの長さは 7 ヶ月ごとに倍になっている。今は約 1 時間」 (03:14 - 03:20)。

これで OK な未来の話: 「Claude Code に 1 時間かかる機能を書かせて、全部レビューして、密接に関わり続けられる」 (03:24 - 03:38)。

でも 2 ステップ先を見ると恐怖: 「来年はどうなる? 再来年は? AI が 1 日分の作業や 1 週間分の作業を一度に生成できるほど強力になった時、ロックステップで動こうとする限り、とても追いつけない」 (03:42 - 03:59)。結論: 「この指数関数の恩恵を受けたいなら、責任を持って身を委ね、活用する方法を見つける必要がある」 (04:01 - 04:09)。

この数字は Karpathy の AI Ascent 2026 講演の「12 月の転換点」「100 万倍速くなったコンピューター」議論と整合する。業界の独立した発信源が同じ未来像を共有している、という多元的根拠。

コンパイラのアナロジー — 「アセンブリを読まずに信頼する」 (04:30 - 06:00)

Schluntz の比喩。「コンパイラの初期、多くの開発者は本当に信用していなかった。コンパイラを使うけど、出力されたアセンブリを読んで、自分が書くのと同じか確認していた」 (04:35 - 04:46)。「でもそれはスケールしない。ある時点で大きなシステムを扱う必要が出てきて、システムを信頼するしかなくなる」 (04:46 - 04:54)。

Schluntz 独自の本番版定義: 「コードが存在することは忘れるが、プロダクトが存在することは忘れない」 (04:55 - 05:01)。

コンパイラ類比の完成: 「コンパイラのアナロジーに戻ると、私たちは下層にアセンブリがあることは皆知っている、でもほとんどの人は実際のアセンブリを考える必要はない。それでもアセンブリの理解なしに良いソフトウェアを作れる。ソフトウェアも同じレベルに到達すると思う」 (05:01 - 05:25)。抽象化の層が上がる、という業界進化の常套句を AI 時代に当てはめる。

古い問題の新しい姿 — CTO / PM / CEO の管理問題 (06:00 - 08:30)

Schluntz の強い指摘: 「これは新しい問題ではない」 (06:00)。「CTO はどうやって、自分が専門家ではない領域の専門家をマネジメントするか? PM はどうやって、自分が読めないコードで作られた機能をレビューするか? CEO はどうやって、財務会計の専門家でなくても会計士の仕事をチェックするか?」 (06:08 - 06:24)。

これらは何百年、何千年も存在した問題で、解決策がある: 「CTO は実装を理解していなくても受け入れテストを書ける」「PM はプロダクトを実際に使って期待通り動くか確認できる」「CEO はスポットチェックで信頼を構築できる」 (06:30 - 07:05)。

Schluntz の哲学的結論: 「自分が理解していない実装をマネジメントするのは、実は文明と同じくらい古い問題。世界中の全マネージャーが既にこれに対処している。ただ、私たちソフトウェアエンジニアは慣れていない。スタックの底まで完全に理解する純粋な個人貢献者に慣れている」 (07:08 - 07:38)。「最も生産的になるには、これを手放す必要がある」 (07:38 - 07:46)。

安全に・責任を持って手放す方法: 「抽象化層の検証可能性を見つけること — 下層の実装を知らなくても検証できる層」 (07:48 - 08:00)。これが講演全体の中核的設計原理。

技術的負債 — 検証可能性の唯一の例外 (08:30 - 11:00)

Schluntz の率直な但し書き: 「ただし、一つ但し書きがあります — 技術的負債 (Tech Debt) です」 (08:30)。

問題: 「今のところ、自分でコードを読まずに技術的負債を測定・検証する良い方法はない。他のシステム — 会計士の例、 PM の例 — では、実装を知らなくても気にする部分を検証する方法がある。でも技術的負債は、実装の専門家になる以外に良い検証方法がない稀なもの」 (08:30 - 09:04)。

Schluntz の解 — 葉ノード戦略: 「コードベースの『葉ノード』にフォーカスする。他の何にも依存されていないコードやシステムの一部 — 末端の機能、ベル・ホイッスル」 (09:16 - 09:31)。

なぜ葉ノードは安全か: 「葉ノードに技術的負債があってもまあ OK。他に何も依存していないから。変更される可能性が低い、さらに何かが上に構築される可能性も低い」 (09:36 - 09:51)。一方、コア (システムの幹と下層の枝) は: 「コアアーキテクチャで、エンジニアとして深く理解する必要がある。ここが変わる場所、他のものがその上に構築される場所」 (09:55 - 10:05)。

Schluntz の楽観的補足: 「モデルは常に良くなっている。拡張可能で技術的負債のないコードを書かせて信頼できる世界に向かう可能性がある。 Claude 4 モデルでは 3.7 よりはるかに信頼している」 (10:10 - 10:25)。葉ノードの境界が時間とともに広がる、という展望。

「Claude の PM になれ」 — JFK 風の方針 (11:00 - 13:30)

Schluntz の最も引用しやすい一文: 「 Claude の PM になれ。 Claude が君のために何をできるか、ではなく、君が Claude のために何をできるかを尋ねよ」 (11:09 - 11:15)。 JFK の 1961 年就任演説の本歌取り。

具体的なアドバイス: 「チームの新人がこのタスクで成功するには、どんなガイダンスや文脈が必要か? 私たちは AI と素早い往復チャットに慣れすぎている — 『この機能を作って』『このバグを直して』」 (11:24 - 11:51)。

でも実際は: 「人間が入社初日に『この機能を実装して』と言われたら、成功するとは思えない。コードベースのツアー、要件、仕様、制約が必要」 (11:51 - 12:15)。だからバイブコーディングでは、開発者がこの情報を Claude に与えて、「成功できる状態」にする責任を負う。

Schluntz の具体的な作業フロー: 「Claude と機能を作るとき、私は 15-20 分かけてガイダンスを 1 つのプロンプトにまとめてから、 Claude に料理させる。その 15-20 分は、別の会話で Claude と往復してやり取りすることが多い — コードベース探索、ファイル探し、計画立案、必要な変更ファイル特定、従うべきパターン」 (12:24 - 13:09)。「アーティファクト、全情報が揃ったら、新しい context か『この計画を実行して』と Claude に渡す」 (13:09 - 13:20)。

「ビジネスがない人は本番でバイブコーディングすべきじゃない」 (13:30 - 14:30)

Schluntz の率直な制限事項: 「タイトルにも関わらず、 本番のバイブコーディングは全員向けじゃない。完全に非技術者が、一から完全にビジネスを作ろうとするのは、危険」 (13:33 - 13:45)。

理由: 「正しい質問ができないから。 Claude にとって効果的な PM になれないから」 (13:55 - 14:05)。これは Karpathy の「下限 vs 天井」整理と完全に整合する — バイブコーディングの「下限を上げる」効果は素晴らしいが、本番では別。

Schluntz の含意: バイブコーディングを「democratization (民主化)」として歓迎しつつも、「production responsibility (本番責任)」とは別軸で扱う、という二層整理。「コーディングできない人がゲームやサイドプロジェクトを作る」のは素晴らしい、「コーディングできない人が決済システムを作る」のは危険、という線引き。

22,000 行の PR を 1 日でマージ — Anthropic 内部の実証 (14:30 - 18:30)

講演の最強の証拠: 「私たちは最近、 22,000 行の変更を本番の強化学習コードベースにマージしました、そのほとんどを Claude が書いた」 (14:39 - 14:46)。

責任を持って実行した方法 4 つ:

Claude の PM 役を真剣に: 「1 回のプロンプトでマージしたわけじゃない。要件整理、 Claude のガイド、システム設計に、人間の数日分の作業がかかった」 (15:09 - 15:25)。
葉ノードに集中: 「変更は主にコードベースの葉ノードに集中していた。そこに技術的負債があっても OK だと知っていた」 (16:11 - 16:25)。
コアは人間レビュー: 「重要だと考えた部分、拡張可能である必要のある部分は、人間が重点的にレビュー」 (16:25 - 16:35)。
検証可能チェックポイント設計: 「安定性のストレステストを慎重に設計、人間が簡単に検証できる入力と出力を持つようにシステム全体を設計、これで全コードを読まずに正しさを確認できた」 (16:39 - 17:35)。

結果: 「コードベースの他の変更と同じくらい自信を持てるようになった。でも、全て手で書いて 1 行ずつレビューする時間と労力のごく一部で届けられた」 (17:48 - 18:05)。

最もエキサイティングな副次効果: 「人間の 1 週間分の時間を節約しただけじゃなく、これができると分かったことで、エンジニアリングについて違う考え方ができるようになった。 2 週間ではなく 1 日でできるとなると、もっと大きな機能・変更ができると気づく」 (18:21 - 18:53)。「ソフトウェアの限界コストが下がり、より多くのソフトウェアを消費・構築できる」 (18:57 - 19:05)。 Jevons パラドックスの AI 版。

セキュリティ — 「証明可能に正しい」フレームワークの提案 (24:30 - 27:30)

観客質問への応答。「数ヶ月前、上位 10 のバイブコーディングアプリが超脆弱で、プロハッカーですらない人が情報を漏洩可能と証明した」という指摘 (24:30 - 25:00)。

Schluntz の答え: 「全て『Claude の PM になり、文脈を十分理解して、何が危険か、何が安全か、どこで注意すべきかを知る』ことに尽きる」 (25:14 - 25:35)。「報道される事例は、そもそもコーディングをやるべきじゃない人たちがやっているもの」 (25:40 - 25:50)。

製品設計レベルでの解: 「証明可能に正しいホスティングシステムが出てくることを期待している。認証部分や支払部分はあなたのために用意済み、 UI 層を埋めるだけ」 (26:23 - 26:43)。最もシンプルな例として Claude Artifacts を挙げる (フロントエンドのみで、認証も支払いもない → 構造的に安全)。「これのバックエンド版を誰かが作るべき」 (27:00 - 27:25) という業界へのプロダクトアイデアの種まき。

テスト駆動開発 (TDD) と葉ノードの実用知 (28:00 - 31:00)

最後の観客質問への応答 — Claude のテスト書き方。「Claude は実装に特化しすぎたテストを書くラビットホールに陥りやすい」 (29:55)。

Schluntz の対処: 「私は具体的に指示する: 『エンドツーエンドテストを 3 つだけ書いて、ハッピーパスとエラーケースとこの別のエラーケース』。非常に具体的に、テストが一般的でエンドツーエンドであることを指示する」 (30:08 - 30:42)。

Schluntz の作業スタイル: 「バイブコーディングしているとき、私がコードで読む唯一の部分、あるいは最初に読む部分はテスト。テストに同意してテストが通れば、コードはまあ良いと感じる」 (30:48 - 31:04)。「Claude にミニマリストなエンドツーエンドテストを書くよう促せる場合、これが最も上手く機能する」 (31:04 - 31:15)。 TDD が AI 駆動開発と相性が良い、という業界知見。

業界文脈

Code with Claude は Anthropic が開催する開発者向けカンファレンス。 2025 年 5 月の SF イベント (Hannah Moran × Christian Ryan の Prompting 101、 Boris Cherny の Claude Code セッション等が並ぶ) と、同年内の各種拡張イベントがある。 Schluntz の本トークは Anthropic 公式チャンネルに公開された、同社の AI 駆動開発文化の対外的な発信。

時期的に重要 — Schluntz の本講演は Karpathy の AI Ascent 2026 講演 (2026/05) より前の発信だが、概念整理は完全に整合する。「Karpathy が業界の高所から整理」、「Schluntz が現場での実装を具体化」という補完関係。同じ業界転換が、複数の独立した権威ある発信源から確認される、という多元的根拠の構造。

Schluntz の Building Effective Agents (Barry Zhang と共著、 2024/12) は、業界で最もよく引用されるエージェント設計指針の 1 つ。「ワークフロー vs エージェント」「シンプルなパターンから始める」等の指針を体系化した。 Skills not Agents (Barry Zhang × Mahesh Murag、 2025/12) と並んで、 Anthropic の 2025-2026 年の AI 駆動開発文化の対外公表の中核。

関連動画との位置づけ

この講演を理解する文脈の系譜:

Karpathy の 2025/02 の vibe coding 造語ポスト (X) — 概念の起点
Building Effective Agents (Schluntz × Barry Zhang、 2024/12) — 著者自身の理論基盤
プロンプティング 101 (Hannah Moran × Christian Ryan、 Anthropic、 2025/05) — Claude プロンプト設計の入門
本回: Vibe Coding in Prod (Responsibly) (Schluntz、 Code with Claude、 2025) — 本番運用のための具体的指針
エージェントを作るのをやめた、 Skills を作ることにした (Barry Zhang × Mahesh Murag、 Anthropic、 2025/12) — 共著者 Barry Zhang による発展形
バイブコーディングからエージェント工学へ (Karpathy、 Sequoia AI Ascent 2026、 2026/05) — 業界全体の概念整理

Schluntz 講演は「Anthropic 内部の現場実装」、 Karpathy 講演は「業界全体の高所俯瞰」。並べて読むと、低層 (具体的な戦術) と高層 (パラダイム整理) が噛み合う。 Schluntz の「22,000 行 PR」「葉ノード戦略」「Claude の PM」は、 Karpathy の「Software 3.0」「エージェント工学」「下限 vs 天井」の具体的実例として読める。

実装上の含意

LLM プロダクトを構築する技術者にとって、本講演の示唆:

第一に、 葉ノードの識別を技術設計の標準にする。自社コードベースで「他の何にも依存されていない末端機能」と「コアアーキテクチャ」を区別する作業を、 Claude 駆動開発の前提として実施する。機能ごとに「これは葉か幹か」をタグ付け、葉のみバイブコーディング対象、幹は人間レビュー必須、というポリシー化。

第二に、 15-20 分のコンテキスト構築投資を組織的に評価する。「すぐに Claude に頼む」のではなく、「Claude にどう情報を渡すか」を時間をかけて設計する作業を、エンジニアリング工程として明示する。 PR レビュー時に「使われたプロンプトと計画」も含めて評価する、という運用変更。

第三に、 検証可能チェックポイント設計を本番ロールアウトの前提にする。「コードを読まずに正しさを確認できる入出力」を、機能設計時から組み込む。ストレステスト、受け入れテスト、観測可能な入出力ペア、という抽象化層を意識的に設計する。

第四に、 「来年の AI は今の 2 倍、再来年は 4 倍」を製品ロードマップに織り込む。「今日は 1 時間タスクが可能」を前提に作った製品は、 1-2 年で陳腐化する。「1 日タスク」「1 週間タスク」を扱えるエージェントへの移行を、ロードマップ前提に組み込む。

第五に、 採用基準の更新。「Claude の PM ができる人」 = 「正しい質問を立てられる人」「15-20 分のコンテキスト構築投資を惜しまない人」「葉ノードとコアを判別できる人」を、技術採用の評価軸に追加する。 Karpathy の採用プロセス再設計提案と一貫する。

批評的な視点

本講演の強みは、「22,000 行 PR」という具体的な数字を伴う実証。一方で、留保もある。

第一に、 22,000 行 PR の事例は Anthropic 内部の 本番強化学習コードベース での話で、完全にオフラインで動くシステム (Schluntz が観客質問で確認)。認証、支払い、ユーザーデータ、外部通信を含むシステムでは、セキュリティリスクが構造的に違う。「外向きサービスで 22,000 行をバイブコーディングする」が同じ結果になるとは限らない。

第二に、「葉ノード戦略」の判別は経験を要する。「これは葉か幹か」を初心者が判断するのは難しい。 Schluntz が前提とする「コードベースを深く理解しているシニアエンジニア」のような開発者層には適用できるが、ジュニアやチームへの教育設計が別途必要。

第三に、「15-20 分のコンテキスト構築投資」は、個人の生産性として測れるが、組織の評価指標としては難しい。「コンテキスト構築 15 分」が見えるエンジニアリング工程に組み込まれないと、「すぐに動くアウトプット」を求める文化と衝突する。

第四に、 Karpathy の「下限を上げる」と Schluntz の「本番は別物」の緊張。「コーディングできない人が本番でビジネスを作るべきじゃない」という Schluntz の発言は、 democratization の理想と矛盾する。「専門知識が必要な領域は専門家しか参入できない」という保守的な含意を持つ。これは AI 業界の democratization 議論で論争的なテーマ。

第五に、「証明可能に正しいホスティングシステム」という Schluntz の提案は、まだプロダクトとして存在していない (2026/05 時点)。業界へのアイデアの種まきとしては価値があるが、現時点で「本番でバイブコーディングする」にはセキュリティ・認証・支払いを既存フレームワークで補う必要がある。

これらの留保はあるが、「Anthropic 内部の現場実装」を公的に共有する稀少な発信として、本講演の存在価値は決定的。同社が AI 駆動開発文化を持つ社内文化を、業界全体への教材として公開している、という意味でも歴史的記録。

読者へのテイクアウェイ

自社コードベースを「葉ノード」と「コア」に区分し、バイブコーディングを葉ノードに集中させる運用ポリシーを作る
「すぐに Claude に頼む」を「15-20 分のコンテキスト構築投資」に置き換える。 PR レビュー時にプロンプトと計画も評価する
「検証可能チェックポイント」を機能設計の前提にする。ストレステスト、受け入れテスト、観測可能な入出力で、コードを読まずに正しさを確認できる層を作る
製品ロードマップに「AI タスク長 7 ヶ月ごと 2 倍」を織り込む。「今日の AI に最適化された製品」を作ると 1-2 年で陳腐化する
採用基準を「Claude の PM ができる人」 = 正しい質問・コンテキスト構築・葉ノード判別の 3 能力に更新する
「本番でバイブコーディングは全員向けじゃない」という Schluntz の制限事項を、 democratization の理想と分けて理解する。ゲームやサイドプロジェクトと、認証・支払いを含む本番システムでは戦略が違う

動画の構成

(00:00) オープニング — 「皆さんお気に入りのテーマ、バイブコーディング、そして責任を持って本番で」
(00:23) Erik Schluntz 自己紹介、 Anthropic Programming Agents、 Building Effective Agents 共著者
(00:38) 「自転車事故で手を骨折、 2 ヶ月ギブス、 Claude が私のコードを全部書いた」
(01:00) 真のバイブコーディングの定義 — Cursor / Copilot は厳密にはバイブコーディングではない
(01:34) Karpathy の定義引用 — 「コードが存在することすら忘れる」
(02:18) バイブコーディングのマイナス面 — API キー超過、 DB に変なデータ
(02:42) バイブコーディングのプラス面 — ゲーム、サイドプロジェクト、賭け金の低い領域
(03:14) 指数関数 — AI タスク長は 7 ヶ月ごとに 2 倍
(03:42) 来年は 1 日、再来年は 1 週間タスク — ロックステップ不能
(04:30) コンパイラのアナロジー — アセンブリを読まずに信頼する
(04:55) 「コードが存在することは忘れるが、プロダクトが存在することは忘れない」
(06:00) 古い問題の新しい姿 — CTO / PM / CEO の管理問題
(07:08) 「文明と同じくらい古い問題」 — 自分が理解していない実装の管理
(07:48) 抽象化層の検証可能性が解
(08:30) 但し書き: 技術的負債は検証可能性の例外
(09:16) 葉ノード戦略 — 他に依存されていないコード部分
(09:55) コア (幹) は人間が深く理解する必要
(10:10) モデル改善で葉ノードの境界は広がっていく
(11:09) 「Claude が君のために何をできるか、ではなく、君が Claude のために何をできるかを尋ねよ」
(11:24) Claude の PM になる思考法
(12:24) 15-20 分のコンテキスト構築投資 — 別の会話で往復、計画立案
(13:33) 「非技術者が本番でビジネスを作るのは危険」
(14:39) 「22,000 行の変更を本番強化学習コードベースにマージ」
(15:09) 責任を持って実行した 4 つの方法
(16:11) 葉ノードに集中
(16:39) 検証可能チェックポイント設計 — ストレステスト + 入出力
(17:48) 結果 — 他の変更と同じ自信、ごく一部の時間で
(18:21) ソフトウェアの限界コスト低下 — もっと大きな変更ができる
(19:46) 締めの 4 原則 — Claude の PM、葉ノード、検証可能性、指数関数
(20:06) Q&A 開始
(20:08) Q1: AI 時代の学習方法は変わるか
(22:18) Q2: コンテキスト構築の情報量の塩梅
(24:30) Q3: バイブコーディングとサイバーセキュリティのバランス
(26:23) 証明可能に正しいホスティングシステム提案
(27:00) Claude Artifacts を例として
(28:00) Q4: TDD のコツ — エンドツーエンドテスト 3 つに絞る
(31:00) Q5: Claude Code と Cursor / VS Code の使い分け、 compact のタイミング
(31:00) 締め、拍手

重要な引用

「自転車事故で手を骨折して 2 ヶ月ギブス、 Claude が私のコードを全部書いていた」 (Schluntz、 00:38)
「真のバイブコーディングは『コードが存在することすら忘れる』こと」 (Schluntz 引用 Karpathy、 01:43)
「AI ができるタスクの長さは 7 ヶ月ごとに倍になっている。今は約 1 時間」 (Schluntz、 03:14)
「来年・再来年に AI が 1 日・1 週間タスクをこなせるようになった時、ロックステップで動こうとする限り、追いつけない」 (Schluntz、 03:42)
「コードが存在することは忘れるが、プロダクトが存在することは忘れない」 (Schluntz、 04:55)
「自分が理解していない実装をマネジメントするのは、文明と同じくらい古い問題」 (Schluntz、 07:08)
「技術的負債は、実装の専門家になる以外に良い検証方法がない稀なもの」 (Schluntz、 08:48)
「葉ノードに技術的負債があっても OK、他に何も依存していないから」 (Schluntz、 09:36)
「Claude が君のために何をできるか、ではなく、君が Claude のために何をできるかを尋ねよ」 (Schluntz、 11:09)
「15-20 分かけてガイダンスを 1 つのプロンプトにまとめてから、 Claude に料理させる」 (Schluntz、 12:24)
「非技術者が一から完全にビジネスを作ろうとするのは危険」 (Schluntz、 13:33)
「22,000 行の変更を本番の強化学習コードベースにマージ、そのほとんどを Claude が書いた」 (Schluntz、 14:39)
「人間の 1 週間分の時間を節約しただけじゃなく、違う考え方ができるようになった」 (Schluntz、 18:21)
「ソフトウェアの限界コストが下がり、より多くのソフトウェアを消費・構築できる」 (Schluntz、 18:57)
「1-2 年後、全コードを読む・書くと要求する人は大きな不利になる」 (Schluntz、 19:46)
「証明可能に正しいホスティングシステム — 認証・支払いは事前用意、 UI 層を埋めるだけ」 (Schluntz、 26:23)
「私がコードで読む唯一の部分、あるいは最初に読む部分はテスト」 (Schluntz、 30:48)

出典

Vibe Coding - Eric Schluntz, Anthropic Team (Code with Claude)

関連リソース:

Building Effective Agents (Schluntz × Barry Zhang、 Anthropic、 2024/12) — 著者本人による理論基盤
Claude Artifacts — Schluntz が「証明可能に正しい」例として挙げる
Karpathy の「vibe coding」造語ポスト (X、 2025/02)
METR Research: AI タスク長の指数関数測定 — Schluntz が引用する 7 ヶ月 2 倍の根拠
Machines of Loving Grace (Dario Amodei、 2024/10) — 観客質問で言及された「サイエンスフィクションじゃない、プロダクトロードマップ」

エリック・シュランツ

Erik Schluntz

Anthropic リサーチャー / Programming Agents 担当 / Building Effective Agents 共著者

用語集

バイブコーディング (Vibe Coding): Andrej Karpathy が 2025 年 2 月に X で造語。「完全にバイブに身を委ね、指数関数を受け入れ、コードが存在することすら忘れる」 AI による完全自動コーディング。 Schluntz は本講演でこの定義を厳密に適用し、「Cursor / Copilot のタイトなフィードバックループは厳密にはバイブコーディングではない」と整理。
Building Effective Agents: Anthropic が 2024 年 12 月に公開した、エージェント設計の業界標準ガイド。 Erik Schluntz と Barry Zhang の共著。「ワークフロー vs エージェント」「いつエージェントを使うべきか」「シンプルなパターンから始める」等の指針を体系化、業界で最もよく引用される設計指針。
葉ノード戦略 (Leaf Node Strategy): Schluntz が本講演で提唱した、本番バイブコーディングの中核戦術。コードベースを「葉ノード (他に何にも依存されていない末端機能)」と「コア (システムの幹と下層の枝)」に区分、バイブコーディングは葉ノードに集中、コアは人間が深く理解する、という二層運用。葉ノードに技術的負債があってもシステム全体への影響が限定されるため。
抽象化層の検証可能性 (Verifiability at Abstraction Layer): Schluntz が本講演で提唱した、本番バイブコーディングの中核原理。下層の実装を知らなくても、上層の抽象化レベルで動作を検証できる層を設計する。 CTO の受け入れテスト、 PM のプロダクト試用、 CEO のスポットチェックがこれに該当する設計判断。
技術的負債 (Tech Debt): Ward Cunningham が 1992 年に提唱したソフトウェア工学用語。短期的な実装上の妥協が、将来的に修正コストとして累積する現象。 Schluntz は本講演で、これが「コードを読まずに検証する方法がない」唯一の領域だと指摘、バイブコーディング戦略の限界として扱う。
Claude の PM になれ: Schluntz が本講演で提唱した、バイブコーディングの心構え。開発者は Claude にとってのプロダクトマネージャーであり、タスクを成功させるための文脈・要件・制約を提供する責任を負う。 JFK の 1961 年就任演説「Ask not what your country can do for you, but what you can do for your country」を本歌取りしたフレーズ。
AI タスク長の指数関数: METR (Model Evaluation and Threat Research) が 2025 年に公開した観測。 AI モデルが一貫して完了できるタスクの長さ (人間時間換算) が、約 7 ヶ月ごとに倍増している。 2025 年時点で約 1 時間、 2026 年で約 2 時間、 2027 年で約 4 時間、という具合に外挿される。 Schluntz が本講演の核として使う数字。
ソフトウェアの限界コスト (Marginal Cost of Software): 経済学用語の応用。 1 単位の追加生産にかかる費用 (marginal cost) が下がると、消費量が増える、という需要曲線の効果。 Schluntz は「AI でソフトウェアの限界コストが下がり、より多くのソフトウェアを消費・構築できる」と論じる。 Jevons パラドックスの AI 版。
証明可能に正しいホスティングシステム (Provably Correct Hosting System): Schluntz が本講演の終盤で提案したプロダクトアイデア。認証、支払い、セキュリティ等の重要部分は事前に設計済みで、開発者が UI 層だけ埋めればいい「塗り絵型」フレームワーク。 Claude Artifacts (フロントエンドのみで安全) を参考に、バックエンドも含めた版を構築する余地。
Claude Artifacts: Anthropic が 2024 年に公開した Claude の機能。 Claude が書いたコードを、 Claude AI 内のサンドボックスでホストして実行・表示する。フロントエンドのみで、認証も支払いもないため構造的に安全。 Schluntz が「証明可能に正しい」例として引用する。
Code with Claude: Anthropic が開催する開発者向けカンファレンス。 2025 年 5 月の SF イベント (Hannah Moran × Christian Ryan の Prompting 101、 Boris Cherny の Claude Code セッション、本講演等) と、同年内の各種拡張イベント。 Anthropic の AI 駆動開発文化の対外的な発信の場。
Barry Zhang: Anthropic リサーチエンジニア、 Building Effective Agents の Schluntz の共著者。 2025 年に Anthropic が発表した Agent Skills の設計を主導。「Claude Code を作ったら、それが汎用エージェントだと気づいた」というプロトタイプから Skills の概念に到達。 MEMEX 既存記事「Skills not Agents」で詳述。
JFK の 1961 年就任演説: John F. Kennedy が 1961 年 1 月の大統領就任演説で発した有名な一節「Ask not what your country can do for you, but what you can do for your country (国があなたのために何をしてくれるかではなく、あなたが国のために何ができるかを問え)」。 Schluntz の「Claude が君のために何をできるか、ではなく、君が Claude のために何をできるかを尋ねよ」はこの本歌取り。
Anthropic 本番強化学習コードベース: Schluntz が 22,000 行の PR の対象として挙げた、 Anthropic 内部のシステム。観客質問への応答 (26:00 付近) で「完全にオフラインで動くもの」と Schluntz が明示。認証、支払い、外部通信を含まないため、セキュリティリスクが構造的に低い。これが 22,000 行バイブコーディングが可能だった文脈的条件。
Jevons パラドックス: 19 世紀のイギリス経済学者 William Stanley Jevons が 1865 年に提唱。「ある資源の効率的利用が可能になると、その資源の消費量はかえって増える」という現象。例: 石炭エンジンの効率向上が石炭消費を減らさず、むしろ増やした。 Schluntz の「ソフトウェアの限界コスト低下で、より多くのソフトウェアを消費・構築できる」は Jevons の AI 版。
METR (Model Evaluation and Threat Research): 2022 年設立の独立研究機関。旧称 ARC Evals。大規模 AI モデルの能力評価を実施、 OpenAI、 Anthropic 等の発表前モデルへのアクセスを得て、危険な能力の検出を担う。 2025 年公開の「AI が完了できるタスク長は 7 ヶ月で倍増」という観測が業界で広く引用される。

comment is stripped from the HTML output. */}