第2章 LLMの基礎 — 解答例

本文: 第2章 LLMの基礎

問1

→ 参照: 2.2.2節(トークンベースの課金 / プロンプトキャッシュ) / 2.4節

(a) キャッシュなし

各ステップの入力は「固定8,000 + 蓄積したツール結果」。ステップ i の入力は 8,000 + 1,500×(i−1) なので、

入力累計 = 15 × 8,000 + 1,500 × (0+1+…+14) = 120,000 + 157,500 = 277,500 トークン
入力コスト = 277,500 / 1,000,000 × $3 = $0.8325
出力累計 = 15 × 400 = 6,000 トークン → 6,000 / 1,000,000 × $15 = $0.0900
合計 $0.9225

(b) 先頭8,000トークンに5分キャッシュ

キャッシュ書き込み(ステップ1): 8,000 × 1.25 = 10,000 トークン相当
キャッシュ読み出し(ステップ2〜15の14回): 8,000 × 14 × 0.1 = 11,200 トークン相当
キャッシュ対象外(蓄積するツール結果): 157,500 トークン
実効入力 = 10,000 + 11,200 + 157,500 = 178,700 トークン相当
入力コスト = 178,700 / 1,000,000 × $3 = $0.5361
出力は変わらず $0.0900
合計 $0.6261

削減率 = (0.9225 − 0.6261) / 0.9225 = 32.1%

考察: 削減されたのは入力側だけであり、それでも全体の3割強が消える。これは 2.4節で述べた「コストの大半が入力側、しかもその多くが同じ内容の再送」という構造の帰結である。なお、ここで削減しきれていない157,500トークンは蓄積するツール結果であり、キャッシュのブレークポイントを会話履歴の末尾へ移動させてツール結果もキャッシュ対象に含めると、削減率はさらに上がる(2.4節)。

問2

→ 参照: 2.2.2節(プロンプトキャッシュ)

問題箇所: 先頭に [現在時刻: 2026-07-29 14:32:11] が置かれている点。

プロンプトキャッシュはプレフィックス(先頭からの一致)で判定される。先頭の1トークンでも変われば、それ以降のすべてがキャッシュミスになる。この構成では現在時刻が毎回変わるため、後続の6,000トークンの規程も3,000トークンのツール定義も一度もキャッシュヒットしない。それどころか毎回キャッシュ書き込み(1.25倍)が発生する設定なら、キャッシュを使わない場合より高くつく。

修正した構成

[あなたは経理業務を支援するエージェントです。以下の規程に従ってください……(6,000トークン)]
[利用可能なツール定義(3,000トークン)]
        ↑ ここまでを cache_control でキャッシュ対象にする(9,000トークン)
[会話履歴]
[現在時刻: 2026-07-29 14:32:11]   ← 毎回変わるものは最後尾へ

鉄則は 「変化しないものを前に、変化するものを後ろに」(2.2.2節)。現在時刻はシステムプロンプトではなく、ユーザーメッセージ側の末尾やその直前に付与するのが素直である。

補足(本文の範囲外): 時刻の粒度を「日付のみ」に落として1日単位でしかキャッシュを壊さない、という運用も考えられるが、本文が示す原則は「後ろに置く」ことである。

問3

→ 参照: 2.3.1節 / 2.3.3節 / 2.3.4節 / 2.3.5節

原因① Temperature が高すぎる(→ 0 にする) ツール呼び出しのJSONは構造が厳密に決まっており、揺れる余地がない。Temperature が高いと分布が平坦化して低確率トークンが選ばれやすくなり、スキーマにないキーを出す・型を間違える・構文が崩れる、といった失敗が増える。ツール呼び出し・構造化出力では temperature=0 が原則(2.3.5節の早見表)。あわせて、Top-p を同時にいじっていないかも確認する(2.3.2節:両方を同時に動かさない)。

原因② Frequency / Presence Penalty が 0 になっていない(→ 0 に戻す) JSONでは {、"、:、フィールド名といったトークンが構造上必然的に繰り返される。ペナルティをかけると、この必然的な繰り返しまで抑制され、閉じ括弧や引用符が落ちて構文が壊れる。設問の「キーの重複」も、ペナルティで正常なトークン列が歪められた結果として説明できる。エージェントでは常に 0 に固定するのが安全である(2.3.3節)。

原因③(閉じ括弧欠けの最有力候補)max_tokens が小さすぎる 出力が上限で打ち切られると、JSONは必ず途中で切れる。生成パラメータの設定ミスとしてはこれが最も直接的である。修正方針は、ツール引数の想定サイズに余裕を足した値を設定したうえで、stop_reason を必ず分岐して "max_tokens" ならパースせずに再試行・分割へ回すこと(2.3.4節)。

採点の観点: 「2つ挙げよ」なので ①②、または ②③、①③ のいずれの組み合わせでも、症状との対応が説明できていれば正解としてよい。

問4

→ 参照: 2.5.1節 / 2.5.2節 / 2.5.4節(+ 13章のプライバシー保護)

構成A: クローズドウェイトモデルのみ

	内容
利点	初期コストがほぼゼロ(従量課金)。運用負荷が低く、GPU調達も推論基盤の構築も不要。最高性能帯のモデルをすぐ使える。エージェント本体(ループ制御・ツール設計・評価)という本質的な作業に集中できる
リスク	氏名・メールアドレスを含む文書がプロバイダに送信される。医療・金融・行政のような規制環境や、社内規程で外部送信が禁じられている場合は成立しない。データ保持ポリシーは各社の規約に依存する。モデルがプロバイダ都合で更新・廃止され、バージョンを自分で固定できない

構成B: ハイブリッド(ローカルの小型オープンウェイトモデル + クローズドウェイト)

2.5.2節が挙げる典型構成そのもの。PII検出・マスキングをローカルの小型モデルで行い、マスク済みのデータのみをフロンティアモデルに投げる。

	内容
利点	個人情報を自社環境から出さずに、フロンティアモデルの性能を使える。規制要件に適合させやすい。ローカル側は Apache 2.0 / MIT のモデルを選べばライセンス上の制約も小さい(2.5.3節)
リスク	マスキングの取りこぼしが最大のリスク(表記ゆれ、部署名+役職のような間接識別子は検出が難しく、1件の漏れが事故になる)。GPU調達と推論基盤の運用負荷が乗る。モデルが2つになるぶん保守と評価の対象が増える。マスキングで文脈が壊れ、回答品質が落ちることがある

見落としやすい点: RAGでは埋め込み生成も外部APIへの送信である。文書をチャンク化してクラウドの埋め込みAPIに投げれば、生成モデルを避けた意味がなくなる。ハイブリッド構成を採るなら、埋め込みモデルもローカル化するか、マスキング後に埋め込むかを決めておく必要がある。

採点の観点: 「オープンウェイト=オープンソース」と混同していないか、ライセンスをモデルカード単位で確認する必要に触れているか(2.5.4節)も評価対象になる。

Built with Astro ・ Deployed on Cloudflare Pages