複数セッションのClaude Code運用｜並行と直列を分ける4つの軸

タブをもう1つ開くだけで、手が増えたように見えます。Claude Codeは、それを止めません。止められないからこそ、重ねてよい組み合わせかどうかを考える前に手が動きます。

困るのは、重ねた瞬間ではありません。片方の書き込みがもう片方を上書きし、誰も気づかないまま保存が進んだあとです。消えたことに気づくのは、たいてい別の作業をしている最中です。

この記事は、並行させてよい条件と、途中で直列へ戻すサインを扱います。素材は運営元WEBMARKSで実際に起きた衝突と、公式ドキュメントです。検証環境はclaude-opus-5・Claude Code v2.1.x・macOS 15で、2026-08-03に確かめた条件です。

進行役は3人です。若葉さんが用語の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01Claude Codeの複数セッションを、AIエージェントに何本まで同時に持たせていいんですか？

若葉さん

若葉さんの発言

そもそも、同時にいくつも開いてよいものなんでしょうか。開けてしまうということは、問題ないという意味ですか。

鈴木さん

鈴木さんの発言

コンロに近いと思っています。口がいくつあっても大丈夫ですが、1つの火に鍋を2つ乗せることはしませんよね。数ではなく、鍋と火の組み合わせの話です。

Claude Codeは、複数のセッションを同時に開くこと自体を制限していません。ターミナルのタブやウィンドウを増やすだけで、並行作業を始められます。その手軽さが、判断を後回しにさせます。

先に結論を書きます。並行させてよいのは、①触る対象が重ならない、②互いの出力に依存しない、③どちらも人間ゲートの直前まで進んでいない、この3つがそろったときだけです。1つでも欠けたら、順番を決めて直列にします。

判断を誤ると、片方の書き込みがもう片方を上書きし、気づかないまま作業が進みます。ここが厄介なところで、上書きは対象が重なった瞬間には音を立てません。誰も見ていない場所で保存が進んだあとに、はじめて発覚します。

つまり「何本まで開けるか」という問いの立て方が、そもそもずれています。台数の上限ではなく、組み合わせの相性を見ます。運営元WEBMARKSは2026-06-24にAI社員体制を統合したところで、稼働はまだ約1か月ですが、複数のセッションを同時に開く場面はすでに日常です。

Claude Codeを業務でどこまで使うかの全体像は、Claude Codeの業務活用｜任せる仕事の地図と判断軸4つにまとめています。ここで扱う判断は、その実行運用にあたる論点の1つです。

02複数セッションを並行させて事故にならないのは、AIエージェントがどんな条件を満たしたときですか？

並行してよいかどうかは、感覚ではなく3つの条件で判定します。

1. 触るファイル・ディレクトリが重ならない（例: 片方は記事本文、もう片方は図解のSVGだけを扱う）
2. 片方の出力を、もう片方が読み込む必要がない（依存関係がない）
3. どちらのセッションも、送信・公開・削除のような人間ゲートの直前まで進んでいない

Claude Codeの公式ドキュメントは、サブエージェントが独立した文脈を持つと説明しています（出典: Claude Code公式ドキュメント「Sub-agents」）。ここで気をつけたいのは、独立しているのは文脈であって、書き込み先ではないという点です。

文脈が別でも、出口が同じなら書き込みは重なります。3つの条件がそろってはじめて、競合する余地がなくなります。

具体例で見ます。片方のセッションで記事の本文を書き、もう片方で別の記事の本文を書くなら、対象は重なりません。逆に、両方が同じ記事マップCSVのstatus列を更新しようとするなら、ファイルは1つですから対象が重なります。

03複数セッションを走らせたあとに直列へ戻すサインは、AI社員の手元のどこに出るんですか？

高梨課長

高梨課長の発言

開く前に確認したつもりでも、途中で「これはまずいのでは」と思う瞬間があります。あれは何を見ているんでしょうか。

鈴木さん

鈴木さんの発言

開始時点では見えていなかった重なりが、走らせたことで見えた瞬間だと思っています。だから、途中で止められる作業から並行に回すほうが安全です。

並行で始めても、途中で直列に戻すべきサインが2つあります。

1. 同じファイルパスに、両方のセッションが書き込もうとしていると気づいたとき
2. 片方の結果を見てから、もう片方の入力を決めたいと感じたとき

どちらも、開始時点では見えていなかった重なりです。2つ目は、あとから依存に気づいたケースにあたります。走らせてから気づく前提で組み立てておくと、止める判断が軽くなります。

たとえば、片方のセッションが作った図解のキャプションを、もう片方が本文に反映する設計だと後から気づいた場合です。この時点では、触っているファイルそのものは重なっていません。それでも直列に戻します。

サインを見つけたときに惜しむべきは、ここまで進めた作業ではありません。気づかずに進めた場合に消える作業のほうです。

04並行か直列かは、複数セッションで動くAIエージェントの作業のどの軸を見て決めるんですか？

3つの条件と2つのサインを、実務で使える4つの軸に整理し直します。行が判断軸、列が並行・直列それぞれの状態です。

「対象が重なる」は、同じファイルだけを指すわけではありません。同じディレクトリの別ファイルでも、片方が生成する一覧やインデックスを両方が更新するなら、実質的には重なっています。ファイル名の一致ではなく、最終的に書き換わる場所で判定します。

依存関係も、コードの参照だけを指すわけではありません。片方の結論を読んでからでないと、もう片方の書き出し方が決まらないなら、それも依存です。

05複数セッションを並行させるとき、人間ゲートとの近さと状態の共有はAIエージェントにどう効くんですか？

人間ゲートとの近さは、操作の種類ではなく距離で測ります。同じ送信操作でも、下書きを作っている段階と、送信ボタンを押す直前とでは、割り込みの緊急度が違います。

ここで、OSの世界にあるadvisory lock（勧告的ロック）という考え方が参考になります（出典: Linuxマニュアル flock(2)）。ロックを確認し合うプロセス同士でだけ、同時書き込みを避けられる仕組みです。確認しないプロセスの書き込みまでは止めません。Claude Codeの複数セッションは、既定ではこの確認の仕組みを使っておらず、重なりを防いではくれません。

4つの軸のうち、実務で見落としやすいのは「状態の共有」です。対象が重ならず、依存もなくても、互いの進み具合が見えなければ、あとから重なりに気づけません。

台帳を見れば分かる、という状態にも注意が要ります。読んだ時点の情報が古ければ、判断はその分だけ遅れます。共有していれば安全だと考えず、いつ書き、いつ読み直すかというタイミングまで決めておきます。

読み方はシンプルです。4つの軸がすべて左側なら並行、1つでも右側に振れたら直列にします。

06複数セッションが同じファイルへ書き込んだ事故は、AI導入の現場で何が欠けていたんですか？

複数セッションが実際に衝突した例が、WEBMARKS社内にあります。2026-07-24、複数のAIエージェントが同じ記事ファイルへ同時に書き込み、内容が上書きされました。経緯と再発防止策はAIエージェント並列実行の競合｜上書き事故を止める3点で公開しています。

この事故で欠けていたのは、前の章で見た「状態の共有」でした。どちらの処理も、相手が同じ範囲を触っていることを知る手段を持たないまま動いていました。

注目したいのは、欠けていたのが技術的な仕組みではなく、名乗りだったことです。宣言があれば、後から動いた側が同じファイルを避けられました。片方が書いた1行を、もう片方が読める場所に置くだけで防げた種類の事故です。

規模が大きくなるほど、この差は開きます。姉妹誌のAIO Journalは、公開URLを251本運営しています（2026-07-28 sitemap.xml実測）。本数が増えるメディアほど、執筆・検証・図解制作が同時に走る場面が増え、並行と直列の切り分けを個人の勘に任せられなくなります。

07自動で起動する処理まで数えると、Claude Codeの外でもAIエージェントの並行は起きるんですか？

同じリスクは、人が手で開くセッションだけの話ではありません。定時に起動する常駐処理も、人が意識しないまま並行実行の判断を必要とします。

WEBMARKSはlaunchdジョブをplist 8本定義しており、実際にロードされているのは1本です（2026-07-28 launchctl実測）。

この差は、そのまま「これから並行の判断が必要になる余地」です。ロードする本数が増えるほど、対象の重なりを事前に確認する必要も増えます。

手で開くセッションと違い、常駐処理は起動の瞬間に人が見ていません。重なりに気づく相手がいないぶん、書き込み先を先に宣言しておく価値は、むしろ大きくなります。

08Claude Codeで複数セッションを事故なく回す手順は、AIエージェントに何をさせる順ですか？

実務では、次の5段階を回すだけで、並行と直列の判断を都度考えなくて済みます。

1. 着手前に、それぞれのセッションが触る範囲（ファイル・ディレクトリ）を1行で書き出す
2. 範囲が重なったら、片方を止めるか、重ならない単位まで粒度を小さく割る
3. 作業状態を一時ファイルや台帳に書き、もう片方のセッションから読める場所に置く
4. 人間ゲートに近づいたセッションを優先し、遠いほうを一時停止する
5. 完了したら状態を更新し、次に開くセッションが今どこまで進んでいるかを確認できるようにする

1の宣言は着手宣言と呼びます。書いてから始めるだけで、あとから重なりに気づくコストを避けられます。形式は自由で、次のように短い1行で十分です。

# 例: 着手前に書く範囲の宣言(ファイル名は自由)
対象: 02_記事/AGIM-023*.md のみ
除外: 04_図解/ 配下には触れない
開始: 2026-08-03 10:00

セッションが3つ以上になっても、考え方は変わりません。ペアごとに3つの条件を確認し、1組でも条件を欠けば、その2つだけを直列にします。関係のない他のセッションまで一律に止める必要はありません。

4の「人間ゲートの手前で止める」は、Claude CodeのPreToolUseフックで実装できます（出典: Claude Code公式ドキュメント「Hooks」）。フックは対象の操作だけをaskやdenyで止め、それ以外は通常どおり自動で流します。

3の「状態を書く」は、単独のセッションでも指示がぶれないように作業状態をファイルへ逃がす運用と、同じ考え方です。詳しくはClaude Codeのコンテキスト管理｜指示がぶれない3つの手で扱っています。

ファイルの分離をさらに強く仕組み化したい場合は、作業ディレクトリ自体を分けるgit worktreeという方法もあります。詳しくはGit公式ドキュメント「git-worktree」にまとまっています。本記事は判断基準に絞るため、設定手順はここでは扱いません。

09複数セッションの宣言の粒度は、AI活用の単位としてどこで区切るのがいいんですか？

高梨課長

高梨課長の発言

範囲を書き出すのは分かりました。ただ、どこまで細かく書けばよいのか、そこで手が止まりそうです。

鈴木さん

鈴木さんの発言

広すぎても狭すぎても効きません。私は「これができたら1つ終わり」と言える単位で切っています。記事なら1本、図解なら1セットですね。

粒度の決め方にはコツがあります。ディレクトリ単位まで広げすぎると、範囲が重なる判定が頻発し、ほとんどの組み合わせが直列に倒れます。逆に1行単位まで細かく割ると、宣言を書く手間のほうが大きくなります。

ちょうどよいのは、成果物の単位です。記事1本、図解1セットのように、完成したかどうかを一言で言える塊で区切ると扱いやすくなります。

この粒度には、もう1つ利点があります。成果物の単位は、人間ゲートの単位ともほぼ一致します。公開するか、送るかを判断する対象は、たいてい成果物ごとだからです。範囲の宣言と、止める場所の宣言が、同じ言葉で書けるようになります。

10Claude Codeの複数セッションで、AIエージェントの何を見落とすと事故になるんですか？

高梨課長

高梨課長の発言

条件も軸も分かったのですが、それでも事故る人はいますよね。どこで踏み外すんでしょうか。

鈴木さん

鈴木さんの発言

たいてい、宣言そのものではなく書き方の粗さです。「このフォルダは触らない」と書いた人が、その下のログには書き込んでいた、という形で残ります。

つまずくのは、たいてい粒度の粗さです。ディレクトリ単位で「触らない」と決めても、片方がその配下のログファイルにだけ書き込んでいれば、重なりは残ります。

記事本文と図解のキャプションファイルを別物として扱い、見落とすケースもあります。公開ビルドは本文とcaptions.jsonの両方を読みに行くため、片方だけを見て「重ならない」と判断すると足元をすくわれます。

粒度をそろえたつもりでも、片方のセッションが履歴ファイルやログへ想定外に書き込むことがあります。触ってよい範囲だけでなく、触ってはいけない範囲も明示しておくと、この見落としは減らせます。

似た症状でも、原因が別のことがあります。ファイルの更新時刻を手がかりに担当を推定して、かえって誤る事故はAI運用の障害の原因切り分け｜証跡で追う4段の順序で扱っています。ここで扱う衝突の原因は更新時刻ではなく、書き込み範囲の重なりです。両者を混同すると、対策の向きを間違えます。

Anthropicも、エージェントを動かす設計では想定外の操作に備えた保護策が要ると述べています（出典: Anthropic公式「Building effective agents」）。セッションを重ねるほど、想定外の重なりに備える保護策の重みは増します。

見落としは、次のような形で表に出ます。

3つに共通するのは、症状が出た時点では原因が見えないことです。だから、原因を探すより先に、範囲の宣言があったかどうかを確かめます。

11複数セッションを開く前に、AI導入の現場では何を確認しておくんですか？

次の7項目を、セッションを開く前に確認します。1つでも「いいえ」があれば、開く前に潰しておきます。

• 開こうとしている複数のセッションが、同じファイル・ディレクトリに触れないか確認したか
• 片方の出力を、もう片方が読み込む依存関係がないか確認したか
• どちらかが送信・公開・削除の直前まで進んでいないか確認したか
• 作業範囲を、台帳やメモなど互いに見える場所へ書き出したか
• 重なりに気づいたときの見分け方（保存内容の食い違い等）を決めているか
• 重なりが見つかったとき、どちらを優先し、どちらを止めるかの基準があるか
• 完了後に状態を更新し、次に開くセッションが参照できる状態にしたか

上の4つは開く前に決めることで、下の3つは走らせたあとに効くものです。前半だけを整えて後半を飛ばすと、気づいたときに止め方が決まっていない、という状態になります。

12よくある質問

13まとめ｜今日やる3つのこと

並行の可否は、開いた本数ではなく組み合わせで決まりました。判断の軸は4つあり、人間ゲートに近い側が最優先でした。そして、事故を止めたのは高度な仕組みではなく、先に名乗る1行でした。