セッションが切れるたびに「前回どこまでやったっけ」を思い出すコストに、正直うんざりしていた時期がある。今は複数のAIエージェントを運用していて、セッション終了時に進行中タスク・保留事項・次アクションを自動でファイルに書き出す仕組み（以下、handoffファイルと呼ぶ）を2ヶ月以上回している。それだけで、再開時の文脈復元にかかる体感時間が数分から5秒くらいまで縮んだ。
そんな中で、Claude Codeに複数セッション間でメッセージをやり取りできる新機能が入った、という記事を読んだ（Claude Codeの新機能、"仕事の引き継ぎ"じゃありません）。この記事は公式ドキュメントを丹念に読み込んで「仕様と実態のズレ」を3点指摘した内容で、非常に勉強になった。読みながら気になったのは、「じゃあ自分が2ヶ月運用してきたhandoffの仕組みは、この新機能でどこまで代替できるのか」という点だった。
この記事では、自前運用してきたhandoffシステムの実態と、Claude Codeが公式に持つ4つのセッション関連機能を実際に触って比較し、どこまでが被っていてどこからが別物なのかを整理する。
前提
- 個人でAIエージェント（秘書役1体＋部門ごとの担当エージェント数体）を運用しているMac環境（Claude Code CLI）
- handoffファイルは各セッション終了前にMarkdownで書き出し、次セッション開始時に読み込む運用を約2ヶ月継続
- 検証時点のClaude Codeバージョンは v2.1.224 台
自前のhandoffシステムはどう動いているか
もともとの課題は単純で、AIエージェントとの作業セッションが途切れると、前回の文脈を思い出せず、毎回ゼロから説明し直す必要があったことだった。特に複数のエージェントを日替わりで使い分けていると、「あの件、どこまでお願いしてたっけ」を確認するだけで数分溶ける。
対策として、セッション終了時にhandoffファイル（引き継ぎメモ）を自動生成する仕組みを構築した。中身は「進行中タスク・保留事項・次のアクション・決定事項」の4項目に固定して構造化している。構造をガチガチに固定したのがポイントで、書式が毎回ブレると読み込む側（次のセッションの自分、あるいは別のエージェント）が拾い漏らす。
<!-- handoff.md のセクション構造（テンプレート抜粋） -->
## 進行中タスク
- [ ] {タスク名}: {現在の状態、直近でやったこと}
## 保留事項
- {判断待ちの事項}: {誰の判断待ちか、いつまでか}
## 次のアクション
1. {次にやるべきこと（具体的な1手目）}
## 決定事項（このセッションで確定したこと）
- {決定内容}: {理由}
このテンプレートに沿って書き出すようにしてから、セッション再開時の文脈復元が5秒程度で完了するようになった。「前回どこまでやったっけ」のやり取りがほぼゼロになったのは、体感として一番大きい変化だった。AIエージェントの「記憶」はモデルの中ではなくファイルシステムに外部化するのが現実解、というのがここでの学びで、構造を固定すると復元精度が安定するという実感がある。
ちなみにこのhandoff運用を始める前は、エージェントごとの応答トーンがバラバラという別の問題も抱えていた。技術的な質問にカジュアルすぎる返答をしたり、雑談にフォーマルすぎる応答をすることがあった。これはhandoffとは別軸の話だが、エージェントごとにペルソナファイル（話し方・一人称・語尾・専門分野を明文化したもの）を作って解決した。約50行の定義を書いただけで、応答トーンが安定し「前と違う人みたい」という違和感がなくなった。この2つ（文脈の引き継ぎ／人格の一貫性）は別問題として切り分けて管理しないと、どちらの改善が効いたのか分からなくなる、という点は地味に重要だと思っている。
Claude Codeの「引き継ぎ」新機能の正体
元記事が指摘していた通り、この新機能の実体は「cross-session messaging」というもので、正確には「引き継ぎ」ではなく「メッセージング」に近い。公式ドキュメントを実際に確認すると、いくつか自前のhandoffと決定的に違う点があった。
渡るのはテキストのみ。公式は「メッセージとは、あるClaudeが別のClaudeに向けて書くテキストであって、会話履歴やファイルではない」と明記している。つまりSendMessageツールを使って別セッションに一言メモを送れるだけで、こちらが構築したhandoffファイルのように「進行中タスク・保留事項・次アクション」を構造化してまるごと引き継ぐような使い方は想定されていない。文脈全体を渡したいなら公式が案内しているのは別の機能（--continue / --resume）で、cross-session messagingの役割ではない。
送信元の検証が厳格。メッセージにはverifiedPeerPidというフィールドがあり、これはメッセージを送ってきたプロセスのPIDをカーネルレベルで検証した値を指す。同じフィールド名に見えるfromは同一ユーザーの別プロセスなら偽装できるため、送信元の識別にはverifiedPeerPidを使えと公式が明記している。複数のAIエージェントを外部からの入力（Telegram経由など）で動かしていると、この手のなりすまし対策がどこまで作り込まれているかは実は結構気にする部分で、ここは自前実装よりしっかりしていると感じた。
受信タイミングを制御できる。デフォルトだと、セッションがアイドル状態のときに他セッションからのメッセージが新しいターンとして届き、そのたびにフルコンテキストが送信される。これはトークン消費的に無視できない挙動で、crossSessionInboundを"hold"に設定すると即時配信を止められる。
{
"crossSessionInbound": "hold"
}
settings.jsonにこの1行を足すだけで、他セッションからのメッセージは保留され、こちらの都合の良いタイミングでまとめて確認できるようになる。複数エージェントを常時稼働させていると、アイドル状態のたびに割り込まれてフルコンテキスト送信のコストが積み上がるのが地味に痛いので、この設定は最初に触っておく価値がある。
対応OSが限定的。macOSとLinux（WSL 2内のLinuxを含む）のみで、ネイティブWindowsでは使えない。自分の環境はMacなので影響はなかったが、チームにWindows環境の人がいる場合は最初に確認しておいたほうがいい。
4つの機能を比較する
Claude Codeのセッション関連機能を触ってみて、役割がきれいに分かれていることが分かった。自前handoffと並べると次のようになる。
| 機能 | 渡るもの | 主な用途 | 自前handoffとの関係 |
|---|---|---|---|
| 自前handoffファイル | 構造化した4項目（タスク・保留・次アクション・決定） | セッションをまたいだ「引き継ぎ」そのもの | （比較対象） |
claude --continue |
現在ディレクトリの最新の会話全体 | 直前のセッションにそのまま戻る | 全文脈を渡す点は近いが、範囲固定・要約なし |
claude --resume <id> |
指定セッションの会話全体 | 過去の特定セッションを選んで再開 | 同上。ピッカーで選べる分だけ柔軟 |
| cross-session messaging | テキストメッセージ1本のみ | 稼働中の別セッションへの一言連絡 | 「引き継ぎ」ではなく「連絡」に近い |
| agent teams（実験的機能） | タスクの割り振り（各エージェントは別コンテキスト） | 役割分担したリレー作業の自動化 | 引き継ぎというより並行作業の指揮系統 |
--continueと--resumeは会話全体を丸ごと復元するので、自前handoffが目指していた「文脈復元」に一番近い。ただし自分がhandoffで欲しかったのは全文脈の再生ではなく、「今どのタスクが進行中で、何を判断待ちにしていて、次に何をやるべきか」という要約だった。会話ログを--continueでそのまま読み込むと、それこそコンテキストが肥大化して的外れな応答が増える問題に逆戻りする。実際、以前ひとつのエージェントに全業務を任せていたときはこれで応答が遅くなり、役割別にエージェントを分割してルーティングする構成に変えた経緯がある。分割後は各エージェントの応答精度が体感で大きく上がり、処理速度も平均2倍程度になった。「全部の履歴を渡す」と「要点だけを渡す」はトレードオフで、後者を選んだのが自前handoffだったと今は理解している。
agent teams（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1で有効化する実験的機能で、デフォルトは無効）は、複数のClaude Codeインスタンスをそれぞれ別のコンテキストウィンドウでspawnして役割分担させる仕組みで、これはこれで「調査→実装→レビュー」のようなリレー作業には向いている。ただしトークン使用量はチームメイトの数と稼働時間でスケールするため、公式もコスト管理としてSonnet系モデルの使用を勧めている。自分のhandoff運用のような「1人のエージェントがセッションをまたいで作業を続ける」ケースとは、そもそも解いている問題が違う。
実際に代替を試してみて分かったこと
一番気になっていた「cross-session messagingで自前handoffを廃止できるか」を実際に試した。結論は「単体では無理、組み合わせれば一部は簡略化できる」だった。
試した手順はこうだ。稼働中の別セッションに向けてSendMessageツールで「T-xxxの進行中タスクをこちらに引き継ぐ」という一言を送ってみたところ、届くのはその一言のテキストだけで、当然ながら元セッションが持っていた保留事項や決定事項の詳細は付いてこない。受け取った側のセッションは「何を引き継がれたか」を自分で会話履歴やファイルから探しにいく必要があり、これは自前handoffが解決していた「復元5秒」からは程遠い。むしろ「担当を交代したことをもう一人のエージェントに知らせる」用途——例えば秘書エージェントから別の作業中エージェントへ「そのタスクは優先度が上がったので先にやって」と一言添える、といった使い方には向いていると感じた。
一方で--resumeは文脈の完全性という点では自前handoffより優れていた。セッションIDや名前で過去のセッションを検索でき、v2.1.223以降は現在のプロジェクトディレクトリだけでなくgit worktreeや同じマシン上の他プロジェクトまで検索範囲に含まれるようになっている。ただし全文脈を読み込む分、コンテキストウィンドウの消費は避けられない。自分の場合は「そのタスクだけ手短に思い出したい」場面が大半なので、--resumeで毎回全文脈を読み込むより、handoffファイルの4項目を読む方が圧倒的に速い。
使い分けの指針
2ヶ月分の運用と今回の検証を踏まえて、自分の中では次のように役割分担を決めた。
- 要点だけ手早く復元したい（「あのタスク、どこまでやったっけ」） → 自前handoffファイル
-
直前のセッションに完全に戻りたい（会話の細部まで必要） →
claude --continue/--resume - 稼働中の別セッションに一言だけ連絡したい（担当交代・優先度変更の通知） → cross-session messaging
- 役割分担したリレー作業を自動化したい（調査→実装→レビュー） → agent teams（コスト増に注意）
自前handoffを「引き継ぎ」の主役として残しつつ、cross-session messagingは「稼働中のエージェント同士の連絡手段」として補助的に足す、というのが今のところの落とし所になっている。廃止するどころか、むしろ役割が増えた形だ。
まとめ
元記事が指摘した「cross-session messagingは仕事の引き継ぎではない」という点は、自分で2ヶ月handoffを運用してきた立場からも強く同意する。渡るのがテキスト1本だけという設計は、構造化した引き継ぎメモの代替にはならない。結局のところ、Claude Codeの各機能は「何を渡したいか」で明確に役割が分かれていて、自分の場合は要点の要約が欲しかったので自前handoffの居場所は消えなかった、というのが今回の一番の収穫だった。同じように自作の引き継ぎ機構を持っている人は、廃止する前に一度「渡したいものが会話全体か、一言の連絡か、要約か」を切り分けてみると、公式機能とどう共存させるかが見えやすくなると思う。
私はこのやり方に落ち着きましたが、もっと良い手があれば知りたいところです。handoffの構造化フォーマットを4項目以上に増やしている方や、逆にcross-session messagingだけで運用を回せている方がいれば、どんな工夫をしているか教えてもらえると助かります。