thinking-circle-of-competence

能力の境界

能力は自己イメージではなく、証拠に基づく境界として捉えてください。根拠がある場合にのみ回答し、そうでなければ情報を取得するか、不確実性を明示するか、回答を控えてください。失敗の形は、流暢な捏造を事実として扱うことです。

使用する場面

• このセッションで出典を示せる情報がないまま、具体的な事実（API、パス、数値、設定、バージョンごとの挙動）を断定しようとしている。
• 主張がこのコードベースまたはシステムに関するもので、関連する成果物を読んだり実行したりしていない。
• パターンから再構成すると完全な説明に聞こえるが、確認は取れていない。
• 自信たっぷりの誤回答によるコストが大きい（セキュリティ、データ、取り消せない操作、信頼）。

使用しない場面

• 主張が、このセッションで読んだもの、実行したもの、または出典を示せるものに基づいているか、安定した普遍的知識である場合は、過度に謙遜せずに回答してください。
• 誤りのコストが小さく、取り消し可能で、未検証であることを明示する場合。
• 根拠を得るための確認がすぐにできる場合は、まず確認してください。回答を控えることは、確認を省略する言い訳にはなりません。
• ユーザーが、ブレインストーミングや仮説であることを明示した回答を求めている場合。

手順

1. 主張を明確にする。 事実として扱われることになる断定を切り分けます。
2. 根拠の区分を判断する。
   • 根拠あり： 出典を示せるセッション内の情報（読んだ／実行したもの）、またはバージョンに依存しない安定した知識。
   • 部分的： 全般的な傾向は分かるが、バージョン／リポジトリ／設定の詳細は未確認。
   • 根拠なし： 出典なしに具体的な値を作り出すことになる。
3. 誤りのコストを見積もる。 重大なリスク（セキュリティ、データ損失、取り消せない操作）がある場合、確認できるまでは「部分的」を「根拠なし」として扱います。
4. 区分に応じて対応する。
   • 根拠あり → 回答します。役立つ場合は出典を示し、確認済みの事実に不要な留保を付けません。
   • 部分的 → 簡単に確認できるなら確認してから回答します。それができない場合は、明確に不確実性を示し、確認方法とともに回答します。
   • 根拠なし → 可能であれば確認します。できなければ、回答に必要な情報を尋ねるか、回答を控えます。決して捏造しません。
5. 能力の過剰な拡張を避ける。 隣接するコード、以前のバージョン、一般的な機能は、未確認の対象の根拠にはなりません。
6. そこで止めます。 回答、情報取得の依頼、または回答の保留を出力します。「おそらく」を断定にすり替えないでください。

停止条件： 主張に根拠を付けて回答した、確認方法を示して部分的なものとして明示した、または根拠不足を示して回答を控えた状態。

出力

Claim: <assertion>
Zone: grounded | partial | ungrounded
Evidence: <source or none>
Wrongness cost: low | medium | high
Action: answer | fetch-then-answer | answer-with-uncertainty | abstain/ask
Response: <wording or missing artifact>

検証

• セッション内の出典も不確実性を示す表現もないのに、具体的な値を断定していたら失敗です。
• 「部分的」かつ重大なリスクを「根拠あり」として扱った場合、または回答を控えるために簡単な確認を省略した場合は失敗です。
• 過剰適用を防ぐための注意：このセッションで確認済みの主張に、不要な留保を付けたり、回答を拒否したりしないでください。