Anthropicの公式メモリ文書は、少なくとも「プロジェクト単位」と「ユーザー単位」の記憶を分けて説明しています。公式のMemory仕様に照らすと、Claude Code Projects 共有メモリの検収は、画面に情報が表示されるかではなく、別セッションで再現できるか、更新が反映されるか、権限を越えて拡散しないかまで確認する作業です。
症状：新しいAgentが同じプロジェクトに入っても、規約や作業状態を誤って解釈する。
最短解決策：記憶の出所、適用範囲、更新責任者を表にし、再利用・変更・分離・復旧の順で実行ログを残してください。
このページは、個人開発者、小規模な開発チーム、クラウド型の開発環境を管理する担当者向けです。単にClaude Code Projectsの使い方を知りたいだけなら、まずClaude Code向けMacレンタルの利用方法を確認し、実際の作業環境が必要な場合だけ検収項目を使ってください。
共有メモリとして何を検収するのか
「記憶」という言葉で、異なる状態を一つにまとめてはいけません。最初に次のように分離します。
| 対象 | 主な内容 | 検収で確認すること |
|---|---|---|
| Project Knowledge | プロジェクト資料、設計文書、参照用の知識 | どのAgentが読めるか、更新後に再取得されるか |
CLAUDE.md |
コーディング規約、テストコマンド、ディレクトリ方針 | 現在の作業場所で読み込まれ、実際の操作に反映されるか |
| 個人メモリ | 個人の好み、作業上の習慣、ユーザー固有の設定 | 他のメンバーやAgentへ意図せず広がらないか |
| セッション履歴 | 過去の会話、途中の判断、未完了タスク | 新しいセッションや再開操作でどこまで戻るか |
| Git・外部状態 | ブランチ、コミット、Issue、成果物、環境変数 | 記憶とは別に、状態を再現できるか |
Projectsの共有範囲や表示項目は、契約やアカウント、現在の製品仕様によって異なる可能性があります。Projectsの作成・管理に関する公式説明と、Projectsの共有機能に関する公式説明を基準にしつつ、最終判定は自分のアカウントで行ってください。
「現在のセッションで見えている」ことは、「すべてのAgentが安全に再利用できる」ことを意味しません。個人設定、プロジェクト制約、作業状態、秘密情報を同じファイルや同じProject Knowledgeに詰め込むと、便利さと引き換えに境界が崩れます。
個人開発者は、別セッションで同じ判断を再現できるか
個人利用では、記憶が存在するかより、説明を毎回やり直さずに同じ制約が守られるかを見ます。
Claude Code Projectsの共有記憶は、別セッションでも本当に効くのでしょうか。
同じプロジェクトを開き、最初のセッションでは「テストコマンド」「主要ディレクトリ」「禁止している実装」を明示します。次に新しいセッションを開始し、これらを直接答えさせるのではなく、実際の調査や修正を依頼してください。モデルが規約を引用しただけでなく、変更対象や実行コマンドを正しく選べたかを記録します。
検収は次の5段階で行うと、口頭確認に頼らずに済みます。
第一歩：基準状態を固定する
検証用の小さなタスクを1つ決め、開始時刻、作業ディレクトリ、Gitブランチ、対象ファイルを記録します。会話の中で一度だけプロジェクト規約を参照させ、モデルの返答ではなく、読み込まれたファイルと実際の変更を証拠にします。
第二歩：記憶の再利用を試す
セッションを終了し、同じProjectで新しいセッションを開始します。テストコマンドを実行させ、ディレクトリの説明に沿ってファイルを探させます。新しいセッションで以前の会話を知らない状態でも正しい行動ができれば、再利用性の証拠になります。
第三歩：古いルールを無効化する
「テストはA」と書かれていた規則を「テストはB」に変更し、ファイルの変更履歴とGit差分を保存します。その後に新しいセッションを開き、Aを使わずBを使うか確認します。古い情報を答えた場合、記憶機能の不具合とは限らず、別ファイルの重複、コンテキストへの残存、変更の未同期を疑います。
第四歩：履歴とファイルを分けて確認する
会話を再開したときに前回の判断が見えても、それはプロジェクト記憶が読み込まれた証拠ではありません。CLIの再開・継続操作は、セッション履歴の復元と、プロジェクトの指示ファイルの読み込みを別々に確認してください。公式CLIリファレンスには、セッション操作に関係する引数が整理されています。
第五歩：証拠を一つの記録にまとめる
セッションID、作業ディレクトリ、参照した記憶ファイルのバージョン、Gitのブランチと状態、実行したコマンド、生成された差分を保存します。「覚えていたように見えた」という感想は、再検収に使える証拠にはなりません。
Claude Codeのプロジェクト記憶と個人記憶はどう区別しますか。
プロジェクトの全員が守るルールはProject Knowledgeやプロジェクト用のCLAUDE.mdへ置き、個人の好みやローカルな補助設定はユーザー側へ分けます。プロジェクトに不要なエディター設定、個人の命名嗜好、認証情報を共有領域へ入れないことが境界管理の基本です。
小規模チームは、複数Agentの文脈と成果物を分離できるか
複数Agentで同じプロジェクトを扱う場合、共有すべきなのは「不変の規約」と「参照可能な設計知識」です。担当者ごとの一時判断や未完了タスクまで同じ記憶へ書くと、あるAgentの仮説が別のAgentの前提として残ります。
複数のAgentは、どのように同じプロジェクト文脈を共有すればよいのでしょうか。
共通ルール、タスク状態、一時的な意思決定を保存先で分けます。共通ルールはレビュー対象の文書、一時状態はIssueや作業ログ、生成物は担当ブランチと専用ディレクトリに置きます。Gitブランチが分かれていても、同じ外部フォルダーや共有環境変数を使えば完全な隔離にはなりません。
検収時は、メンバーAとAgent Bに同じ質問をするだけでなく、同じ変更要求を別々に実行させます。参照する規約、変更対象、テスト方法が一致するかを比べ、成果物の出力先が重ならないことも確認してください。
判定条件で選ぶ運用方法
- プロジェクト規約だけを全員に適用したい場合は、レビュー済みの
CLAUDE.mdとProject Knowledgeを共有し、変更は所有者の承認制にします。 - タスク状態を頻繁に更新する場合は、共有メモリへ直接追記せず、Git、Issue、作業ログなど履歴が残る場所へ外部化します。
- Agentごとに異なる実験をさせる場合は、専用ブランチだけでなく、作業ディレクトリ、成果物の保存先、実行権限も分けます。
- 同じ記憶を読めても成果物が衝突する場合は、共有範囲を広げず、まず出力先とロック方法を見直します。
- 規約の更新頻度が高い場合は、共有メモリを唯一の正本にせず、Git管理された文書を正本に戻します。
管理者は、権限・秘密情報・クラウド復旧をどう確認するか
プラットフォーム管理者の検収対象は、記憶の正確さだけではありません。誰が読めるか、どのネットワークへ接続できるか、セッション終了後に何が残るかを分けて確認します。
Claude Code Projectsに秘密情報を書かないためには、何を調べればよいのでしょうか。
アクセストークン、内部URL、個人の作業習慣、顧客情報、接続手順をサンプル記憶へ入れないでください。既存の記憶ファイルとProject Knowledgeを定期的に検索し、秘密情報のパターン、個人情報、社内限定の接続先を確認します。権限の検証では、認証、ファイル、Git、ネットワークを別レイヤーで試します。公式のIAM文書も参照し、実際の組織設定との差分を記録してください。
クラウド型のAI開発ワークスペースでは、次の状態を個別に検証します。
- セッションを中断した後、同じ会話を再開できるか。
2.作業ディレクトリと未コミット変更が残るか。 - コンテナやワークスペースを再作成した後、どのファイルが戻るか。
- Gitブランチ、リモート、認証状態が同じか。
- Agentが前回と同じネットワーク権限を持つか。
クラウド上のClaude Codeセッションが中断した場合、プロジェクト状態はどこまで戻るのでしょうか。
会話履歴が戻っても、未コミットのファイル、外部サービスの状態、作業中のプロセスまで復元されるとは限りません。復旧を「会話」「ファイル」「ブランチ」「認証」「ネットワーク」の5層に分け、各層に復元手順を用意します。長いタスクでは、文脈が圧縮された後も必要な状態を追えるよう、判断と次の作業を外部ログへ書き出します。公式のコンテキスト管理に関する説明も、長い処理の設計材料になります。
注意：Gitブランチは変更履歴の分離には役立ちますが、秘密情報、プロセス、ネットワーク権限、共有ボリュームまで分離する仕組みではありません。ブランチが違うだけで安全と判定しないでください。
記憶が効かないときは、どの層から調べるか
回答が誤っていたとき、すぐに「共有メモリが機能していない」と決めないでください。次の順序なら、原因の切り分けが速くなります。
- ファイル未読：対象の
CLAUDE.mdやProject Knowledgeが本当に参照されたか確認します。 - パス不一致：起動ディレクトリが想定と違わないか、親ディレクトリの指示が適用される場所か調べます。
- 規則の衝突：個人設定、プロジェクト設定、会話中の指示が矛盾していないか比較します。
- コンテキスト圧縮：長い会話の後に、重要な制約が失われていないか確認します。
- ブランチ未同期：変更した記憶ファイルが現在のブランチや作業環境に存在するか調べます。
- 権限拒否：読み取り権限、認証、ネットワーク制限で参照できなかった可能性を確認します。
個人利用なら再現タスクを一つ、小規模チームならAgentとメンバーを一組、管理者なら新規ワークスペースと復旧後のワークスペースを比較します。各検証にセッションID、作業場所、記憶ファイルのコミット、Git状態を添えれば、回答の誤りと記憶の欠落を区別できます。
チーム導入後も、何を定期的に再検収するか
導入時だけ合格しても、Claude Code、クラウドワークスペース、Agent設定の更新で挙動が変わる可能性があります。記憶ファイルには所有者、レビュー周期、変更理由、承認者を付け、秘密情報のスキャンを自動化します。Projectsの検索拡張を利用する場合も、ProjectsのRAGに関する公式説明を確認し、知識の更新と検索結果の妥当性を別々に評価してください。
最低限の再検収は次の通りです。
- 個人：新規セッションで規約、テスト、ディレクトリ説明を再現する。
- 小規模チーム：複数Agentが同じ正本を読み、別の一時状態を混ぜないことを確認する。
- プラットフォーム管理者：権限、秘密情報、ファイル、ブランチ、ネットワーク、復旧状態を層別に確認する。
- 全員：規約変更、ツール更新、ワークスペース再作成の後に固定タスクを再実行する。
現在の共有クラウド環境だけで運用すると、会話履歴とファイルの保存先が分かれ、権限変更の追跡が難しくなり、再起動時に未コミット状態や依存環境を失うことがあります。ローカルMacだけに寄せる方法も、複数Agentの同時実行、接続経路、端末管理が負担になりやすい選択です。
一方、Macを固定した検証用ワークスペースとして使えば、開発ツール、ファイル、Git状態を同じ実行環境で確認しやすくなります。短期の検収、チームの再現テスト、クラウド環境へ移す前の比較であれば、KvmzenのMacレンタル環境を候補に入れる価値があります。長期の常時稼働や物理デバイス接続が必要なら自社所有環境を選び、期間限定の検証や一時的なAgent作業なら、Kvmzenのレンタルでこの検収表を実際のリリース手順へ組み込むのが現実的です。