Microsoft Foundry / Azure OpenAIで「複数のAIエージェントをどう業務フローに組み込むか」を検討しているなら、2026年4月更新でまず確認すべきは Workflows です。Workflowsは、エージェント、分岐、変数、人の承認などをUI上で組み合わせ、定型的な処理手順として実行できるMicrosoft Foundryの機能です。単発のチャット応答ではなく、「分類する」「確認する」「承認を待つ」「次の担当エージェントへ渡す」といった業務プロセスを作りたい場合に向いています。Microsoft Learnの該当ページは現行表示で2026年4月28日が最終更新日となっており、2026年4月下旬の更新として確認しておくのが安全です。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIの最新動向として押さえるべきポイント
Microsoft Foundryは、エージェント、モデル、ツールを統合して扱うAzure上のAI開発・運用プラットフォームです。Microsoftの公式説明では、AIアプリケーション開発だけでなく、RBAC、ネットワーク、ポリシー、トレーシング、評価、監視などを含むエンタープライズ向けの管理基盤として位置づけられています。Azure OpenAIから移行する場合も、エンドポイントやAPIキー、既存状態を保持したままFoundryリソースへアップグレードできる導線が案内されています。(Microsoft Learn)
今回の「Build a workflow in Microsoft Foundry」で重要なのは、AIエージェントを単体で作る段階から、複数エージェントを業務の順番に沿って動かす段階へ進みやすくなった点です。Workflowsは、UIベースのビジュアルビルダーで宣言的なアクション列を作り、エージェントと業務ロジックをオーケストレーションする機能として説明されています。(Microsoft Learn)
| 観点 | 2026年4月更新で見るべきポイント | 実務上の意味 |
|---|---|---|
| ワークフロー設計 | UI上でエージェント、分岐、変数、チャット処理を組み合わせられる | 開発者だけでなく、業務担当者・プロダクトオーナーも処理の流れを確認しやすい |
| マルチエージェント | 複数の専門エージェントを順番または条件に応じて呼び出せる | 問い合わせ対応、申請審査、調査、レビューなどを段階化できる |
| Human in the loop | 承認や追加質問など、人が介在するステップを作れる | AIに全自動化させにくい業務でも導入しやすい |
| Power Fx | Excelライクな式で条件分岐や変数操作ができる | コードを書かずに判定ロジックを作れる |
| YAML・バージョン管理 | ビジュアル編集とYAML編集、保存ごとのバージョン履歴に対応 | レビュー、差分確認、運用管理がしやすい |
Workflowsは何を解決する機能なのか
Workflowsの本質は、「AIに答えさせる」機能ではなく、AIエージェントを業務プロセスの部品として並べる機能です。
たとえば、カスタマーサポート業務では次のような流れが考えられます。
- ユーザーの問い合わせを受け取る
- 問い合わせ内容を分類する
- 契約情報やナレッジを参照する
- 回答案を作成する
- 重要度が高い場合は人間の承認を待つ
- 承認済みの回答を送信する
このような処理は、単体のチャットボットにまとめるとプロンプトが肥大化し、失敗時の原因も追いにくくなります。Workflowsを使うと、分類エージェント、調査エージェント、回答作成エージェント、承認ステップを分けて設計できます。
特にIT adminsやプロダクトオーナーにとって大きいのは、処理の流れがUI上で見えることです。業務部門から「この条件では承認を必須にしたい」「この回答は別の担当者に回したい」といった要望が出たとき、ブラックボックス化したプロンプトではなく、ノード単位で議論できます。
Microsoft FoundryとAzure OpenAIの関係を整理する
Azure OpenAI利用者が混乱しやすいのは、「Azure OpenAIのモデル利用」と「Microsoft Foundryでのエージェント・ワークフロー管理」が同じではない点です。
MicrosoftのSDK説明では、Foundryリソースはモデル、エージェント、ツールへの統合アクセスを提供します。一方、Azure OpenAIリソースは主に/openai/v1エンドポイントを提供する位置づけです。Foundry SDKはエージェントや評価などFoundry固有機能を扱う場合に向き、OpenAI SDKはOpenAI互換性を重視する場合に向くと整理されています。(Microsoft Learn)
| やりたいこと | 向いている選択肢 | 判断基準 |
|---|---|---|
| 既存アプリからモデルを呼び出したい | Azure OpenAI / OpenAI SDK | Chat CompletionsやResponses API中心で、アプリ側に処理ロジックを持つ |
| エージェントを作り、評価や運用も含めて管理したい | Microsoft Foundry | プロジェクト、RBAC、監視、評価、ツール連携をまとめて扱いたい |
| 複数エージェントを業務手順として動かしたい | Microsoft Foundry Workflows | UIで分岐、変数、承認、複数エージェントを組み合わせたい |
| コードで細かくマルチエージェント制御したい | Agent Framework | ローカルまたはコードベースでオーケストレーションを作り込みたい |
既存のAzure OpenAI利用者は、すぐにすべてをFoundryへ移す必要はありません。まずは「単純なモデル呼び出し」と「業務プロセスとして管理したいAI処理」を分けるのが現実的です。前者は既存APIで継続し、後者をFoundry Workflowsで検証すると、移行リスクを抑えやすくなります。
Workflowsで選べる3つの基本パターン
Microsoft FoundryのWorkflowsでは、代表的なオーケストレーションパターンとして、Human in the loop、Sequential、Group chatが示されています。(Microsoft Learn)
| パターン | 内容 | 向いている業務 |
|---|---|---|
| Human in the loop | ユーザーへの質問や人間の承認を待って次へ進む | 稟議、例外承認、法務確認、重要顧客への回答前レビュー |
| Sequential | あるエージェントの結果を次のエージェントへ順番に渡す | 問い合わせ分類、要約、調査、回答生成などの段階処理 |
| Group chat | 文脈やルールに応じてエージェント間で制御を渡す | 専門家エージェントへの振り分け、エスカレーション、フォールバック |
最初に試すなら、Sequentialがおすすめです。理由はシンプルで、入力、処理、出力の流れが追いやすく、失敗箇所を特定しやすいからです。Human in the loopは、AIの判断に人間の確認を挟みたい業務に向いています。Group chatは柔軟ですが、設計が曖昧だとどのエージェントが責任を持つのか分かりにくくなるため、ルール設計が重要です。
実務での活用シーン
問い合わせ一次対応の自動化
サポート窓口では、問い合わせ内容の分類、ナレッジ検索、回答案作成、承認を一連の流れにできます。
例として、次のような設計が考えられます。
| ステップ | 担当ノード | 役割 |
|---|---|---|
| 問い合わせ受付 | Basic chat | ユーザーから質問を受け取る |
| 内容分類 | Agent | 障害、契約、操作方法、要望などに分類する |
| 条件分岐 | Logic | 障害や返金など重要カテゴリなら承認ルートへ進める |
| 回答案生成 | Agent | FAQや社内ナレッジをもとに回答案を作る |
| 承認確認 | Human in the loop | 送信前に担当者が確認する |
この構成にすると、AIの出力をそのまま顧客へ返すのではなく、人間の確認ポイントを設けられます。金融、医療、公共、BtoBサポートなど、誤回答の影響が大きい領域では特に重要です。
プロダクト要求の整理
プロダクトオーナー向けには、顧客要望や営業メモを整理するワークフローも有効です。
たとえば、入力された要望を「既存機能で対応可能」「新機能候補」「仕様確認が必要」「サポート案件」に分類し、新機能候補だけを別エージェントに渡して、影響範囲、想定ユーザー、優先度、確認事項を出力させます。
この場合、Workflowsの価値は自動化そのものよりも、判断の型を標準化できることにあります。属人的にメモを読むのではなく、同じ基準で分類・要約・エスカレーションできるため、ロードマップ検討の材料をそろえやすくなります。
社内申請・承認フロー
Human in the loopは、社内申請との相性が高いパターンです。
たとえば、SaaS利用申請を受け付け、AIが目的、利用部署、データ種別、外部共有有無を整理します。個人情報や機密情報を扱う場合は、IT管理者またはセキュリティ担当の承認ステップへ進めます。承認不要の低リスク申請は、標準回答を返すように設計できます。
ここで大切なのは、AIに最終判断を任せすぎないことです。Workflowsは「AIで人を置き換える」ためだけでなく、「人が判断すべき箇所を明確にする」ためにも使えます。
Workflowsの作成手順
Microsoft Learnでは、Sequential workflowを例に、Microsoft Foundryポータルでの作成手順が示されています。大まかな流れは、Foundryにサインインし、New Foundryを有効にした状態でBuildから新しいワークフローを作成し、エージェントを割り当て、保存して実行するというものです。重要な注意点として、Foundryはワークフローを自動保存しないため、変更後は都度Saveを選ぶ必要があります。(Microsoft Learn)
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Foundryにサインイン | 対象プロジェクトを間違えていないか |
| 2 | Buildを開く | New Foundry側の画面で作業しているか |
| 3 | Create new workflowからSequentialなどを選択 | 最初はSequentialで小さく始める |
| 4 | Agentノードに既存または新規エージェントを割り当てる | 各ノードの目的が重複していないか |
| 5 | Saveする | 自動保存されないため必ず保存する |
| 6 | Run Workflowで実行 | 各ノードが完了しているか |
| 7 | チャット画面で応答を確認 | 想定どおりの出力か、変数が正しいか |
| 8 | 必要に応じてノードを追加 | 分岐や承認を増やしすぎない |
最初から大きな業務フローを作るのは避けましょう。おすすめは、2〜3ノードだけの小さなワークフローで「入力→分類→回答案」までを作り、出力品質と運用上の問題を確認してから承認や分岐を追加する進め方です。
ノード設計で押さえるべき考え方
Workflowsのノードは、処理の部品です。公式ドキュメントでは、Agent、Logic、Data transformation、Basic chatなどのノード種別が説明されています。(Microsoft Learn)
| ノード種別 | 役割 | 設計のコツ |
|---|---|---|
| Agent | エージェントを呼び出す | 1エージェントに複数の責務を持たせすぎない |
| Logic | if/else、go to、for eachなどを扱う | 分岐条件を業務ルールとして明文化する |
| Data transformation | 変数設定や値の解析を行う | 後続ノードが使いやすい形式に整える |
| Basic chat | メッセージ送信や質問を行う | ユーザー入力を明確に取得する |
失敗しやすいのは、1つのAgentノードに「分類、検索、回答、承認判定」まで詰め込む設計です。これでは、出力が期待と違ったときに、どこで誤ったのか分かりません。
実務では、次のように責務を分けると管理しやすくなります。
- 分類エージェント：入力をカテゴリ化する
- 調査エージェント：必要な情報を集める
- 生成エージェント：回答案や要約を作る
- レビュー用ステップ：人の承認や追加質問を扱う
エージェント名も「Agent1」「SupportAgent」のような曖昧な名前ではなく、「問い合わせ分類」「契約リスク判定」「回答案生成」のように、業務上の役割で付けるとレビューしやすくなります。
JSON Schemaと変数は本番運用の鍵になる
Workflowsでは、エージェントの出力をJSON Schemaとして構造化し、変数に保存できます。これは本番運用で非常に重要です。自然文のまま次のノードへ渡すと、後続処理が安定しにくくなります。分類結果、重要度、要約、次アクションなどは、できるだけ構造化して渡すべきです。
たとえば、問い合わせ分類では次のような出力形式を考えられます。
{
"name": "support_ticket_summary",
"schema": {
"type": "object",
"properties": {
"category": { "type": "string" },
"priority": { "type": "string" },
"summary": { "type": "string" },
"next_action": { "type": "string" }
},
"required": ["category", "priority", "summary", "next_action"],
"additionalProperties": false
},
"strict": true
}このようにしておくと、後続のLogicノードで「priorityがhighなら承認へ進む」「categoryがbillingなら請求担当エージェントへ渡す」といった処理を作りやすくなります。
ただし、JSON Schema、プロンプト、保存済み変数にパスワード、キー、トークンなどの機密情報を含めてはいけません。Microsoft Learnでも、これらにシークレットを含めないよう明記されています。(Microsoft Learn)
Power Fxで条件分岐と変数操作を作る
Workflowsでは、Power Fxを使って条件分岐や変数操作を行えます。Power FxはExcelに近い式体系を持つローコード言語で、変数の値を設定したり、文字列を解析したり、条件を評価したりする用途に使えます。変数を参照する際は、システム変数にはSystem.、ローカル変数にはLocal.のプレフィックスを付ける必要があります。(Microsoft Learn)
たとえば、ユーザーの名前を大文字にして出力するような処理では、ローカル変数を使って次のような考え方で式を作れます。
{Upper(Local.customerName)}条件分岐では、次のような設計が考えられます。
If(Local.priority = "high", "approval_required", "auto_reply")実務では、Power Fxを使う前に「どの値を変数に保存するか」を決めることが重要です。分類結果をcategory、重要度をpriority、承認要否をapprovalRequiredのように明確にしておくと、式が読みやすくなります。
よくある失敗は、変数名のスコープを付け忘れることです。priorityだけではなく、ローカル変数ならLocal.priorityのように参照します。型の不一致も起きやすいため、文字列、数値、真偽値を混在させないようにしましょう。
Hosted agents利用時の注意点
2026年4月更新で特にIT管理者が見落としやすいのが、Hosted agentsとWorkflow designerの関係です。
Microsoft Learnでは、Hosted agentsはworkflow designerでサポートされていないと説明されています。Hosted agent内で他のエージェントを呼び出したり、ワークフローをオーケストレーションしたりする場合は、Microsoft Agent Framework workflowsまたは同等のワークフロー機能を持つエージェントフレームワークを使う案内になっています。(Microsoft Learn)
つまり、UIベースで業務フローを組みたいならWorkflows、コンテナ化された独自コードで細かく制御したいならHosted agentsやAgent Framework、と使い分ける必要があります。
| 要件 | Workflows向き | Hosted agents / Agent Framework向き |
|---|---|---|
| 業務担当者も流れを確認したい | はい | 限定的 |
| 承認、分岐、変数をUIで設計したい | はい | コード実装が中心 |
| 独自フレームワークや複雑な実行制御が必要 | 限定的 | はい |
| コンテナ化した自社コードを動かしたい | いいえ | はい |
| まずPoCを短期間で作りたい | はい | 要件次第 |
プロダクトオーナー視点では、「どちらが高機能か」ではなく、「誰が保守するのか」で判断するのが現実的です。業務部門と一緒に流れを改善するならWorkflows、開発チームがコードで継続的に改善するならAgent Framework側が向いています。
IT adminsが確認すべき権限とガバナンス
Workflowsを組織で使う場合、最初に確認すべきはRBACです。Microsoft FoundryのRBACドキュメントでは、Entra ID認証を使う場合にロールが適用され、キー認証ではロール制限なしにフルアクセスを許可するため、セキュリティと細かなアクセス制御の観点からEntra ID認証が推奨されています。(Microsoft Learn)
また、Foundryの権限設計では、Foundry resourceとFoundry projectというスコープを分けて考える必要があります。Azure AI User、Azure AI Project Manager、Azure AI Account Owner、Azure AI Ownerなどの組み込みロールが用意されており、開発者、チームリード、管理者で役割を分ける設計が可能です。(Microsoft Learn)
Workflows導入時のチェックポイントは次のとおりです。
| 項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| RBAC | 作成者、編集者、閲覧者の範囲を決める | 誰でもワークフローを変更できる |
| Entra ID認証 | APIキー依存を避けられるか確認する | キー漏えい時の影響範囲が広がる |
| 変数とプロンプト | シークレットや個人情報を保存しない設計にする | 機密情報がワークフロー内に残る |
| バージョン管理 | 変更履歴を確認し、ロールバック方針を決める | 変更後の不具合原因を追いにくい |
| 監視・評価 | 期待出力、失敗条件、承認条件を定義する | PoCのまま本番投入される |
特に、プロダクト部門がワークフローを編集できる場合でも、接続先、認証、外部データ利用、ログ保存についてはIT管理者が基準を作るべきです。AIワークフローは便利ですが、通常のアプリケーションと同じく権限管理と変更管理が必要です。
よくある失敗と対処法
Microsoft Learnのトラブルシューティングでは、Workflowsが表示されない、変更が反映されない、予期しない出力になる、Power Fxで名前や型のエラーが出る、タイムアウトする、といった問題が整理されています。(Microsoft Learn)
| 失敗例 | 原因 | 対処法 |
|---|---|---|
| Workflowsの項目が見えない | 権限不足や対象プロジェクトの違い | プロジェクトのRBACと作業中のFoundryプロジェクトを確認する |
| 変更したはずなのに反映されない | Saveしていない | Foundryは自動保存しないため、変更ごとにSaveする |
| エージェントが期待どおり動かない | ノードにエージェントが割り当てられていない、プロンプトが曖昧 | 各Agentノードの割り当てと責務を確認する |
| JSON出力が後続処理で使えない | Schemaが曖昧、必須項目が不足 | requiredと型を明確にし、テスト入力で検証する |
| Power FxでName isn’t validが出る | System.やLocal.の付け忘れ | 変数スコープを明示する |
| Type mismatchが出る | 文字列、数値、真偽値の型が合っていない | Text()やValue()などの変換を検討する |
| 実行がタイムアウトする | ワークフローが複雑すぎる、外部サービスが遅い | 処理を小さく分割し、外部呼び出しの待ち時間を確認する |
本番に近い検証では、「うまくいく入力」だけでなく、「曖昧な入力」「空の入力」「権限がないユーザーの入力」「長文の入力」「誤分類しやすい入力」を試す必要があります。AIワークフローはデモでは動いても、例外処理を作っていないと運用で詰まりやすくなります。
導入前に決めておくべき設計基準
Microsoft Foundry Workflowsを使い始める前に、次の5点を決めておくと失敗しにくくなります。
| 設計項目 | 決めること | 例 |
|---|---|---|
| 対象業務 | 何を自動化・半自動化するか | 問い合わせ一次対応、申請レビュー、要望分類 |
| 成功条件 | 何ができれば成功か | 分類精度、承認時間短縮、回答案作成時間の削減 |
| 人の関与 | どこで承認や確認を入れるか | 高リスクカテゴリだけ承認必須 |
| データ形式 | どの出力をJSONで保存するか | category、priority、summary、next_action |
| 運用責任 | 誰が変更、監視、改善するか | IT管理者、業務責任者、開発チーム |
独自性を出すなら、最初から「AIに何をさせるか」ではなく、「人が判断すべき箇所をどこに残すか」から設計するのがおすすめです。承認ポイントが明確なワークフローは、業務部門にも説明しやすく、監査や改善もしやすくなります。
まず取るべき次のアクション
Microsoft Foundry / Azure OpenAIをすでに使っている組織は、次の順番で確認するとよいでしょう。
- 既存のAzure OpenAI利用のうち、単純なモデル呼び出しと業務フロー化したい処理を分ける
- Microsoft Foundry側で対象プロジェクト、RBAC、利用できるモデルとエージェントを確認する
- Sequential workflowで小さな検証を作る
- JSON Schemaで出力を構造化し、後続ノードで使えるか確認する
- Human in the loopを追加し、人の承認が必要な条件を明確にする
- 保存、バージョン履歴、権限、シークレット管理を確認してから本番候補にする
2026年4月更新の「Build a workflow in Microsoft Foundry」は、単なる操作手順の追加ではなく、Microsoft Foundryを業務プロセスの実行基盤として使うための重要な入口です。Azure OpenAIでモデル利用を始めた組織ほど、次の段階では「AIを呼び出す」だけでなく、「AIエージェントをどう安全に業務へ組み込むか」が課題になります。まずは小さなSequential workflowを作り、入力、分岐、構造化出力、承認の4点を確認するところから始めるのが現実的です。
コメント