Developer Foundations ドメイン5: モデル選択と最適化（16.8%）
この章で学ぶこと: LLM の基本（トークン、コンテキストウィンドウ、サンプリング、非決定性、次のトークンの生成、fast mode、thinking、effort、zero/single/multi-shot）、技術の基礎、モデルの選び方と移行時の変化、コストとトークンの管理。
| スキル | 配点 | この章の節 |
|---|---|---|
| LLM の基礎（LLM Fundamentals） | 5.2% | 第1節 |
| 技術の基礎（Technical Fundamentals） | 6.1% | 第2節 |
| モデル選択とトレードオフ（Model Selection and Tradeoffs） | 2.7% | 第3節 |
| コストとトークンの管理（Cost and Token Management） | 2.8% | 第4節 |
本番の53問のうち約9問が出ます。
前の章とつながる部分:
- thinking（適応型と手動）、プロンプトキャッシュ、バッチ API → ドメイン2 第3節
- effort の5段階、Agent SDK の
max_budget_usd→ ドメイン1 第2.3節 - コンテキストの管理（圧縮、サブエージェント） → ドメイン1 第3.4節
- モデル ID の固定 → ドメイン2 第6.3節
注意: この章はモデル名・価格・既定値など変わりやすい数字が多い章です。すべて2026年11月時点の公式ドキュメントの値です。試験は2026年7月版のガイドにもとづくので、ガイドに出てくる名前（Opus、Sonnet、Haiku）と考え方を中心におぼえ、細かい数字は本番前に公式ドキュメントで確かめてください。
1. LLM の基礎（5.2%）
1.1 次のトークンの生成
Claude のような LLM は「自己回帰型」の言語モデルです。事前学習では、それまでの文章をもとに次の単語を予測するように学習します。事前学習しただけのモデルは、質問に答えたり指示に従ったりするのが得意ではないため、ファインチューニングや RLHF（人のフィードバックによる強化学習）で使いやすくしています。
応答は、トークンを1つずつ予測して足していくことで作られます。だから:
- 出力が長いほど時間がかかる（出力トークンの数が応答時間に効く）
- 途中で
max_tokensに達すると、そこで止まる（ドメイン4）
1.2 トークン
| ポイント | 内容 |
|---|---|
| トークンとは | モデルが扱う最小の単位。単語、単語の一部、文字、バイトのこともある |
| 1トークンの長さ | モデルと言語によって違う。古いモデルでは英語で約3.5文字 |
| 新しいトークナイザー | Claude 4.7 以降のモデルは新しいトークナイザーを使い、同じ文章でも約30%多くトークンになる |
| 正確に知るには | トークン数を数える API を使う（第4.3節） |
移行での注意: 古いモデルで測ったトークン数を、新しいトークナイザーのモデルの費用見積もりやコンテキストの収まり具合に使い回してはいけません。使うモデルの ID で数え直します。
1.3 コンテキストウィンドウ
- コンテキストウィンドウは、応答を作るときにモデルが参照できる文章のすべてで、応答そのものも含む。学習に使った大量のデータとは別の「作業用の記憶」
- 会話が進むと、ユーザーのメッセージとアシスタントの応答がたまっていく（ドメイン1 第3.4節）
- 今の主なモデルは 100万（1M）トークン。1M トークンは今のトークナイザーで英語の約55.5万語
- 大きければよいわけではない。トークンが増えると正確さや思い出す力が落ちる（context rot）。何を入れるかを選ぶことが、空きの大きさと同じくらい大事
- 一部のモデルには「context awareness」があり、会話の中で残りのコンテキスト（トークン予算）を把握しながら作業する
1.4 サンプリング、temperature、非決定性
| 用語 | 意味 |
|---|---|
| サンプリング | 次のトークンを、確率の高い候補の中から選ぶこと |
| temperature | ランダムさを調整するパラメータ。高いと多様で創造的、低いと保守的で決まった答えに近づく |
| 非決定性 | 同じ入力でも、呼ぶたびに出力が変わりうること |
大事な事実:
- temperature を 0 にしても、結果は完全には決定的になりません。同じ入力でも API 呼び出しごとに違う出力になりえます（Anthropic の API でも、クラウド事業者経由でも）
- 最新のモデルでは、
temperature、top_p、top_kを送ると 400 エラーになります（例: Claude Sonnet 5.5、Claude Haiku 5.5 の移行ガイド）。代わりにプロンプトで振る舞いを導きます
非決定性への対応:
- 1回の結果で判断せず、評価用データで何回か測る（ドメイン2 第1.2節）
- 形をそろえたいなら構造化出力（ドメイン2 第3.6節）
- 同じプロンプトを複数回実行して比べると、ハルシネーションに気づける（ドメイン4 第4.3節）
1.5 fast mode
| ポイント | 内容 |
|---|---|
| 何か | 同じモデルを、より速い推論の設定で動かす。賢さや能力は変わらない |
| 速さ | 出力トークン毎秒（OTPS）が標準の最大2.5倍。最初のトークンまでの時間（TTFT）が速くなるわけではない |
| 指定 | リクエストに speed: "fast" |
| 確認 | 応答の usage.speed が "fast" か "standard" |
| 対応モデル | 2026年11月時点で Claude Opus 5.5（Opus 5、Opus 4.8 は研究プレビュー）。対応しないモデルで指定するとエラー |
| 料金 | 割増し。例: Opus 5.5 は通常 $4 / $20（入力 / 出力、100万トークンあたり）が fast mode では $8 / $40 |
| レート制限 | 通常とは別の、fast mode 専用の制限。超えると 429 |
| 使えないもの | バッチ API |
| ストリーミング | 一緒に使える。速さの効果がいちばん見えやすい |
1.6 thinking と effort
thinking の2つの方式（適応型・手動）はドメイン2 第3.5節、effort の5段階はドメイン1 第2.3節を見てください。ここでは選び方の要点です。
- effort は、1つのモデルの中で「賢さ」と「速さ・コスト」を交換するつまみ。公式ドキュメントは、モデルを変えるより effort を調整するほうがよいことが多いとしている
- effort は応答のすべてのトークン（文章、ツール呼び出し、thinking）に効く
- 多くのモデルの初期値は
high。Claude Opus 5.5 と Claude Haiku 5.5 はmedium。初期値と同じ値を指定するのは、省略するのとまったく同じ - 公式のベストプラクティス:
1. effort ははっきり指定する
2. 速さが大事な仕事や簡単な仕事は
low3. 自分の用途で試してから本番に出す 4. 仕事の難しさに合わせて変える 5. キャッシュに頼る会話の途中で、最上位の effort を変えない（キャッシュが無効になる）
1.7 zero-shot、single-shot、multi-shot
| 方法 | 意味 | 向いている場面 |
|---|---|---|
| zero-shot | 例を見せず、指示だけで頼む | 簡単でよくある作業 |
| single-shot（one-shot） | 例を1つ見せる | 形式を1つ示せば足りるとき |
| multi-shot（few-shot） | 例をいくつか見せる | 形式、口調、構造をそろえたいとき |
公式のプロンプトのベストプラクティスより:
- 例は、出力の形式・口調・構造を導くいちばん確実な方法の1つ。少数の良い例で正確さと一貫性が上がる
- 例は「関係がある（実際の用途に近い）」「多様（例外ケースも入れ、意図しないパターンを覚えさせない）」「構造化（
<example>タグ、複数なら<examples>タグで囲み、指示と区別する）」ようにする - 3〜5個の例がよい結果につながる。例の良し悪しを Claude に評価させたり、追加の例を作らせたりもできる
2. 技術の基礎（6.1%）
試験ガイドの説明は「AI アプリ開発を支える基礎技術。REST API を包む SDK との統合、WebSocket などの基本的なエンジニアリング実践」です。
2.1 REST API と SDK
- Claude API は
https://api.anthropic.comの REST API（ドメイン2 第3.1節） - 公式 SDK は REST API を包み、認証やバージョンのヘッダー、再試行、エラー処理、型、ストリーミングの補助を引き受ける。Python、TypeScript、C#、Go、Java、PHP、Ruby の7言語（ドメイン2 第4.1節）
- API は会話の状態を持たない。毎回、必要な会話をすべて送る
2.2 ストリーミングの接続のしかた
| SSE（server-sent events） | WebSocket | |
|---|---|---|
| 向き | サーバーからクライアントへの一方向 | 双方向 |
| 接続 | HTTP の応答をつないだまま、少しずつ送る | 専用の接続を張り、両方から送れる |
| Claude API | Messages API のストリーミングはこれ（ドメイン2 第3.3節） | 公式ドキュメントで WebSocket の API は見つからなかった |
WebSocket の説明は一般的な知識で、Claude 固有の公式資料からの要約ではありません。自分のアプリで「ブラウザ ↔ 自分のサーバー」を WebSocket でつなぎ、「自分のサーバー ↔ Claude API」を SSE で受ける、という組み合わせもよくあります。
2.3 速さの指標
| 指標 | 意味 | 効くもの |
|---|---|---|
| レイテンシ | プロンプトを送ってから出力を受け取るまでの時間 | モデルの大きさ、プロンプトと応答の長さ、ネットワーク |
| TTFT（time to first token） | 最初のトークンが出るまでの時間。チャットなど対話型で大事 | ストリーミングで体感が良くなる。プロンプトキャッシュでも短くなる |
| OTPS（出力トークン毎秒） | 出力の速さ | fast mode で最大2.5倍 |
3. モデル選択とトレードオフ（2.7%）
3.1 今のモデル（2026年11月時点）
| Claude Fable 5.1 | Claude Opus 5.5 | Claude Sonnet 5.5 | Claude Haiku 5.5 | |
|---|---|---|---|---|
| 速さ（相対） | 遅め | 中くらい | 速い | いちばん速い |
| 料金（入力 / 出力、100万トークンあたり） | $10 / $50 | $4 / $20 | $2 / $10 | $0.10〜 / $0.50〜 |
| thinking | 適応型（常にオン） | 適応型（常にオン） | 適応型 | 適応型 |
| effort の初期値 | high |
medium |
high |
medium |
| コンテキストウィンドウ | 1M | 1M | 1M | 1M |
| 最大出力 | 128K | 128K | 128K | 128K |
- 試験ガイドは Opus、Sonnet、Haiku の3つを挙げています。Fable は Opus よりさらに上の段のモデルとして、ガイドの後に加わったものです
- 公式のコスト最適化の目安: 簡単な仕事は Haiku、本番のほとんどの仕事は Sonnet、いちばん複雑な推論は Opus
- Haiku 5.5 だけは、プロンプトが10万トークンを超えると高い料金になります。ほかの 4.6 以降のモデルは、1M トークンまで同じ単価です
3.2 選ぶときに考えること
公式ドキュメントが挙げる観点: 必要な能力、速さ、コスト、effort。
始め方は2つあります。
| 始め方 | 手順 | 向いている場面 |
|---|---|---|
| 効率から始める | Haiku で作る → よくテストする → 要件を満たすか評価する → 足りない能力があるときだけ上げる | 試作、応答時間が厳しい、コストに敏感、大量で単純な仕事 |
| 能力から始める | Opus で作る → プロンプトを最適化する → 評価する → effort を下げたり小さいモデルに変えたりして効率化する。xhigh や max でも足りなければ Fable |
複雑な推論、科学や数学 |
トレードオフの考え方:
| 上げたいもの | 代わりに増えやすいもの | 打ち手 |
|---|---|---|
| 品質 | コスト、レイテンシ | 上位のモデル、高い effort |
| 速さ | 料金（fast mode）、品質（小さいモデル、低い effort） | fast mode、Haiku、low effort、ストリーミング |
| 安さ | 待ち時間（バッチ）、品質 | バッチ API（50%）、キャッシュ、小さいモデル |
3.3 リリースをまたぐ挙動の破壊的な変化
新しいモデルでは、前のモデルで動いていたリクエストがエラーになることがあります。Claude Sonnet 5.5 の移行ガイドの例:
| 変化 | 前のモデル | Sonnet 5.5 など新しいモデル | 対応 |
|---|---|---|---|
| サンプリングのパラメータ | 使えた | temperature、top_p、top_k は 400 エラー |
外して、プロンプトで導く |
| アシスタントのプリフィル | 使えた | 400 エラー | 構造化出力やシステムプロンプトで |
thinking の予算（budget_tokens） |
使えた | 400 エラー | effort にする |
thinking: {"type": "disabled"} |
使えた | 400 エラー | 最も低い thinking の設定を使う |
ツールの強制（tool_choice の type "any" と "tool"） |
使えた | どちらも 400 エラー（Claude Opus 5.5、Sonnet 5.5、Fable 5.1 など） | tool_choice: {"type": "auto"} にし、ツールに strict: true を付け、いつツールを使うかをプロンプトに書く。"none" は使える |
| thinking | 指定したときだけ | thinking を書かなくても考える |
max_tokens を見直す |
| トークナイザー | 旧 | 同じ文章で約30%多い | トークン数とコストを数え直す |
| 画像 | 標準の解像度 | 高解像度（大きい画像はトークンが増える） | 画像のトークンも見直す |
移行の基本: モデル ID を変えたら、エラーになる設定を外し、effort の試し直しと評価をやり直し、コストの基準を取り直します（ドメイン2 第2節のライフサイクル）。
注意: Architect Foundations の試験ガイドには tool_choice の "any" や特定ツールの強制が出てきます。古いモデルの多くで使えます。概念として理解したうえで、Opus 5.5・Sonnet 5.5・Fable 5.1 のような新しいモデルや、手動の extended thinking を使うときは 400 エラーになることを知っておきます（Define tools の「Forcing tool use」）。
4. コストとトークンの管理（2.8%）
4.1 トークンの予算
| 予算のしかた | 方法 |
|---|---|
| 1回の出力の上限 | max_tokens |
| エージェント全体の費用の上限 | Agent SDK の max_budget_usd（ドメイン1 第2.3節） |
| 推論の量 | effort を下げる |
| 入力の量 | 必要な情報だけ入れる、ツール出力を削る、サブエージェントに任せる |
| 送る前に数える | トークン数を数える API（第4.3節） |
4.2 使用量を追う
| 方法 | わかること |
|---|---|
応答の usage |
そのリクエストの input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens など |
Agent SDK の ResultMessage |
total_cost_usd、usage（ドメイン1） |
| Claude Console の Usage / Cost ページ | 組織の使用量と費用 |
| Usage and Cost API | 組織の過去の使用量と費用をプログラムで取る。Admin API キーが必要。経理との照合、監視、アラートに使う |
4.3 トークン数を数える API
- Messages API と同じ形の入力（システムプロンプト、ツール、画像、PDF）を受け取り、入力トークンの合計を返す（
messages/count_tokens） - 使い道: レート制限とコストの管理、モデルの振り分けの判断、プロンプトを決まった長さに収める
- 返す値は見積もりで、実際とわずかに違うことがある
- サーバーツール（Web 検索など）を含む入力はエラーになる
- 使う予定のモデル ID で数える（トークナイザーがモデルで違うため）
4.4 コストを見積もる
計算の基本:
1回の費用 = 入力トークン数 × 入力単価 + 出力トークン数 × 出力単価
（キャッシュの読み込み・書き込みは、それぞれの倍率をかける）
例（Sonnet 5.5、入力 $2 / 出力 $10、100万トークンあたり。2026年11月時点）:
1日1万件。1件あたり入力 3,000 トークン（うち 2,500 は毎回同じシステムプロンプト）、出力 500 トークン。
| 入力 | 出力 | 1日の合計 | |
|---|---|---|---|
| キャッシュなし | 3,000万トークン × $2 = $60 | 500万トークン × $10 = $50 | $110 |
| キャッシュあり | キャッシュ読み込み 2,500万 × $2 × 5%（Sonnet 5.5 の読み込みは基本価格の5%）= $2.50、残り 500万 × $2 = $10 | $50 | 約 $62.50 + キャッシュ書き込み分 |
わかること: 出力は入力より単価が高いので、出力を短くすることも効きます。この例では、キャッシュで入力の費用が大きく減ります。
4.5 コストを下げる手段
| 手段 | 効果 | 詳しくは |
|---|---|---|
| 合ったモデルを選ぶ | 簡単な仕事に高いモデルを使わない | 第3節 |
| effort を下げる | 1回あたりのトークンが減る | 第1.6節 |
| プロンプトキャッシュ | 読み込みは基本価格の10%（Opus 5.5 と Sonnet 5.5 は5%、Fable 5.1 は2.5%）。書き込みは 1.25倍（5分）または 2倍（1時間） | ドメイン2 第3.7節 |
| バッチ API | 50% | ドメイン2 第3.8節 |
| 使用量を見張る | 無駄を見つける | 第4.2節 |
ほかの料金の調整（ほかの割引や割増しと重ねてかかる）:
- データの処理場所を米国に限る（
inference_geo: "us"）と 1.1倍 - fast mode は割増し（第1.5節）
4.6 キャッシュのチェックポイント
試験ガイドの「cache check-pointing」が何を指すかは、詳しい説明がありません。ここでは、キャッシュする範囲の終わりの目印「キャッシュのブレークポイント（cache_control）」と解釈してまとめます（解釈であることに注意）。
- ブレークポイントは最大4つ置ける
- 書き込みはブレークポイントの位置だけで起きる
- 読み込みは、ブレークポイントから最大20ブロック前までさかのぼって、前に書かれたキャッシュを探す
- 自動キャッシュなら、リクエストの最上位に
cache_controlを1つ置くだけで、会話が伸びるにつれて位置が自動で進む - 変わらない内容（ツール → システム → 会話の前半）を前に置き、変わる内容を後ろに置く
5. 試験に向けたまとめ
| 問われ方 | 考え方 |
|---|---|
| temperature 0 なら毎回同じか | 同じとは限らない。評価は何回か測る |
| 新モデルで temperature が 400 エラー | temperature、top_p、top_k を外し、プロンプトで導く |
| もっと速く出力したい（品質はそのまま） | fast mode（OTPS 最大2.5倍、割増し、バッチ不可）。TTFT は変わらない |
| 品質とコストの調整 | まず effort。それでも足りなければモデルを変える |
| 形式をそろえたい | 3〜5個の、関係があり多様な例を <example> タグで |
| どのモデルから始めるか | 効率から（Haiku から上げる）か、能力から（Opus から下げる） |
| 移行でトークン数が増えた | 新しいトークナイザーで約30%増。使うモデルで数え直す |
| 送る前にトークン数を知りたい | トークン数を数える API（見積もり） |
| 組織全体の費用を追いたい | Usage and Cost API、Console の Usage / Cost |
| 毎回同じ長い前置き | プロンプトキャッシュ。会話の途中で effort を変えない |
6. 用語集
| 用語 | 意味 |
|---|---|
| 自己回帰型 | 前の文章から次のトークンを1つずつ予測するしくみ |
| トークナイザー | 文章をトークンに分けるしくみ |
| context rot | コンテキストが長くなると正確さや思い出す力が落ちること |
| temperature | 出力のランダムさを調整するパラメータ |
| 非決定性 | 同じ入力でも出力が変わりうること |
| fast mode | 同じモデルを速い推論の設定で動かすオプション |
| effort | 賢さと速さ・コストを交換するつまみ |
| TTFT / OTPS | 最初のトークンまでの時間 / 出力トークン毎秒 |
| few-shot（multi-shot） | 例をいくつか見せて頼む方法 |
出典
- Glossary（Claude Platform Docs）: コンテキストウィンドウ、レイテンシ、事前学習（次の単語の予測）、temperature と非決定性、TTFT、トークン
- Context windows（Claude Platform Docs）: 応答も含むこと、たまっていくこと、context rot、context awareness
- Models overview（Claude Platform Docs）: 今のモデルの比較、料金、thinking、effort の初期値、コンテキスト、トークナイザー
- Choosing the right model（Claude Platform Docs）: 観点、効率から / 能力から始める方法、effort の調整
- Fast mode（Claude Platform Docs）: 速さ、
speed、レート制限、バッチ不可 - Effort（Claude Platform Docs）: 初期値、すべてのトークンに効くこと、ベストプラクティス
- Prompting best practices（Claude Platform Docs）: 例の使い方（3〜5個、関係・多様・構造化）
- Claude Sonnet 5.5 migration guide（Claude Platform Docs）: 400 エラーになる5つの設定（thinking の予算、サンプリングのパラメータ、プリフィル、ツールの強制、thinking の無効化）、移行のチェックリスト
- Claude Fable 5.1（Claude Platform Docs）: Fable 5.1 のモデルページ
- Claude Haiku 5.5 migration guide（Claude Platform Docs）: トークンの数え直し（約30%増）、サンプリングのパラメータを外す
- Pricing（Claude Platform Docs）: fast mode・長いコンテキスト・データの場所の料金、コスト最適化の目安
- Token counting（Claude Platform Docs）: 数える API、見積もりであること
- Usage and Cost API（Claude Platform Docs）: 組織の使用量と費用の取得
- Prompt caching（Claude Platform Docs）: ブレークポイント、さかのぼる範囲、倍率
第2.2節の WebSocket の説明と、第4.6節の「キャッシュのチェックポイント」の解釈は、公式ドキュメントからの直接の要約ではありません。第4.4節の計算例は、公式の単価と倍率を使った試算です。内容は上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。