はじめに

先日、AWS Certified AI Practitioner（AIF-C01） を受験し、無事合格することができました。

試験勉強をしている中で、Amazon Bedrockをはじめとした生成AIに関するさまざまな用語が登場しますが、その中でも個人的に最初は違いが分かりづらかったのが、生成結果のランダム性や多様性を調整する以下の3つのパラメータです。

Temperature（温度）
Top P（トップP）
Top K（トップK）

上記は試験対策として以下のように覚えることができると思います。

Temperature：ランダム性や創造性をコントロールする
Top P：確率で候補を絞る
Top K：候補数で絞る

ただ、言葉だけだとピンと来ず「実際に値を変えると何が変わるのか？」まではなかなかイメージできませんでした。

そこで今回は、Amazon BedrockのPlaygroundを使い、同じプロンプトに対してTemperature・Top P・Top Kを変更すると生成結果がどのように変化するのか を実際に試した結果を残します。

AWS Certified AI Practitionerを勉強している方の理解の助けになれば幸いです。

Amazon Bedrockの推論パラメータとは

検証に入る前にAmazon Bedrock上の推論パラメータについて触れておきます。
まず、生成AIは文章を一度にすべて生成しているわけではなく、生成途中の文章に対して「次にどのトークンが来る可能性が高いか」という確率分布を計算しながら出力を生成していきます。

Amazon Bedrockでは、モデルが次のトークンを選択するときのランダム性や候補範囲を調整するために、Temperature・Top P・Top Kなどの推論パラメータを利用できます。

まずは3つの違いを簡単に整理します。

パラメータ	何を調整するか	小さい場合	大きい場合
Temperature	確率分布の形	高確率の候補が選ばれやすい	低確率の候補も選ばれやすい
Top K	候補の個数	候補が少ない	候補が多い
Top P	候補の累積確率	候補が限定される	より多くの候補が残る

個人的には、試験対策として次のように覚えると分かりやすいと思います。

Temperature = 確率分布の形を変える
Top K = 個数で絞る
Top P = 確率で絞る

それぞれもう少し詳しく見てみます。

Temperature（温度）とは

AWSの公式ドキュメントには、以下の記述があります。

[温度] — 予測出力の確率分布の形状に影響し、モデルがより確率の低い出力を選択する可能性にも影響します。

確率の高い出力を選択するには、モデルに影響する値を低く設定します。
確率の低い出力を選択するには、モデルに影響する値を高く設定します。

ちょっと分かりづらかったので以下のように理解しています。

Temperatureを低くすると確率分布が急になり、高確率の候補が選択されやすくなる
逆に高くすると確率分布が平坦になり、もともとの確率が低かった候補も選択されやすくなる

例えば、次のトークン候補が以下だったとします。

次のトークン候補	確率
AWS	50%
Amazon	25%
クラウド	15%
宇宙	7%
ペンギン	3%

Temperatureが低ければ、次のように高確率の候補がより選ばれやすくなります。

AWS >>> Amazon > クラウド >>> 宇宙・ペンギン

一方、Temperatureを高くすると候補間の確率差が小さくなり、「宇宙」や「ペンギン」のような低確率の候補が選ばれる可能性も高くなります。

その結果として、次のように理解できます。

Temperatureが低い → 安定した、予測しやすい回答

Temperatureが高い → 多様で、意外性のある回答

Top Kとは

Top Kは非常に分かりやすく、次のトークンとして考慮する候補を「上位何個まで」にするか を指定します。

例えば先ほどの候補に対して、次のように設定した場合を考えます。

Top K = 3

このとき残るのは上位3候補だけで、4位以下は候補から外れます。

次のトークン候補	確率	Top K = 3 のとき
AWS	50%	残る
Amazon	25%	残る
クラウド	15%	残る
宇宙	7%	除外
ペンギン	3%	除外

つまり非常にシンプルに、次のように覚えることができます。

Top K = 候補を個数で絞る

Top Pとは

AWSの公式ドキュメントには、以下の記述があります。

[トップ P] — モデルが次のトークンについて考慮する最も可能性の高い候補のパーセンテージ。

小さい値を選択するとプールのサイズが小さくなり、選択肢がより可能性の高い出力に限定されます。

大きい値を選択するとプールのサイズが大きくなり、モデルが可能性の低い出力を考慮できるようになります。

専門用語で言うと、このモデルはレスポンスのセットの累積確率分布を計算し、分布の上位 P% のみを考慮します。
例えば、[トップ P] に 0.8 の値を選択した場合、モデルはシーケンスにおいて次に来る可能性が最も高い 80% のトークンの確率分布から選択します。

分かりづらいのですが、Top PはTop Kとは異なり、
確率の高い候補から順番に足していき、累積確率が指定した値に達する範囲を候補とする方式 となります。

ここで、次のように設定したとします。

Top P = 0.75

先ほどと同じ候補について、確率を上から順に足していくと次のようになります。

次のトークン候補	確率	累積確率	Top P = 0.75 のとき
AWS	50%	50%	残る
Amazon	25%	75%	残る
クラウド	15%	90%	除外
宇宙	7%	97%	除外
ペンギン	3%	100%	除外

累積確率が75%に達するまでの「AWS」「Amazon」の2つが候補として残り、その中から次のトークンが選ばれます。

Top Kとの違いを整理すると、次のとおりです。

Top K
→ 候補の「個数」で制限

Top P
→ 候補の「累積確率」で制限

試験ではこの違いを押さえておくと理解しやすいと思います。

Amazon Bedrock Playgroundで試してみる

ここから実際にAmazon Bedrockで試してみます。

Amazon Bedrockには、AWSマネジメントコンソール上から基盤モデルに直接プロンプトを入力して結果を確認できるPlaygroundが用意されています。

本記事にて使用するモデルは東京リージョン（ap-northeast-1）では提供されていないため、オレゴン（us-west-2）に変更しておいてください。

AWSコンソールより「Amazon Bedrock」を開いて左側のメニューから「Playground」を選択
「Select a model to get started」よりモデルを選択を押下
「モデル選択」画面から今回使用するモデルを選択する。

今回使用するモデル

今回は、Mistral AI / Mistral 7B Instruct を使用します。
このモデルを選んだ理由は、今回比較したい以下の3パラメータすべてに対応しているためです。

temperature
top_p
top_k

日本語に強いモデルでの検証もしたかったのですが、（Claude Haiku 4.5 や Amazon Nova Lite等）特定のパラメータが自由に変更できないといった制約があったため、コンソールでサクッと操作できるという意味でも当該モデルにしています。

AWSの公式ドキュメントに記載されている Mistral 7B Instruct の設定値は以下になります。

パラメータ	デフォルト	最小	最大
Temperature	0.5	0	1
Top P	0.9	0	1
Top K	50	1	200

Amazon Bedrockの利用料金について

実際にPlaygroundを使用する前に、料金についても触れておきます。

「Playground」という名称から無料のお試し環境のようにも見えますが、無料で何度でもモデルを実行できる機能というわけではないため実施される際はご注意ください。
Amazon BedrockのPlaygroundでモデルを実行すると、モデルの推論利用に応じて料金が発生する可能性があります。

Amazon Bedrockの料金は、使用するモデルやリージョン、利用方法などによって異なります。

テキスト生成モデルのオンデマンド推論では、モデルによって主に以下のような利用量をもとに料金が計算されます。

入力したプロンプトのトークン数
モデルが生成した出力のトークン数

参考：

今回使用するMistral 7B Instructの費用感

AWS公式の料金ページには、Mistral 7B をオンデマンドで利用した場合の計算例が載っています。
2,000トークンを入力して1,000トークンを出力するケースです。

内訳	計算式	金額
入力	2,000 / 1,000 × 0.00015 USD	0.0003 USD
出力	1,000 / 1,000 × 0.0002 USD	0.0002 USD
合計	―	0.0005 USD

1回あたり 0.0005 USD なので、日本円にすると1円にも届きません。
今回のように短い文を十数回生成する程度であれば、金額を気にせず試せる水準です。

ただし、これはあくまで Mistral 7B の場合です。
同じページに載っている Mistral Large の例では、同じトークン数で 0.04 USD と80倍の開きがあります。
どのモデルを選ぶかで金額は大きく変わる、という点は頭に入れておいた方がよさそうです。

なお、料金はモデル、リージョン、サービスTier、料金改定などによって変わる可能性があるため、実際に試す際は必ず最新の Amazon Bedrock の料金を確認してください。

検証方法

共通のプロンプトを利用して、Temperature、Top P、Top Kを変更した際、どれだけ変化があるかをチェックしてみたいと思います。
それぞれの条件で複数回実行して傾向を確認します。

プロンプト（全検証共通・1種類）

Continue this sentence in one sentence:
The engineer opened the terminal and immediately regretted it, because

日本語訳

この文に続く一文を書いてください：
エンジニアはターミナルを開き、そしてすぐに後悔した。なぜなら

「日本の首都は？」のような正解がほぼ決まっている質問では、設定値を変更しても回答内容の差が分かりにくいため、意図的に ある程度自由度の高い文章生成タスク にしました。
また、because で終えているのは、続く内容が常識で決まらないようにするためです。

なお、Mistral 7B Instruct は日本語生成が弱いため、プロンプトは英語にしています。

検証マトリクス（全14回）

最大出力トークン数（Maximum output tokens）は「128」で共通にしました。
以下の表では、その検証で 変化させたパラメータを太字 にしています。

■ 検証1：Temperature を変える（Top P と Top K は固定）

Temperature	Top P	Top K	回数
0.2	1.0	200	2
0.6	1.0	200	2
1.0	1.0	200	2

■ 検証2：Top P を変える（Temperature と Top K は固定）

Temperature	Top P	Top K	回数
1.0	0.1	200	2
1.0	1.0	200	2

■ 検証3：Top K を変える（Temperature と Top P は固定）

Temperature	Top P	Top K	回数
1.0	1.0	5	2
1.0	1.0	200	2

検証1：Temperature を変える

まず基準となる Temperature 0.2 の出力です。
2回とも「エラーメッセージが押し寄せ、致命的なシステム障害を示していた」という同じ内容で、違いは真ん中あたりの表現だけでした。

1回目の出力
the flood of error messages and warning alarms assaulted his senses, indicating a catastrophic system failure.

2回目の出力
the flood of error messages and warning lights illuminated the room, indicating a catastrophic system failure.

続いて Temperature 0.6 の出力です。
ここで急に、エラーメッセージではなく「コンパイルを始めるコマンドを打ち込んだ」という別の話になりました。

1回目の出力
entered a complex sequence of commands to initiate the compilation of the software code.

2回目の出力
typed in a complex command to initiate the compilation of the software code.

最後に Temperature 1.0 の出力です。

1回目の出力
because a torrent of error messages scrolled down the screen,
each one more alarming than the last.

2回目の出力
the flood of error messages and warning signs filled the screen,
indicating a major system malfunction that would take hours to troubleshoot
and potentially result in significant downtime for the company.

気づいたこと

上げれば上げただけ変化する、という単純な結果にはなりませんでした。

まず内容です。
0.2 と 1.0 の4回は、すべて「エラーメッセージが押し寄せる」という同じ出だしでした。
Temperature を5倍にしたのだから、「上げると創造的になる」という説明どおり突拍子もない展開が出てくるのではと期待していたのですが、そうはなりませんでした。

意外だったのは、間に挟んだ 0.6 です。
2回とも「複雑なコマンドを打ち込んでコンパイルを始めてしまった」という、エラーメッセージが一切出てこない別の理由を返してきました。
最も高い 1.0 ではなく、真ん中の 0.6 で内容が飛んだことになります。

次に文の長さです。

Temperature	1回目	2回目
0.2	16語	16語
0.6	14語	13語
1.0	17語	31語

最長の31語はたしかに 1.0 で出ました。
この回は「復旧に何時間もかかり、会社に大きなダウンタイムをもたらす可能性がある」と、聞いてもいない先の展開まで書き足しています。
ただし 0.6 は 0.2 より短くなっているので、「上げれば長くなる」という関係でもありませんでした。

最後に形式です。ここだけは素直な結果でした。

0.2：2回とも because に自然につながる形
0.6：because entered a complex sequence of commands と主語が抜けている（2回とも）
1.0：1回目が because から始まり、プロンプト末尾の because と重なって「なぜなら、なぜなら」になっている

0.2 では崩れず、値を上げると崩れ始めています。ここは説明どおりの挙動です。

まとめると、形式の崩れ方は値に沿っていたものの、肝心の内容と長さは 0.6 が飛び出す形になりました。
2回ずつしか試していないので断定はできませんが、少なくとも Temperature を上げれば上げただけ出力が多様になる、という単純な話ではない ことは分かりました。

検証2：Top P を変える

Temperature を 1.0 に固定し、Top P だけを変えます。

ここで Temperature を最大にしておくのがポイントです。
Temperature を低くすると確率分布が尖るため、Top P を緩めても低確率の候補はほとんど選ばれません。
つまり Top P を動かしても出力が変わらず、Top P 自体の効果が観察できなくなってしまいます。

実際、検証1の Temperature 0.2 は Top P = 1.0、つまり絞りなしの状態でしたが、2回ともほぼ同じ文が返ってきていました。

まず Top P = 0.1 です。

1回目
the flood of error messages and warning alarms filled the screen,
indicating a catastrophic system failure.

2回目
the flood of error messages and warning alarms filled the screen,
indicating a catastrophic system failure.

一字一句、完全に同じでした。

Temperature は 1.0、つまりランダム性が最も高いはずの設定です。
それなのに2回とも寸分違わぬ文が返ってきました。

対して Top P = 1.0 の結果です。

1回目
because a flood of error messages filled the screen, each one more daunting
and cryptic than the last, and the once optimistic engineer realized that
not only was the system down, but it would take a herculean effort to
bring it back online.

2回目
the alarming number of error messages and system notifications flooded
the screen, indicating a serious issue with the program's latest update.

43語と21語。同じ Temperature 1.0 とは思えない差が出ました。

気づいたこと

Top P を絞ると、Temperature は効かなくなります。

Temperature 1.0 は Mistral 7B で設定できる上限、つまり確率分布をいちばん平坦にした状態で、確率の低いトークンにも出番が回りやすくなります。
一方の Top P 0.1 は、確率の高い候補から順に足していき、累積10%に届いたところで残りを切り捨てます。

問題はこの2つが同時に効いたときです。
分布をどれだけ平坦にならしても、上位10%に入る候補が1個しかなければ、モデルはその1個を選ぶしかありません。
選択肢がないので、何度実行しても同じ文が返ってきます。

Temperature と Top P は横並びの2つのツマミではなく、Temperature が整えた分布に対して、Top P が後から切り落としをかける という前後関係にあります。
一般的なサンプリングの実装でも、Temperature でスケーリングした分布に Top K や Top P の絞り込みを適用する順序で処理されるため、今回の結果はその順序どおりの挙動といえます。

検証3：Top Kを変える

同じく Temperature 1.0 固定で、Top K を変えます。

Top K = 5 の結果です。

1回目
the flood of error messages and system alerts filled his screen,
each one more ominous than the last.

2回目
the flood of red error messages filled the screen,
each one more ominous than the last.

Top K = 200 の結果です。

1回目
because a flood of error messages scrolled down the screen,
each one more ominous than the last.

2回目
the flood of error messages and warning symbols that filled the screen
indicated a major system malfunction.

気づいたこと

候補数を40倍にしても、ほとんど変わりませんでした。

4回中3回が each one more ominous than the last（どれも前のものより不吉だった）で終わっていて、K = 5 と K = 200 の間にはっきりした違いは見つけられませんでした。
検証2で Top P があれだけ効いたのを見た後だと、拍子抜けする結果です。

理由はおそらく、6位以下の候補にそもそも確率がほとんど残っていない ことだと思います。
「エラーメッセージが画面を埋め尽くす」という強い文脈では、次に来る単語の候補が上位数個に集中します。
その状態で K を200まで広げても、6位以下は確率がほぼゼロなので、候補として並んではいても実際には選ばれません。

このプロンプトでは、K = 5 も K = 200 も結局は同じことをしていた ということになります。

検証結果のまとめ

3つの検証を並べると、こうなりました。

変更したパラメータ	出力の変化
Temperature 0.2 → 1.0	形式は崩れたが、内容の変化は値に比例しなかった
Top P 0.1 → 1.0	劇的（0.1では2回とも完全に同じ文）
Top K 5 → 200	ほぼ変化なし

不思議なのは、Top P と Top K はどちらも「候補を絞る」パラメータなのに、片方だけがこれほど効いたことです。

理由は、試験対策で覚えたあの一行そのものでした。

Top Pは確率で候補を絞る
Top Kは候補数で絞る

Top P は確率の合計で線を引くので、分布の形に合わせて残る個数が変わります。
候補が上位に集中していれば、1個目だけで10%に届いてしまい、残るのは1個だけ。
逆に分布が平坦なら、10%に届くまでに何個も必要になるので、たくさん残ります。
今回は前者だったため、候補が1個に絞られて2回とも同じ文になりました。

一方の Top K は分布の形に関係なく、常に上位K個 を残します。
5個でも200個でも、6位以下の確率がゼロに近ければ、選ばれる候補は結局変わりません。

暗記としては「確率で絞る」「個数で絞る」だけの違いですが、実際に動かしてみると、同じ「絞る」でも 効き方がまったく違う ことが分かりました。

補足：極限まで絞った場合

検証には含めていませんが、Top K = 1 も試してみました。
Temperature を 0.2 にしても 1.0 にしても、4回すべてが完全に同じ文になりました。

しかもその文は、検証2の Top P = 0.1 で出たものと 一字一句同じ でした。

the flood of error messages and warning alarms filled the screen,
indicating a catastrophic system failure.

累積確率で切る Top P と、個数で切る Top K。
絞り方の仕組みはまったく違うのに、限界まで絞ると同じ最有力候補1個にたどり着く、というのが面白いところです。

ハマりどころ：チャットモードでは検証できない

最後に、これから同じ検証をする方への注意点です。

最初、Playgroundの チャットモード で試していたのですが、Temperature を変えても出力がほとんど変わらないという現象に悩まされました。

原因は 会話履歴 でした。
チャットモードは過去のやり取りを保持するため、モデルは毎回それまでの全出力を読んだうえで次を生成します。
その結果、直前の出力に引っぱられる力が Temperature よりも強く働いてしまうようです。

実際、別のプロンプトで試していたときは、前回の出力の末尾を受けて次の出力ができあがるという連鎖が9回続きました。
Temperature を0から1.0まで振っても、この連鎖は崩れませんでした。

そのため、本検証をコンソールで試される場合は、シングルプロンプトモードを使ってください。
こちらは1回ごとに独立して実行されるため、履歴の影響を受けません。

実際に触ってみて分かったこと

資格試験の勉強では、次のように用語と意味を1対1で暗記しがちです。

Temperatureが高い
＝ ランダム性が高い

しかし実際にPlaygroundで試してみることで、次の違いがイメージしやすくなりました。

Temperature
→ 候補そのものを削るのではなく確率分布を変える

Top K
→ 個数で候補を削る

Top P
→ 累積確率で候補を削る

また、「値を上げれば上げただけ結果が変わる」というわけでもない点は、実際に試して初めて分かったことでした。
検証1では、いちばん高い 1.0 ではなく途中の 0.6 で、まったく別の内容が返ってきています。

生成AIの出力にはランダム性があるため、1回の結果だけで判断せず、同じ条件で複数回実行して傾向を見ること が大切だと感じました。

試験ではどのように問われるか

最後に、試験対策という観点でも触れておきます。

私が受験したときは、「Temperature のデフォルト値はいくつか」のようにパラメータの数値そのものを問う問題は出ませんでした。
代わりに多かったのが、業務のシナリオを示したうえで「うまくいっていない状況をどう改善するか」を選ばせる形式です。
その選択肢のひとつに、推論パラメータの調整が並んでいるという出題のされ方でした。

試験の内容そのものを書くことはできないため、雰囲気が伝わるように例題を自作してみました。

例題

ある企業では、コールセンターに寄せられた問い合わせ内容を Amazon Bedrock で要約し、担当部署へ振り分ける仕組みを構築しました。
運用を開始したところ、同じ問い合わせを要約させても実行するたびに文面が変わってしまい、振り分け先が安定しないという報告が上がってきました。
出力を安定させるために、まず取るべき対応はどれですか。

A. Temperature の値を上げる
B. Temperature の値を下げる
C. 最大出力トークン数を増やす
D. プロンプトに例文を追加する

答えは B です。

実行するたびに文面が変わるのは、確率の低い候補まで選ばれる余地があるためです。
Temperature を下げれば確率分布が尖り、高確率の候補が選ばれやすくなるので、同じ入力に対して安定した出力が得られます。

こうした問題で問われているのは、パラメータの数値を暗記しているかどうかではありません。
「ばらつきを抑えたいなら下げる」「多様なアイデアが欲しいなら上げる」という方向を、シナリオと結びつけて判断できるか です。

今回のように一度自分で値を振ってみておくと、選択肢を読んだ時点で「これは出力を安定させたい場面だ」と判断しやすくなると思います。

まとめ

今回はAWS Certified AI Practitioner（AIF-C01）の試験範囲でも登場するTemperature・Top P・Top Kについて、Amazon Bedrock Playgroundを使って違いを確認しました。

暗記した一行の意味が、実際に手を動かしてみて初めて腹に落ちた検証でした。
今後は上位のAssociateレベルの資格にもチャレンジしていきたいと思います。

長文になってしまいましたが、最後までお読みくださりありがとうございました。

参考