AIが質問して、私が答える——導入事例から1,527問を作らせて、答える候補として残ったのは761問だった

このブログは、自社のCMS「writeWired」のサイトを、AIと一緒に作り直してきた記録です。この記事の作業は、2026年7月29日と30日の2日間です。プロンプトの設計と集計はClaudeと進め、質問の生成はwriteWiredの機能からAIのモデルに一括で実行させました。

やりたかったこと：検討している人が使う言葉を知りたかった

作り手には、検索の言葉が分からない

writeWiredのサイトには、管理画面の機能を1画面1ページで、事実だけ書いたページがあります。社内では機能リファレンスと呼んでいます。よくある質問に1問1ページで答えるFAQもあります。ページ同士は互いにリンクでつないであります。

次の課題は、これらを見つけてもらうことでした。見つけてもらうには、探している人が使う言葉で書かれている必要があります。ところが、その言葉が作り手には分かりません。製品を探している人が、どんな言葉で検索しているのかが分からないのです。

私は、探している人が使う言葉の候補を「当事者の文脈の辞書」と呼ぶことにしました。この辞書の言葉と、機能リファレンスやFAQをリンクでつなぐ。それが目標でした。

導入事例を、AIに検討者の立場で読ませる

辞書の元として、導入事例に目を付けました。writeWiredのサイトには、お客さんの導入事例が20ページあります。導入事例は、読んだ人が「これはうちの話だ」と思い、問い合わせにつながるように書いています。

これを逆から使います。AIに導入を検討している人の役をさせて、導入事例を読ませる。そこで出てくる「ここが知りたい」が、そのまま辞書になるのではないか、と考えました。

出てきた質問には、私が答えます。FAQを作り直したときは、AIが答えを書き、私が確認しました。今回は配役が逆で、AIが質問を作り、私が答えます。

こうやってみた：事例20ページを読ませて、まず276問

最初のプロンプト

最初にAIに渡したプロンプトの趣旨は、次のとおりです。

• 立場は、情報システム部門・マーケティング部門・Web運用担当のいずれかを、事例の内容に合わせて選ぶこと
• 導入事例の本文を読んで、「ここが知りたい」と思った質問を挙げること
• 既存のFAQ117問と同じ趣旨の質問は出さないこと（禁止リスト）。言い換えや、細かさを変えただけのものも不可
• 質問の一つひとつに、元になった事例本文の記述を添えること
• 質問は、自社に引き寄せた形にすること

禁止リストを入れたのは、機能全般のFAQと同じ質問がまた出てくるのを避けたかったからです。最後の一行は、読む人に「自分のことだ」と思ってもらうために入れました。

出てきた質問

20ページすべてに実行して、276問が出ました。たとえば、こんな質問です。

当社は繁忙期にアクセスが集中しますが、このサイトでは想定同時接続数やピーク時の応答時間をどの水準に置き、どのような負荷試験を行ったのでしょうか。
——元の記述「年商1,000億円超の国内大手製薬企業」

約8,000ページを2ヶ月で公開するために、A社側では何人が参加し、コンテンツ整理や確認にどの程度の工数をかけましたか？
——元の記述「コンテンツ数：約8,000ページ／開発期間：2ヶ月」

読んだ第一印象は「すぐには答えられない質問が多いな」でした。性能の話は前提を聞かないと答えられませんし、工数の話は個別の数字です。

似た質問を束ねて数えると、一番多かったのは費用・期間・成果の59問、次が移行・切替の46問でした。機能の名前はほとんど出てきません。検討している人が聞くのは、機能のことより、プロジェクトのことでした。

ただ、この276問は、一つの聞き方で出たものにすぎません。聞く立場が変われば、出てくる質問も変わるのではないか。それを確かめないまま、「費用の質問が多い」と結論するわけにはいきませんでした。

こうやってみた：聞く立場とモデルを1か所ずつ変えて、9パターン

変える場所は、1回に1か所

最初のプロンプトを基準にして、変える場所を1回につき1か所だけにしました。2か所いっぺんに変えると、質問が変わったときに、どちらが原因か分からなくなるからです。

質問は合計1,527問、経験談の種が160個になりました。

分かったこと

一つ目。聞く立場が、質問の領域を決めました。同じ20ページを読ませているのに、制作パートナーの立場では160問のうち88問、55%がテンプレートの話でした。運営担当では32%が更新の運用。情報システム部門では障害・保守の質問が46問出ました。基準では7問だった話題です。決裁者の立場では、費用・期間・成果が48問でした。

二つ目。質問を事例から離さなかったのは、禁止リストではありませんでした。禁止リストを外して回しても、既存のFAQと同じ趣旨の質問は出てきませんでした。効いていたのは、質問ごとに「元になった事例本文の記述」を添えさせる一行です。出どころを毎回指させると、AIは事例に書いていない話を作りにくくなります。

三つ目。モデルを替えると、質問の深さが変わりました。一方は複数の事例にまたがるテーマを出し、もう一方は各事例の細かい作りに踏み込みました。

こうなってしまった：読んでみると、答えるべきでない質問が多かった

数えている間は、財産に見えていた

ここまでは、質問を数えていました。数えて分かるのは、どの話題に質問が集まるかまでです。次に、中身を読みました。

当社では障害・災害時のRTOとRPOを審査項目にしています。この構成の目標復旧時間、データ損失許容時間、バックアップ保持期間、復元試験の頻度を教えてください。

この案件の初期費用、追加開発費、月額利用料、運用保守費はそれぞれいくらで、何年で投資回収する想定だったのでしょうか。

前者は情報システム部門、後者は決裁者の立場から出た質問です。数字をそのまま聞くもの、審査の項目を並べるもの、「当社は〜ですが」とこちらの知らない会社の事情を前提にするもの。読んでいくと、事例のページで答える話ではない質問がかなり含まれていました。辞書の材料としては使えても、出てきた質問にそのまま答えられるわけではありませんでした。

原因の一つは、自分のプロンプトだった

固有の数字を聞く質問を外したあとも、「答えられない」質問が多く残りました。原因は、最初のプロンプトに入れた「自社に引き寄せた形にすること」の一行でした。

この一行で、AIは「当社は〜ですが」という架空の会社の事情を作るようになっていました。架空の事情を前提にした質問は、事例に書いていない部分を聞いてきます。正直に答えると「できません」「分かりません」が並びます。

事例本文の記述を指させる指示で、AIの創作を止めていました。ところが同じプロンプトの中で、引き寄せの部分だけは、自分から創作を許していたことになります。

だからこうしてみた：仕分けながら答えない基準を言葉にし、行き先を決めた

答えない理由を、二つ決めた

仕分けながら、私は答えない理由を二つ言葉にしました。

• 固有の数値は書かない。費用、性能、工数、投資回収、検索順位。書けば相場観として一人歩きします。費用の答えは、導入プランのページの「お問い合わせください」です
• 役務の約束になることは書かない。書けば、できなくてはいけなくなるからです

二つ目の基準は、この日の仕分けでは一部にしか当てはめきれていません。当てはめて削除したのは、最後の読み直しで見つけた、公開前の確認の進め方を聞く4問だけです。役務の約束になりそうな質問がまとまった束（91問）は削除の方向で考えていましたが、決めきれず、残った761問の中に入ったままにしました。

大きく分けられる単位から順に落とした

1,527問を頭から1問ずつ読んだわけではありません。大きく分けられる単位から落としていきました。

最初は、どの立場から出た質問か、です。禁止リストを外した160問は実験用なので、最初から数に入れません。制作パートナーの質問は、事例のページが想定する読者ではないので、パートナー向けFAQという別のコーナーに回すことにしました。情報システム部門と決裁者の質問は、審査の項目と数字が中心だったので、立場ごと外しました。ただし移行と切替の質問だけは、どの立場から出たものでも残しました。移行は、誰が聞いても移行だからです。

次に、費用・性能・工数・成果のように固有の数値を聞く束は、束ごと「答えない」にしました。ここまで落としてから、残りを1問ずつ読んで決めました。

答える640問と、迷って保留にした121問を合わせて761問。1,527問のうち、事例の文脈で答える候補として残ったのは、およそ半分でした。

「当社は〜ですが」と架空の事情を前提にした質問は、表の行としては分けていません。固有の数値を聞くものや、外した立場から出たものは、上の行で落ちています。それ以外は、761問の中に残りました。架空の事情を前提にした質問に、どう答えるか。できること・追加開発になること・対応しないことを質問ごとに見分けてから答えを書く、という案が出ていましたが、この日には決めていません。答えを書く段の宿題として残しました。

件数の多さは、答える理由にならなかった

仕分けていて、もう一つ気づいたことがあります。同じ趣旨の質問がたくさん出ても、それだけ大事な質問だとは限りません。

たとえば、同時編集についての質問は山ほど出ました。でもwriteWiredの答えは「更新は先に保存した人が優先」という方針一つで、全部に答えられます。AIが演じる検討者は、提案依頼書のチェックリストのような質問を忠実に並べます。件数は、その再現の量です。どれに答えるかは、人が決めることでした。

経験談の種160個のほうは、質問ではないので仕分けの外です。整理すると、こちらから差し出すノウハウ記事の目次34本になりました。

その後

761問に答える作業より先に、私は経験談の種から作った目次に取りかかりました。全部が自分の「語れること」でできていたからです。この目次はその後、writeWiredでの作り方の考え方をまとめる記事集に形を変えました。こちらも導入事例を材料に書こうとして行き詰まり、最後は記事ごとにAIに質問させて、私が答える形で書き直しています。そのとき私は、導入事例から検討する人の言葉は取り出せたが、生々しくて、サイトのコンテンツとしては使えなかった、と振り返っています。事例を材料にするなら、事例の書き方そのものを先に決める必要がある、という結論でした。

制作パートナー向けFAQに回した139問も、その後、そのコーナーを作る路線自体をやめています。

今回の作業で分かったこと

AIに読者の質問を作らせるなら、聞く立場を変えて何度か出す

最初の276問では、費用・期間・成果の質問が一番多く出ました。でも、聞く立場を一つ替えるだけで、質問が集まる話題は別の場所に移りました。一つの聞き方で出た結果は、一つの断面です。AIに想定読者の質問を出させるときは、誰として聞かせるかを変えて比べないと、偏りに気づけません。

創作を止めるのは禁止より、根拠を指させること

禁止リストを外しても、質問は事例から離れませんでした。効いていたのは、元になった記述を毎回添えさせる指示です。一方で、「自社に引き寄せて」という指示は、AIに架空の事情を作らせました。同じプロンプトの中に、創作を止める指示と、創作を許す指示が同居していました。AIに書かせる指示を足すときは、それが根拠のない部分を埋めさせる指示になっていないかを確かめる必要があります。

出てきた質問は、答える候補にすぎない

質問は抽出できました。でも、そのまま答えられる質問ばかりではありませんでした。固有の数字、こちらの知らない会社の事情、審査の項目。件数が多いことも、答える理由にはなりませんでした。どれに答えるかは、人が選ぶしかありません。今回は、どの立場から出たか、固有の数値を聞く束か、という大きな単位で先に落とし、残りを読みながら答えない理由を言葉にしました。それでも、役務の約束に当たりそうな91問や、迷った121問は、この日には決めきれていません。基準は最初からあったのではなく、仕分けながらできていきました。