投稿者 投稿日: カテゴリー AIニュース
AIエージェントを3体以上並列で動かすと、トークンだけ増えて品質は上がりません。
OpenAIでCodexを開発するEric Provencherが、2026年9月17日にX上でこう警告しました。エージェントを並べるほど互いの作業を検算し合い、トークンの消費だけが膨らむという指摘です。EC運営でも商品説明の生成や在庫・受注処理をAIに任せる動きが広がっていますが、「並列数を増やせば速くなる」という発想は運用コストを直撃します。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が、AIエージェントの並列設計とEC運用コストの論点を整理して解説します。
何が起きたか：Codex開発者が名付けた「協調税」
結論から言えば、並列サブエージェントが2体を超えると、ほぼ常にトークンを浪費して品質は改善しない、というのがProvencherの主張です。The Decoderが2026年9月17日に報じました。理由はシンプルで、エージェント同士が互いを信頼せず、他のエージェントの作業をもう一度確かめにいくからです。
Provencherはこの現象を「coordination tax（協調税）」と呼んでいます。並列の処理レーンを多数走らせたまま、暴走させず、過剰な検証にトークンを焼かせずに維持するのは極めて難しい、という説明です。
象徴的な事例として記事が挙げているのが、Pythonファイル1本のリファクタリングに1,393体のエージェントを投入し、トークン代に2万ドルを費やした試みです。これに対してProvencherは、1体のAstraエージェントであれば「ごく一部のコスト」で同じ仕事ができたとコメントしています。2万ドルは、仮に1ドル150円で換算すると約300万円規模です（為替レートは要確認）。エージェントを大量に並べれば時間は短縮できるかもしれないが、トークンのオーバーヘッドは「罠」だ、というのが彼の結論です。
コスト増の内訳も具体的です。サブエージェントを増やすとその数だけシステムプロンプトが積み上がり、入力トークンが膨らみます。さらにコンテキストが足りないサブエージェントは、他のエージェントがすでに実行したのと同じツール呼び出しを重ねます。Provencher自身も「重複作業が最大の要因だ」と認めており、OpenAIとしてもこの領域でより良い仕組みを出す必要があるとしています。
日本のEC事業者にとっての論点：並列数がそのまま運用コストになる
EC運営の現場に引き寄せると、この指摘は「AI導入の費用対効果が読めない」という悩みに直結します。商品登録、レビュー要約、在庫アラート、問い合わせ一次対応といった業務ごとにエージェントを立て、同時に走らせる設計は直感的です。しかし今回の指摘が正しければ、3体目以降に増やした分は速度以外の見返りが乏しく、トークン費用だけが線形に増えていきます。AIの本番移行が思うように進まない背景にも、こうした見積もりの甘さがあります（AIの本番移行は23%止まり）。
特に効きやすいのが、複数モールをまたぐ自動化です。楽天市場のRMS、Amazonのセラーセントラル、Shopifyの管理画面をそれぞれ別のサブエージェントに担当させると、店舗共通の運用ルール、つまり禁止ワード、送料と同梱の条件、薬機法や景表法で使えない表現といった前提を、エージェントの数だけシステムプロンプトとして配ることになります。ルールが長いほど、担当者を増やすたびに固定費が乗る構造です。
もうひとつは検算の重複です。人手の運用では「誰かが確認したならもう一度は見ない」という前提が働きますが、エージェント同士にはその前提がありません。商品データの整合チェックを2体に任せれば、同じ商品マスタを2回読みにいくのが普通に起こります。多数のエージェントを走らせたときの統制の難しさは、以前取り上げた100体規模のエージェントが不正な近道を選んだ検証とも通じる話です。
明日からの初動：並列は2本まで、通知型に切り替え、単価を測る
第一に、並列の上限をルール化することです。今回の指摘に従うなら、同時に走らせるサブエージェントは2体までを基本線とし、3体以上にするのは「明らかに独立していて、互いの結果を参照しない作業」に限る、と決めておくのが現実的です。商品説明の生成とレビュー分析は独立ですが、価格改定と在庫連動は独立ではありません。
第二に、Provencherが挙げた通知型の設計に寄せることです。メインのエージェントがサブの進捗を絶えず確認しにいく（ポーリングする）のをやめ、完了したときだけ通知を受け取る形にすると、確認のたびに消えていた往復分のトークンが減ります。実装としては、別スレッドに投げて終了時にだけ結果を戻す構成が近いです。
第三に、共通ルールをプロンプトに埋め込まず、外部のドキュメントとして持たせ、必要なときだけ参照させることです。禁止ワード一覧や送料表をシステムプロンプトに全文貼り付けている運用は、サブエージェントが増えた瞬間にコストが倍々になります。キャッシュの活用でAPI費用を下げた事例はClaude APIのコストを73%削減した回で触れています。
第四に、月次でトークン単価と処理件数を実測することです。1件あたりのトークン数と単価、月間処理件数を並べれば、どの業務が黒字でどこが赤字かは1枚の表にできます。最新モデルの運用コスト観点はGPT-6 Astraの活用と運用コストにまとめています。
まとめ
AIエージェントは「数を増やせば強くなる」道具ではありません。2体を超えると検証の重複でトークンだけが増える、という現場の警告は、EC運営のAI導入でも同じように効きます。並列数の上限を先に決め、共通ルールを外出しし、完了通知型に寄せる。そのうえで1件あたりのコストを測る。この順番で設計すれば、エージェント化は費用対効果の読める投資になります。
参考文献
- The Decoder｜AI agent swarms are a massive waste of tokens with zero quality gain, says OpenAI Codex developer
- Eric Provencher（X）｜並列サブエージェントとトークン消費についての投稿
- Eric Provencher（X）｜coordination tax についての投稿
- Nous Research｜Refactoring Hermes with 1,393 agents
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Decoder
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
