SSOTと3つのskillsで作る、AI秘書の記憶管理
前回、SSOTの上にQA基盤を載せた話を書きました。判断フローをGitHubリポジトリ化してClaude Codeのskillsにしたら、QAマネージャーが1人でも回る仕組みになった、という内容です。
今回は、そのSSOTの上に「AI秘書としての記憶管理」を載せた話です。
LLMを日常的に使っていると、コンテキスト上限の壁にぶつかります。チャットが長くなると文脈が失われる。新しいチャットを始めると、昨日の議論をゼロから説明し直す必要がある。覚えてほしいことを覚えてくれない。この問題を、自分の環境ではどう解いたかを共有します。
「覚える・忘れる・思い出す」を設計する必要がある
Ubieのhatakeさんが書かれた記事で、認知科学の4段階モデル（符号化→保持→忘却→想起）という整理を知りました。これは自分が直面していた問題の言語化として、とても腑に落ちました。
情報は溜まり続けるが整理されていない。不要な情報がノイズになって、本当に必要な情報が埋もれる。「覚える」だけでなく「忘れる」と「思い出す」も設計しないと、AIの記憶は機能しない。
LLMを日常的に使う人なら、この問題は誰もが経験するはずです。では、自分の環境ではこれをどう解いたか。結論から言うと、SSOTという記憶の土台があったおかげで、非常にシンプルな仕組みで済みました。
記憶の土台：「共有リポジトリ＋個人リポジトリ」の二層構造
私はEngOps（EMみたいな仕事）兼QAマネージャー兼SREマネージャーとして、複数のドメインを横断して仕事をしています。その中で、GitHub上に複数の共有リポジトリと、1つの個人リポジトリを持つ構成に辿り着きました。
共有リポジトリは、組織のSSOT（Single Source of Truth）です。project用リポジトリ、コーポレートチーム用リポジトリ、QAチーム用リポジトリなど、ドメインごとにリポジトリがあり、案件の状態、担当者、課題、リスクといった、誰が読んでも同じ意味に取れる客観的な事実と状態が構造化されています。
一方、個人リポジトリは、`personal-context`という名前で、自分だけが使う判断支援の場所です。3つのフォルダで構成しています。
`/context`には、作業中の情報を入れます。共有リポジトリを更新するには1歩足りない、まだ固まっていない情報。検討途中のアイデアや、もう少し様子を見たい状況などです。
`/decisions`には、共有リポジトリには書けなかった判断・決断の背景を入れます。共有リポジトリには「何を決めたか」は書きますが、そこに至るまでの政治的な文脈や、採用しなかった選択肢の理由など、表に出しにくい情報をここに置きます。
`/people`には、人単位でファイルを作っています。その人がどんな人なのか、自分がその人とどんな話をしたのかが入っています。「Aさんは慎重派で、データを揃えてから持っていかないと動かない」「Bさんとは先週この件で合意した」といった、人に紐づく文脈です。
共有リポジトリとpersonal-contextの境界
この二層構造で大事なのは、何を共有リポジトリに置き、何をpersonal-contextに置くかの仕分けです。
共有リポジトリには「What・How・Status」と、重要な「Why」を載せます。この案件はどんな案件で、今どのような状態で、ここまで何をやってきて、次に何をやらないといけなくて、それを阻むブロッカーやリスクは何か。
一方で、personal-contextには、共有リポジトリの構造に当てはまらない情報が載ります。
具体例で示します。
①プロジェクトにおける分離例
共有リポジトリには「この案件のブロッカーはXチームの承認待ち」と書きます。
personal-contextには「Xチームの担当者は慎重派で、データを揃えてから持っていかないと動かない」と書いてあります。前者は誰が読んでも有用な事実、後者は自分がその人との関係の中で得た知見です。
②QAの場面における分離例
共有リポジトリには「QA方針はリスクベースで決定」と書きます。
personal-contextには「この判断に至るまでに別の選択肢も検討したが、こういう理由で現在の方針にした」と書いてあります。前者はチームが参照すべき決定事項、後者は決定の背景にある文脈です。
この境界を明確にすることで、共有リポジトリの透明性と、個人の文脈の豊かさを両立できます。共有リポジトリは組織のダッシュボードとして誰でも見える。personal-contextは自分のAI秘書だけが参照する。
この二層構造の上で、3つのskillsが記憶を管理する
土台が整理できたので、その上で動く記憶管理の仕組みはとてもシンプルです。Claude Codeのskillsを3つ作りました。/session-start、/session-end、/switchの3つです。
`/session-start`は、想起のためのスキルです。新しいセッションを始めるときに、共有リポジトリとpersonal-contextから、今のセッションに必要な文脈を読み込みます。SSOTに情報が構造化されているので、これだけで「昨日どこまでやったか」「今日何をすべきか」「関係者の状況はどうか」が復元できます。
`/session-end`は、記憶の書き出しと整理のためのスキルです。セッションを終えるときに、今回のセッションで得られた重要な情報だけをpersonal-contextに書き出します。共有リポジトリを更新すべき情報があればそちらも更新します。書き出さなかった情報は、次のセッションには引き継がれません。これが「忘却」の機能を果たしています。
`/switch`は、文脈を切り替えるためのスキルです。例えばEngOpsの作業から雑談モードに切り替えたいとき、あるいはQAの文脈からSREの文脈に移りたいとき。作業文脈を明示的に切り替えることで、不要な情報がノイズにならないようにします。
認知科学の4段階モデルで言えば、session-startが想起、session-endが符号化と忘却、switchが文脈の再構成です。3つのskillsで4段階を自然にカバーしています。
なぜこれだけで済むのか
記憶管理がシンプルで済む理由は、skillsの設計が優れているからではありません。SSOTに情報が構造化されているからです。
案件の状態、担当者、課題、リスク——これらがGitHub上に構造化されていれば、session-startで読み込むだけで文脈が復元できます。人に紐づく文脈がpersonal-contextの`/people`に整理されていれば、「この人とはどんな話をしていたか」もすぐに引き出せます。
もしSSOTがなければ、記憶管理の仕組み自体を高度化する必要が出てきます。どの情報をどのくらいの期間保持するか、どの情報を優先的に思い出すか、といったルールを精緻に設計しなければならない。SSOTがあれば、その複雑さの大部分をデータの構造が吸収してくれます。
前回の記事で「SSOTがあるから、QA基盤が機能する」と書きましたが、記憶管理でも全く同じ構造です。
SSOTは情報基盤であり、品質基盤であり、記憶基盤である
前々回の記事と前回の記事、そして今回の記事を通じて見えてきたのは、SSOTの役割が段階的に広がっているということです。
Togglの工数データをつないだら、「判断の材料が揃う場所」になりました。定性情報と定量情報を突き合わせて、アサインの最適化余地が見えるようになった。
QA基盤を載せたら、「AIが品質判断の文脈を持てる場所」になりました。skillsがSSOTを参照することで、QA判断に必要な情報を自動で集められるようになった。
そして今回、記憶管理を載せたら、「AIが長期的な文脈を維持できる場所」になりました。セッションが切れても、SSOTとpersonal-contextから文脈を復元できる。
つなげるものが増えるほど、SSOTの価値は加速度的に上がっていく。前々回の結論がここでも成立しています。そして、この「つなげる先」はまだまだあるはずです。
