エージェント的行動工学

大規模言語モデル (LLM) は、本質的に非決定論的です。 同じ入力が常に同じ出力を生成するとは限りません。 従来のテスト方法では、この変動を考慮に入れるのに苦労しています。 システムが期待どおりに一貫して動作する自信を持てるように、開発プロセスをどのように適応させることができますか?

エンタープライズの AI 変革は、さらなる問いを投げかけています。すなわち、独自の知見をどのように保護し、ガバナンスを効かせるのか、という点です。 信頼性の高い動作をどのように設計しますか? 実行証跡を使用して、時間の経過とともにシステムを改善するにはどうすればよいでしょうか。

エージェント行動エンジニアリング (ABE) は、この記事で提案されているように、AI エージェントの動作を指定、グラウンディング、制御、検証、および観察するためのプラットフォームに依存しない手法です。 この手法は、ユーザーとシステムのニーズを明確にし、期待される結果を定義し、実行の境界を設け、代表的なシナリオに対して変更を検証するのに役立ちます。 従来のテストでは、特定の実装が期待どおりに動作することを確認できますが、多くの場合、モデル、プロンプト、ツール、またはデータ ソースの変更に起因する挙動のずれを完全に検出できません。 ABE は、望ましい動作を明示的かつ継続的に検証できるようにすることで、この課題に対処し、チームが結果に対する信頼を失うことなくエージェント システムを進化させることができます。

主な概念

ABE の主要なアーティファクトは動作コントラクトです。 コントラクトは、必要な動作を実装とは別に定義して、システムの変更に応じて期待が明示的かつ検証可能なままになるようにします。 エージェント型システムでは、モデル、プロンプト、ツールの実装、ナレッジ ソース、メモリ、ポリシー、オーケストレーション、ユーザー アクセスはすべて時間の経過と同時に変化する可能性があります。 動作コントラクトを使用して、これらの変更が必要な動作に及ぼす影響を評価し、ドリフトを特定して対処します。

コントラクトの動作

行動コントラクトは、ある特定の状況下において、エージェントが何をすべきか、また何をしてはならないかを規定するものです。 次を指定します。

• 契約が適用される状況、関係者、および適用範囲。
• 許容できる結果と必要な結果の特性。
• 禁止される結論、開示、操作、および副作用。
• エージェントが結論を出すまたは行動する前に必要な証拠。
• 証拠が不十分な場合、または依存関係が失敗した場合の動作。
• エスカレーション、承認、停止条件。

この契約により、適用可能なセキュリティと責任ある AI 要件が明示的になります。 設計時にこれらの要件を定義して、チームが最初から実装と検証に組み込むことができるようにします。 責任とワークロード固有のポリシーの定義に関するガイダンスについては、「Azureワークロードにおける責任ある AI」を参照してください。

動作コントラクトは、ソフトウェアの義務を明示的にするという、契約による設計と同じ原則を共有します。 実装を規定せずに必要な動作を定義するため、実装が変更されても要件は安定したままでいられます。

1 つの限定された状況に対して 1 つのコントラクトを使用し、そのバリエーションに複数のシナリオを使用します。 アクター、権限、必要な証拠、または許容可能な結果が大きく変化したときに、別のコントラクトを作成します。

製品チームとエンジニアリング チームは、動作契約をバージョン管理された資産として共同で維持します。 ドメインの専門家によってサポートされているプロダクトオーナーは、意図した動作と予想される結果を承認します。 エンジニアリングは、技術的な制約と証拠の要件を共同作成し、テスト可能なシナリオ定義、カバレッジ、バージョン管理、検証を維持します。

行動の期待に対する変更を共同で確認し、必要に応じてセキュリティとリスクのレビューを実行します。 これらの期待を維持する技術的なメンテナンスは、チームのエンジニアリング レビュー プロセスに従う必要があります。 関連するガイダンスについては、機能仕様の担当範囲とテスト戦略の責任を参照してください。

例: リスクの低い製品レビューを承認する

小売 Web サイトでは、公開前に、審査チームが顧客の製品レビューを適正利用ポリシーと照らして確認する必要があります。 ワークロード チームは、エージェントがリスクの低い申請を承認し、リスクの高いケースや不確実なケースを標準チームに送信することを望んでいます。 目標は、サイトの発行基準を維持しながら、手動レビューを減らすことです。

次の表に、このエージェントのバージョン管理された動作コントラクトを示します。

コントラクトは、JSON、YAML、Markdown、Word ドキュメント、または PDF に保持できます。 プロダクトオーナー、ドメイン エキスパート、エンジニアがレビューおよび共同でバージョン管理できる形式を選択します。 JSON または YAML を使用すると、ツールで個々のフィールドを簡単に読み取ることができます。 選択した形式に関係なく、信頼できる唯一の正本を保持し、シナリオと評価結果をそれにリンクします。

この例では、このポリシーは否定的な製品フィードバックを許可し、個人情報を含む提出物の人間によるレビューを必要とします。 顧客の送信内容:

バッテリーの寿命はわずか1時間。 私は再びそれを買うことはありません。

予想される決定は、申請を承認することです。 決定レコードは、該当するポリシールールを引用し、テキストが製品のエクスペリエンスを説明し、このポリシーの下で人によるレビューを必要とするコンテンツを含まないことを説明します。

提出に個人情報が含まれている場合、予想される決定は、人による審査に回し、非公開にしておくことです。 現在のポリシーを取得できない場合、申請も非公開のままです。

承認されたレビューを公開する前に、アプリケーションはアクセス許可を適用し、送信を確認します。 エージェントの決定を評価するには、その提出物に対する標準チームの予想される決定と比較します。

シナリオライブラリ

シナリオ ライブラリは、動作コントラクトを具体的なユーザー シナリオに変換します。 各シナリオでは、クエリまたはタスク、証拠と依存関係の条件、および予想される結果を定義します。 コントラクトの要件を変更せずに動作コントラクトを適用します。

製品とドメインの専門家は、シナリオと期待される結果を検証します。 エンジニアリングでは、コントラクトの定義とカバレッジを維持します。

次の表は、シナリオ ライブラリが製品レビュー エージェントの代表的な状況に動作コントラクトを適用する方法を示しています。

合成ケース (架空の提出とシミュレートされたポリシー サービス応答) でテストを開始します。 グラウンド トゥルース データを収集すると、エンジニアリング チームが機能の実装の完了を妨げる可能性があります。 合成ケースは、コントラクトまたは実装のギャップを明らかにし、ドメインの専門家に正解データの整備を完了する時間を与えます。

合成ケースを使用して、個別のゴールデン データセットの実際のワークロード ケースを収集する際に、対象分野の専門家 (SME) をガイドします。 ゴールデン データセットは、実際のクエリ、対応する証拠、SME で検証された期待される結果など、同じ構造を使用してシナリオの範囲を広げます。 1 つのシナリオには、多くのゴールデン ケースが含まれる場合があります。

否定的なレビューのシナリオでは、標準チームは、製品を批判するが、公開ポリシーを満たす実際の投稿を収集します。 承認されたテスト入力と適用可能なポリシー バージョンを保持し、期待される決定を確立します。 合成ケース ガイド集。 これらはゴールデン データセットに昇格されません。

グラウンド・トゥルースは、エージェントの記録された出力ではなく、正確性を確立できるドメイン検証済みの期待される結果または証拠です。 評価に適したデータを使用するを参照してください。

概念実証中にシナリオを使用して、同一の契約条件とコストおよび待機時間の制限に対して実装を比較します。 製品レビュー エージェントでは、承認の決定をテストし、標準化チームの予想される結果に対する引き継ぎを行います。 設計とトレードオフを アーキテクチャの決定レコードに記録し、回帰テストのシナリオを保持します。

各ケースをシナリオとコントラクト のバージョンにリンクし、それが合成であるか、実際のワークロード データから取得されたかを記録します。 プロンプトに依存しないシナリオを維持し、実装の変更に応じて必要な動作をテストできるようにします。

境界ケースを追加し、レビューした本番障害。 セキュリティ境界がスコープ内にある場合は、AI レッド チーミングと脅威モデリングにおけるプロンプトインジェクション、誤用、および情報窃取シナリオを含めます。

開発、回帰、および保護対象のリリースセットを別々に保ちます。 リリース検証用にいくつかのテスト ケースを確保し、それらを使用して実装を開発または調整しないでください。 これらのケースとその期待される結果へのアクセスを制限します。 ケースが実装の変更をガイドする場合は、それを回帰スイートに移動し、ドメインエキスパートによって検証された別のケースに置き換えます。

動作範囲

動作範囲は、ワークロードの非機能要件の一部をカバーします。 レイテンシ、コスト、トークン使用量、再試行、ツール呼び出し、承認の待機に費やされた時間など、リソースと実行の制限を定義します。

コントラクトは正しい動作を定義します。 エンベロープは、システムが動作しなければならない運用限界を定義します。 コントラクトは、これらの制限が受け入れ基準の一部である場合に、オペレーティング エンベロープ バージョンを参照できます。 エンベロープを個別にバージョン管理し、変更されなかった動作要件を再定義することなく運用制限を変更できるようにします。 ビヘイビア コントラクトとオペレーティング エンベロープでは、1 対 1 のリレーションシップは必要ありません。

Replay

リプレイの設計

名前が示すように、再生では、収集されたツールと API 応答または RAG 結果を提供して、システムの推論手順を再実行します。 このアプローチは、プロンプトを調整し、不足している証拠を特定するのに役立ちます。 これは、ライブ API またはモデル コンテキスト プロトコル (MCP) ツールへの繰り返しの呼び出しを避けます。これらは、コストが高い、レート制限される、または時間の経過とともに変化するデータを返す可能性があります。

運用環境でリプレイデータを収集します。 分析または SME レビューの前に、ポリシーに従って機密データを削除またはマスクします。 ケースの意味を変更せずに、応答ペイロードとその要求引数を保持します。 黒塗りによって必要な証拠が削除された場合は、承認済みのテンプレートを使用して制限を文書化します。

本番環境由来のデータをゴールデン データセットに追加したり、テスト ダブルの作成に使用したりする前に、SME によるレビューと精査を行ってください。 テスト ダブルは応答をシミュレートできるため、再生では、運用データを必要とせずに新規および既存のシナリオをサポートできます。 Dev Proxy を使用したモック応答 と Microsoft Foundry の評価データセット を参照してください。

リプレイの構成と実行

評価と回帰テストに使用する再生データセットをバージョン管理します。 更新プログラムとベースラインを比較するには、同じケースとエバリュエーター のバージョンを使用して、同じデータセット バージョンに対して両方の実装を実行します。 テスト中の変更を除き、他のテスト条件は同一に保ちます。 ケースを追加または修正するときは、新しいデータセット バージョンを作成し、両方の実装を再実行します。

開発中は、より小さなケース セットを再実行して、変更している動作を確認できます。 新しいシナリオの記録済み応答がまだない場合は、シミュレーションによる応答を使用し、データセット内でそれらにラベルを付けてください。

実行の目的を選択してください：

実行構成は、データセットや評価器にとどまりません。 また、プロンプト、モデル、API/MCP サーバー、サポート ライブラリなどが含まれます。 評価を実行するときは、明確な仮説と関連する変更を行い、各実行で最小限のセットのみが変更されるようにする必要があります。 これにより、影響を正しく測定し、記録管理の不備のために同じ更新プログラムを複数回実行しないようにすることができます。

Replayによって単体テストまたは統合テストが置き換えられることはありません。 各テストはソフトウェア システムの異なる側面をチェックし、同様に重要です。 「AI ワークロードのテストと評価」を参照してください。

次の図は、共有リプレイ プロセスを示しています。

例：製品レビューエージェントの変更を確認する

製品レビュー エージェントのリリース 42 が、個人情報が含まれているために標準化チームに提出する必要がある申請を承認するとします。 チームは、リプレイ データセーフガードを使用してケースを準備し、重点的な開発テストを使用して、候補 43 の実装を修正します。

1. 候補 43 の評価実行を設定します。 評価データセットには、通常のケースだけでなく、ポリシーに準拠した否定的なレビュー、不確かな投稿、依存関係エラーも含める必要があります。 それを、機能 (個人情報ルール) をテストするケースで更新します。 更新により、データセットの新しいバージョンが作成されます。 新しいデータセットで評価とベースラインを実行します。 完全なデータセットを再生して、シナリオごとの意思決定の精度、コスト、待機時間を測定します。

2. リリース検証データセットを新しいユース ケースで更新し、更新されたバージョンを取得してください。 展開されたデータセットのバージョンを参照し、受け入れのしきい値を設定します。 同じ拡張スイートと記録された証拠に対して候補 43 とベースライン 42 を再実行します。

3. 既存のケースと新しいケースを、レビュー済みの想定結果に照らして確認します。 要件に適合する否定的なフィードバックには approve を、個人情報を含む送信内容には human_review が想定されます。 人によるレビュー待ちの投稿が非公開のままであることを確認します。

4. 結果とケースごとのトレースを構成バージョンとともに保存します。 各シナリオのメトリックを計算します。 評価結果を使用して実装を改善し、リリースの検証結果を基に候補を出荷できるかどうかを決定します。 全体的な改善がなされたとしても、必須要件を満たせなかったという事実は覆りません。

Architecture

ABE 手法を使用してワークロードの機能を設計するには、問題の検出から始めて、コントラクト内で予想される動作をキャプチャします。 次に、ワークロードにエージェントによる実行が必要かどうかを判断します。 ビジネスオーナーおよびエンジニアリング チームと協力して、ユーザーのニーズと前提条件を明確にします。 動作コントラクトからシナリオを導き出し、システムが必要とする知識と証拠を特定し、周囲のシステムが適用する必要があるコントロールを決定します。

動作コントラクトとシナリオ ライブラリは、2 ループ システムを接続し、実装と改善をガイドします。 開発者のインナーループは、リリース前に変更を検証します。 本番環境の外部ループでは、実行の証拠やフィードバックを収集し、障害や要件の変更を特定します。

ABE は、この作業を 5 つのエンジニアリング上の責務: 指定、基板、制御、検証、観察 に整理します。 これらの責務は論理的なものであり、5 つの必要なサービスやシーケンシャルなランタイム ステップではありません。 1 つの機能に対する作業は、複数の責務に及ぶ可能性があります。

責任ある AI とセキュリティは、5 つの責務すべてに共通する横断的な懸念事項です。 指定の責務により、行動コントラクトで責任ある AI の期待とセキュリティ要件が明示的になります。 制御の責務は、これらの要件を支えるアクセス規則と実行時の保護策を実装します。

Specify と ground は、プロジェクトの準備状況と実現可能性に関する早期チェックを提供します。 指定では、問題と成功条件が確立されます。 Ground は、該当するアクセス要件の下で必要な情報が利用可能で使用可能かどうかを評価します。 これらの結果を使用して、実装にコミットする前にギャップを特定し、概念実証で残りの前提条件を検証します。 詳細については、「 技術戦略をビジネス要件に合わせる」を参照してください。

ビヘイビア コントラクトとシナリオ ライブラリを使用して、実行可能な設計を比較します。 決定論的な実装またはモデル支援の手順を使用した固定ワークフローは、要件を満たす場合があります。 評価によって、追加のコスト、待機時間、運用の複雑さを正当化できる利点が示される場合は、エージェント型アプローチを選択します。 実行アプローチの選択に関するガイダンスについては、固定ワークフローとエージェント主導システムの比較を参照してください。

指定

設計思考を使用して、自動化する内容と方法を選択する前に、ユーザーの実際のニーズを理解します。 ユーザー、ビジネスオーナー、および専門家と協力して、許容可能な結果、制約、および障害時の動作について合意します。

バージョン管理された動作コントラクトでこれらの要件をキャプチャし、シナリオ ライブラリを作成するためのテスト シナリオを導き出します。 製品チームとエンジニアリング チームは、期待される動作への変更を一緒に確認します。 責任ある AI とセキュリティの問題に対処するには、ドメインの専門家、リスク スペシャリスト、セキュリティ スペシャリストを関与させます。 動作コントラクトとシナリオ ライブラリの両方をバージョン管理します。 リリース ノートでは、サポート対象として公開されているコントラクトとシナリオ ライブラリのバージョンを特定する必要があります。

製品ロードマップと共に要件の変更を確認し、それらに対する実装を再確認します。 マルチエージェント ワークロードの場合は、エンドツーエンドのコントラクトを定義し、責任、証拠の要件、またはアクセス許可が変更される場合は、ハンドオフ コントラクトを追加します。

製品レビュー エージェントについては、どの申請が自動承認の対象となるか、人によるレビューが必要となるのはどのような場合か、またポリシーまたはレビュー キューを利用できない場合にどのように対処するかについて、標準チームと合意します。

次の図は、動作コントラクトとシナリオ ライブラリが実装と検証をどのようにガイドするかを示しています。 シナリオ ライブラリを使用して、ゴールデン データセットのキュレーションをガイドし、評価基準を定義します。 テストされたケースの数など、シナリオ別に結果を報告し、全体的なスコアでギャップが隠されないようにします。 評価と運用から得られた結果を確認すると、シナリオ ライブラリまたは動作コントラクトが更新される可能性があります。

発見手法については、ユーザー調査を実施し、得られた知見を共有するを参照してください。

地面

Ground は、取得した情報、ツールの応答、ビジネス ルール、メモリなど、エージェントに渡す知識と根拠を規定します。 ソースと権威性を保持しながら、各タスクの関連する承認された情報を準備します。 来歴、鮮度、感度は、適切に表現する必要があるいくつかの重要な属性です。

エージェント向けに管理対象情報を準備するには:

• 信頼できるソースを選択し、それらを維持管理する担当者を割り当てます。
• アクセス要件を特定し、制御の責任のアクセス許可と秘密度メタデータを保持します。
• エージェントがビジネス上の意味、ソース、またはバージョンを失うことなく使用できる形式で情報を準備します。

設計時に、情報源がビヘイビア契約に必要な証拠を提供できることを確認します。 製品レビュー エージェントの場合は、各評価を完全な提出テキスト、そのリビジョン、および適用可能なポリシー バージョンにリンクします。 必要な証拠がないか、アクセスできない場合は、データまたはアクセスの問題を解決するか、スコープを絞り込むか、該当する機能を保留します。

実行時に、取得レイヤーは、検索でデータが返されたか、一致するものが見つからなかったか、または失敗したかを報告します。 アプリケーションは、その状態を証拠メタデータと共に使用して、続行するか、不十分な証拠に対する契約で定義された応答に従うかを決定します。

プロンプトやモデルに関係なく、ワークロード所有のバージョン管理された資産にビジネス定義とルールを保持します。 データ コントラクトまたはセマンティック モデルを使用して、他のエージェントやシステムと交換される情報の構造と意味を定義します。

次の表は、業務上の定義と特定のリクエストに対する証跡を区別しています。 オントロジプラットフォームまたはセマンティックモデルプラットフォームは、エージェントとシステムが共有ビジネスの概念と関係を必要とする場合に、これらの定義を整理するのに役立ちます。

実装例については、Fabric オントロジ データ バインディング (プレビュー) とPower BI セマンティック モデルを参照してください。

結果をエージェントに渡す前に、決定論的コードでビジネス ルールを適用するルール エンジンまたはワークフローを確立できます。 ドメイン でレビューされたケースに対してこれらの規則を繰り返しテストして、実装が意図したポリシーと一致することを確認し、実装の不確実性を軽減します。

コンテキストをアセンブルするときは、ビジネス ガイダンス、現在の証拠、メモリのソースと根拠を特定します。 エージェントがメモリに書き込むことができる内容と、それを保持する期間を定義します。 メモリは正本記録をオーバーライドしてはなりません。また、プロンプトや命令と同じように扱うことはできません。

次の図は、エージェントの知識、証拠、メモリを準備して組み合わせる方法を示しています。

状態

Control は、認証、承認、ランタイム ガバナンスによってワークロードを保護します。 システムにアクセスできるユーザー、各呼び出し元とエージェントが実行できる操作、承認が必要なアクションが定義されます。 モデルではなく、アプリケーション コードと接続済みサービスでこれらの決定を強制します。

セキュリティのベスト プラクティスに従い、脅威モデリングを実施して、実装するランタイムセーフガードを決定してください。 データ フロー図 (DFD) は、呼び出し側、エージェント、ツール、データ ストア間で情報がどのように移動するかを示しています。信頼境界を越える場所も含まれます。 その分析を使用して、アクセス チェックを適用する場所、データ共有を制限する場所、および承認を要求する場所を決定します。

これらの信頼境界は、攻撃に対する防御の一部です。 たとえば、取得されたコンテンツやツールの応答には、悪意のある命令が含まれている可能性があります。 モデルがそれらの指示に従っている場合でも、アクセス チェックと承認ゲートを引き続き適用する必要があります。 多層防御とゼロ トラストの原則に従ってください。 これらのコントロールを、1つの対策だけで十分とみなすのではなく、プロンプトインジェクションに対する防御などの他の防御と組み合わせます。

呼び出し元とエージェントの ID を認証し、そのタスクとターゲット リソースの各データ アクセスとツール アクションを認可します。 最小限の特権を適用し、基盤の責任で特定されたアクセス要件を遵守させます。 作業を委任するときは、呼び出し元の認可コンテキストと証拠参照を保持し、各ハンドオフでアクセス許可を再確認します。 委任によって権限を拡張してはなりません。 アクセスが拒否された場合は、別のツールまたはエージェントを介して拒否をバイパスするのではなく、定義された停止またはエスカレーション パスに従います。

ランタイム ガバナンスでは、必要な承認、必須のワークフロー ステップ、運用エンベロープの制限 (予算やレート制限など) も適用されます。 繰り返しても安全な操作のみを再試行してください。 制限に達したら、コントラクトの停止またはフォールバックの動作に従います。 これらの制御は、ワークロードのより広範な回復性設計を補完します。

製品レビュー エージェントの例では、アクセスは割り当てられた投稿、適用可能なポリシー、およびモデレーション アクションに制限されます。 パブリケーション ワークフローは、承認されたレビューを発行する前に、アクセス許可、提出リビジョン、およびポリシー バージョンを確認します。 ポリシーの変更と顧客アカウントのアクションは、エージェントの権限外にします。

次の図は、提案されたアクションの評価と記録方法を示しています。

検索の例については、「セキュリティで保護されたマルチテナント RAG 推論ソリューションの設計」を参照してください。 ID 管理と階層型保護のガイダンスについては、「ID 管理、アクセス、最小権限」、および「セキュリティの設計原則」を参照してください。

ワークフロー オーケストレーションによって実装される実行コントロールの例については、「 ワークフロー指向のマルチエージェント パターン」を参照してください。

確かめる

Verify では、単一ケースのチェックと、開発者のインナーループでのデータセット レベルの評価が組み合わさります。

1 つのケースを確認する

実装時に、記録またはシミュレートされた応答を使用してテスト ケースを実行または再実行します。 実行トレースを調べて、証拠、ツールの呼び出し、制御の決定、結果を動作コントラクトとシナリオと比較します。 調査結果に基づいて、実装をデバッグおよび改善します。

Evaluations

バージョン管理されたデータセット全体で評価を実行して、サポートされているシナリオ全体の動作を測定します。 動作コントラクトからメトリックと受け入れしきい値を定義します。 次の表では、製品レビュー エージェントのシナリオと関連する対策について説明します。

同じデータセットとエバリュエーターのバージョンを使用して、候補とベースラインを比較します。 詳細については、「リプレイの構成と実行」を参照してください。

集計スコアがデグレードを隠さないように、シナリオ別に結果を報告します。 テスト ケースを繰り返して一貫性を確認します。 評価前に、実行回数と受け入れ基準を定義します。 動作コントラクト、データセット、エバリュエーター、しきい値のバージョンを結果と共に記録します。

動作限界で実行時間の長いケースと障害時の挙動をテストします。 ステップ数とツール呼び出し数を定義しますが、コントラクトで指定されている場合にのみ正確なパスが必要です。 マルチエージェント ワークロードの場合は、ハンドオフだけでなく、エンドツーエンドの結果もテストします。

単体テストと統合テストと共にこれらのチェックを実行します。 必要なシナリオのしきい値を満たさないリリースをブロックします。 リリース ガイダンスについては、 導入パスのチェックリストを参照してください。

観察する

Observe は本番実行を分析して、成功した動作、失敗、およびその原因を特定します。 システムは、分析を容易にするためにユーザー フィードバックを収集する必要があります。 シナリオ分類から分析を開始します:

1. タスクと実行コンテキストを使用して、記録された実行を分類します。 各ランを、該当するシナリオとコントラクト バージョンに一致させてください。 不明確またはあいまいなケースをレビュー用にフラグ付けします。

2. 結果をシナリオの予想される動作と比較し、その情報とユーザー フィードバックを組み合わせて、成功または失敗を評価します。 証拠が不十分な場合は、ケースを未評価のままにします。

3. トレースとレビュー担当者のフィードバックを使用して障害を調査します。 知識のギャップ、実装または依存関係の失敗、不明な要件など、原因別に結果をグループ化します。

4. 製品の所有者、ドメインの専門家、エンジニアに調査結果を確認させ、何を変更するかを決定させます。 回帰カバレッジに準備されたケースを追加する前に、予想される結果を検証します。 各変更の理由を記録し、リリース前に確認してください。

製品レビュー エージェントの例では、個人情報を含む申請を非公開にしたままヒューマン レビューにルーティングすることは正常な動作です。 それを承認することは失敗の例です。 画像レビューをサポートする要求は、潜在的なスコープ変更を示しています。

タスク入力、ツールの要求と応答、モデルに提供された取得されたコンテンツ、出力をキャプチャします。 ソース バージョン、管理上の判断、および失敗を保持します。 ユーザーとレビュー担当者のフィードバックを実行とリリースにリンクします。 キャプチャされたデータを最小限に抑え、アクセスと保持の制限を適用し、分析またはデータセットのキュレーションの前に リプレイ データ準備ガイダンス に従います。

本番環境での知見を評価に結び付ける例については、エージェントの可観測性品質ループを参照してください。

導入パスのチェックリスト

ワークロード内の 1 つの重要な動作に関する最小限の実行可能な実装から始めます。

最小の便利な ABE 実装はプラットフォームではありません。 これは、明示的で、再生可能で、評価され、制御された 1 つの振る舞いです。 最初の作業ループは、[指定] と [検証] にあります。 チームが 1 つのインターフェイス規約を使って実際の行動上の問題を防止、検出、または診断できるようになる前に、広範なプラットフォームを構築するのは避けてください。

1. 範囲が明確で重要な影響のある状況を選択し、その製品とエンジニアリングの責任者を特定し、ドメインの専門家を関与させます。
2. 証拠と失敗状態を含む、レビュー済みの行動コントラクトを 1 つ記述します。
3. 通常、境界、不十分な証拠、および依存関係障害のケースのシナリオを定義します。 これらのシナリオから合成ケースを生成してテストを開始してください。
4. 合成ケースを使用して、別個のゴールデン データセット向けに実際のワークロード ケースを収集およびキュレーションする際の指針として専門家を支援します。
5. 再生のための安定したツールとナレッジベースの応答をキャプチャまたはシミュレートします。
6. 確定的なチェックと、契約で必要な判断ベースの評価者のみを追加します。
7. 継続的インテグレーションでシナリオを実行し、重大な障害が発生した場合はリリースを停止します。
8. コントラクト、実装、証拠パス、および結果を識別するのに十分な情報を本番実行から記録します。
9. レビュー済みの本番の検出事項を回帰シナリオに変換します。

プロンプト、モデル設定、アプリケーション コードを変更すると、エージェントの動作が変わる可能性があります。 運用環境で使用する前に、これらの変更を検証してください。 テストしたバージョン、評価のセットアップ、結果を記録してください。 安全なデプロイプラクティスに従って、変更を段階的に導入し、問題が発生した場合の復旧方法を計画します。 復旧計画に構成の変更を含めます。

ワークロードに必要な内容を学習するときに、この最初のループを土台にして進めます。 エージェントとシステムに共有のビジネス定義とリレーションシップが必要な場合は、 セマンティック データ モデル がその基盤を提供できます。 決定が明示的なビジネス ルールに従う場合、 ルール エンジン はモデルの外部でこれらのルールを適用できます。 ワークロードに必要なアクセス制御と実行証跡を最初から維持し、リスクと本番環境での知見によってそれが正当化されるように監視と自動化を拡張します。

Azureに ABE を実装する

ABE はプラットフォームに依存しません。 Azureは、5 つのエンジニアリング責任をサポートするために使用できるサービスを提供します。

次の図は、各 ABE の責任を、ワークロードに対して考慮するAzureサービスにマップします。

各エンジニアリング上の責務ごとに、Azure 機能をチームが管理する契約、制御、およびレビュー プロセスと組み合わせます。

Azureサービスを選択する前に、その機能、リージョン、APIがワークロードに適合していることを確認してください。 必須の強制適用とリリース チェックのために、一般公開 (GA) サービスとアプリケーション所有のコントロールを優先します。 次のセクションで説明する機能の一部はプレビュー機能であり、ワークロードに適していない場合があります。

Azure で指定

Azure ReposやGitHubなど、既存の Git リポジトリにコントラクト、シナリオ、オペレーティング エンベロープ、再生構成を保持します。 変更が期待される動作に影響する場合は、共有されたレビュー責任に従います。 技術的なメンテナンスにはエンジニアリング レビューを使用します。

Azure の基盤

エージェントを、基盤となる責任について特定した権威あるソースに接続します。 製品レビュー エージェントの場合は、Web サイトの既存のアプリケーション API から開始して、投稿と現在承認されているポリシーを取得します。

ナレッジ ソース間で取得が必要な場合は、Azure AI 検索 のエージェント型取得を検討してください。 オプションのソース参照とアクティビティ ログを含むグラウンディング コンテンツを返すことができます。 選択した取得方法のコストと待機時間を測定します。

ビジネス データが既に Microsoft Fabric 内にある場合、Fabric IQ ツールは、Microsoft Foundry エージェントをセマンティック モデルとオントロジ項目に接続できます。 統合と オントロジの機能 はプレビュー段階です。 接続の認証方法、アクセスできるデータ、およびデータがAzureコンプライアンス境界を離れる可能性があるかどうかを確認します。

セマンティック定義をエージェント実装とは別にバージョン管理し、そのバージョンをテスト証拠とともに記録します。 Fabric Git 統合では、プレビュー段階のオントロジ項目がサポートされます。

Azure での制御と実行

Foundry Agent Service では、プロンプト エージェントとカスタム のホステッド エージェントを実行できます。 その他のランタイムまたはデプロイの要件については、AKS、Azure Container Apps、またはAzure App Serviceを検討してください。 オプションを比較するには、Azure コンピューティング サービスを選択を参照してください。 認可、承認、実行ルールをアプリケーションと接続されたサービスに実装します。

Foundry エージェントの場合は、サポートされている MCP 接続とエージェント間接続には、Microsoft Entra エージェント ID を使用します。 エージェントがユーザーの代理として動作する場合は、ユーザーの権限とエージェントの権限の両方を確認します。 リリース前に、エージェントが実行時に使用する ID とアクセス許可を確認してください。

Azure API Managementは、認証ポリシー、レート制限、クォータを使用して共有 MCP エンドポイントを管理できます。 Agent Framework ミドルウェアを使用して、フレームワークが実行する関数ツールに対するアプリケーション側で管理するチェックを追加します。 その境界外で実行されるツールの場合は、ゲートウェイまたはダウンストリーム サービスで必須の承認とポリシーを適用します。

アクションに人間による確認が必要な場合は、function-tool approvalを使用します。 ワークフローの承認が再起動後も存続する必要がある場合は、実行を許可する前に、永続的な チェックポイント ストレージ を構成し、保留中の承認状態を復元してください。 状態を変更するツールの場合は、入力を検証し、アクション Executor でべき等セーフガードを追加します。 実装に伴うバージョン オーケストレーションと制御の設定。

Azure AI Content Safetyのプロンプト シールドは、ユーザー プロンプトとグラウンド ドキュメントでのプロンプト挿入の試行を検出できます。 これらのチェックを認可と組み合わせます。 動作コントラクト内のブロックされたコンテンツにワークロードがどのように応答するかを定義し、その応答をテストします。

製品レビュー エージェントの場合、割り当てられた申請と現在のポリシーに対する読み取りアクセス権が付与されます。 書き込みアクセスは、申請を承認するか、人間のレビューのためにルーティングするモデレーション操作に制限されます。 提出とポリシーのバージョンチェックは、パブリケーション ワークフローで適用されます。

Azure の検証する

準備済みのリプレイ ケースとテスト結果をAzure Blob Storageに格納できます。 再生構成で特定のデータセット バージョンを参照し、本番環境由来のケースをソース実行にリンクします。 保護されたホールドアウト ケースと保持された本番証拠へのアクセスを制限します。 ID ベースのアクセス、データ保護、およびリテンション期間については、Blob Storage アーキテクチャのガイダンスに従ってください。

Foundry 評価データセットを使用すると、完了した応答をスコア付けしたり、エージェントに入力を送信して新しい応答を生成および評価したりできます。 制御された再生の場合は、エージェントを呼び出す前に依存関係アダプターを構成します。 データセットを管理シナリオ ライブラリの実行コピーとして発行し、同じホールドアウト アクセス制限を適用します。

明示的な参照値またはルールを持つ基準には決定論的チェックを使用し、判断ベースの基準にはモデルベースのエバリュエーターを使用します。 Foundry カスタム エバリュエーターは 、外部スコアリング エンドポイントと同様に、両方のアプローチをサポートします。

製品レビュー エージェントの場合、コードベースのチェックでは、構造化された決定を標準チームの予想される決定と比較できます。 モデル ベースのエバリュエーターは、送信されたテキストに基づいて、説明と引用されたポリシー ルールがその決定をサポートしているかどうかを評価できます。 Rubric評価者 とカスタム評価者はプレビュー中です。

ゲートでスコアを使用する前に 、エバリュエーター ツールの互換性 を確認します。 Azure AI 検索またはFabricデータ エージェントの呼び出しを含む会話の場合は、tool_call_accuracy、tool_input_accuracy、tool_output_utilization、tool_call_success、またはgroundedness結果を使用しないでください。 決定論的コントラクト アサーションまたはサポートされている別の評価方法を使用します。

ケースごとの結果とトレースを、それらを生成した構成とともに保存します。 パイプラインでリリースしきい値を適用し、必要なシナリオが失敗した場合にリリースをブロックします。 実装を比較するときは、同じケースと評価ツールのバージョンを使用してください。 Azure Machine Learningでカスタム モデルをトレーニングする場合は、そのバージョンを構成設定に含めます。

Azure の観察

Foundry トレースでは、プロジェクトに接続されている Azure Monitor Application Insights リソースが使用されます。 アプリケーションのツール用コードと取得コードを計装して、必要な追加の証拠をキャプチャします。

記録する必要があるコンテンツを決定します。 Foundry クライアント側トレース統合 には、メッセージ コンテンツを記録するための設定が含まれています。 インストルメンテーションで、必要なツールの応答と取得されたコンテンツが操作名とタイミングと共にキャプチャされていることを確認します。 テレメトリのエクスポート前に機密性の高いペイロードを最小化またはマスキングし、データ ポリシーで許可されている情報のみを保持します。

トレース評価 (プレビュー) を使用して、クレンジング要件を満たす保持された Application Insights トレースを評価することを検討してください。 要求を再実行せずに、Foundry の外部にあるエージェントからのサポート対象の OpenTelemetry トレースを含む既存の対話をスコア付けします。 これらのスコアを使用して本番環境での挙動を調査し、リリース前に再生と評価を通じて、結果として得られる実装の変更を確認します。 この機能はパブリック プレビュー段階であり、サービス レベル アグリーメントはなく、運用環境のワークロードには推奨されません。 運用環境の監視やリリースの決定に依存しないでください。

Log Analytics クエリと Azure Monitor アラートを使用して、挙動の異常と運用エンベロープ違反を調査します。 現在プレビュー段階の Application Insights エージェントの詳細ビューは、個々の実行を調査するのに役立ちます。 確認した結果と準備したケースを、次の変更と再生のサイクルに投入しました。

Contributors

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主な執筆者:

• Yang Song | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• チャド・キットテル |プリンシパル ソフトウェア エンジニア
• Bryan Ostdiek | プリンシパルデータサイエンティスト
• ピーター・パーカー |Azure AI クラウドストラテジストおよびアーキテクトのプリンシパル ソリューション エンジニア
• ラマ・ピラサニ | 学際的フォワードデプロイメントエンジニアリングマネージャー
• ロニー・ヤテス | Forward Deployed Engineering担当ゼネラルマネージャー

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• Microsoft Foundry のエージェント
• AI エージェントを評価する
• Azure AI 検索 におけるエージェント駆動型の検索
• Application Insights を使用して AI エージェントを監視する
• エージェント行動契約(研究論文)

関連するリソース

• AI エージェントの設計パターン
• エージェント検索拡張生成
• 機械学習オペレーション