memory MCPでハンドオフは要らなくなる？──ハンドオフ運用者が永続化MCPと向き合った結論

この記事について

対象読者

• Claude Codeでハンドオフ運用をしてきた方

• memory MCPやclaude-memなど永続化MCP系ツールに一瞬揺らいだ方

• コーディング以外のドメイン（企画設計・研究・組織運営）でAIエージェントを使っている方

要点
永続化MCPとハンドオフは対立構造ではなく、同じ問題を選別主体だけ変えて解いていた話と、選び方を2軸で整理した話です。結論を一言で言うと、ゲームのセーブの話でした。

以前こんな話を書いた

前に、Claude Code の運用は「会議と議事録」だと書きました。界隈の言葉で言えば、これはハンドオフ（handoff）方式です。セッションを会議、セッション終了時に作成する引継ぎプロンプトをハンドオフ・ドキュメントとして扱います。次のセッションはそれから始める形です。

この運用に切り替えてから、明らかに引継ぎ事故が減りました。前回何をどう決めたのか分からないまま次のセッションを始めて、Claude に同じ説明を二度することがなくなったわけです。それで、この運用に満足していました。満足していたはずでした。

SNSで“永続記憶”という言葉をよく見るようになった

ところが最近、タイムラインで「Claude Code に永続記憶を付ける方法」「memory MCP で無限メモリ」みたいな記事のタイトルを続けて見かけるようになりました。memory MCP、claude-mem、Obsidian vault を外部記憶として使う構成、その他いろいろ。とくに claude-mem はローンチから短期間で GitHub Stars 数万を集める祭り状態になっていました。

仕組みとしては、ストレージに作業ログをため込んでおいて、次のセッション開始時にフックで関連情報を検索してコンテキストに注入する、という構成が多いようです。

そして気づくのですが、騒がれている記事のほとんどがコーディング文脈です。Claude Code や Cursor で、昨日のデバッグ、先週決めたアーキ判断、捨てた選択肢、こういうものを次のセッションに持ち越そうとしている、ということです。コードベースそのものを覚えさせるというより、コーディング作業の経緯を引き継ぐ話なんです。これがいま一番熱を持っている領域に見えます。

一瞬、揺らいだ

正直に言うと、数日揺らぎました。「あ、これ自分のやり方、もう古いんじゃないか」と思ったわけです。

ハンドオフ運用してきた人なら、同じように感じた瞬間があるんじゃないでしょうか。私の揺らぎどころは二つありました。一つは「これ使えば自分のハンドオフ運用いらないのでは？」という単純な不安。もう一つは「コーディング領域では同じ問題をツール側で解こうとしているらしい。だとしたら、どっちが優れているのか？」という問いでした。

25年 Tech 業界にいますが、新しい自動化の波が来るたびに、自分の運用が時代遅れになっている不安は常にあります。memory MCP もそういう波に見えました。

仕組みを調べたら、対立構造ではなかった

揺らいだまま放置するのもなんなので、永続化MCP系ツールの仕組みと、それが実際にどの文脈で語られているかを調べました。結論から書きます。

メモリ永続化の公式アプローチも、結局は選別している

私のハンドオフ・ドキュメントには「削った情報」があります。全部残したらそれは録音で、録音そのままだと次に読む人の負担を下げにくい。だから永続化MCP系のツールは「録音＋自動検索」で負担を下げようとしている。これも一つの解です。手動ハンドオフは別の解で、Skillが生成した内容を人間が確認・選別することで、読む側の負担を減らす。ハンドオフの価値は選別にあるわけです。

調べてみて気づいたのは、メモリ永続化問題への Anthropic 公式の整理も実は選別を前提としているということでした。Anthropic が公式に出している memory tool のドキュメントには、「初期化セッションで progress log と feature checklist を立てて、次のセッションが読み込んで再開する」というパターンが推奨例として書かれています。これは実質、ハンドオフです。

つまり「永続化MCP＝何でも覚える、ハンドオフ＝選別して渡す」という対立構造は、たぶん不正確でした。公式が示すパターンに近づけば近づくほど、永続化MCP系もやっていることは選別になります。違いは誰が選別するかにあります。人間が選別の主体になるのが手動ハンドオフで、ツールが選別の主体になるのが自動ハンドオフ。同じ問題を、選別の主体だけ違う方法で解いていただけでした。

節約できるという記事と、無駄が増えるという記事が両方ある理由

調べているうちに、永続化MCPについて書かれた記事は大きく二派に分かれることに気づきました。

節約派は「memory を入れると毎回の説明が減ってトークンが節約できる」と書きます。無駄派は「memory は常駐コストと要約コストが乗るので結局トークンが無駄になる」と書きます。一見矛盾していますが、両方とも正しい。念頭に置いている読者像が違うだけでした。

節約派が念頭に置いているのは「何も最適化していないユーザー」。毎セッション同じ説明を繰り返している人がツールを入れれば、説明分のトークンは減ります。無駄派が念頭に置いているのは「規律ある手動運用をしている人」。規律ある手動運用をしている人から見ると、ツールはすでにやっていることを自動化する代わりに、その税金（常駐コストと要約コスト）を乗せてきます。

これに加えて、両派ともコーディング領域に最適化された議論をしていることに注意が必要です。サービスの企画設計（いわゆる要件定義フェーズ）のような別ドメインで議論されていることは、まだ多くありません。だから「○○の人が▲▲と言っている」を額面通りに受け取っても、自分のドメインに合わない可能性があります。

公式が遠回しに言っていることに気づいた

調べていて一番面白かったのは、Anthropic 公式の memory tool ドキュメントが、手動ハンドオフ方式と同型のパターンを推奨していることでした。

memory tool は Claude API の組み込みツールで、厳密にはSNSで話題の memory MCP（MCPで動くメモリサーバー）とは別物です。なお、claude-mem は厳密には Claude Code プラグインで、MCP サーバー機能を内包する複合構造です（SNSでは「永続化MCP系」として総称されることが多い）。ただし、メモリ永続化という同じ問題領域への Anthropic 公式の見解として、永続化系ツールを考えるうえでも参照価値があります。

ドキュメントには「Initializer session で progress log・feature checklist を作る。Subsequent sessions はそれらを読み込んで状態を復元する。End-of-session update で次セッションの起点を最新化する」と書いてあります。これは要するに、markdown でハンドオフを整理して持ち回せと言っているのに近い。ツールが全部自動でやってくれるのではなく、構造化された人による選別を前提に、その記録媒体としてmemory toolを使う設計です。

claude-memを実運用してきた実務家のあいだでは、「単体ではなく、ハンドオフ用のmarkdown(HANDOFF.md等)との役割分離が現実的」という声が、英語圏・日本語圏の両方で出ています。深く運用した層ほど、自動キャプチャの利点と手動の選別の利点を分けて使う傾向があります。多くのセッションを実運用してきた運用者が「監査可能・差分追跡可能・git親和性・選別の主体性が自分の手に残る、これらは markdown 方式が優れる」と指摘しています。日本語圏でも独立に「セッション引き継ぎ」「HANDOVER.md」「/handover カスタムスラッシュコマンド」を解説する記事が複数あります。

つまり、永続化MCPの祭りの裏側で、「ちゃんとハンドオフを残せ」という地味な合意が静かに形成されつつある。これが、私の揺らぎが収束した一番大きな決め手でした。

では、自分はどっちを選ぶべきなのか──2軸で考えてみた

両者が同じ問題を解いていると分かったあと、次に考えたのは「では、何を基準に選べばいいか」でした。整理してみたら、判断軸は2つに集約できました。

軸1：決定の理由を残したいか、やったことが残ればよいか

手動ハンドオフが効くのは、判断の文脈や却下理由を残したい人です。なぜそう決めたか、何を捨てたか、誰待ちで止まっているか。これらを自分で吟味した上で残しておくと、後から自分や他人が経緯を追えます。

永続化MCPが効くのは、作業ログとして「やったこと」が残れば十分な人です。読んだファイル、走らせたコマンド、書き換えた箇所。これらは自動キャプチャで十分機能しますし、量が多いので人手では現実的に追えません。

企画設計のように判断の連鎖が中心の仕事は前者寄り、コーディングのように作業ログが中心の仕事は後者寄りに収まりやすい印象です。

軸2：少量・高密度な記録か、大量・連続的な記録か

手動ハンドオフが効くのは、1日に数セッション、各セッションが完結性を持つ働き方です。1回ごとに丁寧にハンドオフを確認・調整する時間が取れますし、Skill出力の内容も意味のある単位にまとまります。

永続化MCPが効くのは、1日に10セッション以上、絶え間なくコンテキストを切り替える働き方です。1セッションごとに確認・選別していたら追いつかないし、残した量がそのまま読む負担になります。自動化されたほうが現実的です。

2軸を組み合わせると4象限になる

完全な「片方だけ」になる人は意外と少なくて、コーディング作業は永続化MCP、判断記録は手動ハンドオフのように使い分けている人が現実的に多いはずです。これも合理的な選択です。本記事ではハンドオフ運用がメインの読者を想定しているので、その視点で軸を整理しましたが、両方使うのも普通にアリです。

私はこう選んでいます

私自身は、いまのところ手動ハンドオフ方式（自作のhandoffスキルで明示的に/handoffを実行し、各mdに反映する運用）を続けています。ゲームでいう手動セーブが好きな派、ということです。中途半端な状態が自動的に保存されてほしくない、自分が納得した時点で明示的に保存したい。反映漏れも、全文チェックではなく「あの件、記録した？」と念押しで確認する程度です。永続化MCP系も実装次第で手動寄りにできますが、SNSで話題の自動キャプチャ型はオートセーブ寄りで、私はhandoffスキルの方が手に馴染みました。理由は単純で、企画設計のドメインだと軸1で決定の理由を残したい側、軸2で少量・高密度な側の両方に当てはまるからです。判断の主体性を自分の側に置いておきたい、というのもあります。

ただこれは私のドメインと働き方の話なので、コーディング領域で1日10セッション回す人なら、たぶん永続化MCPに倒したほうが合理的です。手段は対立しません。同じ目的を、ドメインに合った方法で解くだけです。

ちなみに余談ですが、重要な決定をしたセッションでは念のため2回/handoffすることもあります。難所を超えた後にバックアップセーブをふたつ作るみたいな感覚です笑

結論

永続化MCPは「ハンドオフ運用を時代遅れにする技術」ではなく、「同じ問題を、選別主体を変えて解く技術」でした。Anthropic 公式の memory tool ドキュメントが推奨しているパターンを見ても、両者は構造的に同型です。判断軸は2つ。「決定の理由を残したいか／やったことが残ればよいか」、そして「少量・高密度か／大量・連続的か」。この2軸で自分のポジションを見ると、どちらに寄せるべきかが見えてきます。両方使う併用も、もちろんアリです。

揺らいだおかげで、自分がやっていたことの位置づけが少し広く見えました。それは悪くない副産物でした。