融資承認モデルは、性別や民族性に基づいて人々に不利益を与えてはなりません。
責任ある AI の公平性の原則を適用する: 人口統計学的グループ間のバイアスを評価し、軽減します。
理由: 公平性は公正な扱いを目指します。信頼性 (一貫した結果) やプライバシー (データ保護) と混同しないでください。
最終確認：2026年6月
AI-901 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
融資承認モデルは、性別や民族性に基づいて人々に不利益を与えてはなりません。
責任ある AI の公平性の原則を適用する: 人口統計学的グループ間のバイアスを評価し、軽減します。
理由: 公平性は公正な扱いを目指します。信頼性 (一貫した結果) やプライバシー (データ保護) と混同しないでください。
自動運転モデルは、予期せぬ状況でも一貫して動作し、安全にフェールセーフする必要があります。
信頼性と安全性を適用する: 厳格なテスト、監視、エッジケースに対するガードレールを設定します。
理由: 信頼性と安全性は、不確実な状況下での一貫した、危害を回避する動作に関するものであり、データが誰に関するものであるかではありません。
健康アプリは個人データを処理するため、漏洩や悪用から保護する必要があります。
プライバシーとセキュリティを適用する: 個人データを保護し、アクセスを制御し、同意を尊重します。
理由: この原則はデータの機密性と保護をカバーします。公平性と包括性は、システムが誰にサービスを提供するかに関するものです。
ソリューションは、能力や背景に関係なく、人々に力を与え、関与させるべきです。
包括性を適用する: 障害を持つ人々を含め、誰もが恩恵を受けられるように設計します。
理由: 包括性は幅広いアクセス可能性と到達性に関するものです。公平性は特に公平な結果に関するものです。
ユーザーは、AI システムがどのように意思決定を行い、その限界が何であるかを理解する必要があります。
透明性を適用する: システムがどのように機能するか、その目的、機能、および限界を説明します。
理由: 透明性はシステムを理解可能にします。説明責任は、誰がその責任を負うかに関するものです。
AI システムの動作に対して誰かが責任を負うことができるよう、明確な所有権とガバナンスが必要です。
説明責任を適用する: 人々はガバナンスフレームワーク内で設計、構築、運用を行い、責任を負い続けます。
理由: 説明責任は人間の責任を割り当てます。透明性はシステムを説明するだけであり、所有権を割り当てるものではありません。
生成 AI モデルがプロンプトから一貫性のある段落を生成する方法を説明します。
大規模言語モデルは、膨大なトレーニングテキストから学習したパターンを使用して、次のトークンを繰り返し予測します。
理由: 生成モデルは確率的トークン予測を介して新しいコンテンツを生成します。保存された回答をそのまま取得するわけではありません。
モデルを選択する: 1つは安価で大量のチャットが必要で、もう1つは複雑な多段階推論が必要です。
タスクに合わせてモデルを選択する — 日常的なチャットにはより小さく/高速なモデルを、難しいタスクにはより大規模な推論モデルを使用します。
理由: 大きいものが常に良いとは限りません。機能、コスト、レイテンシーにはトレードオフがあるため、ワークロードのニーズに応じて選択してください。
モデルをどのように消費するかを決定する: マネージド標準エンドポイントか専用容量か。
変動する負荷には標準 (従量課金制) デプロイメントを、安定した大容量かつ予測可能なパフォーマンスにはプロビジョニングされたスループットを使用します。
理由: プロビジョニングは一貫したレイテンシーのために容量を予約します。標準はトークンごとに課金され、開始するのが最も簡単です。
出力が反復的すぎるため、より創造的で多様な応答が欲しい。
temperature パラメーターを上げてください。確定的で焦点を絞った出力が必要な場合は、0 に近づけて下げてください。
理由: temperature はトークン選択のランダム性を制御します。高い場合は創造的、低い場合は一貫性があります。
応答が文中で途切れるか、出力の長さとコストを制限する必要があります。
max tokens (最大完了長) パラメーターを調整して、応答の上限を設定します。
理由: Max tokens は出力長を制限します。創造性を変えるものではありません — それは temperature または top-p です。
厳密な temperature なしで、トークンの選択を最も可能性の高いセットに制限したい。
top-p (核サンプリング) を使用して、確率の合計が p になる最小のトークンセットにサンプリングを制限します。
理由: Top-p は確率質量によって候補プールを絞り込みます。通常、top-p か temperature のどちらかを調整し、両方を積極的に調整することはありません。
ワークロードは、プロンプトからマーケティングコピーと要約を作成する必要があります。
これは生成 AI ワークロードです — 自然言語の指示からのコンテンツ作成です。
理由: 生成ワークロードは新しいコンテンツを生成します。テキスト分析は既存のテキストから洞察を抽出するだけです。
システムは、最小限の監視で手順を計画し、ツールを呼び出し、目標に向かって行動する必要があります。
これは agentic AI ワークロードです — 推論し、ツールを使用し、アクションを実行する LLM 駆動の agent です。
理由: Agentic は生成に加えて自律性とツール使用を追加します。単なる生成 AI はコンテンツを返すだけです。
ワークロードは、顧客レビューから感情、キーフレーズ、および固有表現を抽出します。
これはテキスト分析 (NLP) ワークロードです。
理由: テキスト分析は既存のテキストを解釈します。生成ワークロードのように新しい文章を生成することはありません。
ワークロードは、通話を書き起こし、応答を読み上げる必要があります。
これは音声ワークロードです — 音声テキスト変換 (speech-to-text) 認識とテキスト音声変換 (text-to-speech) 合成です。
理由: 音声は音声入出力をカバーします。コンピュータービジョンは画像を扱い、音声を扱いません。
ワークロードは、写真からオブジェクトを検出し、テキストを読み取る必要があります。
これはコンピュータービジョンワークロードです — 画像分類、オブジェクト検出、および OCR です。
理由: コンピュータービジョンは画像を解釈します。ドキュメントからの情報抽出は関連していますが、別のタスクです。
ワークロードは、スキャンされた請求書から日付、合計、ベンダーなどのフィールドを抽出する必要があります。
これは情報/データ抽出ワークロード (ドキュメント理解) です。
理由: 抽出はドキュメントから構造化フィールドをプルします。一般的な OCR は生のテキストを返すだけで、ラベル付けされたフィールドは返しません。
テキストブロック全体を読まずに、主要なトピックが必要な場合。
キーフレーズ (キーワード) 抽出を使用して、最も重要な用語を浮上させます。
理由: キーフレーズ抽出は注目すべき用語をリストします。一方、エンティティ検出は人や場所のような固有名詞を分類します。
テキスト中に言及されている人物、組織、場所、および日付を特定する必要があります。
固有表現認識 (エンティティ検出) を使用して、これらのエンティティを分類します。
理由: エンティティ検出は固有名詞をラベル付けします。感情分析は代わりに感情的なトーンをスコアリングします。
レビューが肯定的、否定的、中立的のいずれであるかを知りたい。
感情分析を使用して、テキストに表現されている意見をスコアリングします。
理由: 感情はトーンを測定します。要約はコンテンツを凝縮しますが、極性を判断するものではありません。
長いレポートの短い要約が必要な場合。
テキスト要約 (抽出型または抽象型) を使用してドキュメントを凝縮します。
理由: 要約は意味を保持しながら短縮します。キーフレーズ抽出は用語をリストするだけで、読みやすい要約ではありません。
音声をテキストに変換することと、テキストを音声に変換することを区別する。
音声認識 (speech-to-text) は音声を書き起こします。音声合成 (text-to-speech) は話された音声を生成します。
理由: 認識は入力音声→テキストです。合成はその逆です — 2つの方向を混同しないでください。
Azure でモデルを発見し、デプロイし、AI アプリを構築するための単一の場所が必要です。
Microsoft Foundry portal を使用します — ここにはモデルカタログ、デプロイ、playground、および agent ツールがホストされています。
理由: Foundry は統合ハブです。個々の Azure AI サービスは存在しますが、Foundry はソリューションを構成し、デプロイする場所です。
尋ねられた質問に関係なく、モデルに常に丁寧なサポート agent として応答させたい。
システムプロンプトで動作とペルソナを設定し、特定の質問はユーザープロンプトに入れます。
理由: システムプロンプトは全体的な動作とルールを形成します。ユーザープロンプトはターンごとの要求です。
カタログでモデルを選択し、アプリから呼び出し可能にする必要があります。
Foundry portal でモデルのデプロイを作成します。これにより、エンドポイントとキーが提供されます。
理由: カタログ内のモデルはデプロイされるまで使用できません。デプロイによって呼び出し可能なエンドポイントが公開されます。
コードを記述する前に、プロンプトをテストし、temperature を調整したい。
Foundry portal のチャット playground を使用して、デプロイされたモデルと対話し、パラメーターを調整します。
理由: playground を使用すると、プロンプトと設定を対話的に反復処理できます。実験に SDK は必要ありません。
アプリケーションコードからデプロイされたチャットモデルを呼び出す必要があります。
Foundry (Azure AI) SDK を使用して、デプロイエンドポイントにメッセージを送信するチャットクライアントを作成します。
理由: SDK はエンドポイントを型付きクライアントでラップします。システムメッセージとユーザーメッセージを渡し、完了を読み取ります。
アプリはデプロイされたモデルに対して認証する必要があります。
デプロイのエンドポイント URL を API キーまたは Microsoft Entra ID (Azure AD) 資格情報と共に使用します。
理由: キーベースの認証が最も簡単です。Entra ID はより安全で、コードにシークレットを埋め込むことを回避します。
指示に従い、ツールを使用する AI アシスタントを、あまりコードを書かずに構築したい。
Foundry portal で単一の agent を作成します — その指示、モデル、およびツール (Agent Service) を定義します。
理由: portal の agent ビルダーは動作とツールを宣言的に構成します。オーケストレーションループを手書きする必要はありません。
agent は常に情報源を引用し、話題外の要求を拒否すべきです。
これらのルールを agent の指示 (システムレベルのガイダンス) にエンコードします。
理由: agent の指示は、プレーンなチャットモデルのシステムプロンプトと同様に、ターン全体で一貫した動作を誘導します。
agent は、そのトレーニングデータだけでなく、会社のドキュメントから回答する必要があります。
agent にナレッジ/grounding ツール (例: ファイル検索または Azure AI Search) を与え、データが取得できるようにします。
理由: Grounding/RAG は最新のプライベートコンテキストを提供します。これがないと、モデルは幻覚を起こしたり、古い知識を使用したりする可能性があります。
Foundry agent をプログラムで駆動するためのカスタムアプリが必要です。
Foundry SDK を使用して agent クライアントアプリを構築します — スレッドを作成し、メッセージを追加し、agent を実行し、応答を読み取ります。
理由: SDK はスレッド、実行、およびメッセージを公開するため、アプリは agent をあらゆるワークフローに統合できます。
受信テキストから感情とエンティティを抽出するアプリを構築する必要があります。
Foundry を介してアクセスされる SDK または REST 経由で Azure AI Language (テキスト分析) を使用し、感情および NER 機能を使用します。
理由: 古典的な NLP タスクの場合、Language サービスは目的に合わせて構築されており、一般的な LLM にプロンプトを出すよりも安価です。
ユーザーは質問を話し、デプロイされたモデルにそれに回答させたいと考えています。
音声を音声入力を受け入れる multimodal モデルに送信するか、まず書き起こしてからモデルにプロンプトを出します。
理由: Multimodal モデルは音声を直接取り込むことができます。そうでない場合は、speech-to-text を使用してテキストモデルに供給します。
アプリは高品質の書き起こしと自然な音声出力を必要としています。
Foundry Tools 内で Azure AI Speech を使用して、speech-to-text と text-to-speech を行います。
理由: Speech サービスは、チャットモデル単独で提供できる範囲を超えた、調整された認識と実物そっくりのニューラル音声を提供します。
アプリが自然な音声で応答を読み上げる必要がある。
Azure AI Speech の text-to-speech をニューラル音声と共に使用します。必要に応じて SSML でプロソディを制御します。
理由: ニューラル音声は自然に聞こえます。SSML を使用すると、ペース、ピッチ、発音を調整できます。
アプリは、ユーザーが提供した写真で何が起こっているかを説明し、それに関する質問に答える必要があります。
画像を Foundry の multimodal モデルに送信し、質問でプロンプトを出します。
理由: Multimodal LLM は画像コンテンツについて推論します。従来の Vision サービスは固定タグとキャプションのみを返します。
アプリは、要求に応じてテキスト記述から画像を生成する必要があります。
Foundry に text-to-image モデル (例: DALL-E / 画像生成モデル) をデプロイし、アプリから呼び出します。
理由: 画像生成モデルはプロンプトから視覚要素を作成します。ビジョンモデルは既存の画像を分析するだけです。
画像を分類し、そこから印刷されたテキストを読み取るアプリが必要です。
Foundry を介してアクセスされる Azure AI Vision (画像分析と OCR) を使用して、ビジョンアプリを構築します。
理由: Azure AI Vision は、すぐに使える画像分析と OCR を提供します。一般的なタスクのためにモデルをトレーニングする必要はありません。
アプリは、スキャンされたページから印刷されたテキストと手書きのテキストを抽出する必要があります。
Azure AI Vision の OCR (読み取り) 機能を使用して、認識されたテキストとその場所を返します。
理由: OCR は座標付きの生のテキストを返します。構造化フィールド抽出には、代わりに Content Understanding が必要です。
請求書やフォームから構造化フィールド (合計、日付、明細項目) を抽出する必要があります。
Foundry Tools の Azure AI Content Understanding を使用して、ドキュメントやフォームから構造化データを抽出します。
理由: Content Understanding はラベル付けされたフィールドを抽出します。単なる OCR は非構造化テキストのみを返します。
画像のバッチから構造化された記述とメタデータを抽出する必要があります。
Azure AI Content Understanding を使用して画像を分析し、構造化された出力を返します。
理由: Content Understanding は、自由形式のテキストキャプションを超えて、コンテンツタイプ全体で一貫した構造化結果を生成します。
通話記録を主要なデータポイントを含む構造化された要約に変換する必要があります。
Azure AI Content Understanding を音声に適用して、書き起こしを行い、構造化フィールドを抽出します。
理由: Content Understanding は書き起こしと抽出を組み合わせます。Speech だけでは書き起こししか提供しません。
トレーニングビデオからシーン、トピック、および主要なフィールドを抽出する必要があります。
ビデオに Azure AI Content Understanding を使用して、モダリティ全体で構造化された洞察を抽出します。
理由: 音声ストリームと視覚ストリームを一緒に分析して、単なる書き起こしではなく構造化された出力を生成します。
最小限の労力で、会社のプライベート FAQ 知識をモデルの回答に追加する必要があります。
ファインチューニングではなく、ドキュメントに対する検索 (RAG) でモデルを grounding します。
理由: RAG はクエリ時に現在のデータを注入し、よりシンプルで安価です。ファインチューニングは動作を変更しますが、知識の鮮度を変更するものではありません。
デプロイされたモデルからの有害または安全でないテキストおよび画像出力をブロックする必要があります。
デプロイで Azure AI Content Safety フィルターを有効にして、有害なコンテンツを検出してブロックします。
理由: Content Safety は実行時に責任ある AI ガードレールを強制します。ベースモデル単独では安全性が保証されません。
デプロイ後、応答品質を測定し、ドリフトを監視する必要があります。
Foundry の評価および監視ツールを使用して、出力をスコアリングし、時間の経過とともにメトリックを追跡します。
理由: 評価は品質 (groundedness、関連性) を定量化します。監視は本番環境での回帰を検出します。
1つのアプリケーションのために、モデル、agent、および接続を整理する必要があります。
Foundry プロジェクトを作成します。これにより、デプロイ、接続されたリソース、およびそのソリューションのツールがグループ化されます。
理由: プロジェクトはワークスペースの境界です。接続は Azure AI Search やストレージなどの外部リソースをリンクします。