AIエージェントのオーケストレーション｜5つの制御

AIエージェントのオーケストレーションは制御設計から始める

「調査担当、分析担当、資料作成担当を分ければ、AIはもっと賢く動く」

この発想は自然だ。ところが、担当を増やした瞬間に別の問題が始まる。誰が最初に動くのか。途中結果はどこへ保存するのか。意見が割れたら誰が決めるのか。失敗した処理をどこから再開するのか。

AIエージェントのオーケストレーションとは、複数のエージェントを並べることではない。実行の入口から終了までを制御する設計である。

OpenAIのAgents SDKは、オーケストレーションを「どのエージェントを、どの順序で実行し、次に何が起こるかを決める流れ」と説明している。LLMに判断させる方法と、コードで流れを固定する方法があり、両方を組み合わせられる。

実務で難しいのは、フレームワークの選定より手前だ。入口、ルーティング、共有状態、権限、失敗処理を決めないまま実装すると、動いているように見えても説明できないシステムになる。

オーケストレーションは「司令塔」を置くだけではない

「司令塔となるエージェントを1つ置けばよい」と考えたくなる。だが、司令塔もAIであれば判断を誤る。専門エージェントが正しい結果を返しても、統合の仕方を間違えることもある。

Microsoftは、エージェント構成を次の3段階で整理している。

Microsoftの設計ガイドも、単一エージェントで十分な仕事に複数エージェントを使わないよう勧めている。複雑さは無料ではない。エージェント間の受け渡しが1つ増えるたびに、入力形式、例外処理、監視、認証の設計が増える。

つまり、最初の問いは「何体作るか」ではない。

単一のエージェントでは、どの境界を守れないのか。

明確な答えがなければ、単一エージェントと決定論的なワークフローから始める方がよい。Microsoftの単一・複数エージェント比較でも、マルチエージェント化によって状態同期、認証情報、監視、遅延、費用が増えると整理されている。

AIエージェントのオーケストレーションで決める5つの制御

業務で使うなら、実装前に5つの制御を仕様にする。ここが曖昧だと、プロンプトを磨いても安定しない。

1. 入口と終了条件を決める

最初に決めるのは、何を受け取ったら処理を始め、何がそろったら終わるかだ。

たとえば営業提案の作成なら、入口は「会社名」だけでは足りない。対象商談、提案目的、利用できる顧客情報、提出期限、出力形式が必要になる。終了条件も「資料ができた」では曖昧だ。必須ページ、根拠リンク、未確認事項、承認者まで定義したい。

入口では最低でも次を固定する。

• 依頼IDと依頼者
• 利用できるデータの範囲
• 必須入力と不足時の扱い
• 期待する成果物の形式
• 完了、保留、失敗の判定条件

面白いのは、入口を厳密にすると、そもそもAIへ渡さない仕事が見えることだ。入力不足なら人に確認する。定型変換なら通常のプログラムで処理する。AIエージェントを呼ぶのは、判断の余地が残る部分だけでよい。

2. ルーティング条件を決める

次は、誰に何を任せるかである。

ルーティングをLLMの自由判断だけに任せると、同じ依頼でも呼び出すエージェントが変わる。探索には便利だが、監査や再現が必要な業務では困る。

条件は、できるだけ構造化する。

OpenAIの公式ガイドでは、中央のマネージャーが専門エージェントをツールとして呼ぶ方式と、担当へ会話を引き渡すハンドオフを分けている。利用者との窓口を1つに保ちたいなら前者、担当そのものを切り替えたいなら後者が合う。

重要なのは、方式名ではない。ルーティングの入力、選択理由、代替先を記録できるかである。

3. 共有する状態を決める

複数のエージェントが同じ仕事を進めるには、途中状態が必要になる。チャット履歴を丸ごと渡すだけでは、重要な判断と雑談を区別できない。

共有状態は、業務上の項目に分ける。

• 現在の目的と処理段階
• 確定した事実
• 仮説と未確認事項
• 参照したデータと更新時刻
• 実行済みの操作
• 次に許可されている操作

状態には版番号も要る。調査エージェントが古い顧客情報を読み、別のエージェントが更新後の情報で提案を作れば、最終結果は食い違う。受け渡し時に「どの版を読んだか」を残せば、やり直す範囲を絞れる。

Google Cloudのエージェント設計パターンは、要件に応じて事前定義ルールとモデルの推論を組み合わせる構成などを示している。状態更新も同じだ。金額、契約、顧客ステータスのような重要項目は、自由文ではなく決めた形式で更新する。

4. 権限と承認点を決める

複数のエージェントに同じ権限を配るのは危険だ。調査担当がCRMを更新できる必要はない。文章作成担当がメールを送信できる必要もない。

エージェントごとに、次の4段階を分ける。

1. 閲覧できる
2. 下書きを作れる
3. 変更案を申請できる
4. 実行できる

さらに、実行前に人間が確認する条件を明記する。外部送信、課金、削除、契約変更、個人情報の共有は、承認なしで進めない。逆に、社内向けの要約や読み取り専用の集計まで毎回承認にすると、運用が詰まる。

権限表には「誰ができるか」だけでなく、「どの条件ならできるか」を書く。

たとえば、メール作成エージェントは返信下書きまで。送信は担当者の承認後。CRM更新エージェントは会社情報の不足項目を提案できるが、商談フェーズ変更は担当者確認後。この粒度なら、AIの速度と人間の責任を両立しやすい。

API仕様書を5つの契約で整理する方法も合わせて読むと、エージェント間の入出力と権限をAPI契約へ落としやすい。

5. 失敗、再開、証跡を決める

最後は、うまくいかなかったときの設計だ。

AIエージェントは、外部APIのタイムアウト、情報不足、矛盾した結果、権限不足に出会う。すべてを「再試行」で処理すると、同じメールを二度送ったり、同じデータを二重登録したりする。

失敗は少なくとも4種類に分けたい。

AWSのAgentic AI Lensは、能力に基づくルーティング、代替経路、競合解決をマルチエージェントの信頼性に必要な要素として挙げている。

再開位置も重要だ。最初から全部やり直すのではなく、確認済みの調査結果は再利用し、失敗した工程から再開する。そのために、依頼ID、実行したエージェント、入力版、出力、判断理由、外部操作の結果を残す。

証跡は監査のためだけではない。改善の材料でもある。どのルーティングで失敗したか、どこで人に戻ったかが分かれば、次に直す仕様を選べる。

発注者と開発側で合意する成果物

オーケストレーションは、プロンプト一覧だけでは発注できない。少なくとも次の5つを成果物として合意したい。

ここで責任を分ける理由は、AIの判断精度だけを開発側へ押し込まないためだ。どの金額なら承認が要るか。何日古い情報なら再確認するか。どの矛盾を人が裁定するか。これらは業務判断であり、発注者が決める。

開発側は、その判断を実装できる条件へ変換する。入力形式、状態遷移、API、監視、テストを設計し、条件どおりに止まることを確かめる。

AIチャットボットを本番運用につなぐ5つの仕様でも、回答範囲、参照情報、引き継ぎ、評価、運用を分けている。オーケストレーションでは、それをエージェント間の受け渡しまで広げるイメージだ。

受け入れ基準は数値と再現手順で置く

5つの制御は、最低限の業務制御である。本番運用には、品質、費用、遅延、同時実行、制御基盤そのものの障害も非機能要件として加える。

検収では、次のような条件をテストケースにする。

• 同じ依頼IDで外部操作が二重実行されない
• 権限のないエージェントが更新を要求したら停止する
• ルーティング結果と選択理由が記録される
• 途中失敗後、確認済み工程を再実行せず再開できる
• 最大実行時間と費用上限を超える前に保留へ移る
• 同じデータを同時更新した場合、古い版による上書きを防ぐ
• オーケストレーターが停止した場合、進行中の依頼を識別して復旧できる

「正しい答えが出た」だけでは検収しにくい。停止すべき場面で止まり、再開時に二重実行せず、判断を後から説明できる。そこまで確かめて、業務システムとしての合格になる。

導入前に確認したいチェックリスト

実装へ進む前に、次をチームで確認してほしい。

• 単一エージェントでは解けない理由が説明できる
• 各エージェントの責任が重複していない
• 入口の必須項目と不足時の扱いが決まっている
• ルーティング条件と選択理由を記録できる
• 共有状態に版と更新者がある
• 外部送信、課金、削除、契約変更の承認点がある
• 同じ操作を二重実行しない識別子がある
• 失敗を一時障害、入力不足、権限不足、矛盾に分けている
• 途中工程から安全に再開できる
• 完了、保留、失敗を利用者へ説明できる

全部に答えられなくても構わない。答えられない項目が、実証実験で確かめるべき仮説になる。ただし、分からないまま本番権限を渡すのは避けたい。

AIエージェントのオーケストレーションは、賢い司令塔を作る競争ではない。仕事の入口、分担、状態、権限、失敗を、チームで扱える仕様にすることである。

株式会社Atsumellでは、業務フローの整理から、機械的に検証できる入出力仕様や状態遷移、権限・承認、評価条件、運用設計までを一緒に組み立てている。複数のAIエージェントを検討しているが、どこから仕様にすべきか迷っているなら、まず現在の業務と止めたい事故を聞かせてほしい。

関連記事

• AIエージェントの比較で見る6つの条件
• AIチャットボットの作り方｜5つの仕様
• AI内製化は何を残す？4つの社内資産