Keyaki Labs — 2026年8月

セッション同士で会話ができる
Claude Codeの機能、ご存知ですか？

2026年8月7日に入ったばかりの「クロスセッションメッセージング」。
機能の中身と、実際にどう使っているかまで。

Claude Code AIエージェント 開発環境
Section 01

どういう機能なのか

別のターミナルで動いているClaudeに、伝言を送れる。

What it is

別のターミナルのClaudeに伝言できる

「隣のターミナルで動いてるセッションに、
　マイグレーション終わったか聞いて」

  • こう頼めば、Claudeが自分で相手を探して送る
  • 頼まなくても、必要だと判断すれば自分から送る
  • 同じPCの別ターミナル／別のPC／ブラウザのセッションにも届く
  • 条件を満たせば設定不要。最初からON
  • 誰に届くか見たいときは /list-agents（/peers でも可）
Key Numbers

どれくらい新しいのか

3週間
機能が追加されてから
2026年8月7日 → 8月28日
7回
その3週間での主な更新
ほぼ毎週どこかが変わっている
0
同じPC内での
サーバー経由の回数
ポイント： いま触ると、まだ形が固まりきっていない段階を見られる。
Timeline

この3週間で起きたこと

日付入ったもの
8月7日機能そのものが追加（macOS・Linux）誕生
8月7日別のPCのセッションに、こちらから会話を始められるように
8月17日Windowsに対応
8月19日「終わったら教えて」の購読機能
8月21日一覧に自分自身の名前も出るように
8月26日受信表示が全文から1行プレビューに
8月27日一部のクラウド基盤経由でも使えるように
最重要

渡るのはテキストだけ

文脈を共有する機能ではなく、伝言する機能。

メッセージ（伝言）

  • 送信側のClaudeが書いたテキストだけ
  • 会話履歴は渡らない
  • ファイルも渡らない
  • 相手は、いま生きている別のセッション
  • 例：「移行が終わったので進んでいい」

セッションの再開（引き継ぎ）

  • 会話そのものが渡る
  • 履歴がそのまま引き継がれる
  • 相手は、同じ会話の再開
  • 例：昨日の作業を別ターミナルで続ける
  • 公式も「文脈を移したいなら resume」と明示
Comparison

似た機能との棲み分け

機能何をするもの相手
クロスセッション
メッセージング		 自分で立てた独立セッション同士の伝言 自分の他セッション
セッションの再開会話そのものを別ターミナルで続ける同一の会話
サブエージェント1セッション内の委譲。結果を要約して返すセッション内
agent teamsClaudeがチームを組んで自己調整（実験的）チーム内
agent view投げっぱなしにして後で確認する管理画面背後のセッション
Remote Controlスマホやwebから自分のセッションを操作自分（人間）
channelsCIやチャットの外部イベントを流し込むClaude以外の外部
選び方： まず「文脈ごと渡したいのか、伝言なのか」。次に「相手は誰か」。この2段階で1つに決まる。
Section 02

実際にどう使っているか

人間が中継役から降りる。「窓口セッション」と「作業セッション」。

Before

依頼が1件来るたび、人間が伝書鳩

プロジェクトごとにセッションを立て、チャットには全部の依頼が届く。

  • ① チャットの通知に気づく
  • ② 中身を読む
  • ③ どのプロジェクトの話かを判断する
  • ④ 該当するターミナルのタブを探して開く
  • ⑤ 依頼の文面を貼り付ける
  • ⑥ 足りない前提を補足して指示にする
つらいのは： 判断が要らない作業なのに、そのたびに自分の作業が中断されること。1件1〜2分では済まない。
Solution

窓口セッションと作業セッション

🚪 窓口セッション

  • 名前を 窓口 にする
  • 受信箱を見に行くのは、ここだけ
  • どのプロジェクトの話かを判断する
  • 該当セッションへ原文のまま転送する
  • 自分では実務をやらない。連絡役に徹する

🔧 作業セッション

  • 名前をプロジェクト名にする
  • 自分から受信箱を見に行かない
  • 窓口からの転送を待つ
  • 対応が終わったら自分で現場に返信する
  • 自分の担当のことだけ考えていればよくなる
さきほどの6ステップのうち、人間に残ったのはゼロ。通知に気づく必要すらない。
How it works

窓口セッション方式

現場とのやりとりが何往復しても、人間はこの図に登場しない。

💬 チャットツール 🚪 窓口 PJ1 作業 PJ2 作業 返信 対応が終わったので、作業セッションが現場へ直接返す 返信 現場からの返事。拾うのは窓口だけ 伝言 どのPJかを判断し、原文のまま転送 — 別のプロジェクトでも、同じことが回る — 返信 返信 伝言
以前はこの矢印が全部いったん人間を通っていた。読んで、担当を判断して、ターミナルを開いて、貼る。その層がまるごと消えた。
Side Effect

ついでに、取りこぼしも消えた

狙って設計したわけではない副産物。

  • チャットツールの未読取得は、取得した瞬間に既読になる
  • 複数セッションが同時に見に行くと、先に取った1つだけが受け取る
  • そのセッションが「自分の担当じゃない」と判断したら、誰にも処理されないまま流れる
  • → 見に行くのが窓口だけになったので、これが起きなくなった
結果： 手間を減らすための設計が、そのまま事故も防いでいた。
Insight
名前が役割で、
役割がそのまま宛先になる。
  • 宛先はセッションの名前。/rename で自分で付けられる
  • 新しいプロジェクトは、セッションを立てて名前を付けるだけで転送先が1つ増える
  • 設定ファイルもレジストリも要らない
  • ⚠️ 現場からの依頼は要約させず、原文のまま転送する。「表示がおかしい」の中身が要約で落ちる
Pitfalls

事故りやすいポイント

① 送信停止は広く効く

  • 送信ツールを拒否リストに入れると…
  • サブエージェントやチーム機能への送信まで止まる
  • 内部で同じ送信ツールを共有しているため
  • 「外部だけ止めたい」つもりが手元の委譲も動かなくなる

② ドキュメントが追いつかない

  • 新しい機能なので更新が遅れる箇所がある
  • 「使えない」と書かれているのに、前日に解消済みだった
  • 動かないと書かれていても更新履歴を見る価値がある
Summary

押さえるのは3つだけ

✉️

渡るのはテキストだけ

  • 文脈を渡したいなら、この機能ではなくセッションの再開を使う
🏷️

宛先はセッションの名前

  • 名前の付け方が、そのまま運用の設計になる
🔒

同じPC内なら外を経由しない

  • 自分のOSユーザーだけが読み書きできる通り道を使う
複数のセッションを動かすと、人間はどうしても伝書鳩になる。その層が、まるごと要らなくなった。