Claude Codeのセッション連携に学ぶAIの役割分担設計

「AIに任せたら、別の作業が壊れていたことに後で気づいた」「1つのセッションに全部やらせていたら、途中で何を頼んだのか自分でも分からなくなった」——AIに実務を任せ始めた人ほど、この取りこぼしに一度はぶつかります。

結論から言うと、AIを事故らせないコツは「賢い1体をどこまで信じるか」ではなく、仕事を役割で分けて、役割の間で渡すものを"要約だけ"に絞るという設計にあります。2026年8月にClaude Codeへ入った新機能「クロスセッション・メッセージング」は、その原則を道具の側から裏づける形になりました。

株式会社Fyveは、中小企業や個人事業のためにAIを実務へ落とし込む支援をしています。私自身、無人で回す定期処理と、その場で判断する対話作業を役割で分けて日々動かしてきました。この記事では、新機能の事実を押さえたうえで、非エンジニアの方が明日から使える「AIの役割分担設計」に翻訳してお伝えします。

クロスセッション・メッセージングとは——Claude Codeのセッション連携（v2.1.224）

まず新機能の事実を、公式ドキュメントと複数メディアの報道で確認できた範囲だけ整理します。断定できない仕様細部は避け、裏取りが取れたところに絞ります。

なぜ今このテーマが重要なのか。背景には、AIエージェントが「調べる」だけでなく「実際に手を動かす（ファイルを書き換える・外部ツールを操作する）」方向へ急速に進んでいる流れがあります。実行権限をAIへ渡すほど、便利さと引き換えに「取りこぼしや暴走が実害に直結する」リスクが上がります。だからこそ、任せる前に役割と境界をどう設計するかが、以前より重い問いになっているのです。

クロスセッション・メッセージングは、2026年8月7日にClaude Code v2.1.224で公開された機能です（macOS と Linux が対象。Windows は対象外で、Amazon Bedrock などのクラウド提供版でも使えません）。同じマシンやアカウントで動いている「別のセッション」同士が、互いを見つけて連絡を取り合えるようになりました。

仕組みは2つの道具で成り立っています。

• ListAgents——いま動いている他のセッション（別のターミナルやプロジェクト、バックグラウンドで進んでいるものを含む）を一覧で見つける
• SendMessage——見つけた相手にメッセージを届ける

ここで一番大事なのは、セッション間で渡るのは「テキスト（要約）」だけだという点です。会話の履歴も、ファイルも、権限も渡りません。受け取った側には、送り主へのリンクが付いた「カード」として表示されるので、どこから来た連絡かを後から辿れます。公式ドキュメントは、届いたメッセージが勝手に権限承認を通したり、設定を書き換えたりはできないと明記しています。

用途としては、たとえば「あるセッションが加えた変更が、別のセッションの前提を壊しそうなとき、影響が出る相手に一言知らせる」「別のセッションが待っている答えを渡す」といった連携が想定されています。派手な機能ではありませんが、設計思想がはっきり出ているのがこの機能の面白いところです。

クロスセッション・メッセージングは"共有メモリ"ではない

ここを勘違いすると使い方を誤ります。この機能は「複数のセッションで頭の中を1つに共有する」ものではありません。渡るのはあくまでその都度の1通のメッセージ（テキスト）だけで、各セッションは自分の文脈を各自で保ったままです。

言い換えると、これは「みんなで同じノートに書き込む」仕組みではなく、「別々のノートを持つ人同士が、必要なときに一言メモを渡し合う」仕組みです。だからこそ、片方の混乱が全体に広がらず、役割ごとの独立が保たれます。「連携＝全部を共有すること」だと考えていると、この割り切りの意味を取り違えてしまいます。連携とは、共有ではなく"絞って渡すこと"——これがこの機能の隠れたメッセージです。

なぜ「1人の万能AI」は取りこぼすのか

新機能の話に入る前に、そもそもなぜ役割で分けるのか、という土台を押さえておきます。ここが腹落ちしていないと、便利な道具を足しても事故は減りません。

注意力は再現しない

1つのセッション（1体のAI）に、調査も、実装も、文章の推敲も、公開判断も全部載せると、最初はうまくいくように見えます。ところが作業が長くなるほど、AIは前半で自分が決めたことを取りこぼし始めます。「さっき"公開前に必ず確認する"と言ったのに、いつの間にか確認を飛ばして先に進んでいた」という現象です。

これは能力の問題というより、注意を最後まで一定に保つのが再現しないという構造の問題です。人間が長時間の単純作業でミスを増やすのと同じで、「気をつける」で塞げる穴ではありません。私の経験でも、最もコストが高くつくのは派手な失敗ではなく、この静かな取りこぼしでした。誰も気づかないまま間違った成果物が世に出てしまうからです。

全部を1体に載せると「渡すものを絞る余地」が消える

もう1つの問題は、1体に全部載せていると、そもそも「何を渡して、何を渡さないか」を選べないことです。頭の中で全部つながっているので、切り分けようがありません。役割を分けて初めて、「この役割にはこの情報だけあれば十分」という線引きができるようになります。渡すものを絞れる人だけが、任せても事故りにくい状態を作れます。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

私の運用——無人で回す作業と、その場で判断する作業を分ける

ここからは私自身の運用です。私は日々のAI活用を、大きく2種類の役割に割っています。

• 無人で回す作業（定期処理）——決まった時刻に、決まった手順で走る。人が横で見ていない前提で組む
• その場で判断する作業（対話）——目の前で相談しながら進め、最後の判断は人が下す

この2つは、求められる性質がまるで違います。無人側は「勝手に暴走しないこと」「取りこぼしても止まること」が最優先で、便利さより安全側に倒します。対話側は逆に、その場の文脈をたっぷり持たせて、判断のキレを上げます。

具体的に、無人側では次のような設計にしています。触ってよい範囲を事前に絞り、範囲の外へ書き込もうとしたら、その作業を採用せず止める。人が横で見ていない前提だからこそ、「うっかり範囲外を触った」を後から気づく仕組みではなく、その場で止める仕組みにしておく。加えて、同じ処理を二度走らせても壊れないように作り、迷ったら進めずに人へ返す（＝止まる方を既定にする）。便利さを少し削ってでも、この安全マージンを厚くしておくのが無人側の鉄則です。

一方の対話側は、私が目の前にいるので、多少踏み込んだ操作でも、最後に私が確認して判断できます。同じAIでも、役割が違えば「どこまで自由にさせるか」の設計が正反対になる——これが、役割を分けて初めて手に入る設計の自由度です。1体に全部載せていると、この「役割ごとに緩急を変える」ことができません。

両者の間でやりとりするときも、私は丸ごとの文脈を渡しません。無人側が仕上げた成果は「何を作ったか」の要約と置き場所だけを対話側に渡し、対話側はそれを見て「公開してよいか」を判断します。履歴を全部見せ合う必要はないし、見せ合うと逆に判断がぶれます。

新機能のクロスセッション・メッセージングを最初に見たとき、私が感じたのは「自分が手作業で組んでいた"役割を分けて、要約だけ渡す"やり方が、道具の側に降りてきた」ということでした。得をするのは、自分の仕事をすでに役割へ割れている人だけです。丸ごと1体に載せている人には、分ける対象も、渡すものを絞る余地もありません。

役割分担そのものの考え方（どこで止め、どこを隔離するか）は、別の記事で詳しくまとめています。

Claude CodeAIエージェントの役割分担｜停止点と隔離の設計

具体例：調べる役と判断する役を分けて動かす

抽象論だけだと掴みにくいので、身近な例に落とします。ある話題について「最新情報を調べて、記事の下書きを作り、公開する」という仕事を、AIに任せるとします。これを1回のお願いで丸ごと投げるのではなく、役割を3つに割ります。

• 調べる役——複数の情報源を当たり、事実と出所を集める。判断や公開はしない
• 書く役——調べる役から「要点と出所」を受け取り、下書きを作る。集めた生データ全部は受け取らない
• 公開する役——書く役から「原稿と、確認してほしい点」を受け取り、公開前チェックを通してから出す

ポイントは、役割の間で渡すものを絞っていることです。調べる役が集めた検索結果を丸ごと書く役へ渡すと、書く役は情報の海で溺れます。だから「要点と出所」だけを渡す。書く役から公開する役へも、原稿と注意点だけを渡し、途中の推敲履歴は渡しません。

こうしておくと、たとえば公開する役が「この固有名詞、裏取りの出所が見当たらない」と気づいたとき、調べる役にだけ差し戻せます。全部が1体に載っていたら、どこで裏取りが抜けたのかを丸ごと辿り直すことになります。役割を割ってあるから、問題の切り分けが一手で済むのです。これは、複数のセッションが要約を渡し合うクロスセッション・メッセージングの想定用途と、ちょうど重なります。

渡すのは"要約だけ"——履歴・ファイル・権限を渡さない設計

クロスセッション・メッセージングの仕様で、私が最も重要だと考えるのは「渡るのはテキストだけで、履歴・ファイル・権限は渡らない」という割り切りです。これは技術的な制約であると同時に、安全にAIを連携させるための設計原則そのものです。

なぜ要約だけに絞ると安全なのか。理由は3つあります。

1. 権限が伝染しない

あるセッションが「ファイルを書き換えてよい」という許可を持っていても、その許可はメッセージ経由で相手に移りません。もし権限まで一緒に渡ってしまうと、連絡を受けただけのセッションが、本来できないはずの操作をできてしまう。連絡と権限を切り離すのは、AIに実行権限を渡す時代の基本の守りです。

2. 事故の飛び火が小さくなる

渡すのが要約テキストだけなら、片方のセッションが変な状態に陥っても、相手に丸ごと感染することはありません。渡した「言葉」が届くだけで、内部状態は各自のまま。役割ごとに被害を閉じ込められます。

3. 受け取る側の判断がぶれない

全履歴を渡されると、受け取った側は情報の海に飲まれて、かえって何を判断すればいいか分からなくなります。「要点はこれ」という要約に絞られていれば、判断の軸がはっきりします。人間同士の引き継ぎでも、分厚い議事録より1枚のサマリーの方が動けるのと同じです。

権限を分けて渡す・渡さないの線引きについては、権限モードの記事も参考になります。

Claude CodeClaude CodeのManual権限モードとは｜AIに安全に任せる新しい権限設定

三段設計——「役割に割る→各役割に関所→受け渡しは要約だけ」

ここまでを1本の設計にまとめると、AIに任せる仕事の品質は、次の三段で守れます。私はこれを「注意力でなく工程で守る」と呼んでいます。

1. 役割に割る——仕事を「無人で回す/その場で判断する」「調べる/書く/公開する」のように役割へ分解する
2. 各役割に関所を置く——役割ごとに「ここを通らないと次へ進めない」チェック点を工程の中に埋める
3. 受け渡しは要約だけ——役割の間で渡すのは要点のテキストに絞り、履歴・ファイル・権限は渡さない

この三段の関係は、どれか1つでは穴が塞がりません。役割を分けても関所が無ければ取りこぼすし、関所を置いても「何をチェックするか」の中身が空なら、関所も止めようがない。私は以前、投稿原稿を自動点検する仕組みを組んだのに、点検の中身（規範）が薄かったせいで、崩れた表現が関所を素通りしたことがありました。教訓は、「守ってほしいことの中身」と「必ず実行させる仕組み」は別の層で持ち、片方を直したらもう片方も対応させるということです。

良い関所とは、通らないと先に進めないもの

「関所」と言うと堅苦しいですが、要はそれを通過しないと次の工程へ進めない確認点のことです。ここで大事なのは、関所が「お願いベース」ではなく「通過が条件」になっていることです。

「できれば確認してね」は関所ではありません。忙しい人が横断歩道の一時停止を省くように、AIも長い作業の途中では"できれば"を飛ばします。良い関所は、確認を飛ばしたら次へ進めない形になっている。たとえば「公開の役割は、タイトルと固有名詞を読み上げて自分でOKを出すまで、公開の操作へ進まない」というように、確認と前進を結び付けておきます。

もう1つの条件は、関所の中身が具体的であることです。「品質を確認する」ではAIも人も何を見ればいいか分かりません。「固有名詞の出所が本文かメモにあるか」「タイトルが32文字を超えていないか」のように、イエス・ノーで答えられる粒度まで落とすと、関所が実際に機能し始めます。中身が曖昧な関所は、置いてあっても素通りされます。

図の左のように1体へ全部載せると、渡すものを絞る余地がなく、取りこぼしがそのまま外へ出ます。右のように役割で分け、間を要約だけでつなぐと、各役割に関所を置け、事故が飛び火しません。クロスセッション・メッセージングが「テキストだけ渡す」と割り切っているのは、まさに右側の形です。

非エンジニアが明日から使うには

「セッションを分ける」と聞くと技術的に感じますが、考え方は事務作業の分担と同じです。専門ツールを入れる前に、まず次の順で整理してみてください。

ステップ1：1つのお願いに詰め込みすぎない

「調べて、下書きして、投稿まで一気にやって」と1回で頼まず、「調べる」「下書きする」「最終チェックする」に分けて頼みます。分けるだけで、途中の取りこぼしが目に見えるようになります。

ステップ2：役割ごとに"必ず通す確認"を1つ決める

たとえば「公開の役割は、公開前に必ずタイトルと固有名詞を読み上げて確認する」のように、役割に1つだけ関所を決めます。多すぎると形骸化するので、まずは各役割1つで十分です。

ステップ3：役割の間で渡すのは"要点"に絞る

前の役割の全部をコピペして次に渡すのではなく、「何を作ったか・どこに置いたか・注意点は何か」の3行だけを渡します。渡す情報を絞るほど、次の役割は判断しやすくなります。

手順書に検品を埋め込む具体的な書き方は、こちらの記事で解説しています。

AI業務効率化AIに任せる手順書の書き方｜検品を工程に埋め込む

やりがちな失敗——役割分担のアンチパターン

役割で分ける設計は強力ですが、やり方を誤ると逆に事故を増やします。私が実際に踏んだ、あるいは相談を受けてよく見る失敗を挙げます。

分けすぎる

役割を細かく割りすぎると、受け渡しの回数ばかり増えて、どこで何をしているのか追えなくなります。目安は「1つの役割を一言で説明できる」こと。「調べて整理して要約して分類して……」と説明に接続詞がいくつも要るなら、それは1つの役割に詰め込みすぎか、逆に割りすぎのどちらかです。まずは2〜3の役割から始め、痛みが出たところだけ足すのが安全です。

関所を増やしすぎて形骸化する

「念のため」で確認点を10個も並べると、人もAIも全部は守れず、結局どれも素通りするようになります。関所は数ではなく質です。役割ごとにまず1つ、「これだけは絶対に通す」というものを決め、それが機能してから足す。多い関所は、無い関所と同じくらい危険だと考えてください。

要約が薄すぎる／厚すぎる

「要約だけ渡す」を、単に短くすることだと誤解すると、次の役割が判断できません。逆に不安で全部盛り込むと、渡す意味がなくなります。良い要約の基準は「次の役割が、その要約だけで次の一手を決められるか」です。短さでも網羅でもなく、受け手が動ける最小限を狙います。

権限をまとめて渡してしまう

「面倒だから、この役割に全部の権限を持たせておこう」とやると、役割を分けた意味が半分消えます。連絡や情報は渡しても、「触ってよい範囲」は役割ごとに絞る。クロスセッション・メッセージングが「権限は渡さない」と割り切っているのは、この失敗を道具の側で防いでいるとも言えます。触らせない範囲を先に決めておくのが、任せる前の一番の守りです。

よくある疑問

セッションを分けると、かえって管理が煩雑になりませんか？

最初は手間が増えたように感じます。ですが、1体に全部載せて「どこで何が壊れたか分からない」状態を後から解きほぐすコストの方が、はるかに高くつきます。役割が分かれていれば、問題が起きた役割だけを見ればよく、原因の切り分けが速くなります。

「要約だけ渡す」と、大事な情報が抜け落ちませんか？

ここは中身次第です。要約が薄ければ判断を誤ります。だからこそ、渡す要約には「次の役割が判断に必要な要点」を意識して入れます。全部渡すことと、要点を渡すことは違います。目指すのは前者の"安心"ではなく、後者の"判断できる状態"です。

Windowsでは使えないのですか？

クロスセッション・メッセージング自体は、現時点でmacOSとLinuxが対象です。ただしこの記事で伝えたい「役割で分けて要約だけ渡す」という設計は、特定のツールや機能に依存しません。道具が無くても、頼み方と手順の分け方だけで今日から実践できます。

特別なツールを導入しないと、この設計はできませんか？

いいえ。新機能はこの設計を"楽にする"だけで、前提ではありません。普段お使いのAIチャットでも、「1回のお願いに詰め込まない」「役割ごとに確認点を決める」「次へは要点だけ渡す」の3つを守れば、同じ効果が得られます。まずは道具を増やす前に、頼み方を分けるところから始めるのが、失敗の少ない順序です。ツールはあくまで、整った運用の上に乗せるものだと考えてください。

導入チェックリスト——自分の任せ方を点検する

最後に、今の自分のAIの任せ方を点検できるチェックリストを置きます。新機能を使うかどうかに関わらず、役割分担の設計として使えます。1つでも「いいえ」があれば、そこが取りこぼしの入口です。

• 1つのお願いに、性質の違う作業（調べる・書く・公開する等）を詰め込みすぎていないか
• それぞれの役割を、接続詞なしの一言で説明できるか
• 役割ごとに「これだけは必ず通す」確認点を1つ決めているか
• その確認点は「中身（何をチェックするか）」まで具体化されているか（"確認する"という掛け声で終わっていないか）
• 役割の間で渡すのを「要点」に絞れているか（前の作業を丸ごとコピペしていないか）
• その要約だけで、次の役割が次の一手を決められるか
• 「触ってよい範囲（権限）」を役割ごとに絞っているか（全部の権限をまとめて渡していないか）

このリストは、そのままAIに任せる作業の"設計図"になります。まず紙に自分の仕事を書き出し、どこで役割が混ざっているかを見つけるところから始めると、取りかかりやすいはずです。

まとめ——道具が横並びの時代、差は"工程の設計"に出る

AIに任せる仕事の品質は、賢い1体をどこまで信じるかでは決まりません。役割に割り、各役割に関所を置き、受け渡しは要約だけにする——この三段の設計で決まります。

Claude Codeのクロスセッション・メッセージングが「テキストだけ渡す/履歴・ファイル・権限は渡さない」と割り切ったのは、便利さの追求ではなく、任せて事故らないための最小設計を道具に落とした結果だと私は見ています。同じ設計は、専門ツールが無くても、頼み方と手順の分け方だけで実践できます。

私たちは、こうした「AIに任せる工程の設計」を、中小企業や個人事業の現場に合わせて一緒に組み立てる支援をしています。まず自分の仕事を役割に割ってみるところから、始めてみてください。