AI にどこまで任せるか — 新規プロダクト立ち上げの工程設計

新規プロダクトを立ち上げるとき、AI をどこまで使うかは毎回悩みどころです。「全部 AI に任せて一晩で作らせる」という記事も見かけますし、逆に「結局レビューで全部書き直すから最初から自分で書いたほうが早い」という感想も聞きます。私自身、自社プロダクトを何本か立ち上げてみて分かったのは、この二択が問いの立て方として間違っているということでした。

適切な問いは「AI に任せるか否か」ではなく、「どの工程の、どの判断を、誰が持つか」 です。ビジネスモデルの検討と、技術選定と、実装と、量産・整形では、AI の得意さも失敗したときの被害も全く違います。同じ温度で扱うから「丸投げして事故る」か「全部手動で遅い」のどちらかになります。

この記事では、私が自社プロダクトの立ち上げで実際に回している 4 工程のフローと、工程ごとの「任せる／決める」の線引き、そしてモデルの使い分けを共有します。実装ガードレールの話は Claude Code hooks で品質ゲートを作る に、レビュー設計は AI コードレビューを多層で組む に書いたので、本稿はその手前、工程そのものの設計に絞ります。

立ち上げを 4 つの工程に割る

まず全体像です。私は新規プロダクトを次の 4 工程で立ち上げています。

工程	主な作業	AI の役割	人が持つ判断
1. ビジネスモデル検討	課題定義、収益構造、競合、撤退ライン	壁打ち相手・視点の網羅	やる／やらないの決定
2. 技術選定・設計	スタック決定、アーキテクチャ、スキーマ	選択肢の列挙とトレードオフ整理	制約の確定
3. 実装	scaffold、機能実装、テスト	主力。大部分を書かせる	レビューと受け入れ基準
4. 量産・整形	文言、i18n、データ変換、定型ファイル	ほぼ全部任せる	サンプリング検査

ポイントは、工程 1 に近いほど人の判断比率が高く、工程 4 に近いほど AI 比率が高いという傾斜です。この傾斜を意識せずに全工程で同じ関わり方をすると、上流で事故るか下流で時間を溶かすかのどちらかになります。

工程 1: ビジネスモデル検討 — 壁打ちに使い、決定はしない

新規プロダクトの構想段階で AI を使う価値は、視点の網羅にあります。「この課題設定で本当にお金が取れるか」「似たことをやって失敗した事例はないか」「収益構造の前提が崩れるのはどういうときか」といった問いを、疲れずに何十回も投げ返してくれる相手として優秀です。

私がこの段階で必ず投げる質問はだいたい決まっています。

• この課題は「あったら嬉しい」か「無いと困る」か。判断根拠は何か
• 課金が発生する瞬間はどこか。無料で使い続けられる抜け道はないか
• 同種のサービスが過去に畳んだ事例はあるか。畳んだ理由は何か
• この前提が崩れたら撤退、というラインを 3 つ挙げるとしたら何か

ただし決定は絶対に AI に渡しません。 理由は単純で、AI は「やめたほうがいい」を言い切るのが構造的に苦手だからです。プロンプトに「厳しく評価して」と書けば批判的な観点は出してくれますが、それは要求された役割を演じているのであって、事業判断ではありません。撤退ラインを決めるのも、そのラインに触れたときに実際に手を止めるのも、人間側の仕事です。

この段階の出力は、コードではなく判断の記録です。私は Obsidian の vault に「なぜこの課題を選んだか」「撤退ラインはどこか」を残しています。後の工程で AI に渡すコンテキストとして効きますし、半年後に自分が「なぜこれを作り始めたんだっけ」となったときの参照先にもなります。

工程 2: 技術選定・設計 — トレードオフを出させ、制約は自分で確定する

スタックとアーキテクチャを決める工程です。ここでの AI の使い方は、選択肢とトレードオフを出させて、判断材料を揃えることに尽きます。

私は Claude Code の /feature-dev のような、設計フェーズを明示的に持つワークフローをこの段階で使います。コードベース探索、明確化質問、アーキテクチャ設計を分けて回すタイプのものです。重要なのは、この段階で AI に「制約」を先に伝えることです。制約が曖昧なまま設計させると、技術的には妥当だが自分の運用に合わない案が出てきます。

私が必ず先に確定させて渡す制約は次のあたりです。

• 運用人数: 1 人で回すのか、将来チームを入れるのか
• コスト上限: 月いくらまでならインフラに払えるか
• 撤退可能性: 畳む可能性が高いなら、ロックインの弱い構成にする
• 法規制: 薬機法・景表法・個人情報など、業種固有の制約
• 既存資産: 使い回せる自前ライブラリや既存リポの有無

このうち 法規制は特に人が持つべき判断です。AI は一般論としての法令知識は持っていますが、「この表現がこの業種のこの文脈でアウトかどうか」は、最終的に事業者が責任を負う領域です。設計段階で「この機能は表現規制に引っかかる可能性があるので、出力に人間の確認を挟む導線を先に作る」といった判断は、AI の提案を待つのではなく自分から要件に入れます。

この工程の出力も、コードより先に設計判断の記録です。ADR（Architecture Decision Record）形式で「何を選んだか」ではなく「なぜ他を選ばなかったか」を残しておくと、実装工程で AI が別案を提案してきたときに一瞬で却下できます。これは想像以上に時間を節約します。

工程 3: 実装 — 主力。ただし受け入れ基準は先に書く

ここからは AI が主力になります。scaffold、機能実装、テスト、リファクタ。分量で言えばコードの大半を書かせます。

この工程で人が持つべきなのは 受け入れ基準です。「動いたら OK」で回すと、AI が書いたコードのうち「動くけど設計意図から外れている部分」が積み上がっていきます。実装を投げる前に、次を明文化しておきます。

• この機能が満たすべき振る舞い（テストで表現できる形で）
• 触ってはいけない箇所（既存の契約、公開 API、スキーマ）
• 完了の定義（テストが通る／型が通る／lint が通る／実機で確認済み）

そのうえで、決定論的なゲートを hook に落とします。commit 前に typecheck / lint / secret 検出を強制する話は 記事 #1 に書いた通りで、この工程の生産性はゲートの品質にかなり依存します。「AI が書いたものを人がレビューする」だけの体制は、量が増えると必ず破綻します。 機械的に判定できるものは機械に、LLM でしか拾えない観点だけを人と AI のレビューに回す、という切り分けが要ります。

もう一つ、実装工程で効くのは区切りごとのコミット習慣です。AI とのセッションは長くなると要約圧縮が入り、初期の文脈が薄れます。フェーズ単位でコミットしておくと、セッションをまたいでも「どこまで終わっているか」が git 履歴から復元でき、コンテキストが飛んでも被害が小さくて済みます。

工程 4: 量産・整形 — ほぼ全部任せる

文言の一括修正、i18n の対訳追加、データ形式の変換、定型ファイルの生成。この工程は判断がほとんど発生しないので、AI に任せてサンプリング検査だけします。

ここで人が見るべきなのは、全件ではなく分布です。100 件の変換結果を全部読むのではなく、ランダムに 5 件と、境界っぽい 3 件（最長・最短・特殊文字を含むもの）を見ます。それで問題がなければ通し、崩れていたらプロンプトを直して全件やり直す。1 件ずつ直すのは工程 4 でやるべき作業ではありません。

モデルの使い分け — 工程で替える

ここが実際のコストに直結します。Claude のモデルは能力と価格が段階的に分かれていて、2026 年 7 月時点では次のような構成です。

モデル	入力 / 出力（100 万トークンあたり）	位置づけ
Claude Fable 5	$10 / $50	最も難しい推論・長時間の自律作業
Claude Opus 5	$5 / $25	複雑なエージェント的コーディング、業務用途
Claude Sonnet 5	$2 / $10 ※	速度と知性のバランス。コーディングで Opus に迫る
Claude Haiku 4.5	$1 / $5	最速・最安。単純作業向け

^※ Sonnet 5 は導入価格で、2026 年 8 月 31 日まで $2 / $10、9 月 1 日以降は $3 / $15 になります。

この価格差を工程に当てはめると、割り当てはこうなります。

• 工程 1・2（構想と設計）: 最上位モデル。判断材料の質が後工程すべてに波及するので、ここをケチるのは筋が悪いです。使うトークン量自体は多くないので、単価が高くても総額は知れています。
• 工程 3（実装）: 中位モデル。Sonnet 5 はコーディングとエージェント的な作業で上位モデルに近い品質が出るので、量が出る実装工程の主力にすると費用対効果が良くなります。難所だけ上位モデルに投げます。
• 工程 4（量産・整形）: 最小モデル。判断がない作業に高いモデルを使う理由はありません。

入力単価で見ると最上位と最小の間には 10 倍の開きがあります。しかも Fable 5 と Opus 系は新しいトークナイザーを使っていて、同じテキストでも Haiku 世代より 3 割ほど多くトークンを消費します。同じ文章を処理させたときの実効コスト差は 10 倍では済まず、13 倍前後になる計算です。工程 4 を最上位モデルで回すのは、単純にその倍率をそのまま払っているだけです。逆に工程 1 を最小モデルで回すと、浅い判断材料で事業を始めることになり、そちらのほうがずっと高くつきます。

実務上のコツは、モデルを替えるタイミングを工程の区切りに合わせることです。プロンプトキャッシュはモデルごとに分かれているので、セッションの途中でモデルを替えると、切り替え先のキャッシュがコールドな状態から書き直しになります。キャッシュ読み出しは通常の入力の 1 割ほどの単価ですが、書き込みは逆に 1.25 倍以上かかるため、安いモデルに落としたつもりで割高になることがあります。工程が変わるところでセッションも切る、という運用にしておくと素直です。

もう一段細かく効かせたいなら、サブエージェントに軽いモデルを割り当てる手もあります。メインの会話は上位モデルのまま、探索や定型処理だけを安いモデルの子タスクに逃がす形です。メインセッションのキャッシュを壊さずにコストだけ下げられるので、工程 3 の中で「調べる」比率が高いときに効きます。

作業場所を分ける — 考える場所と作る場所

最後に、地味ですが効いている工夫を一つ。私は 「考える場所」と「作る場所」を物理的に分けています。

• 考える場所: Obsidian の vault。課題定義、撤退ライン、設計判断（ADR）、運用ルール、タスク
• 作る場所: git リポジトリ。コード、テスト、設定

分ける理由は 2 つあります。1 つは、AI に渡すコンテキストが安定すること。リポジトリの中に判断メモが混ざっていると、実装セッションでノイズになります。逆に vault 側にコードが混ざると、判断を追いたいときに邪魔になります。

もう 1 つは、判断の履歴が残ること。コードの履歴は git が持ってくれますが、「なぜその設計にしたか」は明示的に書かないと消えます。AI との会話ログはセッションが終われば実質失われますし、要約圧縮で削られることもあります。残したい判断は、会話の外に出しておく必要があります。

この分離を前提にすると、実装セッションを始めるときに「vault のこの ADR を読んでから作業して」と指示するだけで、必要な文脈が揃った状態でスタートできます。プロジェクトが長期化するほど効いてきます。

まとめ

AI と新規プロダクトを立ち上げるときに効くのは、ツールでもプロンプトでもなく、工程ごとの権限設計です。上流ほど人が決め、下流ほど AI に任せる。この傾斜を意識するだけで、「丸投げして事故る」も「全部手動で遅い」も回避できます。

人が絶対に持つべき判断は 3 つに絞れます。撤退ライン、法規制、コスト構造。この 3 つは、間違えたときに後から取り返しがつかないか、事業者としての責任が伴う領域です。それ以外の探索・比較・実装・整形は、積極的に AI に寄せて構いません。

モデルの使い分けも、この傾斜と同じ形に揃えると素直です。判断材料を作る工程には最上位を、量が出る実装工程には中位を、判断のない作業には最小を。単価差は 10 倍あるので、工程に無頓着なまま回すと請求書で驚くことになります。

まずは今動いているプロジェクトで、「この作業はどの工程か」「この判断は誰が持つべきか」を一度言語化してみてください。それだけで、任せる範囲と自分で抱える範囲の線が引きやすくなります。