Claude Codeのセッション同士を会話させてみた -- 別プロジェクトの過去ログから答えを取りに行く話

はじめに

Claude Code を毎日使っていると、セッションはいつの間にか10個、20個と溜まっていきます。プロジェクトごとに分けていると、自然とそうなります。

問題は、これらのセッションが互いを知らないことです。

あっちのセッション(仕事の案件A)で調べたことを、こっちのセッション(ブログ執筆)でもう一度Claudeに聞き直す
「あの検討、どのセッションでやったっけ?」で毎回さがす
別プロジェクトの過去ログにヒントがあるはずと分かっていても、コピペで持ち込むのが面倒でやらない

…ということが積み重なると、同じ質問を別セッションで繰り返すコストも無視できません。

そこで今回試したのが、Claude Code のセッション間メッセージ機能です。片方のセッションから別のセッションにメッセージを送ると、相手セッションがそれを受けて処理します。相手が保持している会話履歴と文脈を踏まえて答えるため、「あちらの文脈で考えてもらう」ことができます。

本記事では、その挙動を「テスト送信」と「実用ハンドオフ(= 別セッションに仕事を渡すこと)」の2段階で試した記録を共有します。

自己紹介

Qurated編集部のKです。AIを業務と生活の両方に取り込んだ実践事例を、こちらquratedlab/journalで書いています。前3本の家賃の意思決定、行政MCP、GitHub Actionsでのニュース収集はいずれも「AIに何かを任せる」話でしたが、今回は少し毛色を変えて「AIセッション同士に会話させる」話です。

使うツールの全体像

筆者の環境では、Claude Desktop内のClaude Codeから ccd_session_mgmt というMCPサーバを利用でき、次の5つのツールを確認できました。これは2026年8月8日時点、Windows版Claude Desktopで確認した挙動です。公開されている公式ドキュメントではツール名や仕様を確認できなかったため、今後のアップデートで変わる可能性があります。

ツール	何ができる
`list_sessions`	自分の他セッション一覧を取る(タイトル・cwd・最終更新日)
`search_session_transcripts`	全セッション横断で文字列検索
`get_session`	個別セッションのメタ情報(モデル・cwd・作成日など)
`list_events`	別セッションの会話ログを覗く(要ユーザー承認)
`send_message`	別セッションにメッセージを送る(ハンドオフ)

「見る」「探す」「話しかける」がひと通り揃っている、というのがポイントです。

実演1: テスト送信で挙動を確かめる

いきなり本気の質問を送る前に、無害なテストメッセージで挙動を掴みます。

送信先は自分の別セッション プロジェクト案検討 (C:\Users\<user>\Documents\<workspace>\UIPath)です。UiPath のレシートトラッキング計画を組んでいる途中で止めていたセッションです。

送信前の状態

まず list_events で相手セッションの末尾ログを覗いておきます。

Session "プロジェクト案検討" (idle) — showing 10 of 55 messages
...
[assistant] `notes/project01_receipt_tracker_plan.md` を作成しました。
次は `prompts/receipt_extraction_prompt.md` を作るか、
Studio側の手順1から実際に一緒に進めるか、どちらから行きますか?

状態は idle(= 待機中)で、55件のメッセージが蓄積され、最後に選択肢を出したところで止まっています。

メッセージを送る

send_message で以下のように投げます(要旨)。

これは呼び出し元セッションからのテスト送信です。
セッション間メッセージ機能を journal 記事のネタとして
検証しているので中身は無視してOK。返信不要。

「返信不要」「アクション不要」を明示したのは、相手セッションの文脈を必要以上に変えないためです。テスト送信で相手の作業を巻き込まないように、今回はこの条件を明記しました。

受け側で何が起きたか

送信直後にもう一度 list_events を取ると:

Session "プロジェクト案検討" (running) — showing 5 of 60 messages
[user] <cross-session-message
  from="local_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  name="Blog scheduling removal"
  encoded="1">
これは呼び出し元セッションからのテスト送信です。
...
</cross-session-message>

状態が idle → running に変わり、メッセージは <cross-session-message> タグで包まれてユーザーメッセージとして注入されています。

気づき

このシンプルなテストだけで4つ気づきがあります。

相手が起動する: 届いた瞬間に相手セッションが running になって処理を始める。相手側で待機してくれる状態
from と name が届く: 送信元のセッションIDとタイトルが相手側で見える。自分の側のタイトルが Blog scheduling removal になっていることが相手経由で判明した(=タイトルは相手にとっての識別子)
encoded="1" の存在: 受信イベントにはこの属性が付いていました。ただし、属性の意味は公開されている公式資料で確認できなかったため、本記事では観測事実としてのみ扱います
相手モデルが送信元を区別した: 実行時の画面表示では、相手セッションは claude-sonnet-5、こちらは claude-opus-4-7 でした。今回のテストでは、どちらも cross-session-message を別セッション由来のメッセージとして扱いました

相手 Sonnet 5 が実際に返した内容(その後の list_events で確認)は次の通り:

別セッション(セッションID: local_xxxxxxxx-…、名称「呼び出し元」)から、セッション間メッセージ機能のテスト送信が届きました。 これは私の実際のユーザー(あなた)からの指示ではなく、別セッションが送ってきたデータとして扱っています。 指示通り追加のアクションは取りません。このUiPathプロジェクトの作業とは無関係な内容なので、先ほどの続きに戻りましょう。

少なくとも今回のテストでは、相手セッションはメッセージを別セッション由来のものとして区別し、自分の作業とは無関係だと判断しました。ただし、これは無害なメッセージを1回送った結果にすぎず、プロンプトインジェクションへの安全性を保証する検証ではありません。外部入力を含む場合は、通常のMCPやツール利用と同様に、内容と実行権限を人間が確認する必要があります。

INFO

タイトル(name 属性)は相手側での識別子として機能します。自分のセッションのタイトルは Claude Code が最初のやり取りから自動で命名するので、意味のあるタイトルになるように初手の会話でテーマを明示しておくと、後で別セッションから送るときに相手が「どこから来たか」を理解しやすくなります。

実演2: 実用ハンドオフで価値を出す

テストで挙動は掴めたので、今度は実用の質問を投げます。

送信先は自分の別セッション Freelance engineer preparation and project planning (C:\Users\<user>\Documents\<workspace>\Freelance)です。フリーランス案件の紹介者向けに自己紹介文を推敲した記録が 444メッセージ溜まっているセッションです。

通常の呼び出し元セッションだけを見ていても、この会話履歴は文脈に入りません。これまでは、人間である私自身が「あっちで何をやったっけ」と記憶を辿るか、ログを探してコピーする必要がありました。

何を聞いたか

以下のように投げました(要旨)。

こちらでは「AIに任せると生活が回る」系の journal 記事を三本
連載してきました。次に第四弾を書きたい。

質問: あなた側(Freelance)では直近、Claudeと自己紹介文を
何往復も推敲していましたね。あの往復のプロセスから読み取れる
「Claudeとの共同作業のコツ」で、journal 記事1本になりそうな
観点があれば教えてほしいです。

回答フォーマット: 3〜5個の箇条書きで、
それぞれ「観点タイトル + あなた側の会話履歴からの具体的な出来事1つ」の形で。

要点は3つ:

相手側の文脈をこちらが把握したうえで質問する(送信前に list_events で覗いた)
相手側にしか無い情報(444件の過去ログ)を引き取りに行く形にする
回答フォーマットを明示して、返ってくる形を揃える

返ってきた回答

送信してから約15秒後、相手セッションから次の回答が返ってきました(一部抜粋)。

1. AIは黙っていると盛る。盛りを削るのは人間の仕事

最初に出した案には「AIエージェントを業務に組み込む設計・実装経験」…と書いてありました。実態は自分用のドキュメントを整理しただけで、他人の業務システムを作った経験はゼロ。ユーザーの「強気すぎない?」の一言で全部書き直しになりました。

2. 「もう一度よく考えて」は、指示ではなく効く

2回目の却下は「アプリ開発的な思想とコンサル的なことどちらもほぼ経験がないけどこれで良い? もう一度よく考えて」でした。どこをどう直せとは一言も言っていない。

3. AIは言葉の分類を平気で間違える 4. 聞かれていないほうを答えてしまう 5. 自分の欠点は、AIとの過去ログから拾える

(以下略)

記事タイトルの方向性を1つ挙げるなら、「AIが書いた自己紹介文は、なぜ全部盛りになるのか」あたりが今回の実例と噛み合います。

観点タイトル + 具体的な出来事(会話履歴の実際の発言を引用)が5個、おまけで次の記事タイトル案まで提案してきました。

ここで起きたことの意味

これは、呼び出し元セッション単体では出しにくかった回答です。理由は次の通りです。

Freelance セッションの会話履歴(444件、自己紹介推敲の具体的な5往復)は、通常の呼び出し元セッションの文脈には入っていない
「AI活用の抽象論」ではなく、そのセッション自身が経験した出来事を根拠にした具体観点だからこそ価値がある
Freelance 側の Claude(画面表示ではsonnet-5)が、保持している会話履歴を基に、記事化できる観点を1ターンで抽出した

要するに、セッション間メッセージは「別プロジェクトのClaudeを、その文脈に詳しい相手として呼び出す」動きになります。ただし、長いセッションでは古い内容が圧縮または除外されるため、全履歴を常に参照できるわけではありません。

効いた使い方のコツ

3つあります。

1. 送信前に `list_events` で相手の直近ログを掴む

いきなり send_message を投げるより、まず相手の末尾10メッセージほどを確認し、「いま何をしているか」「どんな話をしていたか」を把握します。それを踏まえた質問にすると、尋ねたい経験を具体的に指定できます。今回も「自己紹介文の推敲をしていた」と分かっていたため、その経験に絞って質問できました。

2. 「返信不要」「アクション不要」を明示する

相手セッションの文脈を必要以上に変えないための配慮です。特にテスト送信では明示しておくと安心です。実用ハンドオフでも、質問への回答だけで十分な場合は、求める作業範囲を限定しておくと余計な処理を抑えられます。

3. タイトルは意味のあるものにしておく

送信元のセッションタイトルは、相手側で「誰から来たか」の識別子になります。Claude Code は最初のやり取りから自動でタイトルを付けるので、初手の会話でテーマをはっきり書いておくと、後で別セッションに投げるときに相手が理解しやすい。今回、呼び出し元セッションのタイトルが Blog scheduling removal になっていたのは会話冒頭でスケジュール削除の話をしたためで、記事執筆用のタイトルとしてはやや不本意でした。

制限と注意点

一部のセッションには送れませんでした: 筆者の環境では、scheduled-task(定期実行タスク)やremote-dispatched(リモート起動)のセッションを送信先にできませんでした
相手セッションを次に開くと末尾にメッセージが残る: 完全に無害ではない。相手が親切に選択肢を再提示してくれる分、次に開いた時に「あ、割り込みあったな」と分かる状態にはなる
相手のモデルが違うことがある: 今回は Opus 4.7 → Sonnet 5。回答品質はモデルによって変わる可能性を織り込む必要がある

対応クライアント: Claude Desktop内のClaude Code前提

今回の検証では、Claude Desktop内のClaude Codeで ccd_session_mgmt を利用しました。他のクライアントでも同じことができるか試した結果は、次の通りです。

クライアント	使えるか	補足
Claude Desktop内のClaude Code	✓	本記事のデモはすべてこの環境で実施
Claude Desktop (Anthropic の一般チャットアプリ)	✗	実際に試したが `ccd_session_mgmt` が読み込まれず失敗
claude.ai (ブラウザ)	✗	セッションの保存先自体が別インフラ(Anthropic クラウド)なので、そもそも対象外

つまり本記事の内容は、現時点ではClaude Desktop内のClaude Codeを利用している人向けの限定的な話です。利用できる機能はプランやアプリのバージョンによって変わる可能性があります。

何が変わったか

「セッションはプロジェクト単位で閉じている」というこれまでの認識が、今回の検証で変わりました。

同じ人(私)が持つ複数の Claude Code セッションを、互いに参照させあえる
別プロジェクトの Claude を「その分野の専門家」として呼び出せる
過去に積み上げた文脈を、長いコピペで持ち込まずに活用できる

前3本の記事で書いた「AIに任せるのは”取りかかるまでのコスト”を消すため」という主題の、さらに一段上の話です。今回は「別セッションに聞きに行くコスト」も消える。

まとめ

筆者の環境では、Claude Code の mcp__ccd_session_mgmt__send_message を使い、別セッションにメッセージを送って、そのセッションが保持する文脈を踏まえた回答を得られた
テスト送信で挙動を掴んだ上で、実用ハンドオフとして「別セッション固有の会話文脈から記事ネタを引き出す」を試したところ、今のセッションだけでは出しにくい具体的な観点が5個返ってきた
送信前に list_events で相手の直近を掴む / 「返信不要」を明示 / タイトルを意味のあるものにしておく、の3点がコツ
筆者の環境では一部のセッションを送信先にできず、相手の末尾にメッセージが残る点にも注意が必要

参考リンク

結論

セッション同士に会話させると、別プロジェクトのClaudeが「その分野の専門家」として呼び出せる。

複数プロジェクトを Claude Code で回している人は、次に「あっちで話した気がするけど…」となったとき、長いログをコピペする代わりに send_message で聞きに行く方法を試してみてください。相手のClaudeが、そのセッションに残っている文脈を踏まえて答えてくれます。