Azure AI Foundryで複数のAIエージェントを業務プロセスに組み込みたい場合、まず確認すべき機能が「Workflows」です。Workflowsは、Microsoft Foundry上でエージェント、条件分岐、変数、承認ステップなどをビジュアルに組み合わせるUIベースのワークフロー機能です。結論から言うと、今回の「Build a workflow in Microsoft Foundry」は既存の単一エージェントをただちに置き換えるものではありません。繰り返し実行する業務手順を、より管理しやすく、テストしやすい形でオーケストレーションするための機能として捉えるのが実務的です。(Microsoft Learn)
管理者は、Foundryプロジェクトの権限、New Foundryの利用、クラシックポータルからの移行、Hosted agentsの扱いを確認する必要があります。開発者は、ワークフローの保存・バージョン管理、JSON出力、Power Fx、変数スコープ、タイムアウト時の分割設計を事前に押さえておくと、導入時の手戻りを減らせます。(Microsoft Learn)
Azure AI FoundryとMicrosoft Foundryの関係
現在の公式ドキュメントでは、Azure AI Foundryは「Microsoft Foundry」という名称で整理されています。Microsoftの説明では、AIプラットフォームの名称はAzure AI StudioからAzure AI Foundry、そして現在のMicrosoft Foundryへ進化したとされています。一方で、Azureリソースの種類は引き続き Microsoft.CognitiveServices/accounts のままであり、名称変更だけを理由に既存リソースが別物になるわけではありません。(Microsoft Learn)
そのため、社内ドキュメントや設計書では次のように整理すると混乱を防げます。
| 表記 | 実務上の扱い |
|---|---|
| Azure AI Foundry | 旧称または従来の検索語として残りやすい名称 |
| Microsoft Foundry | 現在の公式ドキュメントで使われる名称 |
| Foundryプロジェクト | エージェント、モデル、ツール、ワークフローを管理する単位 |
| Foundryリソース | Azure上で管理される上位リソース |
検索や社内問い合わせでは「Azure AI Foundry Workflow」と呼ばれることが多くても、最新の公式手順では「Microsoft Foundry」「Workflows」と表記される点に注意しましょう。
Workflowsは何をする機能か
Workflowsは、Microsoft Foundryのビジュアルビルダーで、エージェントと業務ロジックを宣言的な手順として組み立てる機能です。単一のチャットボットにすべてを任せるのではなく、「分類する」「確認する」「別の専門エージェントに渡す」「人間の承認を待つ」といった処理を順番や条件に沿って制御できます。(Microsoft Learn)
たとえば、問い合わせ対応では次のような流れを作れます。
- ユーザーの問い合わせ内容を受け取る
- 分類用エージェントが「請求」「技術サポート」「契約変更」などに分類する
- 緊急度や信頼度に応じて、人間の確認ステップへ分岐する
- 回答生成エージェントが返信案を作る
- 必要に応じて承認後に回答を返す
このように、Workflowsは「AIに自由に考えさせる」ための機能というより、AIエージェントを業務フローに組み込むための制御レイヤーです。
公式情報で確認すべき主な変更点
今回の公式情報で重要なのは、Workflowsが複数エージェントのオーケストレーション、条件分岐、変数処理、人間を介した処理を視覚的に設計する機能として明確に整理されている点です。コードを書かずにif/elseや変数を扱える一方、YAML表示やVisual Studio Codeでの編集に進む選択肢も示されています。(Microsoft Learn)
| 確認ポイント | 内容 | 実務上の意味 |
|---|---|---|
| ワークフローの位置付け | UIベースの宣言型オーケストレーション | 単発のチャットではなく、繰り返し業務に向く |
| 対応パターン | Human in the loop、Sequential、Group chat | 承認、段階処理、専門エージェント間の連携を設計できる |
| 保存方法 | 自動保存ではない | 変更ごとにSaveしないと作業内容を失う可能性がある |
| バージョン管理 | 保存ごとに変更不可の新バージョンを作成 | 検証済み状態を残しやすいが、不要バージョンの整理も必要 |
| YAML表示 | YAML Visualizer Viewを有効化可能 | GUIと構成ファイルの両方で編集できる |
| JSON出力 | JSON Schema形式の応答を設定可能 | 後続ノードや外部処理に渡しやすい |
| Power Fx | 変数処理、文字列処理、条件評価に利用 | Excelライクな式でローコードに制御できる |
| Hosted agents | ワークフローデザイナーでは未サポート | Hosted agent内の制御はAgent Frameworkなどを使う必要がある |
特に見落としやすいのは、Hosted agentsがワークフローデザイナーではサポートされない点です。Hosted agentの中で他のエージェント呼び出しやワークフロー調整を行う場合は、Microsoft Agent Framework workflowsまたは同等のワークフロー機能を持つフレームワークを使う必要があります。(Microsoft Learn)
なお、GitHub上の公式ドキュメント履歴では、2026年5月12日に hosted agents を Hosted agents に表記統一するコミットが確認できます。日本時間では5月13日の更新として把握されるケースがありますが、このコミット自体は主に表記変更であり、ワークフロー機能そのものの仕様変更と混同しない方が安全です。(GitHub)
Workflowsが向いているケース、向いていないケース
Workflowsは、すべてのAIエージェント開発に必須ではありません。効果が出やすいのは、手順がある程度決まっており、判断や承認を含む業務です。
| 判断基準 | Workflowsが向いている | 単一エージェントでよい可能性が高い |
|---|---|---|
| 処理手順 | 毎回ほぼ同じ順序で進む | 会話内容によって自由に変わる |
| 関与する役割 | 分類、検索、回答、承認など複数の役割がある | 1つのエージェントで完結する |
| 人間の確認 | 承認、差し戻し、追加質問が必要 | すぐ回答してよい |
| 監査性 | どのノードで何が起きたか追いたい | 厳密な追跡は不要 |
| 出力形式 | JSONなど構造化データとして扱いたい | 自然文の回答だけでよい |
たとえば、社内FAQボットのように「質問を受けて回答する」だけなら、まずは単一エージェントで十分です。一方、経費申請の一次確認、問い合わせの部門振り分け、契約レビューのリスク判定、障害報告のエスカレーションなどは、Workflowsで段階的に設計した方が運用しやすくなります。
管理者が確認すべき設定
Workflowsを有効に活用するには、開発者に画面を触らせる前に、管理者側で権限とポータルの前提を整える必要があります。
Foundryプロジェクトのアクセス権
公式ドキュメントでは、ワークフローを作成・実行するにはFoundryプロジェクトで該当操作を行うアクセス権が必要とされています。トラブルシューティングでは、ワークフローオプションが表示されない、または作成・編集できない場合に、プロジェクトでContributorロール以上を確認するよう案内されています。(Microsoft Learn)
一方、Microsoft FoundryのRBACドキュメントでは、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerといったロール名が案内されています。これらは以前のAzure AI User、Azure AI Ownerなどから名称変更されたもので、ロールIDや中核権限は変更されていないと説明されています。(Microsoft Learn)
実務では、次の順で確認するとよいでしょう。
| 確認項目 | 見る場所 | 注意点 |
|---|---|---|
| ユーザーの権限 | Azure portalのAccess control（IAM）またはFoundryのAdmin画面 | 個人ではなくMicrosoft Entraグループで付与すると管理しやすい |
| プロジェクト単位の権限 | Foundryプロジェクト | リソース全体とプロジェクトで権限スコープが異なる |
| ロール名 | Foundry Userなどの新名称 | 旧名称が画面やスクリプトに残る可能性がある |
| ロールID | 自動化スクリプト | 名称変更中はGUID指定の方が安全な場合がある |
New Foundryと現在のポータルを使う
ワークフロー作成手順では、Microsoft Foundryにサインインし、New Foundryトグルがオンであることを確認してから、右上メニューのBuildを選択し、Create new workflowからSequentialなどを選ぶ流れが示されています。(Microsoft Learn)
クラシックポータルを使っている環境では、現在のFoundryポータルへ切り替えた上で、対象プロジェクトや機能が表示されるか確認してください。公式の移行ドキュメントでは、現在のポータルにはFoundryプロジェクトのみが表示され、ハブベースのプロジェクトなどはクラシックポータルに戻る必要がある場合があると説明されています。(Microsoft Learn)
シークレットをプロンプトや変数に入れない
Workflowsでは、JSON Schema、プロンプト、保存済みワークフロー変数を扱えます。ただし、公式ドキュメントはパスワード、キー、トークンなどのシークレットをJSONスキーマ、プロンプト、保存されたワークフロー変数に含めないよう明記しています。(Microsoft Learn)
これは単なる注意書きではありません。ワークフローはバージョン履歴を持つため、誤って秘密情報を保存すると、後から削除しても過去バージョンや監査ログの扱いが問題になる可能性があります。APIキーや接続情報は、Azure側の認証、接続設定、Key Vault、マネージドIDなどの管理された仕組みに寄せるべきです。
開発者が押さえるべき設計ポイント
まずはSequentialから始める
初めてWorkflowsを使う場合は、Sequentialパターンから始めるのが安全です。Sequentialは、あるエージェントの結果を次のエージェントへ順番に渡すパターンで、ステップごとの処理結果を確認しやすいからです。(Microsoft Learn)
たとえば、問い合わせ処理なら次のように分けます。
| ノード | 役割 | 出力例 |
|---|---|---|
| Ask a question | ユーザーから問い合わせを受け取る | 問い合わせ本文 |
| Invoke agent | 分類エージェントでカテゴリ判定 | billing、technical、contract |
| if/else | 緊急度やカテゴリで分岐 | 高リスクなら人間確認へ |
| Invoke agent | 回答案を生成 | 返信文案 |
| Send message | ユーザーへ返答 | 最終回答 |
この分割により、どの段階で誤分類したのか、どの出力が後続ノードに悪影響を与えたのかを確認しやすくなります。
JSON Schemaで後続処理に渡しやすくする
エージェントの出力を後続ノードで使うなら、自然文だけに頼らずJSON Schemaで構造化することを検討しましょう。公式手順では、エージェントにJSON Schema形式の出力を設定し、出力を変数として保存する流れが示されています。(Microsoft Learn)
たとえば、問い合わせ分類なら次のような項目を返す設計が考えられます。
{
"category": "technical",
"confidence": 0.86,
"requires_human_review": false,
"reason": "The user asks about an application error after deployment."
}このようにしておくと、confidence が低い場合だけ人間確認へ回す、category が billing の場合だけ請求担当エージェントへ渡す、といった条件分岐を作りやすくなります。
Power Fxではスコープの付け忘れに注意する
Workflowsでは、Power Fxを使って変数の設定、文字列の解析、条件評価などを行えます。Power Fxで変数を参照する場合、システム変数には System.、ローカル変数には Local. のプレフィックスが必要です。(Microsoft Learn)
よくある失敗は、変数名だけを書いて「名前が無効です」というエラーになるケースです。
| やりたいこと | 誤りやすい書き方 | 推奨される考え方 |
|---|---|---|
| ユーザー入力を大文字化 | Upper(Var01) | Upper(Local.Var01) のようにスコープを付ける |
| 会話情報を条件に使う | Conversation.Id | System.Conversation.Id のように参照する |
| 数値比較 | 文字列のまま比較 | 必要に応じて Value() などで型変換する |
Power Fxのエラーは、AIモデルの応答品質とは別問題です。プロンプト修正で解決しようとせず、変数名、スコープ、型を先に確認しましょう。
展開前に行うべき検証
ワークフローを作成したら、Run Workflowで実行し、各ノードの完了状況、チャットウィンドウの応答、保存した変数の値を確認することが推奨されています。(Microsoft Learn)
本番展開前は、少なくとも次の観点でテストしてください。
| テスト観点 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 正常系 | 想定どおり各ノードが完了するか | エージェント未割り当てのノードが残る |
| 分岐 | if/elseが期待どおり動くか | 変数の型が文字列と数値でずれる |
| JSON出力 | 必須項目が欠けないか | モデル出力がスキーマに合わない |
| 人間確認 | 承認・追加質問の流れが止まらないか | 誰が入力するのか運用ルールが曖昧 |
| タイムアウト | 外部サービス待ちで止まらないか | 長い処理を1つのワークフローに詰め込みすぎる |
| セキュリティ | 秘密情報が保存されていないか | プロンプトや変数にキーを直接書く |
| バージョン | どの版を検証済みにするか | 保存のたびにバージョンが増え、管理が曖昧になる |
特に「保存」は重要です。Foundryはワークフローを自動保存しないため、変更後にSaveを選択しないと、編集内容が残りません。(Microsoft Learn)
移行時の注意点
クラシックポータルや古いSDKを使っている環境では、Workflows単体だけでなく、Foundry全体の移行計画と合わせて確認する必要があります。
公式の移行ドキュメントでは、azure-ai-inference パッケージが2026年5月30日に廃止されること、Assistants APIが2026年8月26日に日没予定であること、現在のFoundryエクスペリエンスでは azure-ai-projects 2.x や openai パッケージを使うことが示されています。(Microsoft Learn)
また、Responses APIとFoundry Agent ServiceはすべてのAzureリージョンで使えるわけではないため、移行前に対象リージョンの対応状況を確認する必要があります。サポートされていないリージョンのFoundryリソースでは、現在のポータルでエージェントを作成または実行できない可能性があります。(Microsoft Learn)
移行時は、次の順番で進めると安全です。
- 現在のプロジェクトがクラシック由来か、現在のFoundryプロジェクトかを確認する
- 使用中のSDK、API、エンドポイント形式を棚卸しする
- Responses API対応リージョンにあるか確認する
- 開発環境で小さなSequentialワークフローを作る
- 既存エージェントの入出力をJSON化できるか確認する
- RBAC、監査、バージョン管理、秘密情報の扱いを管理者と合意する
- 本番相当データで分岐、承認、タイムアウトを検証する
Workflowsは便利ですが、移行プロジェクトの最初から複雑な業務全体を自動化しようとすると失敗しやすくなります。まずは「分類して担当に振り分ける」「回答案を作って人間が承認する」など、効果が見えやすい小さなプロセスから始めるのが現実的です。
よくあるトラブルと対処法
公式ドキュメントで示されているトラブルシューティングを、実務向けに整理すると次のようになります。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Workflowsが表示されない | 権限不足、対象ポータルではない | プロジェクト権限とNew Foundryの状態を確認する |
| 編集内容が反映されない | Saveしていない | 変更のたびにSaveし、バージョンを確認する |
| 実行結果が想定と違う | エージェント未割り当て、出力形式の不整合 | 各AgentノードとJSON Schemaを確認する |
| Power Fxで名前エラー | System. または Local. の不足 | 変数スコープを明示する |
| Power Fxで型エラー | 文字列、数値、真偽値の不一致 | Text()、Value() などで型をそろえる |
| タイムアウトする | ワークフローが大きすぎる、外部サービスが遅い | 処理を小さなセグメントに分割する |
トラブル対応では、最初にプロンプトを疑うのではなく、ノードの接続、変数、権限、保存状態を確認してください。Workflowsはビジュアルで作れる分、画面上ではつながっているように見えても、実行時には変数や型の不整合で止まることがあります。
管理者と開発者で分担すべきこと
Workflowsの導入は、開発者だけで完結させない方が安全です。AIエージェントが業務フローに組み込まれると、権限、監査、セキュリティ、コスト、運用品質が関係します。
| 役割 | 担当すべきこと |
|---|---|
| 管理者 | Foundryリソース、プロジェクト、RBAC、Entraグループ、ポータル移行、監査方針を管理する |
| 開発者 | ノード設計、エージェント割り当て、JSON出力、Power Fx、テストケースを作成する |
| 業務担当者 | 承認条件、例外処理、差し戻し基準、最終判断者を定義する |
| セキュリティ担当 | シークレット管理、外部サービス連携、ログ・保存データの扱いを確認する |
AIエージェントの精度だけでなく、「どこで人間が介入するか」「どの出力を信頼して次へ進めるか」を決めることが、Workflows導入の成否を分けます。
まず何をすべきか
Azure AI FoundryでWorkflowsを検討しているなら、次の順に進めてください。
まず、社内で利用している名称を整理し、Azure AI FoundryとMicrosoft Foundryが同じ進化上のプラットフォームを指していることを共有します。次に、対象プロジェクトでWorkflowsを作成・実行できる権限があるか確認します。そのうえで、複雑な業務全体ではなく、1つの繰り返し業務をSequentialワークフローとして試作してください。
最初の試作では、必ずJSON出力、if/else、Save、バージョン履歴、Power Fxの変数スコープを確認しましょう。Hosted agentsを使っている場合は、ワークフローデザイナーに直接載せられる前提で設計せず、Agent Framework workflowsなど別の実装経路を検討する必要があります。(Microsoft Learn)
Workflowsは、AIエージェントを「便利なチャット」から「管理できる業務プロセス」へ近づける機能です。管理者は権限と移行条件を整え、開発者は小さな業務フローから検証を始めることで、導入リスクを抑えながら実用化に進められます。
コメント