AI モデルのしくみと構成の要点整理と想定問題

正解: C 【A（不正解）】 ？ 人が書いた規則に沿って文を作る昔ながらの方法です。 LLM は規則で文を組み立てるのではなく、学習したデータから続きを予測して文を作る。 【B（不正解）】 ？ 質問と回答の対応表を引く方法です。 LLM には質問専用の回答表はない。質問の続きとして最もありそうな文を生成している。 【C（正解）】 ？ 直前までの文から続きを予測する方法です。 公式の説明どおり、LLM は直前までの文に続く可能性が最も高い語を予測し、それを繰り返して文を作る。 【D（不正解）】 ？ 外部の情報を探して持ってくる方法です。 モデル単体は検索をしない。最新情報を使うには、検索などの道具やグラウンディングを組み合わせる。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）／大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: B 【A（不正解）】 ？ 意味を数値の並びで表したものです。 埋め込みはトークンに割り当てるベクトルで、文章を区切る単位そのものではない。 【B（正解）】 ？ 入出力の量や料金を数えるときにも使われる数え方の基本です。 LLM は語彙を単語・単語の一部・句読点などのトークンに分け、それぞれに番号を付けて扱う。 【C（不正解）】 ？ モデルを呼び出せる状態に置くことです。 デプロイはモデルの配置のことで、文章を区切る単位ではない。 【D（不正解）】 ？ 1 回に扱える量の上限のことです。 コンテキスト ウィンドウは扱える量の上限で、区切りの単位そのものではない。

出典: 大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: D 【A（不正解）】 ？ 質問と雑談で処理の道筋を分ける考え方です。 公式の解説は、質問だからといって別の Q&A 用の処理経路を通るわけではないと説明している。 【B（不正解）】 ？ 質問と答えの組を記憶して引く考え方です。 LLM は語どうしの関係を学ぶもので、あらゆる質問の答えを記録した表を持つわけではない。 【C（不正解）】 ？ 直前の 1 語にだけ注目する考え方です。 モデルはそれまでの文全体を見て、どの語が次の語に強く影響するかに重みを付けている。 【D（正解）】 ？ 続きの予測を繰り返す考え方です。 公式の解説どおり、質問の後には答えが続くのが最もありそうなので、答えのような文が生成される。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: B 【A（不正解）】 ？ 項目ごとに名前を繰り返す書き方です。 公式の解説は、フィールド名を毎回書くよりも表の形の方が場所を取らないことがあるとしている。 【B（正解）】 ？ 余分な文字を減らしてまとめる書き方です。 連続する空白はそれぞれ別のトークンになり得る。表の形はデータを少ない量で渡しやすい。 【C（不正解）】 ？ 記号で文を区切る書き方です。 句読点もトークンになるため、増やすと量が増える方向に働く。 【D（不正解）】 ？ 出力のばらつきを調整する設定です。 温度は出力のランダムさの設定で、入力の長さは変わらない。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: C 【A（不正解）】 ？ モデルの性能を測る指標です。 ベンチマークは性能の比較に使う数値で、語の意味を表すベクトルではない。 【B（不正解）】 ？ 出力のばらつきを調整する設定です。 温度は生成の設定で、語の意味を数値で表したものではない。 【C（正解）】 ？ RAG などの検索で、文書を探す材料として使われるデータです。 公式の解説どおり、文脈から意味を織り込んだベクトルを埋め込みと呼び、似た意味ほど近い向きになる。 【D（不正解）】 ？ 利用量の上限のことです。 クォータはサブスクリプションなどに割り当てた利用量の上限で、意味の表現とは関係ない。

出典: 大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: B 【A（不正解）】 ？ トークンが文の何番目にあるかを伝える情報です。 位置エンコーディングは並び順を伝える情報で、周りのトークンへの重み付けそのものではない。 【B（正解）】 ？ エンコーダーとデコーダーの両方で働く仕組みです。 公式の解説は、アテンション層が周りのトークンに重みを付け、埋め込みの値を計算すると説明している。 【C（不正解）】 ？ プロンプトに例をいくつか入れる方法です。 少数ショットはプロンプトの書き方で、モデル内部の重み付けの仕組みではない。 【D（不正解）】 ？ 自分のデータで追加学習させることです。 微調整はモデルを追加で学習させる作業で、トークン間の重み付けの仕組みの名前ではない。

出典: 大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: B 【A（不正解）】 ？ 見た目の長さを比べる方法です。 文字数が近くても意味が近いとは限らない。埋め込みの比較には使わない。 【B（正解）】 ？ ベクトルの向きの近さを測る方法です。 公式の解説どおり、埋め込みの意味の近さはベクトルのコサイン類似度で測れる。 【C（不正解）】 ？ 語に振られた通し番号を比べる方法です。 トークン ID は語に振った番号で、番号の近さは意味の近さを表さない。 【D（不正解）】 ？ 生成の設定値を比べる方法です。 温度は出力のばらつきの設定で、語の意味の近さとは関係ない。

出典: 大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: C 【A（不正解）】 ？ 出力のばらつきを決める設定です。 温度を変えても入力の長さは変わらないため、このエラーは解決しない。 【B（不正解）】 ？ 出力のランダムさを調整する設定です。 Top_p も出力の設定で、入力が長すぎる問題とは関係ない。 【C（正解）】 ？ 1 回に扱えるトークン量の上限です。 モデルが 1 回に扱える量には上限がある。文書を分ける、要らない部分を削るなどで収める。 【D（不正解）】 ？ 処理する場所と支払い方の区分です。 デプロイの種類は処理場所と課金の違いで、1 回の入力量の上限を広げるものではない。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: A 【A（正解）】 ？ GPT-5 や o シリーズなどが含まれる言語モデルの種類です。 公式の解説どおり、推論モデルは要求の理解と処理に時間をかけ、科学・コーディング・数学に強い。 【B（不正解）】 ？ 文章を意味のベクトルに変えるモデルです。 埋め込みモデルは検索や類似度の計算に使うもので、証明やコードの生成には向かない。 【C（不正解）】 ？ テキストの指示から画像を作るモデルです。 画像を作るモデルで、数学の証明やコードの生成には使わない。 【D（不正解）】 ？ テキストを自然な声にするものです。 文章を読み上げる機能で、複雑な問題を解く用途ではない。

出典: Azure OpenAI の推論モデル

正解: D 【A（不正解）】 ？ 複雑な問題を段階的に考えるモデルです。 推論モデルは考えて答える用途向けで、文書をベクトルに変える役割ではない。 【B（不正解）】 ？ テキストから画像を作るモデルです。 画像を作るモデルで、文書のベクトル化には使わない。 【C（不正解）】 ？ 話し言葉をテキストに変えるモデルです。 音声を文字にするモデルで、文書をベクトルにするものではない。 【D（正解）】 ？ モデル カタログで推論タスク「埋め込み」に分類されるモデルです。 埋め込みは意味の近さで検索するときに使う。モデル カタログでも推論タスク「埋め込み」で絞り込める。

出典: Microsoft Foundry Models の概要／大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）

正解: B 【A（不正解）】 ？ パラメーター数を抑えた言語モデルです。 画像を入力できないモデルでは、写真の内容について答えられない。 【B（正解）】 ？ 画像も入力として扱えるチャット モデルです。 ビジョン対応モデルは画像を分析して文章で答えるマルチモーダル モデルで、この用途に合う。 【C（不正解）】 ？ テキストの指示から画像を作るモデルです。 画像を作るモデルで、送られた写真の内容を読み取って答える用途ではない。 【D（不正解）】 ？ 意味の近さで検索するためのモデルです。 写真について会話で答えることはできない。検索の下準備に使うモデルである。

出典: ビジョン対応のチャット モデルを使う

正解: B 【A（不正解）】 ？ 大量のデータで学習した大きなモデルです。 幅広い用途に強いが、用途が絞られ軽さを求める場面では第一候補にしにくい。 【B（正解）】 ？ Meta の Llama の 1B・3B などが含まれる種類のモデルです。 公式は 1B・3B などの SLM を、デバイス上やエッジでの推論向けと説明している。店舗の端末での軽い利用に合う。 【C（不正解）】 ？ 答える前に長く考えるモデルです。 考える量を増やすほど時間とトークンが増える。軽さを求める用途とは逆の方向になる。 【D（不正解）】 ？ 画像を作るためのモデルです。 商品案内の文章のやり取りには使わない。

出典: 大規模言語モデル（LLM）（モジュール「生成 AI とエージェントの概要」）／Microsoft Foundry Models の概要／Azure で販売される Foundry Models（Meta のモデルの節）

正解: C 【A（不正解）】 ？ 1 つのモデルの説明やライセンスを見るページです。 モデル カードは 1 つのモデルの詳しいページで、多数のモデルを絞り込む一覧ではない。 【B（不正解）】 ？ 設定を変えながらモデルを試す画面です。 プレイグラウンドはモデルを試す画面で、モデルを探す一覧ではない。 【C（正解）】 ？ Foundry ポータルで多数のモデルが並ぶページです。 モデル カタログには提供元・地域・デプロイ方法・推論タスクなどのフィルターがある。 【D（不正解）】 ？ 利用量の上限のことです。 クォータは利用量の上限で、モデルを探す画面ではない。

出典: Microsoft Foundry Models の概要

正解: D 【A（不正解）】 ？ そのモデルの既存のデプロイを一覧するタブです。 既存のデプロイの一覧が見られる場所で、利用条件は載っていない。 【B（不正解）】 ？ 性能の測定結果を見るタブです。 性能の指標を見る場所で、利用条件は載っていない。 【C（不正解）】 ？ 説明・バージョン・対応データ形式を見るタブです。 モデルの説明や版の情報を見る場所で、利用条件はライセンスのタブにまとまっている。 【D（正解）】 ？ モデルのライセンスに関する法的な情報を見るタブです。 公式の説明どおり、ライセンスのタブにモデルの利用許諾に関する法的な情報がある。

出典: Microsoft Foundry Models の概要

正解: A 【A（正解）】 ？ カタログの「リーダーボードを表示」から開く機能です。 カタログの「リーダーボードを表示」と「モデルを比較」で、一部のモデルの指標を比べられる。 【B（不正解）】 ？ 有害な内容を検出して遮断する仕組みです。 安全対策の設定で、モデルどうしの性能を比べる機能ではない。 【C（不正解）】 ？ 組織のルールに合っているかを調べる画面です。 使えるデプロイの種類などを制限する仕組みで、性能の比較には使わない。 【D（不正解）】 ？ 利用量の上限を確認する画面です。 上限の確認や引き上げの申請に使う画面で、性能の比較はできない。

出典: Microsoft Foundry Models の概要

正解: C 【A（不正解）】 ？ 外部の提供元が提供しサポートするモデル群です。 サポートと保守は各提供元が受け持ち、SLA やサポートの形もまちまちである。 【B（不正解）】 ？ 外部のコミュニティが作り保守するモデルです。 公式の説明では、Hugging Face のモデルの問い合わせ先は Hugging Face のフォーラムやサポートである。 【C（正解）】 ？ Microsoft がホストして販売するモデル群です。 公式の説明どおり、Microsoft のサポートと企業向けの SLA が付き、Azure と深く統合されている。 【D（不正解）】 ？ 自社で学習させたモデルです。 自社のモデルには Microsoft のモデル サポートが付かない。条件に合わない。

出典: Microsoft Foundry Models の概要

正解: B 【A（不正解）】 ？ 大量の依頼をまとめて非同期で処理する種類です。 急がない大量処理向けで、ふだんのやり取りの出発点ではない。 【B（正解）】 ？ Azure 全体の拠点で処理し、トークン量で払う種類です。 公式は多くの用途でグローバル標準から始めるよう勧める。新モデルが最初に出て、価格が低く、地域も広い。 【C（不正解）】 ？ 微調整したモデルの評価だけに使う種類です。 微調整モデルの評価専用で、24 時間で自動的に消え、SLA も無い。 【D（不正解）】 ？ 決まった地理的範囲で処理能力を予約する種類です。 データの所在地と予約した処理量が必要なときの選択肢で、最初の一歩には向かない。

出典: Microsoft Foundry Models のデプロイの種類

正解: D 【A（不正解）】 ？ 世界中の Azure の拠点で処理する種類です。 処理はどの Azure リージョンでも行われ得るため、EU の中だけに限れない。 【B（不正解）】 ？ 大量の依頼を非同期でまとめて処理する種類です。 処理場所はグローバルで、EU の中に限る条件を満たさない。 【C（不正解）】 ？ 微調整したモデルの評価用の種類です。 評価専用で、データの所在地の保証が無い。 【D（正解）】 ？ 米国・EU・アジア太平洋の決まった範囲で処理する種類です。 データ ゾーンの種類は、Microsoft が定めたゾーン（EU など）の中だけで処理し、トークン量で課金される。

出典: Microsoft Foundry Models のデプロイの種類

正解: A 【A（正解）】 ？ 依頼を 1 つのファイルにまとめ、非同期で処理する種類です。 グローバル標準より 50% 安く、24 時間以内の完了を目標とする。急がない大量処理に合う。 【B（不正解）】 ？ 1 件ずつ依頼してすぐ応答を受け取る種類です。 すぐ応答が返る代わりに、まとめて安く処理する割引は無い。 【C（不正解）】 ？ 処理能力を予約して確保する種類です。 安定した処理量を確保する方式で、急がない一度きりの大量処理を安くする目的には合わない。 【D（不正解）】 ？ 微調整したモデルの評価用の種類です。 評価専用で 24 時間で消える。本番の大量生成には使わない。

出典: Microsoft Foundry Models のデプロイの種類

正解: C 【A（不正解）】 ？ 使ったトークン量で払う、ベスト エフォートの種類です。 大量で一定の利用では、応答時間のばらつきが大きくなることがあると公式は説明している。 【B（不正解）】 ？ 依頼をまとめて非同期で処理する種類です。 結果は 24 時間以内を目標に返るもので、すぐの応答には向かない。 【C（正解）】 ？ 処理能力を PTU 単位で予約する種類です。 処理能力が確保されるため、応答時間のばらつきが小さく、量を予測しやすい。 【D（不正解）】 ？ 微調整したモデルの評価用の種類です。 SLA が無く、遅延に敏感な用途向けではない。

出典: Microsoft Foundry Models のデプロイの種類

正解: B 【A（不正解）】 ？ Microsoft が管理する基盤のモデルを API で使う方法です。 使ったトークン量などで払う方法で、Hugging Face の公開モデルを専用の計算資源に置く方法ではない。 【B（正解）】 ？ 新しい Foundry ではプレビューとして提供されている方法です。 Hugging Face などのオープン モデルはマネージド コンピューティングで動かす。使った計算資源の時間に応じて課金される。 【C（不正解）】 ？ サーバーレス API のデプロイの種類の 1 つです。 サーバーレス API の中の種類で、専用の計算資源に置く方法ではない。 【D（不正解）】 ？ 大量の依頼をまとめて処理する種類です。 サーバーレス API の種類で、オープン モデルを専用の資源で動かす方法ではない。

出典: Microsoft Foundry Models の概要／Microsoft Foundry Models のデプロイの概要

正解: C 【A（不正解）】 ？ 応答の長さを抑える設定です。 応答の長さの上限は最大トークン数で決める。温度の役割ではない。 【B（不正解）】 ？ 利用量の上限のことです。 処理量の上限はクォータで、温度とは別のものである。 【C（正解）】 ？ 出力のばらつきを決める設定です。 公式の説明どおり、温度を高くすると応答はランダムで多様になり、低くすると焦点の定まった応答になる。 【D（不正解）】 ？ データを処理する場所の設定です。 処理場所はデプロイの種類で決まる。温度とは関係ない。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: A 【A（正解）】 ？ 出力のばらつきを小さくする方向の設定です。 公式は、法律文書のような生成には低い温度を勧めている。 【B（不正解）】 ？ 出力を多様にする方向の設定です。 高い温度は物語のような創作向けで、ぶれを抑えたい文書には向かない。 【C（不正解）】 ？ 応答の長さの上限を広げる設定です。 長さの上限を変えても、表現のばらつきは小さくならない。 【D（不正解）】 ？ 2 つの設定でランダムさを強める方法です。 どちらもランダムさを強める方向で、しかも公式は 2 つを同時に変えないよう勧めている。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: D 【A（不正解）】 ？ 2 つの設定を連動させる方法です。 公式は 2 つをそろえるよう勧めてはいない。一度に 1 つだけ変えるのが一般的な推奨である。 【B（不正解）】 ？ Top_p の役割を長さの制限とみる考え方です。 Top_p は温度と同じくランダムさを調整するもので、応答の長さを決めるものではない。 【C（不正解）】 ？ 2 つを必ず同時に下げる考え方です。 公式にそのような決まりはない。2 つを同時には変えないのが一般的な推奨である。 【D（正解）】 ？ 1 回に 1 つの設定だけを動かす方法です。 どちらもランダムさを調整するため、公式は 2 つのうち一方だけを変えるよう勧めている。

出典: プロンプト エンジニアリングの手法（Microsoft Foundry）

正解: A 【A（正解）】 ？ 考える途中のトークンの扱いに着目した対処です。 公式の説明どおり、推論トークンは出力トークンとして課金される。max_output_tokens などで総量の上限を決められる。 【B（不正解）】 ？ 考える途中のトークンを費用の外とみる考え方です。 推論トークンは出力トークンとして課金されるため、入力だけを見ても原因はつかめない。 【C（不正解）】 ？ 出力のばらつきの設定で費用を抑える考え方です。 考える量は reasoning_effort などで調整する。温度を下げても推論は止まらない。 【D（不正解）】 ？ 処理の方式を変える考え方です。 バッチは処理を非同期にまとめて安くする方式で、推論の処理そのものを省くものではない。

出典: Azure OpenAI の推論モデル