Claude Codeで複数プロジェクトを並行して進めたくて、WSLでターミナルを3つ4つ開くことがある。ふと気になったのが「これ、コンテキストウィンドウってインスタンス間で分散するの？」ということ。もし100万トークンがアカウント単位の共有プールだったら、4セッション起動した時点で1セッションあたり25万トークンまで落ちる計算になる。それなら同時起動は2つに絞りたい。
調べた結果: コンテキストはインスタンスごとに独立した1Mトークンが割り当てられる。分散はしない。ただしレート制限はアカウント全体で共有されるので、同時セッション数が増えると制限到達が早まる。
コンテキストウィンドウは完全に独立
Claude Codeをターミナルで起動すると、それは完全に独立したセッションになる。Opus 4.6やSonnet 4.6なら、1セッションあたり最大100万トークンのコンテキストウィンドウが割り当てられる。
別のターミナルで2つ目のClaude Codeを起動しても、同じこと。それぞれが独自の1Mコンテキストを持つ。お互いの存在すら知らない。
具体的にはこういうことだ:
- 4セッション起動 = 4つの独立した1Mコンテキストウィンドウ
- 各セッションが独自のCLAUDE.md、プロジェクトファイル、会話履歴を読み込む
- Auto-Compactionも各セッション独立で発生する
- あるセッションで
/compactや/clearを実行しても、他のセッションには何も影響しない
パイのように分割されるのではなく、それぞれが丸ごと1枚のパイをもらえるイメージだ。
共有されるのはレート制限
ここが紛らわしいポイント。コンテキストは独立だけど、レート制限はアカウント全体で共有される。
ProやMaxの使用量プールは1つ。Claude Codeの全セッション、claude.aiのチャット、Coworkデスクトップエージェント — 全部が同じプールから消費する。Anthropicは5時間のローリングウィンドウと週間上限の2層構造でトラッキングしている。
複数インスタンスを同時に動かすとどうなるか:
- トークン消費が倍速で進む。 1セッションで1回のやり取りに5万トークン使うなら、3セッション同時で同じ時間に15万トークン分のレート制限を消費する
- スループット制限が重なる。 各セッションからのAPIコールが1分あたりのリクエスト上限にカウントされる。3セッション同時ならリクエストレートも3倍
- Opusが一番キツい。 OpusはSonnetやHaikuより遥かにスループット制限が厳しい。Opusの並列2セッションで簡単に同時リクエスト上限を超える
つまり4セッション同時なら、レート制限を4倍速で消費する。コンテキストの質は落ちないが、使える時間が短くなる。
Pro vs Max：プラン別の並列セッション実力
複数インスタンスを動かすなら、プランの違いがモロに効いてくる。
| Pro（$20/月） | Max 5x（$100/月） | Max 20x（$200/月） | |
|---|---|---|---|
| 使用量倍率 | 1x | 5x | 20x |
| Opus並列数（実用） | 1 | 2〜3 | 4〜5+ |
| Sonnet並列数（実用） | 2〜3 | 5〜8 | 10+ |
| レート制限リセット | 5時間ローリング | 5時間ローリング | 5時間ローリング |
Proで2つのOpusセッションを並列に走らせると、数分でレート制限に到達する。Max 5xなら2〜3セッションまでは余裕がある。
複数起動を上手く回すコツ
コンテキストは独立、レート制限は共有。この前提で、複数セッションを実用的に回すパターンをいくつか紹介する。
コツ1: モデルを使い分ける
全部Opusで動かすのは贅沢すぎる。複雑な設計作業のセッションだけOpusにして、残りはSonnetかHaikuにする。モデルの指定はセッション単位でもグローバルでも可能だ。
# ターミナル1: 複雑なリファクタリング → Opus
claude --model opus
# ターミナル2: テスト作成 → Sonnetで十分
claude --model sonnet
# ターミナル3: lint修正 → Haikuでいい
claude --model haiku
Opusのスループットがボトルネックなので、これだけでレート制限の圧力が大きく下がる。
コツ2: 並列ではなくローテーション
4セッション同時進行より、集中的に切り替える方が実は速い:
- プロジェクトAのセッションで重いタスクを投げる
- Aが処理中に、プロジェクトBのセッションに切り替える
- Aの出力を確認して次のタスクを投げる
- Bの進捗を確認する
2セッションのローテーションの方が、4セッション同時進行よりスループット競合が少なくて生産的なことが多い。
コツ3: ステータスラインで消費量を監視
Claude Codeのステータスライン機能を使えば、各セッションの画面下部にモデル名・トークンコスト・コンテキスト使用率などをリアルタイム表示できる。カスタムスクリプトで自分好みの情報を出せるのが便利だ。
あるセッションのコストが急上昇しているのに気づいたら、重要度の低いセッションを一時停止してスロットリングを回避しよう。
コツ4: 重い作業と軽い作業を分ける
作業の負荷レベルでグループ分けする:
- 重いセッション （大量ファイル読み込み、コード生成、長いコンテキスト）: 同時1〜2セッションに限定
- 軽いセッション （簡単な質問、小さな修正）: 多少増やしても影響は小さい
Agent Teamsと手動複数起動の違い
Claude CodeのAgent Teamsは、リードセッションからサブエージェントを起動する機能だ。これもコンテキストは独立だが、連携の仕組みが組み込まれている。現時点では実験的機能で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定して有効化する必要がある。
ターミナルを手動で複数開くのとの違い:
| 手動で複数ターミナル | Agent Teams | |
|---|---|---|
| コンテキスト分離 | あり | あり |
| セッション間通信 | なし（手動コピペ） | メッセージング機能あり |
| タスク調整 | 手動 | 依存関係付きの共有タスクリスト |
| レート制限への影響 | 同一プール | 同一プール |
| セットアップの手間 | ゼロ | チーム設定が必要 |
完全に無関係なプロジェクトを並列に進めるなら、手動でターミナルを開く方がシンプル。同じコードベースで協調させたいなら、Agent Teamsの通信チャネルが活きる。
1個？2個？何セッションが最適か
プランと作業内容に応じた目安。
1セッション — Proプランの場合、または1つのプロジェクトに集中したいとき。レート制限の予算を丸ごと1セッションに使えるので、中断なくスムーズに作業できる。
2セッション — Max 5xユーザーのスイートスポット。メインプロジェクトをOpusで、サブタスクをSonnetで。レート制限にはほぼ引っかからず、並列の生産性向上が実感できる。
3〜4セッション — Max 20xでないと実用的でない。それでもOpusは最大1つに。セッション間の切り替えに使う時間の方が、並列化で節約できる時間を上回り始める。
5セッション以上 — Max 20xでも収穫逓減ゾーン。このレベルになると制約はClaude側ではなく、あなた自身がそれだけの会話を同時に管理する脳のキャパシティだ。
コンテキストウィンドウ超過エラーとレート制限の両方に悩んでいるなら、セッションを増やすのではなく、セッション管理を改善するのが正解だ。コンテキストウィンドウ超過の対処法、トークン消費を50%削減する方法、Claude Codeが指示を忘れる原因も合わせて読んでほしい。/compact や /clear の使いどころはClaude Codeコマンドチートシートで確認できる。その他のトラブル全般はClaude Codeトラブルシューティング完全ガイドをどうぞ。
FAQ
各インスタンスがフルの1Mトークンコンテキストを使える？
はい。各Claude Codeセッションは独立した1Mトークンのコンテキストウィンドウを持ちます（Opus 4.6、Sonnet 4.6の場合）。複数起動しても、個々のセッションのコンテキストが分割・削減されることはありません。
複数インスタンスでレート制限は共有される？
はい。同一アカウントの全Claude Codeセッション、claude.aiチャット、Coworkセッションが同じレート制限プールを共有します。3セッション同時だと、1セッションの3倍の速度でクォータを消費します。
2セッション起動すると各セッションが遅くなる？
直接的には遅くなりません。各セッションのコンテキスト処理速度には影響なし。ただし、両セッションのリクエストレートを合算してプランのスループット上限を超えると、両方のセッションでスロットリング（応答の遅延や一時的なエラー）が発生します。
VS Codeとターミナルで同時に使える？
はい。VS Code内のClaude Codeとターミナルのセッションは別インスタンスとして扱われ、コンテキストも独立です。ただしレート制限は同一プールから消費されます。
Opus 1セッションとSonnet 2セッション、どっちがいい？
タスク次第。複雑な設計判断や大規模リファクタリングにはOpus 1セッションが優秀。テスト作成とlint修正のような独立した並列タスクなら、Sonnet 2セッションの方が効率的です。Sonnetの方がスループット制限に余裕があるので。
Agent Teamsも同じレート制限？
はい。Agent Teamsの各チームメイトも内部的にはClaude Codeセッション。同一アカウントのトークンプールから消費します。Agent Teamsの利点はレート制限の分離ではなく、セッション間の連携です。
1つのセッションでレート制限に達したら他にも影響する？
はい。レート制限はアカウントレベルで適用されるので、1セッションで上限に達すると、他の全セッションもローリングウィンドウがリセットされるまでスロットリングされます。
/compactで他セッションのレート制限に余裕はできる？
いいえ。/compact はそのセッション内のコンテキストサイズを圧縮するもので、コンテキストウィンドウ超過エラーの防止に有効です。アカウント全体のレート制限消費量には影響しません — 元々送信したトークンは既にカウント済みです。
まとめ
覚えておくべきメンタルモデルはシンプルだ: コンテキストはセッション単位、レート制限はアカウント単位。
各Claude Codeインスタンスは完全に独立したプロセスで、それぞれ1Mトークンのコンテキストウィンドウを持つ。複数起動しても、個々のセッションの品質が薄まることはない。消費が速まるのはアカウントのレート制限の方だ。
多くの開発者にとって、Maxプランで2セッション同時がちょうどいいバランスだと思う。並列の恩恵を受けつつ、スロットリングを避けられる。Proなら1セッションに集中する方が結果的に生産的だ。
「何セッション起動できるか」より「何セッションを同時に的確に指示できるか」を考えた方がいい。僕の経験では、技術的な制約より先に人間のマルチタスク能力の限界が来る。