会話の記憶を「チームの記憶」にする仕組み、自分の運用と並べてみた

01 — ZOZOの課題と解法

「毎回同じ説明を書き直している」を、Markdownの正本化で解いた

出発点はシンプルだった。Claude Codeに仕様や経緯を毎回プロンプトで説明し直している——文脈はコードの外にあり、セッションを跨げない。そこでZOZOのチームは、Claude Codeとの会話をMarkdownで「メモリ」として正本化した。Claude Code標準のメモリ機能とは別物と記事内で明記されている自前システムだ。

保存フローは、案件・職種・担当者・作業単位・フェーズの5軸で置き場所を判定し、同じ置き場所に似たメモリがないか確認してから新規作成か追記かを決める。要約とタグはfrontmatterに付く。読み込みフローはその逆で、索引から数千件を数十件へ、さらに10件ほどへ絞り込み、質問の意図に合うものを数件選んで見出しと要点だけに圧縮して読む。索引はSQLiteで、識別子に強い全文検索と、「不具合」と打っても「バグ」のメモリが拾える意味検索を並走させている。

ディレクトリは5軸に沿って階層化され、個人領域は01-inbox/から03-issue/まで積み上がる。調査・設計といった実作業スキルにメモリの読み書きそのものを埋め込み、フェーズごとに1本のスキルが1本のフローとして流れる設計にしたのも特徴だ。人が関わるのは「やりたいことを詰める」段階だけになる。

02 — 実測値で見る効果

「共有してから何が変わったか」を、数字で語っている

この記事が良質なのは、効果を印象論で終わらせていない点にある。直近2か月半で保存メモリの再利用は約800回、そのうち保存から18.7時間以内に読まれたのが半分。検索で1件も候補が返らなかったのは2.7%、欲しいメモリが上位3位以内に入っていたのは68.9%。

想起は"明示指示"がないと起きない

「近い記憶がある」とだけ知らせても、一度も読みにいかなかった（110件で0%）。ところが「答える前に思い出してください」と明示すると、3回のうち2回は読む（208件で65.4%）。ヒントを出すだけでは足りず、指示として埋め込む必要があった、という実測。

共有した効果は縦・横・斜めに出た

リーダーとの認識合わせが軽くなり（縦）、設計と実装で担当が分かれた機能で引き継ぎミーティングが不要になり（横）、Claude Codeが自発的に他担当者の設計メモリを読み込んで食い違いを指摘した事例まで出た（斜め）。

未解決の課題も正直に書かれている

古いメモリが検索上位に出てくるのは「防げていない」と明記。想起精度は明示指示前提。検索スケールは、いまの約7,000件では動くが数万〜数十万件でどうなるかは分からない、とある。

03 — 自分の運用と並べる

同じ「メモリ」でも、規模が2桁以上違う

このブログを含む副業ポートフォリオでも、Claude Desktopの自動メモリ機能を毎日使っている。中身は索引役のMEMORY.md（1行1メモリ・150字以内の要約つきリンクリスト）と、個別のメモリファイル15本。ZOZOの約7,000件と比べると、2桁以上小さい規模だ。

個別ファイルはfrontmatterにtypeを持ち、user・feedback・project・referenceの4分類で固定されている。ZOZOのような案件・職種・担当者という組織向けの5軸ではなく、「この情報は誰のものか」だけで分けている、ひとり運用向けの単純な分類だ。実物はこうなっている。

# memory/model-cost-policy.md の先頭
---
name: model-cost-policy
description: モデル使い分けとトークン最適化の方針（2026-07-12ユーザー合意）
metadata:
  type: feedback
  originSessionId: 88152890-3ba6-4f27-878f-a2df09d83aa7
---

トークン消費の最適化方針:
- 既定モデルはSonnet 5。管理・戦略セッションのみOpusに手動切替。
- サブエージェント起動時はmodelを明示指定する。

**Why:** ユーザーは複数プロジェクト並行運用でのトークン消費を懸念。
**How to apply:** Agentツールを呼ぶ前にこの方針でmodelを決める。[[claude-codex-sync]] とセットで使う。

想起の仕組みもZOZOとは対照的だ。ZOZOはSQLiteの全文検索＋意味検索で毎回「近そうなもの」を動的に探しにいく。自分の運用はMEMORY.mdという1枚のインデックスを毎回まるごと読み込み、ファイル同士は[[name]]という静的なリンクで結ばれているだけ。検索エンジンではなく、手書きの目次に近い。

04 — 鮮度問題への処方箋

ZOZOが「防げていない」と書いた鮮度問題、自分の運用にはこう出ていた

ZOZOの記事は、メモリの鮮度——古いメモリが検索の上位に出てくるのを防げていない——を未解決の課題として正直に書いている。自分の運用でこれに近い仕組みを探してみたら、思いがけない場所にあった。

メモリファイルを開くと、経過日数が自動で警告される。「このメモリは65日前のもの。メモリは時点観測であり生きた状態ではない。コードの挙動やfile:line引用は古くなっている可能性がある。事実として主張する前に現在のコードと照合すること」——これはClaude Desktopの土台側が、メモリファイルを読むたびに自動で付ける注記だ。

ZOZOのSQLite検索は「古いメモリが上位に出ないようにする」方向、つまり入口で選別するアプローチを取ろうとしていると読める（記事はまだ防げていないと書いている）。対して自分の運用にあったのは、選別せずに読んだあとで疑わせるアプローチだった。古いメモリを検索結果から除外するのではなく、「これは65日前の観測だ、鵜呑みにするな」と毎回突きつける。検索の精度を上げる代わりに、読み手（Claude自身）の解釈のほうを補正している。

どちらが優れているという話ではない。ZOZOの規模（約7,000件・十数人共有）では、古い情報を検索結果に混ぜないことが実務上の優先課題になる。自分の規模（15件・ひとり運用）では、混ざったとしても目視で気づける範囲に収まっている。だからこそ「経過日数を毎回突きつける」という軽い処方箋で足りている——規模が変われば、この処方箋も足りなくなるはずだ。

05 — 応用

自分のメモリ運用に、今日足せること

ZOZOの規模の仕組みをそのまま真似る必要はない。今日の規模でも足せる部分だけを切り出す。

「近い記憶がある」と知らせるだけでは読まれない、という実測（想起率0%→65.4%）は、自前のメモリ運用にそのまま応用できる。ヒントで終わらせず、「思い出してから答えて」と明示の指示に格上げする。
メモリファイルに経過日数や「時点観測である」旨を明記する一文を足すだけで、検索精度を上げずとも鮮度問題の一部は緩和できる。ZOZOが「防げていない」と書いた課題への、軽量な代替案として使える。
件数が少ないうちの単純な分類（user/feedback/project/referenceのような4分類）は、件数が増えたときに壊れる前提で見ておく。ZOZOの5軸・SQLite二重検索は、7,000件という規模になって初めて必要になった設計だと捉えると、いま自分に何が要らないかも見えてくる。

メモリの仕組みは「何件溜まったら壊れ始めるか」で設計が変わる。自分の運用が今どの規模にいるかを把握しておくことが、次にどの仕組みを足すべきかの判断材料になる。