先に要点
前回の コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 では、アプリ側のコードで agent の流れを決める設計を整理しました。 今回はその対になる、LLM主導のオーケストレーションです。
AI エージェントでは、LLM にツールや専門エージェントを渡し、状況に応じて「次に何を使うか」を判断させることがあります。 OpenAI Agents SDK の orchestration guide でも、instructions・tools・handoffs を備えた LLM が、open-ended なタスクに対して自律的に計画し、ツールや handoff を使う形として説明されています。
この記事では、2026年6月時点の OpenAI Agents SDK の公式情報をもとに、LLM主導のオーケストレーションとは何か、コード主導との違い、向く場面と落とし穴、そして「どこまでを LLM に任せ、どこからコードに落とすか」の境界の引き方を、ツール数やログの症状といった具体まで含めて整理します。
LLM主導のオーケストレーションとは何か
LLM主導のオーケストレーションとは、AIエージェントが与えられた instructions、tools、handoffs を見て、次に何をするかを LLM 自身に判断させる設計です。
たとえば、ユーザーが「競合サービスを調べて、改善案を出して」と依頼したとします。 LLM主導なら、エージェントは状況に応じて、
- web search を使って調べる
- file search で社内資料を見る
- code execution でデータを集計する
- report writer agent へ渡す
- specialist agent を tool として呼ぶ
のような判断を自分で組み立てます。
コード側が「必ずこの順番で実行する」と決めるのではなく、LLM がその場の文脈から手順を選ぶのが特徴です。内部的には、モデルがツールを呼ぶ→結果を受け取る→次の一手を決める、というループ（agent loop）を、最終回答にたどり着くまで繰り返します。このループの上限が後述の max_turns で、無限ループを防ぐ安全弁になります。
コード主導との違い
コード主導では、「分類結果がAならこのagent」「評価NGなら再試行」のように、アプリ側のコードが流れを決めます。 LLM主導では、エージェントに選択肢を渡し、どれを使うかを LLM が判断します。
| 観点 | LLM主導 | コード主導 |
|---|---|---|
| 流れの決め方 | LLMが文脈から判断する | コードの条件分岐で決める |
| 柔軟性 | 高い | 制御しやすい |
| 再現性 | ぶれやすい | 高めやすい |
| コストの読みやすさ | 呼び出し回数が変動し読みにくい | 呼び出し回数を固定でき読みやすい |
| 向く場面 | 開いた調査、壁打ち、複雑な判断 | 定型業務、承認フロー、明確な分岐 |
| 注意点 | 選択肢過多で誤選択・ループが増える | 分岐設計が硬くなりやすい |
どちらが上というより、「どこをAIに判断させ、どこをコードで固定するか」の設計問題です。公式の orchestration guide も両者を対立ではなく組み合わせとして扱い、決定性が欲しい部分はコードに落とすことを勧めています。
LLM主導でよく使われる2つの形
1. Agents as tools
OpenAI Agents SDK では、specialist agent を tool として manager agent に渡す形があります（agent as tool）。 この場合、中心の manager agent はユーザーとの会話を握り続けたまま、必要に応じて専門 agent を tool として呼びます。
たとえば、
- booking expert
- refund expert
- research expert
- code review expert
のような専門担当を tool として持たせ、必要になったら LLM が選びます。
この形は、最終回答を manager がまとめたいときに向いています。専門 agent は「呼ばれて結果を返す」だけで、会話の主導権は manager に残ります。
2. Handoffs
handoff は、別の専門 agent へ会話の主導権を渡す形です。 OpenAI Agents SDK の docs では、handoffs は専門領域ごとの agent に task を delegate するのに便利だと説明されています。
agents as tools が「呼び出して戻る」に近いのに対し、handoff は「担当を切り替える」に近いです。 LLM主導では、この handoff 先をどれにするかも、モデルが文脈を見て判断します。公式ガイドは、ルーティング自体がワークフローの本質で、以降のやり取りを専門 agent に任せたいときは handoff、会話を奪わせず限定的なサブタスクを処理させたいときは agents as tools、と使い分けを示しています。
LLM主導が向いている場面
手順を固定できない調査
調べてみて初めて次に見るべき資料や論点が分かるタイプ。LLM が状況を見て次の tool や specialist を選べる方が強い。
相談内容が幅広い
サポートや社内ヘルプデスクのように質問の種類が広い場面。細かい分岐を全部コードにするより LLM に triage させる方が自然。
創造的・探索的なタスク
新規事業案、設計レビュー、文章改善など途中で方向が変わる作業。コードで固定しすぎると窮屈になる。
例外が多い業務
条件分岐をコードにすると膨らみすぎる業務。LLM主導で大まかに判断させる価値がある。
落とし穴1: 選択肢を渡しすぎると誤選択が増える
LLM主導でいちばん多い失敗が、ツール・handoff・specialist を「便利そうだから」と片端から渡してしまうことです。選択肢が増えるほど判断は楽になりそうに見えますが、実際には誤選択と無駄な呼び出しが増えます。OpenAI Agents SDK の orchestration guide が最初に挙げる助言も「Invest in good prompts. Make it clear what tools are available, how to use them, and what parameters it must operate within（どのツールがあり、どう使い、どの範囲で動くべきかを明確にせよ）」です。選択肢の数と説明の質が、そのまま選択の質に効きます。
ツール数の目安
経験則として、1つのエージェントに渡すツールは 5〜8 個までに収めると、説明とユースケースを衝突なく書き分けられます。10 個を超えたあたりから「機能が似たツール」が混じり始め、20 個を超えると、人間が読んでも「どれを使うべきか」を即答できなくなります。人間が一覧を見て迷う構成は、LLM も同じように迷います。ツールが 20 個必要になったら、1つの巨大エージェントに全部持たせるのではなく、領域ごとにエージェントを分けて handoff でつなぐ、あるいはコード側で文脈に応じて渡す候補を絞る設計に切り替えるサインです。
「選択肢過多」のログ症状
選択肢過多は、トレースを見ると次のような症状で現れます。観測ツール（LangSmith、Langfuse、SDK 標準のトレースなど）で1リクエストの中身を開くと見分けがつきます。
同じツールの連打
同一の search や file_search を、引数だけ少し変えて3回・4回と呼ぶ。1ステップで決められず「とりあえず叩いて様子を見る」状態。
ターン数の肥大
1依頼で通常3〜5ターンのところが10ターンを超え、最後に max_turns 超過で打ち切られる。SDK は上限を超えると MaxTurnsExceeded を投げる。
似たツールの取り違え
get_user と get_customer のように説明が似たツールを、目的と違う方で呼ぶ。説明文の差が曖昧なほど起きやすい。
確認手順はシンプルです。失敗・遅延したリクエストのトレースを開き、(1) ツール呼び出しの回数と種類、(2) 同じツールの重複、(3) 最終ターン数を見ます。回避策は、渡すツールを 5〜8 個に絞る、説明文を「いつ使い・いつ使わないか」まで書く、機能が似たツールは統合するか名前と説明で差を際立たせる、max_turns を業務に合わせて明示設定する（例: 単純Q&Aなら 6、深い調査なら 15 など）、の順です。
落とし穴2: 境界をどこに引くか — コード主導と混ぜる
実務のエージェントは「全部 LLM 主導」か「全部コード主導」かの二択にはなりません。鍵は、どの操作だけをコードに落とすかの境界をはっきりさせることです。判断の自由は LLM に残しつつ、取り返しのつかない操作だけコードの関門を通します。
コードに落とすべき操作の見分け方
目安は「失敗したときに取り消せるか」「外部に影響が出るか」です。読み取り・検索・要約・下書き生成のような可逆で内部的な操作は LLM に任せて構いません。一方、次のような不可逆・対外的な操作は、LLM の流れ任せにせず、コード側の承認点に固定します。
境界の引き方の一例
たとえば返金サポートのエージェントを考えます。LLM主導の manager agent が会話を受け、「調べる・要約する・返金額を算出する」までは自由に tool を選んで進めます。ここまでは全部可逆なので LLM に任せます。問題は最後の「実際に返金を実行する」ステップです。
ここを LLM のツール呼び出しに直結させず、いったんコードに返す設計にします。具体的には、返金実行ツールを「即実行する関数」ではなく「返金提案（金額・対象・理由を含む構造化データ）を返すだけの関数」にします。LLM はこの構造化データを出力するところまでしか触れません。実際の決済 API を叩くのはアプリ側のコードで、そこに金額上限チェック（例: 1万円超は人間承認に回す）、二重実行防止、人間承認待ちのキューを置きます。
この形なら、会話の柔軟さは LLM 主導のまま保ちつつ、お金が動く一点だけは決定的なコードで守れます。「どこに知能を置き、どこに関門を置くか」を分けるのが、ハイブリッド設計の核心です。
逆に注意したい場面
1. コストや回数を厳密に管理したい
LLM が自由に tool や sub-agent を選べるほど、呼び出し回数は読みにくくなります。
コスト上限が厳しいなら、コード側で回数や分岐を制御する、max_turns を低めに固定する、軽量モデルにサブタスクを寄せる、といった対策が安全です。
2. 承認フローが重要
本番反映、課金、外部送信、権限変更などは、前述のとおり LLM の流れ任せにしない方がよいです。 人間承認点はコード主導で置く方が明確です。
3. 同じ結果を再現したい
監査や業務フローでは、同じ入力ならだいたい同じ流れで動いてほしいことがあります。 LLM主導は柔軟ですが、そのぶん完全な再現性は持たせにくいです。再現性が要る区間だけコード主導にする切り分けが現実的です。
4. tool の選択肢が多すぎる
ツールや specialist が増えすぎると、LLM が何を使うべきか迷いやすくなります（落とし穴1参照）。 この場合は、ツール一覧を絞る、agent を分ける、コード側で候補を制限する、といった設計が必要です。
実務での設計ポイント
LLM主導にするなら、次を先に決めておくと安定しやすいです。
- 使わせる tool や specialist を 5〜8 個に絞る
- 各 tool の説明に「いつ使い・いつ使わないか」を書く
- handoff 条件を instructions に明記する
- 完了条件（何を達成すれば終わりか）を明確にする
- 高リスク操作（書き込み・課金・送信・権限変更）はコード側の承認点で止める
max_turnsを業務に合わせて設定し、超過時の挙動を決める- トレースを定期的に見て、連打・ターン肥大・取り違えを潰す
特に「何でもできる agent」にしすぎないことが大事です。 柔軟さは強みですが、曖昧さと選択肢過多を放置すると、コストと不安定さに変わります。
LLM主導オーケストレーションに関するよくある質問
Q. LLM主導が向いている業務は？
A. カスタマーサポート、リサーチ、文書作成支援、コード生成、Q&A など「毎回フローが違う・ユーザー入力で分岐が変わる」業務です。完全自動化より「人間と対話しながら進める」場面に強いです。
Q. ツールは何個まで渡してよいですか？
A. 1エージェントあたり 5〜8 個を目安にすると、説明とユースケースを衝突なく書き分けられます。10 個前後で機能が似たツールが混じり始め、20 個を超えると人間でも即答できず、LLM の誤選択も増えます。超えたら領域ごとにエージェントを分けるか、コード側で渡す候補を絞ります。
Q. 選択肢を渡しすぎているか、どう見分けますか？
A. トレースに「同じツールの連打」「ターン数の肥大と max_turns 超過」「似たツールの取り違え」「入力トークンの急増」が出たらサインです。失敗・遅延したリクエストのトレースを開き、ツール呼び出しの回数・重複・最終ターン数を確認します。
Q. なぜ予測しづらいのですか？
A. LLM がコンテキスト・プロンプト・モデルバージョン・温度設定など複数要因で出力を変えるためです。同じ入力でも違う結果が出る確率があり、再現性とテスト難易度が高くなります。再現性が要る区間だけコード主導にすると緩和できます。
Q. コストは高いですか？
A. コード主導より高い傾向です。毎回判断するためトークン消費が増え、ツール定義が多いほど毎ターンの入力トークンも膨らみます。プロンプトキャッシュ、サブエージェントの軽量モデル化、max_turns の上限設定で抑えられます。
Q. ガードレールはどう設計しますか？
A. ツール許可リスト、危険操作の人間承認、コード側での出力検証、最大ステップ数（max_turns）、予算上限で多重防御します。「LLM が自由に判断 = 何でも許可」ではないので、書き込み・課金・送信・権限変更だけはコードの承認点に固定するのが定石です。
Q. オーケストレーターには何モデルを使いますか？
A. 上位の推論モデル（Claude Opus、GPT-5、Gemini Pro 系など）が定番です。「どのツールを使うべきかの判断」には推論力が要るためで、下位モデルだと判断ミスが増えます。一方、定型のサブタスクは軽量モデルに寄せてコストを抑えます。
Q. デバッグはどうしますか？
A. LangSmith、Langfuse、SDK 標準のトレースなどで「各ステップの入出力・ツール呼び出し・判断理由」を可視化します。「なぜそのツールを選んだか」がトレースできると、選択肢過多や説明文の曖昧さなど改善ポイントが見えます。
まとめ
LLM主導のオーケストレーションとは、AIエージェントが文脈を見て、どのツールや専門エージェントを使うかを判断する設計 です。 開いた調査、幅広い相談、探索的なタスクでは強い一方で、コスト、再現性、承認フロー、そして選択肢過多には注意が必要です。
大事なのは、
- 柔軟に任せる部分（読み取り・検索・要約・下書き）
- コードで固定する部分（書き込み・課金・送信・権限変更）
- 人間が確認する部分（高額・不可逆な操作）
を分けることです。ツールは 5〜8 個に絞り、トレースで連打やターン肥大を監視し、お金や本番が動く一点だけコードの関門を通す。これがLLM主導を実務で安定させる勘所です。 対になる設計として、コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 もあわせて読むと、使い分けが見えやすくなります。
参考リンク
- OpenAI Agents SDK: Orchestrating multiple agents
- OpenAI Agents SDK: Running agents（max_turns と MaxTurnsExceeded）
- OpenAI Agents SDK: Agents
- OpenAI Agents SDK: Tools
- OpenAI Agents SDK: Handoffs
- OpenAI Agents SDK JS: Handoffs