こんにちは、株式会社TIMEWELLの濱本です。私は大企業で新規事業を10年以上手がけ、新規事業開発プログラムの運営と、大企業向けの事業開発コンサルティングを続けてきました。大企業100社以上が参加した挑戦者支援プログラム「CHANGE by ONE JAPAN」では運営責任者を務め、いまは起業家と社内起業家向けのAI駆動開発プログラム「WARP ENTRE」を運営しています。その経験をもとに、「AIネイティブ新規事業開発の方法論」を4回に分けて書きます。第1回は、顧客インタビューです。
シリーズ「AIネイティブ新規事業開発の方法論」 ①顧客インタビュー中にモックを作る技術（この記事） ②リーンキャンバス・7 Powers・デザインコンセプトを1日で回す ③仕様駆動開発（SDD）の再注目と、文書がコードになる時代 ④AGENTS.md・Skills・Hooks・cronで組織のコンテキストを育てる
新規事業の相談を受けていて、この1年で増えた失敗の型があります。AIに顧客ペルソナを作らせ、AIに課題を列挙させ、AIに解決策を提案させ、それを綺麗な資料にして稟議に上げる、というものです。顧客には一度も会わないまま。資料は立派で、論理は通っています。ただ、顧客の言葉が一つも入っていません。私はこの型を「AIで閉じた新規事業」と呼んでいます。AIが作った顧客仮説は、顧客に当ててはじめて検証できます。この記事は、その「当てる」工程を、AIの助けを借りて速く、深く、記録に残る形でやる方法を書いたものです。
要約: 60分の半構造化インタビューを「過去の行動」「課題と回避策と支払い」「ライブモック」「締め」の4ブロックで設計し、前半はモックを出さずに聞き切ります。事前にコーディングエージェントで3つの仮説画面を1枚のHTMLとして用意し、後半に相手の言葉を反映して数分で差し替えながら反応を取ります。終了後は文字起こしをエージェントに渡し、逐語引用とタイムスタンプ付きでインサイトを抽出し、仮説台帳を更新します。この記事のプロンプトはそのままコピーして使えます。
なぜ「聞きながら作る」のか。AIの仮説は顧客に当ててはじめて検証できる
従来の新規事業開発では、顧客インタビューとプロトタイプの間に数週間の空白がありました。インタビューで聞いた話を持ち帰り、資料にまとめ、デザイナーやエンジニアに依頼し、モックができた頃には相手の記憶も自分の記憶も薄れています。2回目のインタビューで見せると、「あのとき言ったのはそういう意味じゃない」と言われます。この往復に1か月かかるのが普通でした。
コーディングエージェントは、この空白を数分に縮めます。相手が「毎週月曜に3つのシステムから数字を転記している」と言った瞬間に、転記を1画面で済ませる仮の画面を作って見せられます。相手の反応は、言葉で説明されたものへの反応ではなく、目の前の絵への反応です。「いや、うちは月曜じゃなくて月初です」「この欄は要らない、代わりにこれが要る」。こういう修正が、その場で出てきます。
ただし、ここで一つ、はっきりさせておきたいことがあります。速くなったのは「作る」工程であって、「聞く」工程ではありません。むしろ、作るのが速くなったぶん、聞く前に作ってしまう誘惑が強くなりました。AIに顧客像を語らせるのは簡単で、それらしい課題も無限に出てきます。しかし、それは仮説です。2024年11月にスタンフォード大学などの研究チームが発表した研究では、1,052人の米国人に2時間の半構造化インタビューを行い、その記録から一人ひとりの「生成エージェント」を作りました。本人の語りに基づくエージェントは、本人が2週間後に同じ質問に答えたときの一致度を基準にして83%の精度で回答を再現しました。一方、年齢や職業などの属性情報だけで作ったエージェントは74%でした1。属性だけのペルソナと、本人の語りを学んだエージェントの間には、明確な差があります。AIのペルソナは、実際の語りを与えてはじめて使い物になるのです。
だから順番はこうなります。まず聞くこと。聞いた言葉を材料にして、その場で作ること。作ったものへの反応をまた聞くこと。記録をAIに渡して、次に聞くべきことを出させること。AIは「聞く」の代わりではなく、「聞いたことを速く形にし、速く整理する」ための道具として使います。自社のチームがAIをどの程度使いこなせているかは、AIリテラシー診断で確認できます。
60分の半構造化インタビューを設計する
半構造化インタビューとは、聞く項目の骨組みは決めておき、順番や深掘りは会話の流れに任せる形式です。完全に自由な雑談では比較ができず、アンケートのような固定質問では本音が出ません。骨組みは4ブロック、合計60分で設計します。
| ブロック | 時間 | 聞くこと | やらないこと |
|---|---|---|---|
| 1. 過去の行動と文脈 | 20分 | 直近に「その仕事」をしたときの具体的な手順、時間、関係者、使った道具 | 自分の事業の説明。モックを見せること |
| 2. 課題と回避策と支払い | 15分 | 一番困った瞬間、いま代わりにやっていること、それに払っている時間とお金 | 「こういう機能があったら使いますか」 |
| 3. ライブモック | 15分 | 相手の言葉を反映した仮の画面を見せ、「何が違うか」を聞く | 説得。良い反応を集めること |
| 4. 締め | 10分 | 他に困っている人、次に話を聞ける人、もう一度見せてよいか | 契約の話 |
ブロック1で大事なのは、「いつも」ではなく「直近の1回」を聞くことです。「普段どうしていますか」と聞くと、人は理想化した平均を答えます。「最後にそれをやったのはいつですか。そのとき、最初に何をしましたか」と聞くと、実際の手順が出てきます。手順が出てきたら、「それは何分かかりましたか」「誰に確認しましたか」「そのとき画面には何が映っていましたか」と、場面を再現するように聞いていきます。以前顧客の本音を引き出すMom Testの技術で書いた原則は、ここでも同じです。意見ではなく、過去の事実を聞くのです。
ブロック2は、「現状のサービスの悩み」を聞く場所です。ここで効く質問を三つ挙げます。一つ目は「いま使っているものを、明日から使えなくなったら何が起きますか」。代替手段の重さが分かります。二つ目は「乗り換えを検討して、やめたことはありますか。何が理由でしたか」。切り替えコストと、相手が本当に評価している軸が出てきます。三つ目は「その困りごとのために、いま何にお金と時間を払っていますか」。以前エンパシーマップの書き方で整理した「劣化した代替手段」が、ここで具体的になります。困っていると言いながら何も払っていないなら、その課題はまだ事業になりません。
もう一つ、私が必ず使う技法が「なぜを3回」です。「転記が面倒で」と言われたら、「なぜ面倒なのですか」。「システムごとに項目名が違うから」。「なぜ項目名が違うと困るのですか」。「上司に説明するとき、どの数字がどれか自分でも分からなくなるから」。3回目で、課題の本体が「転記の手間」ではなく「説明責任の不安」だと分かります。作るべきものが変わる瞬間です。
質問の骨組みは、事業の内容に合わせて毎回作り直します。次のプロンプトをコーディングエージェントやチャットに貼ると、上の4ブロックに沿ったインタビューガイドが出てきます。
あなたは新規事業の顧客インタビューを設計する専門家です。
以下の事業仮説について、60分の半構造化インタビューガイドを作ってください。
# 事業仮説
- 想定顧客：【例：従業員300〜1,000人の製造業の生産管理担当者】
- 想定課題：【例：複数システムからの実績集計に毎週3時間かかる】
- 仮の解決策：【例：システム横断で実績を自動集計し、上司向けの説明文まで作る】
# 制約
- 4ブロック構成：①過去の行動と文脈（20分）②課題と回避策と支払い（15分）③ライブモック（15分）④締め（10分）
- ①②では自社の解決策に一切触れない質問だけにする
- 「〜があったら使いますか」「〜は便利だと思いますか」のような意見・未来・仮定を聞く質問は禁止
- 各質問に「直近の1回を再現させる深掘り質問」を2つ添える
- ②には「代替手段」「切り替えをやめた理由」「いま払っている時間とお金」を必ず含める
- ③は「仮の画面を見せて何が違うかを聞く」質問だけにし、「使いたいか」は聞かない
- 最後に、インタビュアーが無意識にやりがちな誘導の例を、このテーマに即して5つ挙げる
出力は表ではなく、そのまま読み上げられる台本形式で。
出てきたガイドは、そのまま使わず、必ず自分の言葉に直してください。AIが書いた質問文は硬く、相手が構えます。「直近でそれをやったのはいつですか」を「この前やったの、いつでした？」に変えるだけで、答えの量が変わります。
事前に「ライブモックキット」を作っておく
インタビュー中にゼロからモックを作ると、相手を待たせます。事前に「差し替えの土台」を作っておくのがコツです。私はこれを「ライブモックキット」と呼んでいます。中身は、事業仮説から導いた3つの画面案を1枚のHTMLにまとめたものです。上部のボタンで案A・B・Cを切り替えられ、画面内の文言や項目はJavaScriptの変数で差し替えられる構造にしておきます。
なぜ3案なのか。1案だけ見せると、相手はその案の良し悪しを答えます。3案あると、相手は「どれが自分に近いか」を答え、その理由を語り始めます。比較のほうが、人は本音を言いやすいのです。AIでMVP・Mockを作るで書いた「捨てる前提」の作り方が、ここでも生きます。
コーディングエージェントへの指示は、次のプロンプトが土台です。作業フォルダを開いた状態で貼ってください。
顧客インタビューで「その場で差し替えて見せる」ためのモックキットを作ってください。
# 事業仮説（リーンキャンバスの要点）
- 顧客セグメント：【】
- 課題（上位3つ）：【】
- 仮の解決策：【】
- 独自の価値提案：【】
# 作るもの
- 単一の index.html（Tailwind CSSのCDN版を使用。外部ビルド不要。ブラウザで開くだけで動く）
- 画面上部に「案A」「案B」「案C」の切り替えボタン
- 案A：課題1を最短で解く画面／案B：課題2を解く画面／案C：課題1と2を一体で扱う画面
- 各案は「ヒーロー（一言の価値提案）」「主要な操作が1つ見える画面」「結果が見える画面」の3セクション
- 画面内の文言・項目名・数値は、ファイル冒頭の const CONTENT = {...} にまとめ、そこを書き換えるだけで差し替わる構造にする
- ダミーデータは、上の顧客セグメントの業務にありそうな現実的な項目名にする（「サンプル」「テスト」という文言は使わない）
- 見た目は「明らかに仮の絵」だと分かる程度に素朴にする。ロゴ・色・装飾に凝らない
- 入力欄は動かなくてよい。ボタンを押すと次のセクションに移る程度で十分
# 禁止
- 自社名・製品名を出さない
- 「AI搭載」「革新的」など評価語を画面に入れない
生成されたHTMLをブラウザで開き、3案を一度自分で眺めておきます。このとき、「どの案も自分の仮説の押し付けになっていないか」を確認してください。案Cが明らかに一番豪華になっている、というのはよくある失敗です。3案の見た目の重さは揃えます。
インタビュー当日は、二人体制が理想です。一人が聞き、もう一人がエージェントを操作して差し替えます。一人でやる場合は、ブロック3に入る前に「少し画面を用意するので2分ください」と断り、次のプロンプトでその場の言葉を反映させます。
インタビュー中です。相手の発言を反映して index.html の CONTENT を書き換えてください。
構造は変えず、文言と項目だけを差し替えてください。作業は2分以内、確認の質問はしないでください。
# 相手の発言（逐語）
「【例：月初に3つのシステムから数字を出して、Excelで合わせてから、部長に説明用のメモを書いている。メモを書くのが一番つらい】」
# 反映の指示
- 案Bのヒーロー文言を、相手の言葉を使った一文にする（例：「3つの数字を、部長向けの一枚にする」）
- 主要操作の画面に「部長向けメモ」の生成ボタンを足し、結果画面にメモの例文を出す
- 項目名は相手が使った単語（「実績」「月初」「部長」）に揃える
インタビュー中の運び方。モックは「提案」ではなく「質問」
ブロック3の入り方が、この方法の成否を分けます。私は必ずこう言います。「ここまでのお話をもとに、仮の絵を作ってみました。正解を見せるものではないので、違うところを教えてください」。そして案を見せ、最初の質問はひとつだけ。「何が違いますか」。
「どう思いますか」と聞くと、人は褒めます。日本のビジネスパーソンは特にそうです。「何が違いますか」と聞くと、人は自分の現実との差分を探し始めます。「ここに承認の欄がないと使えない」「この数字は月次じゃなくて週次で見る」。差分こそが、次に作るものです。
反応は、言葉だけでなく行動で取ります。画面のどこを最初に見たか。どの案で身を乗り出したか。どこで「あー」と声が出たか。同席者は、その瞬間の時刻と一緒にメモしておきます。文字起こしには残らない情報だからです。
差し替えは、多くて2回までにします。3回、4回と直していくと、相手は「自分の要望を叶えてもらう場」だと思い始め、要望の列挙が始まります。要望は課題ではありません。2回目の差し替えで反応が良くなったら、そこで止めて、次の質問に移ります。「この画面が明日から使えるとして、最初に誰に見せますか」「月にいくらなら、稟議なしで決められますか」。この二つは、モックを見せた後にだけ聞ける質問です。
一つ、絶対に聞かない質問を決めておきます。「使いたいですか」。この質問への答えは、ほぼ全員が「はい」です。そして、その「はい」は何も意味しません。以前の記事でも書いたとおり、「いいですね」という報告ほど危ない兆候はありません。
終了後60分でインサイトを抽出する。逐語引用のないインサイトは捨てる
インタビューが終わったら、記憶が新しいうちに、その日のうちに処理します。録音の文字起こしは、いまはどの端末でも数分で出ます。文字起こしを渡す前に、二つだけ手作業をしてください。氏名、社名、取引先名などの個人情報と機密を伏せ字にすること。そして、モックを見せた時刻を本文に「【ここから案Bを提示】」のように挿入することです。
エージェントへの指示は、次のプロンプトが基本形です。要点は、引用を強制することにあります。AIは、文字起こしを読ませると、書かれていない「インサイト」を自然に補います。それらしく、もっともらしく。だから、引用のない主張は出力させません。
顧客インタビューの文字起こしから、インサイトを抽出してください。
最重要ルール：すべての項目に、文字起こしからの逐語引用とタイムスタンプを付けること。
引用で裏付けられない推論は、書くなら「未確認：」と頭に付けて分けて書くこと。
# 文字起こし
【ここに貼る。個人情報は伏せ字済み。モック提示位置に【ここから案Bを提示】の印あり】
# 抽出する項目
1. 相手が実際にやっている手順（直近の1回の再現）。時間・関係者・道具を含む
2. 一番困っている瞬間（相手の言葉で）。頻度・所要時間・金額が語られていれば数値で
3. いまの代替手段と、それに払っている時間・お金
4. 現状サービスへの不満と、乗り換えを止めている理由
5. モック提示後の反応。各案について「何が違う」と言ったか。案ごとに整理
6. モック提示後にだけ出た発言には【提示後】のフラグを付ける（誘導の影響を区別するため）
7. 相手の発言内の矛盾（前半と後半で違うことを言っている箇所）
8. 私（インタビュアー）が誘導した可能性のある質問と、その直後の発言
9. 次回のインタビューで聞くべき質問を5つ。それぞれ「どの仮説を検証するため」かを添える
# 出力形式
- 見出しごとに箇条書き。各行の末尾に [mm:ss]「逐語引用」
- 最後に、この1件だけでは判断できないことを3つ書く
出力を読むときの目のつけどころは、7番と8番です。矛盾は、相手が建前と本音を両方話した証拠で、たいてい本音は後半にあります。誘導の可能性がある箇所は、そのインサイトを割り引くために使います。自分の質問の癖を毎回指摘されるのは気持ちのよいものではありませんが、これが一番インタビューが上手くなる方法です。
インサイトは、1件ごとに読んで終わりにせず、仮説台帳に積みます。仮説台帳は、リーンキャンバスの各ブロックを「まだ仮説」「支持する発言あり」「反証する発言あり」「検証済み」の4段階で管理する表です。エージェントに、抽出結果を渡して台帳を更新させます。
以下の仮説台帳を、今回のインタビューの抽出結果で更新してください。
ルール：台帳の各行には「支持する引用」「反証する引用」を件数付きで積み上げる。
1件の発言で「検証済み」にしてはいけない。支持3件以上かつ反証0件で「検証済み候補」とする。
# 仮説台帳（現在）
| ID | ブロック | 仮説 | 状態 | 支持 | 反証 | 次に聞くこと |
| H1 | 課題 | 月初の実績集計に毎週3時間かかる | 仮説 | 0 | 0 | |
| H2 | 顧客 | 意思決定者は生産管理の課長 | 仮説 | 0 | 0 | |
| H3 | 収益 | 月3万円なら課長決裁で買える | 仮説 | 0 | 0 | |
# 今回の抽出結果
【ここに貼る】
# 出力
- 更新後の台帳（同じ形式）
- 状態が変わった行と、その根拠の引用
- 新たに追加すべき仮説（相手の発言から生まれたもの）
5件たまったら、横断で見ます。「5件の抽出結果を読み、3件以上で共通して語られた課題、1件だけが語った課題、相互に矛盾する発言を、それぞれ引用付きで一覧にしてください」と指示すれば、パターンが見えてきます。ここまで来ると、以前AIに事業を採点させるで紹介したAIペルソナが役に立ちます。5件の逐語記録を読ませたペルソナは、属性だけのペルソナとはまったく別物です。次のインタビューの質問を考える壁打ち相手として使えます。ただし、あくまで「次に何を聞くか」を考える道具であって、「聞かなくてよい」根拠にはなりません。
気をつけるべきことを、もう一度まとめておきます。同意と個人情報の処理を先にすること。引用のないインサイトは捨てること。モック提示後の発言にはフラグを付けること。1件で結論を出さないこと。そして、言ったことと、やることは違うということ。「月3万円なら払う」と言った人が、実際に払うかどうかは、請求書を出すまで分かりません。
大企業の新規事業部門で、この進め方を回すには
ここまで読んで、「うちは顧客に簡単に会えない」と思った方がいるはずです。大企業の新規事業部門の最大の制約は、モックを作る技術ではなく、顧客への接点です。私が勧めているのは、既存事業の営業や顧客窓口に「30分だけ話を聞かせてほしい顧客を、毎週1人紹介してほしい」と頼むことです。既存顧客は、新規事業のターゲットとずれているかもしれません。それでも、「現状サービスの悩み」を聞く相手としては最良です。乗り換えを止めている理由、いま払っている時間とお金、こうした話は既存顧客が一番よく知っています。
週1件でよいのです。10週で10件の逐語記録と仮説台帳が手元に残ります。稟議書を書く段階で、「顧客の言葉で書かれた課題の一覧」と「支持3件・反証1件」のような検証状況があるかどうか。これがあるだけで、社内の議論は「面白そうか」から「何が確かめられていて、何がまだか」に変わります。上司が指摘するべき場所も明確になります。
もう一つ、大企業ならではの落とし穴があります。法務です。録音、文字起こし、AIへの入力。これらは、事前に同意書の雛形と、社内で使ってよいAIツールの範囲を決めておかないと、毎回止まります。最初の1週間で、法務と一緒に「インタビュー同意書」「個人情報の伏せ字ルール」「利用するツールと、データを外部に送る条件」の3点を紙にしておいてください。これは事業開発部門の仕事です。後回しにすると、10件目のインタビューの直前に全部が止まります。
WARPでは、この「聞く、作る、抽出する」の1サイクルを、参加者自身の事業テーマで実際に回すところまでを扱っています。方法論は読めば分かります。しかし、初回のインタビューで自分がどれだけ誘導しているかは、指摘されないと分かりません。WARPのページに、プログラムの構成を載せています。
まとめ
この記事で書いたことは、道具の話に見えて、実は順番の話です。聞いてから、作る。作ったものを、提案ではなく質問として見せる。記録を、引用付きで残す。1件で決めない。AIは、この順番を守るかぎり、新規事業開発の速度を一桁上げてくれます。順番を崩すと、綺麗な資料と空っぽの仮説台帳が残ります。
明日やるなら、まず社内の誰かに、この記事のインタビューガイドのプロンプトで作った台本を使って、30分だけ話を聞いてみてください。相手は同僚で構いません。終わったら、文字起こしを抽出プロンプトに通し、8番の「自分が誘導した箇所」を読む。それが、この方法論の最初の一歩です。自社の新規事業テーマでこのサイクルを設計したい方は、個別相談でお話ししましょう。
