Playground — ブラウザでモデルを試す

これは何か

Playground は、コンソール（app.fireworks.ai）内にある、コードを 1 行も書かずにブラウザ上でモデルへリクエストを送り、応答を確認できる試し場である。画面をどこから開くかという正確な導線は公式ドキュメントに明記が無く、UI 更新でも変わりうるため、本章では導線の特定ではなく Playground を開いた後の使い方に集中する。確証があるのは、すでに専用デプロイ（第 9 章）を作っている場合、そのデプロイの詳細ページに「Playground」というクイックアクションがあり、そのデプロイ自身を対象に同じ画面を開けるということである。対象モデルには「Try the API」「Deploy on Demand」という CTA（行動喚起ボタン）も用意されており、試した内容から専用デプロイの作成へ進める導線になっている（公式の更新履歴で存在は確認できるが、どの画面に置かれているかは明示されていない）。

Playground のヘッダにはカテゴリタブが並ぶ。公式の更新履歴には LLM / Image / TTS / STT の 4 タブが確認できており、選んだモデルに応じて自動でカテゴリを判別し、カテゴリごとに妥当な既定値を出す設計になっている。ただし Image・TTS・STT 側の機能は後の更新履歴で見直しが入っているため、本章では最も確実に使える LLM タブ（チャット・テキスト生成モデル）を対象に解説する。

画面の要素としては、モデルを選ぶドロップダウンと、temperature や top_p といったパラメータを数値で直接編集できる入力欄がある。ドロップダウンには埋め込み（embedding）用モデルとリランク（rerank）用モデルは表示されない。これらは検索・並べ替え用のスコアを返すモデルで、応答を人間が読んで確かめる Playground の使い方とは噛み合わない。また、レプリカ数が 0（稼働中のサーバーがない状態）まで縮退した専用デプロイに対しては、Playground からのクエリがブロックされる。まずはそのデプロイを起こす操作が必要になる。

いつ使うのか

Playground が向いているのは、次のような「コードを書く前に確かめたい」場面である。

• 第 3 章の Model Library で候補に挙げたモデルが、実際に自分のタスク・文体をこなせるかを 1 回試してみる
• 同じプロンプトのまま temperature や top_p だけを変えて、出力がどう変わるかを目で見て比較し、コードに書き込む前に当たりを付ける
• すでに作成済みの専用デプロイ（第 9 章）が期待どおり応答するかを、アプリに組み込む前にさっと確認する

逆に言えば、Playground は「1 回のリクエストを人間が試す」ための画面であり、プログラムから繰り返し呼び出したり、大量のリクエストをまとめて処理したりする用途には向かない。隣接する機能との違いは次のとおり。

パラメータでモデルの出力を制御する

Playground の主役は、実はモデル選択そのものより、パラメータの数値入力欄である。これらは Chat Completions API のリクエストボディにそのまま対応する値であり、ここで意味を理解しておけば第 5 章で API を書くときに迷わない。API 側では、値を何も指定しない場合、Fireworks はそのモデルの Hugging Face generation_config.json に書かれた推奨値（temperature / top_k / top_p / min_p / typical_p）を自動的に適用する。これは前段で触れた Playground のカテゴリ別スマート既定値とは別の仕組みで、画面に最初から入っている数値がどちらに由来するかは公式ドキュメントには書かれていない。以下の値の範囲・既定値はいずれも 2026-09 時点のものである。

加えて、会話の最初に置く「システムプロンプト」もここで一緒に調整する対象になる。モデルの人格・役割・制約を指示する文で、API 側では messages の先頭に role: "system" のメッセージとして渡す値と同じものである。

先ほど触れた自動適用の対象には、表に挙げた 3 つ以外に min_p と typical_p も含まれる。min_p は確率がある閾値を下回るトークンを候補から除外するもの、typical_p は珍しすぎず平凡すぎない「ふつうの確からしさ」のトークンを選ぶ値（公式の説明では「分布のエントロピーに近い確率を持つトークン」）で、いずれも 0〜1 の範囲を取る。これらは temperature や top_p ほど頻繁に触る対象ではないが、モデルの既定挙動の一部として裏側で効いていることは覚えておくとよい。

temperature が出力の多様性を変える仕組み

モデルは次に来るトークンの候補それぞれに確率を割り当ててから、そこから 1 つを選んで生成する。temperature はこの確率の付き方そのものを作り直す係数で、公式ドキュメントは「0 で決定的、大きいほど創造的（0 = deterministic, higher = more creative）」と説明している。temperature を 0 に近づけると、最も確率の高かった候補にほぼ全ての確率が集中し、毎回ほとんど同じトークンが選ばれる。逆に temperature を上げると、確率の高かった候補への集中が崩れ、次点・次々点の候補にも確率が分散していく。

top_p と top_k は、この確率分布に対して「候補をどこまで絞るか」を決める別軸のフィルタである。top_p は確率の高い順に足し合わせて top_p の値に達するところまでを候補として残し、top_k は確率の高い上位 k 個だけを候補として残す。temperature が確率の「形」を変え、top_p・top_k がその中から「候補として残す範囲」を絞る、という 2 段構えで最終的にサンプリングされるトークンが決まる。

max_tokens とコンテキスト窓の関係

コンテキストウィンドウは、プロンプトと生成される応答を合わせて 1 回のリクエストで扱えるトークン数の上限である。max_tokens はこの中で「応答として生成してよい最大トークン数」を別途キャップするパラメータで、指定しなければ既定値の 2048 が使われる。モデルの実際のコンテキストウィンドウがどれだけ大きくても、max_tokens を上げない限り応答は 2048 トークンで頭打ちになる。

プロンプトが長く、プロンプト長と max_tokens の合計がコンテキストウィンドウを超えてしまう場合の挙動にも注意が要る。この挙動は context_length_exceeded_behavior というパラメータで制御されていて、既定値は「切り詰める（truncate）」である。超えた分だけ max_tokens を自動的に小さくして収め、エラーにはならない。もう 1 つの選択肢である「エラーにする（error）」を明示的に指定しない限り、この自動切り詰めが働く。OpenAI の API から移行してきた場合はここが逆で、OpenAI の既定は「エラーにする」側の挙動に相当する。切り詰めが起きたリクエストは、応答に finish_reason: "length" が付く。

Playground からコードへ ── 同じ設定を API で再現する

Playground でプロンプトとパラメータの当たりが付いたら、次にやることは同じ内容を API 呼び出しとして再現することである。プロンプト・システムプロンプト・temperature や top_p などの数値は、そのまま Chat Completions API のリクエストボディの値に対応する。前段で触れた「Try the API」という CTA も、この橋渡しのための入口として用意されている（設置画面は明示されていない）。

from fireworks import Fireworks

client = Fireworks()

response = client.chat.completions.create(
    model="accounts/fireworks/models/<MODEL_ID>",
    messages=[
        {"role": "system", "content": "Playgroundで固めたシステムプロンプトをそのまま入れる"},
        {"role": "user", "content": "Playgroundで試したのと同じプロンプト"}
    ],
    temperature=0.9,
    max_tokens=500
)

print(response.choices[0].message.content)

パラメータを何も指定しなかった場合に、API 側で実際どの値が適用されたかは、レスポンスヘッダの fireworks-sampling-options で確認できる。設定を数値としてコードに固定してしまえば、Playground で毎回手で合わせていた条件を再現性のある形で持ち運べる。この続きは第 5 章で扱う。

実際にやってみる

ここまでの内容を、実際に手を動かして確かめる。どちらのハンズオンも実モデルへ本物のリクエストを送るため、選んだモデルが Serverless モデルであれば通常の推論と同じ扱いと考えるのが安全である。Playground のリクエストもクォータの対象になっており、超過するとエラーメッセージが表示されることが公式の更新履歴で確認できる。正確な課金の扱いと単価は料金ページと第 5 章で確認すること。

つまずきポイント

理解度チェック

まとめ

• Playground はコンソール内の、コード不要の試し場である。デプロイ詳細ページのクイックアクションから開けることは確認できるが、それ以外の導線は公式ドキュメントに明記が無い
• 埋め込み・リランクモデルは対象外、レプリカ 0 のデプロイはクエリ不可という制約がある
• temperature（0〜2）・top_p・top_k は確率分布の形と絞り込み範囲を、max_tokens・stop は生成の長さと終了条件を制御する
• パラメータを指定しなければ、API 側ではモデルごとの推奨既定値（generation_config.json 由来）が自動適用される。Playground はカテゴリを自動判別してカテゴリごとの既定値を出す設計だが、画面に最初から入っている数値がどちらに由来するかは公式ドキュメントには書かれていない
• Playground で固めた設定は、そのまま Chat Completions API のパラメータとして持ち込める

次の第 5 章では、ここで触れたパラメータを実際の API 呼び出しとして書き、Serverless 推論の課金・レート制限の仕組みまで踏み込む。

参考リンク

• Fireworks AI Changelog
• Concepts — Fireworks AI Documentation
• Glossary — Fireworks AI Documentation
• Querying Text Models — Fireworks AI Documentation
• Create Chat Completion — API Reference
• Serverless Quickstart — Fireworks AI Documentation
• Fireworks AI Pricing