第2章 LLMの基礎(LLM Fundamentals)
2.1 概要
Section titled “2.1 概要”エージェントの中核にはLLM(Large Language Model、大規模言語モデル)がある。エージェント開発者にとってLLMは「中身をすべて理解すべき研究対象」ではなく、「特性と制約を把握して使いこなすべき部品」である。
本章はその立場から書かれている。Transformerの数式を導出することはしないが、なぜコンテキストが長いと高価で遅くなるのか、なぜ日本語は英語よりトークンを消費するのか、なぜTemperatureを上げるとツール呼び出しが壊れるのかといった、実務で必ずぶつかる疑問には答えられるようにする。
エージェント開発の文脈で特に重要なのは、LLMが持つ次の3つの性質である。
- ステートレス(stateless)である — モデルは前回の会話を覚えていない。会話が続いているように見えるのは、毎回すべての履歴を送り直しているからである。この事実がコスト構造とメモリ設計(第8章)のすべてを規定する
- 入力に上限がある — コンテキストウィンドウを超えたものは渡せない。エージェントのループが長引くほどこの上限が近づく
- 出力が確率的である — 同じ入力でも出力が揺れる。ツール呼び出しの信頼性を上げるには、この揺れを制御する必要がある
2.2 Transformerモデルとその仕組み
Section titled “2.2 Transformerモデルとその仕組み”2.2.1 実務に必要な理解の範囲
Section titled “2.2.1 実務に必要な理解の範囲”現代のLLMはほぼ例外なくTransformerアーキテクチャ(Vaswani et al., 2017)を基礎としている。エージェント開発者が押さえるべき要点は次の3つに集約できる。
自己注意機構(Self-Attention): 各トークンが他のすべてのトークンとの関連度を計算する仕組み。これがLLMの文脈理解の中核であり、同時に計算量がトークン数の2乗に比例する原因でもある。10万トークンのコンテキストは1万トークンの10倍ではなく、素朴には100倍近い計算を要する。実際の推論では各種の最適化が入るためここまで単純ではないが、「長いコンテキストは不釣り合いに高くつく」という直感は正しい。
自己回帰生成(Autoregressive Generation): LLMは出力を一度に生成せず、1トークンずつ順番に予測していく。生成済みのトークンは次のトークンの予測に使われる。この逐次性が2つの帰結を生む。第一に、出力トークンは入力トークンより高価である(各社の価格表で出力が入力の5〜6倍になっているのはこのため)。第二に、出力が長いほど比例して遅くなる — ここからストリーミング(第3章)の必要性が出てくる。
確率分布からのサンプリング: モデルは次のトークンを決定的に選んでいるのではなく、語彙全体に対する確率分布を出力し、そこから1つをサンプリングしている。2.3節で扱う生成制御パラメータは、すべてこのサンプリング過程への介入である。
2.2.2 モデルメカニクス(Model Mechanics)
Section titled “2.2.2 モデルメカニクス(Model Mechanics)”トークン化(Tokenization)
Section titled “トークン化(Tokenization)”LLMは文字や単語ではなくトークンという単位でテキストを扱う。トークンは「よく出現する文字の並び」に対して割り当てられた識別子であり、多くのモデルはBPE(Byte Pair Encoding)系のアルゴリズムで語彙を構築している。
トークン化はエージェント開発において、次の3つの実害を生む。
① 言語によるコスト差: トークナイザは主に英語コーパスで最適化されているため、日本語は同じ情報量でもトークン数が多くなる。おおまかな目安は次のとおりである。
| 言語・データ | 1トークンあたりの目安 | 備考 |
|---|---|---|
| 英語テキスト | 約4文字 / 約0.75単語 | 最も効率が良い |
| 日本語テキスト | 約1〜1.5文字 | 英語の2〜3倍のトークンを消費 |
| ソースコード | 約3〜4文字 | インデントや記号がトークンを食う |
| JSON | 約2〜3文字 | 引用符・波括弧がかさむ |
つまり日本語で書かれたシステムプロンプトは、同内容の英語版より2〜3倍のコストがかかる。これは無視できない差であり、大量に呼び出すエージェントではシステムプロンプトのみ英語で書くという選択も現実的な最適化になる(ただし可読性・保守性とのトレードオフである)。
② 文字単位の処理が苦手: 「strawberryにrは何個あるか」という古典的な質問にLLMが失敗しがちなのは、モデルが文字ではなくトークンを見ているためである。エージェントに文字列の厳密な操作(文字数カウント、逆順化、特定文字の置換)をさせたい場合は、LLMに直接やらせずコード実行ツールに任せるのが正しい設計である。
③ 予算見積もりの必要性: コンテキストウィンドウの管理には、送信前にトークン数を把握できることが望ましい。主要プロバイダはトークン計測の手段を提供している。
# OpenAI系: tiktoken でローカルに計測できるimport tiktoken
encoding = tiktoken.get_encoding("o200k_base")text_en = "AI agents are autonomous systems."text_ja = "AIエージェントは自律的なシステムです。"
print(f"英語: {len(encoding.encode(text_en))} トークン ({len(text_en)} 文字)")print(f"日本語: {len(encoding.encode(text_ja))} トークン ({len(text_ja)} 文字)")// OpenAI系: Python 版は tiktoken でローカルに計測する。// TypeScript 版では【概算】で代用する(tiktoken 相当のライブラリは// WASM やモデルファイルの取得を伴い、依存が増えるため)。// 厳密な値が必要なときは、次のコードのようにプロバイダの計測APIを使う
/** 概算のトークン数。ASCIIは約4文字で1トークン、日本語などは約1文字で1トークン。 */function estimateTokens(text: string): number { let ascii = 0 let wide = 0 for (const ch of text) { if ((ch.codePointAt(0) ?? 0) < 128) ascii += 1 else wide += 1 } return Math.ceil(ascii / 4 + wide)}
const textEn = 'AI agents are autonomous systems.'const textJa = 'AIエージェントは自律的なシステムです。'
// JavaScript の .length はUTF-16単位を数えるため、Python の len() と一致しない// 文字がある。文字数は [...text].length(コードポイント単位)で数えるconsole.log( `英語: ${estimateTokens(textEn)} トークン (${[...textEn].length} 文字)`)console.log( `日本語: ${estimateTokens(textJa)} トークン (${[...textJa].length} 文字)`)# Anthropic系: count_tokens エンドポイントで実測できるimport anthropic
client = anthropic.Anthropic()result = client.messages.count_tokens( model="claude-sonnet-5", messages=[{"role": "user", "content": "AIエージェントとは何ですか?"}],)print(f"入力トークン数: {result.input_tokens}")// Anthropic系: count_tokens エンドポイントで実測できるimport Anthropic from '@anthropic-ai/sdk'
const client = new Anthropic()const result = await client.messages.countTokens({ model: 'claude-sonnet-5', messages: [{ role: 'user', content: 'AIエージェントとは何ですか?' }],})console.log(`入力トークン数: ${result.input_tokens}`)注意: トークナイザはモデルファミリごとに異なる。OpenAI用の
tiktokenで数えた値をClaudeやGeminiの見積もりに流用すると誤差が出る。厳密な予算管理が必要な場面では、そのモデル用の手段で計測すること。
コンテキストウィンドウ(Context Window)
Section titled “コンテキストウィンドウ(Context Window)”コンテキストウィンドウとは、モデルが一度に処理できる入力と出力の合計トークン数の上限である。2026年7月時点の主要モデルの状況は次のとおり。
| モデル | コンテキストウィンドウ | 最大出力 |
|---|---|---|
| Claude Fable 5 / Opus 5 / Sonnet 5 | 1,000,000 トークン | 128,000 トークン |
| Claude Haiku 4.5 | 200,000 トークン | 64,000 トークン |
| GPT-5.6 Sol / Terra / Luna | 1,050,000 トークン | 128,000 トークン |
(各社公式ドキュメント、2026年7月29日参照)
100万トークンという数字は、日本語なら書籍数冊分に相当する。「もう制約ではない」ように見えるが、エージェント開発の現場ではこれが誤解のもとになる。理由は3つある。
理由① コストが線形に増える: コンテキストは毎ターン送り直される。エージェントループが20ステップ回れば、初期プロンプトは20回課金される。2.4節で詳しく計算する。
理由② レイテンシが増える: 入力が長いほど最初のトークンが返るまでの時間(TTFT、Time To First Token)が延びる。対話型エージェントでは体感品質に直結する。
理由③ 精度が落ちる場合がある: 非常に長いコンテキストの中央部にある情報は、冒頭や末尾にある情報より参照されにくい傾向が報告されてきた。いわゆる「中盤の喪失(lost in the middle)」現象として知られるものである。近年のモデルはこの点が大きく改善しているが、「入れておけば必ず使われる」と考えるのは危険である。重要な指示はプロンプトの冒頭または末尾に置くという経験則は依然として有効である。
エージェントにおけるコンテキストの内訳は、おおよそ次のように配分される。
このうちツール実行結果(D)が最も膨張しやすい。Web検索の生HTMLやDBクエリの全件結果をそのまま入れると、数ステップでウィンドウを食い尽くす。第7章では、ツール側で結果を要約・切り詰めてから返す設計を扱う。
トークンベースの課金(Token Based Pricing)
Section titled “トークンベースの課金(Token Based Pricing)”課金は入力トークンと出力トークンで別レートである。前述のとおり出力は自己回帰生成のため高価で、多くのモデルで入力の5〜6倍に設定されている(軽量モデルではさらに比率が開き、8倍を超えるものもある)。
2026年7月29日時点の主要モデルの標準レート(100万トークンあたり、USD):
| モデル | 入力 | 出力 | 出力/入力比 |
|---|---|---|---|
| Claude Fable 5 | $10.00 | $50.00 | 5.0x |
| Claude Opus 5 | $5.00 | $25.00 | 5.0x |
| Claude Sonnet 5 | $3.00 | $15.00 | 5.0x |
| Claude Haiku 4.5 | $1.00 | $5.00 | 5.0x |
| GPT-5.6 Sol | $5.00 | $30.00 | 6.0x |
| GPT-5.6 Terra | $2.50 | $15.00 | 6.0x |
| GPT-5.6 Luna | $1.00 | $6.00 | 6.0x |
| Gemini 3.6 Flash | $1.50 | $7.50 | 5.0x |
| Gemini 3.5 Flash-Lite | $0.30 | $2.50 | 8.3x |
GPT-5.6系の長コンテキスト料金: OpenAIのGPT-5.6系は、コンテキスト長に応じて2段階の料金体系を持つ。上表は短コンテキスト時のレートである。長コンテキスト時は別レートが適用され、Sol $10.00 / $45.00、Terra $5.00 / $22.50、Luna $2.00 / $9.00 となる。エージェントは会話履歴とツール結果の蓄積により長コンテキスト帯に入りやすいため、コスト試算では長コンテキスト側のレートも織り込むべきである。
Claude Sonnet 5 の注記: 2026年8月31日までは導入価格として入力 $2.00 / 出力 $10.00 が適用され、9月1日から上記の標準レートに移行する(Anthropic公式価格ページ、2026年7月29日参照)。
価格は変動する。 本表は執筆時点のスナップショットであり、実装前には必ず各社の公式価格ページで最新値を確認すること。
プロンプトキャッシュ(Prompt Caching)
Section titled “プロンプトキャッシュ(Prompt Caching)”エージェント開発において最も効果の大きいコスト最適化がプロンプトキャッシュである。システムプロンプトやツール定義のように「毎ターン変わらない前半部分」をサーバー側にキャッシュしておき、2回目以降は大幅な割引レートで再利用する仕組みである。
Claudeの場合の倍率は次のとおり(2026年7月29日参照)。
| 操作 | 基本入力レートに対する倍率 | Opus 5 での実額 |
|---|---|---|
| 通常の入力 | 1.0x | $5.00 / MTok |
| キャッシュ書き込み(5分保持) | 1.25x | $6.25 / MTok |
| キャッシュ書き込み(1時間保持) | 2.0x | $10.00 / MTok |
| キャッシュ読み出し(ヒット) | 0.1x | $0.50 / MTok |
読み出しが基本レートの10分の1になる点が重要である。同じプレフィックスを2回送る場合を比べると、キャッシュなしなら 1.0 + 1.0 = 2.0倍、5分キャッシュありなら 1.25(書き込み)+ 0.1(読み出し)= 1.35倍となり、1回でも再利用されれば元が取れる。1時間キャッシュは書き込みが2.0倍なので、2回の再利用で損益分岐する(2.0 + 0.1 × 2 = 2.2 < 3.0)。
エージェントループは同一のシステムプロンプトとツール定義を何十回も送り直すため、キャッシュの効果が最も出やすいワークロードである。
import anthropic
client = anthropic.Anthropic()
LONG_SYSTEM_PROMPT = """あなたは社内業務を支援するAIエージェントです。(……長大な行動規範・ドメイン知識・ツール利用方針……)"""
response = client.messages.create( model="claude-sonnet-5", max_tokens=1024, system=[ { "type": "text", "text": LONG_SYSTEM_PROMPT, # この位置までをキャッシュ対象にする "cache_control": {"type": "ephemeral"}, } ], messages=[{"role": "user", "content": "先月の売上を集計して"}],)
u = response.usageprint(f"キャッシュ書き込み: {u.cache_creation_input_tokens} トークン")print(f"キャッシュ読み出し: {u.cache_read_input_tokens} トークン")print(f"通常入力: {u.input_tokens} トークン")import Anthropic from '@anthropic-ai/sdk'
const client = new Anthropic()
const LONG_SYSTEM_PROMPT = `あなたは社内業務を支援するAIエージェントです。(……長大な行動規範・ドメイン知識・ツール利用方針……)`
const response = await client.messages.create({ model: 'claude-sonnet-5', max_tokens: 1024, system: [ { type: 'text', text: LONG_SYSTEM_PROMPT, // この位置までをキャッシュ対象にする cache_control: { type: 'ephemeral' }, }, ], messages: [{ role: 'user', content: '先月の売上を集計して' }],})
const u = response.usageconsole.log(`キャッシュ書き込み: ${u.cache_creation_input_tokens} トークン`)console.log(`キャッシュ読み出し: ${u.cache_read_input_tokens} トークン`)console.log(`通常入力: ${u.input_tokens} トークン`)キャッシュを効かせるための設計上の鉄則は、変化しないものを前に、変化するものを後ろに置くことである。キャッシュはプレフィックス(先頭からの一致)で判定されるため、システムプロンプトの冒頭に現在時刻を入れるといった設計は、毎回キャッシュを無効化してしまう。
✅ 良い順序: [システムプロンプト][ツール定義][固定の参考資料][会話履歴][現在時刻]❌ 悪い順序: [現在時刻][システムプロンプト][ツール定義][会話履歴] ↑ここが毎回変わるため、以降すべてキャッシュミスになるバッチAPI
Section titled “バッチAPI”即時性が不要な処理(大量文書の分類、評価データセットの一括生成など)にはバッチAPIが使える。各社ともおおむね50%割引で、Claudeでは Opus 5 が入力 $2.50 / 出力 $12.50 になる。第11章で扱う評価の実行は、バッチAPIの典型的な適用先である。
2.3 生成制御(Generation Controls)
Section titled “2.3 生成制御(Generation Controls)”サンプリング過程に介入するパラメータ群である。エージェント開発では、これらの設定ミスがツール呼び出しの失敗として表面化することが多い。
2.3.1 Temperature(温度)
Section titled “2.3.1 Temperature(温度)”確率分布の「尖り具合」を調整するパラメータ。値が低いほど高確率のトークンに集中し(決定的)、高いほど分布が平坦化して低確率のトークンも選ばれやすくなる(多様)。
| 設定値 | 挙動 | エージェントでの用途 |
|---|---|---|
| 0.0 | ほぼ決定的。常に最尤トークンを選ぶ | ツール呼び出し、構造化出力、分類、抽出 |
| 0.2〜0.5 | わずかに揺れる | 事実ベースのQA、要約 |
| 0.7〜1.0 | 標準的な多様性 | 対話、文章生成 |
| 1.0超 | 高い多様性。破綻しやすい | ブレインストーミング、創作 |
有効範囲はプロバイダで異なる。 Anthropic の Messages API では
temperatureの有効範囲は 0.0〜1.0 であり、1.0を超える値は指定できない。OpenAI系では 0.0〜2.0 を取れる。マルチプロバイダ対応のエージェントを書く場合、この差を吸収する抽象化層が必要になる。
エージェント開発における原則は「迷ったら低く」である。 ツール呼び出しのJSONを生成させる場面でTemperatureが高いと、スキーマから外れたキーを出力したり、引数の型を間違えたりする確率が上がる。エージェントループは1ステップの失敗が全体の失敗に波及するため、この揺れは高くつく。
一方、エージェントの「計画立案」ステップだけは中程度の値が有効な場合がある。同じ手順を繰り返して行き詰まる(ループに陥る)エージェントに対し、多様性を与えて別の道筋を探させる狙いである。
注意: Temperature = 0 は「完全に再現性がある」ことを意味しない。GPUによる浮動小数点演算の非決定性やバックエンドのバッチ処理により、同じ入力でも出力が揺れる場合がある。再現性が必要な評価では、
seedパラメータ(提供しているプロバイダの場合)を併用し、それでも完全一致は保証されないことを前提に設計する。
2.3.2 Top-p(核サンプリング / Nucleus Sampling)
Section titled “2.3.2 Top-p(核サンプリング / Nucleus Sampling)”確率の高いトークンから順に累積確率が p に達するまでを候補とし、それ以外を切り捨てる方式。top_p = 0.9 なら「累積確率90%に入る上位トークンのみ」から選ぶ。
Temperatureが分布の形を変えるのに対し、Top-pは候補の範囲を切る。裾野にある明らかに不適切なトークンを排除できるのが利点である。
重要な実務指針: TemperatureとTop-pを同時に動かさない。 両者は同じサンプリング過程に作用するため、同時に調整すると効果が交絡して原因の切り分けができなくなる。各社のドキュメントも一方のみの調整を推奨している。エージェント開発では Temperature を主軸にし、Top-p はデフォルトのままにするのが扱いやすい。
2.3.3 Frequency Penalty と Presence Penalty
Section titled “2.3.3 Frequency Penalty と Presence Penalty”いずれも繰り返しを抑制するパラメータだが、作用が異なる。
| パラメータ | 作用 | 効果 |
|---|---|---|
| Frequency Penalty(頻度ペナルティ) | 出現回数に比例して、そのトークンの確率を下げる | 同じ語の連呼を抑える。値を上げるほど反復に強いペナルティ |
| Presence Penalty(存在ペナルティ) | 一度でも出現していれば一律に確率を下げる | 新しい話題への移行を促す |
いずれも一般に -2.0 〜 2.0 の範囲を取り、デフォルトは 0 である。
エージェント開発では、これらを 0 のままにしておくことを強く推奨する。 理由は、ツール呼び出しやJSON出力では同じトークン({、"name"、フィールド名など)が構造上必然的に繰り返されるためである。ペナルティをかけると、その必然的な繰り返しまで抑制され、構文が壊れる。
これらのパラメータが有効なのは、あくまで自由記述の文章生成において「同じ表現ばかり出てくる」問題に対処する場合である。
なお、Anthropicの Messages API はこれらのペナルティパラメータを提供していない。プロバイダによってパラメータ体系が異なる点は、マルチプロバイダ対応のエージェントを作るときの実務的な注意点になる。
2.3.4 停止条件(Stopping Criteria)と最大長(Max Length)
Section titled “2.3.4 停止条件(Stopping Criteria)と最大長(Max Length)”生成を打ち切る条件は3種類ある。
① max_tokens(最大出力トークン数): 出力の上限。エージェントでは必ず明示的に設定する。設定しないと、モデルが暴走して長大な出力を生成し、コストとレイテンシが跳ね上がる事故が起きる。ただし小さすぎると、ツール呼び出しのJSONが途中で切れて構文エラーになる。ツールの引数が大きくなりうる場合は余裕を持たせること。
② stop sequences(停止シーケンス): 指定した文字列が出現した時点で生成を打ち切る。特定のフォーマットで出力させるときに有用である。
③ EOS トークン: モデルが自然に「終わり」と判断した場合。正常終了。
エージェント実装で重要なのは、なぜ生成が終わったのかを必ず確認することである。max_tokens で打ち切られた出力をそのままパースしようとすると、不完全なJSONで例外が飛ぶ。
response = client.messages.create( model="claude-sonnet-5", max_tokens=4096, temperature=0, # ツール呼び出しなので決定的に stop_sequences=["</result>"], messages=[{"role": "user", "content": "..."}],)
# stop_reason を必ず分岐するmatch response.stop_reason: case "end_turn": pass # 正常終了 case "max_tokens": # 出力が途中で切れている。パースせず、リトライか分割処理へ raise ValueError("出力が max_tokens で打ち切られました") case "stop_sequence": pass # 指定した停止文字列で終了 case "tool_use": pass # ツール呼び出しを要求している(第7章)const response = await client.messages.create({ model: 'claude-sonnet-5', max_tokens: 4096, temperature: 0, // ツール呼び出しなので決定的に stop_sequences: ['</result>'], messages: [{ role: 'user', content: '...' }],})
// stop_reason を必ず分岐するswitch (response.stop_reason) { case 'end_turn': break // 正常終了 case 'max_tokens': // 出力が途中で切れている。パースせず、リトライか分割処理へ throw new Error('出力が max_tokens で打ち切られました') case 'stop_sequence': break // 指定した停止文字列で終了 case 'tool_use': break // ツール呼び出しを要求している(第7章)}2.3.5 パラメータ設定の早見表
Section titled “2.3.5 パラメータ設定の早見表”エージェントの用途別の推奨設定をまとめる。
| 用途 | Temperature | Top-p | Penalties | max_tokens |
|---|---|---|---|---|
| ツール呼び出し・構造化出力 | 0 | デフォルト | 0 | 引数の想定サイズ + 余裕 |
| 分類・抽出・ルーティング | 0 | デフォルト | 0 | 小さめ(数十〜数百) |
| RAGに基づくQA | 0〜0.3 | デフォルト | 0 | 中程度 |
| 計画立案・タスク分解 | 0.3〜0.7 | デフォルト | 0 | 中程度 |
| 対話・文章生成 | 0.7〜1.0 | デフォルト | 0〜0.5 | 用途による |
2.4 コスト構造の実際 — エージェント特有の落とし穴
Section titled “2.4 コスト構造の実際 — エージェント特有の落とし穴”エージェントのコストは、単発のチャットとは根本的に異なる増え方をする。ステートレス性の帰結として、会話履歴は毎ターン全部送り直されるからである。
10ステップのエージェントループを考える。システムプロンプト+ツール定義が5,000トークン、各ステップでツール結果が2,000トークンずつ積み上がるとしよう。
| ステップ | 送信される入力トークン |
|---|---|
| 1 | 5,000 |
| 2 | 7,000 |
| 3 | 9,000 |
| … | … |
| 10 | 23,000 |
| 累計 | 140,000 |
出力を各ステップ500トークンとすると累計5,000トークン。Claude Sonnet 5(標準レート $3 / $15)なら:
- 入力: 140,000 / 1,000,000 × $3 = $0.42
- 出力: 5,000 / 1,000,000 × $15 = $0.075
- 合計: 約 $0.50 / タスク1回
ここで注目すべきは、コストの85%が入力側であり、しかもその多くが同じ内容の再送だという点である。だからこそプロンプトキャッシュの効果が大きい。
前半5,000トークンに5分キャッシュを適用した場合を計算してみる。ステップ1で書き込み(5,000 × 1.25 = 6,250相当)、ステップ2〜10で読み出し(9 × 5,000 × 0.1 = 4,500相当)、キャッシュ対象外のツール結果が90,000トークン。実効入力は 100,750トークン相当となり、入力コストは $0.42 → $0.30、総額では $0.495 → $0.377(約24%削減) になる。
この例ではキャッシュ対象を固定部分のみに限ったため削減率は2割強にとどまる。実際のエージェント実装では、ステップが進むごとにキャッシュのブレークポイントを会話履歴の末尾へ移動させ、蓄積したツール結果もキャッシュ対象に含めることで、削減率をさらに引き上げられる。
エージェントのコストを抑える手段を、効果の大きい順に並べると次のようになる。
- プロンプトキャッシュを効かせる — 固定部分を前方に集約する(効果大・実装容易)
- ツール結果を切り詰める — 生データを返さず、要約・上位N件に絞る(効果大)
- モデルを使い分ける — 単純な分類やルーティングは安価なモデルに任せ、複雑な推論のみ上位モデルを使う(効果大)
- 履歴を圧縮する — 古いターンを要約して置き換える(第8章)
- バッチAPIを使う — 即時性が不要な処理のみ(効果中)
2.5 オープンウェイトモデルとクローズドウェイトモデル
Section titled “2.5 オープンウェイトモデルとクローズドウェイトモデル”2.5.1 用語の整理
Section titled “2.5.1 用語の整理”クローズドウェイトモデル(Closed Weight Models) は、モデルのパラメータが公開されず、APIを通じてのみ利用できるモデルである。GPT、Claude、Gemini がこれにあたる。
オープンウェイトモデル(Open Weight Models) は、学習済みパラメータ(重み)がダウンロード可能で、自前の環境で実行できるモデルである。
ここで注意すべきは、「オープンウェイト」と「オープンソース」は同じではないという点である。多くのオープンウェイトモデルは重みこそ公開しているが、学習データや学習コードは非公開である。厳密な意味でのオープンソースAI(データ・コード・重みのすべてが公開)は、Ai2のOLMoシリーズなど一部に限られる。
2.5.2 選択の判断基準
Section titled “2.5.2 選択の判断基準”| 観点 | クローズドウェイト | オープンウェイト |
|---|---|---|
| 初期コスト | ほぼゼロ(従量課金) | GPU調達・運用体制が必要 |
| 大量利用時のコスト | トークン数に比例して増える | 固定費中心。高負荷では有利になりうる |
| データの外部送信 | プロバイダに送信される | 自社環境で完結できる |
| 最高性能 | 一般にフロンティアはこちら | 差は縮小しているが上位帯では劣後 |
| ファインチューニング | 制約が多い/不可の場合も | 自由度が高い |
| バージョン管理 | プロバイダ都合で更新・廃止される | 自分で固定できる |
| 運用負荷 | 低い | 高い(推論基盤・スケーリング・監視) |
エージェント開発における実務的な指針を挙げる。
まずクローズドウェイトで作る。 エージェントの設計で難しいのはループ制御・ツール設計・評価であり、モデルの調達ではない。最初から自前ホスティングに取り組むと、本質でない部分に時間を取られる。
オープンウェイトを検討すべき状況は明確である。医療・金融・行政などデータを外部に出せない規制環境にある場合、極端に大量のリクエストを処理して従量課金が固定費を上回る場合、特定ドメインへのファインチューニングが必要な場合、そしてモデルのバージョンを長期に固定する必要がある場合である。
ハイブリッド構成も現実的な選択肢である。個人情報を含む前処理(PII検出・マスキング)はローカルの小型オープンウェイトモデルで行い、マスク済みのデータのみをクローズドウェイトのフロンティアモデルに投げる、といった設計である。これは第13章のプライバシー保護と直結する。
2.5.3 主要なオープンウェイトモデルファミリー(2026年時点)
Section titled “2.5.3 主要なオープンウェイトモデルファミリー(2026年時点)”| ファミリー | 提供元 | ライセンス | 特徴 |
|---|---|---|---|
| gpt-oss (120B / 20B) | OpenAI | Apache 2.0 | 推論・エージェント用途を志向 |
| Llama 4 | Meta | Llama Community License(独自) | 大規模なエコシステム、マルチモーダル |
| Qwen3 | Alibaba | Apache 2.0 | Dense版とMoE版が揃う。多言語・コーディングに強い |
| DeepSeek R1 / V系 | DeepSeek | MIT(R1関連) | 推論特化。コスト効率が高い |
| Gemma 4 | Apache 2.0 | 軽量。エッジ・ローカル実行向け | |
| Mistral 系 | Mistral AI | Apache 2.0(Magistral Small等) | 欧州拠点。データ主権の要件に適合しやすい |
| Phi | Microsoft | オープン(モデルカード要確認) | 小型・低レイテンシ |
| Nemotron | NVIDIA | オープンウェイト(学習レシピも公開) | エージェント特化の派生あり |
| OLMo | Ai2 | フルオープン | 研究・再現性重視 |
| Command A+ | Cohere | オープンウェイト(要確認) | エンタープライズ・多言語 |
(出典: State of Open-Weight AI Models、2026年7月29日参照)
2.5.4 ライセンスの読み方
Section titled “2.5.4 ライセンスの読み方”ライセンスは同じ企業のカタログ内でも異なる。 「Metaのモデルだから」「Alibabaのモデルだから」とブランド単位で判断せず、必ず個別のモデルカードを確認すること。
商用利用にあたって特に確認すべき条項は次の4点である。
① 商用利用の可否と条件: Apache 2.0 や MIT であれば実務上ほぼ制約なく使える。一方、Llama Community License のような独自ライセンスは、月間アクティブユーザー数の閾値を超える場合に別途許諾が必要になるなどの条件を含むことがある。
② 出力物の扱い: モデルの生成物を他モデルの学習に使ってよいか。禁止している(蒸留を制限する)ライセンスがある。
③ 帰属表示の義務: 「Built with Llama」のような表示義務が課される場合がある。
④ 利用規定(Acceptable Use Policy): 用途制限が付随することがある。これはライセンス本文とは別文書になっていることが多いので見落としやすい。
なお、クローズドウェイトモデルにも利用規約は存在する。API経由のモデルであっても、出力の利用範囲やデータの取り扱いについて各社の規約が適用される。オープンウェイトのライセンスだけを気にして、API側の規約を読んでいないというのはありがちな抜けである。
2.6 モデルファミリーとライセンス — 実務での選定フロー
Section titled “2.6 モデルファミリーとライセンス — 実務での選定フロー”エージェントに使うモデルを選ぶ手順を、判断の順序として整理する。
実務では、単一モデルで全部やろうとしないのが定石になりつつある。エージェント内の役割ごとにモデルを分ける設計(モデルルーティング)は、コストと品質の両方で有利になることが多い。
| エージェント内の役割 | 適したモデル帯 | 理由 |
|---|---|---|
| 計画立案・タスク分解 | 上位モデル | 誤ると全体が破綻するため精度が最優先 |
| ツール選択・引数生成 | 中〜上位モデル | 構造化出力の正確さが必要 |
| 単純な分類・ルーティング | 軽量モデル | 十分な精度が出る。呼び出し回数が多い |
| 結果の要約・整形 | 軽量モデル | 難易度が低く、量が多い |
| 最終応答の生成 | 中〜上位モデル | ユーザーが直接目にする |
また、モデルIDは固定スナップショットを指定することを推奨する。エイリアス(claude-sonnet-5 のような一般名)は指す先が更新される場合があり、本番環境で意図しない挙動変化を招く。
model="claude-sonnet-5" # エイリアス。指す先が変わりうるmodel="claude-haiku-4-5-20251001" # スナップショット。日付が付くmodel: 'claude-sonnet-5' // エイリアス。指す先が変わりうるmodel: 'claude-haiku-4-5-20251001' // スナップショット。日付が付く評価(第11章)を通したバージョンをピン留めし、更新は意図的に行うべきである。
本書のコード例について: 以降のコード例では可読性のためエイリアス(
claude-sonnet-5など)を用いるが、本番ではスナップショットIDに置き換えること。最新のスナップショットIDは公式のモデル一覧で確認できる。
2.7 まとめ
Section titled “2.7 まとめ”- LLMはステートレスであり、会話の継続は履歴の再送で実現されている。この事実がエージェントのコスト構造を規定する
- トークン化により、日本語は英語の2〜3倍のトークンを消費する。また文字単位の厳密な操作はLLMに向かず、コード実行ツールに任せるべきである
- コンテキストウィンドウは100万トークン級に拡大したが、コスト・レイテンシ・中盤の精度低下という3つの理由から、依然として能動的な管理が必要である
- プロンプトキャッシュはエージェントで最も効果の大きいコスト最適化であり、「変化しないものを前に置く」設計が鍵になる
- 生成制御は、ツール呼び出しでは Temperature = 0、ペナルティ = 0 が基本。TemperatureとTop-pを同時に動かさない
stop_reasonを必ず確認する。max_tokensによる打ち切りを見逃すとパースエラーの原因になる- オープンウェイトとオープンソースは別概念。ライセンスはモデルカード単位で確認する
- 単一モデルに全役割を担わせず、役割ごとにモデルを使い分ける設計が実務の主流になりつつある
問1 あるエージェントのシステムプロンプトとツール定義が合計8,000トークンあり、これがエージェントループの15ステップすべてで再送されるとする。各ステップでツール結果が1,500トークンずつ蓄積し、出力は毎回400トークンとする。Claude Sonnet 5 の標準レート(入力 $3 / 出力 $15 per MTok)で、 (a) プロンプトキャッシュを使わない場合の総コスト (b) 先頭8,000トークンに5分キャッシュ(書き込み1.25倍、読み出し0.1倍)を適用した場合の総コスト をそれぞれ計算し、削減率を求めよ。
問2 次のシステムプロンプトの構成には、プロンプトキャッシュを無効化してしまう問題がある。問題箇所を指摘し、修正した構成を示せ。
[現在時刻: 2026-07-29 14:32:11][あなたは経理業務を支援するエージェントです。以下の規程に従ってください……(6,000トークン)][利用可能なツール定義(3,000トークン)][会話履歴]問3
エージェントがツール呼び出し用のJSONを生成する際、しばしば {"customer_id": "CUS-00123", "customer_id": "CUS-00123", ...} のようにキーが重複したり、閉じ括弧が欠けたりする問題が起きている。原因として考えられる生成パラメータの設定ミスを2つ挙げ、それぞれの修正方針を述べよ。
問4 社内文書を扱うRAGエージェントを構築するにあたり、文書には従業員の氏名・メールアドレスが含まれている。クローズドウェイトモデルのみを使う構成と、オープンウェイトモデルを併用するハイブリッド構成のそれぞれについて、利点とリスクを整理せよ。
参考文献・出典
Section titled “参考文献・出典”| 出典 | 内容 | 参照日 |
|---|---|---|
| Anthropic — Models Overview | Claudeモデルのコンテキストウィンドウ・最大出力 | 2026-07-29 |
| Anthropic — Pricing | 標準レート、プロンプトキャッシュ倍率、バッチAPI割引 | 2026-07-29 |
| OpenAI — API Pricing | GPT-5.6系の料金 | 2026-07-29 |
| OpenAI — Models | GPT-5.6系のコンテキストウィンドウ | 2026-07-29 |
| Google — Gemini API Pricing | Gemini系の料金 | 2026-07-29 |
| State of Open-Weight AI Models | オープンウェイトモデルのファミリーとライセンス状況 | 2026-07-29 |
| Vaswani et al., “Attention Is All You Need” (2017) | Transformerアーキテクチャの原論文 | — |
| roadmap.sh — AI Agents Roadmap | 章構成の基準 | 2026-07-29 |
次章予告: 第3章では、LLMを実際に使う上での基本的な選択肢を扱う。ストリーミング応答、推論モデルの使いどころ、ファインチューニングとプロンプトエンジニアリングの使い分け、埋め込みとベクトル検索、そしてRAGの基礎である。エージェントの設計判断に直結する内容である。
Built with Astro ・ Deployed on Cloudflare Pages
© 2026 watakumi — made with 💜 & ☕ ・watakumi.page