プレイブック

アプリケーションのダウンタイムなしで、AI サービスの API キーのローテーションを自動化します。

→プライマリキーとセカンダリキーの両方を Azure Key Vault に自動ローテーションで格納します。プライマリキーが失敗した場合に、アプリケーションがセカンダリキーを試行するように構成します。

理由: Key Vault はローテーションライフサイクルを管理します。デュアルキーパターンにより、ローテーションウィンドウ中に常に1つのキーが有効であることが保証されます。

AI サービスのトラフィックが VNet を離れることがなく、Microsoft が顧客データをサービス改善のために使用できないようにします。

→AI サービスをプライベートエンドポイントでデプロイし、パブリックネットワークアクセスを無効にします。別途、リソースでデータ処理のオプトアウト設定を有効にします。

理由: Private Endpoint はネットワーク分離を提供します。データオプトアウトはデータプライバシーのための個別の設定です。一方が他方を意味するものではありません。

Azure Kubernetes Service (AKS) 内のアプリケーションに、AI サービスへのセキュアで資格情報不要なアクセスを提供します。

→AKS ポッドにユーザー割り当てマネージドIDを割り当てます。このIDに、AI サービスリソースで「Cognitive Services User」RBAC ロールを付与します。

理由: マネージドIDは、Azure リソースの標準的なパスワードレス認証パターンであり、ポッド構成にシークレットを保存する必要がなくなります。

リファレンス↗

部門ごとに個別のサブスクリプションを使用せずに、AI サービスのコストを追跡し、支出制限を適用します。

→部門ごとに個別の AI サービスリソースを作成します。それぞれに「department」リソースタグを適用します。タグ値に基づいてアラートしきい値を設定した Azure Cost Management の予算を構成します。

理由: タグはコスト配分の標準です。Azure の予算は、タグにスコープを設定して、アラートまたはアクションを介して支出制限を適用できます。

AI サービス API のエラー率が 5% を超えるか、レイテンシが 2 秒を超える場合に運用チームにアラートを送信します。

→AI サービスリソースで Azure Monitor のメトリックアラートを構成します。「Failed Requests」と「Latency」のメトリックを適切な集計期間で使用します。

理由: Azure Monitor は、パフォーマンスと信頼性のための直接的かつプラットフォームレベルのメトリックを提供し、ログクエリの遅延なしにリアルタイムアラートを可能にします。

低RTO/RPOのカスタムAIモデル（例：Custom Vision, LUIS）のディザスターリカバリ計画を設計します。

→ペアリージョンにリソースをデプロイします。モデルの毎日のエクスポートを geo 冗長ストレージ (GRS) に自動化します。ヘルスプローブに基づく自動フェールオーバーに Azure Traffic Manager を使用します。

理由: AI PaaS サービスは Azure Site Recovery の対象ではありません。DR には、明示的でスクリプト化されたモデルのエクスポート/インポートと、DNS レベルのトラフィックルーティングサービスが必要です。

長期監査保持のために、すべての AI サービス呼び出しの完全なリクエストおよびレスポンスペイロードをログに記録します。

→Azure API Management (APIM) を AI サービスの手前に配置します。APIM ポリシーを構成して完全なリクエスト/レスポンスボディをログに記録します。ログを不変ポリシーを持つ Azure Storage に送信します。

理由: ネイティブ AI サービスの診断では完全なペイロードはログに記録されません。APIM は、ロギングおよびポリシーファサードの標準パターンです。不変ストレージは監査証跡の整合性を保証します。

患者データを処理し、HIPAA に準拠する必要があるヘルスケア AI ソリューションをデプロイします。

→HIPAA をサポートする米国の Azure リージョンに AI リソースをデプロイします。サブスクリプションについて Microsoft と事業提携契約 (BAA) に署名します。

理由: HIPAA への準拠には、技術的制御（リージョン選択）と法的契約（BAA）の両方が必要です。両方とも必須です。

有害なコンテンツをフラグ付けするが、ブロックする前に人間のレビューを許可するコンテンツモデレーションシステムを実装します。

→Azure AI Content Safety API を使用します。「high」の重大度でフラグ付けされたコンテンツは自動ブロックします。「medium」または「low」でフラグ付けされたコンテンツは人間によるレビューワークフローのためにキューに入れます。

理由: このヒューマン・イン・ザ・ループパターンは、自動化された安全性とモデレーションに必要なニュアンスのバランスを取り、正当なコンテンツの過剰なブロックを防ぎます。

小売店の棚にある特定のブランド商品を検出し、数え上げ、オクルージョンやさまざまな向きに対応します。

→Custom Vision オブジェクト検出モデルをトレーニングします。現実的な棚の環境で製品を表すラベル付き画像のデータセットを使用します。

理由: オブジェクト検出は、分類と位置（カウント用）の両方を提供します。特定の製品 SKU を認識するにはカスタムモデルが必要です。

リファレンス↗

インターネット接続が不安定な工場で、リアルタイムの品質管理画像分析を実行します。

→Azure AI Vision の画像分析コンテナをエッジデバイス（例：Azure IoT Edge）にデプロイします。

理由: コンテナは、クラウドAIモデルをローカルで実行できるようにパッケージ化し、低レイテンシとオフライン機能を提供しながら、接続時にモデルの更新を可能にします。

混在する印刷、手書きテキスト、複数言語を含むスキャンされた歴史的文書からテキストを抽出します。

→Azure AI Vision の Read API（画像分析の一部）を使用します。混在コンテンツで最高のパフォーマンスを確保するために、最新のモデルバージョンを指定します。

理由: Read API は Azure で最も高度な OCR エンジンであり、ドキュメント中心の混在コンテンツシナリオに特化して最適化されており、古い OCR API を凌駕します。

ビデオストリームを分析して、店舗の占有率を監視し、顧客の移動パターンを追跡し、キューの長さを測定します。

→Azure AI Vision Spatial Analysis コンテナを店舗カメラに接続されたエッジデバイスにデプロイします。

理由: Spatial Analysis は、ビデオからのリアルタイム空間分析のために特別に構築されたコンテナ化されたソリューションであり、`personcount`、`persondistance`、`personcrossingline` などの操作を提供します。

Custom Vision オブジェクト検出モデルは、高い精度を持つが、低い再現率（多くのオブジェクトを見逃す）を示しています。

→見逃されたオブジェクトのより多様な例、特に異なる照明、角度、サイズ、部分的なオクルージョンを持つ画像をトレーニングデータセットに追加して拡張します。

理由: 低い再現率は、データ量または多様性の問題です。モデルが効果的に一般化するのに十分なバリエーションを見ていないためです。多様な例を追加することが主要な解決策です。

顧客レビューを分析し、特定の製品機能（例：「バッテリー寿命」には肯定的、「画面」には否定的）に対する感情を特定します。

→`opinionMining` パラメータを有効にして、Azure AI Language の感情分析 API を使用します。

理由: 意見マイニング（アスペクトベース感情分析とも呼ばれます）は、テキスト内の個々のターゲット（アスペクト）に関連する感情を抽出するために設計された特定の機能です。

リファレンス↗

多くの言語をサポートするが、英語で作成された単一のナレッジベースを使用する FAQ ボットを作成します。

→Azure AI Language の Custom Question Answering 機能を使用します。英語のナレッジベースに対して質問を照合するための組み込みのクエリ翻訳機能があります。

理由: 組み込みの翻訳機能により、各言語の個別のナレッジベースを維持する必要がなくなり、コンテンツ管理が大幅に簡素化されます。

Conversational Language Understanding (CLU) モデルが、2つの類似した意図（例：「OrderPizza」と「ModifyOrder」）を混同しています。

→両方の意図に、区別するキーワードやフレーズを強調する例に焦点を当てた、より多様なトレーニング発話を​​追加します。曖昧または重複する例を確認し、削除します。

理由: モデルの精度は、主にトレーニングデータの品質と明確さによって決まります。目標は、意図間に明確な「決定境界」を作成することです。

「ContractValue」や「TerminationClause」などのドメイン固有のエンティティを法務文書から抽出します。

→Azure AI Language を使用してカスタム固有表現認識 (NER) モデルをトレーニングします。ドキュメントからラベル付きの例を提供します。

理由: 事前構築された NER モデルは一般的なエンティティ（人物、場所など）のみを認識します。ドメイン固有のエンティティ抽出タスクにはカスタム NER が必要です。

テキストから氏名や電話番号などの個人識別情報 (PII) を自動的に検出し、編集します。

→Azure AI Language PII 検出 API を使用します。検出するエンティティカテゴリを構成し、編集モードを設定します。

理由: これは PII 専用に構築された API であり、この特定のコンプライアンスタスクにおいて、正規表現や汎用 NER よりも信頼性が高く、包括的です。

臨床ノートから医療エンティティ、関係、およびアサーション（例：否定）を抽出します。

→Azure AI Health Insights、特に Text Analytics for Health サービスを使用します。

理由: これは、医療オントロジー（例：UMLS）でトレーニングされた、HIPAA に準拠した専門サービスであり、一般的な NLP モデルにはない臨床テキストの深い理解を提供します。

技術文書を翻訳し、業界固有の用語やブランド名が正しく翻訳されるようにします。

→Azure Custom Translator を使用します。既存の翻訳済みドキュメント（パラレルドキュメント）のコーパスを使用してカスタムモデルをトレーニングします。

理由: Custom Translator は、特定のドメインの語彙とスタイルに適応し、ニッチな用語を誤訳する可能性のある汎用翻訳モデルよりも高い忠実度を提供します。

複数参加者の会議をリアルタイムで文字起こしし、各発言者にテキストを帰属させます。

→会話書き起こしと話者分離が有効な Azure AI Speech to Text サービスを使用します。

理由: 話者分離は、音声を話者ごとにセグメント化し、書き起こしとともに「誰が何を言ったか」の情報を提供する特定の機能です。

ドメイン固有の頭字語、専門用語、または固有名詞を含む音声の音声認識精度を向上させます。

→カスタム音声モデルをトレーニングします。人間がラベル付けした書き起こしと一致する音声サンプルのデータセット、およびカスタム用語の発音ファイルを提供します。

理由: カスタムモデルは、ベースとなる音響モデルと言語モデルを特定のオーディオ環境、話し方、語彙に適応させ、精度を大幅に向上させます。

eラーニングモジュールのテキスト読み上げナレーションの強調、ピッチ、速度、一時停止を制御します。

→Text-to-Speech API リクエストで Speech Synthesis Markup Language (SSML) を使用します。

理由: SSML は、音声シンセサイザーに詳細な指示を提供するための W3C 標準であり、プレーンテキスト入力では不可能なきめ細かい制御を可能にします。

1000万以上のドキュメントに対応し、大量の同時クエリに対して低レイテンシを必要とする検索ソリューションを設計します。

→Standard またはそれ以上の階層で Azure AI Search を使用します。レプリカを使用してクエリ負荷を処理し、パーティションを使用してデータボリュームを処理することでスケールアウトします。

理由: レプリカはクエリのスループット（QPS）用です。パーティションはインデックスサイズとI/O用です。大規模で高性能なシナリオには両方が必要です。

ユーザーが自然言語の質問（例：「返品ポリシーは何ですか？」）をして、ドキュメントコレクションから直接回答を得られるようにします。

→セマンティック検索を有効にした Azure AI Search を使用します。セマンティックな回答とキャプション機能を利用します。

理由: セマンティック検索は、キーワードマッチングを超えてユーザーの意図を理解し、ソーステキストから直接的で簡潔な回答を抽出して返すことができます。

リファレンス↗

モデル番号の完全一致（キーワード）と概念的に類似したアイテム（セマンティック）を見つける製品検索を実装します。

→検索可能なテキストフィールドとベクトルフィールドの両方を持つ Azure AI Search インデックスを構成します。キーワード（`search`）とベクトル（`vectorQueries`）パラメータを組み合わせたハイブリッドクエリを発行します。

理由: ハイブリッド検索は、BM25 キーワードランキングの精度とベクトル類似性の概念的な関連性を組み合わせることで、両方の長所を提供します。

Azure AI Search のインデックス作成パイプライン中に、製品コード（XX-####）のようなカスタム形式のエンティティを抽出します。

→Azure Function を呼び出すカスタムスキルセットを作成します。この関数には、エンティティを見つけて抽出するための正規表現またはその他のカスタムロジックが含まれます。

理由: カスタムスキルは、組み込みのコグニティブスキルではカバーされないロジックのために、エンリッチメントパイプラインに拡張ポイントを提供します。

「laptop」、「notebook」、「ultrabook」の検索がすべて同じ関連ドキュメントのセットを返すようにします。

→Azure AI Search で同義語を定義する同義語マップを作成します。インデックス定義で、同義語マップを関連する検索可能フィールドに関連付けます。

理由: 同義語マップは、ユーザー定義の同義語をクエリに含めるための専用機能であり、検索の再現率を直接向上させます。

Azure AI Search のスキルセットを更新する際に、変更によって影響を受けるドキュメントのみを再処理して、時間とコストを節約します。

→インデクサー構成でエンリッチメントキャッシュを有効にします。これにより、インデクサーは変更されていないスキルにはキャッシュされた結果を使用し、新規または変更されたスキルのみを再実行します。

理由: 中間スキル出力のキャッシュは、効率的な増分エンリッチメントを可能にする鍵であり、データセット全体の費用のかかる完全な再処理を回避します。

さまざまなドキュメント（例：請求書）からデータを抽出し、ビジネスルールに対して検証し、構造化された出力を保存するパイプラインをオーケストレーションします。

→抽出には Azure AI Document Intelligence のコンポジットモデルを、カスタム検証ロジックには Azure Function を、ストレージには Azure Cosmos DB を使用します。Azure Logic Apps でオーケストレーションします。

理由: このサーバーレスアーキテクチャは、懸念事項を適切に分離します。Document Intelligence は専門的な抽出に、Functions は個別のビジネスロジックに、Logic Apps はワークフローオーケストレーションに使用されます。

複数のフォームタイプ（例：請求書、領収書、写真）を含むドキュメントパッケージを単一のトランザクションで処理します。

→Azure AI Document Intelligence のコンポジットモデルを使用します。ドキュメントタイプを識別し、適切なカスタムまたは事前構築済み抽出モデルにルーティングする分類モデルをトレーニングします。

理由: コンポジットモデルはルーターとして機能し、単一のエンドポイントで複数のドキュメントタイプをインテリジェントに処理し、それぞれが最適なモデルによって処理されるようにします。

Azure AI Search によってインデックス付けされる前にドキュメントから PII を編集し、機密データが検索インデックスに保存されないようにします。

→PII 検出コグニティブスキルをインデクサーのスキルセットに追加します。スキルを構成して PII をマスクし、編集されたテキストフィールドをインデックスにマッピングします。

理由: これにより、インデックス作成中に「進行中の」編集が実行され、検索可能なコンテンツが最初からクリーンであることを保証します。これは、セキュリティおよびコンプライアンスの重要なパターンです。

ドキュメントの鮮度（公開日）と人気（表示回数）に基づいて検索結果をブーストします。

→Azure AI Search でカスタムスコアリングプロファイルを定義します。日付フィールドには `freshness` 関数を、表示回数フィールドには `magnitude` 関数を使用します。

理由: スコアリングプロファイルを使用すると、ドキュメントメタデータからのビジネス固有のシグナルを組み込むことで、基本の BM25 関連性スコアを変更できます。

Azure OpenAI チャットボットは、カスタマーサービスシナリオで、一貫性があり、焦点を絞った、創造的ではない応答を提供する必要があります。

→`temperature` パラメータを 0.1 または 0.2 のような低い値に設定します。ほとんどのモデルでは正確に 0 に設定することは避けてください。

理由: Temperature は出力のランダム性を制御します。値を下げることで、モデルはより決定論的になり、最も確率の高いトークンを選択する可能性が高まります。

RAG ソリューションにおいて、生成モデルが特定のユーザーがアクセスを許可されたドキュメントからのみ回答を合成するようにします。

→取得段階でセキュリティトリミングを実装します。Azure AI Search では、ユーザーの AAD ID とグループメンバーシップに基づいて検索クエリにセキュリティフィルターを適用します。

理由: アクセス制御は、LLM がデータを参照する前に実施される必要があります。検索（取得）レイヤーでのフィルタリングが、これを実装する唯一の安全な方法です。

Azure OpenAI を使用して、非構造化テキストから構造化データを一貫して有効な JSON オブジェクトとして抽出します。

→以下の要素を含むプロンプトを使用します。1) 明確な役割。2) JSON のみを返すという明確な指示。3) フィールド名と型を含む望ましい JSON スキーマ。4) 可能であれば、少数の例。

理由: 高度に構造化された明示的なプロンプトは、LLM から整形された構造化出力を取得する信頼性を大幅に高めます。

ミッションクリティカルなアプリケーションでは、ピーク負荷時にスロットリングなしで、Azure OpenAI からの保証された一貫したスループットが必要です。

→プロビジョニングされたスループットユニット (PTU) を使用してモデルを購入し、デプロイします。

理由: PTU は、専用の予約されたモデル処理容量を提供します。これは、共有容量モデルで動作し、スロットリングの対象となる標準の従量課金制デプロイとは異なります。

リファレンス↗

モデルのトークン制限を超えずに、長時間のチャットボット会話でコンテキストを維持します。

→会話要約戦略を実装します。定期的に別の LLM 呼び出しを使用して会話の古い部分を要約し、この要約と最新のターンをプロンプトに含めます。

理由: この「要約してスライド」パターンは、単純な切り捨てや（最終的に長すぎる）履歴全体を送信するよりも、長期的なコンテキストをはるかに効果的かつ経済的に維持します。

Azure OpenAI モデルが外部 API を呼び出して現在の天気情報を取得できるようにします。

→API を正確な JSON Schema 形式を使用してモデルのツールとして定義します。モデルがいつどのように使用するかを知るために、明確な関数 `description` と詳細な `parameter` 説明を含めます。

理由: モデルは、関数を呼び出すための情報に基づいた決定を下すために、スキーマと説明に完全に依存します。適切に記述された関数は信頼性にとって重要です。

Azure OpenAI を使用して、モデルのコンテキストウィンドウよりもはるかに長いドキュメントを要約します。

→「マップリデュース」または「リファイン」戦略を実装します。ドキュメントをチャンクに分割し、各チャンクの要約を生成し（マップ）、次にチャンク要約のコレクションから最終要約を生成します（リデュース）。

理由: これは、固定コンテキストモデルを任意の長さの入力に適用するための標準パターンであり、ドキュメントのコンテンツ全体が考慮されることを保証します。

AI の応答が生成されている最中に表示することで、チャットアプリケーションの体感的な応答性を向上させます。

→Chat Completions API を呼び出す際に、`stream` パラメータを `true` に設定します。サーバーから送信されるイベントを到着時に処理し、トークンごとに応答を構築します。

理由: ストリーミングは、完全な応答が生成されるまで数秒待つよりも、リアルタイムアプリケーションにとって遙かに優れたユーザーエクスペリエンスを提供します。

AI エージェントは、ユーザーのリクエストを達成するために、複数のツール（例：データベースクエリ、Web 検索、メール送信者）のうちどれを使用するかを動的に決定する必要があります。

→Semantic Kernel や Azure AI Agent Service のようなフレームワークを使用します。各機能を個別のツール/プラグインとして定義し、エージェントのプランナーまたは ReAct ループにツール呼び出しをオーケストレーションさせます。

理由: エージェントフレームワークは、LLM が単純な Q&A を超えて、ツールを使用する自律的なアクターになることを可能にするオーケストレーション層（プランナー/推論ループ）を提供します。

自律型 AI エージェントが、監視なしに高リスクな行動（例：データ削除、金銭の支出）を実行するのを防ぎます。

→ヒューマン・イン・ザ・ループパターンを実装します。エージェントが高リスクな行動を計画した場合、システムは一時停止し、実行前に人間のオペレーターからの明示的な確認を要求する必要があります。

理由: これはエージェントシステムにとって重要な責任あるAIパターンであり、不可逆的または影響の大きい行動をゲートすることで、自律性と安全性のバランスを取ります。