【速報】AnthropicがClaude Codeのセッション間通信を正式発表。なぜ開発者はGit管理を併用すべきか

AnthropicがClaude Codeにセッション間通信機能を正式追加した。独立したAIエージェント同士が、テキストを直接送り合える仕組みだ。

これでAI同士の連携が完璧になると期待した僕だが、仕様を見て考えが変わった。

この機能、コンテキストやファイル履歴は一切渡らない。

単なる伝言の自動化と「状態管理」の違いを理解しないと、不整合のエラーに苦しむことになる。

新機能が来ても僕らがGit管理を併用する理由を、開発者視点で深掘りする。

端末間でAIが喋り出す。セッション間通信の全貌と「伝言」の仕様

AnthropicがClaude Codeの最新機能として、独立したセッション同士でテキストを送受信できるセッション間通信機能を正式にリリースした。

従来の開発では、別のターミナルで動くAIに情報を渡す場合、人間が画面間をコピペで往復する伝言ゲームが発生していた。

今回のアップデートにより、接続中のエージェントを探すListAgentsと、メッセージを直接送信するSendMessageという2つの処理を使って、AI同士のやり取りが自動化された。

この機能の核心となる仕様と制限は、以下の通りだ。

• 送信できるデータ形式はテキスト1本のみ
• 議論の履歴や参照ファイルなどのコンテキストは一切渡らない
• メッセージ送信を契機として新しいセッションを自動生成することは不可
• 溜められる未読メッセージの件数は最大50件まで
• 受け取ったメッセージで自動的にコマンドが実行されることはない

同一マシン内ではUNIXソケットを通じて直接通信し、同一ネットワーク上のリモート環境にも対応する。

連投抑制やレート制限が施されており、受信側の権限設定に応じて人間の承認待ちが入るため、プロンプトインジェクションの伝播を防ぐ堅牢な構造だ。

しんたろー：
AI同士が勝手に会話してシステムを組み上げてくれる未来を期待したけど、届くのが「テキスト1本」と知って納得した。
コンテキストが共有されないなら、伝言を受け取った側のAIは結局「で、どのファイルの何の話？」と迷うことになる。
状態の管理は僕らが裏でGitを握っておかないと破綻する。

また、こうしたエージェント連携を支える内部構造やプラグインの挙動に関しても、開発者が押さえるべき事実が浮き彫りになっている。

プラグインの設定において、フォルダ名や設定ファイル内の名称をたった1語変えただけで、手順書の実行回数が5回中0回から3回中3回へ変化する現象が確認された。

内部のAIが特定の文字列に対して過剰な警戒感を示し、処理を拒否してしまうためだ。

さらに、外部ツールとの接続権限を記述する際にも独特のルールが存在する。

画面上の一覧にはコロン区切りの形式で表示されるのに対し、許可設定ファイルには内部識別名であるアンダースコア区切りで書く必要がある。

表示通りの指定で呼び出すと実行成功率は3回中0回に留まり、すべて内部の拒否ログへ記録されてしまう。

そして最も注意すべきは、壊れた設定や存在しないパスを読み込ませた際の挙動だ。

画面には一切のエラーが出力されず、エラーサイズは0バイト、返ってくるのは正常終了を示す終了コード0である。

設定が反映されていないことに気づく術は、登録件数の数字が増えているかを手動で確認するしかない。

今回の更新は、AI同士の連携を「単なる伝言」にとどめる安全設計であると同時に、設定ファイルのわずかな命名ミスが静かな無視を引き起こすという開発上の課題を提示している。

あわせて読みたいAIエージェントを自作して本番運用する方法｜最小構成の実装とサブエージェント設計 →

画面の裏で起きている「静かな無視」と、Git管理へ回帰する僕らの設計論

セッション間でテキストを送れるようになった機能について、一番のポイントはコンテキストを共有しないという強烈な割り切りだ。

送信できるのはテキストの文字情報だけであり、これまで積み上げた会話の履歴や参照ファイルは一切相手に渡らない。

これはAIエージェントの安全性を担保するための明確な防波堤として機能している。

もしコンテキストごと相手のセッションに流し込める仕様だったら、悪意のある命令がセッションをまたいで伝播する危険性が跳ね上がる。

公式は、機能を単なる伝言に絞り込み、受け手側の権限や人間による承認プロセスを挟める余地を残した。

しかし、この仕様の裏には開発者を悩ませる大きな罠が潜んでいる。

設定や権限の記述にわずかな不整合があるだけで、AIが処理を静かに無視するという挙動だ。

僕らが開発を進める中で一番手痛いのは、画面上に何のエラーも表示されない現象である。

実際に設定ファイルを間違えたまま実行しても、返ってくるのは正常終了を示す終了コード0に過ぎない。

画面の見た目上は完璧に動いているように見えても、内部のログを確認すると呼び出し拒否が記録されている。

コマンドラインの点検ツールで合格と判定されたファイルであっても、実際の実行時にはツールが1件も認識されないといった挙動の乖離が存在する。

静的なチェックツールを過信して本番環境に投入すると、AIが何も仕事をせずに終わるという事態になりかねない。

この問題をさらに複雑にしているのが、プラグインやツールの命名規則がAIの判断に与える影響の大きさだ。

画面上に表示されるツール名と、権限設定ファイルで要求される内部の名称では表記規則が異なる。

画面に表示されたコロン区切りの名称をそのまま記述すると、呼び出し成功率は3回中0回となり、すべて拒否ログへ落ちる。

内部識別名であるアンダースコア区切りの形式に書き換えて初めて、成功率は3回中3回へと切り替わる仕組みだ。

中身がまったく同じ設定ファイルであっても、フォルダ名や設定上の名前を1語変更しただけで、AIが指示を実行する回数が5回中0回から3回中3回へと変化した実験データが存在する。

設定の破綻がエラーとして表面化せず、AIの知らん顔として現れるのが、現代のAIエージェント開発における最大の障壁だ。

しんたろー：
僕もClaude Codeで1人SaaSのThreadPostを開発しているけど、この「エラーを吐かずに黙ってスルーされる」のが一番胃に悪い。バグなら赤文字で倒れてくれた方が100倍マシだ。結局はログを直接監視して、アンダースコアの命名規則を泥臭く合わせるのが一番の近道だ。

では、このセッション間通信機能を使ってAI同士に複雑な連携をさせれば、僕らの開発作業はすべて自動化できるのだろうか。

どれだけAI同士が会話できるようになっても、作業状態の共有には別の仕組みが必要になる。

例えば、並列稼働の検証用に投入されたAIの数は16体だった。

この超大型実験において、メインの協調手段として採用されたのはメッセージ機能ではなくGitリポジトリだった。

各AIは作業状況を記述したロックファイルを更新し、競合が発生した場合はGitのコンフリクト検出によって自分の担当タスクを判断していた。

セッション通信はあくまで「処理が終わったよ」という通知を自動化するツールに過ぎない。

全体でどのようなコードが書かれ、どのタスクが完了しているかという「単一の正解」を保持するには、依然としてGitや共有ファイルシステムが不可欠だ。

メッセージだけで全状態を同期しようとすれば、やり取りのたびにトークンを無駄遣いし、API制限の壁にぶつかる。

僕ら開発者が構築すべきなのは、AI同士を過度に密結合させるシステムではない。

AIエージェントの協調は疎結合な伝言にとどめ、実際のコードや作業履歴はGitで厳格に管理するというアーキテクチャだ。

公式がセッション作成や自動往復に制限をかけているのも、無制限なトークン消費と制御不能なループを防ぐための合理的な制約だ。

AIエージェントを実務に組み込む際は、以下のポイントを前提として設計を組み立てる必要がある。

• 設定の検証は点検コマンドだけに頼らず、ログに出力される拒否記録を直接確認する
• 権限設定には画面表示のコロンではなく、内部名のアンダースコア表記を使用する
• AIの指示スキップを防ぐため、命名規則はプロジェクト内で厳密に統一する
• エージェント間の状態共有にはセッション通信を使わず、Gitやファイルロックを併用する

AIが喋り始めたからといって、僕らがコード管理の手を緩めていい理由にはならない。

AIが自立して動く範囲が広がったからこそ、バージョン管理システムという絶対の真実を中心に置く設計の重要性が高まっている。

明日の開発から変えるべき、AIエージェントの運用プロトコル

Claude Codeの機能拡張やマルチエージェント連携が実用段階に入ったことで、僕らの日常的な開発フローにも明確な変化が求められている。

これまで通りの感覚で設定ファイルや指示文を書いていると、エラーメッセージすら出ないサイレント障害に時間を奪われることになる。

開発実務において、今すぐ見直すべき具体的なポイントは以下の4つに集約される。

1. エラー表示を信じず拒否ログを監視する

プラグインのパス設定が壊れていても、CLIはエラーを吐かず終了コード0で正常終了する。

設定が反映されているか調べる際は、画面上の成功表示ではなく実際の拒否ログを直接確認する習慣をつける必要がある。

特に外部ツール（MCP）の権限設定では、画面上の表示名であるコロン区切りではなく、内部名のアンダースコア表記を使わなければ権限エラーで静かに弾かれる。

表示通りの指定では呼び出し成功率が3回中0回だったのに対し、アンダースコア形に変更しただけで3回中3回成功したデータがそれを示している。

2. プラグインやツールの命名規則を固定する

設定ファイルの中身が全く同じであっても、名前を1語変更しただけでAIがツールを呼び出す頻度が大きく変動する。

名前の違いによって発動回数が5回中0回から3回中3回へと激変した検証結果が存在する。

プロンプトや設定文の修正だけで悩むのではなく、識別子のネーミングがAIに不要な警戒心を与えていないか疑う視点が必要だ。

プロジェクト内での命名ルールを厳格にドキュメント化し、単語の揺らぎを排除することが安定動作への近道になる。

3. セッション間通信と状態管理の役割を分離する

新機能であるセッション間通信は、あくまでテキストメッセージを1本送るだけのシンプルな伝言板として割り切って使うべきだ。

この通信機能では過去の議論履歴や参照ファイルといったコンテキストは共有されず、未読メッセージの蓄積も上限が50件に制限されている。

しんたろー：
正直、AI同士が勝手に喋って勝手に開発を進めてくれる夢をちょっとだけ期待してた。
でもフタを開けてみたら「伝言はやるけど、状態はGitで管理してね」という泥臭い仕様だった。
でもだからこそ、Claude Codeで1人SaaS書いてる僕みたいな開発者には扱いやすい。

エージェント間の複雑なタスク受け渡しやコンフリクト防止には、メッセージ機能ではなくGitのロックファイルや専用ブランチを活用する設計が欠かせない。

16体のエージェントを動かした大規模な実験でも、タスクの重複を防ぎ並列処理を成功させたのはGitによる状態管理だった。

4. トークン消費のオーバーヘッドを常時把握する

プラグインやツールを追加して置いておくだけで、AIは毎回のやり取りでコンテキストを読み込む。

基本セットを読み込ませるだけで毎回の指示に154トークンの固定コストが上乗せされる。

便利だからといって不要なツールを読み込ませ続けると、応答速度の低下とAPIコストの増大を招く。

使わない機能はこまめに外し、セッションごとのトークン占有量を軽量に保つ運用を徹底したい。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

プラグインが正しく認識されているか確認する確実な方法は？

検証コマンドの claude plugin validate はあくまで補助的な判定にとどまる。

実行時にエラーが出ず、正常終了を示す数値である 0 というコードが返っても、一部の機能が静かに無視されているケースがあるからだ。

実務では、特定のファイルを読み込んだときだけ出力される特定の合言葉を仕込み、意図通りに動くか実機テストで確認するのが一番確実だ。

特に権限設定は表示名と内部名で表記が異なり、拒否ログを見ながらアンダースコア区切りの内部権限名へ調整する作業が欠かせない。

セッション間通信機能でエージェント同士のコンテキストや履歴を共有できる？

共有できない。

今回追加されたセッション間通信機能で送信可能なデータ量は テキスト1本 のみであり、過去の議論履歴や参照ファイルは一切引き継がれない仕様だ。

そのため、エージェント同士で複雑なタスク状態を共有したい場合は、従来通り Git リポジトリを介したファイル共有やロックファイルの運用が必要になる。

この機能はエージェント間の「伝言」を自動化するものであり、脳内や文脈の共有ではないと割り切って設計しよう。

プラグインを追加したのに応答しない場合、どこを疑えばいい？

まず確認すべき項目は、設定の 名前 と 拒否ログ の 2つ だ。

設定ファイルの中身が完璧であっても、フォルダや設定の文字数をわずか 1文字 変えただけでAIが安全装置を作動させ、処理を無視する現象が発生する。

また、外部ツールの接続画面で正常と表示されていても、権限名のフォーマット違いでブロックされている場合が多い。

AIの「動きました」という応答を過信せず、ログに記録された拒否メッセージと命名規則を真っ先にチェックしてほしい。

まとめ

セッション間通信の登場で、エージェント同士の連携は間違いなく面白くなった。

結局、コンテキストの断絶や命名規則の罠を泥臭くハックしていく作業こそが、開発の成果を左右する。

AIの「隠れた挙動」をどう乗りこなすか。

僕がClaude Codeで日々試行錯誤している実戦的な知見や運用の裏側は、ThreadPostでも発信していく。

👉 ThreadPostでSNS運用を自動化する