Logic Appsで呼ぶAzure OpenAI Assistantを「Azure AI Foundry Agent」へ移行する方法

はじめに

Azure OpenAI Serviceの「Assistants API」を活用して、Logic AppsでAIワークフローを組んでいる方は多いのではないでしょうか？
しかし、これまでのAssistants API（Legacy）を利用したLogic Appsの実装には、いくつかの課題がありました。

• APIキーの管理: セキュリティリスクがあり、ローテーション運用が手間。
• 実装が複雑: Function Callingを行うために、Logic Apps側で「Runの状態確認（ポーリング）」→「Function実行」→「結果の提出（Submit Tool Outputs）」という複雑なループ処理を書く必要がある。

現在、Microsoftはこれらを解消する次世代のサービスとして、Azure AI Foundry Agent Service への移行を推奨しています。Azure AI Foundry Agent Service REST API は、Azure OpenAI Assistants API と同じプロトコルに従っています。このため、既存の OpenAI 互換のツールや SDK を、最小限の設定変更で使用できるという大きな利点があります。 （参照：Azure AI Foundry Agent Service REST API Reference）

この記事では、既存のAzure OpenAI Assistant APIを使用したLogic Appsを、最新のAzure AI Foundry Agent Service REST APIへ移行する手順を、実例を交えて解説します。
移行により、認証はManaged Identity（キーレス）になり、Logic Appsのフローも劇的にシンプルになります。

---

1. 移行手順 ①：Microsoft Foundry 環境構築

まずは、移行先となるAzure Microsoft Foundry側の環境を整えます。

1-1. プロジェクトの作成

Azure Microsoft Foundry にアクセスし、左メニューの「Foundry」を選択します。
画面上部の「+ Create」をクリックし、新しい「Foundry」および新しい「プロジェクト」を作成します。

※Hubの中にプロジェクトを作る手順もありますが、今回はFoundryからプロジェクトを作成するフローで行います。

1-2. Agent の作成と設定

1-1で作成したプロジェクトから「Go to Foundry Portal」でFoundryポータルを開き、「New agent」で新しいAgentを作成します。

① モデルとインストラクションの設定

今回は、コストパフォーマンスと応答速度に優れた GPT-4.1-mini を選択します。
インストラクションには、移行前のAssistantで使用していたプロンプトをコピー＆ペーストします。
TemperatureやTop Pなどのパラメータも、必要に応じてここで調整してください。

② Action の登録（既存Logic Appsをツールとして呼び出し）

Agent側でLogic Appsを呼び出せるように「Action」として登録します。

⚠️ Logic Appsを表示させるための3つの条件
「Add Action」からLogic Appsを選択して追加しますが、選択画面のリストにLogic Appsが表示されるためには、以下の条件を満たしている必要があります。

1. 同じサブスクリプションおよびリソースグループに存在すること
   Agent (Project) と同じ場所に配置されている必要があります。
2. HTTP要求トリガー（説明付き）で始まり、応答アクションで終わる構成であること
   トリガーには「説明（Description）」フィールドへの入力が必須です。Agentはこの説明を読んでツールの目的を理解します。
3. 現在、従量課金（Consumption）ワークフローのみサポートされていること
   Standardプラン（シングルテナント）のLogic Appsは現時点ではリストに表示されません。

詳細な要件については、以下の公式ドキュメントも参照してください。
Logic Apps をエージェントのアクションとして追加する方法

---

2. 移行手順 ②：Logic Apps の修正

Microsoft Foundry側の準備ができたら、Logic Appsを修正します。
主な変更点は「認証方法」と「HTTPアクション（REST API）の書き換え」です。

2-1. 認証設定：Managed Identityへの変更

APIキーを廃止し、セキュアなManaged Identity（マネージドID）へ切り替えます。

1. Logic Appsの「ID」設定で、システム割り当てマネージドID（またはユーザー割り当て）をオンにします。
2. 「Azure role assignments」画面で「Add role assignment」ボタンでこのLogic Appsに対して 「Azure AI User」 ロールを割り当てます。

これにより、Logic Apps内に一切のシークレットを持たずにAPIをコールできるようになります。

2-2. HTTPアクションの修正：REST APIの書き換え

ここが移行の肝となる部分です。Azure AI Foundry Agent ServiceのREST API仕様に合わせて、HTTPアクションを書き換えます。
今回は、スレッドの作成と実行を一度に行う 「Create thread and run」 APIを例に解説します。

※他のAPI（例：メッセージ取得など）を呼び出す場合も、URIの構成や認証設定の変更点は同様です。

① メソッドとURI

• メソッド: POST

• URI:

  {endpoint}/threads/runs?api-version=v1
  

  ここで {endpoint} は、単なるホスト名ではなく、プロジェクトへのパスを含んだURLになります。

  形式: https://<aiservices-id>.services.ai.azure.com/api/projects/<project-name>
{endpoint}は、1-1で作成したプロジェクトの「Endpoints」から取得できます。
  

  したがって、Logic Appsに入力する完全なURIは以下のようになります。
  https://<aiservices-id>.services.ai.azure.com/api/projects/<project-name>/threads/runs?api-version=v1
  
  （参照：Create Thread And Run API Reference）

② ヘッダーの修正

• API Keyの削除: これまでヘッダーに含めていた api-key は不要になるため削除します。
• Content-Type: application/json はそのまま残します。
  

③ リクエストボディ（Assistant IDの指定場所変更）

これまではURLパスにAssistant IDが含まれることが多かったですが、Agent Service APIの「Create thread and run」では リクエストボディ内で assistant_id を指定 します。

{
  "assistant_id": "asst_xxxxxxxxxxxxxx",
  "thread": {
    "messages": [
      {
        "role": "user",
        "content": "ここにユーザーからの質問が入ります"
      }
    ]
  }
}

• assistant_id: Microsoft Foundryで作成したAgentのID（asst_から始まるID）を記載します。
• thread: 新規スレッドを作成しつつ、最初のメッセージを渡します。
  

④ 認証パラメータ（Audienceの変更）

HTTPアクションの「認証」パラメータ（Advanced parameters）を開き、以下のように設定します。

• 認証の種類: マネージドID
• マネージドID: システム割り当て（または作成したもの）
• 対象ユーザー (Audience): https://ai.azure.com
  • ここが間違っていると 401 Unauthorized エラーになるため注意してください。
    

2-3. フローの簡素化（Function Callingループの廃止）

以前の構成では、Function Callingを行うために「Runが requires_action になるのを待つ」→「ツールを実行する」→「結果を Submit Tool Outputs で返す」という複雑なループ制御が必要でした。

今回の移行により、Logic Apps側で行っていたツール実行制御（Function Callingのハンドリング）は Agent 側が自動で行うようになります。ここが最大のメリットです。

以前のようにLogic Apps内で「どのツールを実行するか」という分岐や「実行結果をAPIに送り返す」という処理は一切不要です。単に 「終わるまで待つ」 だけで、Agentが裏側でAction（別のLogic Appsなど）を必要に応じて自律的に呼び出し、最終回答を作成してくれます。

※ただし、従来通りLogic AppsはAgentの処理完了（status: completed）を待ってから最終的な回答を取得する必要があります。

---

まとめ

今回の移行により、以下のメリットが得られました。

1. セキュリティ向上: APIキー管理が不要になり、Managed IdentityによるRBAC制御が可能になった。
2. 実装コスト削減: 複雑なポーリング処理やFunction Callingのループ処理が不要になり、Logic Appsが非常にシンプルになった。
3. メンテナンス性: Agent側の設定（プロンプトやAction）と、Logic Apps側のフロー（呼び出し）が疎結合になり、管理しやすくなった。

今後の展望

今回は、Azure AI Foundry Agent Serviceへの基本的な移行を行いました。
今後はこの基盤を活用し、以下のような高度な実装も試していきたいと考えています。

• Knowledge Base (RAG) の連携: 独自のドキュメントをVector Storeにアップロードし、回答の精度を向上させる。
• マルチエージェント オーケストレーション: 複数の専門特化したAgentを連携させ、より複雑なタスクを自律的に解決させるシステムの構築。

Azure AI Foundry Agent Serviceはまだプレビュー機能も多いですが、今後のAzureにおけるAI開発の標準となるプラットフォームですので、早めの移行をおすすめします！