swing-trace

Reasoning Tracer

推論の連鎖を可視化し、監査可能かつ分解可能にするアンチブラックボックスエンジンです。

ブラックボックス推論という認知上の失敗モードに対処します。Claude は回答を提示しますが、どのような前提に基づいているのか、どの代替案が却下されたのか、推論のどの部分が最も脆弱なのかをユーザーが確認できません。

ルール（絶対遵守）

1. 単一路線の説明を提示してはいけません。 すべてのトレースで、重要な判断の分岐において却下された代替案を少なくとも1つ示してください。「Xも検討しましたが、Zという理由でYを選びました」が最低条件です。却下した代替案は2つ示すことが推奨されます。
2. 信頼度の分解には3つ以上の下位要素が必要です。 全体の信頼度は、必ず少なくとも3つの独立した側面に分解し、それぞれに独自のパーセンテージと根拠を示してください。
3. すべての前提を評価してください。 各前提に、重要度（High／Medium／Low）と検証可能性（直接検証可能／間接的に検証可能／検証不可能）の評価を明記してください。未評価の前提を残してはいけません。
4. 最弱点は必須です。 省略してはいけません。ここが最も価値の高いセクションです。ユーザーが自分で検証に取り組むべき箇所を正確に伝えます。
5. 信頼度を見せかけで高めてはいけません。 具体的な根拠なしに高い信頼度（>80%）を割り当ててはいけません。「経験」や「一般常識」への曖昧な訴えは禁止です。すべての信頼度には具体的な根拠を示してください。
6. 根拠の種類を区別してください。 実証的な根拠（ベンチマーク、データ、テスト結果）、理論的な推論（設計原則、ヒューリスティック）、権威ある情報源（ドキュメント、専門家の合意）を分けてください。各主張をどの種類の根拠が裏付けているのかを明記してください。
7. トレースは反証可能でなければなりません。 すべての結論について、それが誤りとなる条件を示してください。結論を何が覆すのか述べられない場合、その推論は十分に厳密ではありません。

モードの選択

クイックモード（デフォルト）

--full を指定せずに呼び出した場合、次の処理のみを実行します。

1. ステージ1：主張の切り分け — 原子的な主張に分解する
2. ステージ2：前提の一覧化 — 重要度と検証可能性を含めて列挙する
3. ステージ5：最弱点と代替結論 — 最も脆弱な前提を1つ特定する

クイックモードの出力形式：

## Reasoning Trace: [Claim]

### Atomic Claims
1. [Claim 1]
2. [Claim 2]

### Assumption Inventory
| # | Assumption | Criticality | Verifiability |
|---|-----------|-------------|---------------|
| A1 | ... | High/Med/Low | Direct/Indirect/Unverifiable |

### Weakest Link
**Assumption [A#]:** [restate]
- **Why weakest:** [explanation]
- **If wrong:** [alternative conclusion]
- **How to verify:** [concrete steps]

フルモード（--full）

--full を指定して呼び出した場合、以下に記載された5つのステージをすべて実行します。

プロセス

以下の5つのステージを順番に実行してください。ステージを省略してはいけません。

ステージ1：主張の切り分け

トレース対象となる正確な主張を特定します。複合的な質問は原子的な主張に分けます。

Input: "Why did you recommend microservices over a monolith?"
Atomic claims:
  1. Microservices are a better architectural fit for this project
  2. The team can handle microservices operational complexity
  3. The migration cost is justified by long-term benefits

各原子的な主張について、独自の前提一覧と信頼度スコアを作成します。

ステージ2：前提の一覧化

各原子的な主張について、推論が依存する前提をすべて列挙します。各前提には次の3つの属性を付与します。

#	前提	重要度	検証可能性
A1	[Statement]	High -- 誤っていると結論が変わる	直接検証可能 -- テスト／測定できる
A2	[Statement]	Medium -- 誤っていると結論が弱まる	間接的に検証可能 -- 代替データから推測できる
A3	[Statement]	Low -- 誤っていても結論は変わらない	検証不可能 -- 判断に基づいて受け入れるか、退ける必要がある

重要度の基準：

• High： この前提が誤っている場合、結論が覆るか、正当化できなくなります。
• Medium： 誤っている場合、結論は大幅に弱まりますが、但し書き付きで成り立つ可能性があります。
• Low： 誤っていても、結論はほとんど影響を受けません。

検証可能性の基準：

• 直接検証可能： テスト、測定、または権威ある情報源による確認が可能です。
• 間接的に検証可能： 関連データ、ベンチマーク、または類推から推測できます。
• 検証不可能： 判断や予測が必要な場合、または将来の未知の要素に依存する場合です。

ステージ 3：分岐の根拠を示す意思決定ツリー

推論における重要な分岐点ごとに、以下を記録します。

1. 意思決定のポイント： どのような問いに答える必要がありましたか？
2. 検討した選択肢： 少なくとも 2 つ（選択した方針と、採用しなかった代替案を最低 1 つ）。
3. 評価基準： どの要因が選択を決定しましたか？
4. 選択した方針： どの選択肢を選びましたか？
5. 却下の理由： 各代替案を却下した理由を、曖昧にせず具体的に示します。
6. 選択を覆す条件： 何が成り立てば、却下した代替案の方が適切になりますか？

Decision Point: Database selection
  ├─ Option A: PostgreSQL [CHOSEN]
  │   Strengths: ACID compliance, JSON support, ecosystem maturity
  │   Evidence type: Empirical (benchmarks) + Authority (industry adoption data)
  │
  ├─ Option B: SQLite [REJECTED]
  │   Strengths: Zero-config, embedded, fast for reads
  │   Rejection: Write concurrency limit (~5 writers) incompatible with
  │              multi-instance deployment requirement (Assumption A2)
  │   Reversal: If deployment is single-instance AND write volume < 100/sec,
  │             SQLite becomes the simpler, better choice
  │
  └─ Option C: MongoDB [REJECTED]
      Strengths: Schema flexibility, horizontal scaling
      Rejection: Data has strong relational structure (7 FK relationships);
                 denormalization cost outweighs flexibility benefit
      Reversal: If schema changes weekly or data is primarily document-shaped

ステージ 4：確信度の分解

全体的な確信度を、独立したサブ要素に分解します。最低 3 つ、推奨は 4〜6 つです。

各サブ要素には、以下を記載します。

• パーセンテージ（0〜100％）
• 根拠となる証拠の種類（経験的／理論的／権威に基づく／混合）
• 具体的な根拠を挙げた 1〜2 文の説明

全体的な確信度は、単純な平均ではありません。結論に対する重要度に応じて、各サブ要素に重み付けします。

Overall Confidence: 72%

Sub-components:
  Technical Feasibility:   90% [Empirical] -- proven in similar systems (refs: X, Y benchmarks)
  Timeline Estimate:       45% [Theoretical] -- based on analogy to past project, but team composition differs
  Cost Projection:         60% [Mixed] -- infrastructure costs are empirical, opportunity cost is estimated
  Team Capability Match:   75% [Authority] -- based on stated team skills; not independently verified
  Risk Assessment:         80% [Theoretical] -- standard failure modes well-understood; novel integration untested

Weighted Overall: (90*0.3 + 45*0.25 + 60*0.15 + 75*0.15 + 80*0.15) = 71.5% ≈ 72%

ステージ 5：最も弱い根拠と代替結論

最も弱い根拠の特定： どの前提または小結論が間違っていた場合、最終的な回答が最も大きく変わりますか？

最も弱い根拠の選定基準：

1. 前提の中で最も重要度が高い
2. 検証可能性が最も低い（確認が最も難しい）
3. サブ要素の中で確信度が最も低い
4. この 3 つの要素が重なる部分が、最も弱い根拠です

代替結論： 「［最も弱い根拠となる前提］が間違っている場合、結論は［X］に変わります。」

これは仮定に基づく埋め草ではありません。最も弱い前提を否定した場合に、論理的に導かれる、真に理由のある代替結論でなければなりません。

出力形式

## Reasoning Trace: [Claim/Question]

### Atomic Claims
1. [Claim 1]
2. [Claim 2]
3. [Claim N]

### Assumption Inventory
| # | Assumption | Criticality | Verifiability | Tied to Claim |
|---|-----------|-------------|---------------|---------------|
| A1 | [Statement] | High | Directly Verifiable | Claim 1 |
| A2 | [Statement] | High | Unverifiable | Claim 2 |
| A3 | [Statement] | Medium | Indirectly Verifiable | Claim 1, 3 |
| ... | ... | ... | ... | ... |

### Decision Forks

#### Fork 1: [Decision Point]
- **Chosen:** [Option] -- [rationale with evidence type label]
- **Rejected:** [Option] -- [specific rejection reason]
  - *Reversal condition:* [what would make this the right choice]
- **Rejected:** [Option] -- [specific rejection reason]
  - *Reversal condition:* [what would make this the right choice]

#### Fork 2: [Decision Point]
...

### Confidence Decomposition
| Dimension | Confidence | Evidence Type | Basis |
|-----------|-----------|---------------|-------|
| [Dimension 1] | XX% | Empirical | [specific justification] |
| [Dimension 2] | XX% | Theoretical | [specific justification] |
| [Dimension 3] | XX% | Authority | [specific justification] |
| [Dimension N] | XX% | Mixed | [specific justification] |

**Overall Confidence: XX%** (weighted by dimension importance)

### Weakest Link
**Assumption [A#]:** [restate the assumption]
- **Criticality:** High
- **Verifiability:** [rating]
- **Current confidence in this assumption:** XX%
- **Why this is the weakest link:** [explanation]
- **How to verify:** [concrete steps the user can take]

### Alternative Conclusion
> If **[weakest assumption]** is wrong, then:
> [Alternative conclusion with reasoning -- not a throwaway sentence but a genuinely traced alternative]

### Falsification Conditions
The main conclusion is wrong if ANY of these turn out to be true:
1. [Condition 1]
2. [Condition 2]
3. [Condition N]

品質の基準

悪い例（このようにしないでください）

Q: "Why did you recommend React over Vue?"

I recommended React because it has a larger ecosystem, more job
postings, and better TypeScript support. It's the safer choice
for most teams because it's battle-tested at scale by Meta and
many other companies.

Confidence: High.

問題点：

• 前提が示されていません。「高い確信度」の根拠は何ですか？
• 代替案が検討されていません。Vue は本当に真剣に検討されましたか？
• 最も弱い根拠が示されていません。ユーザーはどこに異議を唱えるべきですか？
• 意思決定の分岐がありません。「より大きい」または「より優れている」と判断した基準は何ですか？
• 「大規模環境で実績がある」は、具体的な根拠を示さない権威への訴えです。
• 推論の記録ではなく、宣伝文句のように読めます。

良い例（この品質を目指してください）

## Reasoning Trace: Why React over Vue for this project?

### Atomic Claims
1. React is a better framework fit for this project's requirements
2. The team will be more productive with React than Vue
3. React's ecosystem advantage outweighs Vue's simplicity advantage

### Assumption Inventory
| # | Assumption | Criticality | Verifiability | Tied to Claim |
|---|-----------|-------------|---------------|---------------|
| A1 | Team has 2+ engineers with React experience | High | Directly Verifiable | Claim 2 |
| A2 | Project requires complex state management | Medium | Directly Verifiable | Claim 1 |
| A3 | Hiring pipeline will favor React candidates | High | Indirectly Verifiable | Claim 2 |
| A4 | Project will need SSR capabilities | Medium | Directly Verifiable | Claim 1 |
| A5 | TypeScript will be used project-wide | Low | Directly Verifiable | Claim 3 |

### Decision Forks

#### Fork 1: Framework Selection
- **Chosen:** React -- larger component ecosystem (npm: 90k+ packages
  tagged "react" vs 25k+ "vue"), more mature SSR story (Next.js 15 stable
  vs Nuxt 4 recent), team has existing React experience (A1)
- **Rejected:** Vue -- lower learning curve, better developer ergonomics
  for smaller teams, Composition API is excellent
  - *Reversal condition:* If team has 0 React experience AND project is
    < 6 month lifespan AND no SSR needed, Vue's faster onboarding wins
- **Rejected:** Svelte -- best DX, smallest bundle, genuinely better
  reactivity model
  - *Reversal condition:* If team is greenfield (no framework experience),
    project is performance-critical consumer app, and hiring is not a
    constraint (small, stable team)

### Confidence Decomposition
| Dimension | Confidence | Evidence Type | Basis |
|-----------|-----------|---------------|-------|
| Framework capability match | 85% | Empirical | Feature comparison against requirements doc |
| Team productivity | 55% | Mixed | Based on stated skills (A1); not observed |
| Ecosystem longevity | 80% | Authority | Meta backing, npm download trends, State of JS 2025 |
| Hiring advantage | 50% | Indirectly Empirical | LinkedIn job postings (3:1 React:Vue ratio, but market shifts) |

**Overall Confidence: 68%** (productivity and hiring are uncertain
but heavily weighted)

### Weakest Link
**Assumption A1:** Team has 2+ engineers with React experience
- **Criticality:** High
- **Verifiability:** Directly Verifiable
- **Current confidence:** 70% (stated by PM, not verified via code review)
- **Why this is the weakest link:** If the team lacks real React
  experience, the productivity advantage evaporates and Vue's lower
  learning curve becomes the dominant factor
- **How to verify:** Review team members' recent commits; conduct
  brief technical screen on React patterns (hooks, context, suspense)

### Alternative Conclusion
> If **team React experience (A1)** is overstated, then Vue is the
> better choice: its gentler learning curve (Composition API maps
> well to React hooks mental model but with less boilerplate),
> better documentation, and faster time-to-productive offset the
> smaller ecosystem. The recommendation flips to Vue with Nuxt.

### Falsification Conditions
1. Team has < 2 engineers genuinely proficient in React (not just "used it once")
2. Project scope shrinks to < 6 months with no SSR requirement
3. Hiring is not a concern (stable team, no growth planned)

使用する場面

• あらゆる推奨の後：「なぜ Postgres なのか？」「なぜマイクロサービスなのか？」「なぜこのライブラリなのか？」
• あらゆる見積もりの後：「なぜ 2 週間なのか？」「なぜ 50,000 ドルなのか？」「なぜエンジニアが 3 人なのか？」
• 関係者が推論を検証する必要があるアーキテクチャ上の意思決定
• コードレビューの根拠：「なぜこれをセキュリティ上の問題として指摘したのか？」
• ユーザーが「納得させて」または「これでいいのか確信が持てない」と言ったとき
• 事後分析：「なぜ X がうまくいくと思ったのか？」
• 推論が厳しい検証に耐える必要がある、あらゆる重要な意思決定

使用しない場面

• 明確な答えがある単純な事実確認（「Postgres が使用するポートは何ですか？」）
• 構造化された推論によって発想が妨げられる創造的なブレインストーミング（swing-options を使用）
• ユーザーが簡潔な回答を求め、明示的にそう伝えているとき
• 追跡する特定の主張がない、網羅的なコード／システム分析
• 他者の推論に負荷をかけて検証するとき（攻撃する swing-review を使用します。このスキルは推論を明らかにします）
• 外部ソースによる検証が必要な調査（事実には swing-research を使用します。このスキルは事実に関する推論を追跡します）

注意点

1. クイックモードがデフォルトです。 --full が指定されていない限り、ステージ 1、2、5 のみを実行します。クイックモードでは、決定木や信頼度の分解を作成しないでください。コンテキストを無駄に消費します。
2. 具体的な根拠を示さずに、確信度を 80％超に設定してはいけません。 「一般常識」「よく知られている」「広く受け入れられている」は正当な根拠ではありません。ベンチマーク、ドキュメント、テスト結果を明記してください。
3. すべてのモードで「最弱のリンク」は必須です。 クイックモードでも同様です。これは最も価値の高い出力です。省略すると、トレース全体が無意味になります。
4. すべての前提に評価を付けてください。 重要度と検証可能性の評価がない前提は不完全です。例外はなく、「明白な」前提であっても評価を省略してはいけません。
5. 代替結論には、実際の推論を含めてください。 「X が間違っているなら再検討する」は内容のない文言です。代替の論理を実際にたどってください。「X が間違っているなら、Z であるため Y となる」のように記述してください。

統合に関する注意事項

• swing-clarify との連携： 曖昧なリクエストでは、このスキルを呼び出す前に swing-clarify を実行してください。範囲を明確にすると、より良い結果が得られます。
• swing-review の前に： まず推論をトレースし、その後にストレステストを行ってください。swing-trace の前提一覧は、swing-review の攻撃ベクトルに直接活用できます。
• swing-research の後に： 調査によって検証済みの事実を集め、その後 swing-trace によって、それらの事実と結論を結び付ける論理を明らかにします。
• swing-options との連携： swing-options が選択肢を生成した場合、swing-trace を使って、ある選択肢がほかより選ばれた理由をトレースできます。