Logic AppsをMCPサーバーとして活用することで、Logic AppsのActionsやConnectorを使用してAI Agentの動作を多様化させることができます。
本記事ではLogic AppsのフローをAI Agentからトリガーさせる方法について解説します。また認証方法について、キーとOAuthの方式で設定する方法を解説します。
概要
AI Agentの活用方法が検討されており、特にAgent 365が発表されて以降はMicrosoft製品との連携が強化されています。Work IQの登場により利便性が向上してきましたが、より複雑な動作を実現したい、一定の自動化をしたいという需要が存在します。
最小のチャットで複雑な動作を実現したい場合、マルチエージェント化か、あるいはAzure FunctionsやLogic Appsにより自身で組んだ処理をMCP化することが選択肢に入ります。
本記事ではノーコードでフローを組み、他のMicrosoft製品と連携しやすい方法としてogic AppsとMicrosoft Foundryを連携させる方法を紹介します。
Azure FunctionsのMCP化については以下をご参照ください。
認証について
外部MCPサーバーを扱う際にはいくつかの認証方式がありますが、Logic Appsの場合はキー認証かOAuthの認証を選択することができます。
Microsoft Foundryのツール認証の詳細については、以下のDocsを参考にしてください。
OAuthとOpenID Connect
Microsoft FoundryからMCPサーバー化したLogic Appsを、OAuth認証でトリガーする方法を解説します。
「OAuth」および関連する単語として「OpenID Connect」があります。
ユーザーがアプリでログインボタンを押したとき、そのアプリ固有のログイン画面ではなく、Microsoftのログイン画面にリダイレクトするところを見たことはあるでしょうか。
ユーザーが指示に従ってMicrosoftアカウントでログインすると、Microsoftが認証を行います。その認証結果をもとにアプリ側へ、いくつか認証に使えるトークンを返します。アプリ側はトークンのうち、アクセストークンをリクエストに含めて、事前に認証を設定してあるバックエンドAPI(今回はLogic Apps)にアクセスすることができるようになります。
結果として、アプリ側はログイン情報を管理せずに認証機能を利用できることとなります。このとき、ログインする部分を「OpenID Connect」と呼び、そこで発行されたアクセストークンを使ってAPIにアクセスする許可の仕組みを「OAuth」と呼びます。
- 認証=OpenID Connect
- 認可=OAuth
設定手順
事前準備するものは以下の通りです。
- Entra ID アプリと設定
- Logic Appsリソースと設定
今回はこれらをMCPサーバー化して、Microsoft Foundryエージェントとして呼び出します。
- Microsoft Foundryリソース設定と設定
Entra ID アプリ
EntraIDのアプリを作成します。
[管理]-[アプリの登録]を選択して、アプリを新規作成します。今回はシングルテナントのみで構いません。
作成後、以下の設定を行います。
- [管理]-[Authentication]
- 設定タブで「パブリック クライアント フローを許可する」を有効に変更
- [管理]-[証明書とシークレット]
- クライアントシークレットタブで、新しいクライアントシークレットを作成する(ページ遷移すると再取得できないため、メモ帳等に保存しておく)
- [管理]-[APIの公開]
- アプリケーション ID の URIの横の「追加」を選択し、そのまま保存する
- 「scopeの追加」を選択して、以下の内容をセットする
- スコープ名:user_impersonation
- 同意できるのは誰ですか?:管理者とユーザー
- その他の設定は任意の値を入力する
- [管理]-[マニフェスト]
- Microsoft Graph アプリマニフェスト
- requestedAccessTokenVersionの項目をnull→2に変更
- Microsoft Graph アプリマニフェスト
設定後、以下の値を保管します。
- Tenant ID
- アプリケーション(クライアント)ID
- クライアントシークレット
- アプリケーションID URI
Logic Apps
MCPサーバーとして使用するLogic Appsをデプロイします。
従量課金プランはMCPサーバーが立てられないため、Standardのいずれかでデプロイする必要があります。今回はワークフロー サービス プランで作成します。Standard WS1でも2026年3月時点で月額2万円超程度のコストが発生するため、運用の際はこの費用を考慮する必要があります。
作成後、[設定]-[環境変数]を開き、以下の通り設定します。
| 環境変数名 | 設定値 |
|---|---|
| WEBSITE_AUTH_AAD_ALLOWED_TENANTS | <自身のテナントID> |
仮ワークフローの作成
仮のワークフローを1つ作成しておきます。今回はTriggerCheckとします。

トリガーの確認のために最初のノードだけ作成しておきます。When an HTTP request is receivedを選択してください。

| 項目 | 設定値 | 補足 |
|---|---|---|
| 説明 | このMCPサーバーは、Logic Appsのワークフローを実行します。ワークフローは「EchoMessage」パラメーターを含み、あなたが指定したメッセージをもとにワークフロー内で処理を行います。 | MCPサーバーのdescriptionsとして認識します |
| パラメーター-Request Body JSON Schema | 下記参照 | MCPサーバーのtool_propertiesとして認識します |
{ "type": "object", "properties": { "EchoMessage": { "type": "string", "description": "ユーザーが入力した生のチャットメッセージ" } }, "required": [ "EchoMessage" ] }
変更後、Saveを押してワークフローを保存してください。
MCPサーバーの作成
[Agents]-[MCP servers]を選択して、[Use existing workflows]を選択します。その後、以下の通り設定します。
| 項目 | 入力値 |
|---|---|
| Name | TriggerCheckMCP |
| Description | <任意の説明を入力> |
| Workflows | TriggerCheckを選択 |
Editを押下し、認証のメソッドを選択します。今回はキー認証、OAuthの両方を検証するため、Key-based and OAuthを選択します。Generate Keyを押下してキーを保存しておきます。

MCPサーバーのURLは以下の通りとなります。これも後にMicrosoft Foundryで設定するために控えておきます。
https://<logicappsデプロイ名>.azurewebsites.net/api/mcpservers/TriggerCheckMCP/mcp
認証の構成
Entra IDアプリを使用したOAuth認証を構成します。
[設定]-[認証]より、[IDプロバイダーの追加]を選択します。プロバイダーはMicrosoftを選択します。

以下の通り設定します。
| 項目 | 入力値 |
|---|---|
| アプリの登録の種類 | 「既存アプリの登録の詳細を提供します」を選択 |
| アプリケーション (クライアント) ID | <作成したアプリのアプリケーション(クライアント)ID> |
| 発行者の URL | https://login.microsoftonline.com/<テナントID>/v2.0 |
| 許可されるトークン対象ユーザー | <作成したアプリのアプリケーション(クライアント)ID> |
| クライアント アプリケーションの要件 | 「任意のアプリケーションからの要求を許可する (お勧めできません)」を選択 |
| ID の要件 | 任意の ID からの要求を許可する |
| テナントの要件 | 発行者テナントからの要求のみを許可する |
その他はデフォルト設定のまま作成します。
Microsoft Foundry
モデルのデプロイ
Microsoft FoundryのエージェントにLogic App MCPを使用させるための設定を進めます。
上の一覧から[ビルド]を開き、左のメニューから[モデル]を選択します。
「基本モデルをデプロイする」のボタンを押下し、任意のChatGPTモデルをデプロイします。
ツールの作成
左のメニューから[ツール]を開き、「ツールを接続」のボタンを押下します。
ここでAgentのツールとして使用できる、さまざまなコネクタを見ることができます。
ここでコネクタとして一覧化されている中には、この画面だけでツールの構築が完了するものと、バックグラウンドでAzureやサードパーティーのリソースと接続するものなどが混在しています。
例えば、この[カタログ]のメニューには、Outlookのコネクタが複数準備されていることがわかります。カスタムと書かれているものが、Logic Appsベースです。

Outlookと接続したい場合、Logic AppsとWork IQのツールのいずれかが選択肢になります。Work IQは設定が少なく利用できますが、機能が必要十分に満たない場合はLogic Appsベースが選択肢となります。
- Work IQのデプロイに進んだ場合

- Outlook.com(カスタム)のデプロイに進んだ場合

参考:Work IQ メールの機能一覧 learn.microsoft.com
ただし、この画面でOutlookツールを選択してLogic Appsをデプロイした場合は、機能を使えても、今回行っているような詳細な認証や設定が行えません。今回の記事でご紹介しているような、自身でリソースを作成してMCPサーバーとして接続する手順をお勧めします。
今回はこれらを使用せず、カスタムタブから「モデルコンテキスト プロトコル(MCP)」を選択して作成します。

MCP サーバー共通の設定
ここからMCPサーバーの設定を行います。
名前はMicrosoft Foundryに登録するツール一意の名称を任意に定義し、リモートMCPサーバーエンドポイントは、Logic Appsの項で提示したMCPサーバーのURLを入力します。

認証方式は4種類の中から選択しますが、今回は「キーベース」と「OAuth ID パススルー」の2種類を使った登録方法を紹介します。
キーベースの場合
資格情報の欄について、左項にX-API-KEYと入力し、右項には上記の手順、Generate Keyで生成しておいたLogic Apps MCPのキーを入力します。

OAuth ID パススルーの場合
以下の通り設定します。
| 設定項目 | 設定値 |
|---|---|
| クライアントID | <Entra IDのアプリケーション(クライアント)ID> |
| クライアントシークレット | <Entra IDアプリのClient Secret> |
| トークンURL | https://login.microsoftonline.com/<TenantID>/oauth2/v2.0/token |
| 認証URL | https://login.microsoftonline.com/<TenantID>/oauth2/v2.0/authorize |
| URLの更新 | https://login.microsoftonline.com/<TenantID>/oauth2/v2.0/token |
| スコープ | <アプリケーション ID URI>/user_impersonation |
リダイレクトURIの取得とアプリへの設定
ツールを作成した後、リダイレクトURLを取得することができます。

作成したEntraIDアプリの[管理]-[Authentication]を開きます。リダイレクトURIの構成タブを選択し、このURIを登録します。
エージェントの作成と設定
左の一覧から[エージェント]を選択し、エージェントの作成ボタンを選択します。
エージェント名とモデルは任意に設定します。
エージェント作成後、左のメニューからツールのタブを選択し、事前に作成しておいたキー認証とOAuth認証のツールをそれぞれ選択します。上の「エージェントで使用する」ボタンを押下することで、エージェントでLogic Appsをトリガーすることができます。

キー認証の場合
以下のプロンプトを入力して確認します。
あなたが持っているツールと、そのスキーマについて説明して
MCPサーバー名を「mcp_logicapp_keybase」と定義し、入力にも「EchoMessage」のスキーマを定義したのですが、AIが生成した回答にもそれが含まれていることが分かります。これはMCPサーバーの定義を読まないと分からない内容であり、連携ができていることがわかります。

実際に使用しようとすると承認を求められるため、了承します。

了承後にLogic Appsをトリガーした結果に基づいたメッセージを取得できます。

実際に成功していれば、Logic Appsのワークフロー実行履歴にもログが残ります。

OAuth認証の場合
今度はOAuth認証のツールを設定します。
検証のため、上記のエージェントからキー認証ツールを削除してOAuth認証のツールに置き換えます。
今度は最初のタイミングで承認を求められるため、これを了承します。


リダイレクトURIを設定していれば、レスポンスを得ることができます。

プログラムでの実装
今回の記事ではUIからツールを設定し、Agentに適用しました。
プログラム上からAgentに適用する場合でも、今回のようにツールの設定までは手動で実施する必要があります。
プログラムから設定したツールを読み込んで、Agentに適用する際は、create_versionを実行する際にtoolsの項目に適用します。
from azure.ai.projects.models import MCPTool
MCP_SERVER_URL = "<MCP ServerのURL>"
MCP_SERVER_LABEL = "logicapp"
mcp_tool = MCPTool(
server_label=MCP_SERVER_LABEL,
server_url=MCP_SERVER_URL,
project_connection_id="<Foundry ポータルで作成したツール接続の ID(= Connection ID)>",
)
agent = project_client.agents.create_version(
agent_name="logicapps-agent",
definition=PromptAgentDefinition(
model="gpt-4.1",
instructions=instructions,
tools=[mcp_tool],
)
)
補足事項
Microsoft FoundryのAI AgentはOAuth認証でLogic Appsにアクセスすることができます。一方でLogic Apps側では、MCPツールの場合に呼び出し元ユーザーのコンテキストをそのまま伝搬するような形にはなっていないため、ユーザーを識別させることができないようです。
アカウント個人に紐づくような処理をさせたい場合は、OpenAPI 3.0で直接APIを使用する方法が推奨されます。
おわりに
本記事では、Logic Apps を MCP サーバーとして公開し、Microsoft Foundry のエージェントからキー認証 または OAuth 認証でトリガーする一連の流れを紹介しました。
特に、既製ツールではカバーしきれない複雑な業務フローや、既存の Logic Apps 資産を AI 化したいケースでは、今回のように Logic Apps を MCP サーバー化するアプローチが有力な選択肢になります。
本記事が、Logic Apps と Microsoft Foundry を組み合わせて AI エージェントを業務に組み込んでいく際の、ひとつの参考になれば幸いです。