AIエージェント オーケストレーションとは｜会社での管理

AIエージェント オーケストレーションとは、得意分野の違う複数のエージェントをまとめて、役割分担や順番、承認、失敗した時の戻し方を調整する仕組みです。会社で使うのであれば、社員がそれぞれ作り始める前に、使う環境・権限・ログ・止め方を先にそろえておくことが大切になります。AIエージェントそのものの基本は、先にAIエージェントとはで確認してみてください。社員10〜200名ほどの会社なら、作り方より先に管理の形を決めておくと、後から困りにくくなります。

AIエージェント オーケストレーションとは｜指揮者と交通管制の役目です

AIエージェント オーケストレーションは、複数のエージェントをただ並べるのではなく、誰に何を任せるかを調整してくれる仕組みになります。音楽で言えば指揮者、道路で言えば交通管制のような役目でしょう。調べる係、まとめる係、下書きを書く係、確認する係がそれぞれ勝手に動くと、一見早く進んでいるようでも、同じ資料を二度読んだり、古い答えを次の係に渡してしまったりします。そうしたズレを減らすために、順番や受け渡す中身、承認、失敗した時の戻し先を先に決めておくわけです。

エージェントが1つだけの場合は、頼まれた内容に合わせて、必要なツールを自分で選びながら答えていきます。これを複数に分けると、それぞれが小さな役割に集中することが出来ます。たとえば問い合わせ対応であれば、内容を分類する係、社内資料を探す係、回答案を書く係、送信前に確認する係に分ける形です。ただ、分けた分だけ便利になる一方で、管理する場所も増えてしまう点は覚えておきましょう。

Microsoft Learn の「AI エージェント オーケストレーション パターン」でも、要件を確実に満たせる範囲で、いちばん簡単な形から使うという考え方が示されています。モデルを直接呼ぶだけで済む作業なのか、ツールを使う単体エージェントで足りるのか、それとも複数のエージェントを束ねる必要があるのかを分けて考えていきます。調整の仕組みを入れるほど、待ち時間も失敗のパターンも増えてしまうからです。

会社として最初に決めておきたいのは、きれいな構成図よりも、どこまでを自動で進めてよいかになります。メールの送信や顧客情報の更新、会計データの変更、人事情報の参照などの操作は、いくら便利でも同じ扱いにするわけにはいきません。最初の打ち合わせでは、出来ることを広げる話の前に、触ってよいデータと止める担当の方を紙に書き出してみてください。

オーケストレーションを入れる目的は、人の手をなくすことではありません。これまで人が毎回つないでいた受け渡しを整理して、確認が必要な場面にはきちんと人の目を残すための設計となります。ここを取り違えてしまうと、便利な自動化のつもりが、止め方の分からない作業の列になってしまいます。

単体エージェント・RPA・通常ワークフローとの違い

大きな違いは、誰が手順を決めるのか、そして状況に合わせてどこまで分かれ道を選ぶのかにあります。通常ワークフローは、あらかじめ決めた道筋に沿って進めていくものになります。Anthropic は、決められたコードの道筋でLLMとツールを動かすものをワークフロー、LLMが自分で手順やツールの使い方を決めていくものをエージェントとして分けています。RPAは、画面操作や決まった手順をなぞる場面と比べると分かりやすいでしょう。

単体エージェントは、1つのエージェントがツールを選びながら仕事を進めていく形になります。Microsoft Learn では、ツールを使う単体のエージェントが、多くの企業の用途で既定の選択肢になり得ると説明されています。分類や要約、翻訳のように1回で済む作業であれば、エージェントを使わずにモデルを直接呼ぶだけで足りる場面もあるでしょう。最初から複数のエージェントに分ける必要が本当にあるのか、ここで一度立ち止まって考えてみましょう。

エージェントを分ければ分けるほど賢くなる、と考えたくなる気持ちも分かります。ただ、Microsoft Learn は、単純な順番型や並列型で足りる場面にわざわざ複雑なパターンを使うことや、意味のある専門性を持たないエージェントを増やすことを、落とし穴として挙げています。名前を分けただけの調査係や分析係、確認係を作っても、管理の手間が増えるだけとなってしまいます。

社員10〜200名ほどの会社であれば、いきなり大きな基盤を作るより、単体エージェントにツールを足すだけで足りないかを先に見てみるのがおすすめです。たとえば社内規程を探して回答案を出すだけなら、1つのエージェントで充分なこともあります。一方で、複数の部署のデータを読み、申請を判定し、別のシステムに更新案を出して人の承認を待つような仕事になると、束ねる仕組みが必要になってきます。

見分け方は、実はそれほど難しくありません。ひとつの作業を最初から最後まで説明してみて、途中で別の専門の担当に渡したくなる場面が2つ以上あるかを見てみてください。そうした場面がなければ、単体エージェントか通常ワークフローで始めたほうが、試すのも管理するのもずっと楽になります。

調整の型｜順番・並列・会話・引き渡し・マネージャー

調整の型は、名前で選ぶものではなく、業務の流れに合わせて選ぶものになります。Microsoft Learn では、シーケンシャル、コンカレント、グループチャット、ハンドオフ、マゼンティックの5つの型が紹介されています。名前を覚えるより、社内のどの詰まりをほどきたいのかから考えていくと、ずっと決めやすくなるでしょう。

シーケンシャルは、決められた順番どおりに進めていく型になります。問い合わせを分類して、資料を探し、回答案を書いて、確認へ回す流れによく合います。前の工程の出力がそのまま次の入力になるため、1つ前でつまずくと、その影響が後ろの工程まで続いてしまいます。最初に試すのであれば、各工程で渡す出力の形を短くそろえてみてください。

コンカレントは、同じ仕事を複数の係に同時に任せて、あとで結果を集める型となります。いくつかの候補案を比べたい時や、別々の目でリスクを確かめたい時、長い資料を分けて読ませたい時に使いやすいでしょう。待ち時間を短くしやすい反面、モデルを呼ぶ回数はその分増えてしまいます。並列にした分だけ、速さと引き換えに利用量も増えると見ておきましょう。

グループチャットは、複数のエージェントが1つの会話の中で話し合いながら進める型です。作る係とチェックする係（作成者とチェッカー）が交互に直していく形も、ここに含まれます。Microsoft Learn では、グループチャットで動かすエージェントを3つ以下に抑えることを検討するよう示されています。直しても直しても終わらない堂々巡りを避けるために、やり取りの回数にも上限を決めておきましょう。

ハンドオフは、最初の窓口役が内容を見て、ふさわしいエージェントに引き継ぐ型になります。社内の問い合わせを、人事・経理・情シスのどこへ回すか判断する場面を思い浮かべると分かりやすいでしょう。引き継ぎ先を間違えると、問い合わせた方を困らせてしまいます。分類しきれない時は、人へ戻す道も用意しておいてください。

マゼンティックは、マネージャー役のエージェントがやることの一覧（タスク台帳）を作り、計画を組み立てながら進める型です。前もって細かい作業を読みにくい、複雑な仕事に向いています。その一方で、全体の費用を予測しにくいという点も、Microsoft Learn で説明されている通りです。初めての社内導入でいきなりここから始めると、費用や責任の説明に困ってしまうかもしれません。

活用シーンと既存システム連携｜広げる前に境界を決めます

部署をまたぐ仕事ほど効果は見えやすくなりますが、そのぶん管理も重くなってしまいます。顧客対応や社内問い合わせ、申請の承認、受注処理、新しく入った方の受け入れ（オンボーディング）といった仕事は、いくつもの情報源と人の判断が絡み合っています。まずは、どのシステムは読むだけにして、どこへの書き込みを許すのかを分けてみてください。

顧客対応であれば、問い合わせを分類して顧客情報を確認し、関係する社内資料を探してから回答案を作る流れになります。CRMやSFA（顧客や商談を管理するシステム）の情報に触れる場合は、返してよい顧客データの範囲を、使う方の権限に合わせる必要が出てきます。Microsoft Learn でも、資料の置き場（ナレッジストア）に広いアクセス権が必要な場合であっても、利用者が本来見られないデータを返してはいけないと説明されています。

社内の問い合わせは、人事規程や経費のルール、ITの手順、申請フォームなど、いくつもの分野にまたがりがちです。分類する係が窓口になって、分野ごとの回答係へ引き継ぐ形であれば、先ほどのハンドオフがよく合うでしょう。最後に申請フォームへの入力まで任せる場合は、下書きで止めておくのか、送信の前に人の確認を挟むのかを決めておきましょう。

申請の承認では、書類に足りないところがないかの確認、規程との照らし合わせ、承認者への回付、差し戻す時の文面づくりまで、いくつもの作業が続きます。AIに判断まで任せ切るよりも、差し戻し案を作る係として使うほうが始めやすくなります。承認そのものは人の手に残しておくと、社内への説明もしやすいでしょう。

受注処理やオンボーディングになると、CRMや契約書、社内のチェックリスト、メール、チャットまでがつながってきます。MCPやiPaaSといった、AIやツール同士をつなぐ仕組みがよく話題になりますが、名前より先に確認したいのは、どの権限で何に触れるのかという通り道のほうです。つなぐ先が増えるほど、1つの誤った出力が別の場所に書き込まれてしまう心配も大きくなります。

ここで避けたいのは、便利そうな連携先から先に増やしてしまうことです。読める場所と書ける場所、止める担当を決めないまま広げると、あとから棚卸しをするのがとても大変になってしまいます。今あるシステムにつなぐ前に、入力してよい情報の線引きを生成AIのセキュリティ対策チェックリストで確認してみてください。

まず棚卸しする｜ばらばらに作られたエージェントを一覧にします

会社で使い始める前に手を付けたいのは、新しい導入よりも、今あるものの棚卸しになります。社員や部署がそれぞれ先に作り始めていると、誰が何を作り、どのデータを読ませて、どこに書き込めるのかが見えにくくなってしまいます。Microsoft Copilot Studio の説明でも、複数のチームが別々に管理する場合や、個別に公開・管理したい場合は、エージェントを分ける理由になるとされています。分けるのであれば、分けたものを後から追える一覧表が欠かせません。

棚卸しの表は、立派な台帳でなくても始めることが出来ます。項目は、名前、作った方、使う部署、使うAI、読むデータ、書き込みの権限、共有の範囲、止め方、月の利用量、承認者くらいで充分でしょう。最初は普段のスプレッドシートで構わないので、すでに使われているものから1行ずつ書き込んでみてください。

この中で意外と抜けやすいのが、止め方の欄になります。Copilot Studio の場合、メインのエージェントのエージェントページで子エージェントや接続先の有効トグル（オン・オフのスイッチ）を切ると、その相手をユーザーやトリガーに反応しない状態にすることが出来ます。削除や接続を外す操作も、これとは別に用意されています。使い始める前に、止める手順を画面の写真つきで残しておきましょう。

現場から棚卸しを嫌がられた時は、見張るための表ではなく、これからも使い続けるためのお手入れの表だと伝えると、受け入れてもらいやすくなります。作った方が不在でも直せるように、使うデータが変わっても追えるように、費用が増えた時にも話し合えるようにするための表だからです。個人の工夫を潰すのではなく、会社で使い続けられる形に直す作業と考えましょう。

社員の方が個人のアカウントや無料のツールで作っている場合は、入力したデータやログの扱いを会社から確認できないこともあります。そのまま野良AIとして残ってしまうと、便利な仕組みほど部署の外からは見えなくなってしまいます。会社から見えない使い方を減らす考え方については、野良AI（シャドーAI）対策も合わせて読んでみてください。

権限・承認・エスカレーション｜人が止める場所を先に置きます

ルールづくり（ガバナンス）は、禁止事項を増やす話ではなく、AIに任せる範囲を3つの段階に分ける話になります。読むだけ、下書きまで、送信や更新は人が承認してから、という順で考えると、現場の方にも説明しやすいでしょう。Microsoft Learn でも、エージェントや束ね役（オーケストレーター）は最小限の権限で設計するという考え方が示されています。まずはこの3段階で、社内の作業を仕分けしてみてください。

読むだけの段階では、エージェントは社内文書やFAQを読んで回答案を出すところまでを受け持ちます。顧客情報や人事情報を読ませる場合は、使う方が本来見られる範囲だけを返すようにしなければなりません。ここを広げすぎてしまうと、AIが悪いというより、権限の決め方が粗かったという問題になってしまいます。

下書きまでの段階では、メールや申請の文面、登録内容、差し戻しの文などを作りますが、送信や更新まではさせません。ChatGPT Business・Enterprise のワークスペースエージェントの説明でも、アプリやコネクタに書き込む操作は、既定では実行中に毎回確認する設定になっています。社内のルールも、最初はこの考え方に寄せておくと始めやすいでしょう。

送信や更新まで任せる段階になると、どこで承認を通すかが大切になります。Microsoft Learn では、人の確認を出力全体にかけるのではなく、特定のツールを使う場面に絞る考え方が示されています。たとえば、回答案づくりは自動で進めて、メールの送信やCRMの更新、ファイルの削除の時だけ承認を求めるといった形です。承認は全部にかけるより、危ない操作だけに絞るほうが続けやすくなります。

人へ判断を戻す（エスカレーション）のは、AIが自信を持てない時だけでは足りません。分類できない問い合わせや根拠が見つからない回答、金額や契約に触れる操作、お客様からの苦情、人事や会計に近い情報は、人へ戻す条件として先に書き出しておきましょう。その条件を決めないまま自動化してしまうと、現場の方は便利さより不安のほうを強く感じてしまいます。

• 閲覧のみ社内文書を読んで、回答案や候補を返すところまでの段階です。書き込みの権限は持たせません。
• 下書きまでメールや申請、登録内容の案までを作ります。送信や更新は人が押す形です。
• 承認後に更新人が確認した操作に限って、システムへの反映を許す段階になります。承認ログもあわせて残しておきます。

共有の接続を使う場合は、誰の権限で動いているのかを特に気にかけておきたいところです。同じ説明では、アプリの認証には、使う方それぞれのアカウントを使う方法と、エージェントが持つアカウントを使う方法があるとされています。共有の接続では、出来るだけサービスアカウント（人ではなく仕組み用のアカウント）を使うよう注意書きもあります。個人のアカウントを共有の接続にしてしまうと、その担当の方が異動や退職をした時に、止め方が分かりにくくなってしまいます。

社内ルールは、長い文書にしなくても始めることが出来ます。最初の版では、作る前の申請、扱ってよいデータ、外へ出す前の確認、止める条件の4つだけでも充分でしょう。下の表をたたき台にして、部署ごとの例外を書き足してみてください。

権限の話は、技術の担当者だけで決めてしまわないほうがよいでしょう。総務や経理、営業、人事の責任者の方が、AIに触らせたくない情報を短く出し合うだけでも、線引きが見えてきます。社内ルールの文書づくりは、生成AIの社内ガイドラインの作り方も参考にしてみてください。

ログ・可観測性・説明責任｜後から追える形にします

ログは、問題が起きた時に誰かを責めるためのものではなく、なぜその答えや操作になったのかをたどるための材料になります。複数のエージェントで動かすと、見た目は1つの結果でも、裏では分類、検索、下書き、承認待ちなどの工程がいくつも連なっています。どの段階で中身が変わったのかを追えなければ、直しようもありません。

Microsoft Learn でも、コンプライアンス要件（法令や社内規程の求め）を満たせるように、後から確かめられる記録（監査証跡）を設計するよう説明されています。ここで残しておきたいのは、使った方、呼び出したエージェント、使ったツール、参照したデータの種類、承認した方、失敗した場所あたりになります。会話をまるごと全部残しておけばよい、という単純な話ではありません。

可観測性とは、ちゃんと動いているかどうかを外から見えるようにする仕組みのことです。待ち時間が長い、途中で止まる、同じ作業を何度も繰り返している、根拠の引用が消えている、といった様子に気づけるようになります。Copilot Studio の説明では、エージェントから呼び出し元へ結果を戻す時に、引用が常に維持されるとは限らないという制限も示されています。引用や根拠が欠かせない業務では、最後の出力だけでなく、受け渡しの途中も確認してみてください。

説明責任を考える時には、誰が何を承認したのかを分けて残すことが大切になります。AIが作った案と、担当者が確認した内容、管理者が許可した権限は、それぞれ別の記録として扱います。全部をまとめてAIのせいのように見せてしまうと、社内にも取引先にも説明しづらくなってしまいます。人が見た場所とAIだけで進んだ場所を、ログで分けて残しましょう。

ログの取り方は、最初から完璧を目指さなくても大丈夫です。動かし始めのうちは、1回の実行ごとに開始時刻と終了時刻、使った方、使った型、承認の有無、失敗した時の理由を残すだけでも、改善の手がかりとして充分に使えます。週に一度は、途中で止まった実行と人へ戻った実行を見返して、どんな条件で詰まっているのかを確かめてみましょう。

説明のためのログは、細かければ細かいほどよいというものではありません。お客様に説明する時、監査で質問に答える時、社内で改善する時では、必要な細かさがそれぞれ違ってきます。お客様には最終的な回答の根拠が、管理者の方には誰が承認したかが大事です。開発や運用の担当者にとっては、どの工程で止まったのかが知りたいところでしょう。

毎週の振り返りでは、うまくいった実行よりも、止まった実行のほうから先に見ていきます。止まった理由が権限不足であれば、すぐに権限を広げるのではなく、まず任せる仕事の範囲を狭めるのが安全でしょう。根拠が消えていたのなら、引用が必要な工程を後ろのほうに置き直してみましょう。費用が増えていた場合は、並列処理ややり直しの回数を見直してみてください。

とはいえ、ログを残しただけでは現場の不安は減りません。どのログを誰が見るのか、月に何回見直すのか、見つけた問題を誰に返すのかまで決めておく必要があります。利用ログの考え方は、生成AI全体のコスト管理にもそのままつながってきます。

コストとツール選び｜呼び出し回数が増える前提で見ます

費用は、エージェントの数ではなく、裏側で何回モデルを呼び出すかで増えていきます。Microsoft Learn でも、複数のエージェントを束ねると、モデルの呼び出しが掛け算で増えると説明されています。1つの依頼を4つのエージェントで処理し、確認で2回やり直すとなると、見た目は1回の依頼でも、中身は何回分もの利用となってしまいます。

金額を考える前に、まずは月にどれくらい動かすのかを数えてみるのが現実的でしょう。たとえば1日20件の問い合わせを20営業日こなすなら、月400回の実行になります。1回の実行で分類・検索・回答案・確認と4回モデルを呼ぶとすると、月1,600回の呼び出しです。ここにやり直しや、作成者とチェッカーの往復が加わると、回数はさらに膨らんでしまいます。

すべてのエージェントに高性能なモデルを使う必要はありません。Microsoft Learn でも、すべてのエージェントが能力の高いモデルを必要とするわけではないと説明されています。分類や決まった形のチェックには軽いモデルを、根拠の確認や長い文章の整理には強いモデルを、というように使い分けを考えてみてください。モデルを分けるだけでも、同じ作りのまま月々の出費が変わってきます。

ツールを選ぶ時は、料金表の安さだけで決めないほうがよいでしょう。見ておきたいのは、使える型、権限の管理、承認を挟めるか、ログ、使えるAI、上限の設定、今あるシステムとのつなぎ方あたりになります。プログラムを書かずに作れるノーコードやローコードの環境は、手軽に作り始められる反面、動作を制御できない可能性があると Microsoft Learn は説明しています。作りやすさと止めやすさを、同じ表で比べてください。

各社の細かな料金は、ここでは並べていません。料金の決まり方が、席ごと、クレジット、使った分だけ、開発費とばらばらなため、単価だけを同じ表に並べると誤解を招きやすいからです。AIエージェントまわりの料金を比べたい方は、AIエージェントの料金や、法人向けサービス全体の生成AIサービス比較で確かめてみてください。

無料枠や試用のツールを使う時も、会社の機密を入れる前に4つだけ確かめておきたいことがあります。入力したデータがどこに保存されるのか、ログを管理者が見られるのか、商用利用の条件はどうなっているのか、退職や異動をした方のアカウントを止められるのか、の4つです。無料で試すことと、会社の業務データを載せることは、分けて考えるようにしましょう。

予算を考える時は、月額だけでなく、利用量が増えた時にどう止まるのかまで見ておきたいところです。上限に近づいた時にお知らせが来るだけなのか、上限で止まるのか、超えた分が別の請求に回るのかで、総務や経理の方の心配はずいぶん変わってきます。予算の打ち合わせでは、料金表を開く前に、月の実行数、1回あたりの工程数、やり直しの上限、使うモデルの種類を書き出してみてください。

会社の出費に置き換える時は、計算の式を社内で1つに決めておくと、ぐっと楽になります。月の実行数に1回あたりのモデル呼び出し数を掛けて、そこに各サービスの単価やクレジットの消費を当てはめる形です。たとえば月400回の実行で4工程なら1,600回分となり、確認のやり直しを2回まで許すのであれば、その分の上振れも見込んでおきます。単価が変わったとしても、この式さえあれば見直すことが出来ます。

導入の進め方｜小さく始めて段階的に広げます

導入は、業務の棚卸し、小さな試し、承認つきの運用、少しずつの拡大という順で進めると無理が少ないでしょう。最初から部署をまたぐ大きな仕組みを作ってしまうと、うまくいかなかった時にどこを直せばよいのか分かりにくくなってしまいます。Microsoft Copilot Studio の説明でも、複数のエージェントを束ねる仕組みは強力である一方で、必ずしも必要とは限らないとされています。

最初に選びたいのは、月に何度も発生して、手順を言葉で説明でき、失敗しても人が元に戻せる仕事になります。社内問い合わせの回答案、申請の不足確認、オンボーディングのチェックリストづくりなどが向いているでしょう。お客様への送信や基幹システムの更新まで任せるのは、下書きでの運用を続けて、ログを確かめてからにしてください。

1週目は、その業務の範囲を決めるところから始めます。どこから始まってどこで終わるのか、どのデータを読むのか、出来上がったものを誰が使うのかを書き出してみてください。2週目には、単体のエージェントや通常ワークフローで足りるかどうかを試していきます。ここで足りるようであれば、無理に複数へ分けないという判断も立派な正解でしょう。

3週目以降になって、役割を分ける意味がある所だけを複数のエージェントに分けていきます。分類、検索、下書き、確認のように、担当が自然に分かれる部分から始めるとよいでしょう。あわせて、それぞれのエージェントが何が出来たら合格なのかも短く書いておきます。回答案なら根拠を示す、検索なら参照元を返す、確認なら差し戻しの理由を出す、といった具合です。

実際に動かし始めたら、毎週見る数字を決めておきましょう。実行した数、失敗した数、人へ戻した数、承認待ちで止まった数、やり直しの回数があれば充分です。数字が増えたから悪い、という話ではありません。どこに詰まりがあるのかを見つけるための材料になります。広げる判断は、成功例の数より、止め方と直し方が見えてからにしましょう。

• 業務を選ぶ月に何度もあり、手順を説明でき、人が戻せる仕事から選びます。
• 単体で試す1つのエージェントや通常ワークフローで足りるかを先に見ます。
• 役割を分ける分類、検索、下書き、確認など、意味がある分担だけに絞ります。
• 承認を置く送信、更新、削除などの操作は人の確認を入れます。
• ログを見る週に一度、失敗と人へ戻した実行を確認します。
• 本番判定を決める失敗時に止められること、承認者が迷わないこと、月の利用量を説明できることを確認します。
• 廃止日を置く試験利用のまま残るエージェントを減らすため、使わない場合に止める日も決めます。

よくあるつまずきは、社内で呼ぶ名前ばかりが先に増えてしまうことです。営業エージェント、経理エージェント、人事エージェントと名前だけが増えても、読むデータや書ける場所、承認者が空欄のままでは、管理は少しも楽になりません。名前を付ける前に、まず棚卸し表の項目を埋めるところから進めてみてください。

もう1つ気をつけたいのが、プレビュー（お試し段階）の機能を本番の前提にしてしまうことです。Copilot Studio の外部エージェント接続の一部にはプレビューと明記されたものがあり、運用環境での使用は想定していないと説明されています。試しに触ってみるのは構いませんが、会社の標準の手順に組み込む前に、提供の状況を確かめておきましょう。

※本文で紹介した各社の説明は、2026年10月9日時点で各社の公式ドキュメント（Microsoft Learn「AI エージェント オーケストレーション パターン」「他のエージェントの概要を追加」、Anthropic「Building effective agents」、OpenAI のヘルプ「ChatGPT workspace agents」）に掲載されている内容で、いずれも提供元による説明です。

よくある質問