「.claudeignore」は公式に存在しない — Claude Code でファイル除外する正解の方法【2026完全ガイド】

エンジニアのゆとです。

Claude Code を使い始めて「.claudeignore というファイルで秘密を守れるはず」と思って探した経験、ありませんか。.gitignore の Claude 版があるはずだと、.env や secrets/ をそこに書こうとして、そんなファイルは公式に存在しない ことに気づいて困惑する。これは僕も経験した。

実は .claudeignore は Anthropic 公式機能として存在しません。

これは「まだ実装されていない」レベルの話じゃない。Claude 自身が「.claudeignore というファイルがある」と幻覚で答えてしまうケースが多発 していて、2026年1月には The Register が報道 するほどの問題になっている。

この記事では:

• なぜ .claudeignore を「あると思ってしまう人」が多いのか
• Claude Code で実際にファイル読み込みを制御する 公式の正解
• コミュニティ実装の .claudeignore パッケージ (claude-ignore)
• 用途別の最適な選択肢

を 2026年5月版の公式ドキュメント（code.claude.com/docs）ベースで整理する。

なぜ「.claudeignore があるはず」と思ってしまうのか

3つの理由がある。

理由1: Claude 自身が「ある」と言う

Claude Code に「秘密ファイルを除外したい」と頼むと、Claude は .claudeignore というファイルを作成する提案をしてくる ことがある。これは Claude の幻覚（ハルシネーション）で、実際にはそのファイルを Claude Code 本体が読み込むロジックは存在しない。

The Register の調査によれば、開発者の多くが「Claude が .claudeignore を作るよう案内したので、.env を書いておけば安全だと思っていた」と回答。実際には .env の中身を Claude Code は読み取って context に展開していた。これがセキュリティ事故になりかけた事例として報道された。

理由2: .gitignore、.dockerignore、.npmignore などの命名習慣

Git、Docker、npm にはツール固有の ignore ファイルがある。同じ命名規則で Claude Code にも .claudeignore があると 自然に推測してしまう。Anthropic は公式 issue (anthropics/claude-code#29455) で「.claudeignore を実装するか」を議論中だが、2026年5月時点で マージされていない。

理由3: AI 関連のブログ記事が .claudeignore を「公式機能」のように紹介していた

検索すると .claudeignore の書き方を解説する個人ブログがヒットする。これらの多くは「Claude が幻覚で生成したコード例」をそのまま転載しているため、事実と異なる情報 が大量に流通している。Daily DevOps ブログの “.claudeignore Doesn’t Exist. Here’s What Does.” のような検証記事も出てきている。

公式の正解: .claude/settings.json の permissions.deny

Claude Code で ファイル読み込みを実際にブロックする唯一の公式メカニズム は、.claude/settings.json の permissions.deny ルール。

基本構文

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.aws/credentials)",
      "Read(~/.ssh/**)"
    ]
  }
}

これで以下のファイル/ディレクトリへの Read ツール経由のアクセスが拒否 される:

• .env ファイル
• .env.production などの派生
• secrets/ ディレクトリ配下全体
• ホームディレクトリの AWS クレデンシャル
• SSH 鍵

deny ルールの評価順序

Claude Code の permissions ルールは以下の順序で評価される:

1. deny ルール — マッチしたら即座に拒否（最優先）
2. ask ルール — マッチしたら確認プロンプトを表示
3. allow ルール — マッチしたら許可

最初にマッチしたルールが優先される。deny ルールに書かれたパスは、他の allow ルールがあっても確実に拒否される。

サポートされる glob パターン

パターン	マッチ対象	例
Read(./.env)	プロジェクトルートの単一ファイル	.env
Read(./.env.*)	ワイルドカード（直下のみ）	.env.local, .env.production
Read(./secrets/**)	recursive glob（サブディレクトリ含む）	secrets/a.json, secrets/sub/b.json
Read(/absolute/path)	絶対パス	/etc/passwd
Read(~/.aws/credentials)	ホームディレクトリ相対	$HOME/.aws/credentials

Edit と Write もブロック対象

deny ルールは Read だけでなく、Edit と Write もブロックできる。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Edit(./.env)",
      "Edit(./.env.*)",
      "Write(./.env)",
      "Bash(cat .env)",
      "Bash(cat .env.*)",
      "Bash(grep * .env)"
    ]
  }
}

特に Bash コマンド経由のシークレット参照 はうっかり漏れになりやすいので、Bash(cat .env*) も deny に入れておくのが安全。

settings.json の階層と優先順位

Claude Code の settings.json は 5層構造:

スコープ	場所	git管理	優先順位
Managed Policy	システムレベル	組織管理	1（最高）
Command line	CLI 引数	-	2
Local	.claude/settings.local.json	×（gitignore推奨）	3
Project	.claude/settings.json	◯（チーム共有）	4
User	~/.claude/settings.json	-	5（最低）

シークレットの deny 設定は通常 Project レベル (.claude/settings.json) に書く。チーム全員に共有される。個人的な設定は .claude/settings.local.json に書いて .gitignore に入れる。

Managed Policy レベルで組織管理者が deny を強制すると、ユーザー側で上書きできない。allowManagedPermissionRulesOnly: true で完全強制も可能。

実例: フリーランスエンジニアの最小限デザイン

クライアント案件で使い回せる最小限の .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./.envrc)",
      "Read(./config/secrets.yml)",
      "Read(./config/credentials.yml.enc)",
      "Read(./config/master.key)",
      "Read(./secrets/**)",
      "Read(~/.aws/credentials)",
      "Read(~/.aws/config)",
      "Read(~/.ssh/id_rsa)",
      "Read(~/.ssh/id_ed25519)",
      "Read(~/.npmrc)",
      "Read(~/.pypirc)",
      "Read(~/.gitconfig)",
      "Edit(./.env)",
      "Edit(./.env.*)",
      "Edit(./config/secrets.yml)",
      "Bash(cat .env*)",
      "Bash(cat ~/.aws/*)",
      "Bash(cat ~/.ssh/*)",
      "Bash(curl * --header *Authorization*)",
      "WebFetch(domain:*.amazonaws.com)",
      "WebFetch(domain:*.googleapis.com)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Edit(./prod/**)"
    ]
  }
}

これを .claude/settings.json としてプロジェクトルートに置き、git に commit する。チーム全員が同じ deny ルールを使えるようになる。

コミュニティ実装の .claudeignore (claude-ignore パッケージ)

「公式機能は存在しないが、.claudeignore の使い勝手は欲しい」という需要に応える形で、li-zhixin/claude-ignore という npm パッケージがコミュニティで作られている。

これは Claude Code の PreToolUse hook として動作し、.claudeignore ファイルを読み込んで該当パターンへの Read を block する仕組み。

インストールと初期化

# npm でグローバルインストール
npm install -g claude-ignore

# プロジェクトで初期化
cd your-project
claude-ignore init

init を実行すると以下が自動生成される:

• .claudeignore — gitignore スタイルのパターンを書くファイル
• .claude/settings.json — claude-ignore hook を呼び出す設定

.claudeignore の書き方

.gitignore と同じシンタックス:

# .claudeignore
.env
.env.*
secrets/
config/credentials.yml.enc

# コメントは # で始まる
*.secret

settings.json での hook 登録

claude-ignore init が以下を自動的に追加する:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read",
        "hooks": [
          {
            "type": "command",
            "command": "claude-ignore"
          }
        ]
      }
    ]
  }
}

これで Read ツールが呼ばれるたびに claude-ignore コマンドが実行され、.claudeignore のパターンに一致するファイルアクセスを block する。

階層的サポート

claude-ignore は カレントディレクトリからルートまで遡って .claudeignore を検索 する。.gitignore と同じ階層的な振る舞いになる。サブディレクトリで個別のルールを定義可能。

公式の permissions.deny vs コミュニティの claude-ignore

観点	permissions.deny (公式)	claude-ignore (コミュニティ)
公式サポート	◎	×
設定ファイル	.claude/settings.json (JSON)	.claudeignore (gitignore syntax)
書きやすさ	△ JSON で冗長	◎ gitignore 知ってる人は即習得
階層的ルール	✗ プロジェクトルート単位	◎ ディレクトリごと
Bash コマンド経由のブロック	◎	✗（Read tool のみ）
Edit/Write のブロック	◎	✗
WebFetch のブロック	◎	✗
インストール	不要（Claude Code 標準）	npm パッケージ
安定性	◎ 公式メンテナンス	△ 個人開発者依存

結論: セキュリティ重視なら permissions.deny が優位。claude-ignore は「.gitignore 感覚で書きたい」「階層的にルールを管理したい」というスタイルの好み次第。

両方併用も可能だが、公式の permissions.deny を必須にして、補助的に claude-ignore を使う のが堅い構成。

The Register 報道 (2026-01-28) の概要

Claude Code ignores ignore rules meant to block secrets

The Register が報じた事案:

• セキュリティ研究者が、.claudeignore が存在すると 誤って認識した開発者が .env を書いていた
• Claude Code は .claudeignore を読まないので、当然 .env を Read してしまった
• API キーや認証情報が Claude のセッションコンテキストに展開された
• 後で git diff を取ったところ、シークレットが Claude 経由で外部 SaaS にも触れていたケースが複数発覚

Anthropic はこれを受けて、「公式の正解は permissions.deny であり、.claudeignore は実装されていない」と明示的に発表。/init コマンドが生成する .claude/settings.json のテンプレートにも Read(./.env) 等の deny ルールがデフォルト追加された。

用途別の選択肢まとめ

ケース1: クライアント案件で機密情報を扱う

→ permissions.deny で .env, secrets/**, クラウドクレデンシャルを全て deny。チーム共有のため .claude/settings.json に commit。

ケース2: 個人プロジェクトで気軽に運用したい

→ claude-ignore パッケージ で .claudeignore を書く。階層的ルールで柔軟性高い。

ケース3: 大企業の組織レベルで強制したい

→ Managed Policy レベル の settings.json を IT 部門が配布。allowManagedPermissionRulesOnly: true で個別ユーザーによる上書きを禁止。

ケース4: コンテキストウィンドウから不要ファイルを除外したい（読み込み許可だが context には載せたくない）

→ claudeMdExcludes で CLAUDE.md ファイルの除外、または .claude/rules/ の path-scoped rules で条件付き読み込み。

まとめ — 「公式機能」と「コミュニティ実装」を区別する

1. .claudeignore は Anthropic 公式機能として存在しない（Claude が幻覚で生成する偽の機能）
2. 公式の正解は .claude/settings.json の permissions.deny — Read/Edit/Write/Bash/WebFetch を細かく制御可能
3. コミュニティ実装の claude-ignore npm パッケージ はあるが、PreToolUse hook 経由で Read のみブロック
4. The Register 報道 (2026-01-28) の事例を機に、Anthropic は公式の正解を明示
5. 本気でセキュリティを確保するなら permissions.deny 必須、補助で claude-ignore を使うのが堅い

Claude Code を業務で使うなら、「秘密ファイルは permissions.deny で守る」をプロジェクト初期に必ず設定 する。これだけで多くのセキュリティ事故が予防できる。

関連記事

Apr 5, 2026 1PasswordがAIエージェントの「鍵管理」に本気を出した — MCP対応・SDK連携を開発者目線で解説AIエージェントがAPIキーを扱う時代の鍵管理を1Passwordで解決する方法を解説。Agentic AI Security機能・MCPサーバー対応・Claude Codeやデプロイパイプラインへのシークレット注入の仕組みを開発者目線で整理。Bitwardenとの機能・料金比較も掲載。読む →

May 5, 2026 AI Agent 時代のシークレット管理設計 — Vault・SSO・MCP の3層アーキテクチャAIエージェントが増えると秘密鍵の管理が破綻する。開発者個人・Agent・CI環境の3層に分けて設計する方法と、1Password/Vault/Doppler/AWS Secrets Managerのツール選定マトリクス、MCP×Vaultパターン、SSO+Token Lifecycle設計、監査ログ、鍵流出パターン3つを網羅した設計論。読む →

May 19, 2026 Claude Code Effort Level 完全活用ガイド 2026 — low/medium/high/xhigh/max の使い分けとモデル別実測Claude Code の Effort Level（low/medium/high/xhigh/max）を Opus 4.7 / Opus 4.6 / Sonnet 4.6 別に徹底解説。設定方法（/effort コマンド、CLAUDE_CODE_EFFORT_LEVEL 環境変数、Skill/Subagent frontmatter）と、ultrathink キーワードによる単発深掘り、コストとパフォーマンスの実測トレードオフを 2026年5月版で。読む →

May 8, 2026 .claudeignore は公式機能じゃない — Claude Code の除外設定、本当の正解は settings.json【2026年5月版】.claudeignore は Claude Code 公式機能ではありません。多くの解説記事が古い情報のままで、公式は settings.json の permissions.deny + respectGitignore を案内しています。3層パターンの整理、移行ガイド、トークン削減実測値まで解説。読む →

FAQ

.claudeignore を作ったらどうなる？

.claudeignore ファイルを置いても Claude Code は読み込まない。完全に無視される。中に書いた .env 等のファイルへのアクセスは普通に発生する。

Claude が「.claudeignore を作ろう」と提案してきたら？

Claude のハルシネーション。そのまま実行せず、permissions.deny への置き換えを促すか、公式ドキュメント (code.claude.com/docs/en/settings) を確認 する。

permissions.deny が効いているか確認するには？

Claude Code セッション中に「.env を読んで」と頼むと、deny ルールが効いていれば「アクセスが拒否されました」というメッセージが出る。または /permissions コマンドで現在の deny ルール一覧を確認可能。

.gitignore と permissions.deny を両方書く必要がある？

両方書く。.gitignore は git のリポジトリ管理用、permissions.deny は Claude Code の動作制御用。役割が違う。.env を .gitignore に入れるだけでは Claude Code には読み込まれる。

Managed Policy レベルの設定はどう配布する？

macOS: /Library/Application Support/ClaudeCode/、Linux/WSL: /etc/claude-code/、Windows: C:\Program Files\ClaudeCode\ にファイルを配置。MDM, Group Policy, Ansible などで配布する。

claude-ignore パッケージは安全？

オープンソースで GitHub で確認可能。ただし 個人開発者のメンテナンスに依存。本番運用や大規模チームでの利用には、まず permissions.deny を主軸にして、claude-ignore は補助として使うのが安全。

.env.local、.env.production 等の派生は別途指定が必要？

ワイルドカードで一括指定可能: Read(./.env.*)。これで .env.local, .env.production, .env.staging などすべてカバーされる。./.env（基本ファイル）と ./.env.*（派生）の両方を deny に入れる のが推奨。

deny ルールを試験的に外して効果を確認したい

.claude/settings.local.json に一時的な許可を書くと、Project 設定の deny を上書きできる（local の優先順位が project より高い）。ただし allowManagedPermissionRulesOnly: true が Managed Policy で設定されていれば上書き不可。