結論：2026年8月13日公開のClaude Code v2.1.232で、subagentの「フォーク」実行（subagent_type: "fork"）がインタラクティブセッションの既定動作になりました。同時に、@メンションで他のセッションを名指しして直接メッセージを送るクロスセッションメッセージングの入力補助も追加され、GitLabのシークレットredaction・clone対応も収録されています。
関連: Claude Code v2.1.238｜プラグイン配布のheadersHelper認証
- フォークが既定オンに：Claudeが立ち上げるsubagent（フォーク・名前付きsubagent問わず）はバックグラウンド実行が標準になり、
CLAUDE_CODE_FORK_SUBAGENT環境変数で挙動を上書きできる - セッション間メッセージングの入力補助：
@を打つと生きている他セッションがタイプアヘッド候補に出て、SendMessageツールで直接名指しできるようになった（v2.1.232以降） - GitLab対応の拡大：
glpat-等のトークンredaction、baregitlab.comURLのclone対応が入り、GitHubとほぼ同等に扱えるようになった
対象読者：複数のターミナル・複数のworktreeでClaude Codeセッションを並行運用している開発者、チームリード、そしてGitLabをメインで使っているエンジニア。この記事では変更点の中身と、導入前に確認しておきたい設定・実装パターンまで解説します。
「別のターミナルで走らせてるあのセッション、さっき自分が入れたスキーマ変更の影響を受けてないか気になるけど、いちいち画面を切り替えて聞くのも面倒だな」——複数のworktreeやリポジトリでClaude Codeを並行運用している開発者なら、一度は感じたことのある地味な不便さのはずです。
2026年8月13日、Anthropicはこの不便さに直接手を入れるアップデートをリリースしました。公式チェンジログによると、Claude Code v2.1.232ではsubagentの「フォーク」実行がインタラクティブセッションの既定動作になり、@メンションで他のセッションを名指しして直接メッセージを送れる入力補助も追加されています。同じリリースにGitLabのシークレットredactionとbare URLのclone対応も入りました。
本記事では、公式チェンジログとcross-session messaging・subagentsの公式ドキュメントを一次ソースに、この変更が実務でどう効くのかを整理します。なお、直前のv2.1.228〜231で入った権限・安全まわりの変更は「Claude Code v2.1.229｜安全強化5つの変更点」で扱いました。今回はその同じ8月前半のリリース群のうち、複数セッション運用に効く2つの機能追加に絞って解説します。
2026年8月時点のスナップショット：直近リリースの位置づけ
まず時系列を整理します。公式チェンジログ（2026年8月14日時点で確認）によると、直近のリリースは以下の通りです。
| バージョン | リリース日 | 本記事に関わる主な変更 |
|---|---|---|
| v2.1.232 | 2026年8月13日 | subagentフォークの既定オン化、@メンションによるセッション指名、GitLabトークンredaction・clone対応、marketplaceエイリアス設定 |
| v2.1.231 | 2026年8月13日 | Slack等の事前登録型OAuthクライアントでのredirect URI不一致を修正 |
| v2.1.229 | 2026年8月12日 | Remote Controlの--continueドキュメント化、self-hosted runnerへのサーバー配信フック対応、gatewayのSSEキープアライブ |
| v2.1.224 | 2026年8月7日 | クロスセッションメッセージング機能そのものの追加（self-hosted環境の追加と同時） |
クロスセッションメッセージング自体はv2.1.224で追加された機能で、今回のv2.1.232はその使い勝手を上げる拡張という位置づけです。@メンションでの名指し指定、フォークの既定オン化、GitLab対応はいずれもv2.1.232が要件バージョンになります。
フォークとは何か：named subagentとの違い
Claude Codeのsubagentには大きく2種類あります。ひとつは.claude/agents/などに定義する「named subagent」（コードレビュー用、テスト実行用など役割ごとに定義するもの）、もうひとつが今回既定化された「フォーク」です。
公式ドキュメントの定義はこうです。
A fork is a subagent that inherits the entire conversation so far instead of starting fresh.
（フォークとは、新規に会話を始めるのではなく、それまでの会話全体を継承するsubagentのことである）
named subagentは毎回まっさらなコンテキストから始まり、Claudeが書いた委任プロンプトだけを受け取ります。一方フォークは、その時点までのシステムプロンプト・ツール定義・会話履歴をそのまま引き継ぐため、事情を説明し直す必要がありません。両者の違いを表にすると次のようになります。
| 比較項目 | フォーク | named subagent |
|---|---|---|
| コンテキスト | 会話全体を継承 | 渡されたプロンプトのみの新規コンテキスト |
| システムプロンプト・ツール | メインセッションと同一 | subagent定義ファイル由来（バックグラウンド実行時はさらに絞られる） |
| モデル | メインセッションと同一 | 定義ファイルのmodelフィールド |
| プロンプトキャッシュ | メインセッションと共有 | 別キャッシュ |
「テストコードのドラフトを別枠でお願いしたいけど、直前までの実装の流れは全部わかった上でやってほしい」というような、文脈を引き継ぎたい一回限りのサブタスクにはフォークが向いています。逆に「コードレビュー」「セキュリティチェック」のように毎回同じ手順で繰り返す定型作業は、named subagentとして定義しておく方が合理的です。named subagentを使った並列ワークフロー設計そのものは「階層subagent×動的ワークフローで大規模移行を並列分割する実装パターン」でも扱っているので、あわせて参照してください。
なぜフォークが既定オンになったのか
公式チェンジログの記述はこうなっています。
Subagent forking is now on by default: a subagent_type: “fork” subagent inherits the full conversation and prompt cache, and non-teammate agent spawns in interactive sessions now run in the background by default.
（subagentフォークは既定でオンになった：subagent_type: "fork"のsubagentは会話全体とプロンプトキャッシュを継承する。また、インタラクティブセッションにおけるteammate以外のagent起動は既定でバックグラウンド実行になった）
ポイントは2つです。ひとつはフォークが「システムプロンプトとツール定義がメインセッションと同一」であるため、初回リクエストがメインセッションのプロンプトキャッシュをそのまま再利用できること。named subagentを新しく起動するたびに発生していたキャッシュの立ち上がりコストが、フォークでは実質的に発生しません。もうひとつは、Claudeが起動するsubagent（フォーク・named subagent問わず）が既定でバックグラウンド実行になった点です。これにより、副タスクを投げてもメインの会話がブロックされにくくなっています。
この既定値はCLAUDE_CODE_FORK_SUBAGENT環境変数で制御できます。公式ドキュメントによる整理は以下の通りです。
| セッションの種類 | 既定値 | 上書き方法 |
|---|---|---|
| インタラクティブセッション | オン（v2.1.232以降） | CLAUDE_CODE_FORK_SUBAGENT=0でオフに |
非対話モード（-p）・Agent SDK |
オフ | CLAUDE_CODE_FORK_SUBAGENT=1でオンに |
v2.1.232より前のバージョンでは、インタラクティブセッションでもこの環境変数を明示的に1にしない限りフォークは使えませんでした。CIやSDK経由で動かしている非対話ワークロードでは、今回のアップデート後も既定はオフのままなので、挙動を変えたくない場合は特に何もする必要はありません。
実装パターン：/subtaskでフォークを手動起動する
フォークはClaudeが自律的にforkタイプのagentをリクエストして起動する場合と、開発者自身が明示的に起動する場合の両方があります。手動で起動するコマンドが/subtaskです。
/subtask draft unit tests for the parser changes so farこのコマンドを打つと、それまでの会話全体を継承したフォークがバックグラウンドで起動し、プロンプト入力欄の下にあるパネルに新しい行として表示されます。作業を止めずにメインセッションで実装を続けながら、フォーク側にテストのドラフト作成を任せる、という使い方です。パネルの操作は以下の通りです。
| キー | 動作 |
|---|---|
↑ / ↓ |
行の移動 |
Enter |
選択したフォークのトランスクリプトを開き、フォローアップを送る |
x |
完了したフォークを消す、または実行中のフォークを停止する |
Esc |
プロンプト入力へフォーカスを戻す |
フォークは自分でさらにフォークを起動することはできません（1段階のみ）。また、フォーク機能自体は使いたいがClaudeが自律的にフォークを立ち上げるのは避けたい、という場合はpermissions.denyにAgent(fork)ルールを追加すると、フォーク機能はオンのままClaudeからの自律起動だけをブロックできます。
@メンションでセッション間に直接メッセージを送る
今回のアップデートでもうひとつ実務に効くのが、クロスセッションメッセージングの入力補助です。クロスセッションメッセージング自体はv2.1.224で追加された機能で、ClaudeがListAgentsで到達可能なセッションを探し、SendMessageで名前を指定してメッセージを届ける仕組みです。v2.1.232では、この宛先を人間側が直接指定できる入力補助が加わりました。
Type @ in the prompt to mention another Claude session by name; Claude then uses SendMessage to reach that session directly.
（プロンプト内で@を入力すると他のClaudeセッションを名前でメンションできる。Claudeはそのメンションを使ってそのセッションへ直接メッセージを送る）
使い方はシンプルで、プロンプトの中でセッション名をメンションするだけです。
Let @api-worker know the schema migration finished@の後に文字を1つ以上打つと、生きている他セッションの名前がタイプアヘッド候補に出てきます。宛先を指定しない場合でも、Claudeは「このsendMessageで届けるべき相手は誰か」を会話の文脈から自律的に判断して送ることがあります。到達可能なセッションは/list-agentsコマンド（エイリアス/peers）で確認できます。
受信側の挙動はcrossSessionInbound設定で制御します。設定できる値は3つです。
| 設定値 | 挙動 |
|---|---|
accept |
届いたメッセージをそのままClaudeに配信する |
hold |
通知だけ出して配信を保留し、承認するまでClaudeには渡さない |
refuse |
配信せずにメッセージを破棄する |
この値を明示的に設定しない場合、公式ドキュメントによれば「送信側がbypassPermissionsのように権限プロンプトを省略するセッションかどうか」で既定挙動が変わります。権限プロンプトを都度確認するセッション同士なら基本的に配信され、bypassPermissions系のセッションが絡む場合は承認待ちで保留されます。設定ファイルで明示するなら次のようになります。
{
"crossSessionInbound": "accept",
"isolatePeerMachines": true
}isolatePeerMachinesをtrueにすると、同一マシン上のセッション間は従来通り即座に届く一方、別マシンやClaude Code on the webのセッションへメッセージを送る前には必ず承認が必要になります。社外に持ち出しているマシンや共有環境がある場合は検討する価値があります。
なお、クロスセッションメッセージングはmacOSとLinux（WSL 2含む）でのみ利用でき、ネイティブWindowsでは提供されていません。またAmazon Bedrock、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundry経由の接続では利用できない点も公式ドキュメントに明記されています。
実装パターン解説：並列worktree運用でのクロスセッションメッセージング活用
実装パターン解説（想定シナリオ）：以下は公式ドキュメントの仕様に基づいて構成した一般的な活用パターンです。特定の企業・案件の実測データではありません。
複数のworktreeで機能開発を並行させているチームを想定します。フロントエンド担当のセッション、バックエンドAPI担当のセッション、DBマイグレーション担当のセッションがそれぞれ別のターミナルでClaude Codeを動かしているケースです。
従来は「マイグレーションが終わったかどうか」を確認するために、担当者がSlackで聞くか、自分でマイグレーション担当のターミナルを確認しに行く必要がありました。クロスセッションメッセージングと@メンションを組み合わせると、この確認作業をセッション同士に任せられます。
# API担当のセッションで
Ask the session running the migration whether it finished, and once it's done,
tell it we're ready for the new tenant_id column
# 到達可能なセッションを確認したい場合
/list-agentsマイグレーション側のセッションが作業を終えたタイミングで、Claude自身がSendMessageを使って「スキーマ移行完了、tenant_idカラムを追加した」という趣旨のメッセージをAPI担当セッションへ送ります。受け取ったセッションはそのメッセージをコンテキストとして扱いますが、公式ドキュメントが明記している通り、届いたメッセージはそれだけで権限プロンプトへの承認にはならず、設定やCLAUDE.mdを変更する指示としても実行されません。あくまで「もう一人の自分」からの情報共有として扱われ、実際の権限チェックは受信側セッション自身のルールがそのまま適用されます。
この設計により、「セッションを跨いだ情報伝達は自動化するが、実行の可否は各セッションの権限設定に委ねる」という境界線がはっきりしているのが、他の自動化ツールとの違いです。バックグラウンドで動くセッション群の全体像を1画面で見たい場合は、Claude Codeバックグラウンドセッション完全ガイドのagent viewもあわせて使うと管理しやすくなります。
GitLab対応の拡大：シークレットredactionとclone対応
今回のリリースではGitLab関連の改善もまとまって入りました。公式チェンジログの該当箇所です。
Added secret redaction for GitLab token families (glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft-, glffct-) and full redaction of routable glpat-/gldt- tokens; the glab CLI config store gets the same sandbox and credential-path protection as gh.
（GitLabのトークンファミリー（glrt-、gloas-、glptt-、glagent-、glimt-、glsoat-、glcbt-、glft-、glffct-）のシークレットredactionを追加し、経路解決可能なglpat-／gldt-トークンは完全redactionの対象にした。glabCLIの設定ストアも、ghと同じサンドボックス・認証情報パス保護を受けるようになった）
GitHub向けにはすでに用意されていたトークンの自動マスキングと、認証情報ファイルへのサンドボックス保護が、GitLabのglab CLIにも同水準で拡張された形です。あわせて、bareのgitlab.comリポジトリURL（ネストしたサブグループ含む）がgithub.comと同じ感覚でcloneできるようになり、clone失敗時のヒントメッセージも実際のgitホストの名前を表示するよう改善されています。GitHubを前提にした社内ドキュメントやオンボーディング手順をGitLab向けに読み替えている場合、この差分は解消されたことになります。GitLabのCI/CDパイプラインへのClaude Code組み込み自体は、公式のGitLab CI/CD連携ドキュメントで別途解説されています。
【要注意】見落としやすい失敗パターンと回避策
失敗1：crossSessionInboundを未確認のまま「メッセージが届かない」と困る
❌ 設定を一切見ずに使い始め、片方のセッションだけbypassPermissionsで動かしていたためメッセージが延々と保留（hold）され続ける
⭕ 導入初日に/list-agentsと/statusのPeer address行で自分のセッションが到達可能な状態かを確認し、意図した挙動になるようcrossSessionInboundを明示的に設定しておく
なぜこれが重要か：既定の挙動は送信側・受信側の権限モードの組み合わせで自動的に決まるため、「なぜか届く」「なぜか保留される」が発生しやすい。明示設定しておけば挙動を予測できます。
失敗2：フォークとnamed subagentの権限差を混同する
❌ フォークは「軽量なsubagent」だと思い、機密情報を含む会話をそのままフォークして外部連携タスクに渡してしまう
⭕ フォークは会話履歴を丸ごと継承する（入力の分離がない）ことを踏まえ、機密情報を扱う会話をフォークする場合は渡す範囲を意識する。context分離が必要なタスクにはnamed subagentを使う
なぜこれが重要か：named subagentは委任プロンプトだけを受け取るのに対し、フォークはそれまでの会話全体を見ることができます。この違いを意識しないまま使い分けると、意図しない情報が想定外の範囲まで伝わる可能性があります。
失敗3：プラットフォーム制約を見落として「動かない」と困る
❌ クロスセッションメッセージングをネイティブWindows環境やBedrock経由の接続で使おうとして、機能自体が存在せず戸惑う
⭕ 事前に対応OS（macOS・Linux／WSL 2）とプロバイダー制約（Bedrock・Claude Platform on AWS・Google Cloud Agent Platform・Microsoft Foundryでは非対応）を確認しておく
なぜこれが重要か：企業のClaude Code運用は複数プロバイダーを併用しているケースも多く、環境によって使える機能が異なる点を事前共有しておかないと、チーム内で「動く人と動かない人」が発生します。
失敗4：v2.1.231のOAuth修正を知らずに古いバージョンのまま悩み続ける
❌ SlackなどのMCP連携でOAuthサインインが失敗し続け、原因がわからないまま古いバージョンを使い続ける
⭕ claude --versionでv2.1.231以降になっているか確認する。事前登録型OAuthクライアント（Slack等）のredirect URI不一致はv2.1.231で修正済み
なぜこれが重要か：MCP接続まわりの不具合はネットワークやアカウント設定の問題だと誤診しがちですが、今回のケースはクライアント側のバージョンに起因していました。まずバージョン確認から入るのが早道です。
導入前に確認しておきたいチェックリスト
# バージョン確認（v2.1.232以降か）
claude --version
# 到達可能なセッションの確認
/list-agents
# 現在のセッションのinbox状態を確認
/status
claude --versionでv2.1.232以降であることを確認する（それ未満ではフォーク既定化・@メンション入力補助は効かない）settings.jsonのcrossSessionInboundを意図した値（accept/hold/refuse）に明示しておく- 社外の複数マシンやリモート環境を運用している場合は
isolatePeerMachinesの要否を検討する - クロスセッションメッセージングを完全に止めたい場合は、
permissions.denyにSendMessage・ListAgentsを追加し、あわせてcrossSessionInboundをrefuseにする - GitLabチームは
glabの設定ストアが正しく保護されているか、bareのGitLab URLでcloneできるかを一度確認する
FAQ
Q1. フォークは今日から自動的に有効になりますか？
Claude Codeがv2.1.232以降に自動更新されたインタラクティブセッションでは、フォークは既定でオンです。無効化したい場合は環境変数CLAUDE_CODE_FORK_SUBAGENTを0に設定してください。非対話モード（-p）やAgent SDKでは既定オフのままなので、動作を変えたい場合は1を設定します。
Q2. crossSessionInboundを設定しないとどうなりますか？
公式ドキュメントによると、値を明示しない場合は送信側・受信側それぞれの権限モードから既定挙動が決まります。権限プロンプトを都度確認する通常のセッション同士では基本的に配信され、bypassPermissions系のセッションが絡む場合は承認待ちで保留されます。挙動を予測可能にしたい場合は明示設定を推奨します。
Q3. Windowsでも使えますか？
クロスセッションメッセージングはmacOSとLinux（WSL 2を含む）で利用できますが、ネイティブWindowsでは提供されていません。フォーク機能自体はOS制約の記載はありませんが、クロスセッションメッセージングと組み合わせて使う場合はこの制約を踏まえてください。
Q4. GitLabのセルフホストインスタンスにも対応しますか？
公式チェンジログの記載はbareのgitlab.com URLのclone対応とトークンredactionが中心で、セルフホストGitLabインスタンス固有の追加対応については2026年8月14日時点の公式チェンジログ本文からは確認できていません。セルフホスト環境で利用する場合は、公式ドキュメントで最新の対応状況を確認してください。
Q5. 既存の名前付きsubagent（named subagent）の挙動は変わりますか？
named subagentの定義方法・フロントマターの仕様自体に変更はありません。変わるのは「Claudeが起動するsubagentは既定でバックグラウンド実行になる」という実行モードの部分です。フォアグラウンドでの結果待ちが必要な場合は、Claudeがその場で前面実行を選ぶか、フロントマターのbackgroundフィールドで制御します。
Q6. v2.1.231のOAuth修正は具体的に何を直したのですか？
公式チェンジログによると、Slackのような「事前登録型のOAuthクライアント」を使うMCPサーバーで、redirect URIの不一致によりサインインが失敗する不具合が修正されました。該当する連携でサインインエラーが出ていた場合は、claude --versionでv2.1.231以降になっているか確認してください。
まとめ：「聞きに行く」から「Claudeが伝える」へ
今回のv2.1.232は、単体の機能追加としては地味に見えるかもしれません。しかし「並行して動く複数のClaude Codeセッションをどう連携させるか」という、複数worktree・複数リポジトリで開発するチームが日常的にぶつかる課題に、公式が正面から手を入れた回だと言えます。フォークの既定化でサブタスクの立ち上げコストが下がり、@メンションでセッション間の情報伝達を人間が仲介しなくてよくなる。権限チェックの境界線は各セッション側に残したまま、伝達の手間だけを削るという設計思想も一貫しています。
今日からできる3アクション：
claude --versionでv2.1.232以降であることを確認し、/list-agentsで到達可能なセッションを見てみるcrossSessionInboundを意図した値に明示し、複数マシン運用がある場合はisolatePeerMachinesの要否を検討する- GitLabを使っているチームは
glabの動作とbare URLでのcloneを一度確認する
次回は、同じ8月前半のリリース群に含まれるプラグインマーケットプレイスのadditionalMarketplaces／allowedMarketplacesエイリアス設定や、Enterprise向けのblockedMarketplacesポリシー拡張など、組織展開まわりのアップデートを整理する予定です。
Claude Codeの複数セッション運用・チーム導入を検討中の方へ
Uravationでは、Claude Codeの導入支援・個別指導を提供しています。フォーク・クロスセッションメッセージングを含む並列開発ワークフローの設計から、組織全体でのガバナンス設計まで、100社以上の支援実績に基づいて伴走します。「うちのチームでこの機能をどう使うべきか」といった個別相談からお気軽にどうぞ。
出典
- Claude Code changelog（公式・v2.1.224〜v2.1.232） — 2026年8月14日時点で確認
- Message your other Claude Code sessions（Claude Code公式ドキュメント）
- Create custom subagents（Claude Code公式ドキュメント）
- Claude Code GitLab CI/CD（Claude Code公式ドキュメント）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。
