2026-09-17 · code

Claude Codeで2サイト同時運用して分かった「コンテキスト汚染」の正体：urisol.com と urinosuke.com を切り替えるたびファイルパスを間違える問題を3ステップで解いた

本記事は広告（アフィリエイトリンク）を含みます。掲載商品の購入によって運営者に紹介料が発生することがあります。内容は当サイト運営の独立した判断に基づいて選定しています。アフィリエイト表記

Claude Codeで複数プロジェクトを切り替えると起こる「コンテキスト汚染」

私は現在、2つのWebサイトを運営している。法人技術記事の urisol.com と、個人ペンネームの urinosuke.com だ。どちらも Astro + Cloudflare Pages で構築しており、Claude Code を使って記事の自動投稿やサイト改修を進めている。

2サイト運用で困ったのが、Claudeが前回のプロジェクトの構造を引きずって誤った指示を出すことだった。たとえば urisol.com の作業をした直後に urinosuke.com へ切り替えると、次のような事故が起きる：

  • urinosuke.com のコンテンツディレクトリ（src/content/blog/）に、urisol.com 用の記事ファイルを生成しようとする
  • GitHub Actions のワークフローファイル名を取り違える（urisol側の .github/workflows/generate-urisol-post.yml を urinosuke 側で呼ぼうとする）
  • Cloudflare Pages のプロジェクト名を混同し、デプロイ先を間違える

これらは「前回のチャットで扱ったプロジェクトの情報が、次のチャットに持ち越される」状態——いわばコンテキスト汚染とでも呼ぶべき現象だった。

解決の3ステップ：プロジェクト固有のコンテキストを明示する

ステップ1：.clauderc.json でプロジェクト名を宣言する

各リポジトリのルートに .clauderc.json を置き、次のようにプロジェクト識別子を埋め込んだ：

{
  "project_name": "urinosuke.com",
  "content_dir": "src/content/blog",
  "workflow_file": ".github/workflows/generate-post.yml"
}

urisol.com 側も同様に、固有の値を持つファイルを作成する。Claude Code はリポジトリ内の設定ファイルを読み取れるため、この宣言があれば「今どちらのプロジェクトを扱っているか」を毎回確認できる。

ステップ2：チャット冒頭で「今からどちらを扱うか」を宣言する

Claude とのやり取りの最初に、次のように明示するルールを作った：

「urinosuke.com の記事生成を依頼する。urisol.com の構造は参照しないこと」

この一文を必ず冒頭に入れるようにしたところ、Claude が前回のチャット履歴を引きずる頻度が大幅に減った。人間側が「今何をするか」を言語化する習慣は、AI開発の文脈でも有効だ。

ステップ3：実行前に「どのファイルを触るか」を出力させる

コード生成や記事投稿の指示を出す際、必ず次のような確認ステップを挟むようにした：

「実行前に、今回触るファイルパスをすべて列挙してください」

Claude は指示に従って、たとえば次のように出力する：

  • src/content/blog/2026-08-28-example.md（記事ファイル）
  • .github/workflows/generate-post.yml（ワークフロー）
  • src/config.ts（サイト設定）

この列挙を目視確認することで、間違ったリポジトリのパスが混入していないかを実行前に検証できる。事後修正より事前確認のほうが圧倒的に速い。

Astro Content Collections の構造が似ているほど混同リスクが高い

urisol.com と urinosuke.com は、どちらも Astro の Content Collections（src/content/blog/）を使っている。フロントマターのスキーマも似通っており、ディレクトリ構造がほぼ同じだ。

この「構造の類似」が、Claude のコンテキスト混同を誘発していたと考えている。もし2サイトが全く異なる技術スタック（たとえば一方はWordPress、もう一方は静的サイト）だったら、パスの取り違えは起きにくかっただろう。

構造が似ているプロジェクトを複数扱うときほど、プロジェクト識別子を明示する仕掛けが必要になる。

Claude Code の「記憶の境界」を理解する

Claude Code（Claude 3.5 Sonnet 含む）は、チャット履歴を一定範囲で保持するが、その「記憶の境界」は公式に明示されていない。私の体感では、10〜20ターン前の指示内容が次のチャットに影響を及ぼすことがある。

この現象を完全に防ぐには、次のいずれかが必要だ：

  1. チャットを明示的に終了し、新規チャットで再開する（コンテキストをリセットする）
  2. 冒頭宣言でプロジェクトを明示する（前回の記憶を上書きする）
  3. 設定ファイルで構造を固定化する（AIが参照すべき情報源を一意にする）

私は2と3を組み合わせることで、コンテキスト汚染の頻度を実用レベルまで下げた。

まとめ：複数プロジェクトのAI開発は「今どれを扱うか」の宣言が9割

Claude Code で2サイトを同時運用して分かったのは、AIは前回のコンテキストを引きずるという当たり前の事実だった。その対策は次の3つに集約される：

  1. .clauderc.json 等の設定ファイルでプロジェクト名を宣言する
  2. チャット冒頭で「今から何を扱うか」を明示する
  3. 実行前にファイルパスを列挙させ、目視確認する

これらは「AIに任せる範囲」の外側にある、人間が担うべき判断プロセスだ。Claude Code の生産性を上げるには、AIの能力を引き出すだけでなく、AIが混同しやすい境界を人間側で明示することが不可欠だと実感している。

参考

関連書籍

実践Claude Code入門——現場で活用するためのAIコーディングの思考法

チーム導入・Claude.md 運用・サブエージェント設計の実務論点がまとまっており、複数プロジェクトでのコンテキスト管理の考え方にも応用が効く。失敗事例の言語化が特に参考になった。

Amazonで見る

楽天で見る

LLMのプロンプトエンジニアリング

GitHub Copilot設計者のプロンプト設計論。コンテキスト・スカフォールディング・テンプレート化の概念地図が、Claude Code の複数プロジェクト運用にそのまま応用できる。

Amazonで見る

楽天で見る

関連記事

まとめて読む: AI活用・自動化

← ブログ一覧へ戻る