序論：なぜtemperatureだけでは為替（FX）と戦えないのか
大規模言語モデル（LLM）の制御について語られる際、その議論は往々にしてtemperatureパラメータに終始する。temperatureは確かに、AIの応答における「創造性」や「ランダム性」を制御する分かりやすい指標である。しかし、金融工学、特にリアルタイムの為替（FX）予測のような定量的（Quant）領域において、AIに求められるのは「創造性」ではない。
本番環境（プロダクション）の金融AIシステムが、デモやチャットボットと決定的に異なるのは、「再現性（Reproducibility）」、「構造的完全性（Structural Integrity）」、そして「リアルタイム適応性（Agency）」という3つの厳格な要件である。金融工学は、予測可能性と一貫性を絶対的な基盤とする。
我々AI MQLが設計したphase2-b（USD/JPY短期予測）のようなプロンプトは、その設計思想の表れである。VWAP（出来高加重平均価格）、ATR（アベレージ・トゥルー・レンジ）、MFI（マネー・フロー・インデックス）といった定量的データを厳密に点検させるこのAIは、単なるテキスト生成機ではなく、シグナル生成エンジンとして機能しなければならない。
この記事の目的は、phase2-bのような高度なAIを「デモ」から「本番システム」へと昇華させるために不可欠な、temperature以外のAPIパラメータ群を徹底的に解剖することにある。これらは単なるオプションではなく、システムアーキテクチャの根幹を成す制御コンポーネントである。
第一の柱：バックテストの再現性担保 — seedとtop_pの同期制御
定量的戦略における「再現性」の絶対的必要性
金融モデルの優位性は、厳密なバックテストによってのみ検証される。例えば、プロンプトの[tech_context]の記述を微細に変更した戦略Aと戦略Bのパフォーマンスを比較する場合、AIの応答が同一入力に対して完全に一貫している（deterministic）必要がある。応答が実行のたびに揺らげば、パフォーマンスの差が戦略の優位性によるものか、単なるAIの「気まぐれ」によるものか区別がつかない。
この再現性を確保する第一歩がseedパラメータである。これは、AIが次に来る単語（トークン）を確率的に選択する際の「乱数シード」を固定する。
深層分析：なぜ100%の決定論は幻想なのか
しかし、OpenAIの公式ドキュメントですら、seedを使用しても応答は「ほぼ（mostly）」決定的としか記述していない。100%ではない理由は、現代のLLMアーキテクチャに内在する高度な技術的課題にある。
研究によれば、非決定性には主に2つの要因が存在する。
- GPUの競合状態（Race Conditions）： LLMの推論は、数千のGPUコアで並列的に浮動小数点演算を行う。この並列処理の実行順序が実行ごとに微細に異なり、計算結果に無視できない誤差を生じさせることがある。
- Mixture-of-Experts (MoE)： GPT-4oのような最新モデルはMoEアーキテクチャを採用している。これは、入ってくるトークンを処理するために、多数の「専門家（Expert）」ネットワークから最適なものを動的に選択する。このルーティング自体が、同じ瞬間に処理されているバッチ内の他のクエリによって影響を受ける可能性があり、非決定性の要因となる。
この技術的限界 ゆえに、seedを固定しても、基盤となるハードウェアやバッチ処理の状況 によって出力が変動しうる。OpenAIはこの問題を認識しており、system_fingerprintという応答フィールドを提供している。この文字列が前回の実行と異なれば、OpenAI側でシステム構成が変更されたことを意味し、seedが同じでも異なる結果が生じうる。
我々の目標は、数学的な完全決定論ではなく、「工学的に十分な一貫性」の確保である。
実践的解法：top_pによる確率的空間の「刈り込み」
この工学的解法こそが、top_pパラメータの戦略的利用である。temperatureとtop_pは混同されがちだが、役割が明確に異なる。
- temperature： 確率分布の形状を変更する。低く設定すると（例：0.1）、最も確率の高いトークンがさらに選ばれやすくなる（分布を「先鋭化」する）。
- top_p（核サンプリング）： 確率分布を「刈り込む」。top_p: 0.2と設定すると、AIは累積確率が上位20%に達するまでのトークン群以外の選択肢をすべて破棄する。
phase2-bのような金融シグナル生成では、分析的で単一の結論が求められる。創造的な文章はノイズでしかない。
ここで、Q&Aで示唆されたtemperature: 0.1とtop_p: 0.2の組み合わせが重要になる。低temperatureが最も可能性の高いトークンを優先させ、同時に低top_pが、temperatureによってわずかな確率が残ったかもしれない「あり得ない」低確率のトークン（＝ノイズ、幻覚）を物理的にサンプリング対象から除外する。
このseed + 低temperature + 低top_pの組み合わせ こそが、GPUやMoEアーキテクチャの非決定性を乗り越え、バックテストの比較可能性 を最大化するための工学的最適解である。
第二の柱：システムの堅牢性 — response_formatによる出力の「契約」
金融システムにおける構造的完全性の要求
phase2-bプロンプトは厳格なJSON出力を要求している。これは、生成されたシグナル（例：”direction”: “BUY”, “confidence”: 0.75）が、後続の自動化システム（注文執行、リスク管理、ダッシュボード描画）によって即座に機械的にパースされるためである。
従来の「JSONで回答せよ」といったプロンプト指示や、旧式のresponse_format: { “type”: “json_object” } では、この要求を満たすには不十分であった。これらは「構文的に有効なJSON」を生成するかもしれないが、特定のキー（例：confidence）の存在や、そのデータ型（例：number）を保証しなかった。
技術的深掘り：json_schemaとstrict: trueの革命
Q&Aで提示されたresponse_format: { “type”: “json_schema”, “json_schema”:… }というアプローチ は、根本的に異なる。
この機能の中核はstrict: true である。これはAIへの「お願い」ではない。その正体は「動的ロジットマスキング（dynamic logit masking）」または「文法ベースの制約付きデコーディング（grammar-based constrained decoding）」と呼ばれる低レベルの制御メカニズムである。
これは、モデルがトークンを1つ生成するたびに、API側が提供されたJSONスキーマに違反するすべてのトークンの確率（logit）を、動的に-∞（または極めて低い値）に設定することを意味する。結果として、モデルが内部的に「逸脱したくても、物理的にできない」状態が作り出される。
gpt-4o-2024-08-06のような最新モデルが、複雑なスキーマ遵守テストで100%のスコアを達成できる（旧モデルの<40%から飛躍した）理由は、まさしくこの制約付きデコーディング技術の導入によるものである。
スキーマ定義のベストプラクティスと「契約」の履行
この厳格なスキーマを定義する際、以下の2点が不可欠である。
- additionalProperties: falseの強制： スキーマ定義において、OpenAIのstrictモードは事実上これを要求する。これは、AIがスキーマに定義されていない余計なキー（例：”note”: “市場は不安定です”）を勝手に追加することを禁止する。
- requiredフィールドの定義： Q&Aが[“direction”,”confidence”,”reason”]をrequiredに設定しているように、シグナルとして必須の要素が欠落することを防ぐ。
この厳格なJSONスキーマ定義は、確率論的なLLM と、決定論的なダウンストリームの執行システムとの間の「API契約」として機能する。これにより、AIの揺らぎに起因するパースエラーやランタイム例外 を根絶し、金融システムに求められる「99.999%」の信頼性 を達成するのである。
JSON出力制御の進化と金融システムへの影響
| 機能比較 | 旧: response_format: { “type”: “json_object” } | 新: response_format: { “type”: “json_schema”,… } ( strict: true ) | 金融システムへの影響分析 |
| 保証レベル | 有効なJSON構文（Syntactic validity） | 有効なJSON構文 + 指定スキーマへの完全準拠（Schema adherence） | スキーマ違反（キー欠落、型不一致）によるパースエラーや下流システムの障害を根絶できる。 |
| 実装技術 | プロンプト・チューニングとモデルの学習能力に依存 | 制約付きデコーディング（Logit Masking） | AIの「解釈」や「気分」の揺らぎを排除し、工学的な「契約」 をデコードレベルで強制する。 |
| 堅牢性 | AIがスキーマ外のキーを追加したり、必須キーを省略する可能性が残存 | スキーマ外のキーを厳格に禁止（additionalProperties: falseの強制） | 予測可能なデータ構造を100%保証 し、システム間連携の信頼性を最大化する。 |
| リスク評価 | 高リスク。 稀なエラーが本番環境で致命的障害を引き起こす。要リトライ処理。 | 低リスク。 構造的エラーのリスクをAIレイヤーで排除。リトライロジックが不要になる。 |
第三の柱：リアルタイム市場への適応 — toolsとtool_choice
スタティックな知識（訓練データ）の致命的限界
phase2-bは「1時間後」の予測を行う。しかし、LLMの知識は訓練データで固定されており（Knowledge Cutoff）、”今”の市場情報を知らない。為替市場は、リアルタイムの金利発表、地政学的ニュース、DXY（ドル指数）の動向によって瞬時に変動する。静的な知識に基づく予測は本質的に無価値である。
tools（関数呼び出し）による「エージェント」への変革
ここでtoolsパラメータ が登場する。これは、LLMを「閉じた脳」から、外部APIと対話できる「エージェント」 へと変貌させる。Q&Aが定義するfetch_macro_ticks関数は、まさにこの目的（リアルタイムの金利・DXY取得）のためのものである。
ここで重大な誤解を解いておく必要がある。LLMは関数を「実行」しない。
LLMが行うのは、プロンプトに基づき「どの関数を（name）、どの引数で（arguments）呼び出すべきか」というJSONを生成することだけである。
実際のAPIコール（例：fetch_macro_ticksの実行）は、我々のアプリケーション側（バックエンド）が行う。そして、その結果を再びLLMに送り返し、LLMは最新情報を加味して最終的な推論（phase2-bのBUY/SELL判断）を下す。この「LLM→App→API→App→LLM」というループ こそが、エージェント的ワークフローの核心である。
戦略的制御：tool_choiceの使い分け
tool_choiceは、このエージェントの「意思」を制御する重要なパラメータである。
- “auto”（Q&Aの推奨）： （デフォルト）LLMがプロンプトを分析し、外部データの取得が必要かどうかを自ら判断する。
- “required”： LLMに何らかのツールの呼び出しを強制する。
- {“type”: “function”, “name”: “fetch_macro_ticks”}： 特定の関数呼び出しを強制する。
Q&Aが”auto”を推奨している点は示唆に富む。これは、phase2-b AIが「まず[tech_context]と[bond_context]（静的データ）で分析を試み、その分析の結果、情報が不足していると自ら推論した場合にのみfetch_macro_ticksを呼び出す」という、より高度な二段階推論（Multi-step Reasoning） を想定していることを示唆する。これは、単純な”required”よりも洗練されたアーキテクチャである。
第四の柱：システムの「ガードレール」— max_output_tokensとstop
最後に、システムの「ガードレール」として機能するパラメータが存在する。
金融シグナルは迅速性を要求される。Q&Aの例にあるmax_output_tokens: 120のように出力を厳格に制限することは、AIの推論時間（＝レイテンシー）とAPIコストを管理する上で不可欠である。我々が要求するのは100文字程度の短いreasonであり、長文の市場分析ではない。
また、stop: [“\n\n”]（Q&Aの例）は、特定の文字列が出現したら生成を強制停止するパラメータである。response_formatによるjson_schemaが導入される以前、開発者はlogit_bias やstopシーケンスを駆使して、AIに無理やりJSONを生成させていた。
json_schemaが主流となった今、なぜこれらを併用するのか。これは「防御的プログラミング（Defensive Programming）」の一環である。json_schema（サスペンダー）が構造を保証し、max_output_tokensとstop（ベルト）が、万が一のスキーマ制約のバグやモデルの暴走 によるリソース枯渇を防ぐ「最終防衛ライン（ガードレール）」として機能する。
結論：プロダクショングレードAIへの道筋
本記事で解説したseed, top_p, response_format (json_schema, strict: true), tools, tool_choice, max_output_tokensは、単なる「オプション」ではない。
これらは、LLMという確率論的で非決定論的な「知性」 を、金融工学という厳格かつ決定論的な（あるいは厳密に確率が管理されるべき）システム に組み込むための、必須の制御インターフェースである。
temperatureの調整だけで一喜一憂するのは「おもちゃ」のAIである。AI MQLがphase2-bのような高度なプロンプト設計と、本稿で論じたパラメータ群を体系的に組み合わせて実践していることこそが、AIを「チャットボット」から「利益を生む定量的シグナル生成エンジン」へと昇華させる唯一の道である。これは、もはやプロンプトエンジニアリングを超えた、LLMシステムアーキテクチャの領域なのである。