第1章 AI駆動開発とは、コードを書くことではない
想定学習時間: 13分
AI駆動開発は、コードを書くことから始まるわけではありません。最初の重要なステップは、あなたのアイデアをAIに投入し、それを基盤としてプロジェクトを立ち上げることです。
新しいプロダクトを開発する際、まずAI（例: Claude）に専用のプロジェクトチャットを作成します。このチャットが、あなたの最初の企画会議室となります。
この段階では、何も完璧に決まっている必要はありません。サービス名も仮で構いませんし、収益モデルが曖昧でも、技術構成が未定でも、画面イメージがぼんやりしていても問題ありません。
重要なのは、思いついたこと、やりたいこと、不安なこと、競合サービス、あなたが困っていること、なぜそれを作りたいのか、誰が使うのか、どんな画面があれば便利そうか、将来どんな経済圏につながるかなど、頭の中にある雑多な素材をそのままAIに投入することです。
最初から人間が完璧に整理しようとすると、AIの持つ構造化能力や問題発見能力を十分に引き出せない可能性があります。むしろ、混沌とした情報をAIに渡し、そこから構造を導き出させるのが効果的です。
例えば、「こんなサービスを作りたい」「この作業を自動化したい」「この業界にこういう課題がある」「外注すると高いから自社エンジンにしたい」「将来的にこのプロダクトとつなげたい」「でも、最初に何を作るべきか分からない」といった、まだ荒削りな文章で十分です。完璧な企画書を作成してからAIに渡すのではなく、企画書を作成する前の混沌とした段階でAIをパートナーとすることが、AI駆動開発の鍵となります。
AI駆動開発において、AIは完成した資料を処理するだけのツールではありません。資料を作る前の混沌を、一緒に整理する相手です。
このプロセスで重要なのは、可能な限り高性能なAIモデルを使用することです。特に、プロダクトの根幹を決めるような重要な企画、要件定義、事業設計の場面では、上位モデルの利用を強く推奨します。その理由は、アウトプットの質が大きく異なるからです。
文章の言い換えや簡単な要約、ちょっとしたアイデア出しのような軽い作業であれば、一般的なモデルでも十分な場合が多いでしょう。しかし、どの機能を最初に作るべきか、どの機能を後回しにするか、課金リスクはどこにあるか、法律や規約に触れる可能性はどこか、拡張しやすい設計はどれか、運用で詰まる設計はどれか、そのサービスは本当にお金になるのか、自社の他のプロダクトとどう連携させるかといった、事業の成否を左右する判断には、モデルの性能が直接影響します。
最初の設計段階での判断は、後々の開発に大きな影響を与えます。初期の思想が間違っていると、いくら実装を進めても困難に直面することがあります。データ構造の変更、機能の過剰な盛り込みによる目的の不明確化、本来分けるべきプロダクトの統合によるリスク増大など、多くの失敗は初期設計の甘さに起因します。
AIを単なるチャット相手ではなく、プロジェクトの強力なパートナーとするために、その役割を明確に設定することが有効です。
例えば、プロジェクトの開始時にAIに対して「このプロジェクトの最高責任編集者、プロダクトマネージャー、CTO、事業計画担当として、一緒に企画を整理してください」と依頼することで、AIの立ち位置が大きく変わります。これにより、AIはプロジェクトの司令塔候補として機能し始めます。
そこから、ひたすらAIと壁打ちを行います。「このアイデアは事業として成立するか」「誰がお金を払うか」「最初に作るべきMVPは何か」「逆に、今は絶対に作らない方がいい機能は何か」「自社の既存プロダクトとどうつなげるべきか」「外注代替エンジンとして作るなら、どの順番がいいか」「APIコストはどこで爆発するか」「人間承認ゲートはどこに置くべきか」「半年後、事業として広げるなら何が必要か」といった具体的な問いを投げかけ、アイデアを企画へと昇華させていきます。
人間相手だと、まだ雑な段階のアイデアを出すのはためらいがちです。「笑われるのではないか」「考えが浅いと思われるのではないか」といった懸念から、言葉にする前に自分でアイデアを潰してしまうことがあります。
しかし、AI相手ならそのような遠慮は一切不要です。思いつきをそのまま投げかけ、荒削りな構想をぶつけ、まだ筋が悪いアイデアも躊躇なく提示してください。AIに叩かせ、分解させ、反論させることで、アイデアは磨かれていきます。
この段階では、むしろ「恥ずかしい」と感じるようなアイデアほど積極的に出すべきです。なぜなら、事業の種は、洗練された言葉の中にあるとは限りません。多くの場合、日常の不満、外注費への違和感、自分だけが感じている面倒くささといった、生々しい感情の中に隠されています。
例えば、「毎回LPを外注するのが面倒だ」という不満から、あるクリエイティブ基盤が生まれたり、「営業リストを作るだけで時間が溶ける」という課題から、ある営業エンジンが生まれたりします。最初は単なる不満であっても、それをAIにぶつけることで要件となり、設計へと進み、最終的には開発指示書を経て、動くものへと近づいていくのです。
多くの人がAIにアイデアを出させようとしすぎることがありますが、私はそれを推奨しません。AIは「新規事業案を100個出して」と言えばいくらでもアイデアを出してくれますが、それを出発点にするべきではありません。
出発点は、あなた自身の中にある「違和感」です。あなたが困っていること、あなたが見てきた現場、あなたが払いたくない外注費、あなたが毎日繰り返している面倒な作業、あなたが本気で作りたい世界。これらこそが、最も強力なアイデアの源泉です。
AIにゼロから夢を考えさせるのではなく、あなたの中にある夢をAIに構造化させる。ここが大きな違いです。AIが出したアイデアは一見きれいに見えますが、あなたの痛みとつながっていないアイデアは、少し困難に直面しただけでやる意味を失い、放置されがちです。
しかし、あなた自身の痛みから生まれたアイデアは違います。自分が困っているから直したくなる、自分が使うから改善したくなる、自分の事業に必要だから途中で止められない、自分の未来に関わるから粘れる。AIは、その「粘り」を加速させる存在なのです。
だから、AIに最初に投入すべきなのは、きれいな企画書ではありません。あなたの本音です。「これ、めちゃくちゃ面倒なんだけど、どうにかならないか」「外注しないで済む仕組みにしたい」「1人でこの業務を回せるようにしたい」「このサービスがあれば、自分の会社が一気に楽になる」「これを作れたら、他の人にも売れるかもしれない」といった、素直な感情で十分です。
そこから、AIに整理を依頼します。例えば、以下のようなプロンプトが有効です。
今の話を、事業アイデアとして整理して
対象ユーザー、課題、解決策、主要機能、収益モデルに分けて
MVPとして最初に作るべき範囲だけ抽出して
逆に、今やると失敗しそうな機能を削って
外注代替エンジンとして見た場合、どの業務を置き換えるか整理して
将来的に自社経済圏へつなげるなら、どのデータを共通化すべきか考えてこのように指示することで、雑多なメモが少しずつ事業の具体的な形へと変わっていきます。
この段階で、AIのプロジェクトチャットを使う意味が明確になります。単発のチャットで毎回相談すると、文脈が散らばり、以前決めたことを忘れ、似たような質問を繰り返すことになります。また、異なるプロダクトの前提が混ざったり、別のプロジェクトのルールを持ち込んでしまったりするリスクもあります。
そのため、プロダクトごとに専用のチャットプロジェクトを分けることが重要です。例えば、自社プロダクトには自社プロダクトのプロジェクト、ある営業エンジンにはその営業エンジンのプロジェクト、ある拡散エンジンにはその拡散エンジンのプロジェクトといった具合です。
これにより、それぞれのプロジェクトが専用の文脈を持つことができます。これは、人間の会社で部署ごとに会議室を分けるのと同じ考え方です。営業部の会議室で財務部の細かいコード修正を議論しないように、AIもそれぞれの「部屋」で、そのプロダクト固有の前提、ルール、目的を持って議論を進めるべきです。
プロジェクトを分けることで、AIはそのプロダクトの「歴史」を持つことができます。過去の方針を踏まえ、やらないと決めたことを思い出し、失敗した経緯を踏まえた提案ができるようになります。次にAI Codeに渡す指示書も、そのプロジェクトのルールに沿って作成されるため、一貫性が保たれます。この積み重ねが、AIを単なるチャットツールから、真の「司令塔」へと変えていくのです。
AIを強力な司令塔にするためには、最初の素材投入が非常に重要です。良い司令塔は、現場を知り、背景を知り、目的を知り、制約を知り、過去の失敗を知っています。
そのため、AIプロジェクトには、企画、要件、過去の失敗、使用している技術、やってはいけないこと、運用ルール、APIの注意点、コスト感、将来構想、競合への違和感、あなたの思想など、可能な限り多くの情報を投入してください。これらの情報が豊富であるほど、AIの回答は深みを増します。
もちろん、機密情報の取り扱いには細心の注意が必要です。APIキーやパスワード、個人情報、取引先の機密情報をそのまま貼り付けるべきではありません。それらは伏せるか、一般化するか、必要であればローカル環境や仮想マシン側で安全に扱うようにしてください。
しかし、プロダクトの「思想」や「設計方針」は積極的に投入すべきです。AIは技術情報だけで動くわけではありません。プロダクトの思想を知らなければ、表面的な提案しかできません。
例えば、自社プロダクトが単なるキャラクターチャットではなく「孤独に寄り添うプロダクトである」こと、ある営業エンジンが単なるメール配信ツールではなく「ホームページをメールで送るという思想がある」こと、ある拡散エンジンが単なるSNS自動投稿ではなく「検索、SNS、AI検索、地図、ECまでを横断する拡散基盤である」こと、ある分析エンジンが投資で楽に儲ける道具ではなく「自社財務を安定させるための分析エンジンである」ことなど、具体的な思想や哲学を伝えることで、AIはそのプロダクトらしい、深みのある判断ができるようになります。AI駆動開発の初期段階では、この思想の共有を省略してはいけません。
初心者は、すぐに「このサービスを作るコードを書いて」とAIに尋ねたくなりますが、それは早すぎます。
まずは、以下のように尋ねるべきです。
このアイデアを、事業として成立する形に整理して
この構想の危険なところを指摘して
最小構成で作るなら、何を削るべきか教えて
このプロダクトの開発順序を考えて
このサービスを1人で運用するなら、どんなAIエージェント組織が必要か整理してこの企画・設計段階で手を抜くと、後で何倍も苦労することになります。逆に、ここを丁寧に実行することで、その後の開発は劇的に加速します。なぜなら、AI Codeに渡す指示書が、背景、目的、制約、実装範囲、完了条件を含んだ、曖昧さのない強力なものになるからです。これにより、AIエージェントも迷いにくく、報告も受け取りやすくなり、バグが出た際にもどの前提が崩れたのか確認しやすくなります。
最初のAIプロジェクトは、単なる相談場所ではありません。それは、プロダクトの記憶装置であり、企画室であり、会議室であり、設計部であり、将来のAI Code指示書生成装置です。AI開発において、ここが本当のスタート地点となります。
だからこそ、新しいアイデアが生まれたら、まずAIにプロジェクトを作成し、そこにアイデアを「ぶち込む」のです。きれいにまとめてからではありません。まとまっていないからこそ、AIに整理してもらうために、反論してもらうために、事業化の可能性を見てもらうために、開発順序へ変えてもらうために、投入するのです。
この最初の一歩を踏み出せるかどうかが、AIを「使う側」で終わるか、AIを「使って作る側」へ進めるかを決定します。アイデアは、頭の中に置いているだけでは何も生み出しません。ノートに書くだけでも、まだ弱い。人に話すだけでも、流れていってしまいます。
AIプロジェクトに入れた瞬間、それは開発の素材となり、要件定義、事業計画、設計書、AI Codeへの指示書、そして実装へと進んでいきます。AI駆動開発は、ここから始まるのです。アイデアを大事にしまい込まず、まずぶち込みましょう。そこから、AI組織が動き出します。
人にたとえると
新商品の企画室で、まだ形になっていないアイデアを専門家と一緒に練り上げる場面を想像してください。
新規事業担当者は、頭の中にある漠然とした「こんなものが作れたらいいな」という思いや、日頃感じている不満を、そのままベテラン企画担当者にぶつけます。サービス名も決まっていない、収益の見込みも曖昧な状態です。ベテラン企画担当者は、その混沌とした話を聞きながら、「誰が使うのか」「何が課題か」「最初に何を作るべきか」といった問いを投げかけ、アイデアを具体的な企画の形へと整理していきます。このやり取りは、商品ごとに分けられた専用の企画室で行われ、過去の議論の経緯が常に共有されます。