Azure Logic Appsで構築するRAG型MCP

Azure Logic Appsで 構築するRAG型MCP

 Azure Logic Appsで構築するRAG型MCP  Logic App MCP×AI Search  API ManagementによるMCP集約

自己紹介  名前：折田菜津子  会社：株式会社 エーピーコミュニケーションズ  主な業務 • AI foundry(MS foundry)を使ったAIエージェント基盤設計構築 • Azure AI関連の新機能を調査

Azure Logic Appsで 構築するRAG型MCP

RAG型MCPの構成  RAG型MCP本体  Logic App(MCP) ×AI Search（ドキュメントインデックス）  API ManagementによるMCP集約  MCPのOauth認可をEntra IDと連携し構成  リクエスト数制限などの制御ポリシーを適用  リクエスト数や利用状況を監視し、可観測性を確保 Entra ID OAuth MCP認可 AI Search Docs MCP(logic app) APIM

Logic App MCP×AI Search

Logic app MCPの構成  MCP構成  Logic app(Standard)配下の各ワークフローがMCPツールとなる。  ワークフローの構成 クエリ本文 ドキュメントを検索 AI Search

Logic app MCPの注意事項 ツールのトリガー説明 • descriptionには「エージェントやLLMがどのような場面でそ のツールを利用すべきか」を明確に記載すること。 • MCPサーバーのツール一覧やルーティング時に参照されるた め、役割・目的・実行内容を簡潔に説明することが重要。 入力パラメータ • • • 各入力パラメータには必ずdescriptionを記載する。 型やフォーマット（例：base64文字列など）が必要な場合は、その旨 を明記する。 必要なパラメータは「required」属性で明示する。 • descriptionにも「必須」であることを記載し、利用者が誤解し ないようにする。

AI Searchへの検索クエリ キーワード＆セマンティック検索 セマンティックランカーが 構成された 検索インデックス キーワード検索＆セマンティック検索の特徴 Blobインデクサーでイン デクシング 利用対象 主に文字情報中心のドキュメントに対してよく用いられる検索方法。 仕組み まずキーワード検索で結果を取得し、その後に「意味的な関連性」を再評価（再ランク 付け）することで、より適切な回答を導き出す。 利用上の注意 セマンティック検索は「検索後の再ランク付け」を行うため、単独では利用できず、必 ずキーワード検索やベクトル検索など他の検索手法と組み合わせて使用する。 ベクトル検索との違い ベクトル検索ではクエリをベクトル化する必要があるが、セマンティック検索はクエリ のベクトル化が不要であり、Embeddingモデルを利用しなくても実行できる。

AI SearchでAIモデルを活用した検索を行うなら、 Microsoft Foundryを使おう！ Logic Appsでも、ベクトル検索などのAIモデルを活用した検索を Azure OpenAI × AI Search で構成することは可能です。 ただし、この方法は従来型のアプローチであり、拡張性の面では制約があります。 おすすめはMS Foundryによる検索！ 一方、MS Foundryでは Foundry IQ を利用することで、ai searchの検索インデックスの ほかに、custom bing searchやsharepointといった多様なデータソースから柔軟に検索 でき、拡張性に優れています。さらに以下の特徴があります。 検索対象の自動判断 クエリ内容に応じて、どのデータソースに検索をかけるかを Foundry IQ が自動で判断。 リフレクション機構 LMが検索結果を評価し、十分な情報が得られていない場合は再検索を実施。 拡張性と管理性 インデックス作成の自動化や、Foundryポータルからの細かなコントロールが可能。 非機能面での強み MS Foundryには、AIエージェントのトレースなどのオブザーバビリティや、セキュリ ティ・品質を担保するガードレールといった非機能機能も備わっています。

APIMによるMCP集約

独自MCPの公開 独自MCPをAPIM経由で 公開・管理可能。 APIMのポリシー（認証、レート制 限、IPフィルタ等）でアクセス制 御やセキュリティ強化が可能。

APIMによるMCP の OAuth 認可フローの構成 APIM を AI 認証ゲートウェイとして活用することで、MCP の OAuth 認可フローを構成可 能。 これにより、PKCE の検証やアクセストークンの取得を、APIM を介して安全にスケラブ ルに実施できる。 1. 2. 3. 4. 5. MCP クライアントは APIM にアクセスし、認証要求を開始 APIM は Entra ID にリダイレクトし、ユーザー認証を実施 認証後、APIM のコールバック URL にリダイレクトされ、 APIM は Entra ID との間で認証コードを Entra ID のアクセス トークンに交換 その後、APIM は MCP クライアント向けに暗号化された セッションキー（MCP サーバトークン）を生成し、トー クンエンドポイント経由で MCP クライアントに返却 MCP API 呼び出し時には、クライアントから送信される MCP サーバトークンを検証し、有効であれば MCP サーバ へ安全にプロキシする処理が行われる

APIM×MCPの認可方法の使い分け APIMへのアクセスに対する送信元制限の可否で分かれる。 送信元制限不可の場合、 OAuth認可を実装 制限可もしくは内部アクセスのみの場合、 サブスクリプションキー認可 pl-subnet 開発端末VNET(spoke) apim-subnet AOAI Roo code functions-subnet Dev box APIM vnet統 合 MCP

App insights とManaged Grafanaダッシュボード使ったオブザーバービリティ API→ALL APIsから Application Insights へのロギング設定可能。 MCPへのリクエスト数の推移など、より詳細な可視化が必要な 場合は、Grafana ダッシュボードを用いて可視化することができ る。 Grafanaダッシュボード(例) • MCPごとの1日あたりの平均応答時間（秒） • MCP APIのエラーコードごとの1日あたりの回数