作り込む前に、
動くもので確かめる。

「何を確かめれば判断できるか」を先に定義します。動くものを作り始める前に、検証すべき仮説と、成功・失敗をどう見分けるかの目安を短時間で言語化します。ここが曖昧なまま作ると「何となく動いたが判断できない」で終わるため、最初に一番時間をかけて詰めます。

• 検証すべき仮説の言語化
• 成功・失敗の判断基準の設定
• 今回は検証しない範囲の切り分け
• 必要なデータ・協力者の洗い出し

向いているケース：作るべきか迷っている / 何を確かめれば判断できるか曖昧

検証に必要な部分だけを、動く形で素早く実装します。作り込みは避け、判断できる最小限に絞ります。要件整理から実装まで生成 AI を組み込む AI 駆動開発で、通常なら数か月かかる試作を数週間に短縮します。本開発で作り直す前提の箇所は、あらかじめ切り分けてお伝えします。

• 検証に必要な機能だけを実装
• AI 駆動開発によるスピード優先の試作
• 実データを流し込める形で構築
• 使い捨て前提と再利用前提の切り分け

向いているケース：動くデモが早く欲しい / 要件が固まっていない

生成 AI・LLM を前提に、要約・分類・抽出・対話・自動化などの実現性を素早く試します。「デモでは動いたが実務では精度が出ない」を避けるため、出力のばらつきや失敗パターン、運用にかかる API コストまで含めて、使いどころを見極めます。

• 要約・分類・抽出・対話・自動化の試作
• LLM の出力精度・ばらつきの検証
• プロンプト・データ設計の当たり付け
• 運用コスト（API 費用）の概算

向いているケース：生成 AI を業務に取り入れたい / 精度が出るか不安

実データ・実利用で使ってもらい、仮説が正しかったかを計測します。利用率・精度・時間短縮といった定量の数字だけでなく、ユーザーがどこでつまずいたかという定性の反応まで拾い、次の判断に使える結果に整理します。

• 実データ・実利用での計測
• 定量（利用率・精度・時間短縮）の測定
• 定性（反応・つまずき）の収集
• 仮説の成否の判定

向いているケース：想定通り使われるか確かめたい / 効果を数字で見たい

「進める・作り直す・やめる」を根拠を持って判断できるよう整理します。本開発に進む場合は、想定スコープと概算見積もり、PoC のうち作り直すべき箇所まで明示し、同じチームでそのまま設計・実装・運用へ引き継げます。「やめる」という結論も、投資判断としては大きな成果です。

• 進める / 作り直す / やめる の判断整理
• 本開発のスコープ・概算見積もり
• PoC で作り直すべき箇所の明示
• 設計・運用フェーズへの引き継ぎ

向いているケース：投資判断の材料が欲しい / 本開発に進むか決めたい