適用対象: Azure Logic Apps (従量課金 + 標準)
人間と対話する AI を利用した自動化が必要な場合は、Azure Logic Apps で 会話型エージェント ワークフローを作成します。 これらのワークフローでは、自然言語、エージェント ループ、 および大きな言語モデル (LLM) を使用して、人間が提供する入力と質問 (プロンプトと呼ばれます) に基づいて決定を行い、タスクを完了 します。 これらのワークフローは、ユーザー主導、有効期間が短い、またはセッションベースの自動化に最適です。
次のワークフロー例では、会話エージェントを使用して現在の天気を取得し、電子メール通知を送信します。
このガイドでは、 Conversational Agents ワークフローの種類を使用して従量課金または標準ロジック アプリを作成する方法について説明します。 このワークフローは、タスクを完了するために作成する、人間が提供するプロンプトとツールを使用して実行されます。 エージェント ワークフローの概要については、 Azure Logic Apps の AI エージェント ワークフローに関するページを参照してください。
Important
従量課金会話型エージェント ワークフローはプレビュー段階であり、 Microsoft Azure プレビューの追加使用条件に従います。
[前提条件]
- Azure アカウントとサブスクリプション。 無料の Azure アカウントを取得します。
従量課金ロジック アプリと Standard ロジック アプリのどちらを作成するかに基づいて、次の前提条件が適用されます。
Conversational Agents という名前のワークフロー タイプを使用する従量課金のロジック アプリ リソース。 Azure portal での従量課金ロジック アプリ ワークフローの作成に関するページを参照してください。
従量課金会話型エージェント ワークフローでは、別の AI モデルを手動で設定する必要はありません。 ワークフローには、Azure AI Foundry でホストされている Azure OpenAI サービス モデルを使用するエージェント アクションが自動的に含まれます。 エージェント ワークフローでは、特定のモデルのみがサポートされます。 「サポートされているモデル」を参照してください。
注
Visual Studio Code ではなく、Azure portal のみを使用して会話型エージェント ワークフローを構築できます。
外部チャットの認証と承認の場合、従量課金会話エージェント ワークフローでは 、Microsoft Entra ID で OAuth 2.0 が使用されます。
この例に従うには、電子メールを送信するための電子メール アカウントが必要です。
このガイドの例では、Outlook.com アカウントを使用します。 独自のシナリオでは、Office 365 Outlook、Microsoft Teams、Slack など、Azure Logic Apps でサポートされている任意の電子メール サービスまたはメッセージング アプリを使用できます。 他のメール サービスまたはアプリのセットアップは例に似ていますが、小さな違いがあります。
制限事項と既知の問題
次の表では、現在の制限事項と、このリリースの既知の問題について説明します。
| ロジック アプリ | 制限事項または既知の問題 |
|---|---|
| 両方 | エージェント用のツールを作成するには、次の制限事項が適用されます。 - トリガーではなくアクションのみを追加できます。 - ツールはアクションで始まり、常に少なくとも 1 つのアクションを含む必要があります。 - ツールは、そのツールが存在するエージェント内でのみ機能します。 - 制御フロー アクションはサポートされていません。 |
| 従量課金 | - 従量課金エージェント ワークフローは、Visual Studio Code ではなく、Azure portal でのみ作成できます。 - エージェントが使用する AI モデルは、任意のリージョンから発生する可能性があるため、特定のリージョンのデータ所在地は、モデルが処理するデータに対して保証されません。 - エージェント アクションは、使用されるトークンの数に基づいて調整されます。 |
| Standard | - サポートされていないワークフローの種類: ステートレス Azure OpenAI Service と Azure Logic Apps の一般的な制限については、次を参照してください。 - Azure OpenAI サービスのクォータと制限 - Azure Logic Apps の制限と構成 |
エージェント ワークフローでサポートされている Azure OpenAI サービス モデル
次の一覧では、エージェント ワークフローで使用できる AI モデルを指定します。
エージェントは、次のいずれかの Azure OpenAI サービス モデルを自動的に使用します。
- gpt-4o-mini
- gpt-5o-mini
Important
エージェントが使用する AI モデルは、どのリージョンからでも発生する可能性があるため、特定のリージョンのデータ所在地は、モデルが処理するデータに対して保証されません。
Billing
従量課金: 課金には従量制モデルが使用されます。 エージェント ループの価格は、各エージェント アクションが使用し、請求書にエンタープライズ ユニットとして表示されるトークンの数に基づいています。 特定の価格情報については、 Azure Logic Apps の価格に関するページを参照してください。
標準: エージェント ワークフローには追加料金は発生しませんが、AI モデルの使用には料金が発生します。 詳細については、Azure 料金計算ツールを参照してください。
会話型エージェント ワークフローを作成する
次のセクションでは、会話型エージェント ワークフローの作成を開始する方法を示します。
Conversational Agents ワークフローの種類では、新しいチャット セッションの開始時という名前の必須トリガーで開始される部分ワークフローが作成されます。 ワークフローには、空の 既定のエージェント アクションも含まれています。
この部分的なワークフローを開くには、次の手順に従います。
Azure portal で、従量課金ロジック アプリ リソースを開きます。
リソース サイドバーの [開発ツール] でデザイナーを選択し、部分的なエージェント ワークフローを開きます。
デザイナーには、[ 新しいチャット セッションが開始されたとき] という名前の必要なトリガーで始まる部分的なワークフローが表示されます。 トリガーの下に、エージェントとして「既定のエージェント」という名前の空のアクションが表示されます。 このシナリオでは、他のトリガーのセットアップは必要ありません。
次のセクションに進み、エージェントを設定します。
注
ワークフローを今すぐ保存しようとすると、デザイナー ツール バーの [エラー ] ボタンに赤い点が表示されます。 変更を保存する前にエージェントがセットアップを必要とするため、デザイナーによってこのエラー状態が通知されます。 ただし、今すぐエージェントを設定する必要はありません。 引き続きワークフローを作成できます。 ワークフローを保存する前に、必ずエージェントを設定してください。
AI モデルを設定または表示する
エージェントの AI モデルを設定または表示するには、ロジック アプリの種類に基づいて次の手順に従います。
既定では、エージェントはロジック アプリのリージョンで使用可能な Azure OpenAI モデルを自動的に使用します。 一部のリージョンでは gpt-4o-mini がサポートされ、他のリージョンでは gpt-5o-mini がサポートされています。
エージェントが使用するモデルを表示するには、次の手順に従います。
エージェントの名前を変更する
次の手順に従って、エージェントの目的を明確に識別するようにエージェント名を更新します。
デザイナーで、エージェントのタイトル バーを選択して、エージェント情報ウィンドウを開きます。
情報ウィンドウでエージェント名を選択し、新しい名前を入力します (例:
Weather agent)。次のセクションに進み、エージェントへの指示を与えます。
エージェントのセットアップ手順
エージェントには、エージェントが実行できるロールと、エージェントが実行できるタスクを説明する手順が必要です。 エージェントがこれらの責任を学習して理解できるように、次の情報を含めることもできます。
- ワークフロー構造
- 使用可能なアクション
- 制限事項または制約事項
- 特定のシナリオまたは特殊なケースの相互作用
最良の結果を得るには、規範的な命令を提供し、命令を繰り返し調整する準備をします。
[ エージェントの手順 ] ボックスに、エージェントがその役割とタスクを理解するために必要な手順を入力します。
この例では、気象エージェントの例では、次のサンプル手順を使用して、後で質問し、テスト用に独自の電子メール アドレスを指定します。
You're an AI agent that answers questions about the weather for a specified location. You can also send a weather report in email if you're provided email address. If no address is provided, ask for an email address. Format the weather report with bullet lists where appropriate. Make your response concise and useful, but use a conversational and friendly tone. You can include suggestions like "Carry an umbrella" or "Dress in layers".次に例を示します。
これで、ワークフローを保存できます。 デザイナーのツール バーで、 [保存] を選択します。
エラーを確認する
この段階でワークフローにエラーがないことを確認するには、ロジック アプリと開発環境に基づいて、次の手順に従います。
デザイナーのツール バーで、[ チャット] を選択します。
チャット クライアント インターフェイスで、次の質問をします。
What is the current weather in Seattle?応答が期待値であることを確認します。次に例を示します。
デザイナーに戻って、ワークフローを再開してください。
ワークフロー サイドバーの [開発ツール] で、[ 実行履歴] を選択します。
[ 実行履歴 ] ページの [実行] テーブルで、最新のワークフロー実行を選択します。
注
ページに実行が表示されない場合は、ツールバーの 再読み込み を選択します。
[状態] 列に [実行中] 状態が表示されている場合、エージェント ワークフローは引き続き動作しています。
監視ビューが開き、ワークフロー操作とその状態が表示されます。 [エージェント ログ] ウィンドウが開き、前に指定したエージェントの指示が表示されます。 ペインには、エージェントの応答も表示されます。
現時点では、エージェントに使用するツールはありません。つまり、エージェントがタスクを完了するために必要なツールを作成するまで、エージェントは実際にメールをサブスクライバー リストに送信するなど、特定のアクションを実行できません。
デザイナーに戻る 監視ビューのツール バーで、[ 編集] を選択します。
天気取得ツールを作成する
エージェントが Azure Logic Apps で使用できる事前構築済みアクションを実行するには、エージェントが使用する 1 つ以上のツールを作成する必要があります。 ツールには、少なくとも 1 つのアクションとアクションのみを含める必要があります。 エージェントは、特定の引数を使用してツールを呼び出します。
この例では、エージェントには天気予報を取得するツールが必要です。 このツールは、次の手順に従ってビルドできます。
デザイナーで、エージェント内と [追加] ツールでプラス記号 (+) を選択し、使用可能なアクションを参照できるウィンドウを開きます。
[ アクションの追加 ] ウィンドウで、ロジック アプリの 一般的な手順 に従って、シナリオに最適なアクションを追加します。
この例では、現在の天気を取得という名前の MSN Weather アクションを使用 します。
アクションを選択すると、 ツール コンテナーと選択したアクションの両方がデザイナーのエージェントに表示されます。 両方の情報ウィンドウも同時に開きます。
ツール情報ウィンドウで、目的を説明するようにツールの名前を変更します。 この例では、
Get weatherを使用します。[ 詳細 ] タブの [ 説明] に、ツールの説明を入力します。 この例では、
Get the weather for the specified location.[ 説明] の [ エージェント パラメーター] セクションは、特定のユース ケースにのみ適用されます。 詳細については、「 エージェント パラメーターの作成」を参照してください。
次のセクションに進み、これらのユース ケースに基づいて、エージェント パラメーターとそのユース ケース、および作成方法の詳細を確認します。
"現在の天気を取得する" アクションのエージェント パラメーターを作成する
通常、アクションには、使用する値を指定する必要があるパラメーターがあります。 ツールのアクションは、1 つの違いを除いてほぼ同じです。 エージェントがツールのアクションのパラメーター値を指定するために使用するエージェント パラメーターを作成できます。 モデル生成の出力、モデル以外のソースからの値、または組み合わせを指定できます。 詳細については、「 エージェントパラメーター」を参照してください。
次の表では、エージェント パラメーターを作成するためのユース ケースと、そのユース ケースに基づいてそれらを作成する場所について説明します。
| 移行先 | エージェント パラメーターを作成する場所 |
|---|---|
| モデル生成の出力のみを使用します。 同じツール内の他のアクションと共有します。 |
アクション パラメーターから開始します。 詳細な手順については、「 モデル生成出力のみを使用する」を参照してください。 |
| モデル以外の値を使用します。 | エージェント パラメーターは必要ありません。 このエクスペリエンスは、Azure Logic Apps の通常のアクション セットアップ エクスペリエンスと同じですが、「 モデル以外のソースからの値を使用する」で便宜上繰り返されます。 |
| モデル生成の出力をモデル以外の値と共に使用します。 同じツール内の他のアクションと共有します。 |
ツールの [ エージェント パラメーター] セクションから開始します。 詳細な手順については、「 モデル出力とモデル以外の値を使用する」を参照してください。 |
モデル生成の出力のみを使用する
モデルで生成された出力のみを使用するアクション パラメーターの場合は、次の手順に従ってエージェント パラメーターを作成します。
ツールで、アクションを選択して情報ウィンドウを開きます。
この例では、アクションは [現在の天気を取得] です。
[ パラメーター ] タブで、パラメーター ボックス内を選択して、パラメーター オプションを表示します。
[ 場所 ] ボックスの右端にある星ボタンを選択します。
このボタンには、次のヒントがあります。 エージェント パラメーターを生成する場合に選択します。
[ エージェント パラメーターの作成 ] ウィンドウには、[ 名前]、[ 種類]、[ 説明] フィールドが表示され、ソース アクション パラメーターから事前に設定されます。
次の表では、エージェント パラメーターを定義するフィールドについて説明します。
パラメーター 価値 Description 名前 < agent-parameter-name> エージェント パラメーター名。 タイプ < エージェントパラメータデータ型> エージェント パラメーターのデータ型。 説明 < agent-parameter-description> パラメーターの目的を簡単に識別するエージェント パラメーターの説明。 注
Microsoft では、アクションの Swagger 定義に従うことをお勧めします。 たとえば、グローバルなマルチテナント Azure でホストおよび管理されている MSN Weather "共有" コネクタからの現在の天気の取得アクションについては、MSN Weather コネクタのテクニカル リファレンス記事を参照してください。
準備ができたら、 [作成] を選択します。
次の例は、Location エージェント パラメーターを使用した現在の天気の取得アクションを示しています。
ワークフローを保存します。
モデル以外のソースの値を使用する
モデル以外の値のみを使用するアクション パラメーター値の場合は、ユース ケースに最適なオプションを選択します。
ワークフローで以前の操作からの出力を使用する
これらの出力から参照して選択するには、次の手順に従います。
パラメーター ボックス内を選択し、稲妻アイコンを選択して動的コンテンツ リストを開きます。
一覧の [トリガーまたはアクション] セクションで、目的の出力を選択します。
ワークフローを保存します。
式の結果を使用する
式を作成するには、次の手順に従います。
パラメーター ボックス内を選択し、関数アイコンを選択して式エディターを開きます。
使用可能な関数から選択して式を作成します。
ワークフローを保存します。
詳細については、 Azure Logic Apps のワークフロー式関数のリファレンス ガイドを参照してください。
モデル出力とモデル以外の値を使用する
一部のシナリオでは、モデルで生成された両方の出力と非モデル値を使用するアクション パラメーター値を指定する必要がある場合があります。 たとえば、静的テキスト、ワークフロー内の以前の操作からのモデル以外の出力、モデルによって生成された出力を使用する電子メール本文を作成できます。
これらのシナリオでは、次の手順に従って、ツールでエージェント パラメーターを作成します。
デザイナーで、エージェント パラメーターを作成するツールを選択します。
[ 詳細 ] タブの [ エージェント パラメーター] で、[ パラメーターの作成] を選択します。
[ 新しいエージェント パラメーター] を展開し、次の情報を指定しますが、アクション パラメーターの詳細と一致します。
この例では、アクションの例は Get current weather です。
注
Microsoft では、アクションの Swagger 定義に従うことをお勧めします。 たとえば、 現在の天気の取得 アクションに関するこの情報を確認するには、 MSN Weather コネクタのテクニカル リファレンス記事を参照してください。 このアクションの例は、マルチテナント Azure 上の共有クラスターでホストおよび実行される MSN Weather マネージド コネクタによって提供されます。
パラメーター 価値 Description 名前 < agent-parameter-name> エージェント パラメーター名。 タイプ < エージェントパラメータデータ型> エージェント パラメーターのデータ型。 説明 < agent-parameter-description> パラメーターの目的を簡単に識別するエージェント パラメーターの説明。 次のオプションから選択するか、それらを組み合わせて説明を指定できます。
- パラメーターの目的、許可される値、制限、制限などの詳細を含むプレーン リテラル テキスト。
- ワークフロー内の以前の操作からの出力。 これらの出力を参照して選択するには、[ 説明 ] ボックス内を選択し、稲妻アイコンを選択して動的コンテンツ リストを開きます。 一覧から、目的の出力を選択します。
- 式の結果。 式を作成するには、[ 説明 ] ボックス内を選択し、関数アイコンを選択して式エディターを開きます。 使用可能な関数から選択して式を作成します。完了すると、[ エージェント パラメーター] の下に新しいエージェント パラメーターが表示されます。
デザイナーのツールで、アクションを選択してアクション情報ウィンドウを開きます。
[ パラメータ ]タブで、パラメータボックス内を選択してパラメータオプションを表示し、ロボットアイコンを選択します。
[エージェント パラメーター] ボックスの一覧から、前に定義したエージェント パラメーターを選択します。
完成した [現在の天気の取得] ツールは、次の例のようになります。
ワークフローを保存します。
[電子メールの送信] ツールを作成する
多くのシナリオでは、通常、エージェントには複数のツールが必要です。 この例では、エージェントには、天気予報を電子メールで送信するツールが必要です。
このツールをビルドするには、次の手順に従います。
デザイナーのエージェントで、既存のツールの横にあるプラス記号 (+) を選択してアクションを追加します。
[ アクションの追加 ] ウィンドウで、次の 一般的な手順 に従って、新しいツールの別のアクションを選択します。
例では、電子メールの送信 (V2) という名前の Outlook.com アクションを使用します。
前と同様に、アクションを選択すると、新しい ツール とアクションの両方が、デザイナーのエージェント内に同時に表示されます。 両方の情報ウィンドウが同時に開きます。
ツール情報ウィンドウで、目的を説明するようにツールの名前を変更します。 この例では、
Send emailを使用します。[ 詳細 ] タブの [ 説明] に、ツールの説明を入力します。 この例では、
Send current weather by email.
"電子メールの送信 (V2)" アクションのエージェント パラメーターを作成する
電子 メールの送信 (V2) アクションに設定するさまざまなエージェント パラメーターを除き、このセクションの手順は 、[現在の天気の取得] アクションのエージェント パラメーターの作成とほぼ同じです。
前の一般的な手順に従って、[ 電子メールの送信 (V2)] アクションでパラメーター値のエージェント パラメーターを作成します。
アクションには、 To、 Subject、 Body という名前の 3 つのエージェント パラメーターが必要です。 アクションの Swagger 定義については、「 メールの送信 (V2)」を参照してください。
完了すると、アクションの例では、次に示すように、前に定義したエージェント パラメーターが使用されます。
完成した 電子メール送信 ツールは、次の例のようになります。
エージェントとツールのベスト プラクティス
次のセクションでは、より優れたエージェントとツールの構築に役立つ推奨事項、ベスト プラクティス、およびその他のガイダンスについて説明します。
Agents
次のガイダンスでは、エージェントのベスト プラクティスを示します。
"Compose" アクションを使用したエージェントとツールのプロトタイプ作成
実際のアクションとライブ接続を使用してエージェントとツールのプロトタイプを作成するのではなく、 Compose アクション を使用して実際のアクションを "モック" またはシミュレートします。 この方法には次のような利点があります。
作成 アクションでは副作用が発生しないため、これらのアクションはイデーション、設計、テストに役立ちます。
エージェントの指示、プロンプト、ツール名、説明に加えて、エージェントのパラメーターと説明を下書きして調整できます。ライブ接続を設定して使用する必要はありません。
エージェントとツールが Compose アクションでのみ動作することを確認すると、実際のアクションを入れ替える準備が整います。
実際のアクションに切り替えるときは、エージェント パラメーターを再ルーティングまたは再作成して、実際のアクションを操作する必要があります。時間がかかる場合があります。
チャット履歴コンテキストの長さを管理する
ワークフロー エージェントは、次の対話のために保持してモデルに渡すトークンまたはメッセージの数に関する現在の制限に基づいて、ツール呼び出しを含むチャット履歴またはコンテキストを保持します。 時間の経過と同時に、エージェントの履歴が拡大し、最終的にモデルの コンテキスト長 の制限または入力トークンの最大数を超えます。 モデルはコンテキストの長さが異なります。
たとえば、 gpt-4o では 128,000 個の入力トークンがサポートされています。各トークンの文字数は 3 から 4 文字です。 エージェント履歴がモデルのコンテキスト長に近づく場合は、古いメッセージまたは無関係なメッセージを削除して制限を超えないようにすることを検討してください。
エージェント履歴を減らす方法を次に示します。
[作成] アクションを使用して、ツールの結果のサイズを小さくします。 詳細については、「 ツール - ベスト プラクティス」を参照してください。
エージェントの指示とプロンプトを慎重に作成して、モデルの動作を制御します。
試験段階の機能: チャット履歴に保持してモデルに渡すトークンまたはメッセージの最大数を減らすことができるように、チャットの削減を試すことができます。
ワークフロー エージェントには、 Azure OpenAI 組み込みのサービス プロバイダー コネクタとほぼ同じ高度なパラメーターがあります。ただし、 エージェント履歴の縮小の種類 の高度なパラメーターは、エージェントにのみ存在します。 このパラメーターは、トークンまたはメッセージの最大数に基づいて、エージェントが保持する履歴を制御します。
この機能はアクティブな開発段階にあり、すべてのシナリオで動作しない場合があります。 [エージェント履歴の削減の種類] オプションを変更して、トークンまたはメッセージの制限を減らすことができます。 次に、必要な数値の制限を指定します。
この機能を試すには、次の手順に従います。
デザイナーで、エージェントのタイトル バーを選択して情報ウィンドウを開きます。
[ パラメーター ] タブで、[ 高度なパラメーター ] セクションを見つけます。
Agent History Reduction Type という名前のパラメーターが存在するかどうかを確認します。 そうでない場合は、[ 詳細パラメーター ] ボックスの一覧を開き、そのパラメーターを選択します。
[エージェント履歴の削減の種類] ボックスの一覧から、次のいずれかのオプションを選択します。
Option Description トークン数の削減 [最大トークン数] という名前のパラメーターを表示します。 エージェント履歴に保持し、次の対話のためにモデルに渡すトークンの最大数を指定します。 既定値は、Azure OpenAI サービスで現在使用されているモデルによって異なります。 既定の制限は 128,000 です。 メッセージ数の削減 Message Count Limit という名前のパラメーターを表示します。 エージェント履歴に保持し、次の対話のためにモデルに渡すメッセージの最大数を指定します。 既定の制限はありません。
Tools
次のガイダンスでは、ツールのベスト プラクティスを示します。
この名前は、ツールにとって最も重要な値です。 名前が簡潔でわかりやすいものになっていることを確認します。
ツールの説明では、ツールに役立つ便利なコンテキストが提供されます。
ツール名と説明の両方に文字制限があります。
一部の制限は、ワークフロー内のエージェントに変更を保存する場合ではなく、実行時に Azure OpenAI Service のモデルによって適用されます。
同じエージェント内のツールが多すぎると、エージェントの品質に悪影響を及ぼす可能性があります。
適切な一般的なガイドラインでは、エージェントに含まれるツールは 10 個以下にすることをお勧めします。 ただし、このガイダンスは、Azure OpenAI サービスから使用するモデルによって異なります。
ツールでは、アクションがすべての入力をモデルから取得する必要はありません。
モデル以外のソースからのアクション入力と、モデルからの入力を細かく制御できます。 たとえば、ツールに電子メールを送信するアクションがあるとします。 プレーンでほとんど静的な電子メール本文を提供できますが、その電子メール本文の一部にはモデル生成の出力を使用します。
モデルに渡す前に、ツールの結果をカスタマイズまたは変換します。
作成アクションを使用して、モデルに渡す前にツールから結果を変更できます。 この方法には次のような利点があります。
モデルに渡される無関係な コンテキスト を減らすことで、応答の品質を向上させます。 大きな応答から必要なフィールドのみを送信します。
モデルに渡されるトークンの課金料金を減らし、モデルに渡されるトークンの最大数である コンテキスト長に対するモデルの制限を超えないようにします。 必要なフィールドのみを送信します。
ツール内の複数のアクションの結果を結合します。
ツールの結果をモックして、実際のアクションから予想される結果をシミュレートできます。 モック アクションは、データをソースで変更せず、Azure Logic Apps の外でのリソース使用に対する料金も発生しません。
エージェント パラメーター
次のガイダンスでは、エージェント パラメーターのベスト プラクティスを示します。
名前は、エージェント パラメーターの最も重要な値です。 名前が簡潔でわかりやすいものになっていることを確認します。
エージェント パラメーターの説明は、ツールに役立つ便利なコンテキストを提供します。
ワークフローをトリガーまたは実行する
デプロイ環境に基づいて、次の方法で会話型エージェント ワークフローをトリガーまたは実行できます。
| 環境 | Description |
|---|---|
| 非プロダクション | ワークフロー デザイナーのツール バーで、[ チャット ] を選択して、Azure portal で会話エージェントとのチャット セッションを手動で開始します。 重要: このメソッドは、テスト アクティビティのみを対象としています。 ポータル ベースのテストでは、一時開発者キーを使用します。 外部ユーザーまたは運用システムでは、このキーを使用できません。 詳細については、「認証と承認」を参照してください。 |
| 生産 | 外部ユーザーまたは Web サイト、モバイル アプリ、ボット、その他の Azure サービスなどのクライアントが会話エージェントにアクセスするための認証を設定する必要があります。 その後、チャット クライアント URL を使用してワークフローをトリガーできます。 |
次の表では、チャット ユーザーまたはクライアントがチャット クライアント URL を使用して運用環境でワークフローを実行する方法について説明します。
| ワークフローの種類 | チャット クライアントの URL の使用 | 必要な認証 |
|---|---|---|
| 消費 | ブラウザーで URL を開くか、 iFrame HTML 要素に URL を埋め込みます。 | Microsoft Entra ID を使用した OAuth 2.0 |
| 標準 | ブラウザーで URL を開き、 iFrame 要素に URL を埋め込むか、 要求 トリガーを使用する場合は、トリガーの HTTP URL を呼び出します。 | マネージド ID または Easy Auth |
チャット クライアント URL を iFrame HTML 要素に埋め込むには、次の形式を使用します。
| ワークフローの種類 | iFrame HTML 要素 |
|---|---|
| 従量課金 | <iframe src="https://agents.<region>.logic.azure.com/scaleunits/<scale-unit-ID>/flows/<workflow-ID>/agentChat/IFrame" title="<chat-client-name>"></iframe> |
| Standard | <iframe src="https://<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe> |
認証と承認
設計、開発、クイック テストなどの非運用アクティビティの場合、Azure portal は 開発者キー を提供、管理、使用してワークフローを実行し、ユーザーに代わってアクションを実行します。 次の一覧では、この開発者キーを処理するためのベスト プラクティスをいくつかお勧めします。
開発者キーは、認証と承認のための設計時の利便性としてのみ厳密に扱います。
会話型エージェントを他のエージェント、自動化、またはより広範なユーザー集団に公開する前に、会話型エージェントワークフローの種類に基づいて、ネットワーク制限または次の外部チャットの認証および承認方法を使用して署名済み SAS に移行します。
Workflow Authentication 従量課金 Microsoft Entra ID を使用した OAuth 2.0 Standard マネージド ID、 Easy Auth (App Service 認証) 基本的に、Azure portal セッション外のユーザーまたは何かがワークフローを呼び出したり操作したりする必要がある場合、開発者キーは適切ではなくなります。
エージェント ワークフローを運用環境にリリースする準備ができたら、必ず移行手順に従って 運用の認証と承認を準備してください。 詳細については、「認証と承認」を参照してください。
運用環境の認証に移行する
ロジック アプリ リソースで、ワークフローの種類に基づいて次の認証を設定します。
Workflow Authentication 従量課金 ロジック アプリ リソースでエージェント承認ポリシーを作成し、Microsoft Entra ID を使用して OAuth 2.0 を導入します。
このポリシーを作成するには、次の手順に従います。
1. 一般的な手順に従ってポリシーを作成しますが、代わりに次の手順を実行します。
2. Azure Active Directory (AAD) を選択します。
3. エージェント承認規則 (会話エージェントの場合) を選択します。
4. [オブジェクト ID] で、エージェントにアクセスできるユーザー、アプリ、またはエンタープライズ アプリごとにオブジェクト ID を入力します。
5. 完了したら、ツール バーの [保存] を選択 します。
詳細については、以下を参照してください。
- ユーザーの重要な ID を見つける
- Microsoft Entra ID のアプリケーション およびサービス プリンシパル オブジェクトStandard マネージド ID、 Easy Auth (App Service 認証) 認証に必要なアクセス パターンを適用します。
必要に応じて、未使用の SAS URL を無効または再生成して、トリガー エンドポイント URL をロックダウンします。
外部チャット クライアント インターフェイスを Web サイトまたは他の場所に含めて人間の対話をサポートするには、次の手順に従ってチャット クライアント URL を取得し、 iFrame HTML 要素 に URL を埋め込みます。
デザイナーのツール バーまたはワークフロー サイドバーで、[ チャット] を選択します。
[ 要点 ] セクションで、[ チャット クライアント URL ] リンクをコピーまたは選択すると、新しいブラウザー タブが開きます。
次の形式を使用する iFrame HTML 要素にチャット クライアント URL を埋め込みます。
Workflow iFrame HTML 要素 従量課金 <iframe src="https://agents.<region>.logic.azure.com/scaleunits/<scale-unit-ID>/flows/<workflow-ID>/agentChat/IFrame" title="<chat-client-name>"></iframe>Standard <iframe src="https://<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe>
認証移行のトラブルシューティング
次の表は、開発者キーから Easy Auth に移行しようとしたときに発生する可能性のある一般的な問題、考えられる原因、および実行できるアクションを示しています。
| 症状 | 考えられる原因 | アクション |
|---|---|---|
| ポータル テストは機能しますが、外部呼び出しでは 401 応答が返されます。 | 外部呼び出しには、有効な署名付き SAS トークンまたは Easy Auth アクセス トークンがありません (標準ワークフローのみ)。 | 署名済みの SAS でワークフロー トリガー URL を使用するか、Easy Auth を設定します (標準ワークフローのみ)。 |
| デザイナー テストは機能しますが、Azure API Management の呼び出しは失敗します。 | API Management の呼び出しには、必要なヘッダー情報がありません。 | API Management ポリシーで OAuth 2.0 トークンの取得を追加するか、サポートされている場合はマネージド ID 認証を使用します。 |
| ロールが変更された後、アクセスに一貫性がありません。 | Azure portal でキャッシュされたセッション | - サインアウトしてもう一度サインインします。 - 新しいトークンを取得します。 |
問題の診断
このセクションでは、エージェント ワークフローをビルドまたは実行するときに発生する可能性のあるエラーや問題のトラブルシューティングに役立つガイダンスについて説明します。
ツールの実行データを確認する
ワークフロー実行履歴には、特定の実行中に何が起こったかを知るのに役立つ有用な情報が用意されています。 エージェント ワークフローの場合、特定のエージェント ループイテレーションのツール実行の入力と出力を見つけることができます。
ワークフロー メニューの [ ツール] で [ 実行履歴 ] を選択し、[ 実行履歴 ] ページを開きます。
[ 実行履歴 ] タブの [ 識別子 ] 列で、目的のワークフロー実行を選択します。
監視ビューが開き、各ステップの状態が表示されます。
検査するエージェントを選択します。 右側に、[ エージェント ログ ] ウィンドウが表示されます。
このウィンドウには、操作中のツールの実行を含むエージェント ログが表示されます。
特定の時点でツール実行データを取得するには、エージェント ログでそのポイントを見つけて、ツール実行参照を選択します。次に例を示します。
このアクションにより、監視ビューの一致するツールに移動します。 エージェントは、現在のイテレーション数を表示します。
監視ビューで、確認する入力、出力、およびプロパティを含むエージェントまたはアクションを選択します。
次の例は、以前に選択したツールの実行に対して選択したアクションを示しています。
エージェントを選択した場合、モデルに渡され、モデルから返される次の情報を確認できます。たとえば、次のようになります。
- モデルに渡される入力メッセージ。
- モデルから返された出力メッセージ。
- モデルがエージェントに呼び出しを求めたツール。
- モデルにフィードバックされたツールの結果。
- 各要求で使用されたトークンの数。
別のエージェント ループイテレーションを確認するには、エージェントで左矢印または右矢印を選択します。
Application Insights のログ
ワークフローの Application Insights または高度なテレメトリを設定した場合は、他のアクションと同様に、エージェント イベントのログを確認できます。 詳細については、「 Azure Logic Apps の標準ワークフローの Application Insights で拡張テレメトリを有効にして表示する」を参照してください。
モデルの最大コンテキスト長を超えました
エージェントのログ履歴がモデルの コンテキスト長または入力トークンの最大数を超えている場合は、次の例のようなエラーが発生します。
このモデルの最大コンテキスト長は 4097 トークンです。 ただし、4927 トークン (メッセージでは 3927、完了時は 1000) を要求しました。 メッセージまたは完了の長さを短くしてください。
エージェントがログに保持し、次の対話のためにモデルに渡すトークンまたはメッセージの数の制限を減らしてみてください。 この例では、[ トークン数の削減 ] を選択し 、[最大トークン数 ] をエラーの指定された最大コンテキスト長 ( 4097) より下の数値に設定できます。
詳細については、「 チャット履歴のコンテキスト長の管理」を参照してください。
サンプル リソースをクリーンアップする
例用に作成したリソースが不要な場合は、引き続き課金されないようにリソースを削除してください。 これらの手順に従って、これらのリソースを含むリソース グループを削除することも、各リソースを個別に削除することもできます。
Azure 検索ボックスに「 リソース グループ」と入力し、[ リソース グループ] を選択します。
この例のリソースを含むリソース グループを見つけて選択します。
[ 概要 ] ページで、[ リソース グループの削除] を選択します。
確認ウィンドウが表示されたら、リソース グループ名を入力し、[削除] を選択 します。