chain-of-thought

思考の連鎖による推論

目的

このスキルは、プロンプトに思考の連鎖（CoT）ブロックを挿入することで、構造化された透明性の高い推論を可能にします。モデルに段階的に考え、推論プロセスを明示し、思考と最終出力を分けるよう促します。

思考の連鎖による推論は、次の点を改善します。

• 問題解決の正確性 - 複雑な問題を扱いやすい手順に分解します
• 透明性 - 推論を可視化し、監査可能にします
• 自己修正 - 推論中にモデルが誤りを発見し、修正できるようにします
• 計画 - 振り返りと段階的な計画の改善を可能にします
• デバッグ - 結論に至った経緯を理解できるようにします

使用する場面

明示的な推論が役立つタスクで、このスキルを有効にします。

• 複雑な問題解決 - 複数段階にわたる数学的、論理的、分析的な問題
• コード分析 - 見慣れないコードベースの理解、デバッグ、アーキテクチャ上の判断
• 計画と設計 - 機能の分解、システムの設計、実装計画の作成
• 調査タスク - 複数の情報源から情報を統合
• 意思決定 - 複数のアプローチにおけるトレードオフの評価
• エラー診断 - バグや予期しない動作の調査
• リファクタリング - コード改善とその影響についての推論
• 「作業過程を示す」ことで成果が向上するあらゆるタスク

仕組み

思考の連鎖では、推論と出力のセクションを区切るために XML タグを使います。

基本構造

<thinking>
Step 1: [Analyze the problem]
- What are we trying to accomplish?
- What information do we have?
- What's missing?

Step 2: [Break down the approach]
- What are the main steps?
- What are potential challenges?

Step 3: [Evaluate options]
- Option A: pros and cons
- Option B: pros and cons
- Decision: [chosen approach and why]

Step 4: [Verify reasoning]
- Does this make sense?
- Are there edge cases?
- What could go wrong?
</thinking>

<answer>
[Clear, concise final output based on the reasoning above]
</answer>

マルチエージェントシステム向けの高度な構造

Manus AI のマルチエージェントシステムに着想を得た、複雑なワークフローでネストされた思考を使う方法です。

<thinking>
## Initial Analysis
[First pass understanding]

## Plan Formation
Current plan:
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Reflection
Is this plan optimal?
- Consideration 1: [reflection]
- Consideration 2: [reflection]

## Plan Update
Revised plan:
1. [Updated step 1]
2. [Updated step 2]
3. [New step 3]

Rationale for changes: [explanation]

## Execution Strategy
How to implement step 1:
- [Details]
- [Considerations]
</thinking>

<answer>
[Final output incorporating refined thinking]
</answer>

プロンプトへの挿入パターン

パターン 1：問題解決のテンプレート

<thinking>
1. Problem understanding:
   - Given: [what we know]
   - Goal: [what we need to find/do]
   - Constraints: [limitations]

2. Approach:
   - Strategy: [chosen method]
   - Why: [rationale]

3. Step-by-step execution:
   - [Step 1 with reasoning]
   - [Step 2 with reasoning]
   - [Step 3 with reasoning]

4. Verification:
   - Does the solution meet requirements?
   - Are there edge cases?
</thinking>

<answer>
[Solution]
</answer>

パターン 2：コード分析のテンプレート

<thinking>
1. Code structure overview:
   - Main components: [list]
   - Data flow: [description]

2. Key observations:
   - Pattern 1: [what and why]
   - Pattern 2: [what and why]

3. Analysis:
   - [Detailed reasoning about the code]

4. Conclusion:
   - [Synthesis of findings]
</thinking>

<answer>
[Clear explanation or recommendation]
</answer>

パターン 3：計画のテンプレート

<thinking>
1. Requirements analysis:
   - Must have: [core requirements]
   - Nice to have: [optional features]

2. Initial plan:
   [List of steps]

3. Risk assessment:
   - Risk 1: [description and mitigation]
   - Risk 2: [description and mitigation]

4. Plan refinement:
   [Updated plan based on risks]

5. Validation:
   - Does this plan address all requirements?
   - Is it feasible?
   - What assumptions are we making?
</thinking>

<answer>
[Final plan with clear action items]
</answer>

ガイドライン

1. 思考を構造化する

• 理解から始める - 分かっていることと、明らかにする必要があることを述べます
• 複雑なタスクを分解する - 小さく、扱いやすい部分に分けます
• 作業過程を示す - 結論だけでなく、中間の手順も書き出します
• 明確にする - 前提、トレードオフ、推論をはっきり述べます

2. 振り返りを行う

• アプローチを問い直す - 「これが最善の方法でしょうか？」
• 論理を確認する - 「この推論に無理はないでしょうか？」
• 代替案を検討する - 「ほかにどのようなアプローチがあるでしょうか？」
• 計画を更新する - 新たな知見に基づいて、ためらわずに見直します

3. 思考と出力を分ける

• 思考ブロック - 探索、推論、問題への取り組みに使います
• 回答ブロック - 整えた最終回答に使います
• 思考は生のままにする - 過度に整えず、実際の推論を示します
• 回答は簡潔にする - ユーザーに見せるのは回答であり、思考は内部のものです

4. 各ブロックの使い分け

<thinking> を使う場面：

• 要件の分析
• 問題の分解
• 選択肢の評価
• 論理の展開
• 実装の計画
• 判断の振り返り
• エラーの発見
• トレードオフの検討

<answer> を使う場面：

• 最終的な推奨事項
• 実装した解決策
• 明確な説明
• 対応事項
• 結論

5. ベストプラクティス

• 思考では正直に述べる - 不確かな場合は、その旨を伝えます
• エラーの修正を示す - 誤りに気付いたら、思考ブロック内で修正します
• Markdown を使う - 読みやすいように思考ブロックを整えます
• 手順に番号を付ける - 推論を追いやすくします
• 回答で要約する - 要点を把握するために、ユーザーが思考のすべてを読む必要がないようにします

例

例 1：問題のデバッグ

プロンプト：「この関数は負の数に対して正しくない結果を返しています。修正できますか？」

<thinking>
1. Understanding the problem:
   - Function works for positive numbers
   - Fails for negative numbers
   - Need to identify why negatives cause issues

2. Code analysis:
   - [Read through the function]
   - Line 15: Uses Math.abs() - converts negative to positive
   - Line 20: Returns result without sign restoration
   - Aha! The absolute value removes the sign, but we never restore it

3. Solution approach:
   - Option A: Track sign separately and reapply
   - Option B: Handle negative numbers differently
   - Choosing A: cleaner and preserves existing logic

4. Implementation plan:
   - Store original sign
   - Apply absolute value for calculation
   - Multiply result by original sign
</thinking>

<answer>
The bug is on lines 15-20. The function uses `Math.abs()` but never restores the original sign. Here's the fix:

```javascript
const sign = num < 0 ? -1 : 1;
const absNum = Math.abs(num);
// ... existing calculation ...
return result * sign;

```

Example 2: Choosing Between Architectures

Prompt: "Should we use microservices or a monolith for this project?"

<thinking>
1. Context gathering:
   - Team size: small (3 developers)
   - Project scope: MVP with planned growth
   - Timeline: 3 months to launch
   - Infrastructure: cloud-based

2. Microservices analysis:
   Pros:
   - Scalability per service
   - Independent deployment
   - Technology flexibility

   Cons:
   - Operational complexity (DevOps overhead)
   - Network latency
   - Distributed debugging challenges
   - Over-engineering for small team

3. Monolith analysis:
   Pros:
   - Simpler deployment
   - Easier debugging
   - Faster initial development
   - Single codebase

   Cons:
   - Scaling requires scaling entire app
   - Potential coupling issues
   - May need to break apart later

4. Decision reasoning:
   - Small team → simpler is better
   - MVP timeline → need speed
   - Planned growth → can refactor later
   - Monolith-first approach is lower risk

5. Recommendation:
   Start with modular monolith, design for eventual extraction
</thinking>

<answer>
For your project, I recommend starting with a **modular monolith**:

**Why:**
- Your small team will move faster without microservices overhead
- 3-month MVP timeline needs simplicity
- You can refactor to microservices later if needed

**Key principle:** Design modules with clear boundaries (separate folders, interfaces) so future extraction is easier.

**Action items:**
1. Structure code in domain modules (auth, payments, users)
2. Use dependency injection for loose coupling
3. Plan data models to avoid cross-module dependencies
</answer>

例 3：複数段階の実装計画

プロンプト：「アプリに OAuth を使ったユーザー認証を追加してください」

<thinking>
## Initial Analysis
Requirements:
- OAuth integration (which providers? assuming Google/GitHub)
- User session management
- Protected routes
- Existing app: appears to be Express.js based

## Plan Formation v1
1. Choose OAuth library
2. Set up OAuth credentials
3. Implement login/logout routes
4. Add session middleware
5. Protect existing routes

## Reflection
Issues with v1:
- Didn't consider token storage
- No user database integration mentioned
- Missing error handling strategy
- Should address CSRF protection

## Plan Formation v2
1. Research codebase for existing auth patterns
2. Choose OAuth library (passport.js likely best for Express)
3. Set up database schema for users
4. Configure OAuth providers (Google, GitHub)
5. Implement authentication routes
6. Add session management with secure tokens
7. Create auth middleware for protected routes
8. Add CSRF protection
9. Implement logout and session cleanup
10. Add error handling for auth failures

## Execution Strategy for Step 1
Need to:
- Check if passport.js already installed
- Look for existing user models
- Identify protected routes
- Check current session handling
</thinking>

<answer>
I'll implement OAuth authentication. Let me start by researching your current codebase to understand existing patterns, then proceed with the implementation plan:

1. Audit current auth patterns
2. Set up passport.js with OAuth strategies
3. Create user database schema
4. Implement login/logout flows
5. Add session management
6. Protect routes with auth middleware
7. Add security measures (CSRF, secure tokens)

Starting with codebase research...
</answer>

マルチエージェントシステムとの統合

Manus AI のようなマルチエージェントアーキテクチャでは、思考の連鎖によって次のことが可能になります。

• エージェントの振り返り - エージェントは実行前に、自身の行動について明示的に推論します
• 計画の更新 - エージェントは中間結果に基づいて戦略を修正します
• エージェント間の通信 - 思考ブロックによって、連携の透明性が高まります
• エラーからの復旧 - エージェントは推論中に問題を検出し、対応できます

エージェントは、複数のターンにわたって思考を保持できます。

<thinking>
## Turn 1 Reflection
Previous attempt: [what was tried]
Result: [what happened]
Learning: [what we discovered]

## Updated Strategy
Based on the failure, trying new approach:
[revised plan]
</thinking>

<answer>
[Action based on updated thinking]
</answer>

参考資料

詳しい例や高度なパターンについては、次を参照してください。

• REFERENCE.md - 発展的な例とパターン
• XML Guide Conventions - XML タグの適切な使用方法

まとめ

思考の連鎖による推論によって、AI の動作は次のように改善されます。

• 透明性 - 結論に至った経緯を確認できます
• 信頼性 - 段階的な推論によってエラーが減ります
• デバッグのしやすさ - 推論が誤った箇所を簡単に特定できます
• 適応性 - 振り返りによって計画を更新できます

明示的な推論によって成果が向上する場合は、このスキルを使用してください。