Claude Codeの/compactをチームで使う前に：context window・memory・subagentsの運用ルール

3行まとめ

同じ作業を続ける

`/compact focus …`で次の判断に必要な文脈だけを残す

別作業へ切り替える

`/clear`で古い前提を切り、混線を防ぐ

大きな読取や独立調査

subagentsへ逃がし、main conversationには判断材料だけ戻す

context windowは作業ログ置き場ではなく、今の推論に必要な作業領域として扱うのが基本です。

• Claude Codeの/compactは、長い会話を全部保存する記憶装置ではありません。次の作業に必要な文脈を残すための要約手段として扱うほうが安全です。
• 別タスクへ移るなら/clear、同じタスクを続けるなら/compact focus ...、大きな読取や独立調査はsubagentsへ逃がす、という分担を先に決めます。
• CLAUDE.md、auto memory、settings、hooks、subagentsは役割が違います。チーム導入では、覚えさせる情報と強制するルールを混ぜないことが一番効きます。

この記事でわかること

`/compact`と`/clear`

続ける作業と切り替える作業を分ける

`/context`と`/memory`

作業前にwindowの重さと読まれる記憶を確認する

`CLAUDE.md`、settings、hooks

毎回必要なルールと強制したい制約を混ぜない

subagents

独立調査を分担し、main conversationを判断の場に保つ

便利なコマンドの使い方ではなく、チームで事故を減らすための運用設計として見ると整理しやすくなります。

この記事では、Claude Codeのcontext windowをチームでどう運用するかを整理します。対象は、Claude Codeを長い実装、依存関係更新、調査、レビュー、複数人の引き継ぎに使い始めた開発チームです。

特に次の判断に絞ります。

• /compactと/clearをどう使い分けるか
• /contextと/memoryをいつ確認するか
• CLAUDE.md、auto memory、settings、hooksをどう分けるか
• subagentsに何を任せ、main conversationに何を戻すか
• compact後に指示が消えたように見える時、どこを直すか

2026年6月11日にClaude Code公式Docsを確認し、手元ではclaude --versionが2.1.138 (Claude Code)でした。Xで見かけるcompactionや長時間エージェント運用の話題は需要シグナルとして見ていますが、本文の根拠には使っていません。

前提知識

1. 1instructions

   system、project、directoryごとの指示が推論の前提になる

2. 2read files

   参照したファイルの内容が作業領域に入る

3. 3tool output

   実行結果やログが長いほどwindowを圧迫する

4. 4conversation

   ユーザーとのやり取りやClaudeの返答も積み重なる

5. 5memory

   読み込まれた記憶やルールも毎回contextを使う

contextが重い時は、会話の長さだけでなく、読ませた情報と出力させた結果も疑います。

Claude Codeのcontext windowは、ユーザーが見ている会話文だけで埋まるわけではありません。公式Docsでは、instructions、読んだfile、Claude自身のresponse、terminalに表示されない内容もcontext windowに入ると説明されています。つまり、会話が短く見えても、裏側では読んだファイルやtool outputで重くなっていることがあります。

ここで大事なのは、context windowを作業ログ置き場にしないことです。ログ、調査メモ、長いエラー出力、全ファイルの読取結果をmain conversationへ積み続けると、次の推論に使える余白が減ります。作業の途中で「Claudeの判断がぼんやりしてきた」「前に決めたことと違う変更を始めた」と感じる時、モデル性能だけでなく文脈の積み方が原因になっている場合があります。

この問題に対して、Claude Codeには/context、/memory、/compact、/clear、subagentsという複数の道具があります。ただし、全部を「記憶」や「圧縮」とひとまとめにすると運用を誤ります。

目的	使うもの	置く情報
今のcontext使用状況を見る	/context	重い要素、最適化のヒント
読まれているmemoryを確認する	/memory	CLAUDE.md、auto memory、rules
同じタスクの文脈を整理する	/compact focus ...	決定、変更、検証、未解決点
別タスクへ切り替える	/clear	古い会話を切って新しく始める
大きな読取や独立調査を分ける	subagents	要約、根拠、リスク、次の一手

/compactは記憶装置ではなく、context windowを整えるために使う

1. 1同じ作業で続行

   未解決の仮説、触ったファイル、次の手順を残して`/compact`する

2. 2不要なログを圧縮

   古い会話や大きな読取結果を、次に必要なsummaryへ置き換える

3. 3別タスクへ移動

   前の前提を持ち込まないために`/clear`する

4. 4作業前点検

   `/context`と`/memory`で、重さと読まれるルールを確認する

`/compact`は保存ではなく整理、`/clear`は切り替えです。どちらが上ではなく、作業の継続性で選びます。

/compactを「セッションを保存するコマンド」と思うと危険です。使いどころは、同じ作業を続けたいが、会話や読取結果が長くなりすぎた時です。古い文脈を全部抱えたまま進むのではなく、次に必要な情報だけを構造化して残します。

context windowには会話以外も入る

根拠

Claude Codeでは、会話、読んだファイル、tool output、memory、instructionsが積み重なります。だから、次のような使い方をするとcontextが急に重くなります。

• 失敗ログを何度も全文で貼る
• monorepoの関連ファイルを広く読みすぎる
• 調査メモを会話内で長く育て続ける
• subagentの調査結果を要約せずにmainへ戻す
• CLAUDE.mdやrulesへ毎回不要な情報を足し続ける

/compactは、この状態を小さくするための道具です。ただし、何を残すかを指定しなければ、残ってほしい判断材料が薄くなることがあります。チームで使うなら、節目ごとに「何を残して次へ進むか」を決めてからcompactします。

/compactと/clearの使い分けを先に決める

条件

同じバグ修正を続ける、同じfeature workの実装へ進む、レビュー前に長い調査を短くしたい。こういう時は/compactが合います。逆に、別のIssueへ移る、無関係な調査を始める、前の会話の前提が邪魔になる。こういう時は/clearで切るほうが読み違いを減らせます。

実務では次のように決めると扱いやすいです。

場面	選ぶ操作	理由
調査から実装へ移る	/compact focus ...	決定と未解決点を残したい
実装からレビューへ移る	/compact focus ...	変更ファイルと検証結果を残したい
別のIssueへ移る	/clear	古い前提を混ぜたくない
雑談や横道が増えた	/clearまたは新規session	本筋に不要な文脈を切る
大きなログを調べる	subagentへ委譲	mainに全文を入れない

/contextと/memoryは作業前点検にする

確認項目

長い作業に入る前は、いきなり/compactするより先に/contextと/memoryを見ます。/contextでは、今のwindowを何が使っているかを確認します。/memoryでは、どのCLAUDE.md、CLAUDE.local.md、rules、auto memoryが読まれているかを確認します。

チームで使うなら、次のタイミングをRunbookに入れておくと効果があります。

• 大きな実装に入る前
• 長い調査が終わった直後
• subagentの結果を統合した直後
• レビューへ渡す前
• 別メンバーに引き継ぐ前

「調子が悪くなったらcompact」では遅いことがあります。節目で確認し、必要ならfocusを指定してcompactする。これだけで、長時間作業の迷子感はかなり減ります。

/compact focus ...はチームの引き継ぎ要約として設計する

項目	内容	見方
目的		何を直す、調べる、判断する作業だったか
触った範囲		変更したファイル、読んだ重要ファイル、関係する設定
失敗した仮説		もう戻らないために、試して違った道を残す
未実行テスト		次に確認すべきコマンドや残ったリスクを書く
次の一手		再開時に最初に見る場所と実行する作業を固定する

automatic compactionだけに任せず、チームが重要とみなす項目をfocus instructionsで明示します。

チームでの/compactは、単なる軽量化ではなく引き継ぎ要約です。次の担当者、翌日の自分、レビュー担当者が読んで状況を把握できる形にします。

automatic compactionに任せきらない

注意点

Claude Codeはcontextが埋まってきた時に自動でcompactionできます。ただ、チーム作業では「何を重要と見なすか」を人間が明示したほうが安全です。認証まわりのバグ修正なら、失敗した仮説、触ったファイル、再現条件、未実行テストが重要です。UIの微修正なら、before/after、対象画面、アクセシビリティ確認が重要になります。

そこで、manual compactではfocus instructionsを具体的にします。

/compact focus on the auth timeout bug.
Keep the user-visible symptom, chosen fix, rejected approaches,
touched files, tests run, tests not run, and remaining security risks.

日本語で依頼しても構いません。

/compact 認証タイムアウトの修正に集中して要約してください。
残すものは、症状、採用した方針、捨てた案、変更ファイル、
実行したテスト、未実行の理由、残るセキュリティリスクです。

短くするだけなら「ここまでを要約して」で済みます。しかし、実務のhandoffではそれだと薄い。残す項目を指定することで、次の作業が再現しやすくなります。

focus instructionsに入れる項目を固定する

確認項目

チームでは、/compact focus ...の型を決めておくと便利です。おすすめは次の7項目です。

残す項目	内容
目的	何を直す、作る、調べる作業か
決定	採用した方針と理由
捨てた案	やらないと決めた選択肢
変更	触ったファイル、変更の意図
検証	実行したコマンド、結果、失敗
未解決	まだ判断していない点
次の一手	次に見るファイル、実行するテスト、レビュー観点

これを毎回揃えると、/resumeした時や別メンバーに渡した時に状況を取り戻しやすくなります。逆に、毎回形式が違うと、compact後のsummaryもレビューしづらくなります。

compaction後に何が残るかを誤解しない

根拠

公式Docsでは、project-rootのCLAUDE.mdはcompaction後に再読込され、sessionへ再注入されると説明されています。一方で、会話の中だけで伝えた指示、nested CLAUDE.md、path-scoped rulesは、条件によって見え方が変わります。該当ディレクトリのファイルを次に読んだ時にrulesが効く、という流れもあります。

つまり、重要なチームルールを「さっき会話で言ったから大丈夫」と扱わないほうがよいです。永続させたいものは、rootのCLAUDE.md、project rules、settings、hooks、社内docsへ移します。/compactは会話を整える道具であって、チームポリシーの保管場所ではありません。

memoryには毎回必要なルールと、あとで思い出す知見を分けて置く

項目	内容	見方
`CLAUDE.md`		build/test command、主要ディレクトリ、レビュー前チェックなど毎回必要なチーム標準
auto memory		あとで思い出す知見。machine-localなので共有前提にしない
settings		使うmodel、permissions、tool制御など設定として固定するもの
hooks		本番操作や外部送信など、必ず止めたい操作を機械的に制御するもの
conversation summary		今の作業を再開するための一時的な引き継ぎ

共有したい知見は、auto memoryへ置きっぱなしにせず、レビューしてRunbookや`CLAUDE.md`へ移します。

Claude Codeのmemoryまわりで起きやすい失敗は、全部を同じ箱に入れることです。CLAUDE.md、auto memory、settings、hooks、conversation summaryは、それぞれ役割が違います。

CLAUDE.mdはチーム標準の入口にする

評価基準

projectのCLAUDE.mdには、毎回必要なチーム標準を書きます。たとえば、build/test command、主要ディレクトリ、レビュー前に必ず見る観点、禁止する変更方針、PRに書くべき検証結果です。

よいCLAUDE.mdは、短く、具体的で、作業ごとに効きます。

# Project instructions

- Use `pnpm test` before proposing a bugfix PR.
- Do not edit database migrations without explaining rollback impact.
- For auth changes, include tests for expired sessions and missing cookies.
- Summarize files changed, tests run, tests not run, and remaining risks.

逆に、古い調査ログ、個人の好み、一度だけ使う仮説、秘密情報に近いメモを入れると、毎回contextを消費します。公式Docsでも、大きすぎるCLAUDE.mdはcontextを消費し、守られにくくなることが示されています。200行を超えるようなら、path-scoped rules、docs、skills、Runbookに分ける判断をします。

auto memoryは便利だが、共有前提にしない

注意点

auto memoryは、Claudeがbuild commands、debugging insights、architecture notes、workflow habitsなどを保存する仕組みです。公式Docsでは、MEMORY.mdの先頭200行または25KBがstartupで読まれ、topic fileは必要に応じて読まれると説明されています。

便利ですが、チーム共有ナレッジベースとしてそのまま扱うのは危険です。auto memoryはmachine-localです。人によって保存内容が違い、古い仮説や個人メモが残ることもあります。秘密情報や顧客情報に近い内容を保存していないかも確認が必要です。

チームでのおすすめ運用はこうです。

• auto memoryは個人作業の補助として使う
• /memoryで定期的に中身を確認する
• チーム共有すべき知見はreviewしてCLAUDE.mdやdocsへ移す
• 保存してはいけない情報をCLAUDE.mdやsettingsで明示する

settingsやhooksをmemory扱いしない

権限境界

重要なのは、settingsやhooksを「強めのmemory」と呼ばないことです。公式Docsでは、settings rulesはclient側で強制され、CLAUDE.mdはClaudeの行動を導く文脈だと整理されています。つまり、CLAUDE.mdは「こうしてほしい」、settingsやhooksは「これは止める」に近い役割です。

置きたい内容	置き場所
毎回守ってほしい作業方針	CLAUDE.md、rules
あとで思い出したい知見	auto memory、docs
必ず止めたい危険操作	settings、permissions、hooks
繰り返し使う手順	Skills、commands、Runbook
外部サービス連携	MCP、権限設定、監査ログ

たとえば「本番DBを更新しないで」はCLAUDE.mdだけに置くより、permissionsやhooksで止めるほうが安全です。「PR本文には未実行テストを書く」はCLAUDE.mdに向きます。「依存関係更新の手順」はRunbookやSkillに分けると使いやすいです。

subagentsは大きな読取と独立調査をmain conversationから逃がす

1. 1main conversation

   計画、意思決定、実装の統合、ユーザーとの確認を担当する

2. 2限定された依頼

   読む範囲、調べる観点、返却形式を先に決める

3. 3subagents

   大きな読取、独立調査、影響範囲確認を別contextで進める

4. 4短い返却

   結論、根拠、未確認点だけをmain conversationへ戻す

subagentの長い結果をそのまま戻すと、main conversationも重くなります。返却は判断に必要な形へ絞ります。

subagentsはcontext節約のためだけの機能ではありません。独立した作業を別のcontext windowで進め、main conversationには判断に必要な要約だけ戻すための分担手段です。

main conversationでやる作業を残す

条件

main conversationに残すべき作業は、頻繁なやり取りが必要なものです。計画から実装、テスト、レビューまで同じ前提を共有する作業、細かい判断をその場で変える作業、短いtargeted fixはmainで進めるほうが自然です。

反対に、次のような作業はsubagentへ渡しやすいです。

• 長いログから失敗原因を絞る
• 公式DocsやREADMEを読んで差分をまとめる
• 複数ファイルの影響範囲を調べる
• セキュリティ観点だけで変更案をレビューする
• 既存テストの失敗パターンを分類する

ここで大事なのは、subagentの戻り値を短くすることです。せっかく別contextで調べても、全文をmainへ貼れば結局contextを使います。

subagentsへ渡す作業を限定する

根拠

公式Docsでは、subagentsはfreshでisolatedなcontext windowから始まると説明されています。main conversationの全履歴を当然に見ているわけではありません。だから、委譲promptには必要な前提を含めます。

使いやすい依頼の型は次の通りです。

Owner: security-review
Scope: auth timeout fix in src/auth and tests/auth
Read: source files, tests, recent failure logs
Avoid: secrets, .env, production data
Expected output: conclusion, evidence files, unresolved risks, next action
Done condition: summarize whether the fix needs additional permission checks

日本語で書くなら、次のようにします。

security-review subagentに依頼してください。
対象はsrc/authとtests/authの認証タイムアウト修正です。
読んでよいのはsource、test、失敗ログです。
.env、secret、本番dataは読まないでください。
戻す情報は結論、根拠ファイル、未確認リスク、次の一手だけにしてください。

委譲プロンプトと返却フォーマットを決める

返却条件

チームでは、subagentからmainへ戻す形式を決めておきます。おすすめは4項目です。

返すもの	内容
結論	何が分かったか
根拠	ファイル、Docs、ログの位置
未確認	まだ見ていない範囲
次の一手	mainで実行すべき作業

大量の引用、raw logs、長い差分は戻さない。必要ならファイルパスやコマンドだけ残し、mainが必要な時に読む。これができると、subagentsはcontextを散らかす道具ではなく、main conversationを軽く保つ作業分担になります。

チーム用Runbookは開始前、途中、引き継ぎ前で分ける

1. 開始前

   `/memory`と`/context`を確認し、古い会話が混ざるなら`/clear`する

2. 途中

   tool outputや読取結果が増えたら、必要な事実を残して`/compact focus …`する

3. 引き継ぎ前

   変更点、未実行テスト、残リスク、次の一手を固定する

小さなRunbookでも、開始前、途中、引き継ぎ前を分けるだけで再開しやすさが変わります。

Claude Codeのcontext運用は、個人の勘で回すよりRunbookにしたほうが安定します。複雑なルールから始める必要はありません。開始前、途中、引き継ぎ前の3段階で十分です。

開始前に読む文脈を絞る

確認項目

作業開始前に見るものは多くありません。

/memory
/context

/memoryで、読まれているinstructionsとauto memoryを確認します。/contextで、今のwindowを圧迫している要素を見ます。古い会話が混ざっている場合は、/clearで始め直す判断をします。

開始promptには、目的、対象範囲、禁止事項、検証コマンドを入れます。

このPRでは認証タイムアウト時の再ログイン導線だけを直してください。
対象はsrc/authとtests/authです。
DB migration、billing、外部API連携は変更しないでください。
実装後にpnpm test tests/authを実行し、未実行なら理由を報告してください。

これだけでも、後半のcompactがかなり楽になります。最初のpromptが曖昧だと、compact後のsummaryも曖昧になります。

途中でcompactする基準を作る

条件

途中でcompactする基準は、チームごとに決めます。おすすめは次の5つです。

• 調査が一区切りついた
• 方針が決まった
• subagentの結果を統合した
• 実装へ入る前に文脈を軽くしたい
• レビューへ渡す前に要約したい

ただし、未決定事項が多い状態でcompactすると、迷っていたことが決まったように残る危険があります。compact前に「決まったこと」と「まだ迷っていること」を分けます。

決まったこと:
- timeout後はlogin redirectではなくsession refreshを先に試す
- src/auth/session.tsだけを変更する

未決定:
- refresh失敗時のtoast文言
- mobile layoutの表示確認

この状態で/compact focus ...を使うと、次の作業が読みやすくなります。

引き継ぎ前に残す証拠を固定する

評価基準

handoff前には、次の項目を残します。

• 変更ファイル
• 差分の意図
• 実行コマンド
• 成功した検証
• 失敗した検証
• 未実行の理由
• 残リスク
• 次に見るファイル
• 参照した公式Docs

別メンバーが/resumeや新しいsessionで続きを始めた時、最初の10分で状況を取り戻せる粒度が目安です。逆に、handoff summaryを読んでも「何を変えたのか」「何が未確認なのか」が分からないなら、compact前の整理が足りません。

結果として期待できること

方針の混線が減る

古い会話に引きずられて別方針へ進むことが減る

summaryをレビューできる

compact後に何が残ったかをチームで確認しやすくなる

memoryの置き場が明確になる

毎回必要なルールと一時的な知見を分けられる

subagentの成果を使いやすい

調査結果をmain conversationの判断材料として戻しやすくなる

作業速度だけでなく、再開性、レビュー性、引き継ぎやすさを成果として見ます。

この運用にすると、Claude Codeを長く使う時の失敗が減ります。特に効くのは、依存関係更新、認証や権限まわりの修正、E2Eテスト修復、複数ファイルにまたがるリファクタリングです。

期待できる変化は次の通りです。

• 古い会話に引きずられて別方針へ進むことが減る
• compact後のsummaryがレビュー可能になる
• memoryに入れるべきものと入れないものが分かれる
• subagentの調査結果がmain conversationを汚しにくくなる
• handoff時に、検証結果と未確認点を残しやすくなる

ただし、これはClaude Codeの性能を上げる魔法ではありません。人間側が、作業単位、残す文脈、止める条件を設計するための運用です。雑に広げると、CLAUDE.mdが肥大化し、auto memoryが古くなり、subagent結果が長くなり、結局main conversationが重くなります。

よくある失敗はcompaction前に潰す

指示が消えたように見える

重要な指示をconversationだけに置いている。必要なら`CLAUDE.md`へ移す

memoryを何でも置き場にする

共有すべき知見と個人の一時メモを混ぜない

settingsとmemoryを混同する

強制したい制約はmemoryではなくsettingsやhooksで扱う

subagentsを増やしすぎる

返却が長くなり、main conversationが読みにくくなる

compactは後始末ではなく、残す情報を選ぶ操作です。失敗しやすい置き場所を先に直します。

ここからは、チーム導入で起きやすい失敗を先に潰します。

compact後に指示が消えたように見える

原因

原因は、重要な指示をconversationだけに置いていたことです。project-rootのCLAUDE.mdはcompaction後にも再注入されますが、会話だけで伝えた指示は要約に入らなければ薄くなります。nested CLAUDE.mdやpath-scoped rulesは、該当ファイルを読むまで効き方が見えにくい場合もあります。

対策は単純です。永続させるべき指示はconversationから出します。

• チーム標準はroot CLAUDE.md
• pathごとの注意はrules
• 必ず止める操作はsettingsやhooks
• 使い回す手順はRunbookやSkill
• 一時的な判断はcompact summary

CLAUDE.mdとauto memoryを何でも置き場にする

注意点

CLAUDE.mdに何でも書くと、毎回contextを消費します。auto memoryに何でも残すと、古い仮説が後から効くことがあります。どちらも便利ですが、片付けないとノイズになります。

チームでは、次のルールを置くとよいです。

• CLAUDE.mdは毎回必要なルールだけにする
• auto memoryは/memoryで監査する
• 秘密情報、顧客情報、非公開URL、APIキーは保存しない
• チーム共有すべき知見はdocsへ移す
• 古くなったmemoryは消す

settingsとmemoryを混同する

権限境界

「Claudeに覚えさせたから大丈夫」は、危険操作の対策として弱いです。本番DB更新、secret読み取り、外部送信、破壊的git操作、権限昇格は、memoryではなくsettings、permissions、hooksで止めます。

たとえば、CLAUDE.mdに「本番DBを触らない」と書くだけでは、曖昧な場面で守られない可能性があります。denyやapprovalのルールに落とし、必要ならPreToolUse系のhookで理由つきで止めるほうが実務向きです。

subagentsを増やしすぎてmainが読めなくなる

確認項目

subagentsを増やすと、並行調査は進みます。その一方で、各subagentの結果を全文でmainへ戻すと、main conversationがまた重くなります。

対策は返却粒度を固定することです。

Return only:
- conclusion
- evidence files
- unresolved risks
- recommended next action
Do not paste full logs unless asked.

これは小さいルールですが、効きます。調査を分けるだけでなく、戻す情報を絞るところまでがsubagent運用です。

実務で使うなら

1. Day 1

   `CLAUDE.md`を短く整理し、毎回必要な情報だけにする

2. Day 3

   `/context`と`/memory`の確認タイミングを作業前に固定する

3. Day 5

   `/compact focus …`のテンプレートを1つ決める

4. Day 10

   subagentsへ渡す調査範囲と返却形式を見直す

5. Day 14

   summaryで再開できたか、未実行テストや残リスクが残っていたかを確認する

成果は作業時間だけで見ず、再開できたか、レビューできたか、残リスクが見えたかで判断します。

最初から全社標準にしないほうがよいです。まず1repo、1種類の作業でpilotします。おすすめは、依存関係更新、bugfix、テスト修復、docs更新のどれかです。成果を「作業時間」だけで見ず、context運用の質で見ます。

2週間pilotの進め方

評価基準

日程	やること	見るもの
Day 1	CLAUDE.mdを短く整理	毎回必要な情報だけか
Day 3	/contextと/memoryを作業前に見る	重い要素、読まれるmemory
Day 5	/compact focus ...の型を試す	引き継ぎsummaryの質
Day 8	subagentへ調査を委譲	mainへ戻す量
Day 10	Runbook化する	開始前、途中、handoff

記録するのは、何分短縮できたかだけではありません。

• compact後のsummaryを読んで再開できたか
• 未実行テストや残リスクが残っていたか
• CLAUDE.mdへ入れるべきでない情報が増えていないか
• subagentが長すぎる結果を返していないか
• settingsやhooksで止めるべき操作をmemoryに逃がしていないか

チーム標準にする前にレビュー観点を決める

確認項目

Claude Codeのcontext運用は、リポジトリの開発体験に直接効きます。だから、次の変更はレビュー対象にします。

• CLAUDE.md
• project rules
• settings
• hooks
• subagent定義
• MCP server追加
• memoryに保存してよい情報のルール
• Runbook

便利になったかだけでなく、権限、秘密情報、出力量、責任境界を見ます。特にMCPや外部API連携がある場合、toolが何を読めるか、何を送れるか、人間承認がどこにあるかを別で確認します。

セキュリティ・コスト注意

secretを保存しない

APIキー、credential、個人情報、顧客情報をmemoryへ残さない

ログを絞る

大量ログは必要箇所だけ抽出し、不要な内部URLや識別子を入れない

本番操作を止める

外部送信や本番変更はpermissionsやhooksで制御する

subagentの範囲を明記する

読ませてよいファイル、戻してよい情報、避ける情報を依頼時に書く

セキュリティとコストは単純な勝敗ではなく、情報の種類、保存先、操作権限で条件を分けて管理します。

context運用は、セキュリティとコストにも関係します。大量のログやファイルをmain conversationへ入れると、token消費が増えます。さらに、ログにsecret、内部URL、顧客識別子、非公開リポジトリ情報が混ざっていると、そのままmemoryやsummaryに残る危険があります。

最低限、次のルールを置いてください。

• APIキー、secret、個人情報、顧客情報をmemoryへ保存しない
• .env、credential、production dumpを読ませない
• 本番操作や外部送信はpermissionsやhooksで止める
• subagentに読ませてよい範囲を依頼時に明記する
• compact summaryに機密情報を残さない
• 長いログは要約し、raw logをmainへ貼りすぎない

コスト面では、/compactで短くすれば常に安くなる、と単純には言い切れません。作業のために何度も読み直す、subagentを増やす、長いmemoryを毎回読み込む、外部toolを多用する。こうした運用もtokenと時間を使います。チームでは、完了条件、停止条件、handoff形式を揃えることのほうが、単発のtoken節約より効く場面が多いです。

なお、この記事にはスポンサー、アフィリエイト、検証環境提供はありません。公式DocsとローカルCLI確認をもとに、運用設計として整理しています。

FAQ

`/compact`か`/clear`か

同じ作業を続けるなら`/compact`、別作業へ切り替えるなら`/clear`

auto memoryの共有

machine-localなので、そのままチーム共有のナレッジベースにはしない

subagentで常に軽くなるか

長い返却を戻せばmain conversationも重くなる

`CLAUDE.md`の長さ

長いほど毎回contextを使うため、毎回必要な情報へ絞る

外部メモリ層との分担

個人の思い出し、チーム標準、検索可能な外部知識を分けて置く

迷った時は、次のpromptで前の議論が必要かどうか、チームで共有すべき情報かどうかで切り分けます。

/compactと/clearはどちらを先に使うべきですか

回答

同じ作業を続けるなら/compact、別作業へ切り替えるなら/clearです。迷う場合は、次のpromptで前の議論が必要かどうかで判断します。必要なら残す。不要なら切る。それだけです。

auto memoryをチーム共有のナレッジベースにできますか

注意点

そのまま共有前提にはしないほうがよいです。auto memoryはmachine-localで、人によって内容が違います。共有すべき知見はreviewして、CLAUDE.md、docs、Runbookへ移します。

subagentに任せればmain conversationは常に軽くなりますか

条件

いいえ。subagentの大きな結果をmainへ戻せば、main conversationも重くなります。効果が出るのは、self-containedな調査を任せ、戻す情報を結論、根拠、未確認点、次の一手に絞った時です。

CLAUDE.mdは長くても問題ありませんか

判断基準

長いほど毎回contextを使い、守られにくくなる可能性があります。毎回必要な情報だけを残し、pathごとの注意はrules、手順はRunbookやSkill、外部接続はMCP設定へ分けるほうが扱いやすいです。

Agentmemoryのような外部メモリ層とはどう分けますか

分担

この記事ではClaude Code公式機能の運用に絞っています。Agentmemoryのような外部メモリ層は、複数agentや複数sessionをまたぐ永続文脈の話です。導入する場合も、まずは保存してよい情報、削除手順、チーム共有の範囲、権限を決める必要があります。詳しくは公開済みの<a href="https://ai-dev.blog.mo-gmo.com/agentmemory-codex-claude-code-persistent-memory-evaluation/">AgentmemoryをCodex/Claude Codeに入れる前に</a>で整理しています。

関連する実務導線

1. 1context運用

   `/compact`、`/clear`、memory、subagentsの使い分けを決める

2. 2チーム向けAGENTS.md

   権限、禁止操作、テスト、レビュー観点を明文化する

3. 3複数agent運用

   Codex、Claude Code、他のagentで共通するルールをそろえる

4. 4レビューゲート

   変更前後の確認、未実行テスト、残リスクをレビューに載せる

context windowの整理は単体の工夫ではなく、チームの指示ファイルとレビュー手順へつなげて定着させます。

Claude Codeのcontext運用を決めたら、次はチームの指示ファイルとレビューゲートへ接続します。CLAUDE.mdだけでなく、Codexや他のagentも使うチームでは<a href="https://ai-dev.blog.mo-gmo.com/team-agents-md-template-permissions-tests-review/">チーム向けAGENTS.mdテンプレート</a>を確認すると、権限、禁止操作、テスト手順、レビュー基準を揃えやすくなります。

CodexとClaude Codeを同じrepoで使う場合は、contextだけでなく権限、レビュー、コストの境界も必要です。併用設計は<a href="https://ai-dev.blog.mo-gmo.com/codex-claude-code-dual-agent-workflow-permissions-review-cost/">CodexとClaude Codeを同じリポジトリで併用する前に</a>で扱っています。

更新通知を追いたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>でAIコーディングエージェント、MCP、memory運用、権限設計の更新をまとめて確認できます。チーム導入、CLAUDE.md整理、MCP設計レビュー、HooksやRunbook作成をまとめて進めたい場合は、記事末尾のお問い合わせ導線から相談できます。

次に読むなら

参照した主な情報源

• https://code.claude.com/docs/en/context-window
• https://code.claude.com/docs/en/commands
• https://code.claude.com/docs/en/memory
• https://code.claude.com/docs/en/sub-agents
• https://code.claude.com/docs/en/features-overview

更新履歴

1. 2026.06.11

   Claude Code公式Docsのcontext window、commands、memory、sub-agents、features overviewを確認

2. ローカル確認

   `claude –version`が`2.1.138 (Claude Code)`であることを確認

3. 需要シグナル

   Xの投稿は需要シグナルとして扱い、本文の事実根拠には使わない

コマンド名や仕様は変わる可能性があるため、更新履歴で確認日と根拠の扱いを残します。

• 2026.06.11: 初版公開。Claude Code公式Docsのcontext window、commands、memory、sub-agents、features overviewを確認し、ローカルではclaude --versionが2.1.138 (Claude Code)であることを確認しました。Xの投稿は需要シグナルとして扱い、本文の事実根拠には使っていません。