LLM temperatureとは？温度設定とパラメータ数の違いを解説

70Bの大規模言語モデル（LLM）には、約700億個の学習済みパラメータがあります。一方、LLM temperature（温度）を0.2に設定すると、対応するAPIでの回答のサンプリング方法が変わるだけで、モデルの重みの数は変わりません。つまり、LLMの「パラメータ」は、どのモデルを使うかと、どのように出力を求めるかという、異なる判断に関わります。まず用途に合うモデルを選び、そのAPIとバージョンが対応する項目だけを設定しましょう。

2026年10月25日時点の各社の公開ドキュメントで確認済みです。 この区別は、以前にも増して重要になっています。現在のAPIには、サンプリング設定を指定するとエラーになるものもあれば、受け付けても無視するものもあります。設定のひな型をそのままコピーすると、リクエストが失敗したり、変更が何の効果も持たなかったりします。

LLMのパラメータには、モデルと生成を左右する別々の役割があります

モデルパラメータは学習済みモデルの一部です。生成パラメータは、モデルに送るリクエストの設定です。 後者を変えても、前者が再学習されるわけではありません。

建物で考えてみましょう。荷重を支える構造が建物の耐えられる重さを決め、可動式のルーバーが空間の使い方を調整します。ルーバーを動かしても、階数は増えません。同じように、temperatureを変えても、小さなモデルが大きなモデルに変わることはありません。

LLMでいう「パラメータ」とは何ですか？

モデルの規模を表す場合、パラメータとは、モデル内部の計算を形づくる学習済みの数値を指します。主なものは重みです。学習では、データを使ってこれらの値を調整します。一方、APIの話では、出力の生成に影響する設定も「パラメータ」と呼ばれます。IBMの解説でも、学習によって得られた値と、外部から指定する設定を区別しています。

提供元が「このモデルはパラメータが多い」と言えば、モデルそのものの話です。開発者が「請求書の情報抽出用にパラメータを変えよう」と言えば、おそらくリクエスト設定を指しています。どちらも、そのまま性能の話として受け取る前に、何を指しているのかを確認する必要があります。

学習済みパラメータの1個は、何を表していますか？

学習済みパラメータの1個は、ネットワーク内部で使われる数値です。たとえば、ある内部信号が別の信号にどの程度影響するかを変える重みがこれに当たります。名前の付いた事実や文書、単語が、それぞれ専用の引き出しに格納されているわけではありません。

さらに別の分類として、学習のハイパーパラメータがあります。学習率のように、学習の進め方を制御する設定です。既存のモデルを呼び出す業務アプリケーションは、通常、こうした学習設定も、学習済みの重みも操作しません。

トークンも、パラメータとは別のものです。 入出力のテキストを分割した単位で、単語の一部分になることもよくあります。プロンプトのトークンが増えても、モデルのパラメータが増えるわけではありません。この単位についてはAIのトークン解説を、学習済みの重みを変えずに指示で振る舞いを導く方法についてはシステムプロンプトの解説を参照してください。

第1部：LLMのパラメータ数からモデルの規模を読み取る

パラメータ数は、保存容量や計算量を見積もる手がかりになります。ただし、それだけで業務に最適なモデルは選べません。 インフラ計画の出発点として使い、最後は実際のタスクで評価しましょう。

LLMの「数十億パラメータ」とは、どのような意味ですか？

「B」は、学習済みの値が10億個あることを示すbillionの略です。70Bと表記されたモデルには、約700億個のパラメータがあります。「T」はtrillion、つまり1兆です。公表されるモデル名では数が丸められていることもあるため、導入に必要なリソースを正確に見積もるには、実際のチェックポイントと保存形式を確認する必要があります。

パラメータ数が同じでも、アーキテクチャ、学習データ、学習方法、得意分野は異なり得ます。同じモデルでも、各重みの保存に使う精度によって、必要なメモリ容量は大きく変わります。

業務でモデルを選ぶ際に確認したいのは、合格基準を満たすかどうかです。請求書の合計金額を正しく抽出できるか、顧客IDを正確に保てるか、必要なチェックに通るパッチを生成できるか。パラメータ数の大小だけでは、こうした問いには答えられません。

70Bモデルの重みに必要なメモリを計算する

重みそのものの保存容量は、パラメータ数に、1パラメータ当たりのバイト数を掛けた値です。 重みがちょうど700億個ある仮想のモデルで計算すると、次のようになります。導入環境で測定した結果ではなく、単純な計算例です。

ここでのGBは10進数のギガバイトです。140 GBは、一部のメモリ表示ツールが使う2進数の単位では約130.4 GiBに当たります。換算で変わるのは単位であり、モデルではありません。

Hugging Faceのドキュメントでは、重みを低い精度で保存する量子化により、精度の維持を図りながらメモリ要件を減らす仕組みを説明しています。形式ごとの違いとトレードオフは、LLM量子化ガイドで解説しています。

プロンプトの長さや同時リクエスト数によっても、モデルを提供する際の負荷は変わります。Hugging Faceのモデルメモリ見積もりツールのドキュメントでも、モデルの読み込みと、回答を生成する推論の実行は明確に区別されています。

パラメータ数からコストと品質はどこまで分かりますか？

ほかの条件が同じなら、重みが多いほど、保存と実行に必要なリソースも通常は増えます。 ただし、「ほかの条件が同じ」という前提には注意が必要です。精度、アーキテクチャ、ハードウェア、バッチ処理、処理するテキスト量によって結果は変わります。

セルフホスティングでは、パラメータ数をハードウェアの候補選びに使えます。ホスト型APIでは、パラメータ数だけで請求額は計算できません。料金を決めるのは、提供元の課金ルールと実際の処理内容です。また、一見効率のよいモデルでも、何度も再試行したり、人が大幅に修正したりする必要があれば、運用には向かない可能性があります。

品質については、モデルの規模を能力の手がかりとして捉え、点数のようには扱わないでください。調達時に求めるべきなのは、代表的な入力に対する結果、失敗例、評価条件です。非公開モデルのパラメータ数について、出典のない推定値を性能の根拠として受け入れるべきではありません。

MoEモデルの総パラメータ数とアクティブパラメータ数の違い

総パラメータ数はモデル全体を、アクティブパラメータ数は1トークンの処理に使われる計算経路について公表された規模を表します。 Mixture of Experts、通常MoEと略されるモデルでは、どちらの数も重要です。

MoEは、エキスパートと呼ばれるサブネットワークと、各トークンをどのエキスパートで処理するか選ぶルーターから構成されます。この「エキスパート」は数学的な構成要素であり、経理や法務を担当させられる専門家ではありません。一部だけを有効にすれば、モデル全体を動かす場合に比べて計算量を減らせますが、残りの重みもどこかに保持する必要があります。PyTorchのMoE解説では、ルーティングと、それに伴う通信について説明しています。

「アクティブ104B」には、開発元が公表した具体例があります。Moonshot AIのKimi K3.1 Pro発表では、総パラメータ数は2.8T、アクティブパラメータ数は104Bとされています。総数を2,800Bに換算すると、104 ÷ 2,800で、アクティブな割合は約3.7%です。この割合は公表値を基に本記事で計算したもので、高速化の実測値でも、品質の順位でもありません。

別の例として、QwenのQwen3-235B-A22Bモデルカードには、総数235B、アクティブ22Bと記載されています。図では、使われていない部屋も見えるようにしています。あるトークンが別の経路を通っても、残りの重みを保存する必要はなくならないためです。

導入時には、モデル全体をどう保存・分散するのか、エキスパートをハードウェアにどう配置するのか、実際の同時実行数でどの程度の性能が出るのかを確認してください。アクティブパラメータ数は、GPUの必要メモリ量を示す仕様ではありません。こうしたインフラ上の論点は、Mixture of Expertsの解説でさらに詳しく扱っています。

第2部：LLM temperatureなどの生成パラメータで応答を調整する

生成設定は、モデルが持つ能力の範囲内で、選択の仕方や生成を止める条件を変えます。 APIは、アプリケーションが応答を求めて呼び出すインターフェースです。設定を変えても、欠けている資料を補ったり、曖昧な指示を直したり、正しい回答を保証したりはできません。

Temperature：候補の選ばれやすさを調整する

Temperatureは、次のトークンを選ぶときの確率分布を変えます。低くすると確率の高い候補がより選ばれやすくなり、高くすると出力に幅が出ます。表現の一貫性を重視するか、多様な下書きを得たいかに応じて使う設定です。

請求書を扱う処理では、通常、表現の多様さは目的ではありません。一方、キャンペーンの見出し案をいくつも出す場合には役立つことがあります。ただし、temperatureを下げても、捏造された請求書番号が正しくなるわけではありません。上げても、知識が増えるわけではありません。

Temperatureをゼロにしても、常に同じ結果が得られるとは限りません。Anthropicの用語集でも、temperatureがゼロで入力が同じでも、結果が異なる場合があると明記されています。再現性は、推論を提供するシステム全体で評価する必要があります。

Top-p：候補として残す範囲を決める

Top-pは、nucleus samplingとも呼ばれ、累積確率を基準に候補を絞ります。指定するのは確率のしきい値であり、候補の個数でも、語彙全体に対する割合でもありません。

説明用に、次のトークンの確率が0.60、0.25、0.10、0.05だとします。Top-pを0.9にすると、上位3候補が必要です。上位2候補の合計は0.85ですが、上位3候補では0.95に達するためです。これは仕組みを説明するための数値であり、モデルの出力を観測した結果ではありません。

Temperatureは確率分布の形を変え、top-pは選択対象となる候補を絞ります。業務向けの初期設定では、サンプリング項目を一度に1つずつ変えましょう。これは、OpenAIのChat Completionsリファレンスの推奨にも沿っています。

LLMのトークン上限：指定するのは長さではなく上限です

生成トークン数の上限は、応答の最大量を制限する設定です。その数ちょうどのトークンを使うよう求めるものではなく、会話を扱える容量であるコンテキストウィンドウを広げるものでもありません。

上限が小さすぎると、JSONオブジェクト、文、コードのパッチが途中で切れることがあります。逆に、大きな上限を指定すれば有用な回答になるわけでもありません。希望する長さはプロンプトで伝え、結果を最後まで生成できる余裕を上限に持たせてください。

推論を行うモデルでは、さらに区別が必要です。OpenAIのResponsesリファレンスでは、出力上限に、表示される出力と推論トークンの両方が含まれるとしています。AnthropicのMessagesリファレンスも、思考トークンをmax_tokensに算入します。許可したトークンがすべて最終回答に現れる前提で、推論リクエストの予算を組まないでください。

停止シーケンス：確実な区切りで生成を終える

停止シーケンスは、指定した文字列が現れたときに生成を終了する仕組みです。本文には現れない明示的な終了マーカーなど、アプリケーションで確実な区切りを定義できる場合にだけ使います。

複数行のレポートで、改行を汎用的な停止条件にするのは適切ではありません。入れ子になったJSONで閉じ波括弧を停止条件にするのも同様です。最初に一致した括弧で、応答が早く終わりすぎる可能性があります。構造化データの抽出では、提供元が対応するスキーマ指定の仕組みを優先し、返された各フィールドを検証してください。

通常は、独自の停止条件を指定せずに始めるのが妥当です。その場合も、出力トークン数の上限と結果の検証は必要です。

ペナルティ：反復を抑える設定は慎重に使う

Presence penaltyは、トークンがすでに登場したかどうかに応じて働きます。Frequency penaltyは、その登場回数に応じて働きます。対応するエンドポイントでは、正の値で再利用を抑え、負の値で再利用を促すことができます。

同じ文字列の繰り返しが、常に問題とは限りません。商品コード、顧客名、JSONのキー、プログラムの識別子などは、正確に繰り返す必要があります。そこにペナルティをかけると、タスクの目的に逆行しかねません。

情報抽出やコード生成は、反復ペナルティなしで始めてください。文章の下書きでは、まず単調な反復構成を招く指示を修正します。それでも必要なら、対応範囲内の小さなペナルティを試し、必要な用語を変えずに文章が改善するかを確認します。Googleの生成リファレンスでも、負のfrequency penaltyは、同じトークンを繰り返すループを引き起こす可能性があると警告しています。

OpenAI・Anthropic・GoogleのAPIで使える範囲とデフォルト値

送信できる設定は、エンドポイント、モデル、APIバージョンで決まります。 SDKで同じフィールド名が使われていても、各社が同じ制御を実装しているとは限りません。

下の表は、OpenAIのChat Completions、AnthropicのMessages APIバージョン2026-10-21、Googleの**Gemini Developer APIのgenerateContent**を対象としています。GoogleのVertex AIやInteractions APIの設定を当てはめたものではありません。

NSは、参照した現行のフィールド説明に、数値の範囲またはデフォルト値が明記されていないことを表します。 ゼロ、無制限、非対応という意味ではありません。また、下記の「省略」はアプリケーション側への助言であり、提供元のデフォルト値を推測して示したものではありません。

出典：OpenAIのリクエストスキーマ、Anthropicのリクエストスキーマ、Anthropicのバージョン移行ガイド、Googleの生成スキーマ、Googleのモデルメタデータ、Googleのtop-pの範囲。

Googleの一般的なトラブルシューティング表は、生成フィールドのリファレンスより狭いtemperatureの範囲を示しています。フィールドのリファレンスと、選んだモデルのmaxTemperatureを併せて確認してください。モデルごとの値には、Model.temperature、Model.topP、Model.outputTokenLimitを使います。サンプルリクエストの値を、公式のデフォルト値として扱わないようにしましょう。

OpenAI：まず推論設定との互換性を確認する

OpenAIの現行のGPT-6ガイドでは、推論の労力設定がnone以外の場合、temperatureとtop_pを削除するよう指示しています。GPT-6 AstraとGPT-6.1 Solはnoneに対応していません。GPT-6 SolとGPT-6 Lunaは対応しています。これは対応可否に関する制約であり、temperatureが特定の数値に固定されると説明したものではありません。

エンドポイントによる違いもあります。**Responsesで使うのはmax_output_tokens**で、現行スキーマの最小値は16です。数値のデフォルトと、全モデルに共通する最大値は記載されていません。また、生成リクエストのスキーマには、Chat Completionsのstop、presence_penalty、frequency_penaltyに相当するフィールドがありません。Chat Completionsのリファレンスでは、o3とo4-miniはstopに非対応と明記され、max_tokensは非推奨となっており、代わりにmax_completion_tokensを使います。

実務では、選んだエンドポイントに合わせてリクエストを組み立て、そのうえでモデルごとの互換性ルールを適用します。表の項目をすべて1つのリクエストにコピーしないでください。

Anthropic：APIバージョンによって設定項目が使えなくなる

Anthropicの10月21日の移行ガイドでは、APIバージョン2026-10-21でtemperature、top_p、top_kを送信すると、デフォルト値を指定していても400エラーになると説明しています。省略時の動作では、temperatureは1.0になります。

古いAPIバージョンに戻せば、すべてのモデルで自由に設定できるわけでもありません。Anthropicの思考機能のドキュメントによると、Claude Sonnet 5.5などのモデルは、思考機能の有効・無効にかかわらず、デフォルト以外のサンプリング値を拒否します。これらのモデルのtop-pのデフォルトは0.99とされ、1は拒否すると明記されています。以前の一般的な設定範囲を、こうしたモデル固有のルールより優先することはできません。

実際に回答を生成するには、モデルの上限内で正のmax_tokens予算を指定してください。ドキュメント上の最小値であるゼロは、回答を生成せずにキャッシュを事前準備するためのものです。情報抽出の初期設定には適しません。

Google：受け付けられた設定が、実際には効かないこともある

GoogleのGemini 3.6 Flashおよび3.5 Flash-Liteの移行ガイドによると、これらのモデルは、非推奨となったtemperature、top-p、top-kの設定を無視します。開発者にはこれらの項目を削除するよう求めており、将来世代のモデルでは400エラーで拒否すると説明しています。

これは、リクエストが拒否される場合とは異なる失敗の仕方です。アプリケーション上ではtemperatureの変更が受け付けられたように見えても、モデルの動作はまったく変わらないことがあります。正常に応答が返ったことを、その設定が効いた証拠とみなす前に、選んだモデルのドキュメントを確認してください。

業務タスクで試す初期設定

まず、提供元が対応する動作を基準にし、成功を測れる形で定義してください。 以下の数値は、設定を調整できるエンドポイントに向けた、本記事の出発点としての提案です。提供元のデフォルト値でも、測定で得た最適値でも、どこでも使えるプリセットでもありません。前述の互換性ルールを優先してください。

情報抽出：元の値を正確に守る

請求書の項目抽出、サポートチケットの分類、契約書のメタデータ抽出では、対応している場合に限り、temperatureを0または0.2で試してください。Top-pは変更しません。独自の停止条件と反復ペナルティは省略します。対応するOpenAI Chat Completionsモデルなら、両方のペナルティを明示的に0に設定する方法でも、ペナルティなしの基準を定義できます。

現行のAnthropicへのリクエストと、前述のGemini Flashモデルでは、サンプリング設定を省略します。フィールドの明確な定義、許可する分類、欠損データの例、提供元が対応する構造化出力機能を使ってください。形式が正しいかどうかとは別に、結果の内容も検証します。

短いレコードの抽出なら、対応する非推論リクエストで、出力上限1,000トークンを初期の実験値にできます。あらゆる用途に適した上限ではありません。途中で切れていないか、実際にどれだけ使ったかを確認し、推論を使う場合にはその分を別途見込んでください。存在しない請求書番号を作らせず、値がないことを示すマーカーを返すよう求めます。

合格基準： 必須フィールドがすべて存在し、値が元資料と一致し、元にない情報は欠損のままであることです。JSONとしての検証に通るだけでは不十分です。

文章の下書き：事実を保ちながら表現に幅を持たせる

営業メールや商品説明文では、まずモデルが対応するデフォルトの動作から始めます。調整可能なエンドポイントなら、top-pを変えずに、temperature 0.7の場合と比較してください。プロンプトには、読者、長さ、文体、必ず含める事実、記載してはいけない主張を指定します。

最初はペナルティを指定しません。対応するOpenAI Chat Completionsモデルが、不要な言い回しを何度も繰り返す場合は、frequency penalty 0.2を試せます。これは、公開された範囲内での控えめな調整です。レビューで改善が確認できた場合にだけ残してください。必要な商品名は正確に保つ必要があります。

サンプリング設定が廃止されたモデルでは、「簡潔に事実を伝える案」と「ストーリーとして展開する案」のように、異なる書き方を明示的に求めます。実際にできた文章を見て、違いを評価してください。

合格基準： 新たな事実関係の主張を加えず、有用な表現の違いが生まれていることです。「意外性がある」と「業務に役立つ文章である」は同じではありません。

コード生成：最後まで出力できる予算を確保し、動作を確認する

限定された修正パッチを、調整可能なエンドポイントで作る場合は、temperature 0または0.2を比較の基準にできます。推論モデルでは、そのモデルが対応する設定に従い、非対応のサンプリング項目を省略してください。検証済みのプロトコルで必要とされる場合を除き、反復ペナルティと独自の停止条件も指定しません。

関連するコード、制約、期待する動作を渡します。パッチ全体を生成できるだけの出力枠を確保してください。応答が上限に達した場合は、見えている部分を安全に適用できると考えず、未完成の結果として扱います。

合格基準： パッチが仕様を満たし、適切なチェックに合格することです。コード内で識別子が繰り返されるのは正常です。また、もっともらしい回答が返ったことは、動作する証拠にはなりません。

パラメータ数や生成設定だけでは保証できないこと

1つの数値だけで評価を代用できる、という考えは過大評価です。 その数値が重みの数でもtemperatureでも、評価の代わりにはなりません。

大きなモデルが、特定の業務で必ず優れているとは限りません。MoEのアクティブパラメータ数が小さくても、その分のメモリだけでモデル全体を保持できるわけではありません。低いtemperatureは正しさを保証しません。大きな出力上限も、論旨が最後まで展開される保証にはなりません。API呼び出しが成功しても、送信した設定がすべて適用された証拠にはなりません。

有効な判断材料は、代表的な入力、明確な成功条件、内容を確認した結果です。サービスを購入するなら、実際に使う設定で業務フローを実演してもらってください。開発するなら、モデル、エンドポイント、APIバージョン、プロンプト、設定を記録し、振る舞いが変わった際に何が変化したのかを追えるようにします。

購入担当者・運用担当者・開発者が次に取り組むこと

購入担当者は成果を比較し、運用担当者は失敗を定義し、開発者は非対応の設定を取り除きます。 この役割分担は、共通の小さな評価セットを使って実践できます。

ホスト型サービスを選ぶ場合、必要な結果が得られると実証されていれば、パラメータ数が分からなくても検討を進められます。セルフホスティング用のハードウェア購入は、チェックポイント全体、精度、処理負荷を見積もってからにしてください。すでに業務フローが問題なく動いているなら、別のモデルがより大きな数値を売りにしているという理由だけで、置き換える必要はありません。

モデルやAPIバージョンを変更する開発者は、互換性の確認にすぐ取り組むべきです。生成設定が公開されていないマネージドインターフェースを使う運用担当者は、リクエストのフィールド構文の影響をほとんど受けませんが、出力の検証は必要です。

1. 1

   必ず成功させたい処理を集める

   次の月曜日に、1つの業務フローから代表的な事例を20件集めてください。不完全な入力、曖昧な入力、極端に長い入力も含めます。モデルを比較する前に、期待する結果やレビュー基準を書き出してください。

2. 2

   リクエストの設定を明確にする

   エンドポイント、モデル、APIバージョンを記録します。対応する設定を確認し、それ以外は取り除き、完全な結果を生成できる出力予算を選びます。必要な用語や、データが欠けている場合の扱いは、プロンプトに記載してください。

3. 3

   1つだけ変えて結果を評価する

   基準となる設定と、対応する項目を1つだけ調整した設定を比較します。情報抽出では元資料との一致を、下書きでは事実の正確さと有用性を、コードでは動作とチェック結果を確認してください。変更の効果が認められない限り、より単純な設定を維持します。

よくある質問

LLMのtemperatureは、どのように働きますか？

次のトークンの確率分布が、どの程度一部の候補に集中するかを変えます。低い値では確率の高い候補が選ばれやすくなり、高い値では多様な候補が選ばれます。変わるのはサンプリングであり、学習済みの重みではありません。また、現在のAPIには、この設定を拒否または無視するものもあります。

70Bモデルには、どのくらいの容量が必要ですか？

重みがちょうど700億個ある場合、重みのみの保存容量は、16ビットで約140 GB、8ビットで70 GB、4ビットを理想的に格納した場合で35 GBです。これらは10進数での値で、実行時のメモリや量子化のオーバーヘッドは含みません。導入に必要なリソースは、実際のチェックポイントと処理内容で決まります。

パラメータの4つの種類とは何ですか？

LLMに共通する、普遍的な4分類はありません。理解のためには、学習済みモデルパラメータ、アーキテクチャの設定、学習の設定、生成の設定という区別が役立ちます。これはシステムを理解するための分類であり、すべてのAPIに設定項目が4つあるという意味ではありません。

GPTとLLMの違いは何ですか？

LLMは大規模言語モデルを意味する広い分類です。GPTはgenerative pretrained transformerの略で、その分類に属する特定のモデル群と手法を指します。ほかの言語モデル群もLLMに含まれます。

LLMの4つの種類とは何ですか？

標準となる唯一の4分類はありません。DenseとMixture of Expertsの違いはアーキテクチャを、重みが公開されているか非公開かの違いは利用可能性を表します。それぞれ別の問いに答える区別であり、組み合わせて品質の順位とみなすべきではありません。

ChatGPTはLLMですか、それともAIですか？

ChatGPTは、モデルを利用するAIアプリケーションです。アプリケーション、その中で選択されるモデル、開発者が使えるAPI設定は、それぞれ異なる層として区別してください。

LLMを使わないAIには、どのようなものがありますか？

AIは、言語モデルより広い概念です。不正検知の分類器やコンピュータービジョンのシステムは、LLMを使わずに機械学習の手法を利用できます。パラメータ数という考え方も、言語モデルだけのものではありません。

最も賢いLLMはどれですか？

パラメータ数から、用途を問わず最良だと決められるモデルはありません。実際の業務を代表する事例を使い、同じ合格基準と記録した設定の下でモデルを比較してください。1つのベンチマーク結果だけで、あらゆる業務への適性は判断できません。

LLMはAIのどの分野に属しますか？

LLMは、言語の処理や生成に使われる深層学習モデルです。学習済みパラメータはモデルの一部であり、temperatureなどのリクエスト設定は、アプリケーションがそのモデルをどう使うかに関わります。

AIシステムの仕組みと、その利用に関わる判断を実務の視点で知りたい方は、ニュースレターにご登録ください。