- 第2〜11章で見た10問それぞれが「何を測っているか」と、良い回答・弱い回答のサインを1枚の表で振り返れること
- 10章を通じて繰り返し現れる、良い回答に共通するパターン（仕組みの理解・具体的な数値や設定名・トレードオフの両面・実務で起きた問題の経験）
- 本書に出てきた専門用語を、英語名・日本語の言い換え・定義のセットで一覧できること
- マネージドAPI（= AnthropicやOpenAIのように提供側がサーバーを運用し、利用者はAPIを呼ぶだけの利用形態）だけを使ってきた候補者には、実体験で答えにくい質問があるという前提を踏まえた使い方
10問の早見表 — 良い回答と弱い回答のサイン
元の投稿が並べた10の質問は、ばらばらの雑学ではない。本書の並びで読むと、1回のLLM呼び出しが処理される流れ——入力の設計から、推論の速さ、そして本番での信頼性と運用まで——を順にたどる形になる（第1章参照）。図12-1は、1回の呼び出しがどの段階を経て、10問のどれに対応するかを示す。
下表は、第2〜11章の「回答を見極めるポイント」を1問1行に集約したものだ。「測っているもの」は各章の「この質問は何を聞いているのか」の要約、「良い回答の要素」「弱い回答のサイン」は各章の該当コールアウトを凝縮している。詳しい根拠や公式ドキュメントの数値は、各章本文を参照してほしい。表中の略語（TTFT・ITL・strict・golden set・fail-closed等）の定義は本章末の用語集にまとめている。
| 質問 | 測っているもの | 良い回答の要素 | 弱い回答のサイン |
|---|---|---|---|
| Q1 コンテキストの扱い方（第2章） | プロンプトの言い回しでなく、渡すトークン集合全体を毎ターン選び直す設計をしているか |
|
|
| Q2 キャッシングの使い分け（第3章） | 「計算の再利用」と「応答の再利用」を区別し、損益分岐と誤ヒットのリスクを実測しているか |
|
|
| Q3 推論レイテンシの改善（第5章） | 「遅い」をprefill（読み込み）とdecode（書き出し）のどちらが原因かに切り分けて対策できるか |
|
|
| Q4 量子化の導入判断（第6章） | 重みと活性値（= 各トークンの計算途中の中間出力）を区別して数値表現を粗くした経験と、劣化を定量的に測る規律があるか |
|
|
| Q5 コンテキストウィンドウの調整（第4章） | 上限に近づいたとき何を残し何を捨てるかを、API仕様の理解とともに設計しているか |
|
|
| Q6 ツール呼び出しの信頼性（第8章） | モデルは実行しないという前提で、検証・エラー処理・再試行の3層を設計しているか |
|
|
| Q7 LLMの監視・運用（第9章） | トレース・トークン・レイテンシ・エラー・ドリフトを、しきい値とアラートを組んで継続的に見ているか |
|
|
| Q8 モデル選定の判断基準（第10章） | レイテンシ・品質・コストをタスク完了あたりで実測し比較した経験があるか |
|
|
| Q9 バッチ処理とスループット（第7章） | Continuous Batchingの仕組みと、同時実行数を実際に調整して起きた副作用を語れるか |
|
|
| Q10 プロンプトインジェクション防御（第11章） | 命令とデータを区別できない構造的前提を理解し、多層防御と許可境界を設計しているか |
|
|
10問に共通するテーマ
第2〜11章の「良い回答に含まれる要素」を並べて読むと、質問ごとに扱う技術は違っても、評価の軸は驚くほど共通している。整理すると次の5点に集約できる。
①実行主体を取り違えない——「モデルは実行しない」（Q6）、「decodeが遅いのはメモリ帯域」（Q3）のように、本当のボトルネックや責任者を正しく言えるか。②単一の指標や単語で片付けない——「レイテンシ」でなくTTFTとITL、「キャッシュ」でなくプロンプトキャッシュとセマンティックキャッシュのように、用語を要素に分解できるか。③具体的な数値・設定名を挙げる——公式ドキュメントのパラメータ名や既定値を、言い換えでなく実際に指せるか。④トレードオフを両面で語る——「緩めると誤ヒットが増える」のように、利点だけでなく副作用まで語れるか。⑤実務で起きた問題や測定手段に触れる——退避・誤ヒット・平均では見えない劣化など、実際に測って初めて気づく失敗を語れるか。
この5点は、図12-2のように「用語を知っている」から「実務の失敗経験を語る」までの1本の深さの軸として並べ直せる。早見表の「弱い回答のサイン」は、この軸のどこかで止まっていることを示すサインであり、「良い回答の要素」はこの軸を先まで進んでいることを示している。
もう1つの見方が、仕組みの理解度と実務経験の具体性を別の2軸として置く整理だ（図12-3）。仕組みは説明できるが数値や失敗経験が出てこない候補者と、現場は知っているが仕組みを説明できない候補者は、どちらも早見表の「良い回答」には届かない。両方が揃って初めて右上の領域に入る。
ただし、10問すべてに同じ深さで答えられる候補者は稀だ。マネージドAPIだけを使ってきた開発者と、自前でモデルをホスティングしてきた開発者では、経験できる領域そのものが違う。第6章は、公式のAPIリファレンスに利用者が量子化を指定するパラメータは載っておらず（2026-08時点、本書の確認範囲）、量子化の指定はすべて推論サーバー起動側のフラグ（例: vLLMの--quantization）として実装されていることを、第7章は、同時実行数などの推論サーバー側の設定項目がホスト型APIでは利用者に公開されていないことを示している。図12-4は、この境界がAPIのどこにあるかを示したものだ。
したがって、Q4やQ9への回答が薄いことは、それ単独では弱い回答のサインにならない。候補者が普段どちらの層（マネージドAPIか自前ホスティングか）で仕事をしているかを先に確認し、その層で聞くべき質問に絞ることが、早見表を正しく使う前提になる。
用語集
本書全体で使った専門用語を、英語名・日本語の言い換え・定義のセットで一覧する。並び順はアルファベット順ではなく、主に登場した章の順（第1〜11章）にしている。
| 用語 | 日本語 | 定義 | 主に出てくる章 |
|---|---|---|---|
| token | トークン | モデルが文章を扱う最小単位。料金はこの単位で決まり、レート制限もリクエスト数と併せてこの単位で数えられる。 | 第1章 |
| context window | コンテキストウィンドウ | モデルが1回の応答生成で参照できる、入出力すべての合計の上限。 | 第1・2・4章 |
| prefill | 読み込み段階 | プロンプト全体を読み込み最初の1トークンを作るまでの処理。計算量が律速する状態（compute-bound）にあたる。 | 第1・3・5・6・7・9章 |
| decode | 書き出し段階 | 出力トークンを1つずつ生成し続ける処理。メモリからの読み出し速度が律速する状態（memory-bound）にあたる。 | 第1・3・5・6・7・9章 |
| KV cache | KVキャッシュ | 各トークンの注意計算の中間結果を保存し使い回す仕組み。 | 第1・3・5・6・7章 |
| TTFT | 最初の1文字が出るまでの時間 | 送信から最初のトークンが出るまでの時間（待ち行列+prefill+通信）。 | 第1・5・9章 |
| quantization | 量子化 | 重みや活性値（= 各トークンの計算途中の中間出力）の数値表現を粗くしメモリと計算コストを下げる技術。 | 第1・6章 |
| tool calling | ツール呼び出し | モデルが外部機能の呼び出しを要求し、実行はアプリ側が担う仕組み。 | 第1・8章 |
| context rot | コンテキスト腐敗 | トークン数が増えるほど想起精度が下がる現象。 | 第2章 |
| prompt caching | プロンプトキャッシング | プロンプト先頭の前方一致部分の計算結果を再利用する仕組み。 | 第2・3・4・5・9・10章 |
| compaction | 圧縮 | 古い会話履歴を要約し、その要約から続行する仕組み。 | 第2・4章 |
| semantic cache | セマンティックキャッシング | 意味が近い過去の質問の応答をそのまま再利用しLLM呼び出しを省く仕組み。 | 第3章 |
| ITL / TPOT | トークン間隔 | 出力トークン同士の生成間隔。decodeの速さを表す。 | 第5・7・9章 |
| perplexity（PPL） | パープレキシティ | 次のトークンを当てる際の実質的な選択肢数を表す指標（低いほど良い）。 | 第6章 |
| Continuous Batching | 継続的バッチ処理 | 1イテレーション（= モデルの全層を1回通す処理。出力トークン1個に相当）ごとにバッチの中身を入れ替える方式。 | 第7章 |
| PagedAttention | ページドアテンション | KVキャッシュをブロック単位で管理しメモリの無駄を削る仕組み。 | 第7章 |
| preemption | 退避 | KVキャッシュ枯渇時に走行中の要求（既定では最後に来た要求）を待機列へ戻し、空きが出たら再計算して再開する仕組み。 | 第7章 |
| strict mode | 厳密モード | 出力トークンを文法で制約し、型・必須項目・enum（= 選べる値の固定リスト）を、スキーマ（= 引数の型と必須項目を定めた仕様）に一致させる機能。 | 第8章 |
| idempotency | べき等性 | 同じ引数で何度呼んでも影響が増えない性質。安全な再試行の前提。 | 第8章 |
| fail-closed | 不明時は拒否側に倒す設計 | 判断できない時に実行を許可せず拒否側に倒す設計。 | 第8・11章 |
| trace / span / session | トレース・スパン・セッション | 1件のリクエストの一部始終（トレース）と、その中の1ステップ（スパン）。複数ターンの会話をまとめる単位がセッション（LangSmithではスレッド）。 | 第9章 |
| drift | ドリフト | 本番の中身が過去の基準からずれる現象（入力分布の変化とモデル側の変化の2種）。 | 第9章 |
| LLM-as-a-Judge | 判定器としてのLLM | 別のLLMを判定器として使い出力の質をスコア化する評価手法。 | 第9・10章 |
| golden set | 評価用データセット | 正解付きの評価用データセット。本番ログの比率で作るのが推奨。 | 第10章 |
| effort | 思考の深さ | モデルを替えずに思考量やトークン消費を段階的に変える設定。 | 第10章 |
| prompt injection | プロンプトインジェクション | 入力がLLMの挙動を開発者の意図しない形で変えてしまう現象。 | 第11章 |
| permission boundary | 許可境界 | モデルやツールにどこまでの権限を与えるかという線引き。 | 第11章 |
つまずきポイント
早見表の「良い回答の要素」に書かれた語句が出てきたかどうかだけをチェックしてしまう。用語を言えることと仕組みを説明できることは別で、第2〜11章の「弱い回答のサイン」はどの章でも「用語を言い換えるだけ」「仕組みの理由を説明できない」という形で繰り返し現れる（図12-2）。
Q4（量子化）とQ9（バッチ処理）は、マネージドAPIだけを使ってきた候補者が実体験で答えられない構造になっている。量子化の指定やバッチの同時実行数は推論サーバーを起動する側の設定であり、公式のAPIリファレンスに利用者が操作できる形では載っていない（2026-08時点、本書の確認範囲、第6・7章、図12-4）。回答が薄いことは、それだけでは実力不足を意味しない。
「弱い回答のサイン」が1つ出た時点で不合格と判断してしまう。早見表は各章末の「深掘り質問の例」とセットで使う前提で作られている。弱いサインが出た箇所こそ、深掘り質問で仕組みへの理解を確かめ直す機会になる。
理解度チェック
Q1. Q4（量子化）とQ9（バッチ処理）に、マネージドAPIだけを使ってきた候補者が実体験で答えにくいのはなぜですか?
量子化の指定や同時実行数といった調整項目は、推論サーバーを起動する側の設定であり、公式のAPIリファレンスに利用者が操作できる形では載っていないため（2026-08時点、本書の確認範囲）。
Q2. 早見表の「弱い回答のサイン」が1つ出ただけで、その候補者を不合格と判断すべきですか?
いいえ。早見表は各章末の深掘り質問とセットで使う前提で作られている。弱いサインが出た箇所は、深掘り質問で仕組みへの理解を確かめ直す機会として使う。
Q3. prefillとdecodeの区別が答えの前提になる質問は、10問のうちどれとどれですか?
Q3（推論レイテンシの改善）は質問文がprefillとdecodeを名指しして切り分けを直接問う。Q9（バッチ処理とスループット）は質問文には現れないが、Continuous Batchingで両者が同じバッチに混在できる理由（selective batching・chunked prefill）を説明するには区別が必要になる。
Q4. 「命令とデータを区別できない」という構造的な前提が根本原因になっている質問はどれですか?
Q10（プロンプトインジェクション防御）。LLMが開発者の指示・利用者の入力・外部データを1本のトークン列として受け取り、区別する仕組みを持たないことが原因である。
まとめ
- 10の質問は雑学の集合ではなく、1回のLLM呼び出しが処理される流れ（入力設計→推論の速さ→信頼性と運用）を順にたどっている
- 良い回答には、仕組みの理解・具体的な数値や設定名・トレードオフの両面・実務で起きた問題の経験という共通パターンがある
- マネージドAPIだけの経験では、量子化（Q4）やバッチ処理の調整（Q9）に実体験で答えられないことがあり、それ自体は実力不足のサインではない
- 早見表と用語集は、質問文を読んだ瞬間に「何を聞かれているか」を思い出すための道具であり、深掘り質問とセットで使うことで初めて機能する
全12章を通じて、「AI開発してます」という一言の裏にある具体的な仕組みを見てきた。面接の場ではこの早見表を手元に、候補者の答えがどの深さにあるかを一緒に確かめてほしい。
参考リンク
- @voidwarriorchan の投稿（10の質問の出典）
- Anthropic Engineering: Effective context engineering for AI agents
- Anthropic — Prompt caching
- Anthropic — Context windows
- vLLM — Quantization
- Yu et al. — Orca（USENIX OSDI '22）
- Anthropic — How tool use works
- Langfuse — Observability data model
- Anthropic — Choosing a model
- OWASP — LLM01:2025 Prompt Injection