チャット機能が大量のトラフィックで実行され、短いシンプルなやり取りで、厳しいレイテンシーとコストの予算があります。
フロンティアLLMの代わりに、FoundryモデルカタログからPhiのような小規模言語モデル (SLM) をデプロイします。
理由: SLMは狭いタスクのコストとレイテンシーを削減します。大規模なLLMは複雑な推論のために予約します。モデルのサイズをブランドではなくタスクに合わせてください。
最終確認：2026年6月
AI-103 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
チャット機能が大量のトラフィックで実行され、短いシンプルなやり取りで、厳しいレイテンシーとコストの予算があります。
フロンティアLLMの代わりに、FoundryモデルカタログからPhiのような小規模言語モデル (SLM) をデプロイします。
理由: SLMは狭いタスクのコストとレイテンシーを削減します。大規模なLLMは複雑な推論のために予約します。モデルのサイズをブランドではなくタスクに合わせてください。
単一のagentが、ユーザーがアップロードした画像とテキストの両方を1つのリクエストで推論する必要があります。
テキストのみのLLMにビジョンモデルを連結するのではなく、Foundryカタログのmultimodalモデル (例: GPT-4oファミリー) を選択します。
理由: ネイティブなmultimodalモデルは1つのプロンプトで画像とテキストを受け入れます。テキストのみのモデルでは、視覚的な詳細が失われる損失の多いキャプションの受け渡しが強制されます。
回答は、モデルの事前学習ではなく、社内のプライベートなナレッジベースにgroundingされる必要があります。
取得レイヤーを構築します。vector embeddingsを使用してAzure AI Searchにコーパスをインデックス化し、そのインデックスに対するRAGを介してモデルをgroundingします。
理由: groundingは推論時に取得された引用可能なコンテキストを注入します。ファインチューニングは知識を静的に焼き付け、引用したり安価に更新したりすることはできません。
agentが内部REST APIを呼び出し、インデックス化されたドキュメントストアから取得する必要がある。
APIをagent tool (function/OpenAPI) として登録し、Foundry agentにAI Searchインデックスを知識ソースとしてアタッチします。
理由: toolはagentに行動能力を与え、知識ソースはgroundingされた取得を提供します。これらは同じコネクタではなく、異なる統合面です。
いくつかのチームが、共有ガバナンスのもとで、分離されたagent構成、接続、デプロイを必要としています。
チームごとのFoundryプロジェクトを持つFoundryハブを使用します。各プロジェクトは独自の接続、デプロイ、アクセスをスコープ設定します。
理由: ハブはネットワーク、ポリシー、共有リソースを一元化します。プロジェクトはアプリまたはチームのワークスペース単位です。1つのプロジェクトをチーム間で共有しないでください。
本番アプリでは、モデルのデプロイに対して予測可能なデータレジデンシーと予約されたスループットが必要です。
レジデンシーに敏感な高スループットのワークロードには、Global deploymentではなく、Standard (リージョン) またはProvisioned Throughput (PTU) デプロイを使用します。
理由: Global deploymentは容量のために任意のリージョンにルーティングします。Standardはリージョンを固定し、PTUは安定したレイテンシーのために容量を予約します。レジデンシーとSLAのニーズに基づいて選択してください。
プロンプトとagentの定義は、レビューとロールバックを伴って開発環境から本番環境へ移行する必要があります。
プロンプトフロー/agentの定義をコードとしてリポジトリに保存し、Azure DevOpsまたはGitHub Actionsパイプラインを使用して環境間で昇格させます。
理由: プロンプトとagentの構成をバージョン管理された成果物として扱います。本番環境での手動によるportal編集には監査証跡やロールバックパスがありません。
トラフィックの急増により、モデルのデプロイに対して429エラーが発生します。
可能な場合はデプロイのTPM/RPMクォータを引き上げ、指数バックオフ付きのクライアント側再試行を追加し、保証された容量のためにPTUデプロイを検討します。
理由: クォータは1分あたりのトークン上限です。バックオフは一時的なスロットリングを緩和します。クォータ計画なしでリソースを複製しても、ボトルネックが移動するだけです。
費用が予測不可能で、長いRAGプロンプトが大部分を占めています。
最大出力トークンを制限し、取得したコンテキストをtop-kに刈り込み、再利用可能なシステムコンテキストをキャッシュし、Azure Monitorでデプロイごとのトークン使用量を追跡します。
理由: コストは入力トークンと出力トークンに比例して増加します。コンテキストと出力を削減することが直接的なてこです。リージョンやSKUを変更しても、トークンあたりの価格が大幅に変わることはめったにありません。
数週間にわたり、本番環境で回答の品質とgroundingの忠実度が低下しているように見えます。
サンプリングされたライブトラフィックに対して、Foundryでgroundedness、関連性、一貫性の継続的なオンライン評価を実行し、スコアの低下をアラートします。
理由: スケジュールされた評価ツールは、生のレイテンシーメトリックでは見えないドリフトを検出します。CPU/レイテンシーダッシュボードだけではgroundingの回帰を明らかにすることはありません。
新しいドキュメントが取得されないため、RAGの回答が古くなります。
AI Searchインデクサの実行履歴とドキュメント数を監視します。増分インデックス作成をスケジュールし、失敗したインデクサの実行をアラートします。
理由: インデクサが失敗したり遅延したりすると、取得品質は静かに低下します。ギャップがデータパイプラインにあるため、モデル側のメトリックは正常に見えます。
アプリは、設定にシークレットなしでFoundryモデルデプロイを呼び出す必要があります。
アプリでmanaged identityを有効にし、「Cognitive Services OpenAI User」ロールを付与します。APIキーではなく、Entra IDトークンで認証します。
理由: キーレスEntra認証は、漏洩の可能性があるシークレットを削除し、RBACを一元化します。Key VaultにAPIキーを保存しても、回転および保護すべきキーが残ります。
Foundryトラフィックは決してパブリックインターネットを通過してはならない。
Foundryリソースと依存関係をprivate endpointsの背後に配置し、パブリックネットワークアクセスを無効にし、プライベートDNSゾーンを介して解決します。
理由: private endpointsはトラフィックをVNetに固定します。ファイアウォールのIP許可リストは依然としてパブリックエンドポイントを介してルーティングされ、分離が弱くなります。
生成された応答に、ヘイトや暴力的なコンテンツが時折含まれます。
ヘイト、性的、暴力、自傷行為のカテゴリについて適切な深刻度しきい値を持つAzure AI Content Safetyフィルターをデプロイに適用します。
理由: コンテンツフィルターはプロンプトと完了をサーバー側でスクリーニングします。システムプロンプトの指示のみに頼ると、jailbreakによって簡単にバイパスされます。
自律型agentは、払い戻しの発行など、取り消し不能なアクションを実行できます。
影響の大きいtoolに対してはhuman-in-the-loopの承認ゲートを設定し、agentを許可されたアクションのセットに制限します。
理由: 承認モードとtoolアクセス制限は自律性を縛ります。制約のない自律型agentは、破壊的なtool呼び出しに対するブレーキを持っていません。
監査人は、特定の回答がどのソースとtool呼び出しによって生成されたかを確認する必要があります。
Foundryでトレース (OpenTelemetry) を有効にし、リクエストごとにプロンプト、取得された引用、tool呼び出し、および出力をキャプチャします。
理由: エンドツーエンドのトレースは来歴と再現性を提供します。集計されたトークンメトリックだけでは、単一の回答の推論チェーンを再構築することはできません。
バックエンドサービスがFoundryプロジェクトで定義されたモデルとagentを呼び出す必要があります。
プロジェクト接続文字列とDefaultAzureCredentialを使用してAzure AI Foundry SDK (AIProjectClient) を利用し、モデルおよびagentクライアントを取得します。
理由: プロジェクトクライアントは接続とデプロイを一元的に解決します。モデルごとのエンドポイントとキーをハードコーディングすると、プロジェクトのガバナンスがバイパスされます。
ポリシー文書に基づいてgroundingされたQ&Aアプリを構築します。
ドキュメントを埋め込み、インデックス化し、クエリごとにtop-kのチャンクを取得し、情報源を引用する指示とともにチャット完了のコンテキストとして渡します。
理由: RAGは再トレーニングなしで知識を最新かつ引用可能に保ちます。完全なコーパスをプロンプトに渡すと、コンテキストウィンドウとコストが超過します。
会話中にモデルがライブの注文ステータスを検索する必要がある。
JSON schemaでtoolを定義し、モデルにtool呼び出しを発行させ、サーバー側で実行し、モデルが要約するための結果を返します。
理由: function/tool callingはモデルに実際のシステムを決定論的に呼び出させます。「推測」するよう求めると、でっち上げが生じます。
タスクが最終回答の前にいくつかの依存するtool呼び出しを必要とします。
tool使用ループを実行します。各toolの結果をモデルにフィードバックし、最終メッセージを返すまで繰り返し、最大反復回数を上限とします。
理由: 反復的なtoolループは多段階推論をサポートします。1回のラウンドトリップでは依存するルックアップを連鎖させることはできず、上限のないループは暴走する可能性があります。
出荷前に、RAGアプリがどのくらいの頻度で幻覚を起こしたり、トピックから逸脱したりするかを定量化します。
ラベル付けされたテストセットに対して、groundedness、関連性、一貫性のFoundry評価ツールを実行し、しきい値スコアに基づいてリリースをゲートします。
理由: 組み込みの評価ツールは測定可能な品質と安全性のシグナルを提供します。いくつかのサンプルをざっと見るだけでは、体系的なでっち上げは捕捉できません。
明確なペルソナ、目標、および境界を持つサポートagentを定義します。
agentのシステム指示 (役割、目標、拒否ルール) を設定し、そのスコープに必要なtoolのみをアタッチします。
理由: 厳密な指示と最小限のtoolアクセスにより、agentはタスクに集中できます。広範な指示とすべてのtoolは、スコープクリープと安全でないアクションを招きます。
agentはセッション内のやり取り全体でコンテキストを記憶する必要があります。
会話ごとにメッセージ履歴を永続化するFoundry Agent Serviceのスレッドを使用し、各実行が以前のやり取りを参照できるようにします。
理由: スレッドは管理された会話メモリを提供します。各呼び出しでトランスクリプト全体を手動で再送信することは脆く、誤って切り詰められやすいです。
agentはカスタムの配管なしでweb groundingとコード実行を必要としています。
手動で統合を構築するのではなく、Bing SearchによるGroundingやCode Interpreterのような組み込みのFoundry agent toolをアタッチします。
理由: 管理されたtoolは、すぐに使用できる状態でガバナンスされ、サポートされます。カスタム再実装はメンテナンスを追加し、プラットフォームの安全制御をスキップします。
プライマリエージェントは、請求に関する質問を専門の請求agentに委任する必要があります。
接続されたagentを使用します。請求agentをメインagentが呼び出せるtoolとして公開し、サブタスクを専門家にルーティングできるようにします。
理由: 接続されたagentは階層的な委任を可能にします。すべてのドメインを1つのメガagentに詰め込むと、指示が肥大化し、精度が低下します。
ワークフローでは、プランナー、リサーチャー、ライターが共有状態を保持しながら共同作業する必要があります。
定義されたorchestrationパターンと共有コンテキストを使用して、multi-agentフレームワーク (Foundry上のSemantic Kernel / AutoGen) でそれらをorchestrateします。
理由: フレームワークは順番の取得、状態、終了を管理します。agent間のアドホックな文字列渡しには調整や停止条件がありません。
agentが一晩 unattendedで実行され、単独で危険な行動をとってはならない。
許可されたtool、アクションごとの予算、コンテンツフィルター、および影響の大きいステップを承認のためにエスカレートするチェックポイントで制限します。
理由: 多層的な保護策により、自律性は安全に保たれます。完全なtoolアクセスと承認ゲートがない自律ループは、取り返しのつかない損害を引き起こす可能性があります。
agentがタスクの途中で断続的に失敗し、失敗したステップを見つける必要があります。
Foundryで実行のトレースされたステップとtool呼び出しの入力/出力を検査して、失敗しているtoolまたは不正な引数を特定します。
理由: ステップレベルのトレースは、実行がどこで中断したかを正確に特定します。単一の最終エラーメッセージでは、どのtool呼び出しまたは推論ステップが実際に失敗したか隠されてしまいます。
出力が一貫せず、書式設定の指示を無視します。
明確なシステムメッセージ、few-shotの例、明示的な出力制約を使用します。厳密な形状のためには、structured outputs / JSON schemaを有効にします。
理由: 構造化されたプロンプトとschema強制出力は結果を信頼性のあるものにします。temperatureを上げたり、盲目的に再試行したりしても、指示の順守は修正されません。
クリエイティブなコピー作業が反復的すぎると感じます。データ抽出作業はあまりにもランダムです。
創造的なタスクにはtemperature/top-pを上げ、抽出には0に近づけて決定論的にします。
理由: サンプリングパラメータは多様性と決定論をトレードオフします。パラメータ設定が本当の原因である場合、モデルを切り替えるのはやりすぎです。
推論agentが難しいタスクで避けられる論理エラーを犯します。
agentがドラフトをレビューして修正するreflection / self-critiqueステップを追加するか、そのステップに推論モデルを使用します。
理由: Chain-of-thoughtとself-critiqueは難しいタスクの精度を向上させます。1回のフォワードパスでは自分の間違いに気づく機会がありません。
運用では、本番環境でリクエストごとのトークン消費量、レイテンシー、および安全性シグナルが必要です。
アプリからAzure Monitor / Application InsightsにOpenTelemetryトレースとメトリックを送信し、トークン、レイテンシー、およびコンテンツ安全フラグをキャプチャします。
理由: 統合されたobservabilityはコスト、パフォーマンス、安全性を結びつけます。手作業でログをスクレイピングしても、遅いターンとそのトークン使用量を関連付けることはできません。
1つのアプリで、安価な分類と時折複雑な推論が混在しています。
複数のデプロイをorchestrateします。簡単なやり取りはSLMにルーティングし、難しいやり取りは1つのアプリレイヤーの背後にあるフロンティアLLMにエスカレートします。
理由: モデルルーティングはやり取りごとのコストと品質を最適化します。すべてに1つのプレミアムモデルを使用すると、簡単な大多数に対して過払いになります。
マーケティングアプリは、テキストプロンプトからオリジナルの画像を生成する必要があります。
画像生成モデル (例: FoundryカタログのDALL-E / GPT-image) をデプロイし、テキストプロンプトとサイズパラメータを指定して呼び出します。
理由: 生成AIモデルは新しいビジュアルを合成します。Image Analysis (vision) APIは既存の画像を記述するだけで、作成することはできません。
既存の製品写真の背景のみを交換し、製品はそのまま残します。
ソース画像と編集可能な領域のみをマークするマスクを使用して、画像編集 (inpainting) エンドポイントを使用します。
理由: マスクは編集範囲をペイントされた領域に限定します。単純なtext-to-image呼び出しではフレーム全体が再生成され、元の製品が失われます。
テキスト記述から短い生成ビデオクリップを生成します。
FoundryカタログにあるSoraなどのtext-to-videoモデルを、プロンプト、期間、解像度パラメータとともに使用します。
理由: ビデオ生成は独自のモデルファミリーです。画像モデルは単一のフレームを出力し、時間的な動きを生成することはできません。
ユーザーがアップロードされたグラフ画像について自由形式の質問をします。
画像と質問をmultimodal LLM (GPT-4o) に送信し、視覚的な質問応答と自然言語の回答を得ます。
理由: multimodalチャットはオープンな視覚的QAを処理します。固定分類法の画像タグ付けは、任意の質問に対する回答ではなく、ラベルを返します。
アクセシビリティのために、何千もの画像に対する記述的な代替テキストを自動生成します。
Image Analysisのキャプション/dense-captions機能を使用して、人間が読める説明を大規模に生成します。
理由: キャプション作成は簡潔な代替テキストを直接生成します。オブジェクト検出は、まだ文章に変換する必要があるバウンディングボックスを返します。
長時間の録画ビデオから、構造化されたフィールドとセグメントレベルの洞察を抽出します。
Azure AI Content Understandingをビデオアナライザーと共に使用し、タイムライン全体にわたって構造化されたschema定義済みの出力を取得します。
理由: Content Understandingはモダリティ全体でgroundingされた構造化出力を生成します。フレームごとの画像呼び出しでは、タイムラインを意識した構造は提供されません。
multimodal agentが、隠された指示テキストを含む可能性のあるユーザー画像を読み取ります。
プロンプトシールド/間接prompt injection検出を有効にし、画像内のテキストを信頼できないデータとして扱い、指示としては扱いません。
理由: 埋め込み画像テキストは古典的な間接prompt injectionベクターです。OCRで抽出したテキストを直接システムプロンプトに渡すと、攻撃者がagentを乗っ取ることができます。
メールから名前、日付、金額を抽出して型付きJSONレコードにします。
ターゲットJSON schemaでLLMをプロンプトし、structured outputsを有効にして、すべてのフィールドが固定形状で返されるようにします。
理由: schema制約付きLLM抽出はオープンな形式を処理し、解析可能なJSONを保証します。脆い正規表現は自然言語の多様性に対して破綻します。
長いサポートのトランスクリプトを簡潔に書き換えた要約を生成します。
長さと焦点の指示を持つabstractive summarizationのためにLLMを使用するか、Languageサービス summarization skillを使用します。
理由: abstractiveな要約は要点を言い換えます。extractiveな文選択は単に文をコピーするだけで、全体的な意味を見逃す可能性があります。
顧客メッセージを感情で分類し、攻撃的なトーンにフラグを立てます。
LLM (またはLanguage sentiment API) を使用して極性をラベル付けし、トーンを検出し、カテゴリと信頼度を返します。
理由: 感情/トーン分析は定義されたラベルを持つ分類タスクです。ラベルschemaのないフリーテキスト生成は、下流でのルーティングが困難です。
30言語にわたる大量のUI文字列を正確かつ安価に翻訳します。
大量で決定論的な翻訳にはAzure AI Translatorを使用し、微妙なニュアンスやコンテキストが重要な箇所にはLLMを予約します。
理由: Translatorは専用に構築されており、安価で、大規模でも一貫性があります。文字列ごとのLLMはコストが高く、実行ごとにトーンが変化する可能性があります。
音声agentは、発信者の音声をリアルタイムで書き起こす必要があります。
Speechサービス のリアルタイムspeech-to-text (または高速書き起こし) を使用して、agentパイプラインにテキストを供給します。
理由: ストリーミングSTTはライブ会話に低レイテンシーの部分的なトランスクリプトを提供します。バッチ書き起こしはオフラインファイル用であり、ライブのやり取り用ではありません。
書き起こしが製品名や医療用語を聞き間違えます。
ドメインオーディオとフレーズリストを使用してCustom Speechモデルをトレーニングし、専門用語の認識を向上させます。
理由: Custom Speechは音響/言語モデルをあなたの用語に適合させます。ベースモデルはあなたのプライベートな専門用語に触れていません。
agentは自然な音声で返答する必要があります。
適切な音声とSSMLを使用してneural Text to Speechを使用し、プロソディー、一時停止、発音を制御します。
理由: Neural TTSとSSMLは、人間のような制御可能な音声を生み出します。SSMLなしのプレーンテキストは、数字や名前に対して平板な表現になります。
vectorのみの取得では、正確なキーワードやコード識別子のマッチを見逃します。
Azure AI Searchでhybrid search (vectorとキーワード) をsemantic rankingと共に使用し、結合された結果を並べ替えます。
理由: hybridとsemantic rerankingの組み合わせは、どちらか単独のシグナルよりも優れています。純粋なvector searchは文字通りの用語を見逃すことがあり、純粋なキーワード検索は言い換えを見逃します。
コーパスには、テキストを選択できないスキャンされたPDFが含まれています。
OCR cognitive skill (Document Intelligence / Vision) をインデックス作成スキルセットに追加し、スキャンされたテキストがチャンク化およびembeddingの前に抽出されるようにします。
理由: OCRエンリッチメントは画像からテキストを取得可能にします。生のスキャン済みPDFをインデックス化しても、検索可能なものは何も生成されません。
取り込み中に、文書ごとにOCR、キーフレーズ抽出、および翻訳を適用する必要があります。
必要なcognitive skillを連鎖させるAI Searchスキルセットを定義し、インデクサが入力するインデックスフィールドに出力を投影します。
理由: スキルセットは、インデックス作成時にエンリッチメントを宣言的にorchestrateします。クエリごとにアプリコードで行うと、作業が繰り返され、再利用が損なわれます。
チャンク化とembeddingをアプリコードではなく、インデックスパイプライン内で処理したい。
AI Search integrated vectorizationを使用して、ドキュメントを分割し、インデックス作成時およびクエリ時にembeddingモデルを呼び出します。
理由: integrated vectorizationは、取り込みとクエリの間でチャンク化/embeddingの一貫性を保ちます。カスタムのクライアント側embeddingはモデルの不一致のリスクがあります。
さまざまなレイアウトを持つ請求書から構造化されたフィールドを抽出します。
Document Intelligenceの事前構築済み請求書モデルを使用するか、カスタムモデルをトレーニングして、信頼度とバウンディング領域を持つ型付きフィールドを返します。
理由: Document Intelligenceはレイアウトを理解し、型付きフィールドを返します。OCRのみのダンプは、フィールドのセマンティクスがない生テキストを提供します。
RAGのために、混合文書のクリーンでgroundingされたmarkdown表現が必要です。
Content Understandingアナライザーを使用して、見出し、テーブル、フィールドgroundingを保持する構造化されたmarkdown出力を生成します。
理由: groundingされたmarkdownは、取得のために構造と引用を保持します。フラット化されたプレーンテキストは、モデルが必要とするテーブルやセクションのコンテキストを失います。
Foundry agentは、実行時にエンリッチされた検索インデックスから取得する必要があります。
AI Searchインデックスをagentの知識ソース/toolとして追加し、各実行が取得され引用された結果に基づいて回答をgroundingするようにします。
理由: インデックスをagent toolとして配線することで、ライブのgroundingされた取得が可能になります。静的なスニペットを指示に貼り付けても、コーパスと同期を保つことはできません。