動的コンテキスト注入：Contexts の使用
学習目標
動的コンテキスト注入を学習した後、以下のことができるようになります：
- 現在のワークモードに応じてAIの行動戦略を切り替える（開発、レビュー、リサーチ）
- Claudeが異なるシーンで異なる優先度とツールの好みに従うようにする
- 同じセッション内での作業目標の混乱を防ぎ、集中力を向上させる
- 異なるフェーズの作業効率を最適化する（迅速な実装 vs 深度のあるレビュー）
現在の課題
開発プロセスで以下の問題に遭遇したことはありませんか？
- 迅速な開発が必要なとき、Claudeが常に過剰に分析し、過度な提案をして進捗を遅らせる
- コードレビュー時、Claudeがコードを修正するのに急いで、丁寧に読んで問題を発見しない
- 新しい問題を研究する時、Claudeがまだ理解していないのにすぐコードを書き始め、方向性を間違える
- 同じセッション内で、開発とレビューを行き来し、Claudeの行動パターンが混乱する
これらの問題の根本原因は：Claudeに明確な「ワークモード」のシグナルがないことです。現在何を優先すべきかを知らないのです。
いつこの方法を使うか
- 開発フェーズ：AIに機能実装を優先させ、詳細な議論は後で
- コードレビュー：AIに先に十分に理解させ、その後に改善提案をさせる
- 技術調査：AIに先に探索学習させ、その後に結論を出させる
- ワークモード切り替え時：現在の目標を明確に伝える
コアコンセプト
動的コンテキスト注入の核心はAIを異なるワークモードで異なる行動戦略を持たせることです。
3つのワークモード
Everything Claude Codeは3つの定義済みコンテキストを提供します：
| モード | ファイル | フォーカス | 優先度 | 使用シーン |
|---|---|---|---|---|
| dev | contexts/dev.md | 機能実装、迅速な反復 | 先に動かして、後に改善 | 日常開発、新機能実装 |
| review | contexts/review.md | コード品質、セキュリティ、保守性 | 先に問題を発見し、後に修正を提案 | Code Review、PRレビュー |
| research | contexts/research.md | 問題理解、ソリューションの探索 | 先に理解し、後に着手 | 技術調査、Bug分析、アーキテクチャ設計 |
なぜ動的コンテキストが必要か？
コンテキスト vs システムプロンプト
システムプロンプトはClaude Code起動時に読み込まれる固定の指示です（agents/、rules/ディレクトリの内容など）。AIの基本的な振る舞いを定義します。
コンテキストは現在のワークモードに応じて動的に注入する一時的な指示です。システムプロンプトを上書きまたは補完し、特定のシーンでAIの振る舞いを変えます。
システムプロンプトは「グローバルデフォルト」、コンテキストは「シーンオーバーライド」です。
ワークモードの比較
同じタスクでも、異なるモードでのAIの挙動の違い：
### タスク：ログイン失敗を引き起こすBugを修正する
#### devモード（迅速な修正）
- 問題を素早く特定
- コードを直接修正
- テストを実行して検証
- 先に動かして、後に最適化
### reviewモード（深い分析）
- 関連コードを十分に読む
- 境界条件とエラーハンドリングをチェック
- 修正案の影響を評価
- 先に問題を発見し、後に修正を提案
### researchモード（徹底的な調査）
- 可能なすべての原因を探索
- ログとエラーメッセージを分析
- 仮説を検証
- 先に根因を理解し、後にソリューションを提示🎒 事前準備
前提条件
このチュートリアルでは、以下のことを前提としています：
- ✅ クイックスタート を完了している
- ✅ Everything Claude Codeプラグインをインストール済み
- ✅ 基本的なセッション管理の概念を理解している
実践：動的コンテキストを使用する
ステップ1：3つのコンテキストの動作を理解する
まず各コンテキストの定義を理解しましょう：
dev.md - 開発モード
目標：機能を迅速に実装し、先に動かしてから改善する
優先度：
- Get it working（動作させる）
- Get it right（正しくする）
- Get it clean（きれいにする）
行動戦略：
- Write code first, explain after（先にコードを書き、後に説明する）
- Prefer working solutions over perfect solutions（完璧なソリューションより動くソリューションを優先する）
- Run tests after changes（変更後にテストを実行する）
- Keep commits atomic（コミットをアトミックに保つ）
ツールの好み：Edit、Write（コード修正）、Bash（テスト/ビルド実行）、Grep/Glob（コード検索）
review.md - レビューモード
目標：コード品質の問題、セキュリティ脆弱性、保守性の問題を発見する
優先度：Critical（重要） > High（高） > Medium（中） > Low（低）
行動戦略：
- Read thoroughly before commenting（十分に読んでからコメントする）
- Prioritize issues by severity（重大度順に問題を並べる）
- Suggest fixes, don't just point out problems（修正案を提案し、単に問題を指摘するだけにしない）
- Check for security vulnerabilities（セキュリティ脆弱性をチェックする）
チェックリスト：
- [ ] Logic errors（論理エラー）
- [ ] Edge cases（境界条件）
- [ ] Error handling（エラーハンドリング）
- [ ] Security（injection, auth, secrets）（セキュリティ）
- [ ] Performance（パフォーマンス）
- [ ] Readability（可読性）
- [ ] Test coverage（テストカバレッジ）
出力形式：ファイルごとにグループ化し、重大度順
research.md - リサーチモード
目標：問題を深く理解し、可能なソリューションを探索する
リサーチフロー：
- Understand the question（問題を理解する）
- Explore relevant code/docs（関連コード/ドキュメントを探索する）
- Form hypothesis（仮説を立てる）
- Verify with evidence（証拠で検証する）
- Summarize findings（発見を要約する）
行動戦略：
- Read widely before concluding（結論を出す前に広く読む）
- Ask clarifying questions（明確化の質問をする）
- Document findings as you go（探索しながら発見を記録する）
- Don't write code until understanding is clear（理解が明確になるまでコードを書かない）
ツールの好み：Read（コード理解）、Grep/Glob（パターン検索）、WebSearch/WebFetch（外部ドキュメント）、Task with Explore agent（コードベースの問題）
出力形式：先に発見し、後に提案
ステップ2：コンテキストを選択して適用する
現在のワークシーンに応じて、適切なコンテキストを選択します。
シーン1：新機能を実装する
適用コンテキスト：dev.md
適用方法：
@contexts/dev.md
ユーザー認証機能を実装してください：
1. メールパスワードログインをサポート
2. JWT tokenを生成
3. ルートを保護するミドルウェアを実装Claudeはどのように振る舞うか：
- コア機能を迅速に実装
- 過度な設計をしない
- 実装後にテストを実行して検証
- コミットをアトミックに保つ（各コミットで小さな機能を完成）
あなたは以下を見るはずです：
- 実行可能なコードを迅速に取得
- テストが通過
- 機能が利用可能だが、まだエレガントではない可能性
シーン2：同僚のPRをレビューする
適用コンテキスト：review.md
適用方法：
@contexts/review.md
このPRをレビューしてください：https://github.com/your-repo/pull/123
重点的にチェック：
- セキュリティ（SQL注入、XSS、認証）
- エラーハンドリング
- パフォーマンスの問題Claudeはどのように振る舞うか：
- まず関連するすべてのコードを十分に読む
- 重大度順に問題を並べる
- 各問題に対して修正案を提供
- コードを直接修正せず、提案のみを行う
あなたは以下を見るはずです：
- 構造化されたレビューレポート（ファイル別、重大度別）
- 各問題に具体的な位置と修正案がある
- Criticalレベルの問題が優先的にマークされている
シーン3：新技術の統合ソリューションを調査する
適用コンテキスト：research.md
適用方法：
@contexts/research.md
プロジェクトに分析データベースとしてClickHouseを統合したいので、調査を手伝ってください：
1. ClickHouseのメリットとデメリット
2. 既存のPostgreSQLアーキテクチャとの連携方法
3. 移行戦略とリスク
4. パフォーマンスベンチマークの結果
コードを書かずに、まずソリューションを明確に調査してください。Claudeはどのように振る舞うか：
- まずClickHouseの公式ドキュメントとベストプラクティスを検索
- 関連する移行事例を読む
- 既存のアーキテクチャとの互換性を分析
- 探索しながら発見を記録
- 最後に包括的な提案をする
あなたは以下を見るはずです：
- 詳細な技術比較分析
- リスク評価と移行提案
- コードなし、ソリューションと結論のみ
ステップ3：同一セッションでコンテキストを切り替える
同一セッション内でコンテキストを動的に切り替え、異なる作業フェーズに適応できます。
例：開発 + レビューワークフロー
#### ステップ1：機能を実装（devモード）
@contexts/dev.md
ユーザーログイン機能を実装してください。メールパスワード認証をサポートします。
...
#### Claudeが機能を迅速に実装
#### ステップ2：自己レビュー（reviewモード）
@contexts/review.md
先ほど実装したログイン機能のコードをレビューしてください：
...
#### Claudeがレビューモードに切り替わり、コード品質を深く分析
#### 重大度順に問題と改善提案をリストアップ
#### ステップ3：レビュー結果に基づいて改善（devモード）
@contexts/dev.md
上記のレビュー意見に基づいて、CriticalとHighレベルの問題を修正してください。
...
#### Claudeが問題を迅速に修正
#### ステップ4：再度レビュー（reviewモード）
@contexts/review.md
修正後のコードを再度レビューしてください。
...
#### Claudeが問題が解決されたかを検証あなたは以下を見るはずです：
- 異なるフェーズで明確なワークフォーカスがある
- 開発フェーズで迅速な反復
- レビューフェーズで深い分析
- 同一モードでの行動の衝突を回避
ステップ4：カスタムコンテキストを作成する（オプション）
定義済みの3つのモードがニーズを満たさない場合、カスタムコンテキストを作成できます。
コンテキストファイルの形式：
#### My Custom Context
Mode: [モード名]
Focus: [フォーカス]
## Behavior
- 行動ルール1
- 行動ルール2
## Priorities
1. 優先度1
2. 優先度2
## Tools to favor
- 推奨されるツール例：debug.md - デバッグモード
#### Debug Context
Mode: Debugging and troubleshooting
Focus: Root cause analysis and fix
## Behavior
- Start by gathering evidence (logs, error messages, stack traces)
- Form hypothesis before proposing fixes
- Test fixes systematically (control variables)
- Document findings for future reference
## Debug Process
1. Reproduce the issue consistently
2. Gather diagnostic information
3. Narrow down potential causes
4. Test hypotheses
5. Verify the fix works
## Tools to favor
- Read for code inspection
- Bash for running tests and checking logs
- Grep for searching error patternsカスタムコンテキストの使用：
@contexts/debug.md
本番環境でこの問題に遭遇しています：
[エラーメッセージ]
[関連ログ]
デバッグを手伝ってください。チェックポイント ✅
以上のステップを完了すると、以下のことができるはずです：
- [ ] 3つの定義済みコンテキストの動作と使用シーンを理解する
- [ ] ワークシーンに応じて適切なコンテキストを選択できる
- [ ] セッション内でコンテキストを動的に切り替えることができる
- [ ] カスタムコンテキストの作成方法を知っている
- [ ] 異なるコンテキストでのAIの挙動の明らかな違いを体験する
よくある落とし穴
❌ 間違い1：コンテキストを切り替えず、AIの自動適応を期待する
問題：同一セッション内で、開発とレビューを行き来するが、現在の目標をAIに伝えていない。
挙動：Claudeの挙動が混乱し、時には過剰分析し、時には急いでコードを修正する。
正しい方法：
- コンテキストを明確に切り替える：
@contexts/dev.mdまたは@contexts/review.md - 各フェーズの開始時に現在の目標を宣言する
## ステップ X：[目標]でフェーズを明確にする
❌ 間違い2：researchモードで迅速な開発を行う
問題：30分以内に機能を迅速に実装する必要があるのに、@contexts/research.md を使用した。
挙動：Claudeが大量の時間を調査、議論、分析に費やし、なかなかコードを書き始めない。
正しい方法：
- 迅速な開発は
devモード - 深い調査は
researchモード - 時間のプレッシャーとタスクの複雑さに応じてモードを選択する
❌ 間違い3：devモードで重要なコードをレビューする
問題：セキュリティ、金銭、プライバシーに関わる重要なコードをレビューするのに、@contexts/dev.md を使用した。
挙動：Claudeが素早く流し見し、深刻なセキュリティ脆弱性を見落とす可能性がある。
正しい方法：
- 重要なコードレビューは必ず
reviewモード - 通常のPRレビューは
reviewモード - 自己迅速反復の時のみ
devモード
まとめ
動的コンテキスト注入は、現在のワークモードを明確にすることで、AIを異なるシーンで最適化された行動戦略にさせます：
3つの定義済みモード：
- dev：迅速な実装、先に動かしてから改善
- review：深いレビュー、問題を発見し修正を提案
- research：十分な調査、理解してから結論を出す
使用のポイント：
- ワークフェーズに応じてコンテキストを切り替える
@contexts/xxx.mdでコンテキストを明確に読み込む- 同一セッションで複数回切り替えが可能
- カスタムコンテキストを作成して特定のニーズを満たすことができる
コアバリュー：AIの振る舞いの混乱を回避し、異なるフェーズの集中度と効率を向上させる。
次回の予告
次回は**設定ファイル詳細：settings.json 完全リファレンス**を学習します。
学習できること：
- settings.jsonの完全な設定オプション
- Hooks設定のカスタマイズ方法
- MCPサーバーの有効化と無効化の戦略
- プロジェクトレベルとグローバルレベルの設定の優先度
付録：ソースコードリファレンス
クリックしてソースコードの場所を表示
更新日時：2026-01-25
| 機能 | ファイルパス | 行番号 |
|---|---|---|
| devコンテキスト定義 | contexts/dev.md | 1-21 |
| reviewコンテキスト定義 | contexts/review.md | 1-23 |
| researchコンテキスト定義 | contexts/research.md | 1-27 |
主要なコンテキストファイル：
dev.md：開発モードコンテキスト、機能実装を優先review.md：レビューモードコンテキスト、コード品質問題の発見を優先research.md：リサーチモードコンテキスト、問題の深い理解を優先