なぜ離職によってコンテキストが失われるのか
アカウントが削除された瞬間、チャットはアクセス不能になる
これは最も明確な境界線であり、Anthropicは次のように明確に文書化しています。「ユーザーがTeamまたはEnterprise組織から削除されると、残りのメンバーはそのユーザーのチャットにアクセスできなくなります。」
これは共有リンクにも適用されます。ヘルプセンターには、ユーザーが遭遇するメッセージさえ記載されています。「会話が見つかりません。要求された会話は存在しないか、アクセス権限がありません。」 6ヶ月前に誰かがチケットに貼り付けたリンクは、機能しなくなります。
データが消えたわけではありません。「削除されたユーザーのデータは、組織のプライマリーオーナーが実行するデータエクスポートに引き続き含まれます」が、管理者によるエクスポートはコンプライアンスのための手段であり、火曜日の午後に質問に答えるための方法ではありません。
プライベートプロジェクトは、その人が去った後もプライベートのまま
プロジェクトの公開範囲はプロジェクト作成時に決定され、メンバーの削除によってそれが緩和されることはありません。「プロジェクトの公開範囲がプライベートに設定されていた場合、チームメンバーがアカウントから削除されると、組織の他のメンバーはそのプロジェクトにアクセスできなくなります。」
文書化されている解決策は、退職する人に作業を委ねています。「チームメンバーが、引き継ぎたいプライベートプロジェクトで何か作業していることを知っている場合、組織内の全員が編集できるようにプロジェクトの権限を調整するか、特定のユーザーを招待して『編集可能』権限を付与する必要があります。」
これは設計としては正しいですが、プロセスとしては脆弱です。退職前の最後の1週間に、他の人がどのプロジェクトを必要とするかを本人が覚えているかどうかに依存するからです。
個人のメモリは、意図的に個人のものである
Claudeのメモリ（記憶）はユーザーごとのストアです。TeamおよびEnterpriseプランでは、オーナーがこの機能を利用可能にするかどうかを制御できますが、Anthropicの言葉を借りれば、「オーナーはユーザー個人のメモリを表示または編集することはできません」となります。
これはプライバシー保護であり、そうあるべきです。しかし、それはClaudeがその人の仕事のつながり（専門用語、繰り返される制約、関係者など）について学習したすべての内容が、検索可能な意味での組織の知識にはならないことを意味します。それを引き継ぐことができるビューは存在しません。
コーディングツールも同様に分かれており、その境界はパスにある
意識して見るとこのパターンは繰り返されており、通常はファイルパスで確認できます。
Claude Codeは、./CLAUDE.mdからプロジェクトの指示を読み込みます。これは公式ドキュメントで「ソース管理を介してチームメンバーと共有される」と説明されています。個人の指示は~/.claude/CLAUDE.mdに保存され、「あなただけ（すべてのプロジェクト）」にスコープされます。そして、自動メモリ（Claudeが修正や決定について自身のために書き留めるメモ）は~/.claude/projects/<project>/memory/に置かれ、「マシンローカルである」こと、および「ファイルはマシン間やクラウド環境間で共有されない」という明確な警告が伴います。ノートPCが初期化されれば、それでおしまいです。
Cursorは、Project Rulesを.cursor/rulesに配置し、これらは「バージョン管理される」と述べています。User Rulesは個人用です。Team Rulesは中央で管理され、「そのチームのすべてのリポジトリとプロジェクトにわたってAgent (Chat)のモデルコンテキストに含まれ」ます。そして、Plan Modeには知っておくべきデフォルト設定があります。「プランはデフォルトでホームディレクトリに保存されます。『Save to workspace』をクリックすると、将来の参照、チーム共有、ドキュメント化のためにワークスペースに移動します。」 誰もそのボタンをクリックしなかったプランは、すべて個人用ファイルになります。
Clineは、その意図について非常に率直です。そのガイダンスでは、プロジェクト設定を「リポジトリに付随すべきチーム共有の動作」に使用し、「チームと共有したい.cline/ファイルをコミットする」ことを推奨しています。グローバルルールはリポジトリの外、~/.cline/および~/Documents/Cline/Rulesに置かれます。
Kiroは、.kiro/steering/にあるワークスペースのステアリングと、~/.kiro/steering/にあるグローバルなステアリングを分離しており、そのCrewメモリレイヤーは~/.kiro/crew/workspace/memory/の下に存在します。Kiro Webの学習されたメモリはさらに狭くスコープされています。「タスクを作成したユーザーとしてのあなたのフィードバックのみが、エージェントが学習する内容に影響を与えます。」
これら4つすべてに共通するルールは、「リポジトリにあれば残り、ホームディレクトリやアカウントにあれば消える」ということです。
よく試みられる対策
より長い退職インタビュー（引き継ぎ面談）。 有用であり、その人が思いついたことは記録できます。しかし、彼らが何年も前に気にするのをやめてしまった40個の小さな制約までは捉えられません。
最終日までにすべてをエクスポートする。 これで手に入るのはアーカイブであり、リソースではありません。Anthropicは、削除されたユーザーのデータが組織のエクスポートに残ることを指摘しており、ほとんどのツールには何らかのエクスポートパスがあります。しかし、会話のzipファイルは、質問が生じたときに誰も検索するようなものではありません。
プロジェクトを共有するように依頼する。 正しい方法であり、文書化されている解決策です。しかし、最も忙しい最後の2週間の間に、来期に誰がどのプライベートプロジェクトを必要とするかを予測することを退職者に求めることになります。
「念のため」アカウントを開いたままにする。 よくあることであり、コストがかかります。そして通常、オフボーディングのチェックリストに含まれない、所有者のいないログインアカウントを生み出すことになります。
一時的に再追加する。 これはClaudeで実際に機能します。「チームメンバーが削除され、後に同じメールアドレスを使用して同じ組織に再度追加された場合、以前のチャット、プロジェクト、スキルが復元されます。」 これは緊急時の現実的な復旧パスです。しかし、これは計画とは言えませんし、すでに別の場所で働き始めている人に頼むこととしては奇妙です。
ドキュメントを増やす。 直感としては正しいですが、ターゲットが間違っています。ドキュメントはページに答えますが、質問には答えが必要です。そのギャップについては、プロジェクトドキュメントをAIメモリに変換する方法で説明されています。
解決策：メンバーが在籍しているうちに、共有知識を共有の場所に書き込む
この問題を扱いやすくするための再定義：退職した後に誰かのコンテキストを復元しようとするのではありません。最初から組織のものであった部分が、常に組織の場所に存在するようにすることです。
この区別により、尊重すべき境界線の正しい側に留まることもできます。退職する同僚の個人のメモリ、プライベートプロジェクト、共有されていないスキルは彼らのものです。Anthropicは、共有されていないスキルは「彼らのアカウントに残り、復元可能である」こと、およびオーナーは個人のメモリを読み取ることができないことを明示しています。それらをターゲットにするべきではありません。あなたが本当に必要としているのは、チームの知識です。決定事項、制約、理由、および個人ではなくプロジェクトにとって真実であった事柄です。
それこそが、MemoryLakeが保持するものです。これは、個人のアカウントではなくワークスペースによって所有され、ツールがクエリを実行する共有メモリレイヤーです。セットアップは3つのステップで行えます。
ステップ 1: APIキーを作成する
サインインして、ワークスペースのAPIキーを作成します。この認証情報はチームに属しているため、個人と一緒に失われることはありません。
ステップ 2: 最初のメモリをアップロードする
1つの主張につき1つの短いエントリを作成します。最も価値のあるアプローチは、1人のメンバーと向き合い、その人だけが知っていることを書き留めることです。記録すべき内容：
理由が紐付けられた決定事項。 「Q1のコンプライアンスレビューで地域間レプリケーションが除外されたため、地域ごとではなくテナントごとにシャードしています。」 決定はコードにありますが、理由は一人の頭の中にあります。
すでに却下されたアプローチ。 最も議論が再燃しやすいカテゴリであり、ドキュメントにもコミットメッセージにも現れないものです。
誰も教えてくれない環境の事実。 別のジョブの前に実行しなければならないジョブ。誰も文書化していないベンダーの制限。CIでのみ失敗するテスト。
誰が何を、平易な言葉で。 壊れたものをどのチームが所有しているか。その奇妙な回避策はどの顧客のためのものか。そのサービスの内部名が実際に何を指しているか。
システムを支えている回避策。 どのチームにも2、3個はあります。これらは、それを維持している人が去るまで目に見えません。
ステップ 3: AIとエージェントを接続する
チームが使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、Claude Code、Cursor、Cline、Codex、OpenClawなどのMCPネイティブエージェントはMCPサーバーを指定することで接続し、他のアシスタントはAPIを介して同じメモリを読み取ります。これにより、新入社員の最初の1週間は、誰のアカウントにもアクセスすることなく、退職した人が持っていたのと同じ回答からスタートできます。このクロスツール構成については、ナレッジワーカーのためのクロスツールメモリで説明されています。
3つの率直な制限事項。MemoryLakeは、ベンダー側にある個人のメモリ、チャット、またはプライベートプロジェクトを読み取り、復元、またはインポートすることはできません。 これらは各ベンダーの製品内のアクセス制御下にあり、そうあるべきです。MemoryLakeは、あなたやエージェントが入力したものだけを保持するため、ステップ2は人間による意図的な作業となります。また、これはオフボーディングのコンプライアンスツールではありません。退職する従業員の活動の公式な記録が必要な場合は、メモリレイヤーではなく、保持ポリシーに基づく管理者エクスポートを使用してください。
実務における変化
オフボーディングが「知識の搾り出し作業」ではなくなります。 知識はすでにチームが所有する場所に書き込まれています。
初期化されたノートPCが問題にならなくなります。 マシンローカルの自動メモリが唯一のコピーではなくなります。
「なぜこの方法にしたのか？」に対する答えが手に入ります。 誰に聞けばいいかを知っている人だけでなく、質問した人全員がアクセスできます。
オンボーディングが本質的な理由で短縮されます。 新しいメンバーは、4人の手を止める代わりに、同じレイヤーにクエリを実行できます。
「デフォルトでプライベート」が地雷ではなくなります。 退職前の最後の1週間に、誰かが権限を変更するのを忘れないように祈る必要はありません。
ベンダーのメモリは個人のままでよく、それで問題ありません。 それを組織のものにする必要がなくなりました。この一般的な区別については、永続メモリが実際に意味することで説明されています。
離職時にコンテキストを維持するためのベストプラクティス
スタック内の境界線がどこにあるか、一度監査する。 各ツールについて、何がリポジトリにあり、何がホームディレクトリやアカウントにあるかを特定します。1時間もあれば終わり、それがすべての診断になります。
プロジェクトのデフォルトの公開範囲を組織にする。 プライベートにするのは理由がある場合の決定であるべきで、誰も選択しなかったときの結果であってはなりません。
「Save to workspace」を救済策ではなく習慣にする。 Cursorのプランはデフォルトでホームディレクトリに保存されます。他の多くのものも同様です。
共有レイヤーをコミットする。 .cursor/rules、.cline/、.kiro/steering/、./CLAUDE.md — これらはすべて設計上、リポジトリ内に配置されます。そのように使用してください。
ルールだけでなく、理由を書く。 ルールはバージョン管理に残ります。しかし、それが存在する理由は通常残らず、それこそが来年そのルールが元に戻されるのを防ぐものです。
知識の引き継ぎは退職予告期間の最初に行い、最後には行わない。 最後の1週間は事務手続きのためのものです。
彼らが気にするのをやめたことについて尋ねる。 「どこにも書かれていないことで、あなたが知っていることは何ですか？」と聞くと肩をすくめられますが、「最後に新しく入った人に何を説明しなければなりませんでしたか？」と聞けば、リストが得られます。
彼らの所有物を尊重する。 個人のメモリ、共有されていないスキル、プライベートプロジェクトは個人に属します。チームが必要とするものを共有するよう依頼し、彼らのアカウントを資産として扱わないでください。
結論
離職によってこれほど多くのコンテキストが失われる理由は、削除ではなくアクセス権です。アカウントが削除された瞬間、チャットはアクセス不能になります。Anthropicはこれを直接述べており、ユーザーが表示されるエラーメッセージまで文書化しています。プライベートプロジェクトはプライベートのままであり、文書化されている解決策では、退職する本人が権限を変更する必要があります。個人のメモリは個人のままであり、オーナーは明示的にそれを読み取ることができません。Claude Codeの自動メモリはマシンローカルであり、ノートPCの初期化によって失われます。Cursorのプランはデフォルトでホームディレクトリに保存されます。KiroのCrewメモリはユーザーのホームパスの下に置かれます。Kiro Webはタスク作成者自身のフィードバックからのみ学習します。
これらはどれも妥当な設計であり、いくつかは削除してほしくないプライバシー保護機能です。これらが総合して意味することは一つです。チームのコンテキストのうち、リポジトリに存在する部分は離職を乗り越えて存続し、アカウントやノートPCに存在する部分は存続しないということです。
ですから、この区分を意図的なものにしてください。使用している各ツールで境界線がどこにあるかを監査し、プロジェクトのデフォルトの公開範囲を組織に設定し、共有レイヤーをコミットし、決定事項、理由、および却下されたアプローチをワークスペースが所有するメモリレイヤーに保存してください。メンバーがまだ在籍しているうちに行ってください。誰かが辞めるからではなく、その時だけが簡単に行える唯一のタイミングだからです。