背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. これは一言でいうと何か

Claude Code は、プロジェクト内の .claude/ とホームディレクトリの ~/.claude から、指示・設定・スキル・サブエージェント・メモリを読み込みます。前者は git にコミットしてチームで共有し、後者は全プロジェクトに効く個人設定です。

このページは新機能の解説ではなく、置き場所の地図です。ここまでの連載で扱った CLAUDE.md（第4回）、スキル（第6回）、フック（第7回）、MCP（第8回）、サブエージェント（第9回）が、ファイルシステム上のどこに座るのかを一望できます。

安心材料も明記されています。ほとんどのユーザーが編集するのは CLAUDE.md と settings.json だけで、残りのディレクトリはすべてオプションです。必要になったときに skills や rules、agents を足せば足ります。

なお Windows では ~/.claude は %USERPROFILE%\.claude に解決されます。CLAUDE_CONFIG_DIR を設定している場合は、以降のパスがすべてそのディレクトリ配下になります。

2. どういう場面で役立つか

• 「これはどこに書くんだったか」で迷ったとき：ページには目的別の対応表があります。たとえば「ツール呼び出しの前後にスクリプトを実行する」なら settings.json の hooks、「/name で呼ぶプロンプトを追加する」なら skills/<name>/SKILL.md、「MCP で外部ツールを繋ぐ」なら .mcp.json（プロジェクトのみ）、といった具合です。
• チーム共有の線引きを決めるとき：どのファイルがコミット対象かがバッジで示されます。settings.local.json は自動的に gitignore され、個人的なオーバーライド用です。
• プロジェクトルート直下に置くものを間違えないため：.mcp.json と .worktreeinclude は .claude/ の中ではなくプロジェクトルートに置きます。CLAUDE.md も同様（ただし .claude/CLAUDE.md でも動きます）。
• リポジトリを畳むとき・環境を整理したいとき：~/.claude にはトランスクリプトや履歴といったアプリケーションデータも溜まります。後述の claude project purge で特定プロジェクト分だけ消せます。

あまり気にしなくてよいこと。 ディレクトリを最初から全部作る必要はありません。また、~/.claude 配下の多くは Claude Code が自動生成するもので、agent-memory/ や projects/<project>/memory/ は自分では書きません。触るのは設定系のファイルだけ、と割り切って構いません。

3. コード・コマンドの実例と解説

前提条件

• プロジェクトスコープのファイルはリポジトリの .claude/ 配下（CLAUDE.md・.mcp.json・.worktreeinclude はルート）、グローバルスコープは ~/.claude/ 配下です。
• 優先順位に注意してください。 組織が配る管理設定（managed-settings.json）がすべてに優先し、--permission-mode や --settings などの CLI フラグはそのセッションの settings.json を上書きします。環境変数が同等の設定に優先するケースもあります。

プロジェクトの settings.json

{
  "permissions": {
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  },
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
      }]
    }]
  }
}

npm test と npm run を確認なしで許可し、rm -rf を拒否し、編集・書き込みの後に Prettier を走らせる例です。ここが CLAUDE.md との決定的な違いで、CLAUDE.md が「Claude が読むガイダンス」なのに対し、settings.json は Claude が従うかどうかに関係なく強制されます。Bash のパターンはワイルドカードを取り、Bash(npm test *) は npm test で始まる任意のコマンドに一致します。

配列の設定（permissions.allow など）は全スコープで合算され、スカラーの設定（model など）は最も具体的な値が使われます。

個人用のオーバーライド

{
  "permissions": {
    "allow": [
      "Bash(docker *)"
    ]
  }
}

.claude/settings.local.json に置きます。チームの settings.json に Docker 権限を足す例です。Claude Code はこのファイルを初めて書いたとき ~/.config/git/ignore に追加します。カスタムの core.excludesFile を使っているなら、そちらにもパターンを足してください。

パスで絞ったルール

---
paths:
  - "**/*.test.ts"
  - "**/*.test.tsx"
---

# Testing Rules

- Use descriptive test names: "should [expected] when [condition]"
- Mock external dependencies, not internal modules
- Clean up side effects in afterEach

.claude/rules/testing.md に置きます。paths: があるルールは一致するファイルがコンテキストに入ったときだけ読み込まれ、paths: がなければセッション開始時に CLAUDE.md 同様に読み込まれます。サブディレクトリ（.claude/rules/frontend/react.md など）も自動で発見されます。目安は明快で、CLAUDE.md が 200 行に近づいたら rules への分割を始めることです。

worktree に持ち込むファイルを指定する

# Local environment
.env
.env.local

# API credentials
config/secrets.json

プロジェクトルートの .worktreeinclude です。worktree はまっさらなチェックアウトなので、.env のような追跡外ファイルは既定では存在しません。ここに書いたパターン（.gitignore 構文）に一致し、かつ gitignore されているファイルだけがコピーされます。追跡済みファイルが二重になることはありません。

出力スタイルで挙動を変える

---
description: Explains reasoning and asks you to implement small pieces
keep-coding-instructions: true
---

After completing each task, add a brief "Why this approach" note
explaining the key design decision.

When a change is under 10 lines, ask the user to implement it
themselves by leaving a TODO(human) marker instead of writing it.

~/.claude/output-styles/teaching.md に置く例です。出力スタイルはシステムプロンプトに追記されるセクションで、既定では組み込みのソフトウェアエンジニアリング用タスク指示を落とします。上の例のように keep-coding-instructions: true を書けば、既定の指示を残したまま追記できます。反映は次のセッションからです（システムプロンプトは起動時に固定されるため）。

プロジェクトのローカルデータを消す

claude project purge ~/work/my-repo --dry-run

トランスクリプト、自動メモリ、タスクやデバッグ、history.jsonl の該当行、~/.claude.json のプロジェクトエントリをまとめて削除します（v2.1.124 以降）。--dry-run は削除計画の確認だけを行います。実行時は完全な削除計画を提示して確認を求めます（--yes で省略可、--all で全プロジェクト）。

その他（~/.claude.json のアプリ状態、keybindings.json、themes/、workflows/、agent-memory/、自動メモリの projects/<project>/memory/、コミットされないファイルの全一覧、アプリケーションデータの保持期間と cleanupPeriodDays）は公式ドキュメントを参照してください。

4. まとめと次回予告

• 読み込み元は2か所。プロジェクトの .claude/（チーム共有）と ~/.claude/（個人・全プロジェクト）。
• 最初に触るのは CLAUDE.md と settings.json だけで十分。残りは必要になってから足します。
• CLAUDE.md は「読ませるガイダンス」、settings.json の permissions と hooks は「強制される設定」。この線引きが全体の背骨です。

知っておくべき事実がひとつあります。トランスクリプトと履歴は暗号化されません。 ツールを通ったものはすべてディスク上のトランスクリプトに記録されます。ファイルの内容、コマンド出力、貼り付けたテキストまでです。守っているのは OS のファイルパーミッションだけなので、ツールが .env を読んだり、コマンドが認証情報を出力したりすれば、その値は projects/<project>/<session>.jsonl に書き込まれます。

露出を減らす手段は3つ挙げられています。cleanupPeriodDays を短くして保持期間を縮める、CLAUDE_CODE_SKIP_PROMPT_HISTORY を設定してトランスクリプトとプロンプト履歴の書き込み自体をスキップする、権限ルールで認証情報ファイルの読み取りを拒否する、です。

最後に削除してはいけないものを。~/.claude.json、~/.claude/settings.json、~/.claude/plugins/ は消さないでください。 それぞれ認証、設定、インストール済みプラグインを保持しています。

次回予告：連載の締めくくりとして、実務での使い方をまとめた「ベストプラクティス」を取り上げる予定です。

関連ページ（本記事で触れた概念の詳細）：CLAUDE.md と rules、自動メモリ →「メモリ」、permissions と hooks →「権限」「Hooks」、skills/ →「Skills」、agents/ →「サブエージェント」、.mcp.json →「MCP」、output-styles/ →「出力スタイル」、.worktreeinclude →「worktree」、設定が効かないときの診断 →「設定をデバッグする」、組織による強制 →「サーバー管理設定」。

---

本記事は執筆時点の公式ドキュメント（.claude ディレクトリを探索する）に基づきます。最新は公式ドキュメントをご確認ください。