第1章 AI駆動開発とは、コードを書くことではない
想定学習時間: 18分
AI駆動開発において、最初からコードを書き始めるのではなく、まずアイデアの整理と計画に時間をかけることが重要です。アイデアを具体的なプロジェクトに落とし込み、壁打ちで磨き上げ、要件定義と事業計画を策定します。その過程で、APIコストや自動化のリスクを考慮し、最終的にAIへの具体的な指示書を作成するという流れを守ることで、開発の失敗を大幅に減らすことができます。
ここでは、AI駆動開発を実践する上で意識すべき10のポイントを解説します。
AIモデルには、それぞれ得意な用途があります。軽い文章の整理、アイデア出し、SNS投稿案、デザイン案、クリエイティブな壁打ちなどでは、中位モデル（例: Sonnet）でも十分に効率的に作業を進められます。すべてのタスクに上位モデル（例: Opus）を使うと、利用上限を消費しやすくなり、肝心な開発作業が中断するリスクがあります。
一方で、インフラ設計、ファイナンス、データベース設計、本番運用、APIコスト設計、そして特に重要な要件定義や、実装を担当するAI（例: Claude Code）への指示書の作成など、判断ミスが大きな影響を及ぼす場面では、上位モデルを使う価値があります。司令塔となるAI（例: プロジェクトClaude）の判断が浅いと、実装を担当するAIへの指示も曖昧になり、結果として不要なファイルの変更、機能追加、あるいは危険な処理へとつながる可能性があります。司令塔AIが背景、目的、制約、コスト、人間による承認プロセスまで整理できていれば、実装AIの動きも安定します。
つまり、モデル選定は単なる好みではなく、開発品質に直結する重要な要素です。ただし、上位モデルを使えば全てが解決するわけではありません。上位モデルでも間違いは起こり、もっともらしい誤った提案をすることもあります。また、あなたの前提が曖昧であれば、期待と異なる結果を出すこともあります。そのため、モデルに頼る前に、何を作りたいのか、何が決定済みで何が未定なのか、何を絶対に避けるべきか、どこにコストやリスクがあるのかといった情報を、まずあなた自身が整理することが不可欠です。その上で、重要な判断のみを上位モデルに任せるのが現実的な使い方です。
AIモデルの選定は、会社における人材配置と似ています。誰がやっても同じ結果になる単純作業に、常に最も優秀で高給な人材を充てる企業はありません。逆に、会社の方向性を決めるような重要会議を、経験の浅い担当者だけに任せることもありません。
AIも同様です。軽い情報の整理、クリエイティブなアイデア出し、文章の言い換えやラフな構成作成、通常の壁打ちなどは、多くの場合中位モデル（例: Sonnet）で十分です。これらをまず中位モデルで試すことで、コストを抑えつつ効率的に進められます。
これに対し、事業の根幹に関わる複雑な要件定義、インフラやデータベースの設計、本番環境の構築、ファイナンス、APIコストの最適化、安全設計、そして実装を担当するAI（例: Claude Code）への重要な指示書の作成といった場面では、上位モデル（例: Opus）の利用を検討すべきです。
もちろん、これは固定的なルールではありません。AIモデルの性能、価格、利用上限は常に変化しますし、新しいモデルが登場すれば状況も変わります。そのため、常に「この作業は中位モデルで十分か」「ここだけは上位モデルに見てもらうべきか」「中位モデルでたたき台を作り、最後に上位モデルでレビューした方がよいか」「上位モデルを使うほどの判断か」「今ここで利用上限を消費する価値があるか」といった問いを自らに投げかけ、試行錯誤を続けることが重要です。この判断を繰り返すことで、あなたは「これは軽い」「これは危ない」「これは上位モデルに見せた方がいい」「これは安いモデルで十分」「これはAIに聞く前に、自分で前提を整理すべき」といった感覚を養うことができます。この感覚が育つと、AI開発の速度と安定感が向上します。
新しい上位モデルが登場すると、その高い性能や深い推論能力、コード生成能力、長文処理、マルチモーダル対応などに魅力を感じ、すぐにでも全面的に移行したくなるかもしれません。しかし、いきなり全てを新しいモデルに切り替える必要はありません。
まずは、あなたのプロジェクトで、普段行っているタスクを新しいモデルに試させてみましょう。例えば、同じ要件定義をさせたり、同じ実装を担当するAI（例: Claude Code）への指示書を作成させたり、同じエラーを読ませてみたり、同じ事業計画を見せてみたりするのです。その上で、「本当に推論が深くなっているか」「余計なことを言わないか」「指示書の精度は上がるか」「開発に使いやすいか」「利用上限の消費はどうか」「自分のプロジェクトに合っているか」といった点を慎重に判断します。
AIモデルの真価は、スペック表だけでは測れません。あなたの具体的な使い方やプロジェクトの特性に合致しているかどうかが最も重要です。AI駆動開発において、モデル選定は経営判断の一つと捉えるべきです。
事業のアイデアは、必ずしも自分の頭の中からだけ生まれるわけではありません。例えば、YouTubeのビジネス系コンテンツを積極的に活用することで、AI開発の新たな燃料を見つけることができます。起業家が事業アイデアを発表し、投資家や経営者がその弱点や可能性を議論するような番組は、単なるエンターテイメントとしてではなく、貴重な情報源として活用できます。
誰かが持ち込んだ事業案、審査員に指摘された弱点、成長の可能性を秘めているのに仕組み化されていない業務、外注費がかさんでいる部分、営業や集客で課題を抱えている部分、人手に頼っているオペレーションなど、これらを常に「AIで置き換えられないか」という視点で観察します。気になる動画があれば、AIにURLを共有し、動画の内容を文字起こしまたは要約してもらいます。そのテキストを司令塔となるAI（例: プロジェクトClaude）に入れ、次のような質問を投げかけます。
このプロセスを経ることで、単に見ていた動画が、具体的な開発素材へと変わります。動画を見て、文字起こしし、司令塔となるAI（例: プロジェクトClaude）に入れ、壁打ちでアイデアを磨き、要件定義に落とし込み、MVPに絞り込み、実装を担当するAI（例: Claude Code）用の指示書へと進める。この流れを確立すれば、YouTubeは単なる暇つぶしではなく、AI開発の強力な燃料となります。
会社のウェブサイトを運営していると届く営業メールや、SNSで目にするビジネス広告、さらにはオンライン商談で得られる資料なども、AI駆動開発においては貴重な開発素材となり得ます。多くの人はこれらを「また営業か」と流してしまいがちですが、AI駆動開発の視点で見れば、これらは市場から届く事業モデルのサンプルです。
「誰に何を売っているのか」「どのような課題を設定しているのか」「集客の導線はどうか」「収益モデルは（初期費用、月額、成果報酬など）」「代理店を増やしたいのか」「人手がかかる部分はどこか」「AIで置き換えられる部分はどこか」といった視点で分析します。少しでも検討の余地があると感じたら、資料請求をしたり、オンライン商談で話を聞いたりしてみましょう。商談の内容は、スマートフォンのボイスレコーダーや文字起こし機能を使ってテキスト化し、もらった資料と共に司令塔となるAI（例: プロジェクトClaude）に入力します。そして、次のような質問を投げかけます。
これにより、商談の文字起こしが、プロダクトの設計書の土台へと変わります。ただし、他社の資料や発言の扱いには細心の注意が必要です。機密情報や個人情報を不用意にAIへ入力したり、外部に転載したりしてはいけません。必要であれば、録音や資料の利用について相手に確認を取りましょう。あくまで自社の学習、分析、事業理解のために使うものです。見るべきは資料の表面的な内容ではなく、その裏にある事業の「構造」です。どのような課題を切り取り、どのような順番で価値を伝え、どこを自動化し、どこを人間が担当し、どこに利益が生まれ、どこに非効率が残っているのか。この構造をAIに整理させることで、あなたは情報を構造化できる人として、AI時代を有利に進めることができます。
AI開発において、最初に見るべきコストはAPIコストです。その次に、サーバーコスト、メモリコスト、ストレージコストを考慮します。どんなに画期的な機能でも、使われるほど赤字になるようでは事業として成り立ちません。ユーザーに喜ばれても、1回使われるたびに原価が積み上がり、回収できなければサービスは継続できません。
AI時代のAPIコストは、まるで飲食店の仕入れ原価のようなものです。原価を無視してサービスを作るのは、原価率を見ずに飲食店を始めるようなもの。料理が美味しくても原価率が崩れれば店は続きません。AI機能が優れていても、API原価が崩れればサービスは継続できないのです。
そのため、要件定義の段階で必ずAIに次のように問いかけます。
執筆時点では、ai.ros.co.jp 自身のMP経済圏で利用可能な、高コスパなAPIを意識しています。ただし、APIの価格や性能は常に変動します。特定のモデル名だけを信じ続けるのではなく、常に最新のコストパフォーマンスを確認することが重要です。事業の根幹には投資し、単純作業には安いモデルを使い、ルールで済むものはAIすら使わない、キャッシュできるものはキャッシュし、再利用できるものは再利用する。高いAPIを使う場合は、有料ユーザーや重要処理に絞る。このコスト感覚がなければ、AIサービスは危険なものになりかねません。
AIが「これは必要です」と提案しても、それを鵜呑みにしてはいけません。AIは、安全側に倒した提案をすることがあります。例えば、「この品質を出すには上位モデルが必要です」「この分析には高性能モデルを使うべきです」「この機能では外部APIを使うのが確実です」「この処理はリアルタイムで判定すべきです」といった提案です。
これらの提案が正しい場合もありますが、常に正しいとは限りません。API料金を支払い、赤字になった際に困るのはあなた自身です。そのため、必ずAIに次のように聞き直しましょう。
この質問をするだけで、当初の設計が大きく変わることがあります。上位モデルが必須と思われた処理が安いモデルで十分だったり、AIが必要だと思っていた処理が単純なルールで済んだり、毎回APIを呼ぶ必要があると思っていた処理がキャッシュで削減できたり、リアルタイム処理が必要だと思っていたものが夜間バッチで十分だったりするケースは少なくありません。AI駆動開発は魔法ではありません。通常のビジネスと同様に、コストを疑い、提案を疑い、より安価な方法を探し、本当に必要か問いかける姿勢が不可欠です。
実装を担当するAI（例: Claude Code）に渡す指示書は、その場で場当たり的に書くべきではありません。プロジェクトの司令塔となるAI（例: プロジェクトClaude）に、一発でコピー＆ペーストできる完璧な形で作らせるべきです。
指示書には、最低限以下の要素を含めます。
pwdやlsでの現状把握、package.json、環境変数、README、主要ファイルの確認など）特に重要なのは「手順0: 作業前確認」です。自分が今どの環境で作業しているのかを正確に把握してから作業を開始することが、誤った修正や無駄な作業を防ぐ上で極めて重要です。存在しない前提でコードを書いても意味がありませんし、別の環境を一生懸命直しても本番環境は何も変わりません。そのため、実装AIに指示を出す前に、司令塔AIでこの指示書を完璧に作成するのです。実装AIはあくまで実行部隊であり、明確で詳細な命令書があって初めてその能力を最大限に発揮できます。
実装を担当するAI（例: Claude Code）が作業を終えると、「実装しました」「修正しました」「テストしました」「エラーはありません」といった報告が返ってきます。しかし、ここで作業を終えてはいけません。その報告を、必ずプロジェクトの司令塔となるAI（例: プロジェクトClaude）へ貼り戻してください。
司令塔AIは、その報告を受けて次の判断をしてくれます。
この反復こそが、AI駆動開発の基本です。実装AIにタスクを投げ、作業させ、報告を受け、その報告を司令塔AIに戻し、次の指示を作成し、再び実装AIに渡す。このループを確立することが重要です。AIに任せるとは、AIの報告を盲目的に信じ切ることではありません。AIが適切に動けるように指示を出し、AIの結果を注意深く確認し、次の判断をあなたが行うことなのです。
AI駆動開発において、勝負はコードを書き始める前から始まっています。アイデアをどのようにAIに入力するか、どのモデルで壁打ちを行うか、どこまでスコープを絞り込むか、どのAPIを使用するか、上位モデルをどこに配置するか、人間による承認プロセスをどこに設けるか、実装を担当するAI（例: Claude Code）にどのような指示書を渡すか、そしてその報告をどう検証するか。これらの「作る前の設計」の段階で、開発の品質のほとんどが決まります。
AIを活用すれば、開発速度は確かに向上します。しかし、開発速度が上がるほど、設計の甘さも早く表面化し、後々の手戻りや問題につながりやすくなります。だからこそ、最初にしっかりと整えることが重要ですいです。
AI駆動開発は、勢いだけで進めるものではありません。AIと協力しながら、ビジネスとして設計し、開発として分解し、組織として動かすという、多角的な視点と計画性を持って取り組むべきものです。