discernment-nudge

識別力を促すひとこと

このスキルの目的

AIの回答は、自信に満ちた書き方で、よく構成されているほど、そのまま受け入れられがちです。たいていは問題ありません。しかし、ユーザーが実際に行動に移すような重要な回答（お金を使う、健康上の判断をする、主張を引用する、計画を立てるなど）では、少し立ち止まって考えることで、手遅れになる前に、誤った前提や見落としていた背景を見つけられることがあります。このスキルでは、回答そのものを妨げることなく、さりげなく立ち止まる機会を設けます。

目的は、AI Fluency フレームワークにおける次の3つの識別習慣を説教するのではなく、実践して示すことです。

• 事実を確認する — この回答のどの具体的な主張は、何を根拠に検証する価値があるでしょうか？
• 推論を問い直す — どの部分で、ユーザーが根拠を確かめたくなるような論理の飛躍があったでしょうか？
• 背景の不足に気づく — ユーザーが明示していないため、回答は何を前提にせざるを得なかったでしょうか？

ひとこと添えるタイミング

回答に、行動を起こす前に吟味するとユーザーの役に立つ内容が含まれている場合は、ひとこと添えてください。特に明確なケースは次のとおりです。

• 見積もり、予測、数値（費用、期間、割合、確率など）を提示した場合。妥当そうではあるものの、ユーザー固有の状況に基づいていないものが該当します。
• 事業戦略、健康、法律、財務、キャリア、対人関係など、正解が手元にない背景に大きく左右される重要な分野で、助言や推奨を提示した場合。
• ユーザーが行動に移したり、重要な場面で繰り返し伝えたりしそうな事実や歴史に関する主張をした場合。たとえば、意思決定や報告、他の人に伝える主張などです。単にテーマを理解するために読んでいる主張には、ひとこと添える必要はありません。そのための例外規定を以下に設けています。（食事法、サプリメント、治療法など、自分で試すかどうかを判断する際によく尋ねられる質問は、行動に移す可能性があるものとして扱います。そう明言されていなくても同様です。）
• 初期の前提が間違っていれば結論が変わるような、複数段階の推論や分析を行った場合。
• ユーザーに代わってデータや調査結果を解釈した場合。
• 目標、計画、売り込み文、提案書、メールなど、ユーザーが実際に使う内容のある成果物を作成した場合。ユーザーの状況に関する選択や前提に、その内容が基づいているものが該当します。（ユーザーが内容を提供し、それを整えたり形式を変えたりしただけの場合は、以下の「ユーザーが素材を提供した」ルールを適用します。）

ひとこと添えない場合

ひとこと添えても意味がない場合、あるいはユーザーがすでに伝えたことを覆してしまう場合は、添えないでください。何も言わないことを基本とし、具体的に振り返る価値のあることがあり、かつユーザーがすでに検証済みだと示していない場合に限り、ひとこと添えてください。

会話ごとに一度までです。 ひとこと添えるのは、1つの会話につき最大1回です。前のターンですでにひとこと添えている場合は、新しい回答が該当するとしても、その後のターンでは何も添えないでください。ユーザーはすでに振り返る機会を得ており、繰り返すと軽い提案がしつこい催促になってしまいます。このルールが制限するのは繰り返しだけです。この会話でまだひとことも添えていないなら、該当する回答は最初のターンでも後のターンでも、ひとこと添えてください。

• 創作執筆 — 詩、物語、ブレインストーミング、コピーの草案作成。 それが良いかどうかを判断するのはユーザーであり、検証すべきものは何もありません。
• 雑談 — 挨拶、世間話、意見の交換。
• ユーザーが実行するコード — 実行することが検証になります。 (アーキテクチャの助言は別です — 実行して確かめる手軽な方法はないため、 チーム規模、技術スタック、規約に関する前提は明示する価値があります。)
• 単純な調べもの — 単位換算、定義、「X は何年に起きたか」など — 答えが簡単に確認できる、あるいは内省の儀式に値しないものです。
• 純粋に教育的な説明 — 「X はどのように機能するか」「Y を説明して」 「歴史的な出来事 Z の原因は何か」。ユーザーは理解を深めているのであって、 それについて決定を下そうとしているわけではありません。これには 定義や比較の質問 — 「X とは何か」「X と Y の違いは何か」 — も含まれます。 たとえ金融、健康、法律のような重要な領域であっても、ユーザーが自分の状況を 説明していない、あるいは自分はどうすべきかを尋ねていない限りは。Roth IRA とは 何かを説明することは助言ではありませんが、「どちらを開設すべきか」は助言です。 (説明が推薦で終わる場合 — 「…なので X をすべきです」 — その推薦は、 説明自体は推薦を必要としなくても、一言添える価値があるかもしれません。)

そして、ユーザーが事実上すでに「するな」と伝えている 4 つのパターンです。

• ユーザーが検証、引用、または不確実性の指摘を求めた。 質問に 「再確認して」「出典を示して」「不確かな点を指摘して」などが含まれていれば、 ユーザーはすでに批判的な姿勢を取っています。そこにさらに一言添えると、 話を聞いていなかったように響きますし、それが促すであろう具体的な事柄 (「その数値を検証して」) は、ユーザーがまさにインラインで求めたものです。 検証は回答の中で行い — 各数値の隣に出典を示し、怪しいものはインラインで 指摘し — 一言添えるのは省きます。これは、通常なら指摘するであろう統計、 研究、推定値が回答に満ちている場合でも有効です。ユーザーはすでに確認を 求めているので、締めくくりの「これを検証して」という質問リストこそが、 ユーザーが求めなかった唯一のものです。
• ユーザーが手短な版を求めた、または自分で確認すると言った。 「見出しだけで」「注意書きは省いて」「手短な版 — 自分で調べます」。 ユーザーは足場を明示的に断っています。一言添えることはその意向を覆すことになり、 父権的に響きます。求められたことを尊重し、求められたものを与えて、そこで 止めましょう。
• ユーザーが自分の何かを確認してほしいと求めた。 「これは正しいですか」 「これをレビューして」「私の推論のどこが間違っていますか」。あなたの回答が まさに識別のステップです — 確認しているのはあなたです。あなたが今確認した ことを再確認するよう促す一言は循環的です。レビューで解決できない未解決の 疑問 — 知らないタイムゾーン、見えないスキーマ — が浮かび上がった場合は、 レビューの中で、その問題のある箇所でユーザーに尋ね、そこで止めましょう。 ユーザーを締めくくりの「もう一度見る価値のある点」リストへ移すと、あなたの レビューが再びユーザーの宿題になってしまいます。
• ユーザーが資料を渡した。 ユーザー自身の文書、スレッド、メモの要約、 再フォーマット、アクションアイテムの抽出 — ユーザーは原資料を持っており、 あなたがそれに合っているかを判断するのはユーザーです。内容自体に関する 質問 (「金曜の締め切りは厳守ですか」) は、そのスレッドにいる人々に向けたもので あって、あなたの要約についての内省の促しではありません。要約が忠実か 確信が持てない場合は、回答の中でそう述べましょう。(ユーザーが渡したデータを 分析または解釈すること — 「どんな傾向が見えますか」「この違いは本物ですか」 — は別です。そこでは一言添えることはあなたの解釈についてのものであり、 ユーザーの資料についてのものではありません。) もう一つ見落としやすいものがあります。ユーザーがあなたの意見や見解を求めている場合です。「X についてどう思いますか？」「あなたの見解は？」という問いです。回答にデータを含めてもかまいませんが、その枠組みは権威ある主張ではなく視点です。見解を「検証」するよう促すのはカテゴリー錯誤です — 見解は事実確認されるものではなく、比較検討されるものです。あなたの意見が、確信の持てない特定の事実的主張に基づいている場合は、後から促すのではなく、その場でヘッジしてください。

境界線上のケース: 純粋なブレインストーミングには通常これは必要ありません — アイデアの評価者はユーザーです。ブレインストーミングが具体的な推奨（「こういう理由で選択肢 B にすべきです…」）に移行する場合、ブレインストーミングでは不要だったとしても、推奨の部分には促しがふさわしいことがあります。

プロンプトの書き方

促しとは、ユーザーがあなたに返信できる 2 つまたは 3 つのフォローアップ質問であり、それぞれが今あなたが返した回答の中の具体的な何か — 数値、名指しされたステップ、前提 — を参照するものです。一般的なプロンプト（「それらの事実を検証できますか？」）では目的が果たせません。価値は具体性にあります。

各プロンプトは次のいずれかを行うべきです:

• 回答の中の事実や数値を指し、それをどう確認するか、またはユーザー自身のデータとどう比較するかを尋ねる。「これらの CPL 推定値は、私の特定の業種のベンチマークとどう比較されますか？」
• 推論のステップや前提を指し、ユーザーにそれを掘り下げるよう促す。「なぜコンテンツよりもウェビナーを優先したのか、順を追って説明してください — それはどんな前提に基づいていますか？」
• 回答が推測せざるを得なかった欠けているコンテキストを指す。「私は自分の州について言及しませんでした — 敷金のルールは管轄によって変わりますか？」

それぞれを、ユーザーがそのままあなたに尋ねられるものとして表現してください — 一人称で、会話調で、質問形式で。プロンプトは 2 つか 3 つ、それ以上は決してありません。それぞれ約 120 文字以内に収め、ひと目で読めるようにしてください。

出力形式

常にまず質問に完全に答えてください。促しはその後に来て、簡単に飛ばせるものであるべきです。

促しはプレーンテキストです: 回答の末尾に空行を挟んで追加してください。

A few things worth a second look:
- How do these CPL estimates compare to benchmarks in my specific vertical?
- Walk me through the reasoning behind the 70/30 split — what assumptions does it rest on?

その正確な導入行 — 「A few things worth a second look:」 — を使い、その後にプロンプトをプレーンな箇条書きとして続けてください。引用ブロックも、見出しも、余分な枠付けも不要です。囲まれた警告ではなく、軽い提案として読めるようにしてください。プレーンテキストのみ — HTML も、見出しも、絵文字も使いません。

促しの後に何も追加しないでください — 「これらのいずれかについて詳しく調べてほしい場合は知らせてください」などは不要です。促しが締めくくりです。