アンケート、いきなり設問から作ってませんか？ ― AIと挑んだ非デザイナーのアンケート作成奮闘記

背景

「アンケート？ サービスデザイナーさんに頼めばいい」

間違いなく設問設計は専門職の方が質の高いものを作れます。

でも最近は生成AIで生産性が上がり、3人くらいの少数チームで案件を回すことが増えました。

そして、そのチームにデザイナーがいない。

そんな状況で「アンケート取らなきゃ」という場面が来たら、どうしますか？

これは、設問設計の専門家ではない私が、AIと協業することで再現性のある形でアンケートを約1時間で作れるようになった話です。

この記事で分かること

• なぜ「設問から書く」と失敗するのか
• 下したい判断から逆算してアンケートを作る5ステップ
• そのステップを「人がやること」と「AIがやること」にどう分けるか
• そのまま使えるプロンプト（コピペ可）

対象読者

• アンケート・サーベイを作る必要があるが専門ではない人（PO・スクラムマスター・企画・エンジニアなど）
• AIを使った実務の進め方に興味がある人

この記事で使う例：「社内LT・勉強会の改善アンケート」

具体例として、「社内LT・勉強会の改善アンケート」を題材とします。

コンテキスト

• 有志で社内LT会（技術共有の勉強会）を運営している
• 次回に向けて満足度と改善点を集めたい
• 回答者は、「登壇した人・参加した人・今回は参加しなかった人」が混ざっている

つまずき：設問から書いたら「あれ、このアンケート何の価値があるんだろ？」

自分にノウハウはないが、アンケートを作らなきゃいけない。

私はとりあえずAIに、口頭でざっくり「LT会について、満足度とか改善点をこういう感じで聞きたいんだよね」と思いつくままに投げました。

するとAIは、それをアンケートで使えそうな設問の形にきれいに整えてくれます。

設問が並び、体裁としては“それっぽいアンケート”が数分で出来上がりました。

……ただ、眺めているうちに引っかかりが出てきます。

「あれ、このアンケート、そもそも何の価値があるんだっけ？」

その違和感を抱えたまま内部レビューに出したら、案の定こう聞かれました。

「このアンケートで、結局なにを把握したいんだっけ？ その結果を、次のどんな行動につなげるの？」

……答えに詰まりました。（そりゃそう）

設問から書き始めたので、そこが設計されていなかったのです。

「なんとなくLT会についてどう思っているか知りたい」くらいの解像度、目的がふわっとしている。

そして困ったことに 聞きたいことが絞れません。

満足度も、テーマの希望も、開催時間も、懇親会も……あれもこれも聞けそうに見えて、どの設問も「これで何を判断するのか」に答えられない。

目的に合わせて設問を設計していない、というのはこういう状態です。

設問から書くと「把握したいこと → 次の行動」がふわっとし、結局、聞きたいことが絞れない。

気づき：AIに渡すのは"設問"ではなく"逆算するための情報"

失敗の原因はシンプルでした。

私はAIに「聞きたい設問」を渡していた。

そうではなく、渡すべきだったのは 「逆算するための情報」

つまり、最後に下したい判断、制約、現場のコンテキストです。

それさえ渡せば、設問への整理はAIが得意とするところでした。

やり方を「逆算」に変えます。

下したい判断（アクション） → 把握したい情報 → 検証したい問い・仮説 → 設問

この順で考えると、「どの判断にも効かない設問」を自然に落とせます。

設問から作るな。逆算で作れ。AIに渡すべきは"逆算するための情報"。

逆算設計の5ステップ（人が渡す / AIが整理 / 人が突っ込む）

全体像はこうです。

ステップ	内容	主にやるのは
1. 制約	器（時間・問数・ツール・回答者）を決める	人 → AIに渡す
2. 目的	下したい判断（複数軸）を渡す	人 → AIに渡す
3. 知りたいこと＋仮説	知りたいこと・現場の勘・過去データを渡す	人 → AIに渡す
4. 設問化	設問に整理する	AIが叩き台／人が突っ込む
5. 回答者目線レビュー	答える人になって点検する	人が突っ込む

LT会アンケートを題材に、順に見ていきます。

Step1：制約 ― まず"器"を決める

設問を考える前に「器のサイズ」を決めます。

ここを渡さないと、AIは平気で設問を膨張させます。

聞きたいことは無限にあるので、設問数が膨れて回答者の負荷が跳ね上がったり、配布ツールで作れない形式の設問が混じったりするからです。

LT会アンケートなら、渡すのはこのあたりです。

• 回答者の負荷
  • 「5分で答えられて十分」を目安に、設問数もそこに収める（例：10問以内）
  • 忙しい人に長いアンケートは回答してもらえない
• 回答者はどんな人か
  • 登壇者・参加者・不参加者が混ざる
  • 立場によって答えられること・答えやすい形が変わるので、そこを意識して設問を作ってもらう
• どの配布ツールで配るか
  • Microsoft Forms / Google Forms などツールごとに対応している設問形式が違う
  • そのツールで表現できる形に限定する

制約を先に渡して、AIが"使えない形式・膨大な設問数"を出してくるのを防ぐ。

Step2：目的 ― 下したい"判断"は1軸とは限らない

「この結果で、誰が何を決めるのか」を渡します。

ここで大事なのは、判断は1軸とは限らないということ。

LT会アンケートでも、絡む軸は複数ありました。

• 判断の軸
  • 次回も開催するか（継続）
  • 内容・運営をどう改善するか
  • 参加者をどう増やすか
• 開催形式の軸
  • オンラインでやるか
  • 対面でやるか

軸が複数あるなら、全部そろえてAIに渡します。

そのうえで 優先順位＝設問数の配分（どこを厚く聞くか）を人が決めて渡すのが肝心でした。

限られた10問を、勝手にAIに均等配分させないためです。

「今回は"参加者を増やす"ための判断材料を厚めに」と決めれば、そこに設問を寄せられます。

判断軸を漏れなく全部AIに渡しきる。そのうえで"設問数の配分"を人が決める。

Step3：知りたいこと＋仮説 ― 現場の勘を渡すと"検証"になる

目的を「答えるべき問い」に分解し、各問いに 事前の仮説 を1つ添えます。

仮説を置くと、設問が「当たり外れを確かめる＝検証」になって鋭くなります。

LT会アンケートの例です。

• 知りたい問い
  • なぜ参加しない人がいるのか？
  • 参加の障壁はどこにあるのか？
• 立てた仮説
  • 「テーマに興味がない」より、"日程・時間が合わない" と "そもそも開催を知らなかった（告知不足）" が主なのでは？

この仮説があるからこそ、「参加しなかった理由」を聞く設問の選択肢に、その2つを必ず入れます。

すると回答で 仮説が当たったか外れたか が分かる。

これが「検証になる」ということです。

さらに、過去のアンケートデータ（前回のLT会アンケートなど）があれば、それで仮説をブラッシュアップして「確実に聞くべき仮説」に磨けます。

人が"現場の勘（仮説）"を渡し、設問を「検証」にする。

Step4：設問化 ― AIが叩き台、人は"現場の突っ込み"

ここまで情報を渡せていれば、AIがかなりいい感じに設問へ整理してくれます。

人の役割は、叩き台に対して 現場ならではの突っ込み を入れることです。

LT会アンケートなら、たとえばこんな突っ込みが必要でした。

• 「オンラインが良い」は本当に形式のせい？
  • 前回がたまたまオンラインで、告知もチャットだけ
  • 形式の良し悪しと、別の要因（告知不足）が混ざっているかもしれない
  • → 切り分ける
• 満足度を5段階で聞くだけでは改善につながらない
  • → 「どこを改善したいか」を具体的な選択肢で聞く
• 登壇者と参加者では聞きたいことが違う
  • → 役割で分岐して、無関係な設問を見せない
• 「参加しなかった理由」を自由記述にすると、たいてい書いてもらえない
  • → 選択肢にする

特に効いたのが「比較を中立に聞く」でした。

開催形式（オンライン/対面）を例に、before / after で示します。

Before（決めつけていた設問）

Q. オンライン開催が対面より良い点は？（複数選択）
  - 移動がいらない
  - 気軽に参加できる
  - 録画を後で見られる

これだと「実は対面の方が良い」という声が拾えません。

しかも、オンラインが選ばれるのは単に前回オンラインだったからで、形式そのものの評価と混ざってしまいます。

After（中立＋観点ごとに聞く）

Q. オンラインと対面、各観点でどちらが良いと感じますか？（行ごとに1つ）
                       オンラインが良い / 同等 / 対面が良い / どちらでもよい
  参加のしやすさ
  発表の聞き取りやすさ
  質問・議論のしやすさ
  参加者どうしのつながり

こうすると両方向に答えられ、かつ「参加のしやすさはオンライン、つながりは対面」のように 観点ごとに強み・弱みを分けて 読めます。

全体を一括で「どっちが良い」と決めつけずに済みます。

もう一つ、原因の切り分けも1問でやれます。

Q. 前回、参加しなかった主な理由は？（1つ選択）
  - 参加した
  - 日程・時間が合わなかった
  - テーマに興味がなかった
  - 開催を知らなかった

「日程」なら日程調整、「興味」ならテーマ改善、「知らなかった」なら告知強化。

理由によって打ち手が変わるので、設問を増やさずに次の一手が決まります。

設問の叩き台はAIに任せ、人は"業務知識でズレを直す"に集中する。

Step5：回答者目線レビュー ― 出す前に、答える人になって読む

最後に、配る前に回答者の立場で読み直します。

チェック観点はこれくらいです。

• その人が実際に知っている範囲で答えられるか（不参加者に「発表の質は？」は聞けない）
• 特定の職種にしか分からない専門用語を使っていないか
• 誘導していないか／選択肢に抜け・重複はないか
• 回答に手間がかかりすぎていないか
• 自由記述は最小限か（文章を書くのは負荷が高いので最後に1問だけ）

最後は人が「答える人」になって読む。AI任せにしない。

そのままAIに貼れる：逆算アンケート設計プロンプト

この作業プロセスは、ChatGPT でも Claude でも、AIツールを問わず使えます。

以下をそのままコピペして使ってみてください。

あなたはアンケート設計のプロです。私が作りたいアンケートについて、
いきなり設問を書かず、次の5ステップで一緒に設計してください。
各ステップで足りない情報は、先に私に質問してください。

1. 制約の確認
   回答時間・設問数の上限、回答者の属性（役割・部署）、配布ツール
   （例：Microsoft Forms / Google Forms）、匿名/記名を確認する。
   配布ツールで実際に作れる設問形式に限定する。

2. 目的（下したい判断）の整理
   この結果で誰が何を判断したいかを確認する。判断の軸が複数あるなら
   全部洗い出し、設問数の配分（どこを厚く聞くか）の優先順位を一緒に決める。

3. 知りたいこと＋仮説
   目的を「答えるべき問い」に分解し、各問いに事前仮説を立てる。
   過去の類似アンケートがあれば、それで仮説をブラッシュアップする。

4. 設問化
   仮説を検証できる設問に変換する。似た問いは1問にまとめ、
   原因を切り分けたい所は選択肢で分ける。比較は中立に（両方向に
   答えられる形で）。センシティブな内容は選択肢中心にする。
   作った叩き台を私がレビューするので、現場感覚のズレは指摘してほしい。

5. 回答者目線レビュー
   本人が答えられるか、専門用語を使っていないか、負荷が高すぎないか、
   誘導していないかを点検する。

最終成果物は「制約・目的・質問本文」の3部構成にしてください。
質問本文は、そのまま配布ツールに貼れるクリーンな形（設問と選択肢の
箇条書き、評価スケールは全段階を明記）でお願いします。

やってみた結果

設問設計の専門家ではない私でも、アンケートが約1時間で形になりました。

ただ、本当に価値だと感じたのはスピードではなく、冒頭で言った「何を把握して、どう次の行動につなげるか」まで一気通貫でつながったことでした。

• 手戻りなく承認された
  • ステークホルダーを交えたレビューでも、「で、何がしたいの？」と差し戻されることなく、大きな手戻りなしにアンケートの内容が承認された
  • 目的と設問がひもづいていたから
• 意図したことが、ちゃんと把握できた
  • 実際に配って集計したら、最初に「把握したい」と決めていたことが、狙いどおりに分かった
  • 集めて終わりの数字ではなく、判断に使えるデータになっていた
• 次の行動を、チームで議論できた
  • その結果をもとに「じゃあ次どうする？」をチームで話せた
  • まさに、目的 → 把握 → 次の一手までつながった

うまくいった要因は、5ステップを「人が判断し、AIが整理する」役割分担（ヒューマン・イン・ザ・ループ）として回したことです。

各ステップで人がコンテキストを渡し、AIが設問に整え、人が現場感覚で突っ込む。

この往復が効きました。

まとめ

• アンケートは設問から作らず、下したい判断から逆算する
• AIに渡すのは「聞きたい設問」ではなく 「逆算するための情報」（制約・判断・現場のコンテキスト）
• 進め方は5ステップ：制約 → 目的（複数軸なら配分も渡す）→ 知りたいこと＋仮説 → 設問化 → 回答者目線レビュー
• 設問化はAIが上手く叩き台を作ってくれる、人は 現場知識でのズレの修正 に集中する
• 合言葉は「まず"何を決めたいか"から書く」

専門職に頼れなくても、AIと役割分担すれば、チームが次どう行動するかの判断につながるアンケートは作れます。

同じ境遇のそこのあなた、是非このやり方を試してみてください！