この記事でやること

前回でai&の全体像を見たので、今回は実際に Playground（ブラウザ上でモデルを試せる遊び場） を使って、モデルの挙動を観察します。

テーマは 「温度（Temperature）を変えると出力はどう変わるのか」 です。

無料で使える qwen/qwen3.6-27b（$0.00）を主役にしました。お金を気にせず何度でも試せるので、温度の影響を見るには最適です。簡単なお題と難しいお題の2問を用意して、T=0 / 1 / 2 の3段階で出力がどう変わるかを実際に見ていきます。

⚠️ 料金・仕様は2026年6月時点のものです。

検証の準備：2つのお題

モデルにやらせるお題を2つ用意しました。性質をわざと変えてあります。

お題A：実用スクリプト（やさしめ）

CSVを集計して積み上げ棒グラフを作る、よくある実務タスクです。

以下の仕様でPythonスクリプトを書いてください。

- sales.csv（列: date, store, amount。dateはYYYY-MM-DD形式）を読み込む
- 月ごと・店舗ごとの売上合計を集計する
- 結果をmatplotlibで積み上げ棒グラフにして monthly_sales.png に保存する
- pandasを使ってよい
- コードのみを出力し、説明は不要です

このお題は「書き方が何通りもあるが、難しくはない」のがポイント。温度を上げたときに出力がどう揺れるかを見ます。

お題B：カスタム仕様の電卓（むずかしめ）

文字列の数式を評価する関数を、eval()禁止で書かせます。仕様にクセを入れてあります。

Pythonで文字列の数式を評価する関数 calc(expr: str) -> float を書いてください。
eval() や ast の使用は禁止です。

仕様:
- 対応する演算子: + - * / ^（べき乗） と括弧 ( )
- ^ は右結合とする（例: 2^3^2 = 2^(3^2) = 512）
- 単項マイナスに対応する（例: -3^2 = -(3^2) = -9 と解釈する）
- 演算子の優先順位: 括弧 > ^ > 単項マイナス > * / > + -
- ゼロ除算の場合は ValueError を送出する
- コードのみを出力し、説明は不要です

LeetCodeの有名問題だと暗記で解けてしまうので、^の右結合や単項マイナスの優先順位など、仕様の細部を正しく読めるかで地力が出るように調整しています。採点は次の9ケースを機械的に通します。

assert calc("1+2*3") == 7
assert calc("(1+2)*3") == 9
assert calc("2^3^2") == 512        # 右結合
assert calc("-3^2") == -9          # 単項マイナスの優先順位
assert calc("2*-3") == -6
assert calc("10/4") == 2.5
assert calc("-(1+2)^2") == -9
assert calc("2^-1") == 0.5         # 指数に単項マイナス
try:
    calc("1/0"); assert False
except ValueError:
    pass

温度（Temperature）って何？

本題に入る前に、温度を簡単に説明します。

LLMは次に続く単語（トークン）を確率で選んでいます。温度はこの確率分布の「鋭さ」を調整するつまみです。

温度が低い（T=0）：一番確率の高い単語を堅実に選ぶ。毎回ほぼ同じ、お堅い出力になる
温度が高い（T=2）：低確率の単語も選ばれやすくなる。多様だが、暴走して崩壊することもある

Qwenで T=0 / 1 / 2 の3段階を試して、この違いを実際に見てみます。

温度比較①：お題A（やさしめ）

まずはやさしいお題Aから。

T=0：堅実な優等生

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv('sales.csv')
df['date'] = pd.to_datetime(df['date'])
df['ym'] = df['date'].dt.to_period('M')

monthly_sales = df.groupby(['ym', 'store'])['amount'].sum().unstack(fill_value=0)
monthly_sales = monthly_sales.sort_index()

ax = monthly_sales.plot(kind='bar', stacked=True, figsize=(10, 6))
plt.xlabel('Month')
plt.ylabel('Total Sales')
plt.title('Monthly Sales by Store')
plt.xticks(rotation=45)
plt.tight_layout()
plt.savefig('monthly_sales.png')
plt.close()

groupby().unstack()で集計し、plt.close()まできっちり書く堅実なコード。問題なく動きました。

T=1：動くが、書き方が変わる

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv('sales.csv')
df['date'] = pd.to_datetime(df['date'])
df['month'] = df['date'].dt.strftime('%Y-%m')

pivot_df = df.pivot_table(index='month', columns='store', values='amount', aggfunc='sum').fillna(0)

pivot_df.plot(kind='bar', stacked=True, figsize=(10, 6))
plt.xlabel('Month')
plt.ylabel('Amount')
plt.xticks(rotation=0)
plt.tight_layout()
plt.savefig('monthly_sales.png')

こちらも正しく動きます。ただT=0と見比べると、集計がpivot_table()に、月の表現がstrftimeに変わっています。正解は同じでも、書き方にゆらぎが出る。これが温度を上げた効果です。

T=2：思考は正しいのに、出力が崩壊

T=2では、思考の途中までは正しいのに、コードを書き出す段階でトークンがぐちゃぐちゃに混ざって崩壊しました。

import pandas pd read csvdf pd.to df['df.groupby(['yearmonthly dfmonthly df plot(kind stacked...

（以下、意味をなさない記号と単語の羅列が続く）

「何をすべきか」は理解しているのに、それをコードとして出力する段階で破綻している、という壊れ方です。

温度比較②：お題B（むずかしめ）

ここからが本番です。難しいお題Bだと、温度の影響がもっと劇的に出ました。

T=0 / T=1：どちらも8/9

T=0もT=1も、shunting-yard（操車場アルゴリズム）を使った本格的なパーサを書いてきました。9テストケースに通したところ、どちらも8/9。

唯一落としたのが 2^-1（指数に単項マイナスが付くケース）です。

興味深いのは、思考の中では「2^-3は2^(-3)になるべき」と正しく認識していたこと。それなのに、いざ実装すると^と単項マイナスの優先順位処理を誤って、2^-1でスタックが空になりエラーになりました。

思考は正解にたどり着いているのに、コードに落とす段階で取りこぼす。難しいお題にした狙いどおり、ここで地力（の限界）が見えました。2^-1のような指数の符号は、人間がパーサを書くときにもよく落とすポイントです。

さらに面白いのが、T=0とT=1が、まったく同じケースを同じ理由で落としたこと。温度を変えても、モデルが構造的に苦手とするところは変わらないわけです。

T=2：完全崩壊（0/9）

お題BのT=2は、お題Aの比ではない壊れ方をしました。思考の前半こそまともでしたが、途中から $ や記号、バラバラの数字が延々と続き、コードはついに出力されませんでした。

崩壊して暴走した結果、生成に約100秒・5000トークン以上を消費。正常時（T=0で約18秒）よりむしろ時間もトークンも食っています。Qwenは無料なので金銭的な被害はありませんが、これが有料モデルだったら「壊れた出力にお金を払う」ことになります。（恐ろしい...）

ハマりどころ：reasoningモデルは思考でトークンを使い切る

実は最初、お題BのT=0でコードが出てこず、思考だけで止まりました。原因は max_tokens（最大出力トークン数）が4096だったこと。

Qwenのようなreasoning系モデルは、答える前に長い思考を行います。お題Bだとその思考だけで5000トークン近く使うため、4096の上限では思考の途中で打ち切られ、肝心のコードに到達しなかったのです。

reasoning系モデルをAPIやPlaygroundで使うときは、max_tokensを大きめ（8192〜16384）に設定する必要があります。「コードが途中で切れる」と思ったら、まずここを疑ってください。

max_tokensを上げたら、ちゃんと最後までコードが出力されました。

温度比較のまとめ

温度	お題A	お題B	一言
T=0	✅ 動く	8/9	堅実な優等生
T=1	✅ 動く（書き方は変化）	8/9	正解は同じ、表現がゆらぐ
T=2	❌ 出力崩壊	0/9（崩壊）	暴走して時間もトークンも浪費

ここから言えることをまとめると、

簡単なタスクなら、T=1までは安定して正解する。 崩壊するのはT=2という極端な設定にしたとき。日常的にはT=0〜1で十分で、T=2は「限界を見る」ための設定。
難しいタスクほど、高温の崩壊は激しくなる。 お題Aの崩壊（変数名が混ざる程度）に対し、お題Bは完全崩壊。
温度を変えても、モデルの弱点そのものは変わらない。 T=0とT=1が同じケースを落とした。
難しいタスクほど、実装は定石に収束する。 お題Aは温度でアプローチが割れたが、お題Bはどちらもshunting-yardでほぼ同じ構造になった。

この検証にかかった金額

$0です。 1セントも減っていませんでした。

今回の検証はすべて無料モデルの qwen/qwen3.6-27b（$0.00 / $0.00）で行ったため、温度を3段階×お題2問＝6回生成しても、T=2の崩壊暴走で5000トークン食われても、一切課金されませんでした。

温度の挙動を理解するための実験としては、タダで回せるQwenは最適な選択肢だったと思います。

まとめと次回予告

第1回として、Playgroundで温度が出力に与える影響を、実際のコーディングタスクで観察しました。

温度は「出力の堅さ／多様さ」を調整するつまみ。 T=0〜1で十分、T=2は崩壊リスク
簡単なタスクはT=1まで安定。難しいタスクほど高温の崩壊が激しくなる
温度を変えても、モデルの構造的な弱点は変わらない（T=0とT=1が同じケースを落とした）
reasoning系モデルはmax_tokensに注意。 思考でトークンを食い尽くす

今回はQwen1モデルに絞って温度を深掘りしましたが、ai&には他にもDeepSeek、Gemma、GLM、gpt-oss-120bなど9モデルが揃っています。

次の回では他のモデルも活用できるような検証を行いたいと思います。

　次回　要件定義とGitHub Copilot Studentで「悩み相談ルーレット」の見た目を作ってみた
https://qiita.com/aonami3902_/items/a85da6c9a9d42dae4687