投稿者 投稿日: カテゴリー Claude
/forkとは、いまの会話を複製して裏で走らせるClaude Codeのコマンドのことです。
2026年7月17日に配信されたClaude Code v2.1.212で、/forkの挙動が大きく変わりました。従来はセッション内にサブエージェントを起動するコマンドでしたが、この版からは会話全体を複製した独立のバックグラウンドセッションを作る仕組みに変わり、手元の作業を止めずに別タスクを裏で進められるようになっています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。楽天RMSの商品CSV加工、Amazonビジネスレポートの週次集計、在庫アラートの抽出、レビュー返信案の生成という4本の定型業務を、1台のターミナルから同時に走らせるところまで具体化します。バックグラウンドセッションに渡す指示文テンプレートは本文中に4本掲載しました。並列作業と聞くとエンジニア向けの話に聞こえますが、指示はすべて日本語の文章で書けるため、コードを書かない店舗運営者にも十分に扱える内容です。
/forkは2026年7月17日のv2.1.212で何が変わったのか
v2.1.212の変更点を一言でまとめると、/forkが「会話の複製を独立したバックグラウンドセッションとして走らせるコマンド」になったことです。Anthropic公式のClaude Code changelogには、/forkが会話を複製して新しいバックグラウンドセッションを作り、claude agentsで開く一覧に独立した1行として追加されること、そして従来の「セッション内サブエージェント起動」は新設の/subtaskコマンドに引き継がれたことが明記されています。元の会話はフォークの影響を受けず、そのまま続行できます。フォークで作られたセッションは、タイトル未設定なら投げたプロンプトの内容から自動で名前が付くため、一覧上でどの業務のセッションかを見分けやすくなりました。
同じv2.1.212では/resumeも強化されています。claude agentsのエージェントビュー上で/resumeと入力すると過去セッションの選択画面が開き、一覧から削除したセッションも含めて、選んだものをバックグラウンドセッションとして再開できる仕様になりました。加えて、2分を超えて実行が続くMCPツール呼び出しは自動でバックグラウンドに移り、セッションが固まらないようになっています（しきい値は環境変数CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整可能）。暴走防止として、1セッションあたりのサブエージェント起動数に既定200回の上限も設けられました。
この変更は単発ではなく、2026年7月の連続アップデートの到達点と読むのが正確です。7月1日のv2.1.198でサブエージェントが既定でバックグラウンド実行になり、完了や入力待ちを通知フック（agent_needs_input / agent_completed）で受け取れるようになりました。worktree（独立したgit作業コピー）内でコード作業を終えたバックグラウンドエージェントが、確認を待たずにコミット・プッシュ・ドラフトPR作成まで進める挙動も同じ版で入っています。7月14日のv2.1.208では、完了したバックグラウンドエージェントが/tasks一覧から即座に消えず、クリーンアップまで残る改善が入りました。裏で終わった作業をあとから確認しやすくなったという点で、地味ながら実務上の効きは大きい修正です。
EC事業者の視点で見ると、この3週間で「1本のターミナルから複数の作業を投げ、状態を一覧で監視し、終わったものを順に検収する」という運用の土台が一気に揃ったことになります。これまで並列作業といえばターミナルを複数枚開いてセッションを別々に起動する方法が主流でしたが、コンテキストの引き継ぎと監視が分断される欠点がありました。/forkは会話の文脈を丸ごと持ったまま分岐できるため、店舗固有のルールを一度読み込ませれば、その前提を共有した複数の作業を次々に切り出せます。
EC定型業務のどれが並列実行に向くのか
並列実行に向く業務の条件は3つです。互いの成果物を待たずに進められること、書き込み先のファイルが重ならないこと、人の判断を最後にまとめて挟めることの3点で、この条件を満たす定型業務なら安心して裏に流せます。逆に、価格改定の最終判断やクレーム対応の送信のような、途中で人の裁量が必要な業務は並列化の対象から外すのが定石です。
公式ドキュメントのRun agents in parallelでは、並列化の手段としてサブエージェント、エージェントビュー、エージェントチーム、動的ワークフローの4方式が整理されており、独立したタスクを渡して後から確認する使い方にはエージェントビュー（claude agentsで開く画面）が推奨されています。エージェントビューからディスパッチしたセッションは自動的に専用のworktreeへ隔離されるため、並列セッションが同じファイルを同時に書き換える事故を構造的に避けられます。同ドキュメントには、複数セッションの同時実行がトークン消費を掛け算で増やす点も注記されており、費用面の設計は後述のKPI章で扱います。
冒頭に挙げた4業務を具体化します。1本目は楽天RMSの商品CSV加工です。商品名は半角255文字（全角換算127文字）、キャッチコピーは半角174文字（全角換算87文字）という上限があり、数百行のCSVをこの制限に合わせて整えるのは典型的な「独立・大量・機械的」な作業に該当します。2本目はAmazonビジネスレポートの週次集計で、Seller Centralからダウンロードした売上・セッションのCSVをASIN単位でまとめ、前週比の異常値を洗い出す作業です。3本目は在庫データからのアラート抽出、4本目は未返信レビューへの返信案生成で、いずれも「出力はすべて下書きで、公開・送信は人が行う」という検収前提に置きやすい業務です。
楽天とAmazon以外の店舗でも考え方は同じです。Yahoo!ショッピングならストアクリエイターProからダウンロードした商品データの文字数チェック（商品名は75文字以内、キャッチコピーは60文字以内）、Shopifyや自社ECならブログ記事の下書きや商品説明のリライト案づくりが、同じ型で並列化できます。自店の業務を棚卸しする際は、1週間のルーティンを書き出し、「CSVやテキストを入力にして、ファイルを出力する作業」に丸を付けるところから始めてください。丸が付いた作業の多くは、そのままバックグラウンドセッションの候補になります。
直近の支援案件で観測したのは、金曜午前にこの4本をまとめて裏に流し、昼までに検収を終えて週次会議に持ち込むという回し方でした。RMSやSeller Centralの画面を目視確認しながら進めたい場合は、Claude Codeの内蔵ブラウザを組み合わせると、ダウンロード作業や画面確認まで含めて1つの環境で完結します。どの業務から着手するか迷うなら、失敗してもやり直しが利くCSV集計系から入るのが安全です。
実装手順：共通コンテキストを1回作り、/forkで4本に分岐させる
手順は4ステップです。この章の最後に、バックグラウンドセッションへ渡す指示文テンプレートを宣言どおり4本掲載します。
第1ステップは、作業ルールの文書化です。プロジェクトフォルダのCLAUDE.mdに、店舗固有のルールを書いておきます。使用ファイルのパス、禁止ワード（楽天の規約で禁止される最大級表現、薬機法に抵触しうる効能表現など）、出力先フォルダの命名規則あたりが最低限の中身です。バックグラウンドセッションは人が横で見ていない時間が長いため、口頭で補正する前提の曖昧な指示は事故につながります。ルールを書き切ってから走らせる順序が結果的に速い、というのが現場で繰り返し見るパターンです。
第2ステップは、メインセッションでの共通前提の読み込みです。claudeを起動し、今週の対象期間、対象ファイルの場所、検収の締切といった前提を会話で確認させます。ここで作った文脈が、この後のフォーク全部に引き継がれます。
第3ステップが分岐です。/forkを実行すると会話の複製が新しいバックグラウンドセッションとして起動するので、そこに個別業務の指示文（後述のテンプレート）を渡します。手元の会話はそのまま生きているため、元のセッションに戻って次の/forkを実行し、2本目、3本目と切り出していきます。会話の背景説明をゼロからやり直さずに済むのが、素のセッションを4枚立ち上げる方式との決定的な違いです。
第4ステップは監視と検収です。claude agentsでエージェントビューを開くと、各セッションの状態が1行ずつ並び、入力待ちのものは「Needs input」と表示されます。現在のセッション内の裏作業は/tasksで一覧でき、完了したものもクリーンアップまで一覧に残ります。成果物はすべて下書きファイルとして受け取り、人が確認してから公開・入稿に回します。
検収を短時間で終えるコツは、見る順番を固定することです。編集部で実際に運用しているプロンプトでは、差分レポートの「要確認」行、検算結果、自己申告メモの3点を先に確認し、問題がなければ本体の流し読みに移る順序にしています。1業務あたりの検収は5〜10分が目安で、4本でも30分強に収まります。v2.1.198以降は完了・入力待ちを通知フックで受け取れるため、監視のために画面へ張り付く必要はありません。裏で走らせている間は別の判断業務に時間を使い、通知が来たタイミングでまとめて検収する流れが定着すると、並列化の効果が最大になります。
1本目は商品CSVの加工です。文字数制限の検査と修正を一括で行い、変更点を差分レポートに残させます。
プロンプト1：楽天RMS商品CSVの一括加工（バックグラウンドセッション用）
data/rakuten/item_master.csv を読み込み、次のルールで全行を加工した item_master_edited.csv を data/rakuten/out/ に出力してください。
1. 商品名は半角255文字（全角換算127文字）以内。超過行は意味を保ったまま短縮する
2. 商品名の先頭30文字以内に {ターゲットKW} を1回だけ含める
3. キャッチコピーは半角174文字（全角換算87文字）以内。「最強」「No.1」「絶対」など楽天市場出店規約で禁止される最大級表現を削除する
4. 加工前後の差分を diff_report.md にまとめる（変更行番号・変更理由つき）
5. 元ファイルは上書きしない
判断に迷う行は加工せずスキップし、diff_report.md に「要確認」と記録してください。
2本目は週次集計です。検算をプロンプト側に組み込み、数値のずれを自己申告させるのがポイントです。
プロンプト2：Amazonビジネスレポートの週次集計（バックグラウンドセッション用）
data/amazon/business_report_{開始日}_{終了日}.csv を読み込み、週次サマリーを reports/amazon-weekly.md に出力してください。
1. 親ASIN単位でセッション数・ユニットセッション率・注文商品数を集計する
2. 前週レポート（reports/amazon-weekly-prev.md）と比較し、ユニットセッション率が1ポイント以上下がったASINを「要注意」として列挙する
3. 要注意ASINごとに、考えられる原因の仮説を2つずつ書く（在庫切れ・価格改定・カート取得率の変化などの観点）
4. 集計値の合計が元CSVと一致するか検算し、結果を末尾に明記する
3本目は在庫アラートです。予測値には目安である旨を必ず書かせ、断定を避けます。
プロンプト3：在庫アラートの抽出と共有文面の作成（バックグラウンドセッション用）
data/stock/zaiko_{日付}.csv を読み込み、在庫アラートを alerts/zaiko-alert.md に出力してください。
1. 在庫数が {しきい値} 個を下回るSKUを抽出する
2. 直近4週の平均販売数から在庫切れ予測日を概算し、7日以内に切れる見込みのSKUを最上部に置く
3. 発注担当がそのまま読める共有文面（200〜300字）を冒頭に付ける
4. 予測はあくまで概算の目安であることを文面に明記する
4本目はレビュー返信案です。画一化と薬機法リスクへの対策をプロンプト内に埋め込みます。
プロンプト4：未返信レビューへの返信案生成（バックグラウンドセッション用）
data/reviews/unreplied.csv（レビュー本文・評価・商品名）を読み込み、返信案を replies/draft_{日付}.md に出力してください。
1. 評価1〜2のレビューは謝罪と改善姿勢を先に、評価4〜5のレビューは感謝を先に書く
2. 全件で言い回しを変え、同じ書き出しを3件以上続けない
3. 健康食品・化粧品カテゴリでは効果効能の断定表現（「効く」「治る」「痩せる」など）を使わない
4. 各返信案の末尾に、修正した方がよい点があれば1行で自己申告するメモを付ける
5. これは下書きであり、公開前に必ず人が確認する前提で書く
よくある失敗と回避策
失敗パターンの1つ目は、複数セッションによる同一ファイルへの同時書き込みです。worktreeを使わずローカルの同じフォルダで4本を走らせ、うち2本が同じCSVを別々に書き換えて片方の変更が消えた、という相談を受けたことがあります。回避策は2段構えで、エージェントビュー経由のディスパッチでworktree隔離を効かせること、そして業務ごとに出力先フォルダを分けてプロンプトに明記することです。読み込みは共有、書き込みは分離という原則を守れば、この種の事故はほぼ防げます。
2つ目は、検収を挟まずに成果物を公開してしまうことです。レビュー返信案をそのまま全件投稿した結果、書き出しが似通った返信が並んで購入者に機械返信と受け取られたケースや、健康食品で効能を断定する一文が混ざりかけたケースが典型です。バックグラウンドセッションは長時間人が見ていないからこそ、出力は必ず下書き止まりにし、公開・送信の操作だけは人が握る設計にします。プロンプト側に「下書き前提」「自己申告メモ」を組み込むのは、この検収を短時間で終えるための仕掛けです。
3つ目は、並列数の出しすぎです。8本、10本と同時に流すと、トークン消費が跳ね上がるうえ、入力待ちのセッションが放置されて結局全体が遅くなります。5,000社支援の中で何度も再現したパターンとして、最初は3〜4本の併走に絞り、検収のリズムが安定してから本数を増やす進め方が結果的に総所要時間を短くします。エージェントビューの「Needs input」表示を1日数回確認する習慣とセットで運用するのが現実的です。
KPI設計と費用・工数の目安
工数のKPIは「1週間あたりの定型業務の所要時間」で測るのが分かりやすい設計です。手作業で合計2〜3時間かかっていた週次集計・在庫チェック・レビュー下書きの束が、並列実行と検収の運用に載ると確認込み30〜40分前後まで縮むのが、直近の支援先で観測した範囲の目安です（業務量と品質基準によって変わるため、あくまで参考値としてください）。時間だけでなく、返信案の修正率（人が手を入れた件数の割合）や、集計レポートの検算エラー件数を品質KPIとして併記すると、速くなったが粗くなった、という劣化を早期に検知できます。
効果の測定は、導入前の1週間で対象業務の所要時間を実測しておくことが出発点です。導入後は「フォークを流した時刻」と「検収完了の時刻」を記録し、拘束時間（人が実際に手を動かした時間）と経過時間を分けて集計します。並列実行の価値は経過時間の短縮よりも拘束時間の圧縮に出るため、この2つを混ぜて測ると効果を見誤ります。月次で修正率の推移も並べておくと、プロンプトを改善すべき業務がどれかが数字で特定できます。
費用面では、Claude CodeはClaude Proのサブスクリプション（月額20米ドル）以上、または API従量課金で利用できます。並列実行はセッション数に比例してトークン消費が増えるため、使用量上限のあるプランでは4本併走を毎日回すと上限に当たる可能性があります。まず週1回の運用から始めて消費量を実測し、足りなければ上位プランやAPI課金への切り替えを検討する順序が無難です。2026年7月時点の見込みとして、週1回・4本併走の定型業務運用であればPro帯でも回るケースが多い一方、日次運用や8本超の併走は上位プラン前提と考えておくのが安全です。
並列エージェント競争の中でEC事業者はどこを見るべきか
2026年7月時点で、並列エージェント機能は3社が正面からぶつかる領域になっています。OpenAIは7月9日にGPT-5.6ファミリー（Sol/Terra/Luna）を公開し、法人向けのChatGPT Workを押し出しました。Googleは7月17日にGemini 3.5 Flashと3.5 Proを公開しています。Anthropic側はフラッグシップのClaude Fable 5に加え、6月30日公開のClaude Sonnet 5、Opus 4.8、Haiku 4.5という構成で、Claude Codeの7月アップデート群はこの競争の中で「並列作業の管理画面」を磨いてきた動きと読めます。モデル単体の賢さ比較よりも、複数の作業を投げて監視して検収する一連の動線がどれだけ短いかが、実務での差になりつつあります。
ツール選定の観点はCodexとClaude CodeのEC業務比較で詳しく扱いましたが、/fork以降のClaude Codeの強みは、会話文脈を保ったまま分岐できる点と、worktree隔離・エージェントビュー・通知フックが標準で揃っている点に集約されます。ターミナルに抵抗がある場合は、デスクトップ環境で同系統の並列作業を扱う選択肢もあり、Claude Fable 5とCoworkの公式ガイド解説が参考になります。
今後の注目は2つあります。1つは実験段階のエージェントチーム機能で、共有タスクリストを持つ複数セッションをリーダーが統率する構成が安定すれば、「集計→異常検知→対策案作成」のような依存関係のある業務連鎖まで自動化の射程に入ります。もう1つはスケジュール実行との接続です。現状の/forkは人が起点になりますが、定期実行の仕組みと組み合わされば、月曜朝に4本の定型業務が終わった状態で1週間を始める運用が現実になります。EC運営の週次ルーティンを「人がやる仕事の一覧」ではなく「検収する成果物の一覧」として設計し直すことが、この流れに乗る準備になると考えています。
よくある質問
/forkを使うのに追加料金はかかりますか
いいえ、/fork自体に追加料金はありません。Claude Codeが利用できる環境（Claude Pro以上のサブスクリプションまたはAPI従量課金）に含まれる標準機能です。ただしバックグラウンドセッションを並列で走らせた分だけトークン消費は増えるため、プランの使用量上限には注意が必要です。
/forkと/subtaskはどう違いますか
/forkとは、会話を複製して独立のバックグラウンドセッションを作るコマンドのことです。一方の/subtaskは、v2.1.212より前の/forkが担っていたセッション内サブエージェントの起動を引き継いだコマンドです。手元の会話と切り離して長い作業を任せるなら/fork、いまの会話の中で結果を受け取りたいなら/subtaskが向きます。
走らせたバックグラウンドセッションはどこで確認できますか
claude agentsコマンドで開くエージェントビューで確認できます。セッションが1行ずつ並び、作業中か入力待ちかの状態が表示され、入力待ちのものは「Needs input」と示されます。現在のセッション内で裏に回した作業は/tasksで一覧でき、完了済みのものもクリーンアップまで一覧に残ります。
途中で止めたセッションを後から再開できますか
はい、再開できます。v2.1.212では、エージェントビューで/resumeと入力すると過去セッションの選択画面が開き、一覧から削除したセッションも含めて、選んだものをバックグラウンドセッションとして再開できます。中断をあまり恐れず、検収の都合に合わせて止めたり戻したりできる設計です。
並列実行で同じファイルを壊しませんか
適切に分離すれば壊しません。エージェントビューからディスパッチしたセッションは自動的に専用のworktree（独立したgit作業コピー）へ隔離されます。それに加えて、業務ごとに出力先フォルダを分け、元ファイルを上書きしない指示をプロンプトに明記しておけば、同時書き込みの事故は二重に防げます。
コードを書けない店舗担当者でも使えますか
はい、使えます。本文のテンプレートのとおり、指示はすべて日本語の文章で書けます。必要なのはプログラミングではなく、業務ルールを曖昧さなく文章化する作業です。最初はCSV集計のようにやり直しの利く業務から始め、検収の習慣を作ってから対象を広げる進め方が定石です。
まとめ
2026年7月のアップデートで、Claude Codeは「1つの会話を複製して分岐させ、複数の定型業務を裏で走らせ、一覧で監視して検収する」という一連の運用を標準機能だけで組める段階に入りました。EC運営との相性がよいのは、週次の定型業務が独立・大量・検収可能という並列化の3条件をもともと満たしているからです。楽天の商品CSV、Amazonの週次レポート、在庫アラート、レビュー返信案の4本から始めて、自店の週次ルーティンを検収型に組み替えてみてください。
参考文献
- Anthropic・Claude Code changelog（v2.1.212ほか）
- Anthropic・Run agents in parallel（Claude Code Docs）
- Anthropic・Create custom subagents（Claude Code Docs）
- anthropics/claude-code CHANGELOG.md（GitHub）
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
