もし手を骨折して2ヶ月間ギプスを付けなければならないが、仕事は止められない場合、プログラマーはどうすればよいだろうか? ある研究機関の研究者であるエリック・シュルンツ氏は、 アンソロピック および共著者として 効果的なエージェントの育成, は次のように答えています:すべてを クロード.
今日、AIがソフトウェア業界のルールを劇的に変えつつある中、生産性を飛躍的に向上させたい企業にとって、「Vibe Coding」は避けては通れない課題となっています。.
数ヶ月前、シュルンツ氏は、「完全自動化された作業」を強いられたという自身の異例の体験を公表し、本番環境において「バイブ・コーディング」を責任を持って実践する方法という、やや物議を醸す話題について論じた。.
このトークは実践的な洞察に満ちており、ここ数日、Xで再び話題沸騰しています。Movezというユーザーは、これを「有料講座100本分よりも価値がある」と絶賛しています。.
「Vibe Coding」の精神に基づき、シュルンツ氏の講演の構成にもAIを活用しました。.
この素晴らしい講演をご覧になりたい方は、, こちらをクリックするとアクセスできます.

「バイブ・コーディング」とは何か

多くの人々は、CursorやCopilotといったAIツールを多用してコードを生成することを「バイブ・コーディング」と同一視しています。しかし、それは正確ではありません。開発者がモデルと密接なフィードバックループを維持し、コードを一行ずつ確認・修正している限り、それを真の「バイブ」と呼ぶことはできません。“
アンドレ・カーパシーは、より正確な定義を次のように示した。「その雰囲気に完全に没頭し、テクノロジーの指数関数的な成長を受け入れ、コードの存在そのものを完全に忘れてしまうこと。」“
この開発スタイルは、開発のハードルを大幅に下げ、エンジニアリングのバックグラウンドを持たない人でも、単独で完全なアプリケーションを構築できるようにします。しかし、これまでこのアプローチによる成功事例は、主に個人制作のゲームやリスクの低いプロジェクトに限られていました。 しかし、非専門家がこのアプローチを実際の本番環境に持ち込むと、APIのクォータを使い果たしたり、サブスクリプションの検証を迂回したり、データベースを勝手に変更したりするなど、制御不能な状況に陥ることがよくあります。.
「バイブ・コーディング」が重要な理由:指数関数的成長の論理
リスクの高いビジネス環境には制御不可能な要因が存在するにもかかわらず、なぜこの技術を推進すべきなのでしょうか。その最大の原動力は、AIの能力が「指数関数的に向上」している点にあります。.
現在、AIが自律的に処理できるタスクの長さは、およそ7ヶ月ごとに2倍になっています。今日、AIは約1時間かかるコーディング作業を確実に完了することができ、開発者は依然としてそれらを一行ずつレビューする余裕があります。 しかし、来年か再来年には、AIが人間の1日分、あるいは1週間分の作業に相当するコードを一気に生成できるようになるでしょう。その時点で、依然として従来の同期型のレビューや修正に固執し続ければ、人間のエンジニアは、爆発的に増大する計算能力のボトルネックとなってしまうことは避けられません。.

コンパイラの歴史を振り返ってみましょう。初期の開発者たちはコンパイラを信用せず、依然としてその基盤となるアセンブリコードを確認していました。システムの規模が拡大するにつれ、開発者たちはより高レベルの抽象化を信頼することを学ばざるを得なくなりました。今後を見据えると、ソフトウェア工学の分野全体として、大規模モデルによって直接生成されたシステムを、本番環境でいかに安全かつ責任を持って受け入れられるかを、あらかじめ検討しておく必要があります。.
本番環境でVibe Codingを適用する方法
本番環境で「Vibe Coding」を実践する上での基本原則は、コードの存在は忘れて、常に製品の存在に焦点を当てることです。.
現代の企業経営において、CTOは受け入れテストを活用して技術専門家を管理し、プロダクトマネージャーは製品を実際に体験することで機能を検証し、CEOは主要なデータスライスを通じて財務モデルを精査しています。いずれも、最下位レベルの実行の詳細には踏み込みません。ソフトウェアエンジニアもまた、基盤となるコードを読まなくても検証可能な、同様の抽象化レイヤーを確立する必要があります。.
重要なのは、検証可能な抽象化レイヤーを見つけることです。.
しかし、現在のAIコーディングには、「技術的負債」という厄介な技術的課題が存在する。現時点では、ソースコード全体を読み込む以外、体系的な手法を用いて技術的負債を測定・検証することは極めて困難である。.
これに基づき、エリック・シュルンツは、コードベース内の「リーフノード」に焦点を当てることを提案しています。これらのノードとは、他のどのモジュールからも依存されていない末端関数や補助コンポーネントを指します。これらの領域では、たとえ多少の技術的負債が生じたとしても、変更頻度が低く、将来のモジュール構築を妨げることもないため、許容範囲内であると考えられます。.
一方、システムの中核となるトランクおよびその基盤となるアーキテクチャについては、エンジニアは依然としてスケーラビリティを深く理解し、厳格に保護する必要があります。.
注目すべきは、モデルの性能が向上するにつれて、AIに任せることができるコードのレベルが、より低いレベルにまで広がりつつあるという点だ。Anthropicで最近実施された社内テストでは、AIが高品質なアーキテクチャを生成する成功率が上昇しており、この境界線は動的に変化している。.
バイブ・コーディングの核心となるスキル:プロダクトマネージャーのように考える
AIに高品質なエンジニアリングコードを生成させるためには、開発者は考え方を変え、自分自身をそのプロジェクトのプロダクトマネージャーとして捉える必要があります。 クロード. クロードがあなたのために何ができるかなどとは聞かないでください。あなたがクロードのために何ができるかを考えてください。.
複雑な開発タスクに取り組む際、開発者はまるで新入社員の初日を迎えるかのように、AIを指導する必要があります。「この機能を実装して」といった指示をただ投げかけるだけでは、失敗に終わることは必至です。開発者は、コードベースの詳細なナビゲーションを提供し、要件や制約を明確に定義する必要があります。.
クロードに実際にコードを書かせる前に、シュルンツは通常、15分から20分ほどかけてAIとやり取りを行います。これには、AIにコードベースを探索させ、関連ファイルを見つけさせ、明確な実行計画を共同で作成させる作業が含まれます。その後、これらすべての手際よく整理された背景情報と仕様が、実行前に単一のプロンプトに統合されます。.
このプロセスにより、モデルのタスク成功率は指数関数的に向上する。.
実例:1日で22,000行のコードをマージ
シュルンツ氏は、Anthropic社内部で起きた極端な実例を明らかにした。同社のチームは、最大22,000行に及ぶコード変更を、本番環境の強化学習コードベースに正常にマージすることに成功したが、その大部分は クロード.
このマージを責任を持って完了させるため、チームは以下の4つの戦略を採用しました:
- プロダクトマネージャーの視点に立った綿密な事前計画
- リーフノードへの変更を厳格に制限する
- コアシステムのロジックに関する手動レビュー
- 検証可能なチェックポイントとストレステストの設計
このアプローチにより、当初は2週間を要していた人的なエンジニアリング作業が、1日に短縮されました。.
開発コストが劇的に低下すると、エンジニアは、これまでリソースの制約により不可能だった大規模なリファクタリングや機能の反復開発を実行できるようになります。.
高度なバイブコーディング技術と実務的なQ&A
シュルンツ氏はまた、学習方法からツールの活用に至るまで、多角的な観点から実践的な知見を共有した。.
学習について:プログラマーはもはや低レベルの細部に頭を悩ませる必要はなくなりましたが、AIによって学習速度は飛躍的に向上しています。開発者は、AIに不慣れなライブラリや設計上の判断について説明を求めることができ、AIをいつでも利用できるペアプログラマーとして活用できるのです。.
経験の蓄積について:AIにより、試行錯誤のスピードが向上します。かつては検証に数年を要していた意思決定も、今では数ヶ月以内に検証できるようになり、エンジニアは同じ期間で数倍もの経験を積むことができるようになりました。.
ヒント:詳細の程度は、実装をどの程度重視するかによって異なります。ただし、モデルに過度な制約を課すと、パフォーマンスが低下することがよくあります。厳格なテンプレートを強制するのではなく、後輩のエンジニアとコミュニケーションをとるつもりで臨んでください。.
セキュリティについて:Vibe Codingは、リスクを理解している人の指導がある場合にのみ安全です。通常、技術的な知識のないユーザーが、適切な認識を持たずにシステムを導入した際に問題が発生します。.
製品設計について:将来のツールでは、「証明可能な正しさ」を備えたシステムが提供されるようになるかもしれません。そこでは、機密性の高いバックエンドロジックがロックされ、ユーザーは管理された環境下で安全に実験を行うことができるようになります。.
テストについて:テスト駆動開発は非常に有用です。複雑なテストを行うのではなく、シンプルなエンドツーエンドテストを徹底しましょう。具体的には、正常な処理の流れを1つ、失敗ケースを2つ用意します。最小限のテストで、信頼性と可読性が向上します。.
ワークフローについて:Claude CodeとCursorを組み合わせることは一般的です。Claudeが生成を担当し、開発者はその出力を確認・修正します。文脈のずれを防ぐため、コンテキストは定期的に圧縮する必要があります。.
不慣れなコードベースの場合:機能を実装する前に、AIを活用してシステムを調査しましょう。重要なモジュールを特定し、類似した実装を見つけ出し、実行前に頭の中でモデルを構築しておくことが重要です。.
まとめ:「指数関数的成長を受け入れる」とは、実際にはどういうことか
指数関数的な成長の本質は、単なる継続的な改善にとどまらず、私たちの予想をはるかに上回るスピードで改善が進むことにある。.
緩やかに始まり、やがて急激に急上昇する曲線のように、AIの能力は単に2倍になるだけでなく、桁違いに飛躍的に向上する可能性がある。.
コンピュータの歴史を振り返ってみると、1990年代のキロバイト単位のメモリから、今日のテラバイト単位に至るまで、その性能向上は2倍ではなく、数百万倍にも及んでいます。.
つまり、本当の問いは「モデルの性能が2倍になったらどうなるか」ではなく、「性能が100万倍になったらどうなるか」ということなのです。“
これこそが「バイブ・コーディング」の真の意味であり、それゆえに無視できない理由なのです。.


