第3章 LLM活用の基本 — 解答例
本文: 第3章 LLM活用の基本
→ 参照: 3.2.2節 / 3.2.4節(+ 3.7.3節)
(a) 最終的な調査レポート(約3,000トークン)→ ストリーミング ユーザーが読む最終応答であり、非ストリーミングだと3,000トークンの生成が終わるまで画面が動かない。逐次表示にすると体感待ち時間が劇的に短くなる。加えて、長い出力の非ストリーミングリクエストは経路上のプロキシやLBのアイドルタイムアウトに引っかかりうる(3.2.4節)ため、たとえ逐次表示しなくてもストリーミングで受け取るのが安全である。
(b) 次に呼ぶツールをJSONで判断 → 非ストリーミング
エージェントの内部ステップであり、JSONは完成するまでパースできない。途中経過には利用価値がなく、ストリーミングの利点が存在しない。完全なレスポンスが揃ってから stop_reason で安全に分岐する形が正しい(3.2.3節のコード例)。
(c) 1万件のログを夜間バッチで分類 → 非ストリーミング 誰も画面を見ていないので逐次性に意味がない。むしろ即時性が不要な処理なので、バッチAPI(約50%割引)の適用対象である(3.7.3節)。
(a) なぜコストが膨らんだか
effort の既定値が high だからである(3.3.2節)。指定しない = 節約されるのではなく、指定しない = すべての呼び出しが high で走る。しかも思考トークンは出力トークンとして課金される(3.3.3節の注記)。設問の構成は 1 + 8 + 8 + 1 = 18回のLLM呼び出しがあり、その全部が最も深い思考を伴って実行されていたことになる。設計の作業は「必要なところを上げる」ではなく 「不要なところを下げる」 である。
(b) 設定し直し方と、効果の大きい順
| 順位 | ステップ | 回数 | 推奨 effort | 理由 |
|---|---|---|---|---|
| 1 | 結果要約 | 8回 | low |
難易度が低く回数が多い。下げても品質がほぼ落ちない、最も費用対効果の高い削減先 |
| 2 | ツール選択 | 8回 | low 〜 medium |
選択肢が明確ならパターンマッチに近く、思考の効果が薄い。ツールが多く紛らわしい場合は medium に留める |
| 3 | 最終応答 | 1回 | medium(内容次第で既定のまま) |
ユーザーが直接目にするため下げすぎない。ただし1回なので総額への寄与は小さい |
| 4 | 計画立案 | 1回 | high(既定のまま) |
誤ると全体が破綻する。最も投資価値が高く、1回しか走らないので下げる意味がない |
削減効果は「1回あたりの節約 × 呼び出し回数」で決まるため、回数の多いステップを下げるのが効く。計画立案を high のまま残しても総額はほとんど変わらない。これは 3.3.3節が述べる「計画フェーズは高いまま、実行フェーズは明示的に落とす」という役割分担であり、第9章の Planner-Executor アーキテクチャの根拠でもある。
→ 参照: 3.6.3節 / 3.7.2節(+ 2.2.2節)
(a) RAG方式を選ぶ。理由3つ
- 出典提示が要件だから。RAGはチャンク単位で「どの文書のどこを根拠にしたか」を追跡でき、出典番号を付けて提示できる。40万トークンを丸ごと投入する方式では、どの部分を根拠にしたのかを機械的に特定できない(3.6.3節の比較表)。
- 部署ごとの閲覧制限があるから。RAGならチャンクにメタデータ(所管部署・権限)を付け、検索時にフィルタしてそのユーザーが見てよい文書だけを文脈に入れられる。全文投入では、閲覧権限のない文書までモデルのコンテキストに入り、回答に混入しうる。これは実質的な権限違反であり、コンテキスト長では解決できない。
- コスト。全文投入は毎クエリ40万トークンに課金される。RAGなら検索した数千トークンで済み、桁が2つ違う((b)参照)。
なお「月に数回更新」は再インデックスの負荷が軽いことを意味し、RAGの主な弱点(更新反映の手間)がこのケースでは問題にならない。むしろRAGが有利に働く条件である。
(b) 概算コスト(Claude Sonnet 5 標準レート: 入力 $3 / 出力 $15 per MTok)
仮定(明示すること)
- 検索で取得するチャンク: 8件 × 600トークン = 4,800トークン
- システムプロンプト + ツール定義: 2,000トークン
- 質問と定型部分: 200トークン
- → 1クエリあたり入力 約7,000トークン、出力 600トークン
- 月間 10,000クエリ
キャッシュなし
- 入力: 10,000 × 7,000 = 70,000,000 → 70 × $3 = $210
- 出力: 10,000 × 600 = 6,000,000 → 6 × $15 = $90
- 合計 約 $300 / 月
固定の2,000トークンにプロンプトキャッシュが効いた場合
- 実効入力 ≒ 200(読み出し)+ 5,000 = 5,200トークン/クエリ → 52 × $3 = $156
- 合計 約 $246 / 月
- ただし月10,000クエリは平均 約14件/時であり、5分キャッシュのTTL内に次のクエリが来ない時間帯が多い。ヒット率は想定より低くなりうるので、上振れ側($300)で見積もっておくのが安全である。
比較(全文投入を選んだ場合)
- 入力 400,000トークン × $3/MTok = $1.20/クエリ → 約 $12,000 / 月(キャッシュが常時ヒットしても約 $1,300 / 月 + 書き込み分)
コスト面だけでも40倍の差がつく。(a)の理由1・2と合わせて、RAG一択と判断できる。
採点の観点: 数値そのものより、仮定を明示していることと、桁の比較で結論を支えていることを見る。
原因
埋め込みによる意味検索は、固有名詞・型番・IDの厳密一致が苦手である(3.5.4節)。「XR-4471B」はベクトル空間上で「XR-4471C」や「XR-3380A」とほとんど区別がつかず、意味的類似度で並べても正しい文書が上位に来ない。加えて、チャンク分割の際に型番が記載された見出し・型番一覧表と、仕様の本文が別チャンクに切れてしまい、仕様側のチャンクに型番の文字列が含まれていないケースも多い(3.6.2節)。この場合、そもそも照合対象がない。
対処法1: ハイブリッド検索にする ベクトル検索とBM25等のキーワード検索を併用し、スコアを統合する。型番のような厳密一致はキーワード側が確実に拾い、言い換えを含む質問はベクトル側が拾う。3.5.4節が「実務では標準的な構成」と述べているとおり、この種の弱点への第一の対処である。
対処法2: 型番をメタデータとして持ち、フィルタ検索する
インデックス構築時に各チャンクから型番を抽出して product_code フィールドに格納し、クエリに型番が含まれる場合はメタデータ完全一致でフィルタしてからベクトル検索する。3.6.2節の「メタデータの付与」の応用で、数値範囲・日付範囲と同じくメタデータフィルタで処理すべき類の条件である。
別解として認められるもの: チャンクに親文書のタイトル・見出し(型番を含む)をヘッダとして継承させる(チャンク設計の改善)、リランカーを入れて上位30件から精査する(3.6.2節)。いずれも本文に根拠がある。
→ 参照: 3.4.2節 / 3.4.3節 / 3.6.1節
模範解答
まず、この要望はファインチューニングが構造的に解決できない類の課題である。3.4.3節が明示するとおり、「知識の追加」はファインチューニングが解決しない問題の筆頭である。理由は3つ。
- 更新のたびに再学習が必要になる。社内規程は改定される。改定のたびに学習データを作り直して再学習するのは、運用として成立しにくい。
- 学習した知識は不正確に想起される。重みに溶かし込まれた知識は、もっともらしい形で誤って再生される(ハルシネーション)。規程のように一言一句が意味を持つ情報には最も向かない。
- 出典を示せず、アクセス制御もできない。「どの規程の第何条に基づくか」を提示できず、閲覧権限による絞り込みもできない。
代わりに提案すべき方式
3.4.2節のフローチャートに沿って、順に検討する。
- 第一に RAG。規程を検索対象にし、該当条項を取得してコンテキストに入れ、条番号つきで出典を示させる。改定は再インデックスだけで反映され、部署別の閲覧制限もメタデータで扱える。
- 規程の総量が数万トークン以下で固定的なら、全文をコンテキストに投入する方式も有力である(3.6.3節)。プロンプトキャッシュ(第2章)と組み合わせればコストも抑えられ、実装は最も簡単で精度も高い。
- その前に、プロンプトの改善と Few-shot 例示を尽くす。3.4.2節の大原則である。
ファインチューニングが正当化されうる条件も、あわせて伝えておくと建設的である。「出力フォーマットを厳密に固定したい」「長大な指示を内在化させてプロンプトを短縮したい」といった目的なら候補になる。ただしそれも、システム設計が固まり評価基盤(第11章)が整い、「プロンプトではこれ以上上がらない」ことがデータで示された後の話である(3.4.4節)。
Built with Astro ・ Deployed on Cloudflare Pages
© 2026 watakumi — made with 💜 & ☕ ・watakumi.page