この記事をシェア
プロローグ：夜のサーバールームで始まったレクチャー
11月の夜、クラウド基盤のメンテナンスが一段落したオフィスに、入社1年目の新人エンジニア葵と、シニアの野口が残っていました。葵はAPI経由で呼び出す生成AIのパラメータ調整に頭を抱えています。
「先輩、temperatureとかtop_pとか、資料で読むだけだとピンと来なくて……」と葵。
野口はコーヒーを差し出しながら微笑み、「じゃあ今日は物語として覚えよう。三つの指輪を持つ召喚士の話だ」と語り始めました。
ここからは、葵が現場のAPI実装を任されるまでに理解した、temperature・top_p・max_tokensの実践知をストーリー仕立てで追いかけます。
Temperatureで創造性を操る：揺らぎの指輪
「最初の指輪はtemperatureだ」と野口。これはAIが次の候補語を選ぶ確率分布の温度を変える設定で、低くすると決まりきった回答、高くすると創造的な回答に振れます。
内部動作をざっくりイメージする
野口はホワイトボードに確率分布を描きながら説明します。「温度を下げると尖った山が立つ。つまり最も確率が高い語に集中して、毎回ほぼ同じ出力になる。逆に上げると山が平らになって、選択肢が広がるんだ。」
| Temperature | 出力傾向 | 一言で言うと |
|---|---|---|
| 0.0 | ほぼ決定論的（常に同じ答え） | 「正確だけど面白くない」 |
| 0.3 | 論理的・安定 | 技術文書やコードに最適 |
| 0.7 | バランス型 | 一般的な自然言語応答 |
| 1.0 | 創造的・遊び心あり | コピーライティングや詩など |
| >1.0 | カオス | ランダムすぎて品質が不安定 |
葵はテスト環境でtemperatureを0.2、0.7、1.0に変え、レスポンスの違いを確認。特に技術解説文で0.8にすると、余計な比喩が増えてしまうことを肌で感じました。
ユースケース別のおすすめ値
野口は続けて、プロジェクトでよく使う設定表を共有します。「実務では幅を決めておいて、案件に合わせて微調整するんだ。」
| ユースケース | おすすめTemperature | 理由 |
|---|---|---|
| コード生成 / 技術文書 | 0.2〜0.4 | 安定・再現性重視 |
| SEO向け記事 / HTML生成 | 0.4〜0.6 | 自然な多様性と一貫性のバランス |
| 文章リライト / 記事要約 | 0.5〜0.7 | 柔らかい言い回しに向く |
| キャッチコピー / 広告文 | 0.8〜1.0 | 想像力を発揮させたい |
| 詩・物語生成 | 1.0〜1.2 | 意図的な創造性重視 |
Top_pで候補を絞る：選抜の指輪
次の指輪はtop_p。野口は「核サンプリング（nucleus sampling）とも呼ばれるやり方だよ」と説明します。確率の高い語から順に合計がtop_pに達するまでを候補に残す仕組みです。
| 値 | 意味 |
|---|---|
| 1.0 | 全単語を対象（制限なし） |
| 0.9 | 上位90%の確率に含まれる語のみ |
| 0.7 | 上位70%の確率の語のみ（かなり安定） |
葵が「temperatureと一緒に動かすんですか？」と尋ねると、野口は即答。「どちらか一方で十分。ウチのチームはtop_pを1.0に固定し、temperatureだけ変える運用が多いね。」
| ユースケース | おすすめTop_p | 備考 |
|---|---|---|
| 安定出力・コード生成 | 0.6〜0.8 | 安定重視 |
| 一般対話 / 記事生成 | 0.9〜1.0 | 多様性も維持 |
| ランダム・発想系 | 1.0 | 制限なしでOK |
Max_tokensで長さを管理：器の指輪
最後の指輪であるmax_tokensは、AIが生成できる最大トークン数の上限を決定します。「入力と出力の合計がモデルのコンテキスト長を超えたらエラーになる。だから長文を扱うときは余裕を持たせるのが鉄則だよ」と野口。
| 出力タイプ | 目安トークン数 | 備考 |
|---|---|---|
| 一文要約 / キャッチコピー | 100〜300 | 数行レベル |
| コードスニペット | 500〜1000 | 小規模関数など |
| 一般記事 / HTML生成 | 2000〜4000 | 1ページ分のHTMLに相当 |
| 長文レポート / 記事 | 6000〜8000 | 3,000〜5,000文字程度 |
| 書籍級長文 | 10,000〜20,000 | 要長コンテキストモデル |
葵は社内ブログ生成用のAPI呼び出しでmax_tokensを3000に設定し、実際に出力が途中で切れないかを検証しました。ここで初めて、単なる数字ではなく「器の大きさ」であることを実感します。
3つのパラメータをどう組み合わせるか
野口は三つの指輪を机に並べるように表を描き、「原則はシンプルだ」とまとめました。
| パラメータ | 意味 | 低い値 | 高い値 |
|---|---|---|---|
temperature |
創造性・ランダム性 | 安定・論理的 | 自由・多様 |
top_p |
候補語の範囲 | 限定的・保守的 | 広範・多様 |
max_tokens |
出力量 | 短文 | 長文・詳細 |
一般的なチューニングの原則は以下の3ステップです。
temperatureを0.3〜0.7の範囲で調整し、文章の性格を整える。top_pは基本的に1.0固定。必要に応じて0.8前後まで絞る。- 十分な長文が必要なときだけ
max_tokensを積極的に増やす。
用途別おすすめセット：実務の現場メモ
葵が実際に社内プロジェクトで使う際の設定表をまとめたのがこちらです。案件の要件に応じて、そのままコピーしてもらえばすぐに検証できます。
| 用途 | temperature |
top_p |
max_tokens |
備考 |
|---|---|---|---|---|
| コード生成・技術回答 | 0.2〜0.4 | 1.0 | 1000〜2000 | 一貫性と正確性重視 |
| SEO向けHTML生成 | 0.4〜0.6 | 1.0 | 4000〜6000 | metaやOGを自然に生成 |
| ニュース記事要約 | 0.5 | 0.9 | 1500 | 簡潔で自然な文体 |
| キャッチコピー生成 | 0.8〜1.0 | 1.0 | 200〜500 | 創造性重視 |
| 商品説明文生成 | 0.5〜0.7 | 0.9〜1.0 | 2000 | バランス良く多様性を確保 |
| ストーリー / 物語生成 | 1.0〜1.2 | 1.0 | 5000〜8000 | 自由な発想を許容 |
API実装の現場ノート：Fireworks.aiの例
最後に、葵が翌週のレビューで提出したAPIリクエスト例を共有します。OpenAI互換のFireworks.aiをPHPで呼び出すケースです。
$payload = [
"model" => "accounts/fireworks/models/llama-v3p1-70b-instruct",
"messages" => [
["role" => "system", "content" => "あなたはSEOに詳しいWebライターです。"],
["role" => "user", "content" => "以下の本文をSEO対応HTMLに変換してください。 ..."]
],
"temperature" => 0.5,
"top_p" => 1.0,
"max_tokens" => 5000,
"stream" => false
];
レビューでは「temperatureを0.5にした理由は？」「max_tokens5000でコストに影響は？」といった問いに、葵がストーリーで学んだ知識を交えながら堂々と回答しました。
エピローグ：三つの指輪を託されて
レクチャーの最後、野口はこう締めくくりました。「パラメータを理解することは、モデルそのものを理解する近道だよ。数値の裏にある確率と制御の仕組みを意識しよう。」
葵はノートを閉じ、APIコンソールに向かいながら、「これで次の案件も怖くない」と呟きます。三つの指輪──temperature、top_p、max_tokens──は、もう単なる数字ではなく、出力品質を自在に操るための相棒になりました。
