AI-901 無料模試（本番形式20問・登録不要）｜Azure資格の森

信頼性と安全性（Reliability & safety）は、想定外の入力や異常時でも、AIが予測可能で安全な範囲に収まって動作し続けることを求める原則です。

防災案内を止めずに安全側で出し続ける設計はその実践で、十分なテストと監視で担保します。データ保護を扱う「プライバシーとセキュリティ」とは別軸です。

公平性（Fairness）は属性によって結果や精度に不当な差を出さない“偏りのなさ”、包括性（Inclusiveness）は多様な人が等しく使える“アクセシビリティ”の原則です。

よく混同しますが、前者は結果の偏り、後者は使えるかどうかが焦点です。

透明性（Transparency）は判断の根拠や能力・限界の“説明可能性”、説明責任（Accountability）は結果に対する“責任の所在”です。

この2つは取り違えやすい定番の対で、「根拠を示せるか（透明性）」と「誰が責任を負うか（説明責任）」で区別します。

temperature（温度）は出力のランダム性を調整するパラメータで、下げると決定的で一貫した出力に、上げると多様で創造的になります。

堅実に揃えたい法務文書では低く設定します。出力の長さを決める「max tokens」や、配置の「リージョン」は、表現の揃いとは関係ありません。

モデルを機能で選ぶ観点は、必要なモダリティ（テキスト/画像/音声）と、一度に扱える入力量（コンテキスト長）が中心で、ほかにコスト・速度・能力も判断材料になります。

デプロイのリージョン（データ所在）や利用料金の支払いサイクルは、運用・契約の設定で、“できること”の選定観点ではありません。

モデルのデプロイ構成では、処理場所や課金方式を決める「デプロイ種別」（Standard／Global Standard／Provisioned など）と、1分あたりの処理量の上限「TPM（クォータ）」を指定・確認します。

利用者の属性や画面の見た目は、デプロイ構成とは無関係です。

音声認識（STT＝Speech to Text）は、音声を文字に書き起こす機能です。

逆に、文字を音声に変換するのは音声合成（TTS＝Text to Speech）で、向きが逆になります。Azureでは Speech サービスが両方を担当します。

コンピュータービジョン（Computer Vision）は、既存の画像を解析して、物体の検出・分類・位置特定や、画像内の文字の読み取り（OCR）を行うワークロードです。

プロンプトから新しい画像を作る「画像生成」とは逆向きで、書類の項目化を行う「情報抽出」とも異なります。

エージェント型AI（agentic AI）は、目標に向けて自分で手順を判断し、検索・予約・API呼び出しなどのツールを使って複数ステップを進めるAIです。

単発の生成AI呼び出しは1回の入力に1回応答するだけで、自律的な判断やツール利用はしません。動作にはどちらもモデルが必要です。

効果的なシステムプロンプトの原則は「明確・具体的」です。AIに期待する役割（例：簡潔なサポート役）、出力形式（例：箇条書き3点）、守るべき制約（例：社内IDは出さない）、必要なら模範例（few-shot＝手本となる例をいくつか見せる手法）まで指定するほど、応答は意図どおりに安定します。

誤答について：「うまく答えて」だけでは曖昧で解釈がぶれます。役割を書かず毎回ユーザーメッセージに入れる方法は、固定ルールを会話全体に効かせられず非効率です。temperature の最大化はランダム性を上げる設定で、安定とは逆方向に働きます。

参考: Microsoft Learn「生成AIとエージェントの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-with-generative-ai-and-agents/

生成モデルの呼び出しは本来1回ごとに独立しており、そのままでは前の発言を覚えていません。多ターンで文脈を保つには、直前の応答の id を次のリクエストの previous_response_id に渡すか、openai.conversations.create() で会話オブジェクトを作り、同じ会話 id を毎回の呼び出しに渡し続けます。

誤答について：資格情報の作り直しは認証のやり直しにすぎず、文脈は引き継がれません。temperature はランダム性の調整で、記憶の機能ではありません。リージョンの変更は配置場所の話で、会話の記憶とは無関係です。

「多ターンの記憶＝会話ID（conversation）の引き継ぎ」という対応はAI-901コード問題の頻出ポイントです。

参考: Microsoft Learn「生成AIとエージェントの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-with-generative-ai-and-agents/

現行のFoundry SDK＋Responses APIの流れは、AIProjectClient を作る→get_openai_client() でOpenAI互換クライアントを得る→responses.create を呼ぶ→応答テキストを output_text から読む、です。設問はこの中の「誤り」を選ぶ形式で、choices[0].message は旧 chat.completions API の読み取り方のため、現行手順の説明としては誤りです。

A・B・Cの3つはいずれも現行手順の正しい記述なので、「誤っているもの」には該当しません。

「output_text（現行のResponses）⇔ choices[0].message（旧チャットAPI）」という新旧の対は、AI-901コード問題の定番の引っかけです。

参考: Microsoft Learn「生成AIとエージェントの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-with-generative-ai-and-agents/

新しいFoundryのプロジェクトAPI（from azure.ai.projects import AIProjectClient の書き方）には、パッケージ azure-ai-projects の2系（>=2.0.0）が必要です。1系（==1.0）は旧クラシック構成向けの別世代APIで互換性がなく、誤って入れるとコードが想定どおり動きません。

誤答について：バージョンを下げて動作が速くなることはありません。課金は利用量ベースの仕組みで、パッケージのバージョンとは無関係です。「画像生成だけ可能になる」ような機能制限の違いでもありません。

「azure-ai-projects の1系＝旧クラシック／2系＝新プロジェクトAPI」というバージョンの罠は、AI-901のpipパッケージ問題の定番です。

参考: Microsoft Learn「生成AIとエージェントの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-with-generative-ai-and-agents/

エージェントは project.agents.create_version に PromptAgentDefinition(model=…, instructions=…) を渡して作成し、役割は instructions で指定します。「モデル＋指示＋ツール」を名前付きで保存して再利用できるのが特徴で、作成後はコードを書く前にFoundryポータル上で応答をテストして動きを確かめられます。

誤答について：「デプロイ済みモデルは不要」は誤りで、指示を解釈する頭脳としてモデルが必須です。「ポータルでテストできない」も逆で、ポータルでのテストが標準の流れに含まれます。

「create_version＋instructions」というメソッド名・引数名の対応は、AI-901コード問題の頻出ポイントです。

参考: Microsoft Learn「生成AIとエージェントの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-with-generative-ai-and-agents/

決まった構造（ISO言語コード＋信頼度スコア）で言語を判定したいときは、Azure AI Language のSDK（パッケージ azure-ai-textanalytics）の detect_language を使います。専用サービスのため出力形式が常に一定で、プログラムでそのまま後続処理に使えます。

誤答について：一般の生成モデルでも言語は当てられますが、確率的に文章を作る仕組み上、表現がぶれて構造化出力の安定性に欠けます。画像生成モデルは画像を「作る」側で言語判定はできません。SpeechSynthesizer は音声合成（文字→音声）のクラスで、検出の機能ではありません。

「構造化された結果が要るなら専用SDK、柔軟さなら生成モデル」という選択軸はAI-901の頻出テーマです。

参考: Microsoft Learn「Azureでのテキスト分析の使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-text-analysis-azure/

Voice Live（パッケージ azure-ai-voicelive）は、音声認識（STT）→推論→音声合成（TTS）という3段階を1つのリアルタイムAPIに統合したサービスで、「話しかけると音声で答える」対話アプリを部品の組み合わせなしで作れます。

誤答について：azure-cognitiveservices-speech はSTT/TTSを個別の部品として組むためのパッケージで、統合対話用ではありません。azure-ai-textanalytics はテキスト分析用、openai は生成モデルへの問い合わせ用で、いずれもリアルタイム音声対話は担当しません。

「統合ならVoice Live、個別ならSpeech SDK」という使い分けと、パッケージ名の対応がAI-901の問われどころです。

参考: Microsoft Learn「Azureでの音声の使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-speech-azure/

アップロードされた写真について質問し、モデルが画像を読み取って答えるのは「プロンプト内の視覚的入力の解釈」で、画像とテキストを同時に受け取れるマルチモーダルモデルの能力です。実装では responses.create の入力に、画像（input_image）とテキストを一緒に含めて渡します。

誤答について：画像生成は新しい画像を「作る」側で、既存画像を「読む」今回とは逆向きです。音声合成は文字→音声の変換で画像とは無関係、音声からの情報抽出は入力の種類（音声）がそもそも違います。

「読む（視覚入力の解釈）⇔ 作る（画像生成）」という向きの区別が、AI-901ビジョン問題の判断軸です。

参考: Microsoft Learn「Azureでのビジョンの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-vision-azure/

マルチモーダルモデルへの視覚入力は、openai の responses.create の入力に {“type”: “input_image”, …} の項目を含め、画像をURLまたはbase64データURLで渡します。テキスト（input_text）と画像を同じリクエストにまとめて渡せる点が要点です。設問は「誤り」を選ぶ形式で、音声認識のクラス（SpeechRecognizer）は音声→文字の変換用のため、「画像を音声認識のクラスに渡す」という記述が誤りです。

A・B・Dはいずれも視覚入力の正しい実装の記述なので、「誤っているもの」には該当しません。

「input_image という型名」と「URL／base64という2つの渡し方」は、AI-901ビジョン実装の頻出ポイントです。

参考: Microsoft Learn「Azureでのビジョンの使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-vision-azure/

会議動画からの要点抽出は Azure AI Content Understanding の守備範囲です。対応する4種類（書類・画像・音声・動画）に動画が含まれており、議題や決定事項のような重要情報を構造化して取り出せます。

誤答について：画像生成モデルは新しい画像を「作る」側で、抽出はできません。テキスト埋め込みモデルは検索・類似度計算のためのベクトル化で、内容の取り出しではありません。音声合成は文字→音声の変換で、動画を読み取る処理とは逆向きです。

「動画からの抽出も Content Understanding」という対応範囲の広さが、情報抽出分野の最重要ポイントです。

参考: Microsoft Learn「情報抽出の使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-information-extraction/

Content Understanding のSDK呼び出しは、①ContentUnderstandingClient を作る→②begin_analyze(analyzer_id=”prebuilt-invoice” など, inputs=[{“url”: …}]) で分析を開始する→③poller.result() で完了を待って結果を受け取る→④結果の fields（抽出フィールド）を読む、の順です。メソッド名の begin_ は「時間のかかる処理（長時間実行操作）を開始する」印で、結果を poller 経由で受け取るのが約束事です。

誤答はいずれも順序の入れ替えで、クライアント生成前のメソッド呼び出し（B）、分析開始前の結果受け取り（C）、完了前のフィールド読み取り（D）は、どれも実行できません。

SDKの手順並べ替えは「クライアント→開始→待つ→読む」という型で覚えるのがAI-901対策の近道です。

参考: Microsoft Learn「情報抽出の使用を開始する」
https://learn.microsoft.com/ja-jp/training/modules/get-started-information-extraction/