この記事では、Microsoft Marketplace で公開する AI アプリとエージェントを構築するためのベスト プラクティスについて説明します。 この記事では、パフォーマンスのキャッシュ、コストの最適化、安全なデプロイ戦略、自動化された CI 検証などの概念について説明します。
モジュール式プロンプトとモデル設計
明確なバージョン管理とロールバック機能を備えたモジュール式プロンプト アーキテクチャ (AI 対話用) を使用します。 ソリューションで大規模な言語モデルのプロンプトまたはチェーンを使用する場合は、個別に更新できるモジュール/コンポーネントに分割します。
たとえば、さまざまな関数に対してプロンプト セクションを分けます (要約用、FAQ に回答するセクションなど)。 コードと同様に、これらのプロンプト (および ML モデル構成) をバージョン 管理システムで管理します。 これにより、パフォーマンスの低下を調整するプロンプトが見つかった場合は、以前のバージョンにすばやくロールバックできます。 また、デプロイされたプロンプト/モデル バージョンの変更ログも保持します。 AI の動作を進化する資産 (エージェントの頭脳のバージョン "1.0" と "1.1" など) として扱います。この方法では、AI を改善する際のリスクが軽減され、加えられた変更の追跡可能性が提供されます (問題が発生した場合に何が変更されたかを説明する必要があるため、デバッグとコンプライアンスに重要です)。
パフォーマンスのためのキャッシュ
スマート キャッシュ戦略を 実装して、パフォーマンスを向上させ、コストを削減します。 多くの AI ソリューションには、次の利点があります。
- セマンティック キャッシュ: 高価な AI クエリの結果をキャッシュします。 たとえば、同じ質問またはドキュメント分析が複数回要求された場合は、モデルが繰り返し呼び出されないように回答をキャッシュします。 埋め込みを使用して、回答を再利用する可能性がある "類似" クエリを検出する
- 取得キャッシュ: エージェントがデータベースまたはコグニティブ検索から情報を取得する場合は、それらの取得結果を短時間キャッシュします (基になるデータが頻繁に変更されない場合)。
- 標準 Web キャッシュ: 静的コンテンツの Content Delivery Networks (CDN)、HTTP 応答キャッシュ (該当する場合)
また、部分的な計算 (複数ステップの推論プロセスでの中間結果など) のキャッシュも検討してください。 キャッシュ ヒット 率を監視し、必要に応じて調整します。 古い回答を回避するために、基になるデータの更新時にキャッシュを無効にすることを念頭に置きます。 効果的なキャッシュにより、モデルへの API 呼び出しを大幅に削減し (呼び出しごとの料金のコストを節約)、ユーザーの応答を高速化できます。 キャッシュによって不正確なデータが提供されないように注意してください。疑わしい場合は、重要な情報には常に新しいデータの使用を優先してください。
API の回復性
すべての外部 API またはモデル呼び出しに 回復性 を組み込みます。 これには、AI モデル エンドポイント (Azure OpenAI サービス呼び出しなど)、サードパーティのサービス、さらには Marketplace API の監視が含まれます。
- 再試行ポリシーを使用する: 一時的な障害の場合 (指数バックオフ遅延あり)
- サーキットブレーカーを実装する: 外部サービスが一貫して失敗したり、低速だったりする場合、復旧させるために短時間呼び出しを停止します（アプリ全体がハングしないようにします）。
- レート制限とクォータを適用する: 独自のコードでサービスや外部のコードがオーバーロードされないようにします。 1 人のユーザーが何らかの方法で要求を過剰にトリガーした場合は、キューに入れるか制限をかけます。 また、外部 API のレート制限も考慮します (そのため、エージェントはブロックされません)。
- グレースフルデグラデーション: 重要でないコンポーネントが失敗した場合（例えば、回答を強化するためのニュースAPIの呼び出し）、エージェントは完全にエラーを起こすのではなく、コア機能で応答を続ける必要があります。
- これらのシナリオをテストする: AI サービスの停止をシミュレートするか、速度を低下させ、アプリケーションが適切に処理することを確認します。クラッシュするのではなく、"サービスがビジーです、再試行してください" のようなメッセージが返される可能性があります。 Marketplace のレビュー担当者は、障害シナリオを誘発することによってソリューションの堅牢性をテストすることが知られており、企業のお客様は間違いなく高可用性を期待しているため、この作業は十分に費やされます。
AI ガードレール
接地、誤った情報フィルター処理、ツールの使用の強制など、 AI 品質ガードレール を実装します。 実際には、これは次のことを意味します。
- AIの応答は常に信頼性の高いデータを基にするよう心がけてください。 エージェントがユーザーの質問に回答する場合は、ナレッジ ベースから引用するか、指定されたコンテキストのみを使用します。 アクションを実行するエージェントの場合は、アクションを実行する前に正しいコンテキストがあることを確認してください
- ハルシネーションフィルター: AIの出力を確認する。 たとえば、回答を生成した後、既知の赤フラグ フレーズや 明らかに 正しくない情報が含まれているかどうかを確認できます。 セカンドパスや安全なフォールバック応答をトリガーするために、「曖昧な表現」（「AIとして、私は...」）や「既知の誤った記述」のリストを保持できます。
- ツールの適用: AI エージェントが特定のツールを使用することになっている場合、または特定の考え方の連鎖に従うことになっている場合 (最初に API を呼び出してデータを取得してから応答する場合など)、コードでそのロジックを適用します。 指示に従うためにモデルだけに頼ってはいけません。プログラムの制約を使用します。 たとえば、すべての未知の用語に対して Web 検索を実行する必要がある場合は、モデルを信頼して検索するタイミングを把握するのではなく、システムで実際に実行されるようにします。
これらのガードレールは、 応答品質と信頼性を維持するために不可欠です。 また、責任ある AI のレンズの下で見ていきます。 それらを設計に文書化します (たとえば、信頼度が X 未満の場合や、クエリで個人データが検出された場合は、エージェントが回答を拒否します)。
適切に保護されたエージェントは、有害または無意味な出力をユーザーに生成する可能性が低くなります。
コストの最適化
設計で コストの最適化 を意識する - トークンの使用、バッチ操作、ベクター データベースの効率的な使用を管理します。 AI 操作 (特に大規模な言語モデル呼び出し) はコストがかかる可能性があるため、次のようになります。
- プロンプトのトークン予算を設定する: プロンプトや出力を無制限に拡大させないでください。 ユーザー入力が非常に長い場合は、最初に要約することを検討してください。 完全性とコストのバランスを取ったサイズ内でプロンプトを維持することを目指す
- 可能な限りバッチ要求: AI を使用して 100 項目を処理する必要がある場合は、1 つずつよりも (API でサポートされている場合) バッチで送信する方がコストが安く、より高速になる可能性があります
- ベクター ストアの使用を最適化する: 埋め込みを使用する場合は、適切なディメンションを使用し、必要なベクターのみを格納し、未使用のベクターを定期的にクリーンアップします。 また、前述のように、繰り返しクエリに対してはベクター検索結果をキャッシュしてください。
- 適切なサービス レベルを選択します。モデルのバージョンが小さいか、初期段階で下位レベルから始まり、必要に応じてスケールアップされる可能性があります
効率性を念頭に置くことで、クラウドの請求書を減らすだけでなく、コスト削減やより良い価格を顧客に渡すことができます。 さらに、無駄のないソリューションは、多くの場合、より高速なソリューションです (ユーザー エクスペリエンスにメリットがあります)。 ソリューションがコスト効率が高い ("最小限のコンピューティング リソースで実行するように最適化されている") 場合は、マーケットプレースの一覧で強調表示することもできます。これは、ビジネスの意思決定者にアピールするためです。
可観測性と監視
包括的な 可観測性 をソリューションに組み込みます。ログ、トレース、ダッシュボードは、顧客のアクティブ化やフルフィルメント イベントなどの重要なフローを具体的に追跡します。 例えば次が挙げられます。
- 各サブスクリプション イベント (解決、アクティブ化など) を、タイムスタンプ、顧客 ID、結果、エラーなどの詳細でログに記録します。 これにより、1 人の顧客のアクティブ化に失敗したかどうかを診断できます
- システムを介してユーザー アクションをトレースする: ユーザーが AI に何かを要求した場合、(Application Insights または同様の Application Performance Monitoring (APM) ツールを使用してトランザクションをトレースするなど、さまざまなコンポーネントを要求がどのように通過したかをトレースできます。
- 主要なメトリックのダッシュボードを設定する: アクティブなサブスクリプションの数、毎日の AI クエリの数、呼び出しの成功/失敗率、平均応答時間など。また、フルフィルメント パイプラインを監視します。たとえば、"過去 24 時間のアクティブ化: 10 成功、1 失敗" を示すタイル
- 異常に対するアラートを実装する: たとえば、Webhook 呼び出しが失敗した場合や、使用量が 0 に低下した (停止を示す可能性がある) 場合は、DevOps チームにアラート/電子メールを送信します
強力な監視を行うことで、問題が普及する前、またはテスト担当者Microsoft気付く前に、問題をキャッチして修正できます。 多くの場合、オブザーバビリティはスタートアップ企業が軽視しがちですが、エンタープライズ対応には不可欠です。 さらに、認定または共同販売のディスカッション中に、堅牢な監視があることを示すことで、利害関係者に印象を与えることができます (信頼できるサービスの実行に真剣に取り組んでいることを示しています)。
自動化された CI 検証
CI の 自動チェック を統合して、品質、セキュリティ、AI の安全性を確保します。 つまり、ユーザーまたはチームが変更を行い、コードをプッシュするたびに、次のことを行います。
- 機能の単体テストと統合テストを実行する
- AI 出力のテストを含めて (たとえば、より小さなダミー モデルやモックを使用して一貫性を保つための決定論的な方法がある場合)、応答で明らかな問題をキャッチします
- 静的分析/セキュリティ スキャナー (GitHub コード スキャンやセキュリティ アナライザー Azure DevOpsなど) を使用して、脆弱性を早期に見つけます。
- 可能であれば、責任ある AI 分析手順を含めます。 たとえば、AI の新しいビルドを使用してクエリのバッチを実行し、有害な出力や不適切な出力を自動的にチェックします
- セキュリティのベスト プラクティスを確保するために、コードまたは ARM テンプレートとしてインフラストラクチャをリントする
これらのチェックを自動化することで、人的エラーを減らし、各ビルドが品質のベースラインを維持することを確認します。 適切なプラクティスを継続的に適用する方が、公開する直前に問題を解決するよりも簡単です。 さらに、これらの CI/CD プラクティスを文書化すると、一覧表示された後もアプリを適切な状態に保つことがMicrosoft確信できます (多くの場合、1 回限りではなく、継続的なコンプライアンスが考慮されます)。 品質ゲートとの継続的インテグレーションは、最新のソフトウェア エンジニアリングの特徴です。
安全なデプロイ戦略
青/緑のデプロイや、AI エージェントの更新のためのリング (段階的) ロールアウトなどのデプロイ戦略を使用します。 ソリューション (特に AI またはプロンプト ロジック) を更新するときは、テストなしですべてのユーザーの実行中のバージョンを一度に置き換えるだけではありません。 代替案:
- 青/緑: 2 つの運用環境 (青と緑) があります。 古い (青) がまだ実行されている間に、新しいバージョン (緑) をデプロイします。 テスト テナントまたはトラフィックの小さなサブセットを緑色に切り替えて観察します。 すべてが正常に表示される場合は、すべてのトラフィックを徐々に緑色に切り替えます。 問題が発生した場合は、すぐに青に戻すことができます (以前の安定したバージョン)
- 段階的デプロイ: 最初に、限られた対象ユーザーに新しいバージョンを導入します。 たとえば、自分の会社のテナントまたはフレンドリーな早期導入者のみがバージョン 2.0 を取得し、他のすべてのユーザーはバージョン 1.0 のままです。 結果を監視し、問題がない場合はリングをより多くのテナントに拡張し、最終的にすべてが移行されるまで
これらのアプローチは、モデルの動作の変化が予測できない可能性があるため、AI で特に役立ちます。 慎重にロールアウトすることで、回帰による影響を最小限に抑えることができます。 また、新しい AI 機能を徐々にオンまたはオフにするための機能フラグも検討してください。 Marketplace はデプロイ方法を指示しませんが、顧客の信頼性と継続性が重要です。 また、 メジャー モデルの更新 が計画されている場合は、サポートと調整し、場合によってはリリース ノートを使用して顧客に通知します (リリース ノートの テンプレート セクションを参照)。 要するに、変更の バックアウト計画 を立てる必要があります。