AIエージェントを1つに詰め込むか複数に分けるかは、今のエージェントに出ている症状で決めます。まず1つで組み、条件分岐が手に負えない、似た道具を取り違える、文脈が混ざる、独立した仕事を同時に回したい、のどれかが出たときだけ文脈ごとに分けます。夜間などに常駐させるなら、排他・冪等・上限回数の3点を先に決めます。
- 分けると調整の手間と利用料が増えます。症状が出るまでは1つのまま、指示と道具の説明を直します。
- 分ける線は「問い合わせ担当」「請求担当」のような仕事の種類ではなく、処理に要る情報が切れる所に引きます。
- 無人で回す処理は、定期実行が重複しうるという前提に立ち、作り始める前に止め方と重ね方の決まりを置きます。
目次
AIエージェントは、まず1つで組んで症状を待つ
AIエージェントは、最初から複数に分けず、1つで組んで症状が出るのを待つのが出発点です。OpenAI はエージェント構築の手引きで、まず1つのエージェントの能力を伸ばし切ることを一般的な推奨としています。Anthropic も、できるだけ単純な形から始め、必要なときだけ複雑にするよう勧めています。
分けると、調整と手渡しが新しく生まれる
エージェントを分けると、役どうしの調整と、情報の手渡しが新しく生まれます。Anthropic は、複数のエージェントが1つより安定して良い結果を出すのは限られた場合で、それ以外では調整の費用が利点を上回ることが多いとしています。
費用の目安として同社は、自社の試験で、複数のエージェントが同じ仕事に1つの場合の3〜10倍のトークンを使ったと書いています。これは同社が自社で比べた目安で、業界全体を調べた調査値ではありません。それでも、分けるほど利用料がかさむ方向であることは、上へ説明するときの材料になります。
1つのまま直せる所を先に探す
指示と道具を足して取り違えが増えたときも、すぐに分けるのではなく、1つのまま直せる所を先に探します。分けるかどうかは、次の節の4つの症状に当たるかで判断します。エージェントを形づくる部品と、そもそも自社で検討に値するかは、チャットボットとAIエージェントの部品の違いを整理した記事で扱っています。
分けるべきなのは、どんな症状が出たときか
1つのAIエージェントを分けるのは、条件分岐が増えて従わない、似た道具を取り違える、文脈が混ざる、独立した仕事を同時に回したい、のどれかのときです。どれにも当たらなければ、分けずに指示と道具の説明を直します。
この4症状は公的な基準ではありません。OpenAI が挙げる分ける目安と、Anthropic が挙げる複数が向く場合を、本記事が並べ直した整理です。
| 出ている症状 | 分けずに先に直すこと | 分ける目安 |
|---|---|---|
| 指示の条件分岐が増えて従わない | 指示を整理し、分岐を減らす | 整理しても分岐が手に負えない |
| 似た道具を取り違える | 道具の名前と説明を書き分ける | 書き分けても取り違えが続く |
| 無関係な情報で文脈が混ざる | 渡す情報を処理に要る分に絞る | 処理ごとに要る情報が別になる |
| 独立した仕事を同時に回したい | 順に回して待てるかを見る | 待てず、互いの結果を使わない |

条件分岐と道具の取り違えは、まず書き方を疑う
条件分岐の症状は、指示の中に「この場合はこう」という決まりが積み重なり、エージェントが一部を守らなくなる状態です。OpenAI は、こうした分岐が手に負えなくなった場合を、分ける目安の1つ目に挙げています。
道具の取り違えについて OpenAI は、道具の数よりも、道具どうしが似通い重なっていることを問題にしています。名前と説明から使い分けが読み取れるように直しても取り違えが続くなら、分ける段階です。
文脈の混ざりと同時に回したい仕事は、分けると効く
文脈の混ざりは、Anthropic が「文脈の汚れ」と呼ぶ状態で、ある処理には要らない情報が同じ会話に溜まり、判断がぶれます。独立した仕事を同時に回したい場合は、互いの結果を使わない仕事を待たせずに済みます。
Anthropic はこの2つに、専門化で道具選びが良くなる場合を加えた3つを、複数のエージェントが1つより安定して良い場合としています。3つ目は、表の2行目で書き分けても直らないときに当たります。
仮の例で表に当てはめる
ここからは仮の例です。問い合わせの一次振り分けと請求書の下書きを1つのエージェントに任せたところ、問い合わせに答える途中で請求書用の道具を呼ぶ取り違えが出た、という場面です。表では2行目に当たるため、まず道具の名前と説明を書き分け、それでも続くなら2つの処理を分けます。
分ける線は、仕事の種類ではなく必要な情報で引く
AIエージェントを分けるときの線は、問い合わせ担当・請求担当のような仕事の種類ではなく、その処理に要る情報(文脈)がどこで切れるかで引きます。仕事の種類で分けると、手渡しのたびに文脈が失われるからです。
Anthropic は2026年1月の記事で、仕事の種類ではなく、必要な文脈で仕事をまとめて分けるよう勧めています。同じ資料や会話を読み続ける処理を別の役に割ると、そのたびに情報を渡し直すことになり、渡し損ねた分が判断から抜けます。
境目は「前の処理を見ずに進められるか」で確かめる
線を引く場所は、「この処理は、前の処理が読んだ資料や会話を見なくても進められるか」という問いで確かめられます。見なくても進められるなら、そこが分けてよい境目です。前の会話の細部が要るなら、同じエージェントに残した方が取り違えを増やしません。
分けると、役ごとに道具と権限を絞れる
分けることには、役ごとに使える道具と権限を絞れるという利点もあります。Claude Code のサブエージェントは、それぞれが自分の文脈・指示・使える道具・権限を持って動く仕組みです。分けたエージェントごとに渡す権限の決め方は、こちらの記事で扱っています。
分けた作業役に渡す4つの項目
分けた作業役には、目的・出力の形式・使う道具と情報源・仕事の境界の4つを渡します。Anthropic は複数エージェントで調べ物をする仕組みを作った記録で、仕事の説明が細かくないと、作業の重複や抜けが出ると書いています。
4つのうち境界が抜けると、隣の役と同じ作業をしたり、誰も持たない作業が残ったりします。出力の形式が抜けると、受け取る側が中身を読み直す手間が増えます。
分けた後の受け渡しは、直列・並列・監督のどれにするか
分けたエージェントの受け渡しは、順番が決まった仕事なら直列、互いに独立した仕事なら並列、何に分けるかが入力ごとに変わる仕事なら監督の型が向きます。監督の型では、中央の役が仕事を割り振り、結果をまとめます。
3つの型は、Anthropic と OpenAI が挙げる型を受け渡しの面から並べ直したもので、公的な分類ではありません。直列は prompt chaining、並列は sectioning に当たります。監督は orchestrator-workers と OpenAI の manager 型に当たります。
| 受け渡しの型 | 向く仕事 | 手渡すもの |
|---|---|---|
| 直列 | 決まった段に分けられる仕事 | 前の段の出力を次の段へ |
| 並列 | 互いに独立し同時に回せる仕事 | 各役の担当範囲と、結果のまとめ先 |
| 監督 | 分け方が入力ごとに変わる仕事 | 目的・形式・道具・境界の4項目 |
振り分けと手渡しは、どの型に近いか
入力を分類して専門の後続へ回す振り分け(routing)は、割り振りだけを行う監督の簡単な形と見なせます。OpenAI の手引きにある手渡し(handoff)は、別のエージェントへ仕事を一方向に任せる形で、渡された側が続きを持ちます。前から後ろへ渡る点で、直列に近い型です。
OpenAI Agents SDK のドキュメントは、専門役を道具として呼ぶ使い方を示しています。専門役が範囲の決まった小さな仕事を手伝い、利用者とのやり取りを引き継がない場合の形です。問い合わせの窓口を1つに保ちたい処理には、この使い方が向きます。
順番を決められるなら、AIに決めさせない
同じドキュメントは、コードで順番を決める方が、LLMに順番を任せるより速さ・費用・性能の面で動きが決まるとしています。順番が毎回同じ仕事は直列にして、順番そのものはプログラムの側で固定しておくと、上にも動きを説明しやすくなります。
常駐させるなら、排他・冪等・上限回数の3点を先に決める
Google Cloud や Kubernetes の公式文書は、定期実行は重複しうるとして、処理を冪等(2回動いても結果が1回分)にするよう求めています。常駐させるエージェントは、排他・冪等・上限回数の3点を先に決めます。
Google Cloud Scheduler は、まれに1回の予定でジョブが複数回動くことがあるとしています。Cloud Tasks の説明でも、重複実行はゼロではないとされます。Kubernetes の CronJob は、ジョブが2回作られる場合があるため、ジョブは冪等であるべきとしています。
ここでいう二重実行は、同じ処理が2回動くことです。同じデータを手で2つのシステムに入れる二重入力とは別の話です。また3点は公的な基準ではなく、クラウド各社と決済の公式ドキュメントにある前提を、本記事が並べ直した整理です。
| 決めること | 防ぐこと | 開発担当に確かめる問い |
|---|---|---|
| 排他 | 前の回が終わる前に次の回が始まる | 前の回が残っていたら次はどうなるか |
| 冪等 | 同じ依頼を2回処理し結果が2回分 | 同じ依頼が2回届いたら何が起きるか |
| 上限回数 | 判断ループと再試行が止まらない | 何回で止め、誰に知らせるか |
排他は、前の回が終わるまで次を始めない決まり
排他は、前の回が終わっていないうちに次の回を始めない決まりです。Kubernetes の CronJob には、前の回が終わっていなければ新しい回を飛ばす Forbid という設定があります。夜間の処理が長引いた日に、次の回が同じ依頼へ手を付けるのを防ぐ考え方です。
冪等は、同じ依頼が2回届いても結果を1回分にすること
排他を置いても、再試行や重複した起動で同じ依頼が2回届く可能性は残ります。AWS Lambda は、再試行するなら同じイベントを複数回処理しても重複取引などが起きないよう求めています。Stripe の API には冪等キーという仕組みがあり、同じ操作を誤って2回行わずに再試行できます。
エージェントに当てはめると、依頼ごとに一意の目印を持たせ、処理済みの目印が来たら書き込みをしない作りになります。返信の下書きが2通できる、請求書の下書きが2枚できる、といった結果を防げます。
上限回数は、止める回数と人に戻す先を決めること
上限回数は、判断ループと再試行を何回で止めるかの決まりです。OpenAI は実行を終了条件まで回るループとし、終了条件の例に最大回数への到達を挙げています。Anthropic の記事でも、制御を保つため最大回数などの停止条件を置くのが一般的とされます。
OpenAI はさらに、再試行や動作の回数に上限を置いて超えたら人に引き継ぐこと、取り消せない動作は人の確認に回すことを挙げています。総務省と経済産業省のAI事業者ガイドライン別添も、AIエージェントが人の意図しない注文やファイル削除を行う可能性に触れています。
無人の時間帯に2回動くと取り返しがつかない操作は、3点を決めたうえで、最初から人の確認を挟む側に置きます。人に戻した後に誰がどの濃さで確認するかは、確認の担当を扱った記事にまとめています。
この記事のまとめ
- 直近に起きた取り違えを数件書き出し、判定表の4行のどれに当たるかを1件ずつ付けます。
- 分ける前と後で利用料を比べられるよう、今のエージェントの1か月分のトークン使用量を控えておきます。
- 夜間に回したい処理を1つ選び、確認表の3つの問いへの答えを開発担当と書き、上への説明資料に添えます。
公開日:2026年10月
読んで終わりにしないために
「自社の場合は、どうすれば?」
その答えを、最大45分で持ち帰る。
記事で分かるのは、一般論まで。AI導入を専門に見ている担当が、貴社の業務に当てはめて“次の一手”だけを一緒に整理します。
この相談で持ち帰れるもの
- 01
自社業務に当てはめたAI活用マップ
- 02
投資対効果(ROI)のシミュレーション
- 03
いまの悩み・疑問への、その場の個別回答


