警告
この記事はAIとの会話をAIに要約してもらい、人間が加筆修正して作成しています。
人間の雑感は文末に記載しています。
目次
- 用語と前提
- コンテキストと圧縮(要約)
- メモリの階層と読み込み順
- CWD(作業ディレクトリ)で“効き方”を制御
- ローカルキャッシュ(再開用)と
--continue - サンドボックス化の実践(強度別)
- ディレクトリ別にルールを差し替える
- チェックコマンド一覧
- テンプレート集(コピペ可)
- 運用レシピ(3パターン)
- よくある誤解と回避策
- まとめ
1. 用語と前提
- コンテキスト: そのターンでモデルが読めるテキスト量。Opus 200K tokens(会話が長いと古い内容は要約=圧縮)。
-
メモリ:
CLAUDE.md等のファイルに書く恒常ルール(毎回読み込まれる“土台”)。 - ローカルキャッシュ: 再開用の会話ログ(端末ローカル保持)。新規セッションでは自動参照されない。
- CWD: Current Working Directory。いま開いているフォルダ。これが超・重要。
2. コンテキストと圧縮
- 会話が膨らむと古い履歴は要約(圧縮)され、大筋は残るが細部は薄れる。
- **消したくない規約・決定は
CLAUDE.mdに“昇格”**させる(会話内の「絶対忘れないで」より確実)
出典;https://github.com/anthropics/claude-code/issues/3841?utm_source=chatgpt.com
ここからは恐らくこうなっているんだろうという推測
- 圧縮後は圧縮した内容でコンテキストメモリに展開される、長いセッションで再度圧縮されると前回圧縮された内容がさらに圧縮されて詳細が捨てられる
- 圧縮された際に直近の会話は保護される(出典:https://www.latent.space/p/claude-code?utm_source=chatgpt.com)
注意
コンテキストの中には人間の発言+それに対するClaudeの返答:文書などの入出力の全部が入る。恐らく人間の発言の方が割合としては少ないはず。
3. メモリの階層と読み込み順
読み込み順(上から土台 → 下ほど上書き/追加)
- Enterprise(組織全体)
- Project(いま開いているプロジェクト=CWD のルート)
- User(あなた個人の恒常ルール)
-
Project(local)(個人用・非推奨。代わりに
@import推奨)
ポイント
- Project=Gitリポかどうかは関係なく、あなたが開いたワークスペース。
- サブディレクトリに
CLAUDE.mdがある場合、その配下を扱うときに追加で取り込まれる
出典;https://docs.anthropic.com/ja/docs/claude-code/memory
Claudeがメモリを検索する方法
Claude Codeはメモリを再帰的に読み取ります:cwdから開始して、Claude Codeはルートディレクトリ / まで(含まない)再帰し、見つけたCLAUDE.mdまたはCLAUDE.local.mdファイルを読み取ります。これは、foo/bar/ でClaude Codeを実行し、foo/CLAUDE.md と foo/bar/CLAUDE.md の両方にメモリがある大きなリポジトリで作業する際に特に便利です。
Claudeは現在の作業ディレクトリ下のサブツリーにネストされたCLAUDE.mdも発見します。起動時に読み込む代わりに、Claudeがそれらのサブツリー内のファイルを読み取る際にのみ含まれます。
4. CWD(作業ディレクトリ)で“効き方”を制御
-
VSCodeで対象フォルダだけ開く=そのフォルダが Project 扱い。
例:code /path/to/repo/A - CWD が
repo/AならA/CLAUDE.mdが前面に効く。 - CWD はルールの“選択スイッチ”。狙い撃ちに使う。
5. ローカルキャッシュ(再開用)と --continue
- ローカルに**セッションログ(再開用)**が保存される(保持期間は設定で可変、既定は約30日想定)。
- 再開する時だけそのログが読み込まれ、現行セッションの文脈に復元される。
- 新規セッションでは勝手に参照されない。
- 便利コマンド:
-
claude --continue… CWD の直近セッションを再開 -
claude --resume <session-id>… 指定セッションを再開
-
再開後も会話が長くなれば再び圧縮は起きる。
要点はCLAUDE.md/NOTES.mdに昇格して“劣化”を防ぐのが吉。
人間の注釈
claude --continueの際にどこまでそのセッションの履歴を遡ってメモリに展開するのかは裏取りできなかった。
圧縮直前の会話履歴が残っていたとしてそれを全部メモリに展開するとは思えないので何かしらCAPを設けているんではないか?
6. サンドボックス化の実践(強度別)
-
軽: CWD 固定 + ルール宣言
- 対象フォルダだけ開く →
CLAUDE.mdに「../ 触らない」等を明記。
- 対象フォルダだけ開く →
-
中: Git/エディタで誤操作防止
- Git pre-commit フックで対象外パスの変更を拒否。
- VSCode
files.excludeで視界を絞る。
-
強: 物理的に見えなくする
- Docker で対象フォルダのみマウントして起動。
- 権限(UNIX/NTFS)で他ディレクトリを読取不可。
- リポジトリ分割や sparse-checkout でワークツリーを絞る。
7. ディレクトリ別にルールを差し替える
- A に集中したい → A を単体で開く(CWD を A に)。
-
A 直下に
CLAUDE.mdと.claude/settings.jsonを置いてA専用の規約/権限を定義。 - 上位(リポ直下)の設定を自動継承させる仕組みには依存しない(A 内で完結)。
人間の注釈
Gitで管理しているのでsettings.jsonはレポジトリルートに置くのだと考えていたのだけどそうではなかった。ひらくディレクトリが重要。
8. チェックコマンド一覧
-
/memory… 読み込まれているメモリファイル一覧を確認 -
/permissions… どの設定ファイルのどの権限が効いているか確認 -
/clearor/reset… セッション履歴のクリア(メモリファイルは別) -
/compact… 手動圧縮(要約)実行(※実行前に要点をノートへ昇格させるのが安全)
9. テンプレート集(コピペ可)
9.1 A/CLAUDE.md(最小・強めのスコープ)
# Scope(絶対遵守)
- 作業対象はこのディレクトリ配下のみ。`../` の上位には一切触れない。
- 変更前に必ず「対象ファイル一覧 + 差分プラン」を提示し、承認後に実行する。
# 変更ガード
- 破壊的変更(削除/大規模置換)は Git でバックアップブランチを切ってから行う。
# 開発ルール(A専用)
- 既存コードの再利用を最優先。重複実装は禁止。
- ランタイムは Node.js 20、ESM。Lint/Format は CI で強制。
9.2 setting.jsonの指定
{
"permissions": {
"allow": [
"Read(**)",
"Edit(**)"
],
"deny": [
"Read(../**)",
"Edit(../**)",
"Read(**/.git/**)",
"Edit(**/.git/**)",
"Read(**/node_modules/**)",
"Edit(**/node_modules/**)",
"Edit(**/*.lock)",
"Read(**/secrets/**)",
"Edit(**/secrets/**)"
]
}
}
注意
上の例だとレポジトリ配下のディレクトリでClaudeCodeを起動した場合にレポジトリのルートにあるclaude.mdも参照できなくなる。
それがいいのか駄目なのかはプロジェクトによって判断しないといけない
雑感(人間が書いています)
Claude 3 Opus (200K トークン) の場合、英語でおよそ 75〜100 万文字、日本語でおよそ 10〜16 万文字が扱えるでそうで、7倍近い差があります。
出典
圧縮が起きずに扱えるコンテキスト量は増えていく方向にはあると思いますが、この中には人間の発話、ClaudeCodeの回答、読み込んだファイル、出力したファイルの全てが入ってくるので人間がリアルタイムに指示する会話の量の制限は思っているより少ないです。また日本語が不利なのは前述のとおりなので日本語で指示するより英語で指示する方が回答精度の劣化のタイミングを遅くなるのはある程度正解です。
人間はまだ200Kトークンを制御できていない
とはいえ下記のように7倍近い性能差が出るはずの英語圏でもAIが使い物にならない発言が見受けられるのはなぜでしょうか?
日本語が英語に比べて不利としても一回のセッションで圧縮が起きる前に取り扱える量は平均的な文庫本に相当する1冊 8〜12万文字以上あります。
人間がリアルタイムに会話の中で文庫本一冊の分量を順序立てて構成するのは不可能でないかと思います。
なので予めルールをファイルとして作っておき、シチュエーションによって適宜参照させ、セキュリティなどの原則論はclaude.mdに記述して毎回呼び出すなどの工夫が必須です。
現状、生成AIの回答が不安定なのはコンテキストの総量の中で人間が適切に指示をしている割合が少なすぎてAIが想像で補完している部分が毎回の回答のたびに変わるからです。
AIの想像した部分が目的に沿う場合はそれを採用するのはいいのですが、採用したならばそれをプロジェクトの中でルール化しないとそのプロジェクトは収束せずにAIの想像力によって毎回成果物が変わってしまいます。
AIに頼りつつ、人間が成果物の可能性を徐々に閉じていく。
今人間に求められているのはそういうことなんだと考えています。
参考URL