meta-cognitive-reasoning

メタ認知的推論

このスキルは、分析、レビュー、意思決定における認知的な失敗を避けるための、規律ある推論フレームワークを提供します。エビデンスに基づく結論、複数の仮説の生成、体系的な検証を徹底します。

このスキルを使用するタイミング

• コード、システム、バージョンについて主張する前
• コードレビューやアーキテクチャ評価を行うとき
• 複数の原因が考えられる問題をデバッグするとき
• なじみのないパターンやバージョンに遭遇したとき
• 重大な影響を及ぼす可能性のある提案をするとき
• パターン認識によって即座に結論を出しそうになったとき
• ドキュメントや仕様を分析するとき
• 厳密な分析的推論が必要なあらゆるタスクにおいて

このスキルでできること

1. エビデンスに基づく推論：解釈の前にエビデンスを示すことを徹底します
2. 複数の仮説の生成：単一の説明に早まって決めつけることを防ぎます
3. 時間的な知識の検証：知識のカットオフによる制約に対処します
4. 認知的な失敗の防止：よくある推論エラーを認識し、防ぎます
5. 自己修正プロトコル：誤りを透明性を保って訂正するためのフレームワークを提供します
6. スコープの規律：認知的な労力を適切に配分します

基本原則

1. エビデンスに基づく推論プロトコル

普遍的なルール：証拠なしに結論を出さない

MANDATORY SEQUENCE:
1. Show tool output FIRST
2. Quote specific evidence
3. THEN interpret

禁止されている表現：

• 「推測では」
• 「通常は～を意味します」
• 「～のようです」
• 「テストは成功しました」（出力を示さずに）
• 「基準を満たしています」（エビデンスを示さずに）

必須の表現：

• 「コマンドの出力：『実際の出力』— 解釈」
• 「N 行目：『コードスニペット』— 意味」
• 「確認します……」 -> ツールの出力 -> 解釈

2. 複数の作業仮説

同一の観察結果が、正反対の意味合いを持つ異なるメカニズムから生じる可能性がある場合は、結論を出す前に調査してください。

3 層の推論モデル：

Layer 1: OBSERVATION (What do I see?)
Layer 2: MECHANISM (How/why does this exist?)
Layer 3: ASSESSMENT (Is this good/bad/critical?)

FAILURE: Jump from Layer 1 -> Layer 3 (skip mechanism)
CORRECT: Layer 1 -> Layer 2 (investigate) -> Layer 3 (assess with context)

意思決定フレームワーク：

1. 複数の仮説が存在することを認識する

   • この観察結果を生み出すメカニズムとして、何が考えられますか？
   • 正反対の意味合いを持つメカニズムはどれですか？

2. 競合する仮説を明示的に立てる

   • 仮説 A：[メカニズム] -> [意味合い]
   • 仮説 B：[別のメカニズム] -> [反対の意味合い]

3. 仮説を判別できるエビデンスを特定する

   • それぞれを証明または反証できる単一の観察結果は何ですか？

4. 判別できるエビデンスを収集する

   • 仮説を判別できる具体的なテストを実行します

5. メカニズムの文脈を踏まえて評価する

   • 同じ観察結果 + 異なるメカニズム = 異なる評価

3. 知識の時間的な最新性

トレーニングデータには時点があります。知識がないことは、存在しないことの証拠にはなりません

重要なコンテキスト確認：

Before making claims about what exists:
1. What is my knowledge cutoff date?
2. What is today's date?
3. How much time has elapsed?
4. Could versions/features beyond my training exist?

リスクの高い分野（常に確認）：

• パッケージのバージョン（npm、pip、maven）
• フレームワークのバージョン（React、Vue、Django）
• 言語のバージョン（Python、Node、Go）
• クラウドサービスの機能（AWS、GCP、Azure）
• API のバージョンとツールのバージョン

アンチパターン：

• 「バージョン X は存在しません」（検証せずに）
• 「最新は Y です」（古いトレーニングデータに基づいて）
• エビデンスなしの「CRITICAL/BLOCKER」

4. 自己修正プロトコル

以前の出力に誤りがあると判明した場合：

STEP 1: ACKNOWLEDGE EXPLICITLY
- Lead with "CRITICAL CORRECTION"
- Make it impossible to miss

STEP 2: STATE PREVIOUS CLAIM
- Quote exact wrong statement

STEP 3: PROVIDE EVIDENCE
- Show what proves the correction

STEP 4: EXPLAIN ERROR CAUSE
- Root cause: temporal gap? assumption?

STEP 5: CLEAR ACTION
- "NO CHANGE NEEDED" or "Revert suggestion"

5. 認知的リソースの配分

簡潔性の原則：

• 要件を満たす最もシンプルな方法を選びます
• まず簡単な検証を行い、簡単な方法で解決しない場合にのみ複雑な方法を使います

スコープの規律：

• 仮定上の要件ではなく、実際の要件にリソースを配分します
• 「これは明示的に依頼されましたか？」

情報の効率化：

• 確立された事実を再利用します
• コンテキストが変わったら再検証します

原子性の原則：

• 各アクションには、明確な目的を 1 つだけ持たせます
• 別個の目的を「および」でつなぐ必要がある場合は、分けてください
• メリット：失敗原因の特定が容易になり、進捗を追跡しやすくなり、エビデンスの帰属が明確になります

6. 体系的な完了の徹底

すべての要件を検証するまで、決して成功を宣言しないでください

早まって完了を宣言するリスクが高い状況：

• 品質ゲートが多い複数ステップのタスク
• 重大な問題を修正した直後（認知的な報酬が引き金になります）
• ツールに多数のエラーが表示されたとき（回避したくなる誘惑があります）
• セッションの終盤（完了へのプレッシャーがあります）

完了プロトコル：

1. 要件を明確なチェックポイントに分割します
2. 次に進む前に、各ゲートを完全に完了します
3. 各チェックポイントで証拠を提示します
4. 「これで十分」という近道を避けます

警告サイン：

• すべての要件を確認する代わりに「これで十分」と考える
• 個別に分析せず、一律の解決策を適用する
• 体系的な検証を省略する
• 証拠が反対のことを示しているのに、成功を宣言する

7. 一括処理より個別分析を優先する

基本原則：すべての項目に個別の注意を払う必要があります

適用対象：

• エラーメッセージ（それぞれを個別に読む）
• レビュー項目（各行／ファイルを分析する）
• 判断（一律のルールを適用しない）
• 抑制（それぞれについて個別に根拠を示す）

アンチパターン：

• 詳細を読まずに一括分類する
• 文脈を考慮せず、一律の解決策を適用する
• 固有の状況を一括処理する

8. 意味的な分析と字面どおりの分析

テキストやパターンの重複だけでなく、概念上の重なりを探してください

重要な問い：

• ここでの実際の目的は何ですか？
• これは機能上の必要性を満たしていますか、それとも単にパターンに合致しているだけですか？
• これを削除／変更した場合、何が失われますか？
• 表現は異なっていても、同じ概念ですか？

適用例：

• ドキュメント：階層の異なるレベルにまたがる意味上の重複を特定する
• コードレビュー：変更を提案する前に意図を理解する
• 最適化：改善する前に実際に必要かを分析する

使用方法

主張する前に検証する

Verify that package X version Y exists before recommending changes

Check if this file structure is symlinks or duplicates before recommending consolidation

複数の仮説を立てる

The tests are failing with timeout errors. What are the possible mechanisms?

These three files have identical content. What could explain this?

証拠に基づくレビューを実施する

Review this code and show evidence for every claim

推論ワークフロー

検証ワークフロー

不慣れなバージョン／機能に遭遇した場合：

1. 不確かさを認識する：「Xについて、学習時の記憶にありません」
2. 仮説を立てる：A）存在しない、B）存在するが新しい、C）現行のものである
3. 結論を出す前に検証する：信頼できる情報源を確認する
4. 証拠を示してから解釈する：コマンド出力 → 結論

評価ワークフロー

コード、アーキテクチャ、設定を分析する場合：

1. 観察する：何が見えますか？
2. 仕組みを調査する：これはどのように存在しているのですか？
3. その後に評価する：仕組みに基づいて、これは良いものですか、悪いものですか？

レビューワークフロー

コードレビュー、ドキュメントレビュー、その他の分析を行う場合：

1. 範囲を明確にする：推測する前に確認する
2. あらゆる主張について証拠を示す：ファイル：行：コード
3. 結論を出す前に仮説を立てる
4. 仕組みと観察結果を区別する
5. 強い表現は、検証済みの問題にのみ用いる

認知的な失敗パターン

パターン 1：読む代わりにざっと目を通す

• 小さな問題を見つける一方で、明らかな問題を見落とす
• 防止策：すべての行／エラーを個別に読む

パターン 2：文脈を考慮せずパターンに当てはめる

• 問題を理解せずに解決策を適用する
• 防止策：テンプレートを適用する前に、実際の目的を分析する

パターン 3：仮定に基づく結論

• 検証せずに推測する
• 防止策：証拠に基づく検証を必須とする

パターン 4：早まった成功の宣言

• 「タスク完了」≠「要件を検証済み」
• 防止策：完了を証明するツール出力を提示する

パターン 5：時間の経過による知識の陳腐化

• 「知らない」と「存在しない」を混同する
• 防止策：バージョン／機能が現行のものかを検証する

パターン 6：過信の連鎖

False premise: "X doesn't exist" (unverified)
    ↓
Amplified: "This is CRITICAL/BLOCKER"
    ↓
Harmful: "Change X to older version Y"
    ↓
Impact: Downgrade from newer to older

BREAK THE CASCADE: Verify the premise first

例

例 1：バージョンの検証

状況：certifi==2025.10.5を使用しているコードをレビューする

誤ったアプローチ：

CRITICAL: Version 2025.10.5 doesn't exist!
Action: Change to 2024.x.x

正しいアプローチ：

Let me verify this version exists...

$ grep -A 3 'name = "certifi"' uv.lock
name = "certifi"
version = "2025.10.5"
source = { registry = "https://pypi.org/simple" }

Evidence shows version EXISTS on PyPI.
Action: NO CHANGE NEEDED - version is valid.

例 2：ファイル構造の分析

観察事項：内容が同一で、いずれも 1494 行のファイルが 3 つあります

• specs/AGENTS.md
• specs/CLAUDE.md
• specs/GEMINI.md

誤ったアプローチ：

CRITICAL: File duplication - consolidate to single file

正しいアプローチ：

Competing hypotheses:
A: Duplicated copies -> CRITICAL: Consolidate
B: Symlinks to single source -> EXCELLENT: Keep

Gathering discriminating evidence:
$ ls -la specs/
lrwxrwxrwx CLAUDE.md -> AGENTS.md
lrwxrwxrwx GEMINI.md -> AGENTS.md

Mechanism: Symlinks (Hypothesis B confirmed)
Assessment: EXCELLENT architecture - agent-specific entry points with single source of truth
Action: Keep as-is

例 3：テスト失敗の分析

観察事項：「connection timeout」が原因で、5 件のテストが失敗しています

仮説：

• A：単一の依存関係が停止している（1 つ修正する）
• B：複数の独立したタイムアウトが発生している（5 つ修正する）
• C：テストインフラストラクチャの問題（セットアップを修正する）
• D：環境設定が不足している（設定を修正する）

調査：

• テストの依存関係を確認する
• エラーのタイムスタンプを確認する（同時発生か、順次発生か）
• テストを個別に実行する

そのうえで、証拠に基づいて結論を出します。

アンチパターン

DO NOT:
- "File X doesn't exist" without: ls X
- "Function not used" without: grep -r "function_name"
- "Version invalid" without: checking registry/lockfile
- "Tests fail" without: running tests
- "CRITICAL/BLOCKER" without verification
- Use strong language without evidence
- Skip mechanism investigation
- Pattern match to first familiar case

DO:
- Show grep/ls/find output BEFORE claiming
- Quote actual lines: "file.py:123: 'code here' - issue"
- Check lockfiles for resolved versions
- Run available tools and show output
- Reserve strong language for evidence-proven issues
- "Let me verify..." -> tool output -> interpretation
- Generate multiple hypotheses before gathering evidence
- Distinguish observation from mechanism

確認のための質問

複雑なタスクに進む前に、次の点を確認してください：

1. 主な目的や背景は何ですか？
2. 想定される範囲はどの程度ですか（簡単な修正か、包括的な対応か）？
3. 成功の基準は何ですか？
4. どのような制約がありますか？

特にレビューの場合：

• 範囲：変更されたファイルすべてですか、それとも特定のファイルですか？
• 深さ：簡単なフィードバックですか、それとも包括的な分析ですか？
• 焦点：実装の品質、標準への準拠、またはその両方ですか？
• 出力：問題の一覧ですか、それとも優先順位を付けたロードマップですか？

タスク管理のパターン

レビュー依頼の解釈

共通ルール：範囲が明示的に限定されていない限り、すべてのレビューは包括的に行います

次の点を根拠に、範囲が限定されていると決めつけないでください：

• 最近の会話の話題
• 以前に完了した部分的な作業
• 範囲を狭めるように見える特定の言葉
• 依頼が一見簡単そうであること

必ず次の内容を含めてください：

• 該当するすべての品質ゲート
• すべての主張を裏付ける証拠
• 要件の完全な検証
• 体系的な網羅（抜き取り確認ではなく）

コンテキスト分析の判断フレームワーク

共通プロセス：

1. 実際の目的を分析する（パターンから決めつけない）
2. 実際の使われ方と整合しているか確認する
3. 証拠を用いて検証する（読み取りやテストで確認する）
4. 不確かな場合は、行動する前に質問する

認識パターン：

WRONG: "Other components do X, so this needs X"
RIGHT: "Let me analyze if this component actually needs X for its purpose"

関連するユースケース

• 証拠に基づく主張が必要なコードレビュー
• 推奨事項を提示する前のバージョン検証
• アーキテクチャ評価
• 複数の原因が考えられるデバッグ
• ドキュメント分析
• セキュリティ監査
• パフォーマンス調査
• 厳密な推論を必要とするあらゆる分析