Azure Logic Apps での Easy Auth (App Service 認証) を使用して会話エージェントワークフローをセキュリティで保護する (プレビュー)

2025-10-09

適用対象: Azure Logic Apps (Standard)

Important

この機能はプレビュー段階にあり、「Microsoft Azure プレビューの追加使用条件」が適用されます。

エージェントワークフローは、ユーザー、エージェント、モデルコンテキストプロトコル (MCP) サーバーとクライアント、ツールブローカー、外部サービスなど、より多様な呼び出し元とメッセージを交換できるため、統合オプションを拡張します。非エージェントワークフローは、小規模で既知の固定の呼び出し元のセットと対話しますが、エージェントの呼び出し元は動的、不明、信頼されていないネットワークから取得できます。その結果、各呼び出し元に対して認証とアクセス許可の適用を行う必要があります。

運用環境の会話型エージェントワークフローを保護するために、呼び出し元または会話エージェントと対話するユーザーを認証および承認するように Easy Auth を設定します。 App Service 認証とも呼ばれる Easy Auth には、次の機能が用意されています。

呼び出し元要求ごとに検証済みの ID を指定します。
各ユーザーに接続を割り当てます。
条件付きアクセスポリシーを適用します。
取り消し可能な資格情報を発行します。
最小特権の原則、ロール、スコープに基づいてアクセス許可を付与します。
ユーザーが会話エージェントと対話できるように、Azure portal の外部で外部チャットクライアントを提供します。

これらのメジャーを使用すると、細かいレベルで各呼び出し元を認証および承認し、必要に応じてすばやくアクセスを取り消すことができます。これらの制御がないと、制御されていないアクセス、Shared Access Signature (SAS) URL やアクセスキーなどの漏洩したシークレット、脆弱な監査証跡、その他のセキュリティ上の危険が生じるリスクがあります。

Easy Auth は、Microsoft Entra ID を別のセキュリティ層として使用して、ニーズを満たす組み込みの認証および承認機能を提供します。セキュリティの適用がワークフローの外部で動作する場合は、代わりにビジネスロジックの開発に重点を置くことができます。この問題の分離により、エージェントワークフローの構築、デバッグ、操作、監視、保守、管理、監査が簡単になり、簡単になります。

非エージェントワークフローセキュリティには、通常、静的 SAS、ローテーションシークレット、アクセス制限、IP 許可リスト、サービスタグ、仮想ネットワーク統合、プライベートエンドポイントなどのネットワーク境界制御が含まれます。エージェントワークフローでは、エンドユーザー、マネージド ID、サービスプリンシパル、およびそれらのスコープとロールに関する承認を設計します。このアプローチにより、グローバルなアクセスを安全に行うことができますが、ダウンストリームワークフローアクションはきめ細かいアクセス許可を尊重できます。

このガイドでは、アプリの登録を作成し、エージェントと非エージェントのワークフローを含めることができる Standard ロジックアプリリソースの Easy Auth を設定する方法について説明します。

Important

Easy Auth は、ロジックアプリリソースの基になるアプリ設定 (WEBSITE_AUTH_ENABLED、WEBSITE_AUTH_DEFAULT_PROVIDER、MICROSOFT_PROVIDER_AUTHENTICATION_SECRETなど) に構成情報を格納します。 ARM テンプレート、Bicep テンプレート、または Terraform テンプレートを使用して自動化を設定する場合を除き、これらの設定を手動で編集しないでください。

詳細については、次の記事を参照してください。

[前提条件]

Azure アカウントとサブスクリプション。サブスクリプションをお持ちでない場合は、無料の Azure アカウントにサインアップしてください。
Azure アカウントでは、アプリ登録を作成するために、Microsoft Entra の組み込みロールである Application Developer を使用します。
会話型エージェントワークフローを使用してデプロイされた Standard ロジックアプリリソース。

詳細については、「 Azure Logic Apps でのチャット操作のための会話型エージェントワークフローの作成」を参照してください。
Microsoft Entra を使用してターゲットテナントのアプリの登録を作成するためのアクセス許可を持つ、ロジックアプリリソースに対する Azure 共同作成者ロール以上。

Important

Easy Auth を設定するには、Logic Apps の標準共同作成者ロールとは異なる、上位レベルの Azure 共同作成者ロールがあることを確認します。
(省略可能)対話型サインインを使用するユーザーフローのみをサポートするか、マネージド ID またはサービスプリンシパルを使用する呼び出し元をサポートするかを選択します。

詳細については、「Azure App Service と Azure Functions での認証と承認」を参照してください。
(省略可能)そのドメインに特定のリダイレクト URI を適用する場合は、カスタムドメイン。

アプリの登録を作成する

Easy Auth のセットアップを開始する最善の方法として、ロジックアプリリソースから直接 Microsoft Entra ID で新しいアプリ登録を作成します。代わりに既存のアプリ登録を再利用する必要がある場合は、アプリの登録を更新して、Easy Auth および Azure クライアントと正常に連携する必要があります。

Azure portal で、Standard ロジックアプリリソースを開きます。
リソースサイドバーメニューの [設定] で、[ 認証] を選択します。
[認証] ページで、[ID プロバイダーの追加] を選択します。

[認証] ページに、ID プロバイダーを設定するための [基本] タブが表示されるようになりました。
[ 基本 ] タブの [ID プロバイダー] で、Microsoft Entra ID として [Microsoft ] を選択します。
[ アプリの登録 ] セクションで、[ アプリの登録の種類] で、[ (Conversational エージェントに推奨) 新しいアプリの登録を作成する] を選択します。このオプションには、この選択に対応するオプションが表示されます。
アプリ登録の一意の表示名を指定します。次に例を示します。 agent-logic-app-reg-prod
ユーザー割り当てマネージド ID の場合は、[新しいユーザー割り当てマネージド ID の作成] を選択します。

新しい ID を作成するには、名前を指定するか、既存の ID を選択します。
[サポートされているアカウントの種類] で、他のテナントを意図的に受け入れる場合を除き、[現在のテナント - シングル テナント] を選択します。

シングルテナント設定は、現在の組織のディレクトリ内のアカウントのみを参照します。そのため、このディレクトリ内のすべてのユーザーアカウントとゲストアカウントで、アプリケーションまたは API を使用できます。たとえば、対象ユーザーが組織の内部にある場合は、この設定を使用します。

次の例は、アプリの登録の外観を示しています。

Important

明示的なガバナンスポリシーと条件付きアクセスポリシーを設定していない限り、 Microsoft Entra ディレクトリ - マルチテナントを選択しないでください。

詳細については、次の記事を参照してください。

[ 追加チェック] で、次の値を選択します (まだ選択されていない場合)。

Setting	価値
クライアントアプリケーションの要件	このアプリケーション自体からの要求のみを許可する
ID 要件	特定の ID からの要求を許可する
許可されている ID	[特定の ID からの要求を許可する] が選択されている場合にのみ表示されます。既定の事前設定された値は、現在のユーザー (つまり自分) を表すオブジェクト ID です。この値は、次の方法で更新できます。 - 他の開発者またはユーザーのオブジェクト ID を含めます。 - グループ要求を使用して、個々のオブジェクト ID ではなく、特定のグループを含めます。 - ロジックアプリリソースの既存のアプリ登録を選択します。その場合は、アプリの登録を更新して、Easy Auth で正常に動作するようにしてください。詳細については、「組み込みの承認ポリシーを使用する」を参照してください。
テナントの要件	発行者テナントからの要求のみを許可する

[ 除外されたパス ] セクションをスキップします。

必要に応じて、[ App Service の認証設定] で次の設定を確認し、適切なアクションを実行します。

Setting	アクション
アクセスを制限する	一部の認証済みエンドポイントを許可する場合を除き、[ 認証を要求してすべての匿名要求をブロックする] を選択します。
認証されていない要求	呼び出し元がエージェントであるかエージェントベースであるかに基づいて、「HTTP 302 リダイレクトが見つかりました: エージェントに推奨」を選択します。

完了したら、[ 追加 ] を選択して ID プロバイダーの追加を完了します。

Azure によってアプリの登録が作成され、アプリ設定が更新され、Easy Auth ランタイムが有効になります。 Azure が完了すると、ロジックアプリの [認証 ] ページに Microsoft が ID プロバイダーとして一覧表示されます。クライアントと呼び出し元は、ID を認証する必要があります。ロジックアプリは、認証されていないクライアントと呼び出し元を意図したとおりに拒否し、要求に有効なトークンが含まれていない場合は 302 Found リダイレクト 応答または 401 Unauthorized 応答を発行します。

アプリの登録の作成が完了したら、認証が期待どおりに動作することを確認できるようになるまで、ロジックアプリのセットアップをできるだけ最小限にしてください。後で、アプリ登録リソースの次のページに移動して、適用するアクセス許可スコープまたはアプリロールを追加できます。
- アプリ登録サイドバーの [ 管理] で、[ API の公開 ] を選択してアクセス許可スコープを追加します。詳細については、「スコープを追加する」を参照してください。
- アプリ登録サイドバーの [ 管理] で、[ アプリロール ] を選択してアプリロールを割り当てます。詳細については、「アプリロールの割り当て」を参照してください。
または、次のセクション「既存のアプリの登録を更新する」で対応する手順を確認できます。
アプリの登録が正しく設定されていることを確認するには、「簡単な認証のセットアップをテストして検証する」を参照してください。

既存のアプリの登録を更新する

別の API または以前のプロトタイプと共有されている既存のアプリ登録を再利用する必要がある場合は、次の手順に従って、指定した設定を確認して調整し、アプリの登録が Easy Auth およびエージェントクライアントで正常に動作するようにします。

Azure portal の検索ボックスで、 Microsoft Entra ID を見つけて選択します。
サイドバーメニューの [ 管理] で [ アプリの登録] を選択し、アプリの登録を見つけて選択します。
アプリ登録サイドバーメニューで、[ 管理] を展開します。
[ 管理] で [ ブランドとプロパティ] を選択し、[ ホームページの URL ] 設定でロジックアプリの Web サイトの URL が指定されていることを確認します。

注

バックエンド専用 API またはエージェント API の場合、ホームページ URL は省略可能です。この値は、エンドユーザーがランディングページまたはドキュメントページを必要とする場合にのみ設定します。トークンリダイレクトでは、この値は使用されません。
[管理] で、 [認証] を選択します。
1. [ プラットフォーム構成] で、 Web エントリが存在することを確認します。
2. Web エントリの [リダイレクト URI] で、事前に設定された Easy Auth (App Service Authentication) コールバック URI を見つけます。これは次の構文に従います。
  
  https://<logic-app-name>.azurewebsites.net/.auth/login/aad/callback
  
  シナリオでカスタム API アプリケーション ID を公開する必要がある場合を除き、この既定値をそのまま使用してください。このコールバック URI は、既定のアクセストークン 対象ユーザー であり、これらのリソースにアクセスするクライアントからのアクセストークンを受け入れるリソースを指定します。
  
  許可されたトークン対象ユーザーの背後にある目的は、これらのリソースに対して有効なトークンを提示する要求のみを受け入れるということです。アクセストークン要求には、トークンを要求するクライアントと、トークンを受け入れるリソースの 2 つのパーティが含まれます。受信者はトークン "対象ユーザー" と呼ばれ、この場合はロジックアプリです。
  
  詳細については、「リダイレクト URI とは」を参照してください。
3. Azure で リダイレクト URI 設定が事前設定されていない場合は、ロジックアプリ名を使用して URI を手動で入力します。次に例を示します。
  
  https://my-chatbox-logic-app.azurewebsites.net/.auth/login/aad/callback
  
  Important
  
  対話型フロントエンドをホストしている場合を除き、カスタムリダイレクト URI は使用しないでください。
4. Front-channel ログアウト URL の設定を無視します。
5. 暗黙的な許可フローとハイブリッドフローの場合は、次のオプションの両方を選択します。
  - アクセストークン (暗黙的なフローに使用)
  - ID トークン (暗黙的およびハイブリッドフローに使用)
  詳しくは、次のドキュメントをご覧ください。
  - Microsoft ID プラットフォームと OAuth 2.0 の暗黙的な許可フロー
  - ID トークンを要求する (ハイブリッドフロー)
6. [ サポートされているアカウントの種類] で、ビジネスニーズに合ったオプションを選択します。
  
  ほとんどの場合、この組織ディレクトリ内のアカウントのみを選択します (Microsoft のみ - シングルテナント)。 マルチテナントオプションの場合は、明示的な Azure ガバナンスポリシーと条件付きアクセスポリシーが設定されていることを確認します。これらのオプションの詳細については、「サポートされているアカウントの種類による検証の違い」を参照してください。
7. [ 詳細設定] の [ パブリッククライアントフローを許可する] で、指定したモバイルおよびデスクトップフローを有効にするための [いいえ ] 設定を保持します。
  
  この例外はネイティブの場合に存在します。パブリッククライアントは、デバイスまたは認証コードを使用してリソース所有者パスワード資格情報 (ROPC) フローを回避する必要があります。
8. 終了したら、[保存] を選択します。
[管理] で、[証明書とシークレット] を選択します。 [ フェデレーション資格情報 ] タブで、ロジックアプリへのアクセス権を持つ新しいユーザー割り当てマネージド ID を設定して、アプリの登録時にマネージド ID をフェデレーション ID 資格情報として使用できるようにします。

ロジックアプリへのアクセス権を持つユーザー割り当てマネージド ID がない場合は、次の手順に従います。
1. 「ユーザー割り当てマネージド ID を作成する」の手順を使用して、ユーザー割り当てマネージド ID を作成します。
2. ユーザー割り当て ID をロジックアプリに追加します。
3. アプリの登録時に、ユーザー割り当て ID をフェデレーション ID 資格情報として設定します。
必要に応じて、ロール、スコープ、ユーザーグループ、などのXMS_CCを設定する必要がある場合は、次の手順に従います。
1. [ 管理] で、[ トークンの構成] を選択します。
2. [ 省略可能な要求 ] セクションで、要求を追加します。
  
  注
  
  トークンの肥大化を避けるには、大規模なグループ要求ではなく、ロールまたはスコープの確認を設定します。
[ 管理] で [ API のアクセス許可] を選択し、次の手順に従います。
1. [構成されたアクセス許可] の下で [アクセス許可の追加] を選択します。
2. [ API のアクセス許可の要求 ] ウィンドウの [ Microsoft API ] タブで、 Microsoft Graph を見つけて選択します。
3. アクセス許可の種類として、[ 委任されたアクセス許可] を選択します。
4. [ アクセス許可の選択 ] ボックスに「 User.Read」と入力します。
5. [ アクセス許可 ] 列で、[ ユーザー] を展開し、 User.Read アクセス許可を選択します。
詳細については、「 Microsoft Graph にアクセスするためのアクセス許可を追加する」を参照してください。

必要に応じて、[ 管理] で [ API の公開] を選択し、アクセス許可スコープを定義して公開できるようにします。

アプリケーション ID URI 設定の場合、事前設定された URI は、ロジックアプリリソースをアクセストークンの対象ユーザーとして表し、次の形式を使用する一意の識別子です。

api://<application-client-ID>

この API で定義されているスコープセクションで、ロールと対象ユーザーの検証のみに依存する場合は、アクセス許可スコープを定義または公開する必要はありません。ただし、Azure クライアントに委任されたアクセス許可を要求する場合は、次の手順に従ってこれらのスコープを定義します。

[ スコープの追加] を 選択し、次の情報を指定します。

Setting	必須	価値
スコープ名	イエス	`user_impersonation`
同意できるユーザー	イエス	管理者とユーザー
管理者の同意の表示名	イエス	テナント管理者がスコープの同意を提供するときに同意メッセージに表示されるアクセス許可スコープのラベルまたは名前。例えば：アクセス <logic-app-name>
管理者の同意の定義	イエス	テナント管理者が同意画面でスコープを展開したときに同意画面に表示されるアクセス許可スコープの詳細な説明。例えば：サインインしているユーザーの代わりに、アプリケーション <logic-app-name> へのアクセスを許可します。
ユーザーの同意の表示名	いいえ	エンドユーザーがこのスコープに同意した場合に同意画面に表示されるアクセス許可スコープの省略可能な名前。例えば：アクセス <logic-app-name>
ユーザーの同意の定義	いいえ	エンドユーザーが同意画面でスコープを展開したときに同意画面に表示されるアクセス許可スコープのオプションの詳細な説明。例えば：アプリケーションがユーザーの代わりに <logic-app-name> にアクセスできるようにします。
状態	イエス	有効

完了したら、[スコープの 追加] を選択します。
[スコープ] ボックスの一覧で、更新されたスコープ設定を確認して、想定どおりに表示されることを確認します。

アプリの登録の更新が完了したら、Standard ロジックアプリリソースに移動します。
ロジックアプリのサイドバーの [設定] で、[ 認証] を選択します。
[ 認証 ] ページの [ 認証設定] の横にある [編集] を選択して設定を確認します。 [ 認証設定の編集 ] ウィンドウで、次の値を確認します。

Setting	価値	Description
App Service 認証	有効	ロジックアプリは Easy Auth で設定され、有効になっています。
アクセスを制限する	認証を要求する	クライアントと呼び出し元は、ID を認証する必要があります。
認証されていない要求	イエス	ロジックアプリは、認証されていないクライアントと呼び出し元を意図したとおりに拒否し、要求に有効なトークンが含まれていない場合は 302 Found リダイレクト応答または 401 Unauthorized 応答を発行します。

簡単な認証のセットアップをテストして検証する

Easy Auth を設定すると、Azure portal のワークフローの [チャット] ページの内部チャットインターフェイスが使用できなくなります。代わりに、Azure portal の外部で使用できる外部チャットクライアントを使用して、会話エージェントと対話する必要があります。 Easy Auth が期待どおりに動作することを確認するには、次の手順に従って外部チャットクライアントでテストを実行します。

デザイナーのツールバーまたはワークフローサイドバーで、[ チャット] を選択します。

内部チャットインターフェイスが [チャット ] ページに表示されなくなりました。
[ 要点 ] セクションで、[ チャットクライアント URL ] リンクを選択すると、新しいブラウザータブが開きます。
アクセス許可要求プロンプトで、同意を入力し、要求に同意します。

ブラウザーページが更新され、外部チャットクライアントのインターフェイスが表示されます。

ヒント

チャットクライアント URL を iFrame HTML 要素に埋め込むこともできます。この URL は、チャットクライアントを提供する Web サイトで使用できます。次に例を示します。

<iframe src="https:/<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe>
外部チャットインターフェイスで、会話エージェントとの対話を開始または続行します。
ワークフローの実行履歴を確認するには、次の手順に従います。
1. Azure portal でワークフローに戻ります。
2. ワークフローサイドバーの [ ツール] で、[ 実行履歴] を選択し、最新のワークフロー実行を選択します。
3. 監視ビューで、実行履歴と操作の状態が期待どおりに表示されることを確認します。

Easy Auth テスト中のエラーのトラブルシューティング

次の表では、Easy Auth を設定するときに発生する可能性がある一般的な問題、考えられる原因、および実行できるアクションについて説明します。

問題またはエラー	考えられる原因	アクション
対象ユーザーを参照する `invalid_token` + を含む`error_description`	アクセストークンの対象ユーザーと、指定した許可されたトークン対象ユーザーの間に不一致が存在します。	アクセストークンの対象ユーザーと許可されたトークンの対象ユーザーが一致していることを確認します。
403 禁止	要求のワークフローまたはエージェントが見つからなかったことを示している可能性があります。	承認の問題がないか、ワークフロー内のアクションを確認します。

ワークフローで ID を使用する

Easy Auth が要求を検証すると、Easy Auth は ID プロバイダーに基づいて ID データを要求ヘッダーに挿入します。ロジックアプリでは、これらのヘッダーを使用して呼び出し元を認証します。

詳細については、次の記事を参照してください。

AI エージェントワークフローでの認証と承認

フィードバック

このページはお役に立ちましたか?

次の方法で共有

Azure Logic Apps での Easy Auth (App Service 認証) を使用して会話エージェント ワークフローをセキュリティで保護する (プレビュー)