Claude Codeのマルチエージェントで商品ページ100件を並列処理する｜EC業務の分割設計とコスト試算

齋藤竹紘2026年8月5日2026年8月5日Claude

Claude Codeのマルチエージェントとは、並列で作業させる機能のことです。

並列にすれば速く終わる、と語られがちです。Anthropicの公式ブログはその逆を書いています。マルチエージェント構成をいつ使うかを扱った記事には「並列化の主たる便益はスピードではなく網羅性である」と明記され、同じ作業を単一エージェントでやる場合に比べてトークンを3〜10倍消費するとも書かれています。商品ページ100件のリライトをサブエージェント10体に割っても、10分の1の時間で終わるわけではありません。それでも分割する価値があるのは、100件を1つの会話に流し込むと70件目あたりで文体が崩れ、指示していた禁止ワードが混ざり始めるからです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、楽天RMSとAmazon Seller Centralの実画面を前提にした分割設計を、プロンプト5本と設定ファイル例3本つきで整理します。

「並列にすれば速い」が外れる3つの前提

マルチエージェントを入れるべきかは、速度ではなく3つの条件で決まります。Anthropicが公開している判断基準は、コンテキスト汚染・並列化・専門化の3点で、このどれにも当てはまらない作業は単一エージェントのままのほうが安く速い、という順序で書かれています。EC業務に置き換えると、商品ページ100件の改稿は3つとも当てはまる珍しいケースです。

1つ目のコンテキスト汚染は、前の作業で読み込んだ情報が次の作業の邪魔をする現象を指します。楽天RMSの商品登録画面からPC用商品説明（半角10,240文字まで）を10商品ぶん読み込ませると、それだけで数万トークンが会話に積み上がります。11商品目の改稿にとって、1商品目の旧原稿は不要な情報です。それが残り続けると、モデルの注意が薄まって出力が鈍る。サブエージェントは自分専用のまっさらなコンテキストで動き、終わったら最終メッセージとメタデータだけを親の会話に返すので、この積み上がりが起きません。

2つ目の並列化は、作業同士が本当に独立しているかどうかで決まります。商品Aの説明文を書くのに商品Bの説明文は要りません。ここは素直に分けられます。ただし公式ドキュメントが挙げる「分けてはいけない境界」も明快で、同じ作業の順次フェーズ（企画・実装・検証）、密結合したコンポーネント、共有状態を頻繁に同期する必要がある作業の3つは、分割するとかえって遅く高くつきます。カテゴリページの構造を決めながら個別商品を書く作業は、この禁止側に入ります。

3つ目の専門化は、道具と口調の分離です。楽天向けの原稿とAmazon向けの原稿では、守るべき文字数も禁止表現も違います。楽天市場の商品名は半角255文字（全角換算127文字）、キャッチコピーは半角174文字、スマートフォン用商品説明は半角2,560文字。Amazon.co.jpは商品名が半角200文字前後（カテゴリにより上限が異なる）、箇条書きは最大5項目、検索キーワードは250バイト。この2種類の制約を1体のエージェントに同時に持たせると、楽天の原稿にAmazonの箇条書き調が混ざる事故が起きます。現場で繰り返し見るのは、この「制約の混線」による差し戻しです。

分割の考え方として公式ドキュメントが推しているのは、作業の種類で切らず、必要なコンテキストで切るという原則です。企画担当エージェントと執筆担当エージェントに分けると、引き継ぎのたびに情報が劣化する伝言ゲームになる。同じ商品の調査と執筆は同じエージェントが持ち、商品群のほうを横に割る。この向きを間違えると、調整のトークンが実作業のトークンを上回ります。

商品ページ100件をどこで切るか

分割の単位は「1商品1エージェント」ではありません。2026年8月時点のClaude Codeのサブエージェント仕様では、1セッションで同時に走らせられるサブエージェントは既定で20体、セッション全体で生成できる総数は既定で200体です。前者は環境変数 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS、後者は CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION で変更できますが、100商品を100体に割ると同時実行の上限に当たって待ちが発生し、しかも100体ぶんの起動コンテキストを毎回作り直すことになります。

現実的な粒度は、1体あたり8〜12商品です。100商品なら10体前後。1体が処理する商品数を2桁前半に抑えると、そのサブエージェントの中でも文体のブレが出にくく、失敗したときに再実行する単位としても扱いやすい。食品ギフトのように商品間で表現が似ているジャンルなら1体15商品まで伸ばせますが、アパレルのようにサイズ表記や素材表記が商品ごとに違うジャンルでは1体8商品に落としたほうが差し戻しが減りました。

割り方の軸は、商品IDの連番ではなくカテゴリで切ります。楽天RMSの商品管理番号で1〜10、11〜20と機械的に割ると、1体のエージェントが化粧品とサプリと家電を同時に扱う状態になり、薬機法まわりの注意点が混ざります。カテゴリで割れば、そのエージェントに渡す注意事項も1種類で済む。専門化の便益を取りにいく割り方です。

サブエージェント同士が同じファイルを書き換える危険があるなら、frontmatter の isolation フィールドに worktree を指定します。指定するとそのサブエージェントは一時的なgit worktree、つまりリポジトリの独立したコピーの中で動き、変更がなければ自動で片付けられます。危ないのはCSVを直接書き換えるパイプラインで、この指定を省くと10体が同じ出力ファイルを奪い合って壊れる。うるチカラの運用でも、出力先を商品カテゴリごとの別ファイルに分けるところまでを分割設計の一部として扱っています。

出力の返し方も設計対象です。10体それぞれが改稿本文をまるごと親の会話に返すと、結局100件ぶんの本文が親のコンテキストに戻ってきて、分けた意味が消えます。サブエージェントには「書いたファイルのパスと、規約チェックで引っかかった箇所だけを3行以内で返す」と指示する。公式ドキュメントも、多数のサブエージェントが詳細な結果を返すとメインのコンテキストを圧迫すると警告しています。

共有ルールをどこに置くか

複数のエージェントに同じ規約を守らせるには、指示の置き場所を用途で分けます。Claude Codeのメモリ仕様によれば、CLAUDE.md はセッション開始時に読み込まれ、しかもサブエージェントの初期コンテキストにも階層すべてが渡ります。読み取り専用の組み込みエージェントである Explore と Plan だけは CLAUDE.md を読み飛ばす仕様なので、そこに依存した設計にはしない。

CLAUDE.md に入れるのは、毎回必要な事実です。楽天R-Mail本文に自社サイトやSNSの外部URLを置かない、商品ページに電話番号やQRコードを載せない、最上級表現を使わない。この3行は楽天市場の店舗運営規約に直結するため、どのサブエージェントにも常に効いていてほしい種類の指示です。公式ドキュメントは CLAUDE.md を200行以内に収めることを目標として挙げています。長くすると読まれ方が薄まるためで、EC規約の全文を貼るのは逆効果になります。

複数のAIツールを併用していて AGENTS.md をすでに持っている場合、Claude Code は AGENTS.md を直接は読みません。公式ドキュメントが案内している方法は、CLAUDE.md の先頭に @AGENTS.md と書いてインポートすること。インポートは最大4ホップまで再帰的にたどられます。この書き方の整理はAGENTS.mdの書き方とEC開発の共通ルールで詳しく扱っています。

特定のファイルにだけ効かせたい規約は .claude/rules/ に置き、frontmatter の paths でスコープを切ります。楽天用のCSVを触るときだけ楽天規約を読み込ませ、Shopify Admin のテーマファイルを触るときには読み込ませない。これでコンテキストの無駄が減ります。手順そのもの、たとえば「改稿してからCSV変換して検証する」という一連の流れは、rules ではなくスキルに切り出すのが公式の推奨です。スキルの作り方はClaude Agent Skillsの作り方とEC手順書化にまとめています。

サブエージェント自体の定義ファイルは .claude/agents/（プロジェクト単位）または ~/.claude/agents/（利用者単位）に置く Markdown で、frontmatter に name と description が必須、任意で tools、model、skills、memory、background、effort、isolation、color を指定できます。model には sonnet、opus、haiku、fable、あるいは claude-opus-5 のようなモデルIDが書け、既定は親から継承する inherit です。ここを明示的に書くかどうかが、次章のコストに直結します。

実装手順とプロンプト5本・設定ファイル例3本

ここからは実際に動かす順序で並べます。分割計画を作る、サブエージェントを定義する、並列で投げる、検証する、失敗ぶんを再実行する。この5段階です。

最初にやるのは、商品リストを見せて分割計画そのものを作らせることです。人間が勘で10分割するより、カテゴリ分布を見たうえで割ってもらったほうが専門化の効きがよくなります。

プロンプト1：商品100件の並列分割計画を作る

あなたはEC運営の業務設計担当です。
添付の商品リスト（商品管理番号・商品名・カテゴリ・現在の説明文文字数）を読み、
Claude Codeのサブエージェントで並列改稿するための分割計画を作成してください。

条件：
1. 1サブエージェントあたりの担当は8〜12商品に収める
2. 分割はカテゴリ単位で切る。連番での機械的分割は禁止
3. 同時実行は最大10体までに収める（残りは第2バッチに回す）
4. 各サブエージェントに渡す「そのカテゴリ固有の注意事項」を3行以内で添える
5. 薬機法・景表法の注意が必要なカテゴリには、その旨を注意事項の1行目に書く

出力フォーマット：
- バッチ番号／サブエージェント名／担当商品管理番号の一覧／注意事項3行
- 最後に、分割しないほうがよい商品があればその理由とともに列挙

分割計画ができたら、担当ごとのサブエージェント定義を作ります。定義ファイルは自分で書いてもよいのですが、frontmatter のフィールド名を間違えると起動時に落ちるため、Claude に書かせて中身を確認する手順が安全です。

プロンプト2：楽天向け商品説明リライターのサブエージェント定義を作る

プロジェクトの .claude/agents/ に、楽天市場の商品説明を改稿する
サブエージェント定義ファイルを作成してください。

要件：
1. name は rakuten-item-rewriter
2. description に「楽天RMSの商品説明を改稿する。並列バッチ処理で使う」と書く
3. tools は Read, Write, Edit, Grep, Glob のみ（Bash と Agent は与えない）
4. model は sonnet を明示指定する
5. isolation は worktree にする
6. 本文（システムプロンプト）に以下を必ず含める
   - 商品名は半角255文字以内、キャッチコピーは半角174文字以内
   - PC用商品説明は半角10,240文字以内、スマートフォン用商品説明は半角2,560文字以内
   - 楽天市場外のURL・電話番号・メールアドレス・QRコードを一切書かない
   - 最上級表現（最高・No.1・絶対・日本一）を使わない
   - 完了報告は「書き込んだファイルパス」と「規約チェックの警告」のみを3行以内で返す

作成後、ファイル全文を表示して確認させてください。

生成される定義ファイルは、次のような形になります。ここは公式ドキュメントの Quickstart と同じ構造です。

---
name: rakuten-item-rewriter
description: 楽天RMSの商品説明を改稿する。並列バッチ処理で使う
tools: Read, Write, Edit, Grep, Glob
model: sonnet
isolation: worktree
color: red
---

あなたは楽天市場の商品ページ改稿を担当する編集者です。

守る制約：
- 商品名は半角255文字以内、キャッチコピーは半角174文字以内
- PC用商品説明は半角10,240文字以内、スマートフォン用商品説明は半角2,560文字以内
- 楽天市場外のURL、電話番号、メールアドレス、QRコードは書かない
- 最上級表現（最高、No.1、絶対、日本一、業界最安）は使わない
- 薬機法に触れる効能表現（治る、効く、痩せる）は使わない

完了時は、書き込んだファイルパスと規約チェックの警告のみを3行以内で報告してください。
本文そのものは報告に含めないでください。

検証は別のサブエージェントに任せます。公式ドキュメントが「検証サブエージェント」を再現性の高いパターンとして挙げているのは、検証が本質的に前提情報をほとんど必要としないからです。書いた理由を知らなくても、文字数と禁止ワードは機械的に測れます。

---
name: ec-rule-verifier
description: 改稿済みの商品原稿が楽天とAmazonの制約に適合しているか検証する。書き換えはしない
tools: Read, Grep, Glob, Bash
model: haiku
---

あなたは検証専任の担当者です。原稿の書き換えは絶対に行いません。

指定されたディレクトリ内の全ファイルについて、以下を1件も飛ばさずに検査してください。
一部だけ確認して合格と報告することは禁止です。全件を検査してから報告してください。

検査項目：
1. 商品名の半角換算文字数が255を超えていないか
2. キャッチコピーの半角換算文字数が174を超えていないか
3. スマートフォン用商品説明の半角換算文字数が2,560を超えていないか
4. http:// または https:// で始まる文字列が含まれていないか
5. 最上級表現（最高、No.1、絶対、日本一、業界最安）が含まれていないか
6. 薬機法に触れる表現（治る、治療、効く、痩せる、即効）が含まれていないか

出力：ファイル名／違反項目番号／該当箇所の抜粋（20字以内）を1行ずつ。
違反ゼロの場合のみ「全件合格（検査件数：N件）」と報告してください。

並列で投げる指示は、意外なほど平易な日本語で通ります。エージェント名と担当範囲を指定するのが要点です。

プロンプト3：分割計画にもとづいて並列ディスパッチする

分割計画（batch-plan.md）を読み、第1バッチの10グループを
rakuten-item-rewriter サブエージェントで並列に処理してください。

指示：
1. 10体を同時に起動する。1体ずつ順番に処理しない
2. 各サブエージェントには、担当する商品管理番号の一覧と
   そのカテゴリ固有の注意事項3行だけを渡す
3. 出力先は output/{カテゴリ名}.csv に分ける。同じファイルに書かせない
4. 各サブエージェントの完了報告は3行以内に制限する
5. 全体が終わったら、完了数・失敗数・警告が出たファイル名だけを一覧にする

途中経過の本文は表示しないでください。

検証を挟んだあと、失敗ぶんだけを拾い直します。並列処理でいちばん厄介なのは、全部やり直すか個別に直すかの判断です。判断基準をプロンプト側に書いておくと、毎回同じ運用になります。

プロンプト4：検証結果から再実行対象を切り出す

ec-rule-verifier の検証レポート（verify-report.md）を読み、
再実行が必要な商品を切り出してください。

判定ルール：
1. 文字数超過のみ → 該当商品だけを個別に修正（サブエージェントは起動しない）
2. 外部URL混入・最上級表現・薬機法表現 → そのカテゴリを丸ごと再実行する
   （1件混ざったカテゴリは他の商品も汚染されている前提で扱う）
3. 同一カテゴリで2回連続失敗 → 再実行せず、原因を人間に報告して停止する

出力：
- 個別修正リスト（商品管理番号と修正内容）
- カテゴリ丸ごと再実行リスト（カテゴリ名と失敗理由）
- 人間の確認が必要な項目

最後に、実行のたびに設計が壊れないよう、上限値を settings.json に固定します。既定値のまま走らせて上限に当たると、その場でエージェントの生成が失敗して作業が中断します。

{
  "env": {
    "CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS": "10",
    "CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION": "300",
    "CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH": "2"
  }
}

ネスト深さを2に絞っているのは、サブエージェントがさらにサブエージェントを生む構造を浅く保つためです。公式の既定値は3層で、それより深くするとどこで失敗したのか追いにくくなります。EC業務の並列処理では、親が10体を呼び、その10体がそれぞれ検証役を1体呼ぶ、という2層で足ります。

プロンプト5：並列実行後の運用レポートを作る

本日の並列実行について、次回の設計改善に使うレポートを作成してください。

集計項目：
1. 起動したサブエージェント数と、うち失敗した数
2. カテゴリ別の規約違反件数（検証レポートから集計）
3. 1商品あたりの平均処理時間（開始時刻と終了時刻の差から概算）
4. 担当商品数と違反率の相関（8商品担当と12商品担当で差があるか）
5. 次回の分割粒度への提案（増やす／減らす／据え置き、と理由）

数値が取得できない項目は「計測なし」と明記し、推測で埋めないでください。

分割設計でつまずく3つのパターン

いちばん多いのは、検証サブエージェントの早すぎる合格宣言です。公式ドキュメントも「early victory problem」として名指ししている失敗で、検証役が数件だけ確認して合格と報告してしまう。回避策は指示文の書き方に尽きます。「ちゃんと確認して」ではなく「全件を検査してから報告する。一部だけの確認で合格と報告することは禁止」と書き、検査件数を報告に含めさせる。前掲の ec-rule-verifier 定義で検査件数の明記を求めているのは、この対策です。

2つ目は、規約違反の量産です。単発の改稿なら人間が目視で気づく楽天R-Mailの外部URL誘導も、10体が同時に100件書けば見落とします。楽天市場の店舗運営規約では、楽天R-Mail本文や商品ページから自社ECサイト・LINE公式・Instagram・X などの楽天市場外へ誘導することが禁じられています。生成AIは「回遊を増やすなら公式LINEへ誘導しましょう」と自然に提案してくるため、禁止事項をサブエージェントの本文とCLAUDE.mdの両方に書く。片方だけだと、コンテキストが長くなった局面で抜けます。編集部で実際に運用しているプロンプトでは、この禁止3行を定義ファイルの冒頭に固定しています。

3つ目は、コンテキストの取り戻しです。分割したのに、各サブエージェントが改稿本文を全文返してくると、親の会話に100件ぶんの本文が積み上がる。当初避けたかったコンテキスト汚染が、出力側から戻ってくる形です。返却する情報をパスと警告だけに絞る設計は、見落とされやすいわりに効果が大きい。楽天とAmazonの両方を回している店舗で観測されたのは、返却内容を3行に制限しただけで、親セッションの圧縮が発生する回数が目に見えて減ったことでした。

あわせて注意したいのが、同じ作業を順番に分けてしまう設計です。企画エージェント、執筆エージェント、校正エージェントと役割で割ると、引き継ぎのたびに前提が落ちます。公式ドキュメントはこれを伝言ゲームと表現し、実験では調整に使うトークンが実作業のトークンを上回ったと報告しています。役割ではなく商品群で割る。この原則を外すと、並列化の便益が丸ごと消えます。

コストの読み方とモデルの使い分け

費用の見積もりは、トークン単価と3〜10倍という係数の掛け算で考えます。2026年8月5日時点の公開価格では、Claude Opus 5 が入力100万トークンあたり5米ドル・出力25米ドル、高速処理のFast modeは入力10米ドル・出力50米ドル。Claude Sonnet 5 は2026年8月31日までの導入価格が入力2米ドル・出力10米ドルで、その後は入力3米ドル・出力15米ドルに移ります。出力単価だけを見ると、Opus 5 と導入価格中の Sonnet 5 では2.5倍の開きがあります。

商品ページ100件の改稿で、1商品あたり入力4,000トークン・出力2,500トークンを消費すると仮定します（この数値は商品説明の長さに強く依存するため、自社データで測り直すべき目安です）。100件なら入力40万・出力25万トークン。全部を Opus 5 で処理すると入力2.0米ドル・出力6.25米ドルで合計8.25米ドル。全部を導入価格の Sonnet 5 で処理すると入力0.8米ドル・出力2.5米ドルで合計3.3米ドル。ここにマルチエージェントの係数がかかります。3倍で見積もるなら、それぞれ24.75米ドルと9.9米ドル。1回の一括改稿としては小さい額ですが、月次で回すなら差は無視できません。

使い分けの目安は、判断が要る役に上位モデル、作業が定型の役に軽いモデル、です。分割計画を作る親のセッションと、規約違反の原因を推定する役は Opus 5。100件を機械的に書き換えるリライター役は Sonnet 5。検査項目が固定されている検証役は Haiku。frontmatter の model フィールドはこの割り当てを固定するためにあり、既定の inherit のままだと親が Opus 5 のとき全サブエージェントが Opus 5 で動きます。ここを詰める手順はClaude Codeのサブエージェントでモデル指定してコストを下げるに整理しました。Opus 5 の Fast mode を使うかどうかの線引きはClaude Opus 5のFast modeとEC業務の使い分けを、API単価そのものの下げ方はマルチモデル運用ルーティング設計とAPIコスト削減を参照してください。

コスト側でもう1つ効くのが、同じ指示を10体に配る構造そのものです。共通の規約テキストは、10体ぶん重複して入力トークンを食う。Anthropicはプロンプトキャッシュで最大90%、バッチ処理で50%の費用削減が可能と案内しており、規約テキストのように毎回同一の長い前提はキャッシュの対象として設計する価値があります。CLAUDE.md を200行以内に抑える推奨は、読ませ方の話であると同時に、10体に配ったときの総量の話でもあります。

工数の側は、削減幅より安定幅で見たほうが実態に合います。100件の改稿を人手でやると、1件15分として25時間。並列処理に置き換えると実行時間そのものは1時間前後まで縮みますが、分割計画の確認と検証レポートの確認に人が2〜3時間かかります。差し引きで8割強の削減という計算になるものの、初回は分割粒度の調整に半日ほど溶けるのが普通です。2回目以降の再現性を取りにいく施策だと考えるほうが、期待値のずれが起きません。

並列の単位は「サブエージェント」から動き始めている

2026年8月時点のClaude Codeの並列実行ドキュメントは、並列化の手段を4つに整理しています。1つの会話の中で作業を委譲するサブエージェント、複数のセッションを1画面で管理する agent view（claude agents で開く、リサーチプレビュー段階）、共有タスクリストとエージェント間メッセージを持つ agent teams（実験的機能で既定は無効）、そしてスクリプトが多数のサブエージェントを回して結果を突き合わせる dynamic workflows。この並びは、並列化の主導権が「Claudeの1ターンごとの判断」から「スクリプトが持つ計画」へ移りつつあることを示しています。

EC実務にとって意味が大きいのは、後ろの2つです。商品ページ100件の改稿は、いまはサブエージェント10体で足ります。ただし、楽天とAmazonとShopifyの3媒体を横断して500件を整合させる、といった規模になると、1ターンの判断で回すのは無理があります。公式ドキュメントは dynamic workflows の適用例として「500ファイルの移行」「コードベース全体の監査」を挙げていますが、これは商品マスタの一括整備とほぼ同じ形の作業です。

もう1つ、/batch というスキルが用意されています。1つの大きな変更を5〜30個のworktree分離されたサブエージェントに割り、それぞれがプルリクエストを1本開く、という定型処理です。開発向けの機能ですが、商品マスタをGit管理しているチームなら、カテゴリ単位の改稿をレビュー単位に落とす仕組みとしてそのまま使えます。レビューの単位が「100件まとめて」から「カテゴリごとに1本」に変わるだけで、差し戻しの粒度が現実的になります。

競合の解説記事が触れていないのは、並列化の設計が「AIの使い方」ではなく「業務の切り方」の問題だという点です。商品ページ改稿を10体に割れるのは、Claude Codeが優秀だからではなく、商品同士が独立しているからです。逆に、在庫棚卸しのように全SKUの数字が相互に影響する作業は、何体用意しても並列化できません。広告レポートの集計は、媒体ごとに独立しているので割れますが、媒体横断の予算配分判断は割れません。レビュー返信は1件ずつ独立しているので割れますが、同じ不具合への返信をそろえたいなら共有状態が要るので割れません。この見極めを先にやらないまま体数だけ増やすと、トークンが3〜10倍かかるだけで品質は上がらない、という結果になります。

もう一段先を見ると、サブエージェントに永続メモリを持たせる memory フィールドが用意されている点も見逃せません。カテゴリごとの改稿ルールをエージェント自身が学習し、次回の実行に持ち越す運用が公式に想定されています。2026年8月時点では、この機能をEC業務でどこまで信頼して回せるかの検証事例は多くありません。自社で試すなら、まず project スコープで学習内容をバージョン管理下に置き、何を覚えたかを人間が読める状態にしておくのが安全です。

よくある質問

Claude Codeのマルチエージェントは無料で使えますか

いいえ、Claude Codeの利用プランが必要です。サブエージェント機能そのものに追加料金はかかりませんが、複数のエージェントを同時に走らせるとトークン消費が単一エージェントの3〜10倍になるため、実質的なコストは上がります。Claude Sonnet 5 は Free と Pro の既定モデルで、Max・Team・Enterprise でも利用できます。API経由で回す場合は従量課金になります。

サブエージェントは何体まで同時に動かせますか

既定では1セッションあたり同時20体、セッション全体の累計で200体までです。環境変数 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS と CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION で変更できます。上限に達すると、その時点でエージェントの生成が失敗し、残りの作業を親が自分で処理するよう促されます。EC業務では10体前後に抑えたほうが、失敗時の切り分けが楽です。

商品ページ100件を1体に任せるのと10体に割るのでは、どちらが安いですか

1体に任せるほうが安く済みます。10体に割るとトークンが3〜10倍かかるため、費用だけを見れば分割は不利です。分割する理由は品質の安定で、1つの会話に100件を流し込むと後半で文体が崩れ、指示していた禁止表現が混ざり始めます。差し戻しの工数まで含めて比べるかどうかが判断の分かれ目です。

AGENTS.md をそのまま読ませることはできますか

いいえ、Claude Code が読むのは CLAUDE.md です。すでに AGENTS.md を運用している場合は、CLAUDE.md の中に @AGENTS.md と書いてインポートするのが公式に案内されている方法です。インポートは最大4ホップまで再帰的にたどられ、読み込まれた内容はセッション開始時にコンテキストへ展開されます。シンボリックリンクでも代替できますが、Windowsでは管理者権限が必要になります。

楽天の規約違反を並列処理で量産しないためには何をすればよいですか

禁止事項を CLAUDE.md とサブエージェント定義の両方に書き、さらに検証専任のサブエージェントで機械的に検査するのが現実的です。楽天市場では、楽天R-Mail本文や商品ページから楽天市場外のURL・電話番号・メールアドレス・QRコードへ誘導することが禁じられています。指示は守られないことがある前提で設計し、検査は文字列一致で確実に拾う。この二段構えにしておくと、10体が同時に書いても事故が表に出ません。

検証サブエージェントが「全部OK」と嘘をつくのを防げますか

指示文の書き方で大きく減らせます。「全件を検査してから報告する。一部だけの確認で合格と報告することは禁止」と明示し、報告に検査件数を含めさせるのが基本形です。Anthropicの公式ドキュメントも、検証エージェントが数件だけ確認して合格を宣言する失敗を最大の落とし穴として挙げ、具体的な判定基準を渡すこと、失敗するはずの入力も試させることを対策として示しています。

在庫棚卸しやレビュー返信も並列化できますか

作業の独立性しだいです。レビュー返信は1件ずつ独立しているので分割できますが、同じ不具合に対する返信内容をそろえたい場合は共有状態が必要になるため、分割すると整合が崩れます。在庫棚卸しは全SKUの数字が相互に影響するので、並列化には向きません。媒体別の広告レポート集計のように、対象が最初から分かれている作業から始めるのが安全です。

参考文献

著者：齋藤竹紘（株式会社オルセル編集長／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実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示