背景
Claudeに AskUserQuestion という機能があります。選択肢つきの質問を出してくれて、こちらはボタンを押すだけで答えられるやつです。
評判は良く、実装の方針をどうするか、この操作を実行していいか。開発の場面で聞かれることの多くは答えの候補が出そろっている確認で、押すだけで済むのは助かる。紹介記事もいくつも出ています。
- Claude CodeのAskUserQuestionツールとは？選択肢形式の質問を提示してくれる隠れ機能を紹介
- Claude Code の AskUserQuestion でユーザーフレンドリーな選択肢を出す
- Claude Codeへの指示を少しでもさぼりたい！AskUserQuestionツール
ただ、自分は毎回この質問を中断していました。
自分がClaudeとよくやるのは、抽象度の高い相談です。ステークホルダーとの合意形成に使うドキュメントを作るとか。何を軸に置くか、どの順で納得してもらうか、といった話をしています。
この手の相談だと、選択肢を押すだけでは自分の言いたいニュアンスが乗りません。近いものはあるけれど、そのままではない。それがかなりの頻度で起きます。
最初は「なんか選ぶのが逆に手間になっている？」と思っていました。でも先日、そのもやもやをClaude自身に分析してもらったら、思っていたのとは違う答えが返ってきました。
この記事では次のことを書きます。
- 選択肢への違和感の正体が「自分の答えが選択肢の外にある」ことだったという話
- AskUserQuestionで聞いていい問いと、そうでない問いの線引き
- Claudeにそのままコピペして貼れる指示文
対象読者は、Claude Cowork を日常的に使っている人です。とくに合意形成の文書づくりや企画の相談に使っている人、音声入力で話しかけている人には、思い当たるところがあると思います。
最初は、なんとなく選んでいた
キーボードで打ってやり取りしていた頃の話から始めます。
選択肢が出てくると、そこから選ぶのが一番速いです。文章を打つより手間がかからないので、素直に押していました。
そのうちどうなったかというと、自分で考えなくなりました。
出された選択肢を眺めて、この中ならこれかな、という選び方をします。自分の頭の中にある考えを言葉にしてから選ぶのではなく、並んでいるものの中から一番マシに見えるものを拾っていました。
そして、しばらく進んだところで違和感が来ます。
「あれ、自分が思っていたのと違う」
ここが一番やっかいだったと今は思っています。違和感が来るのは選んだ直後ではなく、その選択を前提に成果物ができあがった後だからです。しかもその時点では、どこで道を間違えたのか自分でも分かりません。選んだ記憶はあるのに、選ばされた感覚はないんです。
当時は質問の方を疑いませんでした。自分の考えが足りなかったんだろう、と思っていました。
音声で喋るようになったら、選択肢を選ばなくなった
やり方を変えて、音声入力でClaudeに話しかけるようになりました。
そうしたら、AskUserQuestionとの関係がはっきり変わりました。
選択肢が出てきた瞬間に、この中に自分の言いたい答えがない、と分かるようになったんです。
キーボードの頃と何が違ったのか。打つのが面倒だから選んでいたときは、選択肢を押すコストの方が明らかに低かった。喋る方が速くなると、その差が消えます。選ぶ理由がなくなって、初めて「そもそも選びたくない」が表に出てきました。
キーボードのままの人でも、たぶん同じことは起きています。選択肢を見て一瞬止まったとか、押した後に「うーん」となったとか、あの一瞬がまさにそれです。打ち直すコストが高いので、そのまま押して進んでしまうだけだと思います。
音声にしてからは毎回こうなりました。選択肢が出る。中断する。音声で喋り直す。
毎回です。
AskUserQuestionを知っている人からすると、選択肢の最後に自由入力の欄があるじゃないか、と思うかもしれません。たしかにそこに書けば、選択肢の外の答えも渡せます。
ただ、そこに書きたいのは選択肢のどれでもない別の枠組みなので、一言では収まりません。なぜその選択肢のどれでもないのか、から説明することになって、狭い入力欄に何行も打ち込む羽目になります。それなら中断して喋った方が速い。毎回そう判断していました。
しかも、もう一つ困ることがありました。中断すると、質問のUIごと消えてしまうんです。
何を聞かれていたんだっけ、となります。仕方がないので「さっきの質問をもう一回して」と自分から頼む。聞かれた側なのに、聞き直しをこちらから依頼している状態です。
選択肢に答えがないこと。中断すると質問が消えること。この二つが毎回重なって、もやっとが溜まっていきました。
中断が起きる質問と、起きない質問がある
このもやもやを、Claudeに分析してもらいました。過去1週間分のやり取りを読み返して、何が起きているか整理してほしい、と頼んだんです。
返ってきたのは、中断していた質問としていなかった質問が、きれいに分かれているという答えでした。
中断していなかったのは、こういう質問です。
「履歴を残すファイルは、AとBのどちらを正にしますか」
中断していたのは、こういう質問。
「記事の軸を、次の3つのどれにしますか」「成果物の形式を決めるタイミングを、どこに置きますか」
前者は事実の確認で、後者は設計の判断です。
そして決定的だったのが、次の事実でした。中断したあとに自分が喋った答えは、毎回、提示された選択肢のどれでもない第三の枠組みだったんです。
「軸はどちらでもなくて、既存の内容を分析せずに更新してしまうことが主役だと思う」
「判断材料は、結論の内容そのものなんじゃないか」
一度や二度ではなく、毎回そうなっていました。
つまり中断は、選択肢が答えの範囲を覆えていないことを表しています。
キーボードの頃を思い出すと、ちょっと怖くなります。あのときも同じことは起きていたはずなのに、中断せずに選択肢の中から選んでいました。答えが選択肢の外にあるという情報は、そこで捨てられていたことになります。
線引きは「事実か、AIの仮説か」
分かれ目は、選択肢の中身が何でできているかでした。
| 選択肢の中身 | 例 | 向いている聞き方 |
|---|---|---|
| 事実として閉じている | 出力形式、日付、既知の構成、承認するか却下するか | AskUserQuestionでよい。選択肢が網羅されていて、選んだ理由を聞かれる必要もない |
| AIの仮説にすぎない | 記事の軸、設計の枠組み、判断の順序 | 文章で聞くべき。選択肢はAIが思いついた範囲でしかなく、外に答えがあることが多い |
冒頭で触れた開発での評判は、ここで説明がつくと思っています。実装の方針を選ぶ、この操作を実行していいか確認する、といった問いは上の行に寄っています。答えの候補が出そろっているので、押すだけで進めるのが速い。自分がやっているドキュメントの相談は下の行に寄っているので、同じ機能でも体験が逆になります。
やっかいなのは、この二つが同じ見た目で出てくることです。
事実の選択肢も仮説の選択肢も、画面上ではまったく同じボタンとして並びます。「これが選べる全部です」という顔をしている。でも実際には後者は、AIが数秒で思いついた案が3つ並んでいるだけで、網羅性はどこにも保証されていません。
見た目が「全部」を主張するので、こちらも「この中から選ぶものだ」と思ってしまいます。キーボードの頃に流されていたのは、たぶんこれが効いていたんだと思います。
機械的な理由もあります。文章で聞かれた質問は会話の中に残るので、中断しても読み返せます。AskUserQuestionの質問は消えます。仮説の問いほど考える時間が要るのに、考えるために中断すると質問自体が失われる、という作りになっているわけです。
「他にありますか」では、結局こっちが考えることになる
では文章で聞いてもらえば解決かというと、そう単純でもありませんでした。
文章の質問は、放っておくと開いた質問に退化します。
「他に直したいところはありますか」
これを言われると、結局こちらが論点を毎回自力で見つけて投げることになります。選択肢がない分だけ、負担はむしろ増えます。選択肢への不満が「選ばされること」だったので、その反対は「何も出さずに丸投げされること」ではないんです。
欲しかったのは、こういう形でした。
推奨が1つ示されていて、それ以外の案も並んでいて、どれも外れていたらそのまま喋ればいい、と分かっている状態。
選ぶだけでも答えられるし、選ばなくても答えられる。両方の道が開いていることが大事で、選択肢が悪かったのではなく、選択肢しか道がなかったことが問題でした。
Claudeにこう伝えれば変わる
ここまでの内容を、そのまま指示文にしました。Skillにしてもいいし、会話の途中で貼ってもいいです。
質問をするときは、次のように使い分けてください。
- 選択肢が事実として閉じているとき（出力形式、日付、既知の構成、承認か却下かなど、
選択肢が網羅されていて、選んだ理由を聞く必要がないもの）は、AskUserQuestionで聞いてください。
- 選択肢があなたの仮説にすぎないとき（軸、枠組み、設計の判断）は、AskUserQuestionを使わず、
文章で聞いてください。
- 文章で聞くときは、丸投げの開いた質問にしないでください。あなたの推奨を1つ挙げ、
対抗案も添えて、「どれでもなければそのまま話してください」と一言足してください。
- どちらの場合も、1回の質問で聞くのは1つだけにしてください。
最後の1行だけ補足しておきます。
「2点確認させてください」「3点決めさせてください」のように質問を束ねられると、会話がかなりの確率で止まります。自分の場合、まず1つだけ確認する形の質問には毎回答えられていて、束ねられた質問は半分近く中断していました。
聞き方を文章に変えても、一度に3つ聞かれたら結局止まります。手段の話と本数の話は別々に効くので、両方書いておくのがいいと思います。
この記事自体が、その最初の一本
この指示を入れたあと、最初に書いたのがこの記事です。なので答え合わせがそのまま素材になっています。
記事の軸を決める段で、ClaudeはAskUserQuestionを出しませんでした。代わりに文章で3つの案を出してきました。
- 中断は質問の設計が間違っていることを表していた、という読み替えを主役にする
- 事実の問いと仮説の問いを分ける線引きそのものを主役にする
- 目的を書いたつもりで手段まで固定してしまったルールの失敗を主役にする
推奨は1つめ、と書き添えられていました。そして最後に「どれでもなければ、そのまま話してください」とありました。
自分が返したのは、3つのどれでもありませんでした。
便利だと評判なのに自分は毎回中断していた、というズレから入りたい。キーボードの頃は流されて選んでいて、音声にしたら中断という形で表に出た。そこを書きたい。
今読んでいるこの記事の冒頭が、まさにそれです。3択のままだったら、たぶん1つめを選んでいました。それでも記事は1本できたと思いますが、書き出しは違うものになっていたはずです。
構成を詰める段でも同じことが続きました。この見出しは意味が分からない、前の章と言っていることが食い違う、この章は書き手側の都合になっていて読者目線じゃない。どれも選択肢では返せない種類の指摘で、そのたびに見出しが差し替わっています。
効果は「質問が読みやすくなった」では止まりませんでした。成果物の中身そのものが変わりました。
まとめ
- 選択肢にもやっとするのは、答えが選択肢の外にあるサイン
- キーボードで打っていると気づかずに選んでしまい、後から「思っていたのと違う」になる
- 音声で喋るようになると、中断という形で表に出る
- 事実として閉じている問いはAskUserQuestionでいい。軸や設計のような仮説の問いは文章で聞いてもらう
- 文章で聞いてもらうときは、推奨と対抗案までセットで頼む。開いた質問は丸投げと変わらない
AIの質問に選択肢が並んでいると、答えはこの中にあるものだと思ってしまいます。でも実際には、その選択肢はAIが数秒で思いついた仮説にすぎないことがあります。
もし選択肢が出てもやっとしたら、選ぶ前に一度止まってみてください。そして、その違和感をそのまま言葉にしてClaudeに投げてみてください。自分の場合は、そこから記事が1本出てきました。