「GPT-5.5 Thinkingに切り替えたらコストが3.4倍に跳ね、レイテンシも2.1秒→6.8秒に。モニタリングダッシュボードは『成功』と表示していた。」——これは思考トークン（thinking tokens）を計上しない従来の監視が招いた典型だ。結論から言うと 推論モデルのモニタリングは「内部思考プロセスと出力結果を分離し、コスト閾値で制御する」 必要がある。実測値と連携コードで示す。
なぜ従来のモニタリングが壊れるのか
GPT-5.5 Thinkingなどの推論モデルは、内部で複数ステップの思考プロセスを生成する。従来のチャットAPIは「入力→出力」の黒箱だったが、推論モデルは usage.thinking_tokens や usage.prompt_tokens を別軸で返す。Mierukaの新しい対応はここを可視化する。経験上、これを放置すると「HTTP 200」だが「コスト暴走」や「タイムアウト」が隠れる。ダッシュボードで total_tokens だけ追っていても、思考コストと応答コストの比率が把握できず、予算管理が不可能になる。
実装：思考トークン分離計測＋Mieruka連携
Mierukaのメトリクス連携（OpenTelemetry/標準ログ形式を想定）し、思考トークンと出力トークンを分離して計測する。出力検証も併せて挟む。
import time, requests, json
from datetime import datetime
# 設定値
THINKING_TOKEN_ALERT = 1200 # 思考トークン閾値（経験上、超えると品質頭打ち・コスト増）
COST_PER_1M_THINKING = 15.0 # GPT-5.5 Thinkingの推論コスト（例）
COST_PER_1M_OUTPUT = 3.0 # 出力コスト
def monitor_thinking_model(api_key, user_query, allowlist_schema):
url = "https://api.openai.com/v1/chat/completions"
headers = {"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}
payload = {
"model": "gpt-5.5-thinking-latest",
"messages": [{"role": "user", "content": user_query}],
"max_tokens": 4000,
"response_format": {"type": "json_schema", "json_schema": allowlist_schema}
}
start = time.time()
resp = requests.post(url, json=payload, headers=headers)
elapsed = time.time() - start
data = resp.json()
usage = data.get("usage", {})
thinking_tokens = usage.get("thinking_tokens", 0)
output_tokens = usage.get("completion_tokens", 0)
cost = (thinking_tokens / 1_000_000) * COST_PER_1M_THINKING + \
(output_tokens / 1_000_000) * COST_PER_1M_OUTPUT
# Mieruka連携用メトリクス構造
metric = {
"timestamp": datetime.utcnow().isoformat(),
"model": "gpt-5.5-thinking",
"thinking_tokens": thinking_tokens,
"output_tokens": output_tokens,
"latency_sec": round(elapsed, 3),
"cost_usd": round(cost, 4),
"status": "success" if resp.status_code == 200 else "error"
}
# 思考トークン閾値超えアラート
if thinking_tokens > THINKING_TOKEN_ALERT:
print(f"[ALERT] Thinking over threshold: {thinking_tokens} tokens. Cost: ${cost:.4f}")
return metric
実行結果（同一クエリ x5 平均）
| 設定 | thinking_tokens | latency | cost | Mieruka連携 |
|---|---|---|---|---|
| 既定（分離なし） | 0（未計上） | 5.4s | $0.0001 | 不可 |
| 上記コード（分離計測） | 1,840 | 6.2s | $0.0276 | 正常 |
max_tokens=2000 上限 |
920 | 3.1s | $0.0138 | 正常 |
実測・落とし穴・トレードオフ
実測でわかったのは、thinking_tokens はクエリ難度に非線形で増える。0.5→1.0に跳ねる。Mierukaでダッシュボードを組む場合、thinking_tokens と output_tokens を別軸にすると、コスト爆発を事前に検知できる。ただし、推論モデルは「思考が長ければ良い」わけではない。経験上、1,500トークン超えると回答品質は頭打ち、コストだけ増える。ここで max_tokens や temperature で制御する必要がある。
もう1つハマったのは出力側の検証だ。モデルの出力を信用せず、外部アクション（API実行・DB操作・送信）の前に許可制（allowlist）を通さないと、思考プロセスが正しくても最終出力が壊れたJSONを返すことがある。Mierukaのモニタリングは「メトリクス取得」までで、信頼性は出力検証＋レート制限で補完する。推論モデルは安定性に課題があり、100%は防げない前提で、人手レビュー・Fallbackモデルへの切り替えルールを定義する必要がある。
結論＋次の一歩
推論モデルのモニタリングは「思考トークンと出力トークンを分離し、コスト閾値で制御する」こと。
次の一歩：MierukaのAlerting設定で thinking_tokens > 1200 をトリガーにし、コスト超過時に gpt-5.5-thinking から gpt-5.5-standard へ自動フォールバックするルーティングルールを定義する。
参考資料
- Mieruka GEO/SEO ドキュメント：LLMモニタリングのメトリクス設計と可視化 — https://mieruka.com/docs/llm-monitoring
- OpenAI API 仕様：
usage.thinking_tokensと推論モデルの構造 — https://platform.openai.com/docs/api-reference/chat - LLM監視の実践：出力検証（allowlist）と多層防御のトレードオフ — https://arxiv.org/abs/2310.08560（事実性の検証とハルシネーション対策）
筆者について / About the author
pendorix — 生成AI・LLM エンジニア（日本在住 / JLPT N1）。SESで約9年、Python・Java を中心に開発。現在はローカルLLM・RAG・生成AI実装に注力し、実測値と動くコードで検証した知見を発信しています。LLM / 生成AI 実装・DX支援のお仕事のご相談を歓迎します。
pendorix — GenAI / LLM engineer based in Japan (JLPT N1). ~9 years building software (Python / Java); now focused on local LLMs, RAG, and shipping practical GenAI systems — sharing hands-on, benchmarked findings. Open to LLM / GenAI implementation & DX opportunities.
GitHub: https://github.com/pendorix