先に要点
AI エージェントの構成を見ていると、LLM が自律的に次を決める流れ と コード側で流れを決める形 の2つが出てきます。
前者は agentic で柔軟ですが、後者は speed、cost、predictability の面で強いことがあります。
OpenAI Agents SDK の orchestration ガイドでも、オーケストレーションには大きく
- LLM に判断させる方法
- コードで流れを決める方法
があり、それぞれに tradeoff があると整理されています。
この記事では、2026年4月21日時点の OpenAI Agents SDK の公式ドキュメントを中心に、コード主導のオーケストレーションとは何か、LLM 任せとの違い、どんな場面で向くのかを整理します。
コード主導のオーケストレーションとは何か
コード主導のオーケストレーションとは、どの agent をどの順番で走らせるか、どの条件で次へ進むかを、アプリ側のコードで決める設計です。
たとえば次のような流れです。
- まず分類 agent に依頼内容を分類させる
- その結果が
bugなら修正フローへ進む docなら記事生成フローへ進む- 修正後は必ず評価 agent を通す
- 評価 NG なら再試行、OK なら人間承認へ進む
ここで重要なのは、次に誰へ渡すか を LLM がその場で好きに決めるのではなく、コード側が条件分岐として持つことです。
LLM任せのオーケストレーションと何が違うのか
OpenAI の docs では、LLM 主導のオーケストレーションは、agent が tools や handoffs を使って自律的に流れを決める形として説明されています。
一方、コード主導のオーケストレーションは、your code determines the flow という考え方です。
ざっくり違いを表で見るとこうです。
| 観点 | LLM主導 | コード主導 |
|---|---|---|
| 次の流れ | LLMがその場で判断 | コードの条件分岐で決める |
| 柔軟性 | 高い | 中程度 |
| 再現性 | ぶれやすい | 高めやすい |
| 速度・コスト | 流れ次第で増減しやすい | 予測しやすい |
| 向く場面 | 曖昧で開いたタスク | 明確な分岐や承認フロー |
つまり、柔軟性を優先するなら LLM 主導、制御しやすさを優先するならコード主導、という見方ができます。
なぜコード主導が必要になるのか
1. 速度とコストを読みやすくしたい
LLM に flow を全部決めさせると、何回 handoff が起きるか、どこで再試行するか、どの specialist を何回呼ぶかが読みにくくなります。
小さなぶれでも、積み重なると速度やコストに効きます。
コード主導なら、
- 何回まで再試行するか
- どの条件で evaluator を通すか
- 並列にするか逐次にするか
を固定しやすくなります。
2. 危ない操作の承認点を置きたい
本番反映、課金、外部送信、権限変更のような処理は、どこで人間確認を入れるかが大事です。
こうした承認点は、コード主導の方が明示しやすいです。
3. 分岐条件がすでに明確
たとえば、
- ラベルが
billingなら請求担当 - 優先度が
highなら人間レビュー必須 - 出力が schema 不一致なら再実行
のように分岐条件がはっきりしているなら、LLM に毎回考えさせるより、コードへ置いた方が素直です。
どんな形で使うのか
OpenAI の orchestration docs では、コード主導でよくあるパターンとして次のようなものが挙げられています。
1. 分類して分岐する
最初に structured output でカテゴリを出し、その結果を見てコード側で次の agent を選ぶ形です。
2. 直列にチェーンする
調査 -> 下書き -> 改善 -> 評価 のように、手順をコードでつなぐ形です。
3. evaluator でループする
出力を評価 agent に見せ、NG なら再試行、OK なら次へ進む、という流れです。
4. 並列に走らせる
独立した複数タスクを asyncio.gather のようなコード側の並列処理で走らせる形です。
このときも、誰を並列にするかはコードが決めます。
向いている場面
定型フローがある業務
問い合わせ分類、社内申請、レビュー導線、記事生成フローなど、手順が比較的決まっているものに向いています。
監査や再現性が大事な業務
なぜその agent を呼んだのか なぜ再試行したのか を説明しやすくしたい場面です。
コストを抑えたい業務
不要な specialist 呼び出しや handoff を減らしたいときは、コードで制御する方が読みやすいです。
失敗条件が明確な業務
schema 不一致、禁止操作、評価 NG のように失敗条件が定義しやすい場面は、コード主導と相性がよいです。
向かない場面
一方で、最初から flow を細かく決めにくい仕事には向きません。
たとえば、
- 何を調べるべきか自体が曖昧な調査
- 途中で論点が大きく変わる壁打ち
- かなり開いた創造作業
のような場面では、LLM 主導の柔軟さの方が強いことがあります。
無理にコード主導へ寄せると、分岐だらけでかえって複雑になることもあります。
実務でよくある誤解
1. コード主導ならAIらしさがなくなる
そんなことはありません。
流れ をコードで決めて、各ステップの知的処理 は agent に任せる、という分担ができます。
2. コード主導の方が必ず安全
制御しやすくはなりますが、ルール設計が雑なら危ないです。
危険な tool を開きっぱなしにしていれば、コード主導でも事故は起きます。
3. LLM主導より常に安い
単純なフローなら安くなりやすいですが、コード側で細かく evaluator や retry を組みすぎると、逆に重くなることもあります。
どう判断すればいいか
迷ったら、次の3つで見ると判断しやすいです。
分岐条件が言語化できるか
こういうときはこの agent と短く書けるなら、コード主導に寄せやすいです。
失敗条件が定義できるか
評価 NG や schema mismatch のような条件が明確なら、コードで制御しやすいです。
監査や説明責任が必要か
必要なら、流れをコードに置く価値が高いです。
まとめ
コード主導のオーケストレーションとは、AIエージェント同士の流れや分岐条件を、LLMのその場判断だけでなくコード側で決める設計 です。
柔軟性は少し下がりますが、速度、コスト、再現性、承認フローの明示ではかなり強いです。
大事なのは、
- どこを LLM に任せるか
- どこをコードで固定するか
- どこで評価や人間承認を入れるか
を分けて考えることです。
マルチエージェント全体の前提は マルチエージェントとは？複数のAIエージェントを分けて使う意味と注意点を整理 から、受け渡しは Handoffとは？AIエージェントが役割を受け渡す仕組みを整理 とあわせて読むとつながりやすいです。
参考リンク
- OpenAI Agents SDK: Agent orchestration
- OpenAI Agents SDK: Context management
- OpenAI Agents SDK: Handoffs
- OpenAI Agents SDK: Run config