Microsoft Foundry を「エージェント製品」「ワークフロー製品」「API を叩くもの」のどれかに決めようとするから、整理がつかなくなる。
実体は積み上げ構造だ——モデルの層の上にエージェントの層が乗り、その上にワークフローの層が乗る。
「今どの層を触っているか」で問い直すと、混乱は消える。この記事はその3層の地図を渡す。
混乱の正体——AI 基盤を「一枚看板」で決めようとしているから
「Foundry って、エージェントを作るやつですよね？」「ワークフロー製品の話ですよね？」——会議室でよく聞く問いだ。発言者はどちらも正しいことを言っているが、会話は噛み合わない。
問い方の型が共通しているからだ。「何をする製品か」という一枚看板を貼ろうとする限り、Foundry の全貌は見えない。Foundry は製品名ではなく、スタック（積み上げ構造）の名称だ。複数の層がそれぞれ独立した責務を持ちながら積み重なっている。「今どの層の話をしているか」が決まれば、問いへの答えは自ずと決まる。
本記事では便宜上この積み上げを L1 / L2 / L3 と呼ぶ。Microsoft の公式製品ライン名は Foundry Models（L1 相当）/ Foundry Agents（L2 相当）/ Foundry Workflows（L3 相当） であり、L1/L2/L3 は著者の概念整理フレームだ。公式名と照合しながら、地図として使う。
3層の地図——L1 モデル・L2 エージェント・L3 ワークフローは何をするのか
各層を「何をするか・いつ使うか」で横に並べる。
| 層（本記事の呼称） | 公式製品名 | 何をするか | いつ使うか |
|---|---|---|---|
| L1（モデル=API） | Foundry Models | OpenAI・Anthropic Claude・Meta Llama など 1,800+ のモデルをカタログから選び、API エンドポイントとして提供する | 常に。L2・L3 もこの層を経由する |
| L2（エージェント） | Foundry Agent Service | L1 の上にメモリ・社内知識（RAG）・ツール呼び出し機能を積む。OpenAI 互換の Responses API ベースで GA 済。Python / JavaScript / Java / .NET SDK 対応 | 「会話の履歴を保ちたい」「社内ドキュメントを参照させたい」「外部 API を自律的に呼ばせたい」 |
| L3（ワークフロー） | Foundry Workflows | 複数のエージェントを段取りで繋ぎ、繰り返し可能なプロセスとして回す。旧 PromptFlow の後継（PromptFlow は 2027年4月20日に廃止予定） | 複数の専門エージェントを連携させる複雑なマルチステップ処理が必要なとき |
| 横断（評価・監視・ガバナンス） | Operate 層（Build 2026 公式フレーム） | トレース・評価・エージェントオプティマイザー。本番稼働中の挙動を測定し、改善提案を閉ループで回す | L1〜L3 のどの層でも必要。スタック全体に掛かる |
全ての始まりは「サービス化」だ。 エージェントもワークフローも、最終的には API で叩けるサービスとして動く。L1 はすべての基点であり、L2・L3 はその上に積む「便利さの追加」だ。「どの層が必要か」を問うことが、「何をする製品か」という問いの本来の立て方になる。
Build 2026 では Microsoft がもう一つの3層フレーム——Build（構築）/ Deploy（デプロイ）/ Operate（運用）——を公式に提示している。L1〜L3 がプロダクト構造の地図なら、Build/Deploy/Operate はライフサイクルの地図だ。両方を持っておくと、「製品の何を触っているか」と「開発サイクルのどこにいるか」を分けて考えられる。
ローコードとプロコードは対立していない——Copilot Studio から Foundry エージェントを呼ぶ
「ローコード（Copilot Studio）とプロコード（AI Foundry）のどちらを選ぶか」という問いも、二項対立ではない。
Microsoft は公式ガイダンスで「これらは競合ツールではなく、同じ Microsoft AI スタックの2層」と明言している。Copilot Studio 側から Foundry のエージェントをエンドポイント URL 経由で呼ぶことができる（2026年時点、プレビュー）。
接続手順はこうなる。
- Copilot Studio の「エージェント」タブ → 「追加」→「外部エージェントへ接続」→「Microsoft Foundry」を選択
- Foundry プロジェクトのエンドポイント URL を入力
書式：https://[projectname]-resource.services.ai.azure.com/api/projects/[projectname] - Microsoft Entra で認証を設定し、接続名と説明を入力
- Copilot Studio のオーケストレーターが説明文から「いつ Foundry エージェントを使うか」を判断する
この構成が整うと、役割分担の典型例はこうなる——エンジニアが Foundry で専門ツールや大規模 RAG パイプラインを構築し、業務担当者が Copilot Studio でそれを Teams や SharePoint の体験として組み立てる。カスタム度の低い部分はローコード側で維持し、カスタム度が要る部分だけ Foundry に任せる。段階的な選択ができる。
「ローコードかプロコードか」は出発点の問いとしては整理しやすいが、最終的には「カスタム度がどこまで必要か」という問いに置き換わる。そしてその問いの答えは、層の地図を持っていれば比較的早く決まる。
何を積まないか——「L1+薄いロジック」で足りる境界線
上に積むほど機能は増える。だが積むほど、管理コストと複雑度も積み重なる。「何を積むか」と同時に「何を積まないか」を決めることが設計の本来の仕事だ。
公式ドキュメント（Microsoft Learn「What is Microsoft Foundry Agent Service?」）は、カスタムオーケストレーションが不要なシンプルなユースケースでは、Responses API を呼ぶだけで Foundry のモデルとプラットフォームツールが使えると明示している。既存コードを Foundry 専用に書き直さなくても、API 呼び出し1本で始められる。Getting started fast から内部ツールの本番運用まで、L1 の Responses API 直接呼び出しで対応できるケースは明確に存在する。
一方、L3（Foundry Workflows）が本当に必要になるのは、公式定義によれば「複数エージェントを繰り返し可能なプロセスでオーケストレーションする必要があるシナリオ」に限られる。単一の問い合わせや1ステップの変換であれば、L3 は過剰装備だ。
どの層まで積むかの判断チェックリスト
- 複数のエージェントを連携させる必要があるか？（なければ L2 以下で足りる）
- プロセスが繰り返し可能な定型フローとして設計されているか？（単発の処理なら L1+薄いロジックで足りる）
- カスタムオーケストレーションロジックが必要か？（不要なら L2 の Prompt agent が適切）
- Copilot Studio の標準機能で対応できないカスタム度が要るか？（不要なら Copilot Studio 側で足りる）
全て「いいえ」なら L1 か L2 から始める。積み直しはできるが、解体の手間は最初の設計判断が正確なほど小さくなる。
まとめ
「何をする製品か」と一枚看板で決めようとすると、AI 基盤の問いは答えを持たない。層を問い直すと、整理がつく。
L1（Foundry Models）から始め、メモリ・知識・ツールが要る時だけ L2（Foundry Agent Service）へ。複数エージェントを段取りで繋ぐ必要が出た時だけ L3（Foundry Workflows）へ。横断の評価・ガバナンスはどの層でも必要になる。ローコード（Copilot Studio）とプロコード（AI Foundry）は対立でなく補完であり、接続できる。
次の一歩：Microsoft Learn の Foundry アーキテクチャドキュメントを起点に、手元のユースケースがどの層に着地するかを確認する。L2 を選んだ後のエージェント定義のガバナンス設計については、エージェント定義を Git で管理するが次の参照先になる。