Claude Code の設定

Claude Code をグローバル設定とプロジェクトレベルの設定、および環境変数で構成します。

Claude Code は、ニーズに合わせて動作を構成するためのさまざまな設定を提供しています。インタラクティブ REPL を使用する際に /config コマンドを実行することで Claude Code を構成できます。これにより、ステータス情報を表示し、構成オプションを変更できるタブ付き設定インターフェースが開きます。

構成スコープ

Claude Code は、スコープシステムを使用して、構成がどこに適用され、誰と共有されるかを決定します。スコープを理解することで、個人使用、チーム協力、またはエンタープライズデプロイメント用に Claude Code を構成する方法を決定するのに役立ちます。

利用可能なスコープ

各スコープを使用する場合

Managed スコープは以下の用途です：

• 組織全体で強制する必要があるセキュリティポリシー
• オーバーライドできないコンプライアンス要件
• IT/DevOps により展開される標準化された構成

User スコープは以下の用途に最適です：

• すべての場所で必要な個人設定（テーマ、エディター設定）
• すべてのプロジェクト全体で使用するツールとプラグイン
• API キーと認証（安全に保存）

Project スコープは以下の用途に最適です：

• チーム共有設定（権限、hooks、MCP サーバー）
• チーム全体が持つべきプラグイン
• コラボレーター全体でのツール標準化

Local スコープは以下の用途に最適です：

• 特定のプロジェクトの個人的なオーバーライド
• チームと共有する前に構成をテストする
• 他のユーザーには機能しないマシン固有の設定

スコープの相互作用

同じ設定が複数のスコープで構成されている場合、より具体的なスコープが優先されます：

1. Managed（最高） - 何によってもオーバーライドできない
2. コマンドライン引数 - 一時的なセッションオーバーライド
3. Local - プロジェクトとユーザー設定をオーバーライド
4. Project - ユーザー設定をオーバーライド
5. User（最低） - 他に何も設定を指定しない場合に適用

たとえば、ユーザー設定で権限が許可されているが、プロジェクト設定で拒否されている場合、プロジェクト設定が優先され、権限はブロックされます。

スコープを使用する機能

スコープは多くの Claude Code 機能に適用されます：

Windows では、~/.claude として表示されるパスは %USERPROFILE%\.claude に解決されます。

設定ファイル

settings.json ファイルは、階層的な設定を通じて Claude Code を構成するための公式メカニズムです：

• ユーザー設定は ~/.claude/settings.json で定義され、すべてのプロジェクトに適用されます。

• プロジェクト設定はプロジェクトディレクトリに保存されます：

  • .claude/settings.json ソース管理にチェックインされ、チームと共有される設定用
  • .claude/settings.local.json チェックインされない設定用。個人設定と実験に役立ちます。Claude Code は作成時に .claude/settings.local.json を無視するように git を構成します。

• Managed 設定：集中管理が必要な組織向けに、Claude Code は managed 設定の複数の配信メカニズムをサポートしています。すべて同じ JSON 形式を使用し、ユーザー設定またはプロジェクト設定でオーバーライドできません：

  • サーバー管理設定：Anthropic のサーバーから Claude.ai 管理コンソール経由で配信されます。サーバー管理設定を参照してください。

  • MDM/OS レベルのポリシー：macOS と Windows のネイティブデバイス管理を通じて配信されます：

    • macOS：com.anthropic.claudecode managed preferences ドメイン。plist のトップレベルキーは managed-settings.json をミラーリングし、ネストされた設定は辞書として、配列は plist 配列として機能します。Jamf、Iru（Kandji）、または同様の MDM ツールの構成プロファイルを通じて展開します。
    • Windows：HKLM\SOFTWARE\Policies\ClaudeCode レジストリキーと JSON を含む Settings 値（REG_SZ または REG_EXPAND_SZ）。グループポリシーまたは Intune を通じて展開します
    • Windows（ユーザーレベル）：HKCU\SOFTWARE\Policies\ClaudeCode（最低ポリシー優先度、管理者レベルのソースが存在しない場合のみ使用）

  • ファイルベース：managed-settings.json と managed-mcp.json をシステムディレクトリに展開：

    • macOS：/Library/Application Support/ClaudeCode/
    • Linux と WSL：/etc/claude-code/
    • Windows：C:\Program Files\ClaudeCode\

    ファイルベースの managed 設定は、managed-settings.json と同じシステムディレクトリ内の managed-settings.d/ ドロップインディレクトリもサポートしています。これにより、別々のチームが単一ファイルの編集を調整することなく、独立したポリシーフラグメントを展開できます。

    systemd 規則に従い、managed-settings.json が最初にベースとしてマージされ、その後、ドロップインディレクトリ内のすべての *.json ファイルがアルファベット順にソートされてマージされます。スカラー値の場合、後のファイルが前のファイルをオーバーライドします。配列は連結され、重複排除されます。オブジェクトはディープマージされます。. で始まる隠しファイルは無視されます。

    マージ順序を制御するには、数値プレフィックスを使用します。たとえば、10-telemetry.json と 20-security.json です。

  managed 設定と Managed MCP 構成の詳細を参照してください。

  このリポジトリには、Jamf、Iru（Kandji）、Intune、およびグループポリシー用のスターターデプロイメントテンプレートが含まれています。これらを出発点として使用し、ニーズに合わせて調整してください。

• その他の構成は ~/.claude.json に保存されます。このファイルには、OAuth セッション、MCP サーバーユーザーおよびローカルスコープの構成、プロジェクトごとの状態（許可されたツール、信頼設定）、およびさまざまなキャッシュが含まれます。プロジェクトスコープの MCP サーバーは .mcp.json に別途保存されます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp"
  },
  "companyAnnouncements": [
    "Welcome to Acme Corp! Review our code guidelines at docs.acme.com",
    "Reminder: Code reviews required for all PRs",
    "New security policy in effect"
  ]
}

上記の例の $schema 行は、Claude Code 設定の公式 JSON スキーマを指しています。これを settings.json に追加すると、VS Code、Cursor、および JSON スキーマ検証をサポートする他のエディターでオートコンプリートとインライン検証が有効になります。

公開されたスキーマは定期的に更新され、最新の CLI リリースで追加された設定を含まない場合があるため、最近ドキュメント化されたフィールドの検証警告は、必ずしも構成が無効であることを意味しません。

利用可能な設定

settings.json は多くのオプションをサポートしています：

グローバル構成設定

これらの設定は settings.json ではなく ~/.claude.json に保存されます。これらを settings.json に追加すると、スキーマ検証エラーがトリガーされます。

Worktree 設定

--worktree が git worktrees を作成および管理する方法を構成します。

gitignored ファイル（.env など）を新しい worktrees にコピーするには、設定の代わりにプロジェクトルートの .worktreeinclude ファイルを使用します。

権限設定

権限ルール構文

権限ルールは Tool または Tool(specifier) の形式に従います。ルールは順序で評価されます：最初に拒否ルール、次に ask、次に allow。最初に一致するルールが優先されます。

クイック例：

ワイルドカード動作、Read、Edit、WebFetch、MCP、および Agent ルール用のツール固有パターン、および Bash パターンのセキュリティ制限を含む完全なルール構文リファレンスについては、権限ルール構文を参照してください。

サンドボックス設定

高度なサンドボックス動作を構成します。サンドボックスは bash コマンドをファイルシステムとネットワークから分離します。詳細については サンドボックスを参照してください。

サンドボックスパスプレフィックス

filesystem.allowWrite、filesystem.denyWrite、filesystem.denyRead、および filesystem.allowRead のパスは、これらのプレフィックスをサポートしています：

古い //path プレフィックスは絶対パスに対して引き続き機能します。以前に単一スラッシュ /path を使用してプロジェクト相対解決を期待していた場合は、./path に切り替えてください。この構文は Read および Edit 権限ルールと異なります。これは //path を絶対パスに、/path をプロジェクト相対に使用します。サンドボックスファイルシステムパスは標準的な規則を使用します：/tmp/build は絶対パスです。

構成例：

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker *"],
    "filesystem": {
      "allowWrite": ["/tmp/build", "~/.kube"],
      "denyRead": ["~/.aws/credentials"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"],
      "deniedDomains": ["uploads.github.com"],
      "allowUnixSockets": [
        "/var/run/docker.sock"
      ],
      "allowLocalBinding": true
    }
  }
}

ファイルシステムとネットワーク制限は、一緒にマージされる 2 つの方法で構成できます：

• sandbox.filesystem 設定（上記）：OS レベルのサンドボックス境界でパスを制御します。これらの制限は、Claude のファイルツールだけでなく、すべてのサブプロセスコマンド（例：kubectl、terraform、npm）に適用されます。
• 権限ルール：Edit allow/deny ルールを使用して Claude のファイルツールアクセスを制御し、Read deny ルールを使用して読み取りをブロックし、WebFetch allow/deny ルールを使用してネットワークドメインを制御します。これらのルールからのパスもサンドボックス構成にマージされます。

属性設定

Claude Code は git コミットとプルリクエストに属性を追加します。これらは個別に構成されます：

• コミットはデフォルトでgit トレーラー（Co-Authored-By など）を使用し、カスタマイズまたは無効にできます
• プルリクエストの説明はプレーンテキストです

デフォルトコミット属性：

🤖 Generated with [Claude Code](https://claude.com/claude-code)

   Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

デフォルトプルリクエスト属性：

🤖 Generated with [Claude Code](https://claude.com/claude-code)

例：

{
  "attribution": {
    "commit": "Generated with AI\n\nCo-Authored-By: AI <ai@example.com>",
    "pr": ""
  }
}

ファイル提案設定

@ ファイルパスオートコンプリート用のカスタムコマンドを構成します。組み込みファイル提案は高速ファイルシステムトラバーサルを使用しますが、大規模なモノレポは事前構築されたファイルインデックスやカスタムツールなどのプロジェクト固有のインデックスから利益を得る可能性があります。

{
  "fileSuggestion": {
    "type": "command",
    "command": "~/.claude/file-suggestion.sh"
  }
}

コマンドは hooksと同じ環境変数（CLAUDE_PROJECT_DIR を含む）で実行されます。query フィールドを含む JSON を stdin 経由で受け取ります：

{"query": "src/comp"}

stdout にニューラインで区切られたファイルパスを出力します（現在 15 に制限）：

src/components/Button.tsx
src/components/Modal.tsx
src/components/Form.tsx

例：

#!/bin/bash
query=$(cat | jq -r '.query')
your-repo-file-index --query "$query" | head -20

Hook 構成

これらの設定は、どの hooks が実行を許可されるか、および HTTP hooks がアクセスできるものを制御します。allowManagedHooksOnly 設定は managed 設定でのみ構成できます。URL と環境変数ホワイトリストは任意の設定レベルで設定でき、ソース全体でマージされます。

allowManagedHooksOnly が true の場合の動作：

• Managed hooks と SDK hooks が読み込まれます
• managed 設定 enabledPlugins で強制的に有効にされたプラグインからの Hooks が読み込まれます。これにより、管理者は組織マーケットプレイスを通じて検証済みの hooks を配布しながら、他のすべてをブロックできます。信頼は完全な plugin@marketplace ID によって付与されるため、別のマーケットプレイスからの同じ名前のプラグインはブロックされたままです
• ユーザー hooks、プロジェクト hooks、およびその他すべてのプラグイン hooks はブロックされます

HTTP hook URL を制限：

HTTP hooks がターゲットにできる URL を制限します。マッチングのワイルドカードとして * をサポートします。配列が定義されている場合、一致しない URL をターゲットにする HTTP hooks はサイレントにブロックされます。ホスト名マッチングは大文字と小文字を区別せず、末尾の FQDN ドットを無視し、DNS セマンティクスに一致します。

{
  "allowedHttpHookUrls": ["https://hooks.example.com/*", "http://localhost:*"]
}

HTTP hook 環境変数を制限：

HTTP hooks がヘッダー値に補間できる環境変数名を制限します。各 hook の有効な allowedEnvVars はこの設定との交差です。

{
  "httpHookAllowedEnvVars": ["MY_TOKEN", "HOOK_SECRET"]
}

ポリシーヘルパーで managed 設定を計算

policyHelper 設定は、起動時に managed 設定を動的に計算する実行可能ファイルを指しています。管理者は、静的ファイルの代わりに、デバイスの状態、ID、またはリモートサービスからポリシーを導出できます。MDM またはシステム managed-settings.json ファイルから構成します。Claude Code は、ユーザー設定、プロジェクト設定、HKCU レジストリハイブ、および サーバー管理設定を含む他のスコープに表示される policyHelper を無視します。

設定は以下のキーを受け入れます：

ヘルパーは JSON エンベロープを stdout に書き込みます。設定をトップレベルではなく managedSettings キーの下に配置します。ベアの設定オブジェクトは managedSettings が未定義で解析され、何も適用されないためです：

{
  "managedSettings": {
    "permissions": { "deny": ["Read(//etc/secrets/**)"] }
  },
  "claudeMd": "# Organization context\n...",
  "appendSystemPrompt": "Always cite the internal style guide."
}

ヘルパーが managedSettings を出力すると、そのオブジェクトは実行のためにファイルベースの managed 設定を置き換えます。ヘルパーが起動時にゼロ以外で終了すると、Claude Code はエラーを出力し、起動を拒否します。そのため、停止復旧が必要なヘルパーは独自のキャッシュから提供し、0 で終了する必要があります。

設定の優先度

設定は優先度の順に適用されます。最高から最低：

1. Managed 設定（サーバー管理、MDM/OS レベルのポリシー、または managed 設定）

   • IT がサーバー配信、MDM 構成プロファイル、レジストリポリシー、または managed 設定ファイルを通じて展開するポリシー
   • コマンドラインの引数を含む他のレベルでオーバーライドできません
   • managed ティア内では、優先度は：サーバー管理 > MDM/OS レベルのポリシー > ファイルベース（managed-settings.d/*.json + managed-settings.json）> HKCU レジストリ（Windows のみ）です。1 つの managed ソースのみが使用されます。ソースはマージされません。ファイルベースティア内では、ドロップインファイルとベースファイルがマージされます。

2. コマンドラインの引数

   • 特定のセッションの一時的なオーバーライド。JSON は --settings <file-or-json> を通じて渡され、ファイルベース設定と同じルールを使用して他のレイヤーとマージされます：ここで設定されたキーはローカル、プロジェクト、またはユーザー設定の同じキーをオーバーライドし、キーを省略すると下位レイヤーの値が保持されます

3. ローカルプロジェクト設定（.claude/settings.local.json）

   • 個人的なプロジェクト固有の設定

4. 共有プロジェクト設定（.claude/settings.json）

   • ソース管理内のチーム共有プロジェクト設定

5. ユーザー設定（~/.claude/settings.json）

   • 個人的なグローバル設定

この階層は、組織のポリシーが常に強制されながら、チームと個人がエクスペリエンスをカスタマイズできることを保証します。同じ優先度は、CLI から Claude Code を実行する場合、VS Code 拡張機能から実行する場合、または JetBrains IDEから実行する場合に適用されます。

たとえば、ユーザー設定が Bash(npm run *) を許可しているが、プロジェクトの共有設定がそれを拒否している場合、プロジェクト設定が優先され、コマンドはブロックされます。

アクティブな設定を確認

Claude Code 内で /status を実行して、どの設定ソースがアクティブで、どこから来ているかを確認します。出力は、Enterprise managed settings (remote)、Enterprise managed settings (plist)、Enterprise managed settings (HKLM)、Enterprise managed settings (HKCU)、または Enterprise managed settings (file) などの出所を含む各構成レイヤー（managed、ユーザー、プロジェクト）を表示します。設定ファイルにエラーが含まれている場合、/status は問題を報告して修正できるようにします。

構成システムの重要なポイント

• メモリファイル（CLAUDE.md）：Claude が起動時に読み込む命令とコンテキストを含みます
• 設定ファイル（JSON）：権限、環境変数、およびツール動作を構成します
• Skills：/skill-name で呼び出すか、Claude によって自動的に読み込むことができるカスタムプロンプト
• MCP サーバー：追加のツールと統合で Claude Code を拡張します
• 優先度：高レベルの構成（Managed）が低レベルの構成（User/Project）をオーバーライドします
• 継承：設定はマージされ、より具体的な設定がより広い設定に追加またはオーバーライドされます

システムプロンプト

Claude Code の内部システムプロンプトは公開されていません。カスタム命令を追加するには、CLAUDE.md ファイルまたは --append-system-prompt フラグを使用します。

機密ファイルを除外

API キー、シークレット、環境ファイルなどの機密情報を含むファイルへの Claude Code アクセスを防ぐには、.claude/settings.json ファイルの permissions.deny 設定を使用します：

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./build)"
    ]
  }
}

これは非推奨の ignorePatterns 構成に置き換わります。これらのパターンに一致するファイルはファイル検出と検索結果から除外され、これらのファイルの読み取り操作は拒否されます。

Subagent 構成

Claude Code は、ユーザーレベルとプロジェクトレベルの両方で構成できるカスタム AI subagents をサポートしています。これらの subagents は YAML frontmatter を含む Markdown ファイルとして保存されます：

• ユーザー subagents：~/.claude/agents/ - すべてのプロジェクト全体で利用可能
• プロジェクト subagents：.claude/agents/ - プロジェクト固有で、チームと共有できます

Subagent ファイルは、カスタムプロンプトとツール権限を持つ特殊な AI アシスタントを定義します。subagents ドキュメントで subagents の作成と使用について詳しく学びます。

プラグイン構成

Claude Code は、skills、agents、hooks、および MCP サーバーで機能を拡張できるプラグインシステムをサポートしています。プラグインはマーケットプレイスを通じて配布され、ユーザーレベルとリポジトリレベルの両方で構成できます。

プラグイン設定

settings.json のプラグイン関連設定：

{
  "enabledPlugins": {
    "formatter@acme-tools": true,
    "deployer@acme-tools": true,
    "analyzer@security-plugins": false
  },
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/claude-plugins"
      }
    }
  }
}

enabledPlugins

どのプラグインが有効かを制御します。形式："plugin-name@marketplace-name": true/false

スコープ：

• ユーザー設定（~/.claude/settings.json）：個人的なプラグイン設定
• プロジェクト設定（.claude/settings.json）：チームと共有されるプロジェクト固有のプラグイン
• ローカル設定（.claude/settings.local.json）：マシンごとのオーバーライド（コミットされない）
• Managed 設定（managed-settings.json）：すべてのスコープでのインストールをブロックし、マーケットプレイスからプラグインを非表示にする組織全体のポリシーオーバーライド

例：

{
  "enabledPlugins": {
    "code-formatter@team-tools": true,
    "deployment-tools@team-tools": true,
    "experimental-features@personal": false
  }
}

extraKnownMarketplaces

リポジトリで利用可能にする必要がある追加のマーケットプレイスを定義します。通常、リポジトリレベルの設定で使用され、チームメンバーが必要なプラグインソースにアクセスできることを確認します。

リポジトリが extraKnownMarketplaces を含む場合：

1. チームメンバーはフォルダを信頼するときにマーケットプレイスをインストールするよう求められます
2. チームメンバーはそのマーケットプレイスからプラグインをインストールするよう求められます
3. ユーザーは不要なマーケットプレイスまたはプラグインをスキップできます（ユーザー設定に保存）
4. インストールは信頼境界を尊重し、明示的な同意が必要です

例：

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/claude-plugins"
      }
    },
    "security-plugins": {
      "source": {
        "source": "git",
        "url": "https://git.example.com/security/plugins.git"
      }
    }
  }
}

マーケットプレイスソースタイプ：

• github：GitHub リポジトリ（repo を使用）
• git：任意の git URL（url を使用）
• directory：ローカルファイルシステムパス（開発のみ、path を使用）
• hostPattern：マーケットプレイスホストに一致する正規表現パターン（hostPattern を使用）
• settings：ホストされたリポジトリなしで settings.json に直接宣言されたインラインマーケットプレイス（name と plugins を使用）

source: 'settings' を使用して、ホストされたマーケットプレイスリポジトリをセットアップせずに、小規模なプラグインセットをインラインで宣言します。ここにリストされているプラグインは、GitHub または npm などの外部ソースを参照する必要があります。各プラグインを enabledPlugins で個別に有効にする必要があります。

{
  "extraKnownMarketplaces": {
    "team-tools": {
      "source": {
        "source": "settings",
        "name": "team-tools",
        "plugins": [
          {
            "name": "code-formatter",
            "source": {
              "source": "github",
              "repo": "acme-corp/code-formatter"
            }
          }
        ]
      }
    }
  }
}

strictKnownMarketplaces

Managed 設定のみ：ユーザーが追加できるプラグインマーケットプレイスを制御します。この設定は managed 設定でのみ構成でき、管理者にマーケットプレイスソースに対する厳密な制御を提供します。

Managed 設定ファイルの場所：

• macOS：/Library/Application Support/ClaudeCode/managed-settings.json
• Linux と WSL：/etc/claude-code/managed-settings.json
• Windows：C:\Program Files\ClaudeCode\managed-settings.json

主な特性：

• managed 設定（managed-settings.json）でのみ利用可能
• ユーザーまたはプロジェクト設定でオーバーライドできません（最高優先度）
• ネットワーク/ファイルシステム操作の前に強制されます（ブロックされたソースは実行されません）
• hostPattern と pathPattern を除き、ソース仕様に対して完全一致を使用します。hostPattern と pathPattern は正規表現マッチングを使用します

ホワイトリスト動作：

• undefined（デフォルト）：制限なし - ユーザーは任意のマーケットプレイスを追加できます
• 空配列 []：完全ロックダウン - ユーザーは新しいマーケットプレイスを追加できません
• ソースのリスト：ユーザーは正確に一致するマーケットプレイスのみを追加できます

サポートされているすべてのソースタイプ：

ホワイトリストは複数のマーケットプレイスソースタイプをサポートしています。ほとんどのソースは完全一致を使用しますが、hostPattern と pathPattern はそれぞれマーケットプレイスホストとファイルシステムパスに対して正規表現マッチングを使用します。

1. GitHub リポジトリ：

{ "source": "github", "repo": "acme-corp/approved-plugins" }
{ "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" }
{ "source": "github", "repo": "acme-corp/plugins", "ref": "main", "path": "marketplace" }

フィールド：repo（必須）、ref（オプション：ブランチ/タグ/SHA）、path（オプション：サブディレクトリ）

2. Git リポジトリ：

{ "source": "git", "url": "https://gitlab.example.com/tools/plugins.git" }
{ "source": "git", "url": "https://bitbucket.org/acme-corp/plugins.git", "ref": "production" }
{ "source": "git", "url": "ssh://git@git.example.com/plugins.git", "ref": "v3.1", "path": "approved" }

フィールド：url（必須）、ref（オプション：ブランチ/タグ/SHA）、path（オプション：サブディレクトリ）

3. URL ベースのマーケットプレイス：

{ "source": "url", "url": "https://plugins.example.com/marketplace.json" }
{ "source": "url", "url": "https://cdn.example.com/marketplace.json", "headers": { "Authorization": "Bearer ${TOKEN}" } }

フィールド：url（必須）、headers（オプション：認証アクセス用の HTTP ヘッダー）

4. NPM パッケージ：

{ "source": "npm", "package": "@acme-corp/claude-plugins" }
{ "source": "npm", "package": "@acme-corp/approved-marketplace" }

フィールド：package（必須、スコープ付きパッケージをサポート）

5. ファイルパス：

{ "source": "file", "path": "/usr/local/share/claude/acme-marketplace.json" }
{ "source": "file", "path": "/opt/acme-corp/plugins/marketplace.json" }

フィールド：path（必須：marketplace.json ファイルへの絶対パス）

6. ディレクトリパス：

{ "source": "directory", "path": "/usr/local/share/claude/acme-plugins" }
{ "source": "directory", "path": "/opt/acme-corp/approved-marketplaces" }

フィールド：path（必須：.claude-plugin/marketplace.json を含むディレクトリへの絶対パス）

7. ホストパターンマッチング：

{ "source": "hostPattern", "hostPattern": "^github\\.example\\.com$" }
{ "source": "hostPattern", "hostPattern": "^gitlab\\.internal\\.example\\.com$" }

フィールド：hostPattern（必須：マーケットプレイスホストに対してマッチする正規表現パターン）

各リポジトリを列挙することなく、特定のホストからすべてのマーケットプレイスを許可する場合は、ホストパターンマッチングを使用します。これは、開発者が独自のマーケットプレイスを作成する内部 GitHub Enterprise または GitLab サーバーを持つ組織に役立ちます。

ソースタイプ別のホスト抽出：

• github：常に github.com に対してマッチ
• git：URL からホスト名を抽出（HTTPS と SSH 形式の両方をサポート）
• url：URL からホスト名を抽出
• npm、file、directory：ホストパターンマッチングではサポートされていません

8. パスパターンマッチング：

{ "source": "pathPattern", "pathPattern": "^/opt/approved/" }
{ "source": "pathPattern", "pathPattern": ".*" }

フィールド：pathPattern（必須：file および directory ソースの path フィールドに対してマッチする正規表現パターン）

ネットワークソースの hostPattern 制限と並行して、ファイルシステムベースのマーケットプレイスを許可するには、パスパターンマッチングを使用します。すべてのローカルパスを許可するには ".*" を設定するか、特定のディレクトリに制限するにはより狭いパターンを設定します。

構成例：

例：特定のマーケットプレイスのみを許可：

{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "acme-corp/approved-plugins"
    },
    {
      "source": "github",
      "repo": "acme-corp/security-tools",
      "ref": "v2.0"
    },
    {
      "source": "url",
      "url": "https://plugins.example.com/marketplace.json"
    },
    {
      "source": "npm",
      "package": "@acme-corp/compliance-plugins"
    }
  ]
}

例 - すべてのマーケットプレイス追加を無効にする：

{
  "strictKnownMarketplaces": []
}

例：内部 git サーバーからすべてのマーケットプレイスを許可：

{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    }
  ]
}

完全一致要件：

マーケットプレイスソースはユーザーの追加を許可するために正確に一致する必要があります。git ベースのソース（github と git）の場合、これはすべてのオプションフィールドを含みます：

• repo または url は正確に一致する必要があります
• ref フィールドは正確に一致する必要があります（または両方が未定義）
• path フィールドは正確に一致する必要があります（または両方が未定義）

一致しないソースの例：

// これらは異なるソースです：
{ "source": "github", "repo": "acme-corp/plugins" }
{ "source": "github", "repo": "acme-corp/plugins", "ref": "main" }

// これらも異なります：
{ "source": "github", "repo": "acme-corp/plugins", "path": "marketplace" }
{ "source": "github", "repo": "acme-corp/plugins" }

extraKnownMarketplaces との比較：

形式の違い：

strictKnownMarketplaces は直接ソースオブジェクトを使用します：

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/plugins" }
  ]
}

extraKnownMarketplaces は名前付きマーケットプレイスが必要です：

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/plugins" }
    }
  }
}

両方を一緒に使用：

strictKnownMarketplaces はポリシーゲートです：ユーザーが追加できるものを制御しますが、マーケットプレイスを登録しません。マーケットプレイスを制限して事前登録するには、managed-settings.json で両方を設定します：

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/plugins" }
  ],
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/plugins" }
    }
  }
}

strictKnownMarketplaces のみが設定されている場合、ユーザーは /plugin marketplace add を通じて許可されたマーケットプレイスを手動で追加できますが、自動的には利用できません。

重要な注意：

• 制限はネットワークリクエストまたはファイルシステム操作の前にチェックされます
• ブロックされた場合、ユーザーはソースが managed ポリシーでブロックされていることを示す明確なエラーメッセージを表示します
• 制限はマーケットプレイスの追加およびプラグインのインストール、更新、リフレッシュ、および自動更新に対して強制されます。ポリシーが設定される前に追加されたマーケットプレイスは、そのソースがホワイトリストと一致しなくなると、プラグインのインストールまたは更新に使用できません
• Managed 設定は最高優先度を持ち、オーバーライドできません

ユーザー向けドキュメントについては、Managed マーケットプレイス制限を参照してください。

プラグインの管理

/plugin コマンドを使用してプラグインを対話的に管理します：

• マーケットプレイスから利用可能なプラグインを参照
• プラグインをインストール/アンインストール
• プラグインを有効/無効にする
• プラグインの詳細を表示（提供される skills、agents、hooks）
• マーケットプレイスを追加/削除

プラグインドキュメントでプラグインシステムについて詳しく学びます。

環境変数

環境変数を使用すると、設定ファイルを編集することなく Claude Code の動作を制御できます。任意の変数は、すべてのセッションに適用するか、チームにロールアウトするために settings.json の env キーで構成することもできます。

完全なリストについては、環境変数リファレンスを参照してください。

Claude が利用できるツール

Claude Code は、ファイルの読み取り、編集、検索、コマンド実行、および subagents のオーケストレーション用のツールセットにアクセスできます。ツール名は、権限ルールと hook マッチャーで使用する正確な文字列です。

完全なリストと Bash ツール動作の詳細については、ツールリファレンスを参照してください。

関連項目

• 権限：権限システム、ルール構文、ツール固有パターン、および managed ポリシー
• 認証：Claude Code へのユーザーアクセスをセットアップ
• 設定をデバッグする：設定、hook、または MCP サーバーが有効にならない理由を診断
• インストールとログインのトラブルシューティング：インストール、認証、およびプラットフォームの問題