complex-reasoning

複雑な推論スキル

拡張思考能力を活用し、深い分析を行うための体系的な問題解決フレームワークです。

使用する場面

• 複数の原因が考えられる複雑な問題のデバッグ
• トレードオフ分析を必要とするアーキテクチャの決定
• 本番環境のインシデントにおける根本原因分析
• 複数の変数を考慮したパフォーマンス最適化
• セキュリティ脆弱性の評価
• 多くの依存関係を伴うコードのリファクタリング

推論フレームワーク

Chain-of-Thought（CoT）

順序立てて解決する問題に対する、直線的なステップごとの推論です。

## Chain-of-Thought Analysis

**Problem**: [State the problem clearly]

**Step 1: Understand the Context**
- What do we know?
- What are the constraints?
- What is the expected outcome?

**Step 2: Identify Key Components**
- Component A: [description]
- Component B: [description]
- Interactions: [how they relate]

**Step 3: Analyze Each Component**
- Component A analysis...
- Component B analysis...

**Step 4: Synthesize Findings**
- Key insight 1
- Key insight 2

**Step 5: Formulate Solution**
- Recommended approach
- Rationale
- Trade-offs

**Conclusion**: [Final recommendation with confidence level]

Tree-of-Thought（ToT）

複数の解決経路がある問題に対する、分岐型の探索です。

## Tree-of-Thought Exploration

**Root Problem**: [Problem statement]

### Branch 1: Approach A
├── Pros: [List advantages]
├── Cons: [List disadvantages]
├── Feasibility: [High/Medium/Low]
├── Sub-branch 1.1: [Variation]
│   └── Outcome: [Expected result]
└── Sub-branch 1.2: [Variation]
    └── Outcome: [Expected result]

### Branch 2: Approach B
├── Pros: [List advantages]
├── Cons: [List disadvantages]
├── Feasibility: [High/Medium/Low]
└── Sub-branches: [...]

### Branch 3: Approach C
├── Pros: [...]
├── Cons: [...]
└── Feasibility: [...]

### Evaluation Matrix
| Approach | Feasibility | Impact | Risk | Score |
|----------|-------------|--------|------|-------|
| A        | High        | Medium | Low  | 8/10  |
| B        | Medium      | High   | Med  | 7/10  |
| C        | Low         | High   | High | 5/10  |

**Selected Path**: Branch [X] because [reasoning]

MECE フレームワーク

相互に排他的で、全体として網羅的な分析です。

## MECE Analysis

**Problem Space**: [Define the complete problem]

### Category 1: [Mutually exclusive category]
- Sub-element 1.1
- Sub-element 1.2
- Sub-element 1.3

### Category 2: [Mutually exclusive category]
- Sub-element 2.1
- Sub-element 2.2

### Category 3: [Mutually exclusive category]
- Sub-element 3.1
- Sub-element 3.2
- Sub-element 3.3

**Completeness Check**:
- [ ] Categories are mutually exclusive (no overlap)
- [ ] Categories are collectively exhaustive (cover all cases)
- [ ] Each sub-element belongs to exactly one category

**Priority Matrix**:
| Category | Urgency | Impact | Action |
|----------|---------|--------|--------|
| 1        | High    | High   | Now    |
| 2        | Medium  | High   | Next   |
| 3        | Low     | Medium | Later  |

仮説主導型デバッグ

複雑な問題をデバッグするための体系的なアプローチです。

## Hypothesis-Driven Debug Session

**Symptom**: [Observed behavior]
**Expected**: [What should happen]
**Environment**: [Relevant context]

### Hypothesis 1: [Most likely cause]
**Evidence For**:
- [Supporting observation 1]
- [Supporting observation 2]

**Evidence Against**:
- [Contradicting observation]

**Test**: [How to validate]
**Result**: [Confirmed/Refuted]

### Hypothesis 2: [Second most likely]
**Evidence For**:
- [...]

**Evidence Against**:
- [...]

**Test**: [...]
**Result**: [...]

### Root Cause Identified
**Cause**: [Confirmed root cause]
**Evidence Chain**: [How we proved it]
**Fix**: [Remediation steps]
**Prevention**: [How to prevent recurrence]

コード分析のパターン

依存関係の分析

## Dependency Analysis: [Component Name]

### Direct Dependencies
| Dependency | Version | Purpose | Risk Level |
|------------|---------|---------|------------|
| dep-a      | 2.3.1   | Auth    | Low        |
| dep-b      | 1.0.0   | Data    | Medium     |

### Transitive Dependencies
- Total: [N] packages
- Security vulnerabilities: [N]
- Outdated: [N]

### Dependency Graph

[component] ├── dep-a │ ├── sub-dep-1 │ └── sub-dep-2 └── dep-b └── sub-dep-3

### Risk Assessment
1. **High Risk**: [Dependencies with known issues]
2. **Medium Risk**: [Outdated or unmaintained]
3. **Low Risk**: [Stable, well-maintained]

### Recommendations
1. [Action item 1]
2. [Action item 2]

影響分析

## Impact Analysis: [Proposed Change]

### Affected Components
| Component | Impact Type | Severity | Test Required |
|-----------|-------------|----------|---------------|
| Service A | Direct      | High     | Yes           |
| Service B | Indirect    | Medium   | Yes           |
| Client C  | Downstream  | Low      | Optional      |

### Risk Assessment
- **Breaking Changes**: [List any]
- **Performance Impact**: [Expected effect]
- **Data Migration**: [Required/Not required]

### Rollback Plan
1. [Step 1]
2. [Step 2]
3. [Verification]

### Recommendation
[Go/No-Go with reasoning]

拡張思考との統合

これらのフレームワークを拡張思考と併用する場合：

# Enable extended thinking for complex reasoning
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # deeper reasoning for complex problems
    system="""You are a systematic problem solver. Use structured
    reasoning frameworks like Chain-of-Thought, Tree-of-Thought,
    or MECE analysis as appropriate for the problem.""",
    messages=[{
        "role": "user",
        "content": "Analyze this architecture decision using ToT..."
    }]
)

ベストプラクティス

1. 適切なフレームワークを選ぶ：直線的な問題には CoT、分岐する判断には ToT を使用します
2. 推論を文書化する：レビューや再現が可能になります
3. 前提を検証する：各ステップは検証済みの事実に基づく必要があります
4. 代替案を検討する：常に 2～3 個以上のアプローチを検討します
5. 可能な場合は定量化する：指標を使って選択肢を比較します
6. 探索に時間制限を設ける：分析の深さに上限を設定します

関連項目

• [[extended-thinking]] - 深い推論能力を有効にする
• [[deep-analysis]] - 分析用テンプレート
• [[debugging]] - 一般的なデバッグパターン
• [[testing]] - 検証戦略