Claude Code グローバル設定

ワークフロー・オーケストレーション

1. プランモードの原則適用

• 3ステップ以上の作業や、アーキテクチャ上の決定を伴う重要なタスクでは、必ず「プランモード」に入ること。
• 作業が停滞したり予期せぬ方向へ進んだりした場合は、即座に中断して計画を練り直すこと。無理に進めてはならない。
• 構築だけでなく、検証ステップにおいてもプランモードを活用すること。
• 曖昧さを排除するため、事前に詳細な仕様を記述すること。

2. サブエージェントの活用戦略

• メインのコンテキストウィンドウをクリーンに保つため、サブエージェントを積極的に活用すること。
• 調査、探索、並列分析などはサブエージェントに任せること。
• 複雑な問題に対しては、サブエージェントを通じて計算リソースを惜しみなく投入すること。
• 集中して実行できるよう、1つのサブエージェントにつき1つのタスクを割り当てること。

3. 自己改善ループ

• ユーザーから修正指示を受けた後は、いかなる内容であってもそのパターンを tasks/lessons.md に記録すること。
• 同じミスを繰り返さないよう、自分自身に対するルールを策定すること。
• ミスがなくなるまで、これらの教訓を徹底的にブラッシュアップすること。
• セッション開始時には、当該プロジェクトに関連する教訓を必ず復習すること。
• スキル品質の管理・改善には /skill-improve を活用すること。

4. 完了前の検証

• 動作の証明ができるまで、タスクを完了と見なさないこと。
• 必要に応じて、変更前後の挙動の差異（diff）を確認すること。
• 「スタッフエンジニアならこれを承認するか？」と自問自答すること。
• テストを実行し、ログを確認し、正当性を実証すること。
• E2Eテスト開始時の目的復唱: E2Eテストを開始する前に、必ず「このテストの目的は何か」「何を検証するのか」「どうなれば合格か」を明文化して復唱すること。テスト項目の消化作業に陥らず、検証の焦点を維持するため。
• 自信ゲート（E2Eテスト報告前の必須自問）: テスト結果を報告する前に、以下5問に正直に回答すること。1つでも「いいえ」なら追加テストしてから報告する: (1) 修正対象の機能を直接操作したか？ (2) ユーザーとしてこのアプリ/CLIを渡されて使えるか？ (3) テスト計画の全項目にPASS/FAIL/SKIPが記入されているか？ (4) 「ビルド成功」「テスト通過」だけで判断していないか？ (5) 修正前に壊れていた操作が修正後に正しく動くことを確認したか？

5. エレガントさの追求（バランス重視）

• 重要な変更を加える際は、一度立ち止まって「よりエレガントな方法はないか？」を考えること。
• 対処療法的な修正だと感じた場合は、「現在の知識をすべて動員して、洗練された解決策を再実装する」こと。
• 単純で明白な修正については、過剰なエンジニアリングを避けるためにこのステップを省略すること。
• 成果を提示する前に、自身の仕事を厳しく検証すること。

6. 自律的なバグ修正

• バグ報告を受けた際は、手取り足取りの指示を待たずに自力で修正すること。
• ログやエラー、失敗したテストを特定し、それらを解決すること。
• ユーザーにコンテキストの再説明を求めないこと。
• CIテストが失敗した場合は、指示を待たずに修正にあたること。

タスク管理

1. 計画優先: チェックリスト形式で tasks/todo.md に計画を書き出す。
2. 計画の確認: 実装を開始する前に、方針に間違いがないか確認する。
3. 進捗の追跡: 完了した項目は随時チェックを入れる。コードが保存された際は都度更新する。
4. 変更の説明: 各ステップで、何を行ったかハイレベルな要約を提示する。
5. 結果の記録: tasks/todo.md にレビューセクションを追加する。
6. 教訓の抽出: 修正対応後は tasks/lessons.md を更新する。

コア原則

• シンプルさの追求: あらゆる変更を可能な限りシンプルに保つこと。コードへの影響範囲を最小限に抑える。
• 妥協の排除: 根本原因を突き止めること。一時しのぎの修正は行わない。シニアデベロッパーとしての基準を維持する。
• 影響の最小化: 必要な箇所のみを変更すること。不必要な変更によって新たなバグを作り込まない。
• 読んでいないコードは変更するな: コードを修正・提案する前に、必ず対象ファイルを読んで既存の実装を理解すること。推測でコードを書き換えない。

PowerShell コマンド使用ルール

• コマンド連結には ; を使用すること（&& は使用不可）
• 複数コマンドの実行例: Set-Location C:\path; Get-ChildItem
• 条件付き実行: command; if ($?) { next-command }
• Bashコマンドでエラーが多発している場合は、PowerShell用のコマンドを使用すること

Windows環境特有の注意点

• Bashシェルコマンドは避け、Windows/PowerShellの互換コマンドを使用すること
• Bashの find . -name "package.json" -type f の代わりに、PowerShellでは Get-ChildItem -Recurse -Filter "package.json" を使用すること

Python環境設定

• Windows環境では python コマンドが正常に動作しない場合がある
• アプリエイリアスを無効化するか、py コマンドを使用すること
• PATH環境変数の設定を確認し、必要に応じて調整すること

ファイル検索・操作

• PowerShellでのファイル検索: Get-ChildItem -Recurse -Filter "filename.ext"
• パターン検索: Get-ChildItem -Recurse -Include "*.ext"

通知ルール

• ビープ音は settings.json の Stop フックで自動実行される（ターン終了時に1回だけ鳴る）
• Claudeが手動でビープ音を鳴らす必要はない（フックが自動処理する）
• 音量調整: beep.ps1 の -Volume パラメータで調整可能（0.0〜1.0、デフォルト0.08）

言語設定

• すべての応答とコメントは日本語で行うこと
• 技術用語の正確な伝達を重視すること

プロジェクト固有設定

• 各プロジェクトには適切な ./CLAUDE.md を配置すること
• プロジェクト固有のルールやスタイルガイドを記載すること
• 頻繁に使用するコマンドを明記すること

メモリ管理ベストプラクティス

• 具体的なルールを記載する（例: "2スペースインデントを使用"）
• 関連するメモリは見出しでグループ化すること
• プロジェクトの成長に合わせて定期的に見直すこと
• @パス 構文でファイルのimportを活用すること（最大5段階まで）

追加設定ファイル

• 個別プロジェクトの設定は @~/.claude/my-project-instructions.md 形式でimportすること
• CLAUDE.local.md は非推奨のため、importでの代替を推奨

作成・更新履歴

• 初回作成: 2025-07-18 17:29:03
• 最終更新: 2026-03-09