.claudeignoreでClaude Codeのノイズを消す——除外設定だけでレスポンスが変わった話
.claudeignoreの書き方と実践的な除外パターンを解説。node_modules、ビルド成果物、大量の画像ファイルなど、コンテキストを汚すファイルを除外してClaude Codeの精度を上げる。
エンジニアのゆとです。
2026年5月追記: 公式ドキュメントを読み直したところ、
.claudeignoreは2026年5月時点で Claude Code の公式機能ではないことが判明しました。本記事の体験談・テンプレートは「.gitignoreを使った除外パターン」として読み替えてください。Claude Code の公式な除外設定はsettings.jsonのpermissions.denyとrespectGitignoreです。詳細と移行ガイドは .claudeignore は公式機能じゃない — Claude Code の除外設定の正解 にまとめました。
Claude Codeを使っていると「なんかこのプロジェクト、反応が鈍いな」と感じる瞬間がある。
コードを変更してほしいだけなのに、どこか的外れな提案が混じってくる。「node_modulesの中に入っているコメントを参照して話を始めた」みたいな謎挙動。原因の8割はコンテキストに不要なファイルが紛れ込んでいるせいだ。
.claudeignoreを使って除外設定を整えた瞬間、明らかに応答が変わった。「ノイズを消すだけで精度が上がる」という体験を最初にしたとき、思ったより地味なソリューションに笑ってしまった。設定ファイル1枚の話なので。
.claudeignoreとは
.claudeignoreは、Claude Codeがプロジェクト内で参照するファイルの対象を絞り込む設定ファイルだ。
プロジェクトのルート（CLAUDE.mdと同じ場所）に置く。書式は.gitignoreとまったく同じ。.gitignoreを知っている人なら、即座に書ける。
.gitignoreとの違いをひとことで言うと：
.gitignore→ Gitがバージョン管理対象にするファイルを制御する.claudeignore→ Claude Codeがコンテキストに読み込むファイルを制御する
Gitにコミットしないからといって、Claude Codeが参照しないとは限らない。たとえば.envはGitignoreに入っているがローカルには存在する。.claudeignoreがないと、Claude Codeはそれも見てしまう可能性がある。
また逆のパターンもある。dist/はGitignoreに入っているが、ローカルには大量のビルド成果物が生成されている。それが誤ってコンテキストに含まれると、Claude Codeは圧縮されたJavaScriptバンドルを真剣に読もうとし始める。
なぜ必要なのか
Claude Codeは賢いが、「読まなくていいファイル」を自分で判断するのは苦手だ。
プロジェクトを開いた状態でファイルパスを指定せずに質問すると、Claude Codeはプロジェクト全体を文脈として捉えようとする。その際に以下のようなファイルが混入すると問題が起きる。
node_modules/npmパッケージが全部入っている。Reactだけでも数万ファイルあり、minifyされたソースやREADMEが大量に詰まっている。コンテキストを圧迫するだけで、プロジェクト固有のコードを読む余地が削られる。
ビルド成果物（dist/、build/、.next/など）ソースコードから生成された出力ファイル。元のソースさえあれば不要な情報だが、トークンを消費し続ける。圧縮されたバンドルをClaude Codeが読むと、ハッシュ化されたクラス名と縮退した変数名の羅列に混乱する（する）。
大量の画像・動画ファイルpublic/やassets/に大量の画像が入っているプロジェクトは多い。バイナリファイルは読めないが、ファイルパスとして認識されてコンテキストに含まれることがある。PNG1,000枚のファイルパスリストが混入するだけで、それなりのトークンを使う。
coverage/や.nyc_output/には大量のJSONが生成される。過去のテスト実行結果がコンテキストに混入して、Claudeが「このカバレッジデータを見ると……」みたいな話を始めることがある。いや、それいらない。
.envや.env.localには認証情報やAPIキーが入っている。.gitignoreに入れているから安心……ではなく、Claude Codeのコンテキストに含まれると、その内容を会話の中で参照される可能性がある。人にキーを見せたくないのと同様、AIにも見せたくないケースは多い。
基本的な書き方
.gitignoreと完全に同じ文法なので、使える記法を簡単にまとめる：
# コメント（#で始まる行はコメント扱い）
# ディレクトリ全体を除外（末尾のスラッシュで明示）
node_modules/
dist/
# 特定の拡張子を除外（ワイルドカード）
*.log
*.tmp
*.png
# 特定のファイルだけ除外
.env
.DS_Store
# ネストしたパスを指定
**/coverage/
src/**/*.generated.ts
# 特定のパターンを除外対象から除外（ネゲーション）
*.png
!public/og-image.png
# → PNG全体を除外しつつ、og-image.pngだけ残すネゲーション（!）は.gitignoreでも使える記法で、「一括除外しつつ特定だけ残す」という使い方ができる。
コピペで使えるテンプレート
実際に使っているパターンをプロジェクト種別に分けて載せる。
Next.jsプロジェクト
# ビルド成果物
.next/
out/
dist/
# 依存関係
node_modules/
# テスト関連
coverage/
.nyc_output/
# ログ
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
# 環境変数
.env
.env.local
.env.production
.env.*.local
# OS
.DS_Store
Thumbs.db
# バイナリ・メディア（容量が大きいもの）
*.png
*.jpg
*.jpeg
*.gif
*.svg
*.mp4
*.webm
*.pdf
# 型チェック・生成ファイル
*.tsbuildinfo
*.d.ts.map
# キャッシュ
.cache/
.turbo/Pythonプロジェクト
# 仮想環境
venv/
.venv/
env/
.env/
__pycache__/
*.pyc
*.pyo
# ビルド成果物
build/
dist/
*.egg-info/
.eggs/
# テスト
.pytest_cache/
.coverage
htmlcov/
# 型スタブ
*.pyi
# Jupyter
.ipynb_checkpoints/
*.ipynb
# 環境変数
.env
.env.local
# OS
.DS_Store
__MACOSX/
# ログ
*.log
logs/
# データファイル（大きい場合）
*.csv
*.parquet
*.pkl
data/raw/monorepoプロジェクト
# 全パッケージ共通のビルド成果物
**/dist/
**/build/
**/.next/
**/out/
# 全パッケージの依存関係
**/node_modules/
# パッケージマネージャーキャッシュ
.pnpm-store/
.yarn/cache/
.npm/
# テスト
**/coverage/
**/.nyc_output/
# 環境変数
**/.env
**/.env.local
**/.env.*.local
# TypeScript
**/*.tsbuildinfo
# ログ
**/*.log
# OS
.DS_Storemonorepoはワイルドカードを使った**/dist/形式で全パッケージに一括適用するのが楽だ。パッケージが増えるたびに.claudeignoreを更新しなくて済む。
除外しすぎると困るケース
「全部除外したほうがノイズが減っていい」わけでもない。過剰に除外すると、Claude Codeの助けが必要な場面で情報が足りなくなる。
型定義ファイル（*.d.ts）TypeScriptプロジェクトで*.d.tsを全除外すると、外部ライブラリの型情報が参照できなくなる。「この関数の引数の型が分からない」という状況が増える。自動生成の*.generated.d.tsだけ除外して、通常の型定義は残すほうがいい。
「テストを追加して」「既存のテストと同じスタイルで書いて」という指示を出す場合、テストファイルを除外していると参照できない。テスト自動生成系のタスクをよくやるなら除外しないほうがいい。
ロックファイル（package-lock.json、yarn.lock）依存関係のバージョン固定情報が入っている。「このパッケージのバージョン何？」「互換性の問題を調べたい」という場面で参照されることがある。容量が大きいのは確かだが、除外するなら用途を考えてから。
意図的に見せたいファイル「このアーキテクチャ図のSVGを解析して」「このサンプルのPDFから情報を抽出して」みたいなタスクがあるなら、そのファイルは除外してはいけない。.claudeignoreに*.svgを書いてから「このSVGを見て」と言っても、見られない。
ネゲーション記法を使えば「基本は除外、特定のファイルだけ残す」も書ける：
# 画像は基本除外
*.png
*.jpg
*.svg
# でもこれは必要
!docs/architecture.svg
!public/og-image.png実際の効果：何が変わるか
.claudeignoreを設置した後の体感的な変化をまとめると：
「このバグを直して」という指示に対して、node_modulesの中身ではなく自分のコードを見るようになる。当たり前のことが当たり前にできるようになる、という感じ。
コンテキストの消費が減る不要なファイルがコンテキストに混入しなくなるので、実質的なコンテキストウィンドウが広くなる。同じタスクで使えるトークン量が増える、と言い換えてもいい。
秘匿情報の誤参照がなくなる.envの内容をうっかり会話で使われることがなくなる。セキュリティ的な安心感が地味に大きい。
Claude Codeが謎の場所のファイルを読んでいる挙動が減る。ログを見ていると「なんでそこ読んだ」と思う瞬間があるが、それが減る。
APIの従量課金プランを使っている場合、節約効果も出る。コンテキストに混入するトークンが減れば、入力コストが下がる。MAXプランでも5時間あたりの使用量制限があるので、効率化のメリットは同じようにある。
設置手順（30秒でできる）
# プロジェクトルートに移動
cd your-project
# .claudeignoreを作る（内容はコピペ）
touch .claudeignoreあとは上のテンプレートを貼り付けて、プロジェクトに合わせて調整するだけ。
既に.gitignoreが整備されているプロジェクトなら：
# .gitignoreをベースにして作る
cp .gitignore .claudeignoreコピーして、「Gitには不要だけどClaude Codeには見せたいファイル」を除外対象から外す（ネゲーションで対応するか、そもそも行を削る）。完全な一致にする必要はない。
.claudeignoreはClaude Codeのみが参照する。.gitignoreと別管理で構わない。チームで共有したい場合はGitにコミットすればいいし、個人設定として.gitignoreに/.claudeignoreを追加してもいい。
まとめ
.claudeignoreでやること：
node_modules/、dist/、.next/などのビルド成果物・依存関係を除外*.log、coverage/などのノイズファイルを除外.envなどの秘匿情報を除外- 画像・バイナリの大量ファイルを除外
やらないこと：
- 型定義・テストファイルなど、タスクに必要なものは除外しない
- 全部除外してClaude Codeを盲目にしない
.gitignoreのコピーをベースに作るだけで、大半のケースはカバーできる。設定ファイル1枚で体験が変わる系のやつなので、まだ使っていないなら試してみる価値はある。
関連記事
