AIエージェントオーケストレーション：セキュリティチームが知っておくべきこと

AIエージェントオーケストレーションとは？

AIエージェントオーケストレーションとは、複数のAIエージェントが共有ワークフローを通じて連携し、複雑な複数ステップのタスクを完了できるよう統制して管理することです。これがなければ、マルチエージェントシステムは孤立したautomationの集まりになり、作業の重複や相互の競合が起き、contextも共有できません。

オーケストレーションされたシステムの中心には、オーケストレーターエージェントがあります。これは連携を担うレイヤーで、目標をサブタスクに分解して専門エージェントに委任し、エージェント間のデータフローを管理して最終結果をまとめます。誰が何をどの順序で担当し、問題が起きたときにどう対処するかを決める、プロジェクトマネージャーのような存在です。

単一のAIエージェントは、複雑なタスクに対してすぐに能力の限界に達します。オーケストレーションを使えば、それぞれ特定の機能に最適化された専門エージェントを組み合わせ、end-to-endのワークフローを処理するシステムを構築できます。顧客からの返金リクエストを例に考えてみましょう。

• 注文の詳細を取得するエージェント

• 返品ポリシーを確認する別のエージェント

• 支払いの取り消しを処理する3つ目のエージェント

• これらのステップの順序を決め、例外（返品期限切れなど）を処理するオーケストレーター

これは、Apache AirflowやAWS Step Functionsのような従来のワークフローautomationツールとは異なります。こうしたツールは、決定論的で事前定義されたタスクシーケンスを実行します。エージェントオーケストレーションでは、ここに自律的な意思決定が加わります。オーケストレーターは固定のスクリプトではなく、中間結果に基づいてエージェント、ツール、実行パスを動的に選択します。この非決定性こそがオーケストレーションされたエージェントの強みであり、後述するように保護を難しくする要因でもあります。

AIエージェントオーケストレーションの重要性が高まる理由とは？

組織は、単一目的のAIツールから自律的なマルチエージェントシステムへと急速に移行しています。Wizの『クラウドにおけるAIの現状2025（State of AI in the Cloud 2025）』レポートによると、現在、組織の85%がAIサービスまたはツールを利用しています。

導入するエージェントが増えるにつれ、ボトルネックは個々のエージェントの構築から、エージェント同士の連携へと移ります。オーケストレーションがなければ、エージェントは共有contextを持たない分断されたautomationとして動作し、作業が重複するうえ、エージェントセキュリティのgovernanceも統一されません。たとえば、異なるSaaSのAPIやクラウドストレージバケットに接続された3つのマーケティングエージェントがあっても、どのエージェントがどのデータにアクセスするかを統制することも、失敗したステップを再試行することも、end-to-endのワークフローを監査することもできません。

多くの議論で見落とされているのが、クラウドインフラの観点です。オーケストレーションされたエージェントは、実際のIAMロール、ネットワーク設定、データアクセス権を備えた実際のクラウドサービス上で動作します。どのクラウドのresourceをどの順序で起動するかは、オーケストレーションレイヤーが決定します。そのためオーケストレーションレイヤーは、AIだけの問題ではなく、運用とセキュリティの両面で重要なコントロールポイントになります。

AIエージェントオーケストレーションの仕組みとは？

AIエージェントオーケストレーションは、どのように機能するのでしょうか。オーケストレーションは、計画から実行、フィードバックまでのライフサイクルに沿って進みます。詳細はLangGraph、CrewAI、AutoGenなどのフレームワーク（エージェント間連携の基盤部分を担うソフトウェアライブラリ）によって異なりますが、中核となる仕組みは共通しています。

オーケストレーションシステムの構成要素

どのオーケストレーションシステムにも、共通の構成要素があります。それぞれが実際のクラウドインフラに直接対応しており、これがオーケストレーションをクラウドセキュリティの課題にしている理由です。

セキュリティの観点では、各構成要素は単なるアプリケーションロジックではありません。それぞれが権限を持つIDであり、到達可能なデータパスの集合であり、攻撃者にとっての潜在的な足がかり（ピボットポイント）でもあります。オーケストレーションのセキュリティを理解するには、構成要素をinventoryとして洗い出すだけでなく、それらの関係性をマッピングする必要があります。

オーケストレーターは、コンピューティングサービス上で動作します。サブエージェントは通常、クラウドID（たとえばAWSのIAMロール、AzureのマネージドID、GCP／Kubernetesのサービスアカウント）で実行され、このIDはデプロイアーキテクチャに応じて共有される場合もあれば、エージェントごとに割り当てられる場合もあります。ツールは外部APIを呼び出します。共有メモリは多くの場合、vector databaseやオブジェクトストアに格納されます。この表のすべての構成要素には、クラウドIDと一連の権限が紐付いています。

オーケストレーションのライフサイクル

ライフサイクルは5つの段階で進みます。ただし、2番目から4番目のステップは、runtimeに動的に行われることがよくあります。

• タスク分解：オーケストレーターが目標を受け取り、サブタスクに分解して、関与させるエージェントを決定します。

• エージェントの選択と委任：オーケストレーターが、各専門エージェントの能力と稼働状況に基づいてサブタスクを割り当てます。

• 実行とデータフロー：エージェントがタスクを実行し、outputsをオーケストレーターに戻すか、下流のエージェントに直接渡します。ツールは必要に応じて呼び出されます。

• 状態管理とcontextの共有：オーケストレーターが共有状態を維持するため、エージェントはcontextを失うことなく互いの作業を引き継げます。

• 結果の集約とフィードバック：オーケストレーターがoutputsを収集し、結果を検証してエラーを処理し、最終的な成果を返します。フィードバックループは、以降の実行に活かされます。

重要なのは、オーケストレーターが固定のスクリプトではなく、中間結果に基づいて実行パスを決定する点です。この非決定性により、オーケストレーションされたシステムは強力になる一方で、予測やテスト、そしてruntimeでの保護が難しくなります。

AIエージェントオーケストレーションパターンの種類

オーケストレーションパターンは、エージェントをどのように連携させるかを表します。ほとんどの本番システムは複数のパターンを組み合わせています。選択したパターンはデータの流れ方とエージェント間の通信可否を決めるため、セキュリティ上の攻撃対象領域に直接影響します。

逐次型オーケストレーション

エージェントが、定められた順序で1つずつタスクを実行します。あるエージェントのoutputsが、次のエージェントに渡されます。ドキュメント処理pipelinesのような直線的なワークフローに最適ですが、並列化できる作業には時間がかかります。

• 例：抽出エージェントがデータを取り出し、分類エージェントがラベルを付け、レポートエージェントが最終的なoutputsを生成するcomplianceレビューのpipelineです。

並行型オーケストレーション

複数のエージェントが同時にタスクを実行し、オーケストレーターが結果を収集して突き合わせます。複数のデータソースへの同時クエリのような、独立したタスクに最適です。処理は速くなりますが、outputsが食い違った場合の競合解決が必要です。

• 例：3つの外部フィードに並列でクエリを送り、結果を統合するthreat intelligenceワークフローです。

階層型オーケストレーション

最上位のオーケストレーターが中間層のオーケストレーターに委任し、中間層の各オーケストレーターが自身のサブエージェントを管理します。複数の領域にまたがる複雑なワークフローに有用ですが、レイテンシーと連携のオーバーヘッドが増えます。

• 例：最上位のオーケストレーターが、ネットワーク、アイデンティティ、アプリケーションの各領域を担当する個別のオーケストレーターにタスクを振り分ける、エンタープライズのIT運用システムです。

イベント駆動型オーケストレーション

エージェントは、オーケストレーターからの明示的な指示ではなく、イベントをきっかけに起動します。あるエージェントが結果を発行すると、それをサブスクライブしている下流のエージェントが反応します。疎結合でscalabilityに優れますが、実行フローの追跡や障害のデバッグは難しくなります。

• 例：検出エージェントが検出結果を発行すると、エンリッチメントエージェントと通知エージェントがそれぞれ独立して起動する、セキュリティアラートのpipelineです。

フェデレーション型オーケストレーション

複数の自律的なオーケストレーターが組織やシステムの境界を越えて連携し、それぞれが自身のエージェントプールを管理します。チーム横断のワークフローに有用ですが、信頼、データ共有、governanceの課題が生じます。

• 例：2つの事業部門がそれぞれ独自のオーケストレーションされたエージェントシステムを運用し、レポートを集約するために共通のAPIを通じて結果を共有するケースです。

AIエージェントオーケストレーションのメリット

オーケストレーションの価値は、エージェントシステムの規模が大きくなるほど高まります。特に重要な成果は次のとおりです。

• 単一エージェントでは扱えない複雑さに対応できる：複数のステップや領域にまたがるタスクは、単一のmodelが確実に処理できる範囲を超えます。オーケストレーションにより、こうしたタスクを扱いやすいサブタスクに分解し、専門エージェントに振り分けられます。

• エージェントの機能を個別に拡張できる：システム全体を再設計することなく、個々のエージェントを追加、置き換え、アップグレードできます。より優れた要約modelを導入する場合も、取得エージェントやアクションエージェントに手を加える必要はありません。

• 長時間実行されるワークフロー全体でcontextを維持できる：共有状態の管理により、エージェントはそれまでの経緯を見失いません。これは、複数ターンにわたる顧客対応や段階的なデータ分析に欠かせません。

• タスクの分離により信頼性を高められる：あるエージェントが失敗しても、オーケストレーターはワークフロー全体を停止させることなく、再試行、経路変更、段階的な機能縮退によって対応できます。

• 自然な形で監査証跡を残せる：オーケストレーションを一元化することで、すべての委任、ツール呼び出し、データ交換を記録するポイントが生まれます。これは、complianceとインシデント調査において重要です。

AIエージェントオーケストレーションにおけるセキュリティリスク

エージェントオーケストレーションに関する議論の多くは、セキュリティを補足的な扱いにとどめています。しかし実際には、オーケストレーションされたエージェントは、最新のcloud environmentの中でも特に複雑な攻撃対象領域を生み出します。マルチエージェントアーキテクチャは攻撃対象領域を拡大させ、単一ノードの侵害が下流のエージェントのcontextやアクションを汚染する「信頼の連鎖（trust cascade）」を引き起こします。攻撃者があるエージェントのoutputsを操作すると、その改ざんされたデータが依存するエージェントに流れ込み、オーケストレーションチェーン全体に影響が及ぶ可能性があります。

攻撃者にとって価値の高い標的となるオーケストレーター

オーケストレーターは、どのエージェントを呼び出し、どのツールを使い、どのデータにアクセスするかを決定します。リスクは、オーケストレーターが使用するツールを判断する際に、自然言語の入力に依存している点にあります。これによりprompt injectionに対するexposureが生じ、研究環境では、悪意のあるpromptや細工されたドキュメントでエージェントの意思決定を操作した場合に最大71%の攻撃成功率が確認されています。実環境での成功率は、modelの防御機能、入力検証、guardrailの実装によって異なります。

具体的には、次のように展開します。prompt injection攻撃が、顧客向けのエージェントインターフェースを標的にします。注入された指示はオーケストレーターに届き、オーケストレーターは個人識別情報（PII）を含む社内ナレッジベースへの読み取り権限を持つサブエージェントに、「社内ドキュメントの要約」タスクを委任します。サブエージェントは指示どおりに機密性の高いコンテンツを取得して返します。単独で見ればmisconfigurationのあるコンポーネントは1つもなく、リスクは組み合わせによって生じたのです。

エージェントのアイデンティティと権限の連鎖

オーケストレーションチェーン内の各エージェントは、アクセスできるクラウドのresourceを決定するクラウドID（IAMロール、サービスアカウント）で実行されます。オーケストレーターがサブエージェントに委任する場合、そのエージェントが侵害されたときのblast radiusは、サブエージェントの権限によって決まります。

開発者はタスクの失敗を防ぐために、エージェントに広範で静的な権限を付与しがちです。その結果、過剰な権限を持つアクセスが生まれ、保護されていない大きなblast radiusにつながることがよくあります。オーケストレーションされたシステムでは、こうした過剰な権限を持つロールがチェーン内のすべてのエージェントで増えていきます。注文データを取得するエージェントに、resourceを限定しないs3:*やsecretsmanager:GetSecretValueは必要ありません。

過剰な権限を持つエージェントIDのリスク低減策

• 必要最小限の権限にスコープを限定した、エージェントごとの独自IDの割り当て（「読み取り専用の取得」操作と「書き込み／アクション」操作でロールを分離）

• 各エージェントが呼び出せるツールを制限する、ツールの許可リスト（ホワイトリスト）の導入

• 静的なAPIキーではなく、有効期間の短い認証情報を用いたsecretsブローカリングの利用

• 送信先を承認済みドメインに制限するエグレス制御の設定

• すべてのエージェントとツールの呼び出しにまたがるcorrelation IDを付与した、構造化された監査ログの有効化

ツール呼び出しとRAGを通じたデータのexposure

オーケストレーションされたエージェントは、ツール呼び出しを通じてdatastore、vector database、検索拡張生成（RAG）のナレッジベース、外部APIに頻繁にアクセスします。どのツールを呼び出すかはオーケストレーターが決定しますが、ツールが返すデータはエージェントのcontextに戻り、ユーザーや下流のエージェントに提示される可能性があります。

各エージェントがどのデータに到達できるのか、そしてそのデータが機密性の高いものか、分類済みか、規制対象かについてのvisibilityがなければ、侵害されたオーケストレーションワークフローの真の影響をチームが評価することはできません。

オーケストレーションフレームワークにおけるsupply chainのリスク

オーケストレーションフレームワーク（LangGraph、CrewAI、AutoGen）、MCPサーバーの実装、modelプロバイダー、embeddingライブラリ、vector databaseクライアントは、深いdependenciesの連鎖を形成しています。引用した研究の時点で、エコシステムには1,360のMCPサーバーにまたがる12,000以上のツールが存在すると報告されています。こうした実装はいずれもコードであり、dependenciesの脆弱性、悪意のあるパッケージ、安全でないデフォルト設定など、従来のソフトウェアsupply chainのリスクを抱えています。公開されているMCPサーバーの実装を分析した研究者は、43%にコマンドインジェクションの欠陥があり、30%が無制限のURLフェッチを許可していることを明らかにしました。共有ライブラリのデシリアライゼーションの脆弱性や悪意のあるMCPサーバーが1つあるだけで、オーケストレーショングラフ全体が侵害されるおそれがあります。

shadow AIとgovernanceの及ばないエージェントの増殖

開発者は、マネージドクラウドサービスを使ってオーケストレーションされたエージェントワークフローを立ち上げ、社内のdatastoreに接続し、APIを通じて公開できます。しかも多くの場合、それはセキュリティチームのvisibilityの外で行われます。こうしたシステムを保護するには、エージェントとオーケストレーションツールに加え、それらのエージェントがアクセスできる統合、権限、データまで含めたエージェントの完全なinventoryを作成する必要があります。

Synthesiaのセキュリティチームは、この課題を身をもって経験しました。contextのないアラートに追われていたチームには、AIを活用した環境全体で本当に重要なリスクを把握する手段が必要でした。Wizによってcontextに基づき優先順位付けされたvisibilityを得たことで、チームはnoiseを追いかけるのではなく、実際の脅威に集中できるようになりました。

エージェントオーケストレーションのデプロイでよくある落とし穴

以下は、オーケストレーションされたエージェントをプロトタイプから本番環境へ移行する際に、チームが陥りがちな失敗です。

• オーケストレーションを決定論的なものとして扱う：オーケストレーションされたエージェントは、runtimeに判断を下します。正常系（ハッピーパス）だけをテストすると、予期しない入力で現れる創発的な動作を見逃します。デプロイ前のテストだけでなく、runtimeモニタリングが必要です。

• エージェントに開発者と同じ権限を付与する：エージェントの実行ロールは、least privilegeに従う必要があります。注文データを取得するエージェントに、注文databaseへの書き込み権限は必要ありません。

• エージェント間通信のオブザーバビリティ（可観測性）を確保しない：オーケストレーションチェーン全体のログ記録とトレースがなければ、障害のデバッグやセキュリティインシデントの調査は手探りになります。

• 共有contextのblast radiusを無視する：エージェントが共通のメモリストアを通じて状態を共有している場合、侵害されたエージェントや誤動作したエージェントが、下流のすべてのエージェントのcontextを汚染する可能性があります。

• エージェントの機能のinventoryがないままデプロイする：どのエージェントが存在し、どのツールを呼び出せて、どのデータにアクセスし、どの権限を持っているのかを把握していなければ、自組織のexposureを評価できません。これは、shadow ITのエージェント版です。

• ツールの許可リストを強制しない：エージェントが制限なく任意のツールを動的に呼び出したり、任意のMCPサーバーに接続したりできる状態では、オーケストレーションが際限のない実行基盤になってしまいます。エージェントごとに許可するツールの明示的な許可リストを定義し、実行前にツールの引数を検証してください。

AIエージェントオーケストレーションと関連概念の違い

AIエージェントオーケストレーションと重なり合う用語はいくつかあり、検索クエリでも混同されがちです。次の表で、それぞれの違いを整理します。

実際には、ほとんどのエンタープライズのAIシステムがこれらの概念を組み合わせています。オーケストレーションされたエージェントシステムでは、バッチジョブのスケジューリングにAirflow、modelの更新にMLOpsのpipelines、real-timeで適応的なワークフローの処理にエージェントオーケストレーションを使うことがあります。セキュリティ上の課題は、各レイヤーがそれぞれ独自のID、権限、データアクセスパターンを持ち込む点にあります。

WizによるAIエージェントオーケストレーションの保護

AIエージェントを保護するには、コード、クラウド、アイデンティティ、データ、runtimeを横断した統合的なビューが必要です。Wiz AI-Application Protection Platform（AI-APP）は、この単一の共有ビューを提供し、チームが実際のリスクを迅速に低減できるよう支援します。

Wizがオーケストレーションワークフローの各段階をどのように保護するかを紹介します。

• 構築（Wiz Code）：リポジトリとCI/CD pipelinesをスキャンし、ハードコードされたsecrets、範囲が広すぎるエージェント定義、安全でないMCP統合を、本番環境に到達する前に検出します。

• デプロイ（Wiz AI-SPM）：shadow AIを含むAIフットプリント全体を自動的に検出し、inventoryを作成します。AI-BOM（AI版部品表）を生成してdependenciesをマッピングし、クラウドホスティングのmisconfigurationを指摘します。

• 接続（Wiz Security Graph）：孤立したsignalを結び付け、contextを生み出します。完全なチェーン（例：公開されたendpointから、PIIにアクセスする過剰な権限を持つエージェントへとつながる経路）をマッピングすることで、悪用可能なattack pathを生む有害な組み合わせ（toxic combinations）を自動的に洗い出します。

• 実行（Wiz Defend）：クラウドイベントとruntimeのtelemetryのcorrelationにより、prompt injection、不正なアクション、権限のないデータアクセスなどの異常を検出します。インラインでのトラフィック検査は必要ありません。

実証された効果：PROSのチームは、19のセキュリティツールをWizにconsolidationし、Security Graphを活用して開発者がattack pathを理解できるようにしたことで、90日以内にすべてのクリティカルな問題を解消しました。

最初のオーケストレーションワークフローを保護する場合でも、本番環境で数百のエージェントを管理する場合でも、Wizは統合されたvisibilityを提供し、AIスタック全体のリスクを把握して低減できるようにします。

AIエージェントのオーケストレーションに伴うクラウド、アイデンティティ、データ、runtimeのリスクを可視化し、優先順位付けする方法をWizでご確認ください。 Wizのデモを見る

よくある質問