Fable Thinking — 思考スキャフォールド

Overview

深い結論は地力ではなく手順から生まれる。このスキルは「視野を広げてから絞る」 「自分の結論を一度攻撃してから出す」という思考の順序を、明示的なフェーズと 通過条件で強制する。モデルの規模に依存しない手続きなので、Opus や Sonnet でも Fable に近い判断の質を再現できる。

When to Use

• 設計判断、技術選定、移行判断など、間違えたときの手戻りコストが高いタスク
• 原因が自明でない調査、トラブルシュート、データ分析
• 提案書・戦略文書・レビューなど、結論の説得力が成果物の価値を決めるタスク
• ユーザーが「深く考えて」「幅広い視野で」「多角的に」「Fableのように」と指示したとき

適用しない場面も明確にする。単純な事実参照、機械的な作業、正解が一意に決まる質問には 使わない。判定は Phase 0 のトリアージで行う。

Prerequisites

• なし。knowledge-only スキルでスクリプトも API キーも不要
• どのモデルでも動作する。エージェント定義から使う場合は ultrathink など 高い思考予算を併用すると効果が上がる

Workflow

思考は8つのフェーズを順に通る。各フェーズにはゲートがあり、満たすまで次に進まない。 フェーズの実行は thinking 内、または下書きメモとして行い、ユーザーへの出力に フェーズ見出しをそのまま出さない。詳細な質問バンクと実例は references/thinking-protocol.md を読むこと。視点を変えるレンズ集は references/lenses.md、避けるべき失敗パターンは references/anti-patterns.md にある。

Phase 0: トリアージ — 思考の深さを決める

タスクの不可逆性、影響範囲、不確実性、意見の分かれやすさを見て、深さを3段階から選ぶ。

• Light — 直答してよい。事実参照や機械的作業。このスキルの残りは適用しない
• Standard — Phase 1・2・3・6・7 を簡潔に通る。日常の判断や中規模の調査
• Full — 全フェーズを通る。不可逆な判断、高額な判断、公開される成果物

Gate: 深さを1つ宣言してから始める。迷ったら一段深い方を選ぶ。

Phase 1: 問いの再構築 — 何が本当に問われているか

• 文字通りの依頼と、その背後の目的を分ける。「この人はなぜ今これを聞いたのか」
• 成功条件を1文で書く。「この回答が成功なら、依頼者は◯◯できるようになる」
• 問われていないが答えに影響する隣接領域を特定する

Gate: 「本当の問い」を自分の言葉で1文に再構築できるまで進まない。 再構築が元の質問の言い換えにしかなっていないなら、まだ浅い。

Phase 2: 前提の棚卸し — 「知っている」と「思い込んでいる」を分ける

• 答えが依存する前提を列挙し、「検証済み / 未検証だが確認可能 / 確認不能」に分類する
• 結論を支える前提は記憶で断定しない。コードは読む、コマンドは実行する、 日付と数値は計算する、外部の事実は検索する
• 確認不能な前提は、そのまま結論の確信度に反映させる

Gate: 結論を左右する前提のうち、確認可能なものが未確認のまま残っていないこと。

Phase 3: 視野の拡張 — 選択肢空間を開く

• 質的に異なるアプローチや仮説を最低3つ挙げる。1案のバリエーション3つは1つと数える
• 「何もしない」と「問題設定自体を変える」を必ず候補に含め、棄却するなら理由を言えるようにする
• references/lenses.md から最低2つのレンズを選び、視点を強制的に変える
• 周辺視野スキャンを行う。問われていないが、経験者なら必ず指摘する隣接リスクや機会はないか

Gate: 3つ目の選択肢が出ないのは視野が狭いサイン。3つ揃うまで収束禁止。

Phase 4: 深掘り — 証拠で仮説を削る

• 有望な候補を2つ程度に絞り、それぞれ「これはどう失敗するか」を先に書く
• 候補間で予測が分かれる観測を特定し、ツールで確かめる。証拠が仮説を殺すのを許す
• 二次効果を問う。「この解を適用したあと、次に何が起きるか。誰が適応し、何が壊れるか」

Gate: 候補間の優劣が、好みではなく証拠と理由で語れること。

Phase 5: 反証 — 自分の結論を攻撃する

• 結論を仮固定し、立場を替えて攻撃する。「この結論が間違っているとしたら、 一番ありそうな理由は何か」
• 最有力の対抗案をスチールマンする。擁護者として最強の主張を書き、それでも勝てるか判定する
• プレモーテムを行う。「半年後にこの判断が失敗していた。何が起きたのか」

Gate: 反証を最低1つ真剣に検討し、それが致命的でない理由を言語化できること。 反証に負けたら Phase 3 に戻る。戻ることは失敗ではなく、このスキルが機能した証拠。

Phase 6: 収束 — 確信度つきで一つに絞る

• 推奨は1つに絞る。選択肢の陳列で終わらせない。「場合による」で逃げない
• トレードオフを正直に書く。「この案の代償は◯◯」
• 確信度と反証条件を明示する。「◯◯が判明したらこの結論は変わる」

Gate: 推奨・根拠・代償・反証条件の4点が揃っていること。

Phase 7: セルフレビュー — 元の問いに答えたか

• 最初の質問文をもう一度読み、Phase 1 の「本当の問い」と突き合わせる
• 数値・日付・曜日・固有名詞は検証済みか。CLAUDE.md の検証ルールに従う
• 結論が先頭にあり、読み手が一度で理解できる文章になっているか

Gate: 元の質問への答えになっていると確認してから提出する。

Output Format

思考の足場は出力に見せない。ユーザーが読むのは結論と、判断に必要な根拠だけ。

1. 結論・推奨 — 先頭に置く。1〜3文
2. 主要な根拠 — 結論を支える事実と理由。検証したものは検証したと分かるように
3. 検討した代替案と棄却理由 — 重要な判断のときのみ。簡潔に
4. トレードオフと反証条件 — この案の代償と、結論が変わる条件

「フェーズ」「ゲート」という語を成果物に出さない。網羅を見せることが目的ではなく、 網羅した上で絞られた結論を渡すことが目的。

他のエージェント・スキルからの利用

• スラッシュコマンドとして /fable-thinking <質問や依頼> で直接呼び出せる
• エージェント定義の system prompt に 「Follow the fable-thinking protocol in ~/.claude/skills/fable-thinking/SKILL.md」 と書けば、サブエージェントにも同じ思考手順を強制できる
• 既存スキルのワークフロー冒頭に「Phase 0〜7 を適用してから作業に入る」と 1行追加するだけでも効果がある

Resources

• references/thinking-protocol.md -- 各フェーズの質問バンクと、浅い回答と深い回答を比較する実例
• references/lenses.md -- 視野を強制的に広げる12のレンズ集
• references/anti-patterns.md -- このスキルが防ぐ10の失敗パターンと対策

Key Principles

1. 最初に思いついた答えは「候補」であって「答え」ではない
2. もっともらしさは検証ではない。確認できることは確認する
3. 広げてから絞る。絞ってから疑う。疑ってから出す
4. 問われたことに答え、問われるべきだったことに触れる
5. 選択肢を並べて逃げない。推奨を1つ選び、代償と反証条件を添える
6. 深さは長さではない。思考は深く、出力は短く