なぜチームのAIメモリがまだ存在しないのか
個人のメモリは設計上、個人用である
そうでなかった場合に何が起こるか考えてみてください。もしあなたのアシスタントのメモリが同僚のメモリとプールされていたら、あなたがこれまでに伝えたすべてのこと（下書き、未完成の意見、自分自身の仕事の習慣など）が同僚の回答に現れてしまうでしょう。すべてのベンダーが同じ結論に達しています。メモリはそれを作成したアカウントに帰属する、ということです。
OpenAIはさらに踏み込んで、ワークスペースへの影響をドキュメント化しています。ワークスペースのオーナーがワークスペースのメモリをオフにすると、「そのワークスペースのメンバーの既存の保存済みメモリは削除されます」。メモリは組織レベルの管理下にあるメンバーごとの機能であり、共有資産ではありません。
ベンダーがチームに提供しているレイヤーは、メモリではなく「指示」である
チームスコープの仕組みは実際に存在し、使用する価値はあります。ただ、それらは別のものです。Cursorは、TeamおよびEnterpriseプランのダッシュボードから管理されるチームルールをドキュメント化しています。GitHub Copilotには組織の指示（organization instructions）レイヤーがあり、優先順位は最下位（「個人の指示が最優先されます。次にリポジトリの指示、そして組織の指示が最後に優先されます」）ですが、モデルには提供されます。AGENTS.mdのようなリポジトリファイルは、バージョン管理下にあるため、定義上共有されます。
これらはすべて宣言的かつ静的です。誰かがルールを書き、全員がそれを適用されます。これは規約には最適ですが、チームが実際に失っているもの、すなわち「蓄積された知識」（3週間前の会議での決定、回避策が存在する理由、このアプローチの前に試したことなど）には役に立ちません。ベンダーのAPIのレート制限がドキュメントと異なっていることを記録するために、組織の指示ダッシュボードを開く人はいません。
共有プロジェクトスペースには双方向に壁がある
次に思いつくのは、共有プロジェクト機能でしょう。これは役立ちますが、ドキュメント化された境界線があります。OpenAIのProjectsのドキュメントには、「共有プロジェクトは、プロジェクト外の個々のメンバーのコンテキスト、カスタム指示、またはメモリにアクセスできません」と記載されています。つまり、プロジェクトを共有すると、意図的に個人のコンテキストから切り離されます。また、プロジェクトが共有されると、そのメモリモードが切り替わり、「デフォルトのメモリに戻すことはできません」。これらの壁は、クライアントワークや機密プロジェクトにとっては正しい判断ですが、共有プロジェクトがチームの脳ではなく、孤島であることを意味します。詳細については、ChatGPT Projectsがメモリを共有しない理由をご覧ください。
そして、エクスポートの経路はチームが活動するまさにその場所でブロックされている
少なくとも全員のデータを収集して手動で調整できると考えたなら、まず利用規約を確認してください。OpenAIのエクスポートドキュメントによると、ChatGPTの設定からリクエストされるエクスポートは「Free、Plus、Pro、および対象となるChatGPT Eduワークスペースで利用可能」であり、明示的に「ChatGPT BusinessまたはEnterpriseワークスペースでは利用不可」となっています。
つまり、ほとんどのチームが利用しているプランでは、調整のためのセルフサービスの一括エクスポートは存在しません。チームが共同で知っていることは、共有の場所に書き留められるか、あるいは決して交わることのない6つのプライベートなメモリに分散されたままになります。
人々が試みること
Wiki。 人間にとっては誠実な回答ですが、エージェントに対しては特定の理由で失敗します。Wikiはナラティブなドキュメントとして書かれているため、エージェントはページ全体、または取得されたチャンクを受け取るだけで、何が最新であるかの指標がありません。また、Wikiは静かに陳腐化し、アシスタントがそれを読んでも、そのページが3月のものかどうかは分かりません。
リポジトリ内の長い `AGENTS.md`。 バージョン管理されており、すべてのツールがそれを読み取るため、より良い方法です。しかし、すぐに限界に達します。Cursorはルールを500行未満に抑えることを推奨しており、Claude Codeはファイルあたり200行未満を推奨し、長いファイルは「より多くのコンテキストを消費し、遵守率を低下させる」と指摘しています。リクエストのたびに読み込まれるファイルに、チームのナレッジベースを収めることはできません。
ピン留めされたSlackスレッド。 人間は見つけられますが、アシスタントには見えず、1週間もすれば全員の関心から消え去ります。
各個人のカスタム指示。 6つのコピーが必要で、しかも容量が小さいです。OpenAIは、FreeおよびGoユーザー向けに1,500文字、Plus、Pro、Enterprise、Business、Education向けに5,000文字の制限を設けています。これは1〜2段落の好みの設定に過ぎず、共有された知識体系ではありません。また、これを更新するには、6人に同じテキストを貼り付けるよう依頼する必要があります。
オンボーディングドキュメント。 新メンバーが実際に何を必要としているかをチームが最も分かっていない時期に一度だけ書かれ、その後は更新されません。なぜなら、更新できる立場の人々は、自分が何に混乱していたかをすでに覚えていないからです。
解決策：1つの共有メモリレイヤー（10分未満、ノーコード）
構造的なアプローチは、個人のメモリを共有しようとするのをやめ、すべてのアシスタントが読み取る1つのチーム所有のメモリレイヤーを作成することです。個人のメモリは、各個人がどのように働きたいかを知るという、本来の役割を果たし続けます。共有レイヤーは、仕事そのものに関する事実を保持します。
それがMemoryLakeの役割であり、セットアップはコード不要の3つのステップで完了します。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。これは、チームのツールが共有メモリを読み書きするために使用する認証情報です。アシスタントから独立した1つの認証情報であるため、後からツールを追加してもセットアップをやり直す必要はありません。
ステップ 2: 最初のメモリをアップロードする
ドキュメントから始めないでください。チームが日常的に口にしている20の文章から始めましょう。実際には、これらは次の4つの場所から得られます。
決定事項とその理由。 「監査人が状態を再現する必要があるため、台帳にはイベントソーシングを使用しています。」 理由こそが重要な半分です。理由がなければ、決定は恣意的に見え、再び議論されることになります。
却下された案。 「3月にキューベースの設計を評価しましたが、リトライ時に順序の保証が維持されなかったため却下しました。」 これはチームメモリの中で最も価値の高いカテゴリです。そうしないと、新しいアシスタントや新入社員が毎回同じ提案を繰り返すことになるからです。
外部からは間違っているように見える制約。 営業時間中に再起動できないサービス。誰も列を追加してはならないテーブル。保存期間を規定する顧客契約。
繰り返される修正。 今月、2人のメンバーがアシスタントに同じ修正を指示した場合、それはここに該当します。これが最も明確なシグナルです。
各エントリは1つの主張に留め、新しいチームメイトが追加の質問をせずに行動できるほど平易に記述してください。10分間入力するだけで価値の大部分が得られ、残りは仕事を進める中で蓄積されていきます。
ステップ 3: AIとエージェントを接続する
チームがすでに使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのエージェント（Claude Code、Codex、OpenClawなど）はMCPサーバーを指定することで接続し、他のアシスタントはAPIを介して同じメモリを読み取ります。各個人は自分自身の個人メモリと好みの設定を維持します。変わるのは、6つのアシスタントすべてが、同じソースからあなたのプロジェクトに関する質問に回答するようになる点です。
ここで、3つの率直な制限事項を挙げます。共有レイヤーは魔法の組織図ではありません。第一に、誰かの既存の個人メモリをインポートすることはできません（そのためのエクスポート機能はないため、最初のエントリは手動で入力します）。第二に、ドキュメントストアの権限管理システムではありません。コーパスに対するファイルごとのアクセス制御が必要な場合は、エンタープライズコネクタを使用すべきであり、それを維持してください。第三に、強制力はありません。これはアシスタントが知っていることであり、破ってはならないルールではありません。
実務で何が変わるか
オンボーディングが口伝ではなくなる。 新入社員のアシスタントは、初日からコードベースがなぜそのような形になっているのかを理解しています。これは通常、代わりに作成したであろうドキュメントよりも価値があります。なぜなら、誰も書き留めない部分だからです。
修正が個別の作業ではなくなる。 現在は、誰か一人が落とし穴を発見すると、その一人のアシスタントだけに教えることになります。共有レイヤーでは、その発見は次の質問をするときに全員が利用できるようになります。
人によって回答が食い違うことがなくなる。 アカウントごとのメモリでは、2人の同僚が同じ質問をしても、それぞれの履歴に基づいた異なる回答が返ってきます。共有レイヤーは、少なくともプロジェクトに関する同じ事実を提供します。そのため、意見の相違は「誰のアシスタントが何を知っていたか」ではなく、本質的な内容に関するものになります。
ツールの乱立が知識の問題ではなくなる。 人々は異なるアシスタントを使用するでしょう。それと戦う価値はありません。解決すべきなのは、知識がそれぞれのアシスタントに閉じ込められていることです。この状況は、ナレッジワーカーのためのクロスツールメモリやツール間でのAIメモリの同期で説明されています。
エージェントの作業の重複が減る。 複数のエージェントが同じコードベースで作業する場合、それぞれが白紙の状態から開始すると、同じ誤解が倍増します。これはマルチエージェントメモリにおける失敗パターンであり、異なるスケールでの同じ解決策です。
形骸化しないチームメモリのためのベストプラクティス
1つのエントリにつき1つの主張。 長いエントリは検索精度が低くなり、陳腐化しやすくなります。1つのエントリに2つのアイデアが含まれている場合、片方がもう片方より先に間違った情報になり、それに気づかない可能性があります。
常に「なぜ」を記録する。 「ライブラリXを使用しないこと」は、誰かがユースケースを見つけた瞬間に無視されます。「ライブラリXを使用しないこと。メンテナーが2025年にアーカイブし、依存しているフォークもメンテナンスされていないため」であれば、ルールとして生き残ります。
規約はリポジトリに、知識はレイヤーに。 バージョン管理されたファイルは、常にコンテキストに含めるべきルールのための適切な場所です。共有レイヤーは、増え続ける事実のためのものです。これらを混ぜ合わせると、両方が悪化します。
委員会ではなく、1人のオーナーを割り当てる。 毎月、古いエントリを整理する担当者を1人決めます。月に10分。これがナレッジベースと単なるアーカイブの分かれ目になります。
積極的に削除する。 古いエントリは、存在しないエントリよりも悪質です。存在しないエントリは質問を促しますが、古いエントリは自信に満ちた誤った作業を生み出すからです。
シークレットを入れない。 認証情報はシークレットマネージャーに保管すべきです。メモリレイヤーは知識を保持する場所です。
個人の好みは個人のままにする。 コードの解説方法の好みなどは、チームの知識ではありません。それは個人のメモリやカスタム指示に任せましょう。それがそれらの役割であり、共有レイヤーをクリーンに保つことにつながります。
結論
チームに共有AIメモリがない理由は、ツールが未熟だからではありません。すべてのベンダーが、メモリを個人のアカウントに紐づけるという正しい決定を下したためです。つまり、どれだけ設定を行っても、6つのプライベートなメモリを1つのチームの脳に統合することはできません。Cursorのチームルール、Copilotの組織の指示、リポジトリファイルなど、実際に存在するチームスコープの機能は、ルールのための宣言的なレイヤーであり、知識が蓄積される場所ではありません。
したがって、共有レイヤーは、あなたが作成することを決断しなければならないものです。20の文章、1つのAPIキー、そしてチームがすでに使用しているツール。今10分を投資すれば、人々が本来得られると想定していたAIアシスタントの姿が手に入ります。それは、一人ずつではなく、全員に対して、あなたの仕事が実際にどのように機能しているかを理解しているアシスタントです。もし組織におけるこの症状が1つのチームにとどまらない場合は、エンタープライズAIの忘却で、この問題の規模に応じた対策を解説しています。