結論：待機通知は確認の開始合図に使う

Claude Code 2.1.236では、cross-session SendMessageにnotify_when_idleが追加され、同じ端末の別sessionが次にidleになった時、一度だけ通知を受け取れます。macOSとLinuxが対象で、opt-in、one-shot、no pollingです。通知は「確認しに行く時刻」を知らせるもので、task完了、test合格、公開許可を保証しません。

読者の具体的な困りごとは、複数sessionへ作業を分けた後、何度も画面を開いて終了を確認するか、放置して次工程が遅れることです。この記事を読むと、通知対象、完了条件、readback担当を固定し、過剰なpollingなしで安全に引き継げます。

次の行動：現在並行している作業から、外部副作用がなく成果をreadbackできる一件を選び、one-shot通知で試してください。

公式仕様と制限を確認する

公式Claude Code changelog 2.1.236は、cross-session SendMessageのnotify_when_idleについて、同じmachine上の別Claude Code sessionが次にidleになった時に一度だけ通知し、pollingしない機能だと明記しています。対象OSはmacOSとLinuxです。繰り返し通知、remote hostをまたぐ保証、任意の時刻指定、task結果の検証までは仕様に含まれません。

公式cross-session messaging文書では、sessionの発見、宛先指定、受信可能性、message量の制限を確認できます。changelogには短時間の大量送信で受信側inboxの上限を超える場合、SendMessageが事前に拒否する改善も記載されています。通知が来ない時に同じ依頼を連打せず、宛先session、account、機能状態、inboxの結果を一つずつ確認します。

公式agent teams文書は、agent teamとsubagentと独立sessionの違いを説明しています。notify_when_idleは独立session間の連携であり、共有task listやleadによる完了判定を自動的に追加するものではありません。複数sessionが同じfileを編集する場合は、通知以前にworktreeやownerを分け、競合を防ぐ必要があります。

polling・通常message・待機通知を比較する

  1. 手動polling：状態を細かく確認できますが、担当者の集中を切り、確認間隔が短いほど無駄が増えます。障害対応のように即時性が必要な時だけ使います。
  2. 通常SendMessage：質問や追加指示をすぐ届ける用途です。作業中のsessionへ不要なmessageを送るとcontextと優先順位を乱します。
  3. notify_when_idle：次のidleを一度だけ知りたい時に向きます。通知後に成果物を確認するworkflowを別に持つことが条件です。

選定軸は緊急度、作業時間の予測可能性、成果物のreadback可否、session owner、外部副作用です。長いtest、調査、local build、review下書きは適しています。production障害、顧客応答、承認期限、支払処理のようにidleを待つだけでは危険なtaskは、監視systemや明確なSLAを使います。

idleは「現在modelが応答やtool実行をしていない状態」であり、「要求を満たした状態」とは限りません。permission待ち、失敗後の停止、入力待ち、部分成果でidleになる場合があります。通知受信後は、終了理由、未完task、error、diff、testを読んでから次工程へ進みます。

安全に使う7手順

  1. 送信側と受信側をClaude Code 2.1.236以降へ更新し、macOSまたはLinuxであることを確認します。
  2. 対象session名、repository、branch、ownerを記録し、同名や古いsessionへの誤送信を防ぎます。
  3. 受信側のtaskへ完了条件、停止条件、禁止操作、成果物pathを明記します。
  4. 送信側から対象sessionへ、次のidle時だけ通知する依頼を一度送ります。
  5. 通知待ち中は追加messageを連打せず、緊急時だけownerが直接確認します。
  6. 通知後にtranscript、task状態、成果物、diff、test結果をreadbackします。
  7. 完了なら次工程へ進み、未完なら原因を一文で固定して新しい指示を送ります。

通知messageには「何が終わるのを待つか」「通知後に誰が何を見るか」を含めます。ただしsecret、顧客情報、長いlogをmessage本文へ詰め込みません。参照pathやtask IDを使い、正本はrepositoryやticket systemへ置きます。短く明確なmessageにすると、受信側のcontext消費も抑えられます。

同じ端末で多くのsessionを動かす場合は、命名規則を固定します。project、task、日付、ownerのうち必要な要素を使い、長すぎる名前やemoji依存を避けます。changelogでは非常に長いsession名や大量のsession listに関する制限も改善されていますが、運用側で宛先を簡潔にする方が誤通知を減らせます。

チェックリストとHOLD条件

  • 2.1.236以降である
  • macOSまたはLinuxである
  • 同じmachine上のsessionである
  • 宛先sessionを特定した
  • repositoryを固定した
  • branchを固定した
  • ownerが明確
  • 完了条件を書いた
  • 停止条件を書いた
  • 禁止操作を書いた
  • 成果物pathがある
  • one-shotとして送った
  • 連打しない
  • 通知後のreadback担当がいる
  • idleと完了を区別する

HOLD条件は、宛先を一意に特定できない、別hostをまたぐ、対応OSが未確認、通知後に成果物を読めない、外部副作用があるのに人の承認がない、permission待ちを完了と誤認する可能性がある場合です。通知が届くことを監査やSLAの代替にしません。

通知が届かなかった場合は、まずsessionが実際にidleになったか、送信が受理されたか、sessionが終了していないかを確認します。その後、accountやversionの差を確認します。同じ依頼を何度も送ると、原因を切り分けにくくなり、後から複数通知が届く運用事故を招きます。一回の試行ごとにrequestと結果を記録してください。

よくある質問と次の行動

定期的な進捗通知にも使えますか？

one-shotのidle通知です。定期進捗にはtask更新、hook、監視systemなど目的に合う仕組みを使います。

通知が来たら自動でdeployしてよいですか？

いいえ。idleは品質合格ではありません。test、diff、承認、対象environmentをreadbackしてから人が実行します。

agent teamでも必要ですか？

teamには共有taskやmessageの仕組みがあります。独立sessionとの境界を確認し、同じ通知を二重化しないようにします。

提供内容は公式Claude Code changelog、session間連携は公式cross-session messaging、teamとの違いは公式agent teamsで公開直前に確認してください。

通常のsession連携はSendMessageガイド、goalの完了条件はgoalガイド、無人実行の停止条件はheadlessガイドへつなげます。Miraigentの無料診断では、session分割、完了条件、通知後readback、承認gateを整理します。