このセクションでは、ソリューションの構築について説明します Microsoft Marketplace の技術的要件とベスト プラクティスを満たします。 統合のコア開発 要件 、AI ソリューションに推奨される ベスト プラクティス 、開発を加速するために提供される便利なテンプレートについて説明 します 。
セキュリティ
テナント分離
マルチカスタマー環境で厳密なテナント分離を適用します。 AI サービスがマルチテナント (1 つのシステムから多くの顧客にサービスを提供する) 場合は、各顧客のデータと構成が完全に分離されるように設計します。 この分離は、多くの場合、テナントごとに一意の識別子を使用してデータをパーティション分割し、テナント間でコンテキストを混在させないことを意味します。 たとえば、顧客 B は顧客 A のクエリとデータを表示しないでください。 すべてのレイヤーでアクセス制御を使用します。データベース クエリ、ストレージ バケット、メモリ内操作はすべて、現在のテナントにスコープを設定する必要があります。 テナント間でハードコーディングされたシークレットや共有資格情報はありません。 堅牢な分離を確保することで、企業がソリューションを評価する際の重要な要件であるデータ漏えいから保護できます。
ID と最小特権
認証には Microsoft Entra ID (旧称 Azure AD) と統合し、最小特権アクセスで管理 ID を使用します。 つまり、ソリューションは、エンタープライズ レベルのセキュリティ (MFA、シングル サインオンなど) を提供するログインユーザーに対して、ID 管理をAzure AD/Entra IDにオフロードする必要があります。 Azure サービス内では、マネージド ID を使用して他のリソースにアクセスすることを好みます (たとえば、アプリのコードでは、Azure AD ID を使用して、キーを埋め込まずにAzure Storageまたはデータベースを安全に呼び出すことができます)。 各コンポーネントに必要な最小限のアクセス許可のみが付与されていることを確認します。たとえば、エージェントがストレージ コンテナーから読み取る必要がある場合は、完全なアカウント アクセスではなく、そのコンテナー にのみ読み取りアクセス権を付与します。
最小特権の原則に従うと、コンポーネントが侵害された場合の影響が最小限に抑えられます。
Webhook と API をセキュリティで保護する
すべての Webhook エンドポイントと API を適切な検証、認証、および冪等性で保護します。 たとえば、Marketplace によって呼び出される SaaS フルフィルメント Webhook を設定する場合は、トークンや署名を使用して、呼び出しが実際に Microsoft からのものであり、改ざんされていないことを確認します。 イベント ID を追跡するか重複除去メカニズムを使用して、べき等性を実装します (各イベントは複数回送信された場合でも 1 回だけ処理されます)。 エージェントが API エンドポイントを公開している場合 (たとえば、顧客が結果を照会したり、サービスと統合したりするには)、API キーまたは OAuth を使用してセキュリティで保護し、必要に応じて調整します。 Azure API Managementまたは同様のゲートウェイを使用して、エンドポイントにセキュリティと監視の追加レイヤーを追加することをお勧めします。
Webhook と API をロックダウンすることで、一般的な攻撃ベクトルを防ぎ、承認された呼び出しのみを確実に通過できます。
データ保護
保存時と転送中の両方で、強力な暗号化とデータ保護の対策を適用します。 転送中のデータが暗号化されるように、すべてのクライアント エージェントとサービス サービスの通信に HTTPS/TLS を使用します。 保存データ (データベース、ログ、ファイル ストレージ) の場合は、暗号化を使用します (Azure サービスは既定で保存時に暗号化されることがよくあります。これを確認するか、Azure Key Vaultを使用して独自のキーを管理します)。 AI が個人データや機密データを処理する可能性がある場合は、 PII/PHI フィルター処理を 実装します。たとえば、システムでは、処理前または AI の出力内で、社会保障番号や患者レコードなどのフィールドを自動的にマスクまたは除外して、意図しない露出を回避できます。 AI がログを生成する場合は、可能な限り 機密データを書き込まないように ログ記録を設計します (たとえば、操作が発生したが正確な内容はログに記録されません)。
これらのプラクティスはエンタープライズ セキュリティ標準に準拠しており、セキュリティ レビュー中に詳しい情報が得られる予定です。
シークレットの管理
適切なローテーションと監査ログを使用して、Azure Key Vault を使用して、すべてのシークレット (API キー、資格情報、証明書) を安全に処理します。 シークレットは、プレーン テキストでコードまたは構成ファイルに格納しないでください。 代わりに、Key Vaultに格納し、実行時にアプリケーションで取得します。 Key Vaultの機能を利用します。アクセス ポリシーを設定して、アプリの ID のみが必要なシークレットを取得できるようにし、ログを有効にして誰が何にアクセスしたかを確認し、ローテーション ポリシーを設定します (データベース パスワードや証明書などの一部のシークレットは定期的にローテーションする必要があります)。
監査担当者や精通した顧客は、シークレットの管理方法を尋ねることがよくあります。Key Vaultのような堅牢なシステムを使用して、成熟したセキュリティ体制を示していることを示しています。 また、侵害のリスクも軽減されます (ソース コードや構成を取得した場合でも、ライブ パスワードが見つからないため)。
ロギングのポリシー
顧客の機密情報を格納することなく、有用なセキュリティとパフォーマンス のデータをキャプチャするログ ポリシーを確立します。 たとえば、"User X invoked action Y at time Z" や "AI prompt length = N tokens, response time = M seconds" などのイベントをログに記録しますが、 プライベート データが含まれている可能性がある場合は、ユーザー クエリの実際のコンテンツはログに記録しません。 デバッグで何らかのコンテンツ ログが必要な場合は、ハッシュまたは切り捨てを検討してください。 顧客情報を含むログが保護されていることを確認します (安全に保存され、アクセスが制限されます)。 また、ログのリテンション期間を慎重に計画します。ログはトラブルシューティングと監査に十分な長さ (30 ~ 90 日など) を保持しますが、永続的には保持しないでください。 データ最小化の原則に従います。
明確なログ記録ガイドラインを作成することで、プライバシーを保護し、規制に準拠しながら、問題を診断する機能を維持することができます。
コンプライアンス
- 責任ある AI ドキュメント: 透明性に関する注意事項、制限事項、安全性の開示
- コンプライアンスの整合: SOC、ISO、データ保護規制、およびその他の業界要件
- データ: 保持、削除、およびユーザーの同意手順
- アクセシビリティ コンプライアンス: Web コンテンツ アクセシビリティ ガイドライン (WCAG)、ローカライズされたコンテンツ、UI
- 証拠パッケージ: Marketplace レビュー担当者向け (プライバシー、サポート、セキュリティ)
AI アプリとエージェントへの セキュリティ と 行動ガードレールの 設計の詳細については、コミュニティの投稿を参照してください。
必要条件
オファーの種類の選択
コード行を記述する前に、ソリューションに適した Marketplace オファーの種類を決定します。 Microsoftのガイドラインまたは「オファーの選択」アドバイザーツールを使用して、SaaS、Azureアプリケーション、コンテナ、または仮想マシン (VM) オファーの中から選択してください。 (オファーの種類の詳細については、「発行ガイダンス」セクションで説明しますが、事前に正しく選択することが重要です)。まとめると、次のように選択します。
- SaaS オファー: 複数の顧客向けに中央 Web サービスをホストする場合
- An Azure アプリケーション: ソリューション テンプレートまたはマネージド アプリケーション(顧客のAzure環境に複数のリソースをデプロイする必要がある場合)
- コンテナー オファー: 顧客のテナントで実行するコンテナー イメージとしてソリューションを提供する場合
- または、 自己完結型 VM ソリューションに仮想マシン オファーを使用する
- Microsoft 365 および Copilot エージェント: Microsoft 365 エクスペリエンスと統合されたエージェントをアクティブ化する方法を定義する技術マニフェストが必要です。 Microsoft 365 エージェントの作成の詳細については、「 Office アドイン マニフェストの作成を参照してください。
適切なカテゴリを選択すると、多くの開発要件が発生するようになりました (たとえば、SaaS オファーのみが Fulfillment API を使用し、コンテナーにはデプロイ パッケージが必要です)。 Microsoftの内部 "Offer Selection App" または guidelines はこの段階で選択を検証するのに役立ちます。 このドキュメントでは、ソフトウェア開発会社 (SDK) 全体で最も使用されている SaaS オファーに焦点を当てています。
SaaS Fulfillment API v2 を実装する
取引可能な SaaS オファーを構築する場合は、 SaaS Fulfillment API v2 と完全に統合します。 アプリケーションでは、サブスクリプションのライフサイクルを処理するために必要なすべての REST エンドポイントとロジックを実装する必要があります。 解決、 アクティブ化、 中断、 取り消し、 更新。 実際に：
- 解決 は、顧客がインストール/サブスクライブを試みたときに呼び出されます。サービスはトークンを受け取り、アカウント マッピング (フルフィルメント ID) を返す必要があります
- アクティブ化 は、サブスクリプションを確認するために呼び出されます (多くの場合、顧客がサイトにアクセスした後)
- 一時停止/再開 は、サブスクリプションが保留中 (支払いの問題など) または再アクティブ化されたときに呼び出されます
- Cancel は、顧客またはMicrosoftがサブスクリプションを終了したときに呼び出されます
- 更新 プログラムは、顧客がプラン (SKU) またはライセンス数を変更したときに呼び出されます
必要なビジネス ロジック (アクティブ化時の リソースのプロビジョニング、 一時停止時のアクセスの制限など) を使用して、バックエンドがこれらの必要な REST エンドポイントに応答する方法を計画します。 適切な認証で v2 API エンドポイントを使用し、予想される HTTP 状態を返します。 Microsoftは、この目的のためにクライアント ライブラリとサンプルを提供します。 統合が確実であることを確認 するために、これらのフローをエンドツーエンド で徹底的にテストします (詳細については、発行セクションのテストを参照してください)。 これは、すべての SaaS オファー に必須の要件 です。
ランディング ページとトークンの処理
リダイレクト時にマーケットプレース SaaS トークンを正しく処理する SaaS オファーの ランディング ページ を開発します。 ユーザーが SaaS オファーを取得すると、(URL クエリ内の) トークンと共に、構成済みのランディング ページ URL に Marketplace から送信されます。 アプリケーションでは、そのトークンをキャプチャし、Fulfillment API (Resolve) を使用してサブスクリプションの詳細を取得し、そのマーケットプレース購入をシステム内のアカウントにリンクする必要があります。 このページでスムーズなオンボーディングが提供されていることを確認します。たとえば、トークンの検証後に、アカウントを作成またはリンクするようにユーザーに依頼した後、Activate を呼び出してサブスクリプションを開始します。
ヒント
トークンの解析とサブスクリプションの状態の表示を既に処理している、Microsoftの SaaS アクセラレータ またはスターター キットによって提供されるサンプル ランディング ページを使用または調整します。 適切に実装されたランディング ページでは、多くの一般的なエラー (購入後に顧客がスタックするなど) を防ぐので、ここに労力を費やしてください。
テナントリンクワークフロー
顧客の環境に合 ったテナント リンク ワークフロー を設計します。 ソリューションで顧客のAzure テナントまたはその他のリソースへのアクセスが必要な場合 (マルチテナント SaaS で一般的な場合、またはユーザーに代わって Azure API を使用する場合)、顧客がそのアクセス権を付与する方法を提供する必要があります。 これは、多くの場合、OAuth 同意フローを実装すること、または顧客がAzureテナント ID と管理者の同意を入力できるようにすることを意味します。 たとえば、ランディング ページまたはアプリケーションに [Microsoftに接続] ボタンが表示され、必要に応じてアクセス許可 (特定のデータの読み取りやリソースのデプロイなど) を要求Azure AD OAuth がトリガーされます。 顧客が同意を付与したら、テナントまたは認証トークンをサブスクリプションに安全にマップして保存します。 この手順は、購入後に顧客のAzure環境と統合されるすべてのソリューションに不可欠です。 可能な限り簡単にします (必要なアクセス許可とその理由を文書化します)。 ソリューションが基本的なサブスクリプション (データのみをホストする純粋な SaaS アプリなど) を超えて顧客側から何も必要ない場合は、これが適用されない可能性がありますが、リンクが必要な場合は、SDC またはアーキテクトに再確認してください。
Microsoft Marketplace で取引可能な SaaS オファーのランディング ページを構築します
測定を実装する (使用量ベースの場合)
使用量ベースの課金コンポーネントの場合は、 使用状況をレポートするように測定統合を 設定します。 Marketplace では、一定の料金に加えて (または代わりに) 使用量ベースの料金を使用できますが、発行元は Marketplace Metering API を介して使用状況イベントを出力する必要があります。 課金対象の使用量 (処理されたドキュメントの数、API 呼び出しなど) を特定します。 ソリューションで次の手順を実行します。
- コードをインストルメント化して、顧客サブスクリプションごとにこれらの使用状況イベントをカウントする
- 適切な間隔 (通常は時間単位または日単位) で、各ディメンションの各サブスクリプションの使用状況を使用して Metering API を呼び出します
- 二重課金を回避するために、メーターリングイベントにべき等性または一意の ID を確保する
たとえば、処理された 1,000 件のメッセージごとに課金する場合、サービスは顧客ごとにカウントを累積し、1 時間ごとに合計が課金のためにMicrosoftに送信される可能性があります。 提供されている 測定クライアント サンプルを 使用して、これらの呼び出しを書式設定および認証する方法を確認します。 テストが重要です。パートナー センター レポートで使用状況が正しく表示されることを確認します。 使用状況測定を行わないと、使用量ベースのプランでは顧客に正しく課金されないため、測定統合は収益にとって重要な要素です。
プランと SKU の設計
顧客価値と課金戦略に合わせた プラン/SKU 構造 を定義します。 各オファーには、1 つ以上のプラン (SKU) を含めることができます 。たとえば、"無料試用版"、"Standard"、"エンタープライズ" などです。これらのプラン/SKU 構造を慎重に設計します。
- 差別化が明確であることを確認します (機能、制限、サポート レベル)
- 顧客が価値を導き出す方法 (たとえば、ユーザーごと、容量ごと、消費バンドルなど) に一致する方法で価格を設定します。
- お客様の予算に合わせて、SMB のコストが低く、エンタープライズ向けのプランが高い場合や、月単位と年単位の請求オプションのどちらであるかなどです。
使用メーターがこれらのプランに論理的に関連付けられるようにします (たとえば、"標準" プランには、1 か月あたり最大 1000 個のクエリが含まれる場合があり、その後のクエリごとに課金される場合があります)。 また、特別な契約のプライベート プランも検討します (Marketplace では、特定の顧客のみが表示できる非表示の SKU が許可され、多くの場合、カスタム取引に使用されます)。 開発の早い段階で、アプリでこれらのプランの違いを適用できることをビジネス チームに検証します (プラン A に機能 X が無効になっている場合など、コードはその適用を反映している必要があります)。 よく考え抜いた SKU 戦略は、顧客にアピールするだけでなく、開発を簡素化します (階層ごとに何を構築すべきかを正確に把握しているため)。
運用対応アーキテクチャ
顧客データ間を厳密に分離して 、運用対応のマルチテナント アーキテクチャ を構築します。 これはセキュリティの分離に結び付きますが、開発の観点からは、 多くの顧客に確実かつ安全にサービスを提供するかのようにソリューションを実装する必要があります。 これには次のものが含まれます。
- スケーラブルなAzure サービスの使用 (たとえば、自動スケーリングを使用したAzure App Service、テナント別のパーティション分割を使用したAzure SQLまたは Cosmos DB など)
- 特定の顧客のコンテキストで要求が常に実行され、別のユーザーのコンテキストにブリードできないように、厳密なチェックを実装する
- 複数の同時実行テナントを使用したテストで、パフォーマンスが維持されることを確認する (1 つのテナントが重いジョブを実行している場合は、他のテナントを飢えさせるべきではありません)
- 必要に応じて、テナントごとの機能フラグまたは構成を組み込みます (一部のお客様の設定が若干異なる場合があります)
基本的に、1 人の顧客を想定する設計や、1 つのインスタンスに対してハードコーディングされる設計は避けてください。 1 人のパイロット顧客から始めても、多くのユーザー向けに設計します。 Azure固有の分離機能 (テナントごとに個別のストレージ コンテナー、データベースの行レベルのセキュリティなど) を使用します。 その結果、より多くの顧客を登録し、誰のデータや体験も他のユーザーの影響を受けないように確保できるため、報われます。 また、マーケットプレース 認定とエンタープライズ クライアントが評価するもの でもあります ("顧客データを分離する方法" と尋ねる場合があります。しっかりとした回答とアーキテクチャ図を用意できます)。
環境戦略 (開発 > ステージ > 運用環境)
独自の資格情報とエンドポイントを使用して、開発、ステージング、および運用環境を個別に設定します。 これは標準的なプラクティスですが、複数のテストと更新を行うので、マーケットプレース ソリューションにとって絶対に重要です。
- 開発: 内部の開発とテスト用。 この環境は、毎日のビルドに使用します。場合によってはモック統合エンドポイントを使用します
- ステージ (テスト): 認定テストとドライランに使用される、運用環境の構成を厳密に反映するステージ。 この環境には同じ統合が必要ですが (たとえば、サンドボックス モードで実際の Marketplace API と通信するなど)、運用データから分離されます
- 運用環境: 顧客向けのライブ環境
クロスコンタミネーションを回避するには、それぞれに個別のAzure リソースまたはサブスクリプションを使用します。 API キーと接続文字列の個別のセットを管理します。 たとえば、API キーと接続文字列の個別のセットを別々の Key Vault に格納します。 この考え方は、実際の顧客に影響を与えることなく、ステージで新しいリリースを自信を持ってテストできるということです (おそらく、ステージ URL を指すオファーのパートナー センター "プレビュー" ドラフトを使用する場合でも)。 ステージですべての確認が終わったら、変更を運用環境に反映させます。 この戦略はまた、運用環境で問題が発生した場合に、セットアップに依存して、安定したステージング環境を比較用に使用したり、フェールオーバー先として使用したりできることを意味します。 違いを明確に記録します（たとえば、ステージではテスト決済と偽のメールサービスを使用し、プロダクションでは本物のクレジットカード決済と実際のメールシステムを使用します）。 Microsoftのレビュー チームは、設定した場合、運用環境以外の環境で認定を実行する可能性があります。これは安全です。