%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
AIとの対話で試作品を作る前に、誰のどんな判断を確かめるかを決めます。作った後は、利用者の反応と技術上の結果を分けて記録し、MVPへ進むか、問いや作り方を見直すかを選びます。
AIとの対話で試作品を作る前に、誰のどんな判断を確かめるかを決めます。作った後は、利用者の反応と技術上の結果を分けて記録し、MVPへ進むか、問いや作り方を見直すかを選びます。
「アイデアはあるが、何を作れば価値を確かめられるか分からない」「仕様を議論しているうちに、利用者の反応を見る機会を逃している」。そんなときは完成形から考えるのではなく、まず検証したい問いを絞ります。問いが曖昧なまま画面を増やしても、どの結果を受けて次へ進むべきか判断できません。
AIプロトタイピングとは、AIコーディングアシスタントと対話しながら試作品を作り、事業上の仮説を検証する進め方です。AIに画面やコードの作成を依頼しても、対象者、観察する場面、結果の採否は人が決めます。ツールの操作を知りたい方は「Claude Codeの使い方」をご覧ください。
この記事では、事業のアイデアを試したい方や、試作品からMVPへの移行を判断する方に向けて、経営管理ダッシュボードのPoCを例に、仮説の整理、試作、利用者による確認、製品版に向けた判断を順に説明します。手元の構想に当てはめながら、次に何を確認すればよいかを見つけてください。関連する考え方はAI活用完全ガイド、ビジネスサイドが自分で作る場合は「非エンジニアでもAIで業務ツールが作れる」で扱っています。開発全体の流れから確認したい場合は、AI駆動開発の全体像も参考にしてください。
この記事でわかること
試作を始めたい事業担当者と、MVPへの移行を検討する開発担当者が、同じ判断材料を使って次の作業を決められるように、問いの立て方から結果の整理までを扱います。まず検証したい場面を思い浮かべ、該当する項目から読み進めてください。
- AIプロトタイピングの考え方 — 利用者の操作で答えを得られる問いと、データ利用や公開範囲など先に確認すべき条件を分けます。
- アイデアから製品版までの5段階 — 各段階で残す成果物、次へ進む条件、条件を満たさないときの戻り先を示します。
- 経営管理ダッシュボードのPoC計画 — 画面上の判断体験とデータ取得の実現性を、別々に確かめる手順を説明します。
- ツール選びと役割分担 — 検証する内容とレビュー体制に合わせた選び方、AIの出力を人が確認する順番を整理します。
- MVP・製品版への移行 — 利用者にとっての価値、技術上の障壁、コードの流用可否を分けて評価します。
AIプロトタイピングで検証する価値
試作品は、想定する利用者が課題をどう捉え、提示した解決策を判断に使えるかを確かめるために作ります。
先に「誰が、何を操作し、どんな反応があれば仮説を支持または見直すか」を書き、その問いに必要な画面と動作を選びます。観察だけで判断できないことは、操作後に尋ねる質問として分けておきます。
試作品を使った検討と従来の進め方
プロトタイピングは、製品やサービスのアイデアを形にして検証するプロセスです。ソフトウェアなら画面案、操作できるモックアップ、動作する試作品へと具体化できます。
ただし、動くものが完成したことと、利用者の課題や価値を確かめたことは別です。対象者に操作してもらい、次の点を当初の問いと照らし合わせます。
- 見た場所
- 迷った場所
- 判断に使った情報
たとえば「必要な数値を見つけられるか」を確かめるなら、利用者に通常の判断場面を伝え、最初に開いた場所と探した情報を記録します。
見つけられなかったときは、原因を聞き分けます。
- 表示位置が分からなかった場合 ── 画面を見直します
- 必要な指標自体が違った場合 ── 課題と仕様に戻ります
判断に使えたという発言があっても、実際にどの情報をどう比較したかを確認してから次の要件に反映します。
Claude Codeを使う場合の操作範囲は、記事内のClaude Code Overviewを確認してください。ツールに依頼する作業と、生成結果の確認方法は、プロジェクト側で決める必要があります。
人とAIの作業の分け方は「AI駆動開発とは？従来開発との違い・メリット・導入ステップを実践者が解説」でも扱っています。
AIが変える3つの壁
次の表は、試作時に検討する作業分担を整理したものです。表中の時間、費用、実現範囲に関する記述は、個別の案件で確認した結果ではありません。
自分たちの案件でAIに依頼する作業、人が確認できる作業、追加で担当者が必要な作業を対応させて読んでください。
| 壁 | 従来の進め方 | AIプロトタイピングでの進め方 |
|---|---|---|
| スピードの壁 | ボイラープレート、CRUDロジック、UIコンポーネントをすべて人が書くため、動くものができるまで時間がかかる | 定型的な作業をAIに任せ、人は仕様の判断と動作確認に集中する |
| スキルの壁 | フロントエンド、バックエンド、インフラの知識を持つ人をそろえる | AIが React/Next.js から API/DB 設計、デプロイ設定まで横断的に支援し、ビジネスサイドの人材でも技術的なプロトタイプに手が届く |
| コストの壁 | 外注するとシンプルなWebアプリでもまとまった費用がかかり、仮説が外れたときのサンクコストが大きい | AIツールの利用料と自分の時間で動くものを作れるため、ピボットしたときの損失を小さく抑えられる |
実際に進め方を比べるときは、同じ仮説と公開範囲を前提に、作成、仕様確認、生成物のレビュー、利用者への確認、修正、引き継ぎまでを書き出します。
作成工程だけを抜き出して比べると、後で必要になる確認作業を見落とします。
- 担当者を決められない作業がある場合 ── 扱うデータや公開範囲を狭め、検証方法から見直します
- 必要な確認を含めて問いに答えられる進め方が見つかった場合 ── 試作範囲を決めます
動くものにすると答えやすい問い
操作できる画面があれば、「利用者はどの情報を探すか」「その情報から想定した判断に進めるか」を観察できます。
試す前に、次を記録します。
- 対象者
- 依頼する操作
- 観察する行動
- 聞き取る理由
期待した反応と違ったときに、画面の配置が原因なのか、そもそもの課題設定が違うのかを切り分けるためです。
判断の分かれ目は、未解決の論点が利用者の反応にあるか、試すための前提条件にあるかです。
- 反応を確かめたい場合 ── 問いを絞って試作品を作ります
- 契約、規制、データ利用の可否が分からない場合 ── 使える範囲を確認してから画面と機能を決めます
- 確認が終わるまで実データを使えない場合 ── 例示データで答えられる問いだけに検証範囲を限定します
その結果から実データを使う場面の価値まで判断せず、未確認事項として次の確認方法と担当者を残します。
アイデアから製品版へ進む5段階
各段階で「何を残すか」と「何が分かれば次に進めるか」を決めます。条件を満たさない場合は、機能を足して様子を見る前に、該当する段階の問いや仕様へ戻ります。
判断の根拠を残しておくと、利用者の反応と技術上の問題を分けて見直せます。
段階ごとの作業と次へ進む条件
| 段階 | やること | 次へ進む条件 |
|---|---|---|
| Stage 1: アイデア整理 | 課題と解決策を言語化する | 検証する仮説が少数に絞れている |
| Stage 2: 仕様対話 | 技術スタック・画面・データモデルを決める | 最初に作る画面と機能の順番が決まっている |
| Stage 3: プロトタイプ生成 | 動くコードを小さく積み上げる | コアバリューを画面上で体験できる |
| Stage 4: MVP検証 | ユーザーに触ってもらい改修する | 仮説の支持・不支持が判断できる |
| Stage 5: 製品版への移行 | リファクタリング・テスト・セキュリティを固める | 運用と引き継ぎに耐える品質になっている |
| 段階 | AIの主な役割 |
|---|---|
| Stage 1: アイデア整理 | 壁打ち相手 |
| Stage 2: 仕様対話 | 技術選択肢の提案 |
| Stage 3: プロトタイプ生成 | コード生成 |
| Stage 4: MVP検証 | フィードバックの即時反映 |
| Stage 5: 製品版への移行 | テスト生成・リファクタリング支援 |
段階を進める根拠は、画面が動いたという事実だけでは足りません。
- 利用者に見せる価値を説明できない場合 ── Stage 1へ戻ります
- 必要な画面やデータを選べない場合 ── Stage 2へ戻ります
Stage 4で反応が得られても、製品版に進むには別途、品質と運用の確認が必要です。
- 各段階で残すもの ── 判断の根拠となった発言、操作、動作確認の結果と、未解決の論点を一緒に残します
- 意見が分かれた場合 ── 平均的な評価にまとめず、誰がどの場面で異なる判断をしたかを残して次の確認対象を決めます
Stage 1〜2: 課題と仕様を言葉にする
最初に、誰のどんな課題を、どの場面で確かめるかを決めます。AIとの対話では、次の順番で答えを具体化します。
- 誰の課題か：試作品を触る人と、その人が判断を求められる場面を決めます。
- どんな課題か：現在の方法で困ることを、観察や聞き取りで確認できる形にします。
- 何を変えたいか：現在の方法と試作品を比べ、利用者の行動や判断にどんな違いが出るかを定めます。
- 何が必要か：その違いを確かめるための画面、データ、操作だけを選びます。
経営管理ダッシュボードなら、「複数の場所にある数値を確認する経営者は、判断に必要な情報を一画面で見たい」という仮説を置けます。
そのうえで、どの意思決定を試すのか、その判断にはどの指標が必要かを経営者に確認します。この段階で、次のことも決めます。
- 実データを見せる必要があるか
- 例示データでも情報の配置を評価できるか
必要な指標を説明できなければ画面設計を始めず、判断場面の聞き取りに戻ります。指標が決まったら、利用者に依頼する操作、その操作から分かること、分からないことを並べます。
答えを得るために必要な画面とデータだけをStage 3の作業範囲にします。
Stage 3〜4: 小さく作り、利用者の反応を確かめる
画面と機能を分けて作り、変更ごとに意図した動作を確認します。まず情報の配置を試し、価値の検証にデータの鮮度や取得元が必要と分かったら、連携方法を確認する進め方が考えられます。
データ連携そのものが仮説の中心なら、画面だけを先に完成させても判断材料にはなりません。その場合は、必要なデータを取得できるかを試作の条件に含めます。
利用者には、想定した判断場面を伝えて操作してもらいます。次の点を記録します。
- 最初に見た情報
- 探しても見つからなかった情報
- 判断が止まった理由
結果の読み方は次のとおりです。
- 課題自体が確認できない場合 ── Stage 1へ戻ります
- 課題はあるが提示方法が伝わらない場合 ── Stage 2〜3へ戻ります
- 価値が伝わり、足りない情報を具体的に挙げられた場合 ── その情報を次に検証する要件として整理します
発言だけで採否を決めにくいときは、実際の操作と発言が一致したかを確認します。操作中に手助けが必要だった場合は、手助けなしで同じ判断に進めるかを改めて確かめます。
Stage 5: 品質と引き継ぎを整える
製品として使う判断には、利用者の反応とは別にコードと運用の確認が必要です。データの流れ、認証、エラー処理、テスト、引き継ぎ方法を点検します。
- 未解決の問題がある場合 ── 影響する機能と担当者を付け、提供前に対応するかを判断します
- 担当者が変更内容や失敗時の動作を説明できない場合 ── 流用する範囲を決めずに調査へ戻ります
Claude Codeを利用する場合は、依頼する作業と人が確認する範囲をプロジェクトの指示に残します。
ファイル編集やコマンド実行に関する案内はClaude Code Overviewで確認できます。
- 生成された変更を説明できない場合 ── 採用を保留して影響範囲を読み直します
- 確認後 ── 流用する部分、作り直す部分、引き継ぐ未解決事項を分けて記録します
経営管理ダッシュボードのPoC計画
このPoCでは、「経営者が必要な情報を見つけ、判断に使えるか」と「表示に必要なデータを扱えるか」を別々に確かめます。
- 画面の評価で価値が確認できても ── データ取得の課題は残り得ます
- データが取得できても ── その表示が判断に役立つとは限りません
試す前に両方の確認結果を記録する欄を分けておきます。
画面の骨格を作る
まず経営者と判断場面を選び、そこで必要な指標を画面に配置します。サイドバー、ナビゲーション、KPIカードを含むレイアウトは一例です。
見せる前に、どの指標をどこで見つけ、何を判断してほしいかを作り手が説明できる状態にします。指標の意味や比較対象も、利用者が判断できる形で示します。
- 画面が表示されない場合 ── 起動方法と画面構成を調べます
- 表示できても必要な情報を見つけられない場合 ── 連携するデータを増やす前に、指標の選び方と配置を見直します
- その情報自体が判断に使われない場合 ── 選んだ判断場面や仮説へ戻ります
配置を変えた場合は、同じ判断場面で再び操作してもらい、どの変更が探し方に影響したかを確認します。
必要なデータをつなぐ
次に、選んだ指標の取得元を確認します。会計APIの財務データやCRM APIの商談データを使う想定なら、次を整理してから連携を試します。
- 必要な項目
- 利用できる権限
- 取得に失敗したときの扱い
画面の評価に実データが不要なら、データの利用条件を確認するまで連携を進めない選択もあります。
AIに認証や取得処理の下書きを依頼しても、APIキーの保管、アクセス権限、エラー表示は人が確認します。
- 認証情報がコードに含まれていた場合 ── 取り除き、管理方法を決めます
- 取得に失敗した画面が空白になる場合 ── 利用者が状態を判断できる表示へ修正し、再度動作を確かめます
取得できた場合も、画面の値がどの項目から来たかを追えるようにします。取得元と表示値を対応づけられなければ、その指標を判断材料として扱う前にデータの流れを調べます。
動作を確認し、次の判断に備える
データ取得から画面表示までを通して確認します。表示されない場合は、画面、認証、API応答のどこで止まったかを記録します。
関係者が試作品にアクセスするなら、次を確認してから共有します。
- 公開範囲
- 設定手順
- 扱うデータ
動作確認の後、利用者に画面を操作してもらい、読み取った内容と実際に語った判断を記録します。
「表示できた」「必要な情報を見つけられた」「意思決定に使えると説明できた」は、それぞれ別の結果として扱います。
- 技術上は動いても判断に使われない場合 ── 画面と指標を見直します
- 判断に使われてもデータ取得が不安定な場合 ── 連携方法を検討します
どちらか一方だけを確認できた段階では、もう一方を誰がどう確かめるかを次の作業にします。
結果を次の作業につなげる
確認した結果を、MVPの要件か、仮説・技術選択の見直しにつなげます。以下は結果を整理するための記入例であり、特定のPoCの実測結果ではありません。
| 確認すること | 結果 | 次の行動 |
|---|---|---|
| 経営者がダッシュボードを見て、意思決定に使う場面を具体的に語れたか | 語れた | MVPに向けて、必要な機能セットの洗い出しに進む |
| 同上 | 語れなかった | 表示する指標が違うのか、課題設定が違うのかを切り分け、Stage 1に戻る |
| 外部APIから必要なデータが取得できたか | 取得できた | データ更新の頻度と範囲をMVP要件に記録する |
| 同上 | 取得できなかった | 代替のデータ取得方法を調べ、技術的な障壁として移行判断の表に記録する |
表を埋める際は、結果だけでなく、誰のどの操作や、どの動作確認から判断したかを添えます。
- 利用者の評価とデータ取得の結果が食い違う場合 ── それぞれの次の行動を残してからMVPの範囲を決めます
- 判断できない項目 ── 成功として扱わず、確認する人と方法を決めます
- 追加確認の結果が出たら ── 当初の仮説と照らして、要件に加えるか、試す範囲を変えるかを選びます
AIと人間の役割を分ける
AIには作成や整理を依頼し、人は仮説、生成結果の採否、利用可否を判断します。担当を分けるだけで終わらせず、生成物を確認する順番を作業の中に組み込みます。
確認できる人がいない工程は、試作品を見せる範囲を決める前に担当を確保します。
任せやすい作業と人が判断すること
| AIに任せやすい作業 | 人間が判断する作業 |
|---|---|
| ボイラープレート・CRUDロジックの生成 | 検証する仮説とコアバリューの決定 |
| UIコンポーネントの組み立て | 技術スタックとアーキテクチャの選定 |
| API連携コードの下書き | APIキー・認証情報の扱い方 |
| テストコード・ドキュメントの生成 | 製品版に進むかどうかの意思決定 |
| リファクタリング案の提示 | セキュリティ・ライセンス上の可否 |
確認は、次の順に進めます。
- 依頼した仕様との照合
- コードの差分
- 動作
- 失敗時の表示
期待した動作でも、変更の意図や影響を説明できない部分は調べてから採用します。利用者が価値を感じたかという判断まで、AIの出力だけで済ませないことが大切です。
仕様と違う変更が見つかったら、依頼内容を直すべきか、生成結果を直すべきかを先に決めます。
レビューを開発の流れに入れる
機能を追加するたびに、次を確認します。
- Gitの差分
- 想定した動作
- 失敗時の表示
次の機能に進む条件は、動作したことに加え、変更内容と確認結果が残っていることです。不具合があれば、再現する操作と修正後の確認方法を書きます。
利用者に触ってもらう前には、データの流れ、認証、エラー時の動作を確認します。READMEやプロジェクト規約には、次を残します。
- 起動方法
- 主要なデータの流れ
- レビュー時に見る点
担当者が替わっても、何を確認すれば次に進めるか分かる状態にします。確認が終わらない機能は利用範囲から外すか、確認できる担当者を加えてから試します。
確認結果に応じて試す範囲を変えた場合は、その理由も利用者への依頼内容に反映します。
AIプロトタイピングのツールを選ぶ
- 最初に決める ── 画面上の価値を確かめたいのか、データ連携や業務ロジックまで試したいのかです
- 次に確かめる ── 試作品を製品の土台として使う可能性と、コードを確認できる担当者の有無です
この順番で比べると、必要な操作を再現できるか、生成物を確認できるか、検証後に何を引き継ぐかを判断できます。
本記事は2026年8月時点の情報です。
コード生成型ツールの比較
次の表にある価格帯と機能の記述は、現在の提供条件として確認されたものではありません。
価格や機能の優劣をこの表だけで判断せず、まず自分たちが試す操作、生成コードの確認方法、引き継ぎ先を比べてください。
- 料金や利用条件が選定に必要になった時点 ── 各社の公式情報を確認します
- 確認できない項目 ── 判断を保留し、今回の検証に必要かどうかを先に決めます
| ツール | 適したフェーズ | 価格帯 |
|---|---|---|
| Claude Code | プロトタイプ〜MVP | 月額$20〜100 |
| GitHub Copilot | 全フェーズ | 月額$10〜39 |
| Cursor | プロトタイプ〜MVP | 月額$20〜40 |
| ツール | 特徴 |
|---|---|
| Claude Code | ターミナル統合型。プロジェクト全体を理解した上でコード生成。ファイル作成・編集・実行まで一貫 |
| GitHub Copilot | エディタ統合型。行単位・関数単位の補完に優れる |
| Cursor | VS Codeベースのエディタ。コードベース全体を文脈として活用 |
比較する際は、同じ小さな作業を候補のツールで試し、担当者が生成された変更を読めるか、必要な操作を再現できるか、結果を次の担当者に渡せるかを確認します。
Claude Codeを使った対話的な作り方は、バイブコーディング実践ガイドでも解説しています。
- コードを読める担当者がいる場合 ── 試作時から差分の確認方法と引き継ぎ先を決めます
- いない場合 ── 画面と価値の検証に範囲を絞り、MVPへ進む前に技術的なレビューを担う人を加えます
ノーコード・ローコード型の選択肢
画面上の体験を先に試したい場合は、ノーコード・ローコード型も検討できます。比較するときは、次を確認します。
- 必要な操作を再現できるか
- 検証に使うデータを扱えるか
- 作ったものを後でどう引き継ぐか
製品の土台にするつもりなら、試作後の移行方法も選定時に確かめます。
- Bolt.new：プロンプトからWebアプリを生成するツールです。
- v0 by Vercel：プロンプトからUIコンポーネントを生成するツールです。
- Replit Agent：自然言語の指示からアプリケーションの構築を支援するツールです。
画面上の価値を確かめる段階なら、必要な操作を再現できるかを試します。
独自のデータ連携や業務ロジックが検証の中心なら、その実装と確認を担う人を決め、コード生成型も含めて選び直します。
- 各ツールで実現できる範囲や利用条件 ── 選定時に公式情報で確認してください
- 必要な動作を再現できない場合 ── ツールを増やす前に、その動作が今回の仮説を確かめる条件かを見直します
ツール選びの判断表
| 問い | 答え | 選ぶ方向 |
|---|---|---|
| 作ったものをそのまま製品に育てるか | 育てない（捨てる前提で検証する） | ノーコード型で画面とアイデアの検証を優先する |
| 同上 | 育てる | コード生成型で、最初からGit管理と規約を整える |
| 作り手がコードを読めるか | 読める | Claude Code・Cursorでプロジェクト単位の生成を任せる |
| 同上 | 読めない | ノーコード型から始め、読める人を検証段階で巻き込む |
表は選定の出発点です。たとえば「製品に育てたい」が「コードを読める人がいない」場合は、ツールを決める前にレビュー担当を確保するか、今回の検証を画面の確認に限定するかを決めます。
答えが割れる項目を放置せず、試作品で確かめる範囲に反映します。
- 必要な操作を再現できない場合 ── まずその操作が今回の仮説に必要かを確かめます
- 必要な場合 ── 実現方法を調べます
- 不要な場合 ── 試作範囲から外します
担当者と試作範囲が決まったら、選んだ方法で実際の確認作業まで進められるかを小さく試します。
自作の前に既存ツールを確認する
試作品を自作する前に、すでに使っている業務システムで同じ仮説を確かめられるか調べます。
問い合わせ対応を検討し、HubSpotを利用している場合は、Breezeのカスタマーエージェントを確認する選択肢があります。
- 決める ── まず改善したい応答場面
- 書き出す ── 既存機能で表現できることと不足すること
以下は、HubSpotデモアカウントのBreezeカスタマーエージェントのガイドライン設定画面です。トーンや応答スタイルの入力欄を見ながら、検証したい応答をどう指定するか考えられます。
画面の設定だけで答えられる問いと、利用者に応答を評価してもらう必要がある問いを分けて確認してください。次の画像は、Breezeカスタマーエージェント ガイドライン設定画面を示します。
- 既存機能の設定で検証したい体験を表現できる場合 ── まずその範囲で試し、利用者の反応を記録します
- 必要な体験を表現できず、その不足が仮説の中心に関わる場合 ── 必要な動作を仕様にしてから自作を検討します
どちらの場合も、利用者に何を試してもらい、どの反応を次の判断に使うかを先に決めます。
プロトタイプを育てるか、作り直すか
試作品を製品の土台にするかどうかは、利用者の反応とコードの状態を分けて判断します。価値が確かめられても、試作時のコードをそのまま運用できるとは限りません。
まずコードを読める担当者が流用範囲を評価します。流用できる部分を見つける際も、残る問題と対応する人を明らかにします。
探索的・進化的プロトタイプの違い
| 種類 | 目的 | コード品質の扱い |
|---|---|---|
| 探索的プロトタイプ | 仮説が当たっているかを早く知る | 速度最優先で、品質は度外視してよい |
| 進化的プロトタイプ | 製品版の土台にする | 最初から一定の規律を持たせる |
| 種類 | 最初に整えるもの |
|---|---|
| 探索的プロトタイプ | 検証したい仮説と、触ってもらう相手 |
| 進化的プロトタイプ | ディレクトリ構成、命名規則、型定義、プロジェクト規約ファイル |
探索的プロトタイプで開発時の品質を優先しない場合も、利用者に触ってもらうためのデータの扱い、認証、公開範囲は確認します。
表の「品質は度外視してよい」は、コードをそのまま製品として提供してよいという意味ではありません。
- 製品の土台にする予定がある場合 ── コードを読める担当者、管理方法、テスト方針を決めます
- 途中で目的が変わった場合 ── 既存コードの流用可否を改めて評価します
流用を判断するときは、次を分けて確認します。
- 画面
- 業務ロジック
- データ連携
ある部分を説明・修正できても、別の部分の認証やエラー処理が未確認なら、試作品全体を流用可能とは扱いません。
確認できた範囲だけを残し、残りは調査または作り直す作業として記録します。
MVPへ進む条件を確かめる
PoCの結果を、利用者の価値、技術的な実現性、必要な機能、コードの流用可否に分けて確認します。
項目ごとに根拠となる観察や確認結果を残し、満たしていないものがあれば表の作業へ戻ります。
| 判断項目 | 満たしている場合 | 満たしていない場合の戻り先 |
|---|---|---|
| コアバリューが実際のユーザーから支持されている | MVPの機能セット定義へ | Stage 1で課題設定を見直す |
| 技術的に致命的な障壁がないことを確認済み | 技術スタックを確定する | Stage 2で代替技術を検討する |
| ユーザーが最低限必要とする機能セットが明確になっている | 開発の優先順位を決める | Stage 4でユーザーへの聞き取りを追加する |
| コードベースがMVP開発の基盤として使えるか、書き直しが必要かの判断がついている | 基盤を流用するか、作り直すかを決めて着手する | コードリーディングを行い、流用可否を決める |
- 利用者の反応が十分でも、コードを評価できていない場合 ── 流用は決めません
- コードが整っていても価値を判断できない場合 ── 機能を増やす前に利用者への確認を追加します
流用できる部分と作り直す部分を分けてから、MVPの作業範囲を確定します。未解決の項目が残る場合は、次に誰が何を確認すれば判断できるかまで決めます。
確認の結果、必要な機能が変わったときは、先に利用者の判断場面と照らし、開発の優先順位を見直します。
製品版に向けて見直す領域
製品として提供する前に、用途に応じたセキュリティ、依存ライブラリのライセンス、想定する利用状況での動作を確認します。
AIに確認項目の下書きを依頼する場合も、調査結果と採否は人が確かめます。
| 領域 | 起こりやすいこと | 進め方 |
|---|---|---|
| セキュリティ | 入力値のバリデーション不足、SQLインジェクション対策の漏れ、認証トークンの不適切な管理 | リリース前に人間の目でセキュリティレビューを行い、指摘事項をプロジェクト規約に追記する |
| ライセンス | AIが学習したコードのライセンスとの抵触、OSSライセンスの互換性 | 依存ライブラリの一覧を出し、ライセンス種別ごとに利用可否を記録する |
| パフォーマンス | N+1クエリ、不要なリレンダリング、メモリリーク | 負荷テストを実施し、ボトルネックを特定して改善する |
表に挙げた問題が実際にあるかは、コードと利用条件を調べて判断します。指摘事項には、影響する機能、対応する人、再確認の結果を残します。
- 提供前の解消が必要な問題が残る場合 ── 提供を見送り、対応後に同じ条件で確認します
- 利用状況に応じて見直せる問題 ── 監視方法と見直す条件を決めて運用計画に入れます
たとえば利用者の操作が止まる場面や、想定したデータを扱えない場面が見つかったら、影響する機能を特定して再評価します。
引き継ぎに必要な情報を残す
READMEには、次を記録します。
- 試作品の目的
- 起動方法
- 主要画面
- データの流れ
- 分かっている制約
環境変数は値を書かず、用途と設定方法を示します。
- 引き継ぐ人に実際に起動してもらう場合 ── 主要な動作と未解決の問題を確認できるか試します
- 説明が足りず再現できない場合 ── 資料を補ってから開発範囲を決めます
Claude Codeを使う場合、プロジェクトの指示やレビュー基準をCLAUDE.mdにまとめる方法があります。
指示ファイルの扱いはHow Claude remembers your projectで確認できます。引き継ぐ人から仕様の解釈が分かれる点を指摘されたら、判断の根拠と確認相手を記録し、着手前にそろえます。
よくある質問
プログラミング経験がなくてもAIプロトタイピングはできますか？
画面やアイデアを形にして、利用者の反応を確かめるところから始められます。まず判断場面と扱うデータを限定し、生成物をどこまで利用者に見せるか決めてください。画面上の体験を評価できたら、その結果と技術上の未確認事項を分けて残します。生成コードやデータの扱いを評価できる人がいなければ、MVPへの移行を決める前にレビュー担当を加えます。
どのようなプロダクトに向いていますか？
画面上の操作や情報の見せ方が価値に関わるWebアプリ、業務ツール、データ可視化などでは、試作品を使って利用者の判断を観察できます。リアルタイム処理、ハードウェア連携、厳しいセキュリティ条件が中心なら、画面で確かめる問いと専門的な確認が必要な問いを分けます。後者の確認方法と担当者を決めてから、試作範囲を選びます。
AIが生成したコードを製品版に使えますか？
まず利用者に価値が伝わったかを確認し、その後でコードの流用可否を判断します。データの流れ、認証、エラー処理、依存ライブラリ、テストを調べ、担当者が変更を説明して修正できるか確かめてください。運用上の問題に対応できる部分は流用を検討し、説明や修正が難しい部分は作り直す範囲を決めます。未解決の問題には担当者と再確認の方法を付け、提供の判断に反映します。
プロトタイプを外部のエンジニアへ引き継げますか？
目的、起動方法、データの流れ、未解決の問題を確認できる資料を用意します。README、環境変数の用途一覧、コード規約を渡し、引き継ぐ人に起動と主要な動作を試してもらってください。再現できない操作や判断できない仕様があれば補い、引き継ぐ人が流用範囲を評価できてから次の開発範囲を決めます。
PoCの結果が不十分な場合はどうしますか？
利用者が課題を感じていなかったのか、情報の見せ方が違ったのか、必要なデータを取得できなかったのかを分けて記録します。課題設定が合っていなければStage 1へ、実現方法に障壁があればStage 2へ戻ります。原因を切り分けられなければ、次の試作で確かめる問いを絞り、観察する操作と判断条件を決め直します。追加する機能は、その問いに答えるために必要なものから選びます。
まとめ
AIプロトタイピングでは、仮説を決め、必要な部分だけを作り、利用者の反応と技術上の結果を分けて確認します。
- 画面が動いたら ── 誰が何を判断できたかを確かめます
- 次へ進む条件を満たさなければ ── 課題、仕様、検証方法の該当箇所へ戻ります
着手するときは、次の順番で整理してください。
- 誰がどの場面で困っているかを書き、試作品で確かめる問いと観察する行動を決めます。
- その問いに必要な画面とデータを選び、試作品を育てる可能性とレビュー担当を確認します。
- 利用者の操作と発言、技術上の問題を別々に記録し、MVPへ進む条件と見直す条件に照らして次の作業を決めます。
企業様によって最適な形は異なります。業務のどの場面を試作品で確かめるべきか、既存ツールで試せる範囲はどこか、MVPへ進む前に何を確認すべきかを整理したい場合は、StartLinkにご相談ください。
あわせて読みたい
試作品で確かめる課題を整理したい場合はDXの基本から、既存ツールとの比較や投資判断を進めたい場合は、それぞれの選び方と評価方法から確認できます。
AIを事業やマーケティングで使う目的を考える際にも、次の記事を参考にしてください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
