揮発と蒸留 ── AIと協働するための個人の記憶アーキテクチャ

揮発させてよい記憶と、蒸留して残すべき記憶。AIと協働するとき、その境界をどう引くかが本丸だと、最近そう思っている。

元々、Claude Chat と Claude Code は普通に併用していた。Chat は思考の整理、Code は実装やドキュメント作業。役割が違うので使い分けるのは自然だった。

ただ、ひとつ面倒なことがあった。

Chatで議論したことの続きをCodeでやりたい、Codeでの作業結果をまたChatで議論したい。そう思うたびに、必要な文脈を手でコピペし直していた。スマホのChatで考えていたことをPCのCodeに持っていきたいときは、なおさら。一回一回は小さい摩擦だが、頻度が高いと地味に効いてくる。

これを解決したくて、間に Obsidian vault を挟むことにした。ChatもCodeも同じvaultを参照できるようにしておけば、ノートに必要な文脈を書くだけで、別環境から続きを読める。私はこれを handoff（環境間の引き継ぎ）と呼んでいる。

（最初は Notion でも同じことができるはずだと考えた。ただ、API 経由のレイテンシ、構造化の手間、markdown ファイルを直接置けないことのオーバーヘッド。どれも地味だが日常的にかかる。Obsidian はローカルの素の markdown で、Claude から見ても「ただのファイル」として軽く読める。私の用途では Obsidian のほうがフィットした）

ここまでは、ただの環境セットアップの話。

ところが、先の handoff のために /session-handoff というスキルを作り、加えて /session-wrapup というスキルを足したタイミングで、ふと気付いた。

これは、自分なりの「記憶アーキテクチャ」を組んでいるんだな、と。

このエントリは、その整理。揮発させてよい記憶と、蒸留して残すべき記憶。その境界をどう引くかの話、と言ってもいいかもしれない。

（書きながら整理している節があるので、未完のまま出す）

出発点:ChatとCodeを分けている理由

私の使い方は単純に書くとこうだ。

• 基本は Claude Chat（スマホ・PC両方）

• 複数のファイルを扱う作業は handoff して Claude Code に移し、作業後にChatに戻る

• 全体の下敷きとして Obsidian vault がある

なぜこうなっているか。最初は「複数ファイルを扱う作業はCode」くらいに思っていたが、よく考えるとこの分け方にはちゃんと理由がある。

軸1:Memoryの所在の違い

Chat と Code のMemoryは、どちらも基本はユーザースコープ。私という個人に対してパーソナライズされていく点では同じ。違うのは所在。

• ChatのMemoryはクラウド側にある。Dreamingでパーソナライズされ、デバイスを跨いでも同じ私が引き継がれる。

• CodeのMemoryはローカルファイル（ユーザーグローバルなCLAUDE.md・自作skill群）にある。手元のマシンに密着していて、別デバイスに移ると持ち運ぶ手間がある。さらにプロジェクト直下のCLAUDE.mdがあれば、リポジトリと一緒に動く（こちらはプロジェクトスコープ）。

同じ「Memory」でも、Chatはデバイス非依存、Codeはデバイス依存。所在の仕方が違う。両者は入れ替えがきかず、補完関係にある。

軸2:他セッションの参照容易性

地味だが効くのが、Chatはconversation searchで過去のセッションを横断できること。Codeは基本リポジトリに張り付くので、横断が弱い。

複数の経営テーマを並行して走らせ、別の関係者と話すたびに過去の文脈を引っ張りたい。そういう働き方だと、Chatの横断性は決定的に重要になる。

軸3:思考フェーズと環境

Chatは発散・整理に向き、Codeは収束・実行に向く。スマホでChatを使うのは、移動中や会議の合間に断片的な思考を捕捉するのに向いているからで、これは単なるデバイス制約ではなく思考フェーズと環境の整合。

私がChatとCodeを分けている理由は、この3つ。

ところが、それだけでは説明できないことがある

私の使い方は実はもう一段、別の構造を持っている。

たとえば「WinSession（社内の全社ミーティング・表彰制度）」というひとつのテーマを、私は CHROとの1on1や、Co-CEOそれぞれとの1on1で、繰り返し複数のセッションで参照している。

逆方向もある。代表やボードメンバーとの 1on1 の議題を用意するセッションでは、その関係者と話したい複数のテーマ(それぞれ別の壁打ちセッションで考えてきたもの)を conversation search で引っ張ってくる。1 テーマ → 複数関係者にも、1 関係者 → 複数テーマにも、同じ直交が効いている。

実際、私のセッションは二軸で切られている。タイトルにプレフィックスを付けていて、Org/...（組織テーマの壁打ち）や DeepDive/...（領域の深掘り）といったテーマ軸セッションと、1on1/... の関係者軸セッションが、独立して並走している。

意図的にこの二軸を分けている。テーマと関係者を同じセッションで扱うと、関係者ごとの文脈（話す相手の文脈）と、テーマそのものの構造的議論が混ざる。テーマ軸は概念に集中したい、関係者軸は対話と議題に集中したい。役割が違うからセッションも切る。

そしてその過程で、複数セッションを跨ぎながらテーマそのものが洗練されていく。骨子が固まってきたタイミングで、私はそれを Obsidian に dump する。

ここで Obsidian vault が出てくる。

Obsidianの役割:フローとストックの両方

私のObsidian vaultには次のようなものが入っている。

• concept note:自分の分析レンズになっている概念群（組織や判断で繰り返し効いてくる構造に、自分なりの名前を付けたもの）

• decision record:意思決定の経緯と理由

• proposal draft:経営会議への起案ドラフト

• handoff ノート:環境を跨ぐ作業の中間物

• Codeセッションへの指示ログ:プロンプトや作業手順の蓄積

ほかにも、思いつきメモやスクラップなど雑多なものまで、要するに何でも放り込める場所になっている。

つまりObsidianは、フロー（書きながら考える場所）でもあり、ストック（蒸留された判断の前提）でもある。両者が混ざらないようディレクトリを分けて運用している。

Claude側のMemoryがChatとCodeで分断しているのを、Obsidianが下から繋ぎ直している。WinSessionのような横糸テーマは、Obsidian上のノートとして保持されていて、複数のセッションから参照される。

ここで重要なのは、Claudeの記憶と自分の記憶が別物として共存していること。Claudeの記憶は圧縮済みコンテキスト、自分の記憶は遡るための一次資料。役割が違うから、両方ある。

真ん中にあったもの:短期記憶と長期記憶

ここまで来てようやく見えてきたのが、記憶階層の話。

• 短期記憶:Claudeのセッション（揮発OK、思考の作業領域）

• 長期記憶:Obsidianのconcept note / decision record（蒸留済み、参照される判断の前提）

絵にするとシンプルで、セッションは思考のフラスコ、Obsidianは結晶化装置。フラスコの中で揮発しても困らない、結晶だけ残ればいい。

ポイントは、全部をObsidianに残さないこと。

セッション内の発散、試行錯誤、整理途中のメモは、消える前提でいい。むしろ消えるからこそ気軽に書ける。それを全部ストック化すると、長期記憶側のノイズが増えてconcept noteの参照価値が落ちる。

人間の記憶も同じで、全部を長期記憶に刻んでいたら脳がもたない。短期記憶で揮発させ、価値のあるものだけを蒸留して長期記憶に固定する。consolidationの構造そのもの。

これは個人の記憶設計の話に見えて、組織のナレッジマネジメントが直面している構造と、ほぼ同型だと思っている。組織が抱える「ドキュメントが多すぎて結局誰も読まない」という問題は、フローとストックの分離をしていないから起きる。個人レベルで先に解いておくと、組織設計にも持ち込みやすい。

蒸留プロセスとしての session-wrapup / session-handoff

ここで最近追加したスキルが効いてくる。

/session-wrapup

長いセッションの終わりに、会話履歴から「やったこと・学び・残すべき情報」を抽出して構造化する。そして「これはconcept noteにすべき」「これはADRにすべき」と既存のドキュメント化スキルへ振り分け提案する。

つまり、短期記憶から長期記憶への蒸留装置。

/session-handoff

冒頭で書いた「Obsidian を挟んで handoff する」運用を、スキルとして体系化したもの。Obsidian vault の handoff 用ディレクトリを一時ストレージにして、何を書き出すか・何を読み込ませるかをテンプレ化する。

これは 短期記憶間の橋渡し装置。手でやっていた手続きが skill 化されることで、handoff の摩擦が更に下がった。

この2つを追加したことで、短期記憶を揮発させても困らない構造がようやく完成した。揮発させてよいものは揮発させ、長期記憶にすべきものはwrapupで蒸留し、環境を跨ぐ作業はhandoffで橋渡しする。

別の見方をすれば、/session-wrapup も /session-handoff も、本質的には 可視な compaction（コンテキストの圧縮）。Claudeはコンテキストウィンドウがいっぱいになると裏で自動的に compaction を行うが、それは不可視で、Claude任せ。skill 化した wrapup / handoff は、それを自分の手で・可視にやっている。

逆に言うと、ここまで揃って初めて「気兼ねなくセッションを閉じられる」状態になった。

それまでは、セッションを閉じる前にいつも「これ、まだ閉じていいんだっけ」と一瞬迷っていた。あの小さな迷いが、地味に思考の連続性を削っていたのだと、揃ってから気付いた。

記憶アーキテクチャの完成度は、揮発させることへの安心感として現れる。

mind-as-code との接続

私はもう一段別の構造として、自分の思考そのものをskill fileとして書き起こす mind-as-code という枠組みを作っている。中核にあるのは、思考原則（意思決定の設計、優先順位ルールなど）と、各領域への価値観（構造観、組織観、技術観など）。これらをYAML-fronted Markdownで書き出している。これも一種の長期記憶。

concept noteとskill fileは並列ではなく段階関係にある。新しい概念や判断パターンはまずconcept noteとして書き、何度か実戦で使って「これは効く」と確信できたものだけが、skill fileに昇格する。concept noteはmind-as-codeのsandbox。長期記憶の中にも段階性がある、というのは自分でも最近言語化できたこと。

私がやっていることは、突き詰めるとひとつだ。

mind-as-codeのskill fileは「判断の再利用単位」、concept noteは「分析レンズの再利用単位」、ADRは「決定の再利用単位」、handoffノートは「作業状態の保持単位」。すべて再利用される形式に整えるという同じ思想で動いている。

揮発させるものと保持するものを分け、保持するものは再利用される形式にする。これが、自分が無意識にやってきた設計だった。

別の言い方をすれば、これは個人レベルでの ストック層(自分の知的状態をどこにどう蓄積するか)の設計でもある。AIと協働する時代に、何が競争優位として残るのか。私の今の仮説は ストック層 にあるのだが、その話はまた別の機会に書こうと思う。

まだ未完

正直、このアーキテクチャはまだ揺れている。

• 蒸留プロセスの粒度が、まだ感覚に頼っている。「これはconcept note化すべき」の判断基準自体を skill化したい

• handoffノートの扱いも、永続化するもの・捨てるものの線引きがぼやけている

• ChatとCodeの使い分けは、もっと「セッションテンプレ」化できる気がしている

もうひとつ、長期記憶を整えるほど、その記憶自身を疑う回路が弱くなる、というリスクも自覚している。これは別の機会に書く。

ただ、Claude単体ではなく、Claude × Obsidian × 自作skillで記憶アーキテクチャを組むという方針自体は、自分の中でもう固まった。

AIと協働するというのは、AIに何をやらせるかではなく、自分の側の記憶構造をどう設計するかの話。

AI時代に個人と組織で差がつくのは、AIの使い方ではなく、ここから先だと思っている。

連作で「AIと協働する時代の、個人と組織の知的アーキテクチャ」というテーマを書いていく予定です。
組織のストック層、認識負債、といったテーマで続きます。