【劣化した脳をAIで補完】セッションを跨いだ記憶のリレー
前回、ダウンロードしたファイルが勝手にObsidianの中に入っていく仕組みの記事の最後に「次の問題の影が見えていた」と書いたと思う。「セッションが切れても話が繋がる」ための仕掛けを別軸で考えないといけなくなったと。今回はその話。
前回の話はこちらから
仕組みとしては地味で、AIにセッション終わりに「申し送り」を書かせて、次のセッションが起動した時に最初にそれを読む、というだけの話。
薄れるAIの記憶
Claude Codeと作業していると、最初のうちは何でもよく覚えてくれている。直前にやった作業、いま動かしてるスクリプト、さっき相談した話。会話の流れの中にあるものは、ちゃんと文脈として握ったまま進んでくれる。
ただ、ある時から気になり出したことがあった。たとえば、magiではこういう記事のネタを思いつくままに溜めて、シリーズものやら特別編やらミニシリーズやらのアイディアを仮タイトルとあらすじ（概要）みたいなものをタスクとして管理してもらっている。「残りの記事アイディアのストック状況整理して」などやり取りしながら進めてる感じだ。進行中や今後進めていこうと思ってるものは大体問題ないのだが、たとえば「ちょっとそれは一旦保留しよう」とかで直近タスクから外すと、セッションを跨ぐうちにいつの間にか「溜めておいたアイディア」からなくなってることがあったりする。
自分が困るのはまさにそこだった。直近のタスクは自分でも大体覚えてる。覚えてないからAIに聞いてるんじゃなくて、覚えてないであろう「保留にしたあれ」を含めて、優先順位ごと一覧で見たい。それなのに保留にしたものほど落ちる。
なんでこうなるのかをClaude Codeに聞いてみたら、セッションが長くなると古い情報が薄まっていく、というような事を言われた気がする。技術的な仕組みはよく分かってないままだけど、要するに直前のことは強く残るが、いったん脇に置いたものほど薄れていく、という性質らしい。自分の脳と似たような挙動なのが、ちょっと笑える。
実はこういう問題に気づく前から、Chat側のClaudeでは毎セッションの終わりに「今日のまとめ作って」とは頼んでいた。出てきたまとめのMDをダウンロードして、Obsidianの中に放り込んで終わり、という運用。机の引き出しに「今日の議事録」を毎日入れていくのと、机の上に「明日やることリスト」を置いておくのは、似ているようでまったく違う。当時の自分は前者しかやってなかった。
記憶のリレー
そこでClaude Codeに相談することになる。例によって、具体的なやり方を指定するんじゃなくて、欲しい状態だけ伝えた。
「セッションが切れる時に、次のセッションが困らないように申し送りを書いておいてほしい。直近の話だけじゃなくて、保留中のタスクも優先順位込みで」
これだけ。仕組みの中身はClaude Codeに考えてもらう。番外編③でも書いた、機能を指定するんじゃなくて受け取りたい結果を伝える、という頼み方。相手がAIになっても変わらない。
自己紹介も含めた番外編③はこちらから
「セッションの終わりに『引き継ぎ』として完了した作業・現在の状態・次にやるべきこと・注意事項を MD で書き出します。次のセッションが起動した時、最初にそれを読みます」
仕組みとしてはそれだけ。何かすごい技術を使ってるわけじゃない。
それでも初回の動作確認をしたあとに「あ、これだ」と思った感覚は今でも覚えている。次の日にClaude Codeを起動したら、開口一番「前回保留にしていた○○の件、優先度高めで残っています」と切り出してきた。前のセッションで自分が「これは後でやる」と言って脇に置いたままになっていたやつだった。
何度か使ってみて気づいたのは、テンプレが効いている、ということ。Claude Codeが提案してきた申し送りには「完了した作業」「現在の状態」「次にやるべきこと（優先順）」「注意事項・学び」「重要ファイル・パス」みたいなセクションが最初から決まっていて、その「次にやるべきこと（優先順）」の中に保留中の話まで全部書き出される作りになっていた。「優先順」と書いてあるだけで、直近で動いてるやつだけ書いて済まされない、という押し付けがましいテンプレが効く。
ここまで全部Claude Codeに任せている。中身を自分で設計したわけじゃない。「次のセッションが困らないように」と頼んだだけ。実際、ある時にChat側のClaudeから「Claude Code側でどういう仕組みでやってるの？」と聞かれて、「それはClaude Codeに聞かないと自分でも分からん」と答えたことがある。冗談じゃなくて、本当によく分かっていない。
作業空間の壁
申し送りの仕組みは、ひとつのmagiの中、eventの中等それぞれのリポジトリの中ではちゃんと機能した。「保留が消える」問題は、これでだいぶ落ち着いた。
ところが、一つ解決するとまた一つ解決したい問題が出てくる。
前にも書いたけど、この時点でリポジトリを2つ動かしていた。event（Webサービス開発）と magi（note執筆）。Claude Codeの仕組み上、目的が違えばリポを分けた方が色々と都合がいいことが多いために組んだ体制。
この体制で問題だったのは、note記事がWebサービスの開発日記みたいなものでスタートしたから、magi側で記事化するためにevent側での作業ログやChat履歴が必要だったこと。この情報伝達が地味に重い作業になっていた。
Event側のセッションで何かの実装が進む。詰まる。解消する。という日々の作業がある。それをnote記事にするには、magi側のセッションを起動して、「event側でこういうことがあって…」と最初から経緯を説明することになる。magi側のClaude Codeは、event側で何が起きてたか知らない。
それを毎回口頭で説明するのも面倒なので、event側のセッションで「magi側に共有するための説明資料作って」と頼んでMDを出してもらい、それをmagi側のセッションに貼って読ませる、という運用にしていた。
しかも書き手が二人いるみたいになる。event側のClaude Codeに「magiへの説明資料」を書かせ、それをmagi側のClaude Codeに読ませる。AIとAIの間の伝言係をユーザーがやるとか、AI, DXどこいった？
壁越しの記憶の共有
ある日、いつもどおりEvent側で「magiへの説明資料作って」と頼んでいる最中に、ふと気づいた。
これ、セッション間でできるならリポジトリ間でも「申し送り」は出来るんじゃないか？
event側で書いている「magiへの説明資料」は、項目立てこそ違うけど、要するにEvent側の今の状態を別のセッションに引き継ぐためのものだった。完了した作業、現在の状態、注意事項、重要ファイル——並べているものは、申し送りで書いている内容とほぼ同じ。リポが違うだけで、やってることはセッション間の申し送りと同じだった。
だったら、同じフォーマットにして、同じ場所に置けば、magi側のセッションが直接読みに行けばいい、というだけの話。
実装としては、同じObsidianのVaultを両方のリポが見ているので、Vaultの中のひとつのフォルダに申し送りを集める形にしてしまえば、event側で書いた申し送りをmagi側のセッションが普通に読める。
Claude Codeに相談したら、「両リポ共通の保存場所をVaultの中に決めて、そこに集約しましょう。Git管理は不要、Obsidianの同期に任せれば両リポから普通に読める形になります」と返ってきた。Vaultの中の _handoffs/ という1つのフォルダに、リポを問わず申し送りが集まる、という設計だった。
ここで一応書いておくと、こういう仕掛けで「AI同士が勝手にやり取りしている」みたいな絵を想像する人がいるかもしれない。けど、実態はそうじゃない。共通の格納場所にそれぞれの記憶が保管されている、セッション起動時に一通り目を通して、あとは必要に応じて各リポジトリが情報を探しにいけるようになっているだけ。AIが一つの脳を持ったわけじゃなく、共通のデータベースを持っているだけ。
magiでのnote執筆作業中、eventでの話をするとAIが勝手にそこを見に行って経緯を確認してくれる。「共通データベース」ができたおかげで、説明資料を毎回作る作業が「読んで」と一言で済むようになった。いや、読んでっていう必要さえ無い事も多い。
共通のルール
ここまで来て、Claude Codeから「両リポで形式がバラバラだと壊れるので、共通仕様書を1枚立てましょう」と提案があった。
これは、いきなり仕様書みたいな大層なものを立てたわけではなくて、最初は本当にメモ書きから始まっている。ファイル名のルール、書く項目、保存場所、それくらいが書かれただけのもの。「これが v0.1 です」と言われて、自分は「了解」と返した。中身を細かく読み込んだわけではない。
仕様書の話自体はそれで終わったかと思っていたら、しばらくしてmagi側のセッションから別のレビューが返ってきた。「magi側で使うには、こういう項目があった方がいい」「申し送りの種類を表す短いラベルが揃っていた方がいい」みたいな指摘。それをevent側のClaude Codeに渡したら、「ではv0.2として反映します」と更新がかかった。
書いてて気づいたんだけど、これ、AI同士でレビューを応酬してることになる。event側のClaude Codeがたたき台を書く、magi側のClaude Codeがレビューを返す、自分は両方の間に座って「OK」「採用」を返すだけ。たまにユーザー目線で「ここ分かりにくい」と返すこともあるけど、文面を書いているのは自分じゃない。
なんかちょっと変な感覚はあった。「AI同士で話してるな」というやつ。ただ間に自分がいないと話は進まないので、伝書鳩としては忙しい。
仕様書の中身は、ファイル名のルール、申し送りの種類を表す短い辞書（セッション終わり、作業中、記事完成、レビュー待ち、等）、フロントマターと呼ばれるファイル冒頭のメタ情報のスキーマ、そしてテンプレートの骨格。骨格の方は、前段で書いた「完了した作業」「現在の状態」「次にやるべきこと（優先順）」「注意事項・学び」「重要ファイル・パス」がそのまま入っている。単一リポでセッション間に渡してたフォーマットが、ほぼそのままリポ間にも使われている、ということ。
設計したのはClaude Code。自分は読み返してOKを返した側。
説明不要の快適さ
event側で1日の作業の終わりやセッション切り替えのタイミングで「引き継ぎよろしく」と頼む。event側のClaude Codeが、そこまでの完了分・残り・優先度・注意点を書き出して、Vaultの中の所定のフォルダに保存する。自分はその場では中身を読まないこともある。
翌日、magi側のセッションを起動すると、開口一番こういう報告が来る。「Event側で昨日○○の作業がありました。今日の note 執筆に関連する可能性があります」。前は自分が口頭で説明していたやつを、Claude Codeが勝手にしてくれる。
何が嬉しかったかというと、event側で何が起きていたかを「翻訳して説明する」作業が、まるごと消えたこと。
そしてふと気づくと、最初に解こうとしていた「保留が消える」問題と、後から見えてきた「event の話を magi に翻訳する二度手間」の問題が、同じ仕組みひとつで両方とも片付いていた。
正直、二度手間が消えたのを喜ぶのが先で、両方が一気に片付いていたことに気づくのはだいぶ後だった。気づいたときは「あ、これ全部つながってたんだ」と一人で頷いた、くらいの話。
思い描いたAIとの付き合い
ここまで書いてきて、前回と構造がよく似ているのに気づいた。
前回は「ダウンロードフォルダが散らかる予感がしたので、手作業で予防するんじゃなく、最初から散らからない仕組みを作った」という話だった。今回は、構造としては同じで、「セッションが切れて保留が消える予感がしたので、手作業で覚えておくんじゃなく、最初から消えない仕組みを作った」という話になっている。
意識低い系おじさんは自分を信用してない上に常に楽をしようと思っているので、自分が手を動かなきゃいけないものは早めに仕組化を考える。あとから自分で「えーと、こないだ保留にしたあれ何だっけ」と毎日思い出す姿は、容易に想像できる。続かないだろうな、というのも分かる。だったら最初から仕組みに任せた方がいい。
ただ今回の場合、想定外だったことがひとつある。「リポ間の翻訳の二度手間」が一緒に片付いたのは、正直当時は計算してなかった。単一リポでの「保留が消える」を解消した副産物として、リポ間の情報共有の仕組化に繋がった。
これはたぶん、仕組みの中身がシンプルだったから横展開ができたんだと思う。MDを1枚残す、次のセッションが読む、そんなシンプルな仕組み。複雑な前提を入れていなかった分、別の場所に持って行っても同じ形で動いた、ということだと思う。
理想のAIはまだ先
これで全部解決したかというと、そうでもなかった。
仕組みは動いている。event側で書いた申し送りはmagi側で読まれている。「翻訳の二度手間」は消えた。「保留が消える」も消えた。それでも、一つ解決するとまた一つ解決したい問題が出てくる。
前述のように作業内容によってリポジトリを分けて使ってるけど、「いま自分がやろうとしているこの作業、event側でやるべきなんだっけ、magi側でやるべきなんだっけ」という悩みが出てくるようになる。両リポの境界に座っているような話題が増えてきて、どっちのセッションで進めるのが正しいのか、自分の中でも判断がつかない場面が出てきた。
「両方を知ってる状態」は作れたけど、「両方のどちらでやるべきか」という新しい問いが生まれていた。
ここまで来て、ひとつ振り返って気になったのは、そもそもの動機の話だった。なぜ自分はこんな仕組みを作りたかったんだっけ、と。「保留が消えるから」とは書いたけど、もっと手前に、自分が普段AIに対して抱いている期待というか、こういう風にAIと付き合いたい、という気持ちみたいなものがある気がしてきた。
仕組みとしての話はこれで一区切り。なぜこういう仕組みを欲しがったのか、その思想みたいなものをちょっと次回説明しようと思ってる
ここまで読んでくれてありがとう。
前の章「日々作られるファイルを自動で整理」はこちら
このシリーズを最初から読む場合はこちらから
書いてるのはこんな人
Xもやってるので、よかったら覗いてみてほしい
本編で書いてる作成中のWebサービスの公式アカウント
本編はこちらから
サイトはこちら
