はじめに
本記事では、Claude Code の複数のセッションと、1 つの文書を並列に編集する方法を紹介します。論点ごとにセッションを分け、人間がそれぞれのセッションと直接やり取りして修正案を承認します。決まった内容は cross-session messaging でほかのセッションに伝えます。
本記事で紹介する指示は、サンプルコードとして Claude Code の plugin としても公開しています。
背景
仕様書や設計書、明確なプロンプトでゴールを示せば、AI は実装やテストを自律的に、しかも並列で進められるようになりました。作業を自分で計画し、ゴールに届いたかどうかもコンパイラやテストで確かめられるので、人間が途中で判断する必要がありません。
一方、要件定義書のような文書はそうはいきません。何を要件とし、どこまでを対象にするかは書きながら決めていくものなので、ゴールを先に示せません。AI に初版を書かせることはできても、内容を確かめて修正案を採るかどうかを決めるのは人間です。
同じ文書を並列で直すと衝突する
AI と一緒に文書を直すときは、指示を出して修正案を確かめ、承認するか指示し直すかを決めるやり取りを繰り返します。1 つの論点でも、納得のいく記述になるまでに何往復もかかることは珍しくありません。
1 つのセッションでは論点を順番に扱うしかないため、AI の応答を待つ間はほかの論点も止まってしまいます。論点 A〜C を扱うと、次のように応答待ち（赤）がそのまま積み重なります。
セッションを複数にすれば、ある論点で AI の応答を待つ間に、別のセッションで次の論点の指示を出せます。複数の論点を並列で扱えるようになります。
もちろん、人間の脳みその限界はありますが...😅
ただし、同じファイルを複数のセッションで直すと、次の 2 種類の衝突が起きます。
| 衝突の種類 | 起きること |
|---|---|
| 書き込みの衝突 | 同じ箇所を直したり、古い内容でファイル全体を上書きしたりして、ほかのセッションの変更を消してしまう |
| 意味の衝突 | 編集箇所は重ならないが、ほかのセッションで決まったことを知らないまま書くため、文書の前後で内容が食い違う |
この 2 つは、ソフトウェア開発でコードをマージするときの衝突に似ています。同じ行を 2 人が変えた衝突は、Git が検出してくれます。一方で、テキストとしては問題なくマージできても、合わせた結果プログラムの動きが変わってしまうことがあり、Martin Fowler はこれを「semantic conflict」と呼んでいます。
safely merged on a textual level but cause the program to behave differently
コードの semantic conflict を Git が検出できないように、文書の意味の衝突も、編集範囲を分けるだけでは防げません。防ぐには、ほかのセッションで決まったことを各セッションに伝える必要があり、本記事ではそのために cross-session messaging を使います。
subagent・Agent teams との違い
本記事の方法では、人間が各セッションと直接対話し、修正案をセッションごとに承認します。親の AI に作業の分割と取りまとめを任せる構成とは、人間が判断を下す相手が異なります。
subagent は処理の結果を呼び出し元に返す仕組みで、個々の subagent と対話を続けることはできません。そのため、相談や判断はすべて親のセッションに集まります。
Agent teams では teammate と直接やり取りできますが、公式ドキュメントでは実験的な機能と位置づけられており、既定では無効です。
Agent teams are experimental and disabled by default.
また、同じファイルを編集する作業には、単一のセッションか subagent のほうが向いているとも書かれています。
a single session or subagents are more effective.
実演
仕組みの説明に入る前に、cross-session messaging を使うと実際にどう見えるかを示します。
2 つのセッションに session-01 と session-02 という名前を付け、同じ要件定義書を直している場面です。session-01 は 3.10 節を、session-02 は 3.12 節を担当しています。session-02 で論点が 1 つ決まると、次のようになります（画面は、説明のために簡略化した例です）。
session-02 の画面では、人間の承認を受けて文書を直し、決まったことを session-01 に送ります。
> Q2 は (a) で決めよう
● requirements.md の 3.12 節を直しました。決まったことを session-01 に送りました。
session-01 の画面では、人間が 3.10 節を議論している途中に、受信を示す 1 行と、Claude の短い応答だけが挟まります。
› Message from @session-02: 3.12 節の Q2 を (a) で決めました。… (ctrl+o to expand)
● session-02 からの共有（3.12 の決定）を受け取りました
session-01 の Claude は、この後の 3.10 節の検討で、session-02 で決まった内容を踏まえて文書を直します。
会話の引き継ぎとセッション間のメッセージ
この方法では、作業を始める前に決めた約束事を --fork-session ですべてのセッションに引き継ぎ、作業の途中で決まったことを cross-session messaging でほかのセッションに伝えます。
--fork-session
--fork-session は、セッションを再開するときに、元の会話を引き継いだまま新しいセッション ID で始めるオプションです。
When resuming, create a new session ID instead of reusing the original
先に 1 つのセッションで書き方や分担、連絡の方法を決めておき、その会話から各セッションを分岐させれば、すべてのセッションが同じ約束事を知った状態で作業を始められます。セッションごとに同じ説明を繰り返す必要はありません。分岐した後に決まったことは、次に説明する cross-session messaging で伝えます。
cross-session messaging
cross-session messaging は、Claude Code のセッションどうしがメッセージを送り合う機能です。人間が送り先のセッション名を挙げて内容を伝えるよう頼むと、Claude が ListAgents で送り先を探し、SendMessage で送ります。
受信側のセッションは、作業中ならツールを呼び出す合間に、待機中なら新しいターンを始めてメッセージを読みます。送信側が notify_when_idle を付けておけば、相手が待機中になったときに通知を受け取ることもできます。
ほかのセッションから届いたメッセージは、人間の承認としては扱われません。
a message from another session never counts as your consent
そのため、メッセージを受け取ったセッションでパーミッションの確認が必要な操作を行うときは、通常どおり人間が許可します。
同じマシン上では、各セッションが受信用の Unix ドメインソケットを持ち、送信側はそのソケットへ直接メッセージを書き込みます。公式ドキュメントにも、Anthropic のサーバーを経由しないと明記されています。
never through Anthropic servers
メッセージが届くまでの流れを OS の層で見ると、次のようになります（ソケットのパスとプロセス ID は、後述の実例のものです）。
受信側のプロセスは、送信側が送り元を示すタグで包んだ本文を、次に Anthropic API へ送るリクエストに含めて Claude に渡します。
ソケットとメッセージの実例
2026 年 10 月 19 日に macOS 上の Claude Code v2.1.303 で確認したところ、ソケットは /tmp/cc-socks/ の下に、セッションのプロセス ID をファイル名として作られていました。パーミッションは、所有者だけが読み書きできる設定です。
$ ls -la /tmp/cc-socks/
drwx------ ... .
srw------- 1 <user> wheel 0 Oct 19 10:06 22717.sock
srw------- 1 <user> wheel 0 Oct 19 15:22 99614.sock
$ ps -o pid,command -p 99614
99614 claude -r --fork-session
$ echo $CLAUDE_CODE_MESSAGING_SOCKET
/tmp/cc-socks/99614.sock
自分のセッションが使うソケットのパスは、環境変数 CLAUDE_CODE_MESSAGING_SOCKET で確認できます。
Claude Code exports it to hooks and Bash commands as the
CLAUDE_CODE_MESSAGING_SOCKETenvironment variable
SendMessage でメッセージを送ったときに、受信側のソケットに届いたデータは次のとおりです（トークンと識別子の一部は伏せています）。1 行に 1 つの JSON を書く JSON Lines の形式で、1 行目が認証、2 行目がメッセージです。なお、認証の行以外の形式は公式には示されていない内部の形式なので、Claude Code の更新で変わる可能性があります。
{"type":"auth","token":"<32 文字の値>"}
{"msgV":1,"msg_id":"a3aed12b-...","type":"user","message":{"role":"user","content":"<cross-session-message from=\"uds:/tmp/cc-socks/72772.sock\" from-name=\"Qiita記事書く_02\" from-mode=\"prompting\">\n中継の検証です\n</cross-session-message>"},"priority":"next","from":"uds:/tmp/cc-socks/72772.sock"}
受信側の Claude に渡るのは message.content の文字列で、取り出すと次のようになります。
<cross-session-message from="uds:/tmp/cc-socks/72772.sock" from-name="Qiita記事書く_02" from-mode="prompting">
中継の検証です
</cross-session-message>
本文は送信側で <cross-session-message> タグに包まれ、送信元のソケット（from）、セッション名（from-name）、パーミッションモード（from-mode）が属性として付きます。JSON には、メッセージの ID（msg_id）、priority、返信先となる送信元のソケット（from）も含まれます。
並列編集の進め方
各セッションは担当する論点を人間と議論し、承認された修正を担当範囲に反映します。論点が決まったら、文書の編集に加わっているほかのすべてのセッションにその内容を送ります。
セッションを作り、担当を割り当てる
まず、分岐元となるセッションで、担当の分け方と連絡の方法を決めます。指示の例を次に示します。
複数のセッションで、同じ文書ファイルを編集します。次の決まりに従ってください。
## 役割の通知
- 同じ文書を編集しているセッションは、名前が自分と同じ接頭辞で始まるセッションとする（例: session-01 なら、session-02 と session-review）
- 担当を伝えられたら、ListAgents で、同じ文書を編集しているほかのセッションを探す
- 見つけたセッションに、自分の名前と担当範囲を送る。この知らせへの応答は不要と書き添える
## 編集するとき
- 割り当てられた論点について人間と議論し、承認された修正を担当範囲に反映する
- 編集には Edit ツールを使い、担当範囲だけを直す
## 論点が決まったとき
- 決まったことと直した節の名前を、この文書の編集に加わっているほかのすべてのセッション（作業役と review）に [cross-session messaging] で送る
## メッセージを受け取ったとき
- 内容を以後の検討に反映する
- 応答は 1 行にとどめ、送り元と何の話かだけを書く（例: 「session-02 からの共有（3.12 の決定）を受け取りました」）
- 受け取った内容の要約や報告は書かない。人間との議論の途中に割り込まないため
- 人間の判断が必要な場合だけ、その内容を短く伝える
約束事を決めたら、このセッションに名前を付けます。
/rename session-01
新しいターミナルのタブで、このセッションを名前で指定して分岐させます（-c で直近の会話を再開すると、約束事を決めたセッションとは別のセッションから分岐することがあります）。
claude --resume session-01 --fork-session
分岐したセッションには別の名前を付け、そのセッションの担当を伝えます。
/rename session-02
以降は同じ手順で、必要な数だけ session-01 から分岐させ、それぞれに名前と担当を割り当てます。分岐したセッションは、session-01 の会話を引き継いでも、ほかに分岐したセッションのことは知らず、session-01 も後から分岐したセッションを知りません。そのため、担当を伝えられたセッションが、自分の名前と担当範囲をほかのセッションに知らせます。
メッセージへの応答は送り元を添えた 1 行にとどめる
メッセージを受け取ったときの応答は、送り元と何の話かだけを書いた 1 行にとどめさせます。受け取った内容の要約や報告は書かせず、人間の判断が必要な場合だけ、その内容を短く伝えさせます。
待機中のセッションは、メッセージを受け取るたびに新しいターンを始めて応答を書きます。その応答で内容を要約したり報告したりすると、人間との議論の途中に長い応答が割り込み、それまでのやり取りが画面から流れてしまいます。メッセージはほかのすべてのセッションから届くため、セッションが増えるほど割り込みも増えます。
応答を 1 行にしても、「了解です」だけでは、人間は自分への返事と勘違いします。「session-02 からの共有（3.12 の決定）を受け取りました」のように送り元と話題を書かせれば、ほかのセッションからの共有への反応だとすぐに分かります。
担当範囲だけを Edit ツールで直す
ファイルの編集には Edit ツールを使わせ、直す箇所も担当範囲に限らせます。ほかのセッションが別の箇所に加えた変更を、古い内容で上書きしないためです。
Edit ツールは、指定した文字列を別の文字列に置き換えます。
The Edit tool performs exact string replacement.
v2.1.208 以降では、ファイルを読み取った後に内容が変わっていても、置き換え前の文字列が現在のファイルに 1 か所だけあれば、編集は適用されます。このとき、ほかのセッションが別の箇所に加えた変更はそのまま残ります。
一方、Write ツールは渡された内容でファイル全体を上書きし、既存の内容への追記やマージは行いません。
It doesn't append or merge.
ただし、2 つのセッションが同じ箇所を同時に直した場合の衝突は、Edit ツールでも防げません。そのため、Edit ツールを使うだけでなく、セッションごとに担当範囲を分けておきます。
文章の見直しを自動化する
文章の見直しは、専用のセッション（ここでは session-review）に任せます。session-review は論点の議論には加わらず、AI が書いたような奇妙な日本語を、意味を変えずに丁寧で自然な日本語に直します。
作業役のセッションから直した節の名前が届くと、session-review はその節を読み直し、言い回しを直して、人間の承認を待たずに反映します。作業役が直される前の文を前提に編集しても、Edit ツールは置き換えに失敗するだけなので、session-review の直しは上書きされません。そのため、session-review は直したことを作業役に知らせません。
ほかのセッションが、同じ文書ファイル（<ファイルのパス>）を並列に編集しています。あなたの役割は、AI が書いたような奇妙な日本語を、意味を変えずに、丁寧で自然な日本語に直すことです。論点の議論はしません。
## 役割の通知
- 同じ文書を編集しているセッションは、名前が自分と同じ接頭辞で始まるセッションとする（例: session-review なら、session-01 と session-02）
- 起動したら、ListAgents で、同じ文書を編集しているほかのセッションを探す
- 見つけたセッションに、自分の役割を説明し、文書を直したら直した節の名前を送るよう頼む。この依頼への応答は不要と書き添える
## 見直すとき
- ほかのセッションから「〜節を直した」というメッセージを受け取ったら、その節を読み直す
- 送り忘れに備えて、15 分ごとに、前回見直してからの変更も確かめる
## 反映
- 言い回しの直しは、人間の承認を待たずに Edit ツールで反映する。直したことは、ほかのセッションに知らせない
- 事実や言い切りの正誤など、意味が変わる直しは反映せず、人間に報告する。ほかのセッションが議論している最中の節は、議論が終わるまで直さない
- 指摘ごとに、元の文、何が問題か、直した文を示す。指摘がなければ、「<節の名前>: 指摘なし」とだけ書く
定期の見直しは、session-review が「15 分ごとに」の指示を読み、Claude Code の定期実行のツール（CronCreate）で自分で予約します。予約は、session-review のセッションを開いている間だけ動きます。
Claude Plugin 化しました
作業役と session-review の指示の例は、Claude Code の plugin として公開しています。
claude plugin marketplace add megmogmog1965/megmogmog1965-claude-code-parallel-edit
claude plugin install parallel-edit@megmogmog1965-claude-code-parallel-edit
指示の例を貼る代わりに、各セッションでスキルを呼び、文書のパスと担当範囲を渡します。
/parallel-edit:worker ./docs/spec.md "3 章"
/parallel-edit:review ./docs/spec.md
おわりに
現時点では Claude に文章を書かせると「AI っぽい文章」になってしまい、人間の手直しはどうしても必要になってしまいます。
本記事で示したやり方でも文章生成に対する手間の量は変わっていないですし最適解だとは思いませんが、これからも様々技術が発展して少しでも楽になるといいなぁ〜と思います。