Azure Logic Apps での AI エージェントとモデルを使用したワークフロー (プレビュー)

適用対象: Azure Logic Apps (Standard)

Azure Logic Apps では、大規模な言語モデル (LLM) のエージェントを使用してタスクを完了するワークフローがサポートされています。 エージェントは、反復的なループ 処理を使用して、複雑な複数ステップの問題を解決します。 LLM は、パターンを認識し、人間の操作なしでジョブを実行するトレーニング済みプログラムです。次に例を示します。

• 指示、プロンプト、入力、その他のデータなどの情報に関する分析、解釈、および理由。
• 結果と使用可能なデータに基づいて意思決定を行います。
• エージェントの指示に従い、プロンプトに対する回答を作成して戻します。

自律エージェントまたは会話型エージェントを使用するワークフローを構築できます。 エージェントは自然言語を使用して、ユーザーと接続されたモデルと通信します。 また、エージェントは、モデルによって生成された出力を使用して、人間の操作の有無にかかわらず作業を行います。 このモデルは、エージェントが次の機能を提供するのに役立ちます。

• エージェントの役割、操作方法、応答方法に関する情報を受け入れます。
• 指示や要求、またはプロンプトを受信して応答 します。
• 使用可能な情報に基づいて、入力の処理、データの分析、選択を行います。
• 要求を満たすために必要なタスクを完了するツールを選択します。 ツールは基本的に、タスクを完了する 1 つ以上のアクションを含むシーケンスです。
• 柔軟性を必要とし、流動的、動的、予測不能、不安定な環境に適応します。

エージェントが使用するツールを構築するために使用できる 1,400 以上のコネクタ を使用すると、エージェント ワークフローはエージェントとモデルの機能から大きなメリットを得られるさまざまなシナリオをサポートします。 シナリオに基づいて、ソリューションのニーズに最も適した、人間とのやり取りのない自律的なエージェント ワークフローまたは人間の対話を使用した会話型エージェント ワークフローを作成します。

この概念ガイドでは、主要な概念、自律エージェント ワークフローと会話型エージェント ワークフローの違い、エージェント ワークフローと非エージェント ワークフローの違い、エージェント構造、その他のシナリオ例、基本的な課金情報について説明します。

重要な概念

次の表に、主要な概念の基本的な概要を示します。

自律的なエージェントワークフローと会話型エージェントワークフロー

これらのエージェント ワークフローの種類の違いをより深く理解できるように、次のセクションでは、各エージェント ワークフローの種類の例について説明し、示します。 どちらのワークフローの種類でも、エージェントとツールを使用して現在の天気を取得し、その情報を電子メールで送信します。 すべてのエージェントには、必要なモデルを使用してエージェントを設定し、エージェントのロール、その機能、応答方法に関する手順を提供する情報ウィンドウがあります。

自律エージェントのワークフロー

次の大まかな手順では、基本的な自律エージェント ワークフローの動作について説明します。

1. ワークフローは、サポートされている任意のトリガーから始まります。

   必要に応じて、トリガーとエージェントの間で 0 個以上のアクションを実行できます。

2. エージェントは、システム命令と非人道的なプロンプトまたは入力 (トリガーからの出力や先行アクションなど) を受け入れます。

3. エージェントは、 Azure OpenAI Service にデプロイされたモデル または Azure AI Foundry プロジェクトにデプロイされたモデルを 使用して、指示と要求を解釈して理解します。 また、エージェントはモデルを使用して、指定された入力を処理および分析します。

4. このモデルは、エージェントの指示に基づいて、必要なタスクを実行するためにエージェントが呼び出す必要があるツールを計画するのに役立ちます。

5. エージェントはツールの結果を返し、ワークフローの呼び出し元または指定された受信者に応答します。

次のスクリーンショットは、自律エージェントワークフローの基本的な例を示しています。

会話型エージェントのワークフロー

次の大まかな手順では、基本的な会話型ワークフローの動作について説明します。

1. ワークフローは常に、 チャット セッションが開始されたときにという名前のトリガーで開始されます。

   必要に応じて、トリガーとエージェントの間で 0 個以上のアクションを実行できます。

2. エージェントは、統合されたチャット インターフェイスを介してシステム命令と人間が提供するプロンプトまたは入力を受け入れます。たとえば、 シアトルの天気は何ですか?

3. エージェントは、 Azure OpenAI サービスにデプロイされたモデル を使用して、指示と要求を解釈して理解します。 また、エージェントはモデルを使用して、指定された入力を処理および分析します。

4. このモデルは、エージェントの指示に基づいて、必要なタスクに対してエージェントが呼び出すツールを計画するのに役立ちます。

5. エージェントはツールの結果を返し、チャット インターフェイスを介して人間のプロンプトに応答します。

次のスクリーンショットは、会話型エージェントワークフローの基本的な例を示しています。

次のスクリーンショットは、デザイナー ツール バーまたは Azure portal の [ツール ] の下のワークフロー サイドバー メニューからアクセスできる統合チャット インターフェイスを示しています。

会話エージェント ワークフローでは、他のユーザーが使用できる Azure portal の外部のチャット クライアントもサポートされます。 この外部チャット クライアントのアクセスを提供してセキュリティで保護するには、ユーザーの 認証と承認を行うためにロジック アプリで Easy Auth を設定する必要があります。

エージェントと非エージェントのワークフロー

エージェントを使用するワークフローは、非エージェント ワークフローに課せられる制限を超えて進化する可能性があります。 エージェント ワークフローは、予期しないイベントが発生する環境に適応し、プロンプト、入力、使用可能なデータに基づいて使用するツールを選択し、パフォーマンスを継続的に向上させ、非構造化データを処理し、複雑なシナリオをサポートし、より高いレベルの適応性と柔軟性を提供します。 非エージェント ワークフローは、安定した環境で最適に機能し、定義済みのルールに従い、静的、予測可能、反復的なタスクを実行します。

次の表に、エージェント ワークフローと非エージェント ワークフローの比較を示します。

エージェントのワークフロー構造を調べる

AI オートメーションおよび統合ソリューション用のシングルテナント Azure Logic Apps で新しいエージェント ワークフローを構築するには、Standard ロジック アプリ リソースを作成し、次のいずれかのワークフローの種類を持つワークフローを追加します。

• 自律エージェント
• 会話エージェント

これらのワークフローの種類には、Standard ステートフル ワークフローのすべての機能とエージェント機能が含まれており、エージェントを操作するように特別に設計されています。 これらのワークフローの種類には、空のエージェントが自動的に含まれます。

たとえば、次のスクリーンショットは、新しい自律エージェント ワークフローを示しています。

次のスクリーンショットは、新しい会話型エージェント ワークフローを示しています。

既存の ステートフル ワークフローがある場合、次のスクリーンショットは、自律エージェントと LLM 機能を含めるために エージェント アクションを追加する方法を示しています。

次のスクリーンショットは、使用するデプロイ済みモデルに関する情報を指定するエージェントの接続ウィンドウを示しています。

モデルへの接続を作成した後、エージェントは、エージェントが実行できるロール、エージェントが実行できるタスク、およびエージェントがプロンプトに応答し、質問に回答し、要求されたタスクを実行するのに役立つその他の規範的な情報を説明する指示を提供する必要があります。

モデルに接続されている空のエージェントは、モデルの機能のみを使用するプロンプトに応答できるため、エージェントにツールを含める必要はありません。 ただし、エージェントが Azure Logic Apps で使用できるアクションを使用するには、エージェントでツールを作成する必要があります。 最初にコネクタ ギャラリーからアクションを追加することで、ツールの作成を開始できます。

次の図は、ツールをビルドするためのアクションを参照して選択できるギャラリーを示しています。

次の図は、天気予報を取得し、その予測を電子メールで送信できる気象エージェントを示しています。

その他のシナリオ例

次のセクションでは、エージェントがワークフロー内のタスクを完了する方法をいくつか説明します。

住宅ローンエージェント

1 つの調整されたループで次のタスクを実行して、必要に応じてローンを自律的に、または人間の介入で処理する住宅ローン エージェントを銀行が使用しているとします。

• 顧客と会話して質問に回答します。
• ローンの申請を確認します。
• 財務情報を収集してローンの適格性を評価します。
• リスク データを取得して分析します。
• 提出時に不動産評価を要求し、要約します。
• エッジ ケースに備えて人間のレビュー担当者を含めます。
• アプリケーションを承認または拒否します。
• 意思決定を関係者に伝える。

注文履行エージェント

ビジネスで受注処理担当者を使用して、次のタスクを実行すると仮定します。

• 企業の知識に基づいて、顧客と連携して製品に関する質問に回答します。
• 注文を作成しますが、必要に応じてそれらを人間に渡します。
• インテリジェントなエスカレーションを 24 時間 365 日サポートします。

また、他のエージェント間で作業を調整するエージェントを用意することもできます。 たとえば、ライター、校閲者、発行元などのエージェントのチームが連携して、販売レポートを作成して配布する場合があります。

設備作業指示書エージェント

社内施設チームをサポートするために、作業指示エージェントは次のタスクを実行します。

• 従業員と会話し、サービス要求のオプションを提供します。
• 従業員の選択に基づいて作業指示書を開きます。
• 対応するサービス チームに作業指示書を送信します。
• ジョブの進行状況と状態を使用して作業指示書を更新します。
• 作業が完了したら、作業指示を終了します。
• 完了した作業を適切な関係者に通知してください。

認証と承認

非エージェント ワークフローは、通常、小規模で既知の予測可能な呼び出し元のセットとやり取りします。 ただし、エージェント ワークフローは、人、エージェント、モデル コンテキスト プロトコル (MCP) サーバー、ツール ブローカー、外部サービスなど、幅広い呼び出し元と通信します。 この範囲が広くなるほど統合オプションは増えますが、呼び出し元は動的、不明、または信頼されていないネットワークから発生する可能性があるため、さまざまなセキュリティ上の課題が発生します。 呼び出し元が制御していないネットワークから来た場合、または ID が外部または無制限の ID である場合は、エージェント ワークフロー (特に会話型エージェント ワークフロー) を保護できるように、各呼び出し元を認証して承認する必要があります。これは、ユーザーと対話するための外部チャット クライアントを提供するためです。

非運用アクティビティの場合、Azure portal は認証と承認に 開発者キー を使用します。 運用環境で会話型エージェント ワークフローを実行する準備ができたら、 Easy Auth (App Service Authentication For conversational Agent ワークフローとも呼ばれます) を設定してください。この保護により、Azure portal の外部で外部チャット クライアントが有効になり、Easy Auth の完了後に他のユーザーが使用できるようになります。

次のセクションでは、呼び出し元を認証し、エージェント ワークフローへのアクセスを承認するためのオプションについて説明し、比較します。

開発者キーの認証と承認

設計、開発、クイック検証などの非運用環境のアクティビティの場合のみ、Azure portal は 開発者キー を提供、管理、および使用して、ユーザーに代わってワークフローを実行します。

開発者キーとは

開発者キーは、Azure portal の設計、開発、およびクイック テストの各段階でワークフローを実行するために、Azure portal でのみ使用される便利な認証メカニズムです。 これらの段階では、開発者キーを使用すると、共有アクセス署名 (SAS) を使用して Easy Auth またはコピー トリガーのコールバック URL を手動で設定する必要を省略できます。 キーは、Azure Resource Manager REST API への要求を認証するアクセス トークンである Azure Resource Manager ベアラー トークンのみに基づいて、特定のユーザーとテナントにリンクされます。

ワークフローの実行、 要求 トリガーの呼び出し、内部チャット インターフェイスでの会話エージェント ワークフローとの対話など、ワークフロー デザイナーで組み込みのテスト エクスペリエンスを使用すると、ポータルによって開発者キーが自動的に挿入されます。 キーはテナント セッションとサインインポータル ユーザーに暗黙的にバインドされるため、ARM ベアラー トークンのみに基づくこのバインドのため、外部にキーを配布することはできません。

開発者キーの制限事項

次の一覧では、開発者キーの使用法と設計上の制限事項について説明します。

• このキーは、運用環境のシナリオでは、Easy Auth、マネージド ID、フェデレーション資格情報、または署名されたコールバック URL の代わりではありません。
• キーは、大規模な呼び出し元集団または信頼できない呼び出し元、エージェントツール、またはオートメーションクライアントには設計されていません。
• キーは、詳細なスコープとロールがないため、ユーザーごとの承認メカニズムではありません。
• このキーは、要求実行レイヤーの条件付きアクセス ポリシーによって管理されるのではなく、ポータルのサインイン 層でのみ制御されます。
• キーは、プログラムまたは CI/CD の使用を目的としていません。

開発者キーと Easy Auth の比較については、「 Easy Auth と Developer Key」を参照してください。

開発者キーのユース ケース

次の表では、開発者キーを使用するための適切で不適切なシナリオについて説明します。

Easy Auth の組み込み認証と認可

運用環境では、専用の Microsoft Entra アプリ登録を使用して ロジック アプリ リソースに Easy Auth を設定 することで、会話型エージェント ワークフローと外部チャット クライアント アクセスへのアクセスを保護します。 Easy Auth は、会話型エージェント ワークフローと対話するための適切なアクセス許可を持つユーザーのみを認証および承認します。 この方法では、トークンを分離し、最小限の特権を適用し、広範なマルチアプリケーション登録の再利用を回避します。 ロジック アプリ リソースの Easy Auth を設定した後、ワークフローは、会話型エージェントとの対話に使用できる外部チャット クライアントへの URL を Azure portal の外部に提供します。

Easy Auth には、ワークフローのビジネス ロジックの構築に集中できる組み込みの強制レイヤーが用意されており、次の利点があります。

• カスタム コードなしで Microsoft Entra のサインイン、認証、承認を処理します。

• シークレット、有効期間が長い Shared Access Signature (SAS) URL、アクセスキーをワークフローから排除し、シークレットの無秩序な拡散、ローテーションの手間、露出リスクを軽減します。

• IP 範囲や静的キーではなく、ロールとスコープへのアクセスをマッピングすることで、最小特権の設計を有効にします。

• ワークフローを実行する前にアクセス トークンを検証します。 検証済みの ID を各呼び出し元要求に挿入して、ワークフローが要求ごと、最小特権の承認決定を行えるようにします。

• ワークフロー内で最小特権の決定を適用できるように、ワークフローに送信される要求ごとに検証済みの ID を提供します。

• 条件付きアクセス ポリシー、テナント制限、ロールベースのアクセス制御 (RBAC)、アクセス許可スコープを一元化して、一貫したポリシー アプリケーションと適用を実現します。

• 各呼び出し元要求に、 X-MS-CLIENT-PRINCIPAL、グループ、ロール、スコープ、テナントなどの正規化された ID 要求を挿入します。 カスタム ミドルウェアを排除し、 Json の作成 や 解析 などのダウンストリーム ワークフロー アクションが、要求とスコープに対してきめ細かな承認を適用できるようにします。

• デバッグ、異常検出、診断アクティビティ、監査、ガバナンスのための一貫した認証と承認のログを生成します。

次のプロセスでは、Easy Auth がクライアントを認証し、ロジック アプリにアクセスすることを承認する方法について説明します。

1. クライアントがその ID を認証して Easy Auth で保護されたロジック アプリにアクセスしようとすると、Azure によって要求が Microsoft Entra ID にリダイレクトされます。

2. クライアントが正常に認証されると、Microsoft Entra ID はクライアントにアクセス トークンを発行します。

   これらのトークンは Microsoft Entra ID によって署名され、sub、有効期限 (exp) などの詳細が含まれます。 aud要求は、目的のトークン受信者を指定し、後で受信者ロジック アプリのアプリケーション ID URI を自動的に設定するために使用されます。 この URI は、アクセス トークンの対象ユーザーとしてロジック アプリを表し、次の形式を使用する一意の識別子です。

   api://<application-client-ID>

3. クライアントは、トークンを含む要求をロジック アプリに送信します。

4. Easy Auth は要求をインターセプトし、トークンを抽出して、次のチェックを実行します。

   • aud要求と許可されたトークン対象ユーザーを比較します。
   • aud要求と予想されるアプリケーション ID URI を比較します。

5. 値が一致する場合は、承認が続行されます。 そうでない場合、Easy Auth は HTTP 401 Unauthorized エラーで要求を拒否します。

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

• Azure Logic Apps で Easy Auth を使用してエージェント ワークフローをセキュリティで保護する
• Azure App Service および Azure Functions での認証と承認

簡単な認証と開発者キー

請求書

Azure Logic Apps ではエージェント ワークフローに追加料金は発生しませんが、Azure OpenAI Service および Azure AI Foundry プロジェクトでのモデルの使用には料金が発生します。 詳細については、次のページを参照してください。

• Azure OpenAI Service の価格
• Azure AI Foundry の価格

関連コンテンツ

• Azure Logic Apps で自律エージェント ワークフローを作成する
• Azure Logic Apps で会話型エージェント ワークフローを作成する
• ラボ: Azure Logic Apps を使用してエージェント ワークフローを構築するための概要