AI-103 サンプル問題

正解：D

A　小規模モデルは低遅延・低コストが利点だが、規程間の突き合わせのような多段の論理検証では精度が不足しやすい。今回はレイテンシより正確さが優先されている

B　マルチモーダル対応は画像や音声を入力に取るための能力であり、今回の要件はテキストの論理検証。モダリティを増やしても推論の正確さは上がらない

C　ファインチューニングは応答の形式やスタイルを合わせる用途に向く。規程は改定されるため知識を焼き込む対象として不適切で、多段の論理検証能力も微調整では得にくい

D（正解）　正解。推論モデルは中間の推論トークンを生成してから要約応答を返すため、多段の論理検証に向く。生成する推論トークン量はreasoning effortパラメーターで制御できる

正解：C

A　Foundry IQは複数のデータソースを束ねたナレッジ基盤で、今回のように既存のインデックス1つを最短で使う要件に対しては取り込みの作り直しが過剰

B　Code Interpreterはサンドボックス内でPythonを実行するツールで、社内の検索サービスへ接続する手段ではない

C（正解）　正解。Azure AI Searchツールは既存のAzure AI Searchインデックスをそのままグラウンディング元として使う組み込みツールで、取り込みパイプラインを作り直す必要がない

D　File Searchはアップロードした文書に対するベクトル検索で、既存インデックスを再利用できない。取り込み処理を変更しないという要件に反する

正解：B

A　File Searchはアップロード文書へのベクトル検索であり、意味モデルやオントロジーに基づく分析推論はできない

B（正解）　正解。Fabric IQはMicrosoft Fabricの意味的知能レイヤーで、オントロジー・意味モデル・グラフ・データエージェントをモデル化し、OneLakeやPower BIの分析データに対してエージェントが推論できるようにする

C　Foundry IQは企業の構造化・非構造化データを権限認識型のナレッジベースにするマネージドナレッジレイヤーで、分析用の意味モデルやオントロジーを扱うレイヤーではない

D　Work IQはMicrosoft 365の文脈的知能レイヤーで、文書・会議・チャット・ワークフローの協働シグナルを扱う。分析データの意味モデルは対象外

正解：A

A（正解）　正解。ベクトル検索は自然文の意味的な近さを、キーワード検索は型番のような正確な字面の一致を捉える。両方を実行して結果を統合するハイブリッド検索が、この2種類の入力を同時に満たす

B　意味的な近さは捉えられるが、型番のような固有の文字列は埋め込み空間で識別されにくく取りこぼしやすい

C　型番は正確に当たるが、「異音がする」のような表現ゆれのある自然文では文書側の語彙と一致せず取りこぼす

D　検索を省いてコンテキストに詰め込む方式はコンテキスト長とコストの上限に達し、精度も落ちる。検索方式の選定という問いにも答えていない

正解：B

A　ナレッジベースはキュレートした組織のコンテンツにエージェントを根拠づけるための仕組みで、利用者がその場で持ち込む一時的な文書の置き場ではない

B（正解）　正解。File Searchは利用者が提供した文書をやり取りの中で検索するための手段とされている。会話に添付した文書からベクトルストアを作れるため、組織のナレッジとして整備しなくてもその場で参照できる

C　アップロードされた文書をその場で検索する手段ではないうえ、保持する必要のない内容まで蓄積することになる

D　Azure AI Searchツールは既存のインデックスを参照する手段で、利用者ごとの一時的な文書を都度索引に入れる運用は取り込みの作り込みが必要になり過大

正解：D

A　会話履歴は当該会話の文脈であり、数週間後の別セッションをまたぐ継続には向かない。全履歴を毎回送るとコンテキスト長とコストも破綻する

B　File Searchは文書のベクトル検索であり、利用者ごとの記憶の作成・更新・削除といったライフサイクル管理の仕組みを持たない

C　エージェントのバージョンは保存後に不変で、利用者ごとに作る運用は破綻する。instructionsは利用者データの保存場所ではない

D（正解）　正解。memoryツール(プレビュー)はセッションやデバイスをまたいで継続する長期メモリをエージェントに与える仕組みで、スコープとupdate_delayによって記憶の範囲と更新のタイミングを制御する

正解：C

A　Browser Automationは自然言語でブラウザ操作を行うツールで、Web検索によるグラウンディングを目的としたものではない

B　実装自体は可能だが、引用の生成や実行制御まで自前で作ることになる。組み込みのWeb searchツールで要件を満たせる

C（正解）　正解。Web searchはリアルタイムの公開Web情報をインライン引用付きで返す組み込みツールで、Webグラウンディングを追加する推奨方法とされている

D　Grounding with Bingは市場別フィルタリングなどの高度なWebグラウンディング用途に位置づけが移っており、通常のWebグラウンディングの推奨経路ではない

正解：C

A　instant accessとデプロイは同じプロジェクトで併存できる。ただし既存のデプロイ名がモデル名と衝突する場合はデプロイが優先される

B　管理者はAzure Policyでinstant accessを無効化できるが、それはデプロイ作成の前提条件ではない

C（正解）　正解。instant access(プレビュー)はデプロイを作らずモデル名で呼び出せるが、既定のガードレールが適用され、カスタムガードレールやRAIポリシーをモデル単位で構成できない。モデルごとに異なるフィルターが必要ならデプロイを使う

D　instant accessのモデルには既定のガードレールが適用され、モデル単位のカスタム構成はできない

正解：D

A　分類の精度は上がりうるが、例示を増やすほど入力トークンが伸びる。単純な判定を大量に処理する用途では単価と遅延の両方で不利

B　推論トークンの生成量は抑えられるが、モデル自体の単価は下がらない。多段の推論が不要な判定に推論モデルを充てるのは過大

C　テキストで扱える入力をわざわざ画像にするとトークンも処理時間も増える。モダリティを増やす理由がない

D（正解）　正解。小規模なモデルは低遅延かつ低コストで、定型的な分類のような限定されたタスクに向く。要件がコストと応答時間の最小化であり多段の推論を求めていない場合の選択になる

正解：A

A（正解）　正解。ベースモデル選定の段階では、公開データセットや自社のデータで候補モデルの品質・タスク性能・安全性プロファイルを比較できるFoundryのベンチマークが用意されている

B　継続的評価は公開後の本番トラフィックを対象とする仕組みで、実装前のモデル選定には使えない

C　AIレッドチーミングエージェントは敵対的攻撃をシミュレートして安全性とセキュリティの脆弱性を洗い出すもので、品質とタスク性能の横並び比較が目的ではない

D　トレースは実行済みアプリケーションの挙動を追う仕組みで、まだ実装していない候補モデルの比較には使えない

正解：D

A　申請フォームは共通だが、対象はAzureが販売するモデル・Azure OpenAIモデル・Anthropicモデルに限られる

B　リージョンの追加はクォータ増額の手段ではない。サブスクリプションレベル管理の対象モデルでは全リージョンで同一のプールを共有する

C　デプロイ種別の対応可否はモデルごとに異なり、パートナー提供モデルがPTU限定という規定はない

D（正解）　正解。クォータ増額申請の対象はAzureが販売するFoundry Models・Azure OpenAIモデル・Anthropicモデルで、それ以外のパートナーおよびコミュニティ提供モデルは増額に対応していない

正解：C

A　Visionは視覚コンテンツが対象で、文書のフィールド抽出や音声の処理を1つのスキーマに束ねる役割は担わない

B　Foundry IQは抽出済みの知識をエージェントへ提供するナレッジレイヤーで、抽出そのもののスキーマを定義するサービスではない

C（正解）　正解。Azure Content Understandingはドキュメント・画像・動画・音声の4モダリティを扱い、アナライザーにフィールド抽出スキーマを定義して構造化出力を得られる

D　Document Intelligenceは文書を対象とするサービスで、写真や録音を同じスキーマで扱えない。新規構築ではContent Understandingへの移行が推奨路線

正解：D・E

A　Global種別は任意のAzureリージョンで処理されうるため、データ境界の要件を満たさない

B　PTUによる予約はあるが処理はグローバルにルーティングされるため、データ境界の要件を満たさない

C　DeveloperTierは微調整モデルの評価専用で、データ所在の保証がない

D（正解）　正解。DataZone種別はMicrosoftが定義したデータゾーン(US・EU・APAC)の中でのみ推論データを処理する。EUデータゾーンはAzureのEUデータ境界に含まれるリージョンで処理される

E（正解）　正解。データゾーン内での処理と予約済みPTUによる安定したスループットを両立する種別で、EUデータ境界の要件を満たす

正解：A・E

A（正解）　正解。reasoning effortはLLMの処理量を決める設定で、処理を増やすと関連性は上がる一方、時間がかかり課金対象のLLMリソースを消費する

B　reasoning effortは取得時の設定で、索引側の埋め込みの再生成とは無関係

C　アクセス制御リストの同期は対応するナレッジソース側の機能で、reasoning effortでは切り替わらない

D　ナレッジソースの形態はソースの定義で決まり、reasoning effortでは変わらない

E（正解）　正解。エージェンティック検索のエンジンはlowとmediumのreasoning effortでLLMによるクエリプランニングを使い、mediumでは初回の結果が関連性の基準を満たさない場合に反復的な検索を行う

正解：C

A　azure-ai-inferenceは統一プロジェクトクライアント以前の形で、エンドポイントを複数管理することになる。エージェントや評価といったFoundry固有の機能にも到達できない

B　改称前のリソースモデルの書き方。現行はプロジェクトエンドポイント1つに集約するのが推奨で、エージェントや評価はこの経路では扱えない

C（正解）　正解。Foundry SDKはプロジェクトAPI全体を単一のプロジェクトエンドポイント経由で公開する薄いクライアントで、2.x系がFoundry(新)に対応する。get_openai_client()が返すOpenAI互換クライアントからResponses APIを呼び出せる

D　1.x系はFoundry(クラシック)向けで、スレッドと実行はAssistants API時代の旧モデル。新規開発で選ぶ構成ではない

正解：B

A　モデルを増やしてもエンドポイントの種類は変わらない。エージェントや評価のAPIはこのリソースからは提供されない

B（正解）　正解。Azure OpenAIリソースが提供するのは/openai/v1エンドポイントだけで、エージェント・評価・Foundry固有ツールにはFoundryリソースとその配下のプロジェクトが必要になる

C　カスタムサブドメインはエンドポイントのホスト名を変えるだけで、提供されるAPIの範囲は広がらない

D　検索の接続はグラウンディングの構成要素にすぎず、エージェントや評価を実行できるようにはならない

正解：D

A　同一セッション内で文脈を連鎖させる方法。再訪時に会話全体を再開する起点としては、応答IDをアプリ側で保持し続ける必要があり管理が複雑になる

B　instructionsは振る舞いを定める指示であって履歴の保管場所ではない。要約による情報欠落も避けられない

C　エージェントバージョンは定義の版管理であり、会話履歴を保持する仕組みではない

D（正解）　正解。会話は一意のIDを持つ永続オブジェクトで、作成後はセッションをまたいで再利用できる。応答生成時に会話全体が入力として渡され、生成結果は同じ会話へ追記される

正解：A

A（正解）　正解。storeをfalseにするとサービスは応答を永続化しないため、previous_response_idによる参照ができなくなる。文脈はアプリ側で持ち回る必要がある

B　保存していない応答は参照できないため、この組み合わせでは多ターンの文脈が続かない

C　作成した時点でサーバー側に保持されることに変わりはなく、削除するまでの間は要件を満たさない。文脈も失われる

D　プロンプトキャッシュの保持方針は入力トークン計算の再利用に関する設定で、応答履歴の保存有無とは無関係

正解：B

A　会話を使う場合はサービス側で入力が調整されるため、単純に失敗するわけではない

B（正解）　正解。会話がモデルの対応コンテキストサイズを超える場合、入力コンテキストが自動的に切り詰められる。会話そのものは切り詰められず、その一部だけが応答生成に使われる

C　会話に格納されたアイテムが自動削除されることはない。切り詰められるのは応答生成に渡される入力の側

D　そのような遷移はない。同じ会話を継続して使える

正解：C

A　エージェントは名前付き・バージョン管理された永続資産になる。ツールも履歴も不要な単発処理では管理対象を増やすだけになる

B　ホステッドエージェントは独自コードのオーケストレーションが必要な場合の選択肢で、単純な要約には過剰な構成

C（正解）　正解。エージェントを定義しなくても応答は生成できる。構成をリクエストに直接与え、その応答にのみ適用する形はツールが最小限の単純なシナリオに向く

D　利用者の入力が同じ会話に混ざり、無関係な文脈が応答に影響する。要約に会話履歴は不要

正解：D

A　バージョンは定義の変更履歴を管理する仕組みで、テナント数だけ版を作るのは運用負荷が大きい。実行時の値の差し込みには適さない

B　会話への追加はできるが、モデルはそれを指示ではなく過去の発話として扱う。指示自体をパラメーター化する仕組みではない

C　利用者の入力とシステム側の値が混ざり、入力次第で上書きされうる。指示のパラメーター化としては脆弱

D（正解）　正解。構造化入力はエージェント定義側にプレースホルダーを定義し、実行時に実際の値を差し込む仕組み。構成ごとに別のエージェントバージョンを作らずに済む

正解：A

A（正解）　正解。監査可能で再現性が求められる判断はルールエンジンや分類器に任せ、自然さが必要な生成の段だけを言語モデルに割り当てるハイブリッド構成が適切

B　temperatureを下げると出力は安定しやすくなるが、同一入力に同一出力が返ることが保証されるわけではない。監査要件の根拠にはできない

C　件数が多い業務では人手確認が律速になる。そもそも判定の再現性という要件を技術的に満たしていない

D　推論特化モデルでも生成である以上、同一入力に同一出力が返る保証はない。監査要件に対する答えになっていない

正解：C

A　同一の重い処理を多重に実行するだけで、トークン消費と負荷が増える。タイムアウトの解決になっていない

B　出力が途中で打ち切られるだけで、分析結果は得られない

C（正解）　正解。長時間かかる生成はバックグラウンドで開始し、応答の状態が完了になるまで監視してから取得する。ストリーミングと組み合わせて途中経過を返すこともできる

D　storeは応答を保持するかどうかの設定で、生成そのものの所要時間には影響しない

正解：B

A　形式の再現性は上がるが、あくまで例示による誘導であり逸脱しないことを保証しない

B（正解）　正解。構造化出力はスキーマをリクエストに与えてモデルの出力を準拠させる仕組みで、項目名や型の逸脱を防げる。プロンプトでの依頼と違い形式が保証される

C　ばらつきは減るが、構造そのものを保証する仕組みではない

D　想定外の形が来たときに壊れる後追いの対処で、モデル側で形式を保証する手段が先にある

正解：C

A　定義から分かるのは何が使えるかまでで、実際にどう呼ばれたかは分からない

B　output_textは利用者へ提示する本文で、ツール呼び出しの引数や結果は通常含まれない

C（正解）　正解。会話はメッセージだけでなくアイテムを格納し、ツール呼び出しの記録とツールが返した出力もアイテムとして残る。次のターンの文脈として再利用されるのもこれらのアイテム

D　再現しても内部で何が起きたかは見えない。調査には実行時の記録が必要

正解：D

A　同じ前段を2回処理することになりトークンが二重にかかる。分岐の起点をそろえる正攻法でもない

B　後の指示が前の結果を引き継いでしまい、同じ状態からの2案にならない

C　毎回すべての文脈を送り直す構成になり、分岐のための仕組みとしては非効率。保存しない設定は分岐とは別の論点

D（正解）　正解。同じ応答IDを起点に別々の応答を生成すれば、その時点の状態から会話を分岐できる。前段の処理を繰り返す必要がない

正解：A

A（正解）　正解。現行のFoundryではスレッド・メッセージ・実行という旧モデルに代わり、会話・アイテム・応答という用語と単一の入口であるResponses APIに再編されている

B　ベクトルストアはファイル検索の索引、評価の実行は品質測定の仕組みで、いずれも会話状態の置き換え先ではない

C　エージェントバージョンは定義の版管理、構造化入力は実行時の値の差し込みで、どちらも会話履歴の受け皿ではない

D　エンドポイントを変えても旧来のスレッドと実行の呼び出し形は現行のAPI体系に存在しない。用語とAPIの両方を移行する必要がある

正解：C

A　ハイブリッド検索だけが行われるという理解が誤り。質問の書き換えも取得結果の再ランクもツール側で行われる

B　既定の検索はキーワードと意味の両方を使うハイブリッド検索で、ベクトル検索だけが行われるわけではない

C（正解）　正解。File Searchは問い合わせを受けると、検索向けに質問を書き換え、複雑な質問を並列の検索へ分解し、キーワードと意味を組み合わせたハイブリッド検索を実行して、結果を再ランクしてから応答に渡す。この一連の処理は既定の動作として提供される

D　複雑な問い合わせを並列の検索へ分解する処理もツール側に含まれる。分割を自前で作る必要はない

正解：C

A　同じ内容が複製され、更新の反映漏れが起きる。利用者ごとのアクセス権も反映されない

B　索引は共有できるが、検索の設定はエージェントごとに持つことになる。呼び出し元の権限に基づく絞り込みも自動では行われない

C（正解）　正解。Foundry IQのナレッジベースは複数のナレッジソースをまとめた最上位のリソースで、複数のエージェントで共有できる。アクセス制御リストの同期と呼び出し元のMicrosoft Entra IDでのクエリ実行により、権限を踏まえた取得ができる

D　要約では原文の根拠を示せず、引用も出せない。権限に応じた出し分けもできない

正解：D

A　文単位では文脈が細かく分断されすぎる。既定はトークン数で定義されている

B　重複がないと境界をまたぐ記述が分断される。既定値としても大きすぎる

C　チャンクサイズは合っているが重複の値が異なる。既定の重複はもっと大きく取られている

D（正解）　正解。既定は800トークンのチャンクを400トークン重複させ、text-embedding-3-large(256次元)で埋め込む。応答に渡されるチャンクは最大20個

正解：A

A（正解）　正解。query_typeを指定しない場合の既定はvector_semantic_hybridで、ベクトル検索とキーワード検索を組み合わせたうえでセマンティック再ランクが適用される

B　vectorはベクトル検索のみを行う設定で、完全一致に強いキーワード検索が失われる。既定はキーワード検索を含む

C　simpleはキーワード検索のみで、意味的な近さを扱わない。要求とは逆の設定

D　query_typeはツールの構成として指定でき、simple、vector、semantic、vector_simple_hybrid、vector_semantic_hybridから選べる

正解：C

A　生成後に引き伸ばしても情報量は増えないため、バナーとして必要な精細さが得られない

B　nは同じプロンプトから独立した候補を複数得るための指定で、連結してもつながった1枚の構図にはならない

C（正解）　正解。gpt-image-2は各辺が16ピクセルの倍数、長辺は3,840ピクセルまで、アスペクト比は3:1までという範囲で任意の解像度を指定できる

D　qualityは生成の品質と所要時間の兼ね合いを決める指定で、選べる出力サイズは変わらない

正解：A

A（正解）　正解。マスクはメインの画像入力と同じ型で渡し、アルファ値が0の完全に透明な画素が編集対象の領域を表す。寸法は元画像と一致させる

B　編集領域はアルファチャネルで示すため、塗り分けた不透明な画像では領域を伝えられない。JPEGはアルファチャネル自体を持たない

C　編集の対象範囲を座標で受け取るパラメーターはない。領域はマスク画像で表現する

D　文章の指示だけでは編集範囲が保証されず、意図しない箇所まで変わる。範囲を確実に限定するのがマスクの役割

正解：D

A架空　実在しないパラメーター。透過背景はbackgroundとoutput_formatの組み合わせで指定する

B　JPEGはアルファチャネルを持たないため、圧縮の指定をどう変えても透過は表現できない

C　後処理で単色を抜く方法は被写体の中の同じ色まで消えるため、素材としての品質を保てない

D（正解）　正解。透過背景はbackgroundパラメーターで要求し、アルファチャネルを保持できるようoutput_formatをpngにする必要がある

正解：B

A　応答は速くなるが生成物の品質が落ちるため、品質を落とせないという要件に反する

B（正解）　正解。gpt-image-1系とgpt-image-2はストリーミングに対応し、partial_imagesに0〜3の値を指定すると最終画像の前に中間画像が返る。品質を下げずに体感の待ち時間を短縮できる

C　候補が増えるだけで最初の表示までの時間は短くならず、処理量はむしろ増える

D　待ち時間そのものは変わらず、対話的な体験を損なう

正解：C

A　生成の精細さは上がるが、入力画像の特徴をどれだけ引き継ぐかを決める指定ではない

B　detailは視覚理解を行うチャットモデルで入力画像の解像度を制御する指定で、画像編集の忠実度とは関係しない

C（正解）　正解。input_fidelityは入力画像のスタイルや特徴、とくに顔の特徴にどれだけ寄せるかを制御する。gpt-image-1-miniはこのパラメーターに対応しないため、対応するモデルを選ぶ必要がある

D　編集対象に含めた領域こそが作り替えられる。顔立ちを保ちたいなら対象から外すのが筋で、忠実度の制御にはならない

正解：A

A（正解）　正解。画像生成ツール（プレビュー）はgpt-image-1と、互換性のあるオーケストレーターモデルの2つのデプロイが同一プロジェクトに要る。Responses要求にはx-ms-oai-image-generation-deploymentヘッダーを付ける。成功していれば出力にimage_generation_call項目が含まれる

B　命令の書き方はツールの呼び出しを促す助けにはなるが、デプロイやヘッダーが欠けていれば画像は生成されない

C　Sora 2は動画を生成するモデルで、画像生成ツールの前提条件ではない

D　画像生成ツールはプロンプトエージェントでもホステッドエージェントでも使えるため、形式を変えても原因は解消しない

正解：D

A　参照として渡せるのは単一の画像で、複数枚から選ばせる仕組みはない

B　文章の説明では元の写真の構図や質感を再現できない。画像そのものを参照として渡す

C　自動では調整されず、一致していない要求は失敗する

D（正解）　正解。input_referenceは最初のフレームの視覚的な起点として使う単一の参照画像で、元画像と最終的な動画の解像度は一致させる必要がある。指定できる値は720×1280と1280×720。Sora 2による動画生成はプレビュー段階

正解：B

A　レガシー機能に分類され、既存実装の維持のために提供されている。新規設計の基盤としては推奨されない

B（正解）　正解。PII検出は言語検出・固有表現認識(NER)・Text analytics for healthとともにコア機能に位置づけられ、継続的な投資と機能更新の対象になっている

C　既存のワークロード向けに安定して提供されるレガシー機能であり、長期を見据えた設計の土台には位置づけられていない

D　カスタムモデルを学習できるがレガシー機能に分類される。既存実装の継続利用が前提

正解：B

A　原文にない新しい文を生成する方式のため、逐語性を求める監査要件を満たせない

B（正解）　正解。原文から重要な文をそのまま選び、元の位置を保ったまま返す方式なので、要約の全文が原文に存在することを保証できる

C　出力は生成された文であり、原文の表現がそのまま使われる保証がない

D　長い会議を章立てして整理する機能であり、逐語性という要件には応えない

正解：C

A　構文として妥当なJSONであることは保証されるが、特定のスキーマに準拠することまでは保証されない

B　出力の傾向を寄せるだけで、スキーマ準拠を機構として保証する手段にはならない

C（正解）　正解。与えたJSON Schemaにモデルの出力を厳密に一致させられる。全項目をrequiredにし、additionalPropertiesをfalseにする必要がある点に注意する

D　揺れは減るがスキーマからの逸脱を防ぐ仕組みではなく、連携失敗のリスクは残る

正解：A

A（正解）　正解。単一のファイルを構造と書式を保ったまま翻訳し、翻訳済み文書を呼び出し元へ直接返す。Blob Storageアカウントを必要としない

B　元の文書と訳文それぞれのコンテナーを持つBlob Storageアカウントが前提になるため、要件に反する

C　平文を対象とする機能であり、Word文書の書式やレイアウトは失われる

D　分野固有の用語やスタイルを適応させる仕組みで、文書ファイルの書式保持とは別の論点

正解：A

A（正解）　正解。5件から10,000件の対訳セグメントを取り込み、数分でカスタムのバイリンガルインデックスを構築して、対応する大規模言語モデルを適応させられる

B　用語やスタイルの適応はできるがモデルの学習を伴うため、数分で利用を開始したいという要件には合わない

C　リクエストごとに個々の語の訳を指定する仕組みで、6,000件の対訳資産を活かす手段にはならない

D　品質は担保できるが、既存の対訳資産を自動的に反映する仕組みではなく、要件の解決になっていない

正解：A

A（正解）　正解。実行時に自然文の指示を渡して訳文のトーンや用語の扱いを制御でき、指示が変わっても再学習や再構成を必要としない

B　ニューラル機械翻訳として高速で安定するが、案件ごとに変わる自然文の指示を受け付ける仕組みがない

C　学習データの準備と再学習が案件のたびに必要になり、都度変わる指示には追随できない

D　情報が欠落するうえ、指示を訳文へ反映するという本来の要件にまったく応えていない

正解：A

A（正解）　正解。翻訳を抑止する範囲をマークアップで原文中に指定する機能があり、指定した語句をそのままの表記で出力させられる

B　文がまるごと未翻訳のまま残るため、周囲の説明文が読めなくなり品質が大きく落ちる

C　訳語が一意に定まらず、語形の変化や語順の入れ替わりに追随できないため確実性がない

D　訳語を寄せることはできるが、原文の表記のまま残すことを保証する仕組みではない

正解：A

A（正解）　正解。ナレッジベースはナレッジソースをIDで参照しており、参照が残っている間は削除できない。参照を外してから削除する

B　実行の停止と参照関係の解消は別の話であり、削除が拒否される原因は解消されない

C　リソースの削除の可否とリージョンには関係がなく、移行の作業だけが無駄になる

D　取得時のLLMの処理量を決める設定であり、リソース間の依存関係とは無関係

正解：A

A（正解）　正解。リモートのナレッジソースはコンテンツを取り込まず、クエリ時にプラットフォーム側のAPIから直接取得する(プレビュー)

B　インデクサーパイプラインを生成してコンテンツを取り込む方式であり、取り込まないという要件に反する

C　Blobコンテナーからインデクサーパイプラインを生成する方式で、SharePointのサイトを直接の対象にできない

D　既存のインデックスをラップする方式であり、取り込み済みのコンテンツがあることを前提とする

正解：A

A（正解）　正解。ファイルをAzure AI Searchへ直接アップロードでき、外部のストレージもインデクサーパイプラインも用意せずに検索インデックスが生成される(プレビュー)

B　Blob Storageのコンテナーを用意することが前提になり、外部ストレージ不要という要件に反する

C　レイクハウスからインデクサーパイプラインを生成する方式で、こちらも外部のデータストアが前提になる

D　公開されているWebの情報をクエリ時に取得する方式で、手元のPDFを対象にできない

正解：A

A（正解）　正解。minimalはLLMによるクエリプランニングを行わない構成で、回答の合成とWebのナレッジソースは利用できない

B　リモートのナレッジソースであり、そもそもコンテンツの取り込みを行わない

C　そのような登録数の制約は設定されておらず、機能しない原因にはならない

D　minimalではナレッジベースに登録された全てのソースが常に検索されるため、この説明は誤り

正解：A

A（正解）　正解。LLMによるクエリプランニングを行わず、ナレッジベース内の全ソースへ直接テキスト検索とベクトル検索を発行する。挙動が予測しやすく検索APIからの移行に推奨される。出力モードはextractiveDataに限られる点に注意する

B　既定の設定で、LLMが1パスのクエリプランニングとソース選択を行うため、制御を自分たちで持ちたいという要件と合わない

C　反復して検索する構成であり、制御を手放すうえにコストとレイテンシがさらに増える

D架空　このような設定値は存在しない。指定できるのはminimal・low・mediumの3段階