ユーザーの本音を聞き出したい。でも聞くべきことは決まっているから、雑談で終わらせたくない——そんなときに使うのが半構造化インタビューです。
定性調査の実務でもっともよく使われる形式ですが、いざ自分でインタビューガイドを作ろうとすると「質問をどこまで固定すべきか」「深掘りはどう設計するのか」で手が止まりがちです。
この記事では、半構造化インタビューの位置づけ（構造化・非構造化との使い分け）から、インタビューフローの作り方を5つのステップで整理し、そのまま使える質問例テンプレートを紹介します。
あわせて、多くの実務者がつまずく「深掘りの分岐設計は人手では回りきらない」という構造的な問題と、AIインタビューによる解決アプローチも実際の画面つきで解説します。
半構造化インタビューとは、あらかじめ質問項目（インタビューフロー）を用意しつつ、回答に応じて質問の順序変更や深掘りを許すインタビュー手法です。台本どおりに進める「構造化」と、テーマだけ決めて自由に話す「非構造化」の中間に位置します。半構造化インタビューでは、この質問項目のまとまりをインタビューフローと呼びます（インタビューガイドと表記されることもありますが、指すものは同じです）。
3つの手法の違いを整理すると次のようになります。
使い分けの目安はシンプルです。
•仮説の検証が目的で、回答を横並びで比較したい → 構造化
• テーマがまだ曖昧で、何を問うべきかから探したい → 非構造化
•仮説はあるが、その背景・理由・文脈まで知りたい → 半構造化
ユーザーインタビューや顧客ヒアリングの実務は、たいてい3つ目に当てはまります。「聞くべきことは決まっているが、想定外の話こそ聞きたい」——この両立を狙うのが半構造化インタビューであり、だからこそインタビュー設計、つまりフローの品質が結果を大きく左右します。
インタビューフローの作り方は、次の5ステップで進めると迷いません。60分のインタビューを想定した時間配分の目安も添えます。
最初に決めるのは質問ではなく「この調査で何に答えを出すのか」です。例えば「動画配信サービスの解約者は、何をきっかけに解約を決めているのか？」のように、リサーチクエスチョンを1文で書き切ります。ここが曖昧なまま質問を並べると、聞き終わってから「で、何が分かったんだっけ」となります。
リサーチクエスチョンに答えるために必要なトピックを書き出し、must（これが聞けないと調査が成立しない）とnice-to-have（時間があれば）に分けます。半構造化インタビューは脱線を許す設計なので、時間が押したときに何を削るかを先に決めておくことが重要です。60分なら must のトピックは3〜4個が現実的です。
トピックごとに実際の質問文を書きます。このとき意識するのは3点です。
• オープン質問を基本にする
「はい/いいえ」で終わる質問ではなく、「〜について教えてください」「どんな場面で〜しましたか」と経験を語ってもらう形にする
• 誘導を避ける
「値上げが不満だったんですよね？」ではなく「解約を考え始めたきっかけを教えてください」と、こちらの仮説を言わせない言い回しにする
• 順序を設計する
答えやすいウォームアップ（5〜10分）→ 本題ブロック（40分前後）→ クロージング（5〜10分）の流れを作り、いきなり核心から入らない
半構造化インタビューの価値は深掘りで決まります。よく使う深掘りの型は次の3つです。
•なぜ: 「それはなぜですか？」「何がそう感じさせたのでしょう？」
• 具体的には: 「具体的なエピソードはありますか？」「直近ではいつでしたか？」
• 他には: 「他に理由はありますか？」「逆に良かった点は？」
さらに実務では、回答パターンごとの分岐をフローに書き込みます。
「解約理由が『サービスへの不満』なら不満の中身と強さを掘る。『引っ越しや家族構成の変化』なら生活の変化とサービス評価を分けて聞く」のように、想定される回答の型ごとに次の一手を用意しておくのです。
この分岐設計こそ半構造化の肝ですが、後述するとおり、まじめにやるほど破綻しやすい部分でもあります。
フローができたら、本番の前に社内の1〜2名で通しのリハーサル（パイロット）を行います。質問の意味が伝わるか、時間内に収まるか、深掘りの分岐が実際の回答とかみ合うかを確認し、フローを改訂します。
1回のパイロットで質問文の3割は書き直しになる、くらいの前提でスケジュールを組んでおくと安全です。
ここからは、上の5ステップを反映した質問例のテンプレートです。まず汎用の雛形、続いてシーン別の質問例を2パターン紹介します。コピーして自社のテーマに置き換えてください。
テンプレートの └回答が〜なら の行に注目してください。
解約理由そのものの調査設計（タイミング・謝礼・匿名性）は「解約理由調査のやり方」で解説しています。
これが Step 4 で説明した深掘りの分岐です。そして実は、この分岐こそが半構造化インタビュー設計の最大の難所になります。
上のテンプレートでは、1つの質問につき2〜3パターンの分岐を書きました。
これを本題3ブロックすべてに用意し、さらに深掘りを2段階（回答→深掘り→その回答への深掘り）まで想定すると、分岐の組み合わせは簡単に数十通りに膨らみます。
60分×N人のインタビューで、この分岐ツリーをすべて紙のフローに書き切ることは現実的ではありません。
その結果、実務では2つの負荷がモデレーター個人に集中します。
1つ目は「判断」の負荷です。 分岐の条件は「回答者がサービスに不満を持っていそうなら」「ポジティブな反応なら」といった定性的なものです。回答を聞きながらその場で解釈し、次にどの質問へ進むかを判断する——これはフローに書けない、モデレーターの瞬発力に依存する作業です。
人によって判断がぶれ、同じ調査でもインタビュアーごとに掘れている深さが変わります。
2つ目は「深掘りの実行」の負荷です。どこまで掘るか、何と言って追い質問するかは、結局その場の言葉選びです。
経験の浅いインタビュアーは「なるほど、ありがとうございます」と流してしまい、あとで発言録を読んだ関係者が「ここ、なんで深掘りしなかったの？」と嘆く——定性調査あるあるではないでしょうか。
さらに深刻なのはスケールの壁です。熟練モデレーターが同時に実施できるインタビューは当然1件だけ。対象者を10人、20人と増やすほど日程は延び、後半のインタビューでは疲労で品質が落ち、複数人で分担すれば今度は人によるばらつきが混ざります。「分岐設計をまじめにやるほど、実施できる人が限られていく」というジレンマが、半構造化インタビューには構造的に存在します。
このジレンマに対する解決アプローチとして、弊社の AIインタビュープラットフォーム 「コルクトーク」がどう深掘りを扱っているかを、実際の画面で紹介します。
先に要点を言うと、コルクトーク は「AI が勝手にインタビューを組み立てる」のではありません。分岐はこれまで通り設計者がフローとして設計し、実査中の「判断」と「深掘りの実行」だけを AI が担う、という役割分担です。ここまで読んできたフロー設計のスキルは、そのまま活きます。
今回は例として、先ほどのテンプレート2をベースにした「動画配信サービスの解約理由デプス調査」を実際に作成しました。
設計画面のフロー全体がこちらです。
スクリーニング設問 → 対象者判定 → 解約のきっかけを聞くトーク → 解約理由の型で分岐 → 「不満の深掘り」または「状況変化の深掘り」→回答確認、という流れです。
紙のフローでは文章で書くしかなかった分岐が、ブロックのつながりとしてそのまま表現されています。
回答者と対話しながら深掘りするパートは「トーク（AI）」ブロックが担当します。
設計者が書くのは、そのブロックの目的と聞きたい質問、そして深掘りレベル（軽め/普通/深め）だけです。
「なぜ」「具体的には」「他には」といった追い質問の一つひとつを書き出す必要はありません。どこまで掘るかの深さをレベルで指定すれば、その範囲で AI が文脈に合わせた追い質問を行います。
回答者が特定のサービス名や人物に言及した場合に具体名を聞き出すオプションも、チェックボックス1つで設定できます。
分岐そのものは、設計者が分岐ブロックで明示的に設計します。
選択式の回答（「解約経験あり/なし」など）は通常の条件で決定論的に分岐できますが、コルクトーク の特長は直前の会話内容そのものを条件にできることです。
今回の調査では「回答者が料金・コンテンツ・使い勝手などサービス自体への不満を理由に解約を考えたと判断できるか判定してください」という条件を LLM 条件として設定しました。
実査中はこの判定を AI が行い、true なら「不満の深掘り」へ、そうでなければ「状況変化の深掘り」へ進みます。判定できなかった場合にどちらへ倒すか（フォールバック）も指定できるため、挙動は常に決定的です。
つまり、モデレーターの頭の中にしかなかった「この人は不満型か、環境変化型か」という実査中の判断が、設計時に書ける明文化された条件になるということです。判断基準が明文化されるので、10人実施しても100人実施しても同じ基準で分岐します。
このインタビューに、筆者が1人の回答者として実際に答えてみました。「不満の深掘り」ブロックで「一番の不満は値上げ。
子どもが生まれて視聴時間が取れなくなり、月1,480円を払う価値を感じられなくなった」と答えたところ、AI は次のように返してきました。
参加者の回答画面。値上げへの不満を答えた参加者に対し、AI が視聴タイミングを尋ねる追い質問を返している
「お子さまが生まれて視聴時間が減ったとのことですが、普段はどんなタイミングでサービスをご覧になっていたんでしょうか」
——この質問はフローのどこにも書いていません。回答の中の「子どもが生まれて」という文脈を拾って、利用シーンを特定しにいく追い質問を AI がその場で組み立てています。設計者がやったのは、深掘りレベルを「深め」にしたことだけです。
実施後の管理画面では、セッションごとに「どの分岐が、どの条件で、どう判定されたか」まで確認できます。
人間のモデレーターの頭の中で行われていた判断はあとから検証できませんが、ここでは「解約理由の型で分岐」ブロックが条件にマッチして「不満の深掘り」へ遷移したことが記録されています。
判断の透明性という点で、人手のインタビューでは得られなかった情報です。
やり取りの全文も、ブロックの区切りごとにタイムスタンプ付きの文字起こしとして残ります。
そして AIインタビューは同時に何セッションでも走ります。「分岐設計をまじめにやるほど実施できる人が限られる」というジレンマは、設計はこれまで以上にまじめにやり、実行だけを AI に任せることで解消できるわけです。
従来手法とのコスト比較は、関連記事「デプスインタビューの費用相場と期間」で詳しく解説しています。
デプスインタビュー自体の進め方は「デプスインタビューとは？やり方・質問例・費用まで実務で使える完全ガイド」で整理しています。
最後に、この記事の要点を3行でまとめます。
• 半構造化インタビューは「フローで骨格を固め、深掘りで想定外を拾う」手法。仮説はあるが背景も知りたい調査に最適
• インタビューフローの作り方は、目的の1文化 → トピックの優先順位づけ → 質問文化 → 深掘り・分岐の設計 → パイロット検証の5ステップ
• 深掘りの分岐は設計するほど人手で回らなくなる。分岐は人が設計し、実査中の判断と深掘りの実行を AI に任せるのが現実解
質問例テンプレートはそのままコピーして使えるように書きました。
まずは自社のテーマで1本、フローを設計してみてください。
そして「この分岐、人手で回るだろうか」と感じたら、AIインタビューを試すタイミングです。
コルクトークなら、この記事で見たとおり設計画面でフローを組み、URL を配るだけで24時間・複数名同時のインタビューが動き始めます。
