Vibe Coding から、Drive Coding (欲動のコーディング)へ

AIはコードを書ける。それでもプロダクトが「完成」しない、たった一つの理由

AIは、コードを書ける。

この命題に、もはや異論を唱える人は少ないでしょう。
では、なぜいまだに、AIコーディングだけでプロダクトを「完成」させることは、難しいのでしょうか？

「AIにはハルシネーションがあるからだ」
「私たちの言葉の意図を、表層的にしか解釈できないからだ」
「結局、複雑な仕様を伝えるためのプロンプトエンジニアリングが難しいのだ」

様々な答えがあると思います。
しかし、これらの問題は表層に過ぎないのかもしれません。

真の問題は、AIの「出力」にあるのではなく、我々人間の「入力」にあるのではないか。

そもそも我々自身が、完成させるべきプロダクトの「魂」を、そしてそれをAIに与えるべき「入力」の形式を、知らないのではないか？

本稿は、AIとの協業における真のボトルネックを探り、プロダクト開発の新たな作法を提言する、これまでの議論の集大成です。

幻想としての「Vibe Coding」

「Vibe Coding」とは何か？

Vibe coding（ヴァイブ・コーディング）とは、人間が自然言語（日本語や英語など）で指示を出し、AIが主体となってソースコードを生成・修正していく新しいプログラミングの手法です。

2025年2月にAI研究者のアンドレイ・カルパシー氏によって提唱され、ソフトウェア開発のあり方を大きく変える可能性を秘めた概念として注目を集めています。

その最大の特徴は、開発者がコードの詳細を深く読み書きするのではなく、AIに対して「こんな感じのものを作って」「サイドバーの幅を半分にして」といった、「Vibe（ヴァイブ）」、つまり「雰囲気」や「ノリ」で指示を与える点にあります。
人間はあくまでもプロダクトの目的や大まかな方向性を示す監督役となり、実際のコード作成という手間のかかる作業はAIに任せます。

Vibe Codingの主な特徴

• 自然言語による指示: 開発者は具体的なコードを書く代わりに、チャットで話しかけるようにAIに実装したい機能や修正内容を伝えます。音声入力が使われることもあります。
• AIによる自律的なコード生成: コードを生成・修正します。ファイル構造を横断して文脈を理解し、大規模な変更を自律的に行うことも可能です。
• コードレビューの最小化: 従来の開発では必須であったコードの厳密なレビューを意図的に省略、あるいは簡略化します。生成されたプログラムが意図通りに動作するかどうかを重視し、「動けばOK」という姿勢で開発を進めるのが特徴です。
• 高速なプロトタイピング: アイデアを即座に形にできるため、プロトタイプ（試作品）の開発や新規プロジェクトの立ち上げ（PoC）において絶大な効果を発揮します。

従来手法との違い

	Vibe Coding	従来のAI支援コーディング
AIの役割	開発の主体、共同作業者	開発の補助、アシスタント
人間の役割	指示、フィードバック、動作確認	設計、コーディング、デバッグ
主な作業	AIとの対話（自然言語）	コードの記述・編集
重視する点	開発スピード、アイデアの具現化	コードの品質、保守性、正確性

これまでのAIコーディング支援ツール（例：初期のGitHub Copilot）が、コードの補完や定型的な記述の自動化といった「補助」的な役割だったのに対し、Vibe CodingではAIがより主体的に開発の大部分を担う「パートナー」へと進化している点が大きな違いです。

Vibe Codingの光と影

このアプローチには、無視できない魅力があります。

• メリット（光）: アイデアを即座に形にできる驚異的なプロトタイピング速度、プログラミング経験の浅い人にも門戸を開くアクセシビアリティ、そして開発者がより創造的な作業に集中できる点です。

しかし、その輝きの裏には、深い影が潜んでいます。

• デメリット（影）: AIが生成したコードの品質や保守性は保証されません。そして何より、場当たり的な指示の繰り返しは、プロダクト全体を貫く一貫性の喪失につながります。

Vibe Codingは、アイデアの種火を大きくする「着火剤」としては非常に強力です。
しかし、プロダクトという炎を燃え続けさせ、最後まで届けきるための「燃料」にはなり得ません。
なぜならそこには、プロダクトを一貫した方向へと導く、確固たる「意志」が欠けているからです。

「翻訳家」から「建築家」へ

ボトルネックはどこにあるか？

これまでのプロダクト開発において、成功の鍵を握っていたのは誰だったでしょうか。
それは、経営者、ユーザー、開発者といった異なる言語を話すステークホルダーの間に立ち、彼らの要求を仕様に落とし込む優秀な翻訳家=PMやPdMの存在でした。

AI時代の役割の変化

しかし今、AIがその「翻訳」の役割を、人間を遥かに超える速度で担い始めています。
これにより、私たち人間の役割は、より上流へとシフトせざるを得ません。

もはや、単なる「翻訳家」は不要です。
求められるのは、翻訳すべき物語の原作、すなわちプロダクトの設計思想そのものを定義する建築家としての役割なのです。

問題は、もはや翻訳の精度ではありません。
AIという超高速な翻訳機に渡す「原作」の質、すなわちプロダクトの根幹をなす設計思想そのものが、成否を分けるのです。

「Vibe（雰囲気）」ではなく「Drive（欲動）」を実装せよ

では、その「設計思想」の核となるものは何でしょうか。
本稿では、それを「Drive（欲動）」と呼びます。
心理学、特に精神分析の文脈で「欲動」はフロイトの提唱した "Trieb" という概念であり、これは英語では "Drive" と訳されるのが一般的です。
「衝動」「（内から湧き上がる）強い力」という意味合いを持ち、"Vibe"（雰囲気）との対比において、その内発的で力強い性質を的確に表現します。

二つの力の対比

• Vibe (雰囲気): 外部からの影響で簡単に揺らぐ、曖昧で表層的な「感じ」です。場当たり的で一貫性がなく、その場のノリで移ろいでいきます。

• Drive (欲動): 精神分析の文脈における "Trieb" に由来する、内部から湧き上がる根源的で揺ぎない力です。それはプロダクトの「魂」であり、あらゆる判断の揺るぎない基準となります。

プロダクトに必要な「一貫性」の本質

プロダクト開発において、個々の機能やデザインの「正解」は存在しません。
常に、状況に応じた「最適」が存在するだけです。
そして、その「最適」は市場やユーザーの変化に応じて変わり続けます。

この絶え間ない変化の中で、唯一不変であるべきもの。それが「Drive」です。

「なぜ、私たちはこのプロダクトを作るのか？」
「何を犠牲にしても、これだけは守りたい価値は何か？」

この根源的な問いへの答えこそが、無数の意思決定に一本の筋を通し、プロダクトに美しい「一貫性」を与えるのです。

私たちがAIに与えるべきは、曖昧な「Vibe」ではありません。
プロダクトの核となる、明確で力強い「Drive」なのです。

【実践】マニフェストの実装

では、どうすれば「Drive」をAIに実装できるのでしょうか。
その答えが、プロダクトのマニフェスト=憲法を策定することです。
ここでは、架空のプロダクトを題材に、その策定プロセスを詳細に追体験してみましょう。

サンプルプロダクト定義

• プロダクト名: CogniShelf (Cognition + Bookshelf)

• コンセプト: 「コードを書くように、思考を書き留め、育て、繋げる場所」

• ターゲット: ドキュメントがローカル、Notion、Google Docsに散在しがちな個人開発者や小規模チーム。

• 解決する課題: コードとドキュメントの乖離、ナレッジの検索性低下、チーム内での断片的な情報共有。

Step 1: 【コグニティブ・デザイン】で「Drive」を定義する

まず、プロダクトの魂を言語化し、AIと思考のレンズ（世界観）を共有します。
これは、これから始まる長い旅の羅針盤となります。

• Motive (動機): 我々の根源的な願いは、開発者の知的生産性を、情報の「検索」や「整理」といった雑務から解放し、純粋な「創造」活動へと向かわせることにある。思考の断片が、死んだ情報ではなく、未来のひらめきに繋がる資産となる世界を実現したい。

• Premise (前提):

  • シンプルさは究極の洗練である: 機能を追加することは簡単だが、本質的な価値を見極め、余計なものを削ぎ落とすことこそが真のデザインである。

  • 情報はサイロ化（孤立）させてはならない: 知識は繋がって初めて価値を生む。ツールは、情報の分断ではなく、連携を促すべきである。

  • 開発者のワークフローは神聖である: 新しいツールが、既存の快適なワークフロー（エディタ、Gitなど）を破壊してはならない。

• Purpose (目的): AIによる自動タグ付け・関連付け機能を備えた、ローカルMarkdownベースのドキュメント管理ツールCogniShelfのプロトタイプを開発する。

• Situation (状況): リモートワークの普及により、テキストベースの非同期コミュニケーションが増加。結果として、チームの暗黙知がドキュメント化される機会は増えたが、それらが複数のサービスに散在し、有効活用されていない。

• Constraint (制約):

  • ユーザーデータは、ユーザーの許可なく外部サーバーに送信しない。プライバシーとデータの所有権を最優先する。

  • 特定の企業やプラットフォームに依存しない、オープンな技術（Markdown, Git）を基盤とする。

Step 2: 【背理系フレームワーク】で「原則」を彫り出す

次に、AIとの対話を通じて、プロダクトが直面するであろう根源的な対立構造（アンチノミー）を洗い出し、その中からCogniShelfが守るべき指針（原則）を彫り出します。

あなた（人間）: CogniShelfの開発において、「多機能でパワフルであること」と「究極にシンプルであること」は、しばしば対立する。この二律背反について、歴史上の思想や他のプロダクト事例をアナロジーとして用い、構造的に分析せよ。

AI: 面白いテーマです。この対立は、哲学における「ストア派（禁欲による精神の自由）」と「エピクロス派（快楽の追求）」の対比、あるいはOSにおける「Windows（多機能・万能）」と「初期のmacOS（直感性・シンプルさ）」の設計思想の違いと構造的に類似しています。

• Windows的アプローチ: 全てのユーザーを満足させるため機能を追加し続ける。結果、多機能だが複雑化し、多くのユーザーは機能の10%も使いこなせない。

• macOS的アプローチ: 「ユーザーは本当に何をしたいのか？」を問い続け、本質的でない機能を削ぎ落とす。結果、一部のパワーユーザーには物足りないが、多くのユーザーに直感的で快適な体験を提供する。 CogniShelfは、どちらの哲学を選択すべきでしょうか？

この対話を経て、私たちはCogniShelfが進むべき道を見出します。

• 導出された原則:

  1. 原則A：選択のパラドックスを回避せよ。 迷ったら、機能を追加するより、既存の体験をシンプルにする選択を優先する。機能の多さではなく、一つのことを非常によく行う「単機能の美学」を追求する。

  2. 原則B：標準化は「推奨」と「自動化」で促せ。 チーム利用において、ルールで縛る（強制する）のではなく、優れたテンプレートやAIによる自動整理（推奨）によって、自然と秩序が生まれる状態を設計する。

Step 3: 【公理系アプローチ】で「憲法」を記述する

最後に、導き出された原則を、AIが誤解なく解釈できる厳密な「公理」として記述します。
これがCogniShelf開発における「憲法」となり、AIが自律的にコーディングする際の絶対的な指針となります。

CogniShelf開発マニフェスト

【UI/UXに関する公理】

• 公理1.1: 全ての機能は、新規ユーザーがマニュアルを読むことなく、3クリック以内で主要なタスクを完遂できるよう設計されなければならない (UI.isIntuitive() -> true)。

• 公理1.2: アプリケーションの応答速度は、人間の知覚限界である100ミリ秒を決して超えてはならない。パフォーマンスは機能に優先する。

【データ哲学に関する公理】

• 公理2.1: ユーザーが作成したコンテンツの所有権は、完全にユーザーに帰属する。データはローカルのプレーンテキスト（Markdown）として保存され、ユーザーがいつでも自由にアクセス・移行できることを保証する。

• 公理2.2: ユーザーデータ（コンテンツ、利用状況）は、ユーザーの明示的な許可なく、いかなる外部サーバーにも送信してはならない。

【技術・連携に関する公理】

• 公理3.1: 既存の開発ワークフロー（Gitによるバージョン管理、VSCodeなどの外部エディタでの編集）との分断を避け、シームレスな連携を最優先事項とする。

• 公理3.2: コア機能は、特定のAIモデルやプロプライエタリな技術に依存してはならない。将来的にユーザーがAIモデルを選択・変更できるような、オープンなアーキテクチャを維持する。

このマニフェストをAIに与えることで、AIは単なるコード生成機ではなく、プロダクトの「Drive」を理解し、その価値観に沿って自律的に判断し、一貫性のあるコードを書き続けるパートナーへと進化します。

何故マニフェストなのか？

「要件定義書、スタイルガイドやコーディングルール、用語集等の方が具体的で重要ではないか？」
「こんな抽象的な理念を決める事に、なんの意味があるのか？」

ここでこういった疑問が真っ先に挙げられると思います。

本稿で「マニフェスト」を最上位に置く理由は、両者の役割の階層と、AIというパートナーの特性にあります。

「憲法」と「法律」の違い

記事で触れた比喩を用いると、マニフェストは憲法であり、スタイルガイドやルール、用語集は法律です。

• 法律（スタイルガイドやルール）
  「こういう場合は、こうしなさい」という具体的な行動を規定します。既知の状況に対しては非常に強力で、品質のばらつきを抑えるために不可欠です。しかし、法律に書かれていない、まったく新しい状況や予期せぬ問題に直面したとき、判断の拠り所を失ってしまいます。

• 憲法（マニフェスト）
  個別の行動ではなく、すべての「法律」が準拠すべき根本的な価値観や原則を定めます。未知の状況に直面したときでも、「我々の根本的な目的は何か？」「何を最優先すべきか？」という原点に立ち返ることで、一貫性のある判断を下すための指針となります。

なぜAIには「憲法」が不可欠なのか？

この違いは、パートナーがAIである場合に決定的な意味を持ちます。

人間であれば、ルールの背後にある「思想」や「文脈」を暗黙的に読み取ることができます。しかし、AIはそれができません。

AIに具体的な「法律（ルール）」だけを与えても、そのルールの背後にある「なぜ（WHY）」を理解できないため、ルールの範囲外の事態に極めて脆弱になります。
言われたことはできますが、言われていないことに対しては、一貫性のない、あるいは全く見当違いの出力をする可能性があります。

一方、「憲法（マニフェスト）」を与えられたAIは、未知の問題に直面したときも、その根本原則に立ち返って、最も一貫性のある「最適解」を自ら推論することができます。

例えば、「公理1.1: 全ての機能は、新規ユーザーがマニュアルを読まずに〜」という憲法があれば、AIは新しい機能のUI設計を任された際、複雑な選択肢を避け、直感的なデザインを自律的に選択するでしょう。
これは、具体的なUIデザインの「法律」を一つ一つ教えるより、遥かに強力で柔軟なアプローチです。

順番が重要

結論として、スタイルガイドや用語集もプロダクトの品質を保つ上で極めて重要です。
しかし、それらはプロダクトの「魂（Drive）」を定めたマニフェストという「憲法」から派生する「法律」であるべきです。

まず憲法を制定し、その精神に則って法律を作る（あるいはAIに作らせる）。

この順番こそが、AIという強力なパートナーと共に、変化に強く、一貫性のあるプロダクトを「完成」させるための鍵となるのです。

結論：Drive Architectへの転換

AIは、我々が与えた「Drive」の忠実な実行者です。
マニフェストという形でプロダクトの「魂」を設計し、AIにインストールすること。これこそが、AI時代におけるプロダクト開発の新たな作法です。

Vibe Codingから、Drive Codingへ。

私たちの役割は、単なる指示者=Prompterから、プロダクトの根源的な価値観を定義し、その思想をAIに実装する魂の設計者=Drive Architectへと変わります。

AIがコードを書く時代に、あなたは何を書き、何を設計しますか？
その答えこそが、人間がもたらす真の価値となるのです。