先に要点
前回の コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 では、アプリ側のコードで agent の流れを決める設計を整理しました。
今回はその対になる、LLM主導のオーケストレーション です。
AI エージェントでは、LLM にツールや専門エージェントを渡し、状況に応じて 次に何を使うか を判断させることがあります。
OpenAI Agents SDK の orchestration guide でも、LLM equipped with instructions, tools and handoffs が、open-ended task に対して自律的に計画し、ツールや handoff を使う形として説明されています。
この記事では、2026年4月21日時点の OpenAI Agents SDK の公式情報をもとに、LLM主導のオーケストレーションとは何か、コード主導との違い、どんな場面に向くのかを整理します。
LLM主導のオーケストレーションとは何か
LLM主導のオーケストレーションとは、AIエージェントが与えられた instructions、tools、handoffs を見て、次に何をするかを LLM 自身に判断させる設計です。
たとえば、ユーザーが「競合サービスを調べて、改善案を出して」と依頼したとします。
LLM主導なら、エージェントは状況に応じて、
- web search を使って調べる
- file search で社内資料を見る
- code execution でデータを集計する
- report writer agent へ渡す
- specialist agent を tool として呼ぶ
のような判断を自分で組み立てます。
コード側が 必ずこの順番で実行する と決めるのではなく、LLM がその場の文脈から手順を選ぶのが特徴です。
コード主導との違い
コード主導では、分類結果がAならこのagent、評価NGなら再試行 のように、アプリ側のコードが流れを決めます。
LLM主導では、エージェントに選択肢を渡し、どれを使うかを LLM が判断します。
| 観点 | LLM主導 | コード主導 |
|---|---|---|
| 流れの決め方 | LLMが文脈から判断する | コードの条件分岐で決める |
| 柔軟性 | 高い | 制御しやすい |
| 再現性 | ぶれやすい | 高めやすい |
| 向く場面 | 開いた調査、壁打ち、複雑な判断 | 定型業務、承認フロー、明確な分岐 |
| 注意点 | 呼び出し回数やコストが読みにくい | 分岐設計が硬くなりやすい |
どちらが上というより、どこをAIに判断させ、どこをコードで固定するか の設計問題です。
LLM主導でよく使われる2つの形
1. Agents as tools
OpenAI Agents SDK では、specialist agent を tool として manager agent に渡す形があります。
この場合、中心の manager agent はユーザーとの会話を握り続けたまま、必要に応じて専門 agent を tool として呼びます。
たとえば、
- booking expert
- refund expert
- research expert
- code review expert
のような専門担当を tool として持たせ、必要になったら LLM が選びます。
この形は、最終回答を manager がまとめたいときに向いています。
2. Handoffs
Handoff は、別の専門 agent へ会話の主導権を渡す形です。
OpenAI Agents SDK の docs では、handoffs は専門領域ごとの agent に task を delegate するのに便利だと説明されています。
agents as tools が 呼び出して戻る に近いのに対し、handoff は 担当を切り替える に近いです。
LLM主導では、この handoff 先をどれにするかも、モデルが文脈を見て判断します。
LLM主導が向いている場面
1. 何を調べるべきかが最初から固定できない
調査や戦略検討では、最初から手順を固定しにくいことがあります。
調べてみて初めて、次に見るべき資料や論点が分かるからです。
こういう場面では、LLM が状況を見て次の tool や specialist を選べる方が強いです。
2. ユーザーの相談内容が幅広い
カスタマーサポート、社内ヘルプデスク、AIアシスタントのように、質問の種類が広い場合です。
最初から細かい分岐を全部コードにするより、LLM に triage させる方が自然なことがあります。
3. 創造的・探索的なタスク
新規事業案、調査方針、設計レビュー、文章改善のように、途中で方向が変わるタスクです。
こうした作業では、コードで固定しすぎると窮屈になります。
4. 例外が多い業務
条件分岐をコードにすると膨らみすぎる業務では、LLM主導で大まかに判断させる価値があります。
逆に注意したい場面
1. コストや回数を厳密に管理したい
LLM が自由に tool や sub-agent を選べるほど、呼び出し回数は読みにくくなります。
コスト上限が厳しいなら、コード側で回数や分岐を制御した方が安全です。
2. 承認フローが重要
本番反映、課金、外部送信、権限変更などは、LLMの流れ任せにしない方がよいです。
人間承認点はコード主導で置く方が明確です。
3. 同じ結果を再現したい
監査や業務フローでは、同じ入力ならだいたい同じ流れで動いてほしいことがあります。
LLM主導は柔軟ですが、そのぶん完全な再現性は持たせにくいです。
4. tool の選択肢が多すぎる
ツールや specialist が増えすぎると、LLM が何を使うべきか迷いやすくなります。
この場合は、ツール一覧を絞る、agent を分ける、コード側で候補を制限する、といった設計が必要です。
よくある失敗
1. 選択肢を渡しすぎる
LLM に大量の tool、handoff、specialist を渡すと、便利そうに見えます。
でも実際には、選択肢が多すぎて誤選択や無駄な呼び出しが増えます。
2. 目的と完了条件が曖昧
LLM主導では、目的が曖昧だと進み方も曖昧になります。
何を達成すれば終わりか は、柔軟な設計でも必ず必要です。
3. guardrailをLLM任せにする
安全制約や禁止事項まで うまく判断してくれるはず にすると危険です。
重要な制約は instructions だけでなく、コード側のチェックや承認点も組み合わせた方が安全です。
4. LLM主導とコード主導を対立で考える
実務では、完全にどちらか一方ではなく、組み合わせることが多いです。
たとえば、通常の相談は LLM 主導で進めつつ、外部送信や本番操作だけコード側の承認フローに乗せる、という形です。
実務での設計ポイント
LLM主導にするなら、次を先に決めておくと安定しやすいです。
- 使わせる tool や specialist を絞る
- 各 tool の説明を短く明確にする
- handoff 条件を instructions に書く
- 完了条件を明確にする
- 高リスク操作はコード側で止める
- ログを見て、無駄な呼び出しを減らす
特に 何でもできる agent にしすぎないことが大事です。
柔軟さは強みですが、曖昧さを放置するとコストと不安定さに変わります。
まとめ
LLM主導のオーケストレーションとは、AIエージェントが文脈を見て、どのツールや専門エージェントを使うかを判断する設計 です。
開いた調査、幅広い相談、探索的なタスクでは強い一方で、コスト、再現性、承認フローには注意が必要です。
大事なのは、
- 柔軟に任せる部分
- コードで固定する部分
- 人間が確認する部分
を分けることです。
対になる設計として、コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 もあわせて読むと、使い分けが見えやすくなります。