Gemini 3.1 Pro API：長いコンテキスト、ツール、コスト

大人向けロマンスシリーズ1シーズン分の脚本バイブル30万トークンと、1つの疑問があるとします。どのシーンがキャラクターシートと矛盾しているのか。SpicyAPI上のGemini 3.1 Pro Previewなら全体を1回の呼び出しで読み込めますが、入力料金は20万トークンを超えると2倍になり、出力料金も50%上がります。大きなリクエストはストリーミングで送り、非ストリーミングのタイムアウトに引っかからないようにしてください。

Gemini 3.1 Pro Preview（google/gemini-3.1-pro-preview/chat）は最大1,000,000入力トークンを受け付け、テキストとimage_urlパートに対応します（PDF、動画、音声のパートは非対応）。ツールとJSON出力をサポートし、最大32,768トークンで返答します。長コンテキスト料金は、入力の合計が200,000トークンを超えた時点から適用され、リクエスト全体にかかります。

上限と料金

料金は入力トークンの合計で決まります。標準料金と長コンテキスト料金の2つの課金ティアを比較してください。

温度はデフォルトのままにしてください。GoogleはGemini 3モデルでこれを推奨しており、値を下げるとモデルが同じ出力を繰り返すことがあります。出力の形はresponse_formatとシステムメッセージで整えましょう。

1回の呼び出しの実際のコスト

コスト = 入力トークン × 入力単価 + 出力トークン × 出力単価で、ティアは入力の合計で決まります（キャッシュ分もカウントされます）。例ではキャッシュなしの入力と、出力合計4,000トークンを前提にしています。

推論トークンは出力として課金され、max_tokensの枠を共有します。推論の強度を上げるときは、必要な可視の回答分に余裕を足してください。4,000トークンの枠は、4,000トークン分の可視テキストを保証しません。

200,000を1トークン超えるだけで、呼び出しのコストはほぼ2倍になります。203,000トークンのパケットから古いやり取り5,000トークンを削れば、約50%節約できます。

この金額をさらに膨らませる要因が3つあります。

• ツールのラウンドごとにパケットが再送されます。 250,000トークンのパケットで3ラウンドのツールループを回すと、1ラウンドあたり入力で約$0.90、合計$2.70かかります。出力分は別です。
• キャッシュ分は安いものの、ここでは制御できません。 キャッシュ単価（しきい値超では$0.36）は、キャッシュから提供された入力に適用されます。たとえば、キャッシュ300,000トークンに新規5,000トークンと出力4,000トークンを加えると約$0.19で、キャッシュなしなら$1.16です。Gemini形式のcachedContentフィールドはこのルートでは拒否されるため、キャッシュなしで見積もり、最初の実行後に確定したコストを確認してください。
• 残高ホールドはmax_tokensの全量で計算されます。 テキストのリクエストを実行する前に、プラットフォームは入力とmax_tokensの全量をモデルの料金で確保します。入力1,000,000トークンと出力32,768トークンなら約$4.13です。エラーコードを確認してください。40201はホールドに対する残高不足、40202は利用上限（支出上限）です。前者は過大な出力枠を下げ、後者はキーとワークスペースの上限を確認します。公開画像URLを使うと、ホールドは入力上限の全体を対象にします。アップロードしたり埋め込んだりした画像では、代わりに画像用の固定枠が使われます。

最初の呼び出しの後は、X-Spicy-Task-Idレスポンスヘッダーを読み、そのタスクを照会してください。settledがtrueになった時点で、コストが確定します。これとストリームで返るusageを使って、以降の見積もりをすべて補正します。

パケット全体を入れるべきか

答えがパケット全体にまたがる関係に左右されるなら、全体を送ります。たとえば、シーズン全体の連続性の監査、仕様一式を対象にした「何が変わったか」という質問、脚本とキャラクターシートの矛盾探しです。質問が1つのシーンや1人のキャラクターに限られるなら、一部だけを送ります。シーン18でのMaraの小道具についての質問なら、必要なのはキャラクターシートとシーン12と18であり、シーズン全体ではありません。

チャットアプリの長期記憶の挙動は、このエンドポイントとは異なる場合があります。アプリは選んだ箇所を検索したり古いやり取りを要約したりしますが、APIが見るのはリクエストと一緒に送ったメッセージだけです。

入力ウィンドウが大きくても、すべての詳細が取り出せるとは限りません。散らばった複数の事実を見つけるのは、1つを見つけるより難しく、古い草稿が現行版と競合することもあります。料金のしきい値は精度の境界ではありません。絞り込んだ監査では次のようにします。

• シーズンを最大150,000トークンのアークに分け、それぞれを同じキャラクターシートで監査します。
• Googleが長いプロンプトで推奨しているとおり、質問と出力ルールは、すべての資料の後ろに最後に置きます。
• 各チャンクにラベル（SCRIPT_V3 / scene 12）を付け、回答には渡したラベルだけを引用させます。そのうえで、引用されたラベルがパケット内に実在するか確認します。
• 書き直しではなく、矛盾とその場所を求めます。32,768トークンの返答には、書き直したシーズン全体はそもそも収まりません。
• 差し替え済みの古い草稿は入れません。シーン12の2つの版が同じパケットにあると、古い小道具が現行のものとして引用されます。

同じ予算の考え方を、料金を変えて詳しく扱ったのがClaude Sonnet 4.6のコストガイドとClaude Opusの長文ドキュメントガイドです。

テキストパケットを準備する

このルートはテキストとimage_urlパートを受け付けます。スキャンした脚本で連続性をチェックするなら、OCRで検索可能なテキストと安定したシーンラベルが得られます。パケットを作る前に、破損した名前やシーン番号を直してください。テキストメッセージに貼ったPDFのURLは、文書としては読まれません。脚本、キャラクターノート、ショットリストを、安定したラベル付きのテキストとして書き出します。

CHARACTERS_V2
Mara: 32, photographer. Keeps a copper thermos with a blue band.
Jon: 35, composer. Owns the red leather case.

SCRIPT_V3 / scene 12
Mara puts the thermos on the railway bench. Jon carries the case.

SCRIPT_V3 / scene 18
Jon offers Mara the thermos.

1トークンあたり英字4文字というのは大まかなふるい分け用の目安であり、境界付近でリクエストの料金を出す方法ではありません。コード、名前、英語以外のテキストは、トークン化のされ方が異なります。200,000に対して十分な余裕を残し、システムプロンプトとツール定義も見積もりに含め、返ってきたusageで実際の数と照らし合わせてください。

発見をシーンの変更に落とし込む

このパケットでは、シーン12で水筒が最後に確認できる場所はMaraのところですが、シーン18では受け渡しなしにそれがJonの手に渡っています。有用な回答は、この空白を指摘し、選択肢を示します。

• シーン18の前にJonが取りに行く場面を見せる。 気配りを見せたいビートの場合です。
• Mara自身に取りに行かせる。 2人の距離を保ちたいシーンの場合です。

関係性のビートを選んでから、それを実現するセリフを1行頼みます。モデルの報告は空白を見つける助けになりますが、その行動が何を意味するかを決めるのは作者です。監査では、間にあるシーンをでっち上げて原典として引用させてはいけません。シリーズバイブルでも、同じやり方で、脚本が見せる前に和解を前提にしているシーンを見つけられます。最後に確立された関係の状態、最初に矛盾するシーン、足りない移行について尋ねてください。

まずPlaygroundで試す

1. Gemini 3.1 Pro Previewを開き、Playgroundに切り替えます。
2. CHARACTERSV2と、SCRIPTV3の2つのシーンを貼り付けます。受け渡しが描かれないまま水筒の持ち主が変わるのはどこかを尋ねます。
3. JonとMaraのどちらが取りに行くかを選び、そのビートを成立させるセリフを1行頼みます。

ストリーミングで送る

SPICY_API_KEYを設定し、同じシーンのパケットをアプリから送ります。ストリーミングなら、非ストリーミングで約100秒後にエッジで切断される問題を避けられます。実装の詳細はチャットガイドにあります。

INTENT_KEY=$(uuidgen)
curl --fail-with-body -sN --max-time 600 https://api.spicyapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $SPICY_API_KEY" \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $INTENT_KEY" \
  -D reply.headers -o reply.sse \
  -d '{
    "model": "google/gemini-3.1-pro-preview/chat",
    "stream": true,
    "stream_options": {"include_usage": true},
    "reasoning_effort": "low",
    "max_tokens": 4000,
    "response_format": {"type": "json_object"},
    "messages": [
      {"role": "system", "content": "Return JSON with conflicts and suggested_fixes arrays. Cite only supplied scene labels. Do not invent missing scenes."},
      {"role": "user", "content": "Fictional adults: Mara, 32, and Jon, 35. SCRIPT_V3 / scene 12: Mara leaves her blue-banded copper thermos on the railway bench. Jon carries his red case. SCRIPT_V3 / scene 18: Jon hands Mara the thermos. Identify any missing prop handoff."}
    ]
  }'

パケットの外にある情報のときだけツールを足す

正本のレコードが頻繁に変わるなら、キャラクターの参照はプロンプトの外に置きます。get_characterのような読み取り専用の限定的な関数をモデルに与え、アプリケーションがそのレコードを返すようにします。ターン数には上限を設けてください。同じ大きなパケットで4ラウンド回すと、入力の読み込み4回分のコストがかかることがあります。2つのシーンを固定で監査するなら、事実をプロンプトに入れるほうが簡単で安上がりです。

GoogleのネイティブなSearchやMapsのグラウンディングは別の統合です。このチャットルートは、アプリケーションが実行する関数を使います。ツールループの全体はチャットレシピで確認できます。

Agentに呼び出しを準備してもらう

連続性の監査を繰り返すなら、コーディングAgentにSpicyAPI Skillを使うよう頼みます。「google/gemini-3.1-pro-preview/chatを読み、その例を私の入力に合わせて調整して。実行する前にリクエストを見せて」。CLIでの照会はspicyapi models get google/gemini-3.1-pro-preview/chat --json、MCPでの照会はmodel: "google/gemini-3.1-pro-preview/chat"を指定したspicyapi_model_getです。チャットの呼び出しには、互換クライアントかチャットAPIを使います。メディアタスク用のコマンドでは、チャットの返答は生成されません。

成人向けコンテンツのプロジェクト

脚本のインデックス作成、連続性の監査、制作ノートには向いています。露骨な文章は安定しません。SpicyAPIはこのルートにコンテンツフィルターを追加していませんが、モデルがリクエストを断ったり、表現を和らげたりすることがあります。2026年9月のテストでは、L3 レベルの文章が最後まで完成したのは3件中1件、親密なシーンの執筆は9件中4件でした。親密なシーンのテストでは、リクエスト内でフィクションとして枠付けした場合は3件中3件が完成し、システムプロンプトだけでは3件中1件、直接のリクエストでは3件中0件でした。フィクションとしてのリクエストは、システムメッセージだけに頼るよりこのワークフローの良い出発点になりますが、信頼できる露骨な文章が主な成果物なら、別のモデルを選んでください。詳細はGemini 3.1 Proのレビューにあります。

よくある失敗

現在の料金の確認とPlaygroundでの動作確認は、モデルページから行えます。プレビュー版のモデルなので、本番トラフィックを担わせる前に、変更があった場合にどのモデルへ引き継ぐかを決めておいてください。