AI Serverは、組織が管理するインフラ上のアプリケーション向けにOpenAI互換のAPIを提供します。エージェント統合には、単にチャット応答が成功する以上の具体的な受け入れテストが必要です。選択したモデルは意図した操作を提案し、ホストアプリケーションはその提案を正しく処理しなければなりません。当社の AI Server製品ページ では展開の役割を説明しており、以下の手順は個別の統合をチェックする推奨方法を示しています。

MLCommonsの2026年7月エッジエージェントベンチマーク文書はこの違いを示しています。例ではツール定義をChat Completionsエンドポイントに送信し、モデルが返す構造化された呼び出しを検査しています。[1] エンドポイント名だけでは、すべてのモデル、ランタイム、フレームワークの組み合わせが同じワークフローを完了するとは限りません。

ビジネスデータを変更しないリクエストから始める

使い捨てのテストワークスペースとタスクに適したモデルを選択します。サーバービルド、ランタイム、モデル識別子、エージェントフレームワークのバージョンを記録してください。有効なエンドポイントとトランスポート設定も含めますが、認証情報は報告に含めないでください。記録は、テスト対象のインストールを同名のモデルや他の場所で稼働中の古いサーバーと区別できるようにします。

通常のテキストリクエストを1件送信して開始します。どのエンドポイントが受信し、どのモデルが処理し、呼び出し元が完全な応答を受け取ったかを確認します。パイロットで使用するフレームワークを通じて繰り返します。直接のHTTP成功とフレームワークの成功は別の観察事項ですので、両方の結果を保持してください。

接続障害とタスクの難易度を区別しやすいように、予測可能な答えが得られる短い入力を使用します。生成された挨拶は購買ワークフローについてほとんど何も示しませんが、ルートの最初のチェックとして有用です。この初期テストをより現実的にするためにビジネス認証情報を追加しないでください。

実行前に無害なツール提案を確認する

架空の在庫からアイテムを検索するなど、狭いテスト操作を定義します。必須フィールドと明示的な許可値セットを持つ小さなスキーマを与えます。この段階では、モデルの提案した操作を実行せずに取得します。操作名、解析された引数、欠落または予期しないフィールドに対するフレームワークの扱いを確認します。

結果を人がすべて検査できるほどシンプルに保ちます。アイテムについてもっともらしい文章を返すモデルが必ずしも使えるツール呼び出しを生成しているとは限りません。逆に、正しく形成された呼び出しでも誤ったアイテム名を指定している場合があります。フォーマットの受け入れとタスクの正確さは別々に記録してください。

本番アプリケーションがレスポンスをストリーミングする場合は、同じチェックをストリーミング経由で実行します。消費者が関連する構造化値の完了を待ってから解釈することを検証します。ストリーミング処理と非ストリーミング処理の違いは、成功した経路が両方をカバーすると仮定せず、解決が必要な統合上の問題として扱います。

制御された結果で往復を完了する

提案が検証を通過した後、ホストに架空の在庫を呼び出させ、その結果をモデルに返します。続く応答を検査します。提供された結果を使用し、要求されたアイテムの識別を保持しているはずです。該当なしを返す検索も含め、アプリケーションが欠如を正直に表現しなければならないようにします。

次に、2回目の検索を必要とする短いシーケンスを実行します。フレームワークが各結果を発信元の呼び出しとどのように関連付け、次のリクエストが会話をどのように進めるかを検証してください。実際の顧客文書を保持せずにシーケンスを示すサニタイズ済みトレースを保存します。

ここで、単一ターンのデモンストレーションがワークフローテストに変わります。トレースは誤った関連付け、不必要な繰り返し、または放棄されたタスクを明らかにすべきです。 10月のベンチマーク記事 これらの長時間の対話を評価する際にワークロードの境界が重要である理由を説明しています。

権限チェックはモデルの判断の外に置く

OWASPは過剰な機能、権限、自律性を過剰なエージェンシーの原因として特定しています。その指針では、実行アクションのシステムに認可チェックを配置し、影響の大きい操作には人間の承認を推奨しています。[2] この統合では、モデルが通常は妥当なアクションを求めるかどうかに関わらず、これらの制御を独立してテストしてください。

呼び出し元が実行を許可されていない操作を1つ追加して、作成済みの在庫フィクスチャを拡張します。提案された引数が有効に見えても、ホストまたは下流サービスが拒否することを確認してください。拒否はユーザーに理解可能であり、フレームワークがより権限の高い資格情報に置き換えることがあってはなりません。

無関係な指示を含む取得済みのテスト文書を含めます。OWASPは外部コンテンツを介した間接的なプロンプトインジェクションを説明し、取得拡張生成がこの脆弱性を完全に除去しないことを指摘しています。[3] ここでの受け入れ基準は具体的です：取得された文章はアプリケーションに追加の権限を与えてはなりません。このテストは有用なチェックであり、すべてのインジェクション試行がブロックされる証明ではありません。

中断と記録されたスコープで終了します

テストツールを中断し、リクエストをキャンセルし、依存関係を一時的に利用不可にします。ユーザーが何を見て、フレームワークが何を再試行するかを観察してください。レコードを変更するツールを導入する前に、再試行が既に完了したアクションの重複を避ける方法について合意してください。その決定はアプリケーション設計と下流サービス契約に属します。

提案する受け入れ記録には、テストされた正確な操作、許可されたID、および未解決の動作が記載されます。成功した在庫検索は合意されたパイロットスコープのみを認可すべきです。新しいコネクター、より広い権限、または異なるモデルは影響を受けるチェックの見直しを促します。

展開の議論には、その記録を Software Tailor統合レビューに持参し、存在する場合は編集済みの失敗例も添えてください。次の有用なステップは、所有者がいる再現可能なギャップです。 運用引き継ぎ は初期統合作業終了後もこれらの所有者を保持すべきです。

参考文献

[1] MLCommons. Call for Submission: Edge Agentic Inference Benchmark for MLPerf Inference v6.1. 2026年7月。2026-09-26アクセス。

[2] OWASP Gen AI セキュリティプロジェクト。 LLM06:2025 過剰なエージェンシー2025年版。2026年9月26日アクセス。

[3] OWASP Gen AI セキュリティプロジェクト。 LLM01:2025 プロンプトインジェクション2025年版。2026年9月26日アクセス。

関連記事

Get it from Microsoft