OrcaRouter 上で Google: Nano Banana Pro (Gemini 3 Pro Image Preview)（google）と Google: Gemini 3.1 Pro Preview Custom Tools（google）を直接比較——価格、コンテキストウィンドウ、レイテンシ、スループット、benchmark 品質を並べて示し、ワークロードに最適なモデルを選べます。
| 指標 | Google: Nano Banana Pro (Gemini 3 Pro Image Preview) | Google: Gemini 3.1 Pro Preview Custom Tools | 結論 |
|---|---|---|---|
| 入力 $/100万 | — | $4.00 | — |
| 出力 $/100万 | — | $18.00 | — |
| コンテキスト | 66K | 1M | Google: Gemini 3.1 Pro Preview Custom Tools は Google: Nano Banana Pro (Gemini 3 Pro Image Preview) より 94% 大きいコンテキストウィンドウに対応します。 |
| p50 レイテンシ | 4290 ms | 5312 ms | 中央値で、Google: Nano Banana Pro (Gemini 3 Pro Image Preview) は Google: Gemini 3.1 Pro Preview Custom Tools より 19% 速く応答します。 |
| スループット | — | 710 tok/s | — |
| 品質 | 5.0 | 10.0 | 総合品質指数で、Google: Gemini 3.1 Pro Preview Custom Tools は Google: Nano Banana Pro (Gemini 3 Pro Image Preview) より 50% 高いスコアです。 |
レイテンシに敏感なワークロードでは、Google: Nano Banana Pro (Gemini 3 Pro Image Preview) の方が最初の token を早く返します。 benchmark 品質では、Google: Gemini 3.1 Pro Preview Custom Tools が総合指数で先行します。
Google: Nano Banana Pro (Gemini 3 Pro Image Preview) と Google: Gemini 3.1 Pro Preview Custom Tools はいずれも同じ OrcaRouter エンドポイント経由でプロバイダー原価・token 加算ゼロで利用できるため、両者の切り替えは 1 行の変更で済み、以下の数値がそのまま実際の支払額になります。この比較はライブ料金、公表されている context window、そして OrcaRouter 自身が測定した latency と throughput を取得しており、ベンダーの宣伝用 benchmark に頼るのではなく、あなた固有のワークロードに対してコストとパフォーマンスを比較検討できます。適切な選択はほぼ常にトラフィックの形——プロンプト長、生成するテキスト量、ユーザーがどれだけ latency に敏感か、そして推論の難しさ——に左右されるため、以下のセクションでは 1 つの次元ずつこの判断を分解し、具体的な推奨で締めくくります。二つのモデルのいずれかで指標が欠けている場合、その行は推測せずに省いてあるので、ここでのすべての主張は実際の数値に裏づけられています。
これらのモデルの一方または両方は、ここでは token 単位の料金を公開していません(無料枠、呼び出し単位、または未価格設定のモデルの可能性があります)。そのためコスト列は目安として扱い、予算を組む前に各モデル自身のページでライブレートを確認してください。
Google: Nano Banana Pro (Gemini 3 Pro Image Preview) は最大 66K token の context を受け付け、Google: Gemini 3.1 Pro Preview Custom Tools は 1M を受け付けます。context window は、単一リクエストで送信できるソース素材——ドキュメント、コード、これまでの会話——の量の上限を定めます。ウィンドウが大きいほど長い入力のチャンク分割や検索の配管を省けますが、送信した分はすべて入力 token レートで課金されるため、大きなウィンドウは割引ではなく能力です。ページ上の最大の数値ではなく、ワークロードが現実的に生み出す最長の単一リクエストにウィンドウを合わせてください。また、どのモデルでも非常に長い context の終盤では品質が低下しうることを念頭に置いてください。大きなウィンドウは、あらゆるリクエストを上限まで詰め込む免罪符ではなく、たまに来る長い入力への余裕として扱うのが最善です。
latency と throughput は、本番環境でのモデルの体感を左右します。中央値(p50)の応答 latency は、典型的なリクエストが最初の token を受け取るまでの待ち時間であり、throughput(1 秒あたりの token 数)は開始後に応答がストリーミングされる速さを決めます。対話型チャットや agent ループでは、ユーザーが最初の token を待っているため低い p50 latency が最も重要です。バッチ生成や長文出力では、応答が長いため throughput が全体の所要時間を支配します。上の 7 日間トレンドチャートは、各モデルの latency が安定しているか変動しているかを示し、単一の宣伝数値では隠れてしまう点を明らかにします——平均は優秀でもテールがばらつくモデルは、厳格な p95 SLA を満たせないことがあります。製品に latency の予算があるなら、中央値と曲線の形の両方を読み、エンドツーエンドの latency にはネットワークのホップや、モデルの周りで行う検索・ツール呼び出しも含まれることを忘れないでください。
benchmark スコアは能力を近似しますが、自分のプロンプトでのテストの代わりにはなりません。ここに表示される総合品質指数は複数の公開評価を集約したもので、パーセンタイルは各モデルがカタログ内の比較可能な全モデルの中でどこに位置するかを示します——有用な絞り込みの目安であり、あなたのタスクでの保証ではありません。汎用知能指数で先行するモデルでも、あなたの領域(コーディング、抽出、多言語、長 context 推論)では劣ることがあります。benchmark で候補を絞り込んだうえで、代表的なトラフィックの一部で両モデルを実際に走らせてください。トップラインの数値ではなく、あなたのユースケースに合う具体的な指数に注目してください。コーディング中心の製品はコーディング指数を、リサーチアシスタントは推論指数を重視すべきです。benchmark はモデルが更新されると古くなるため、自分の評価セットで確認する出発点の仮説として扱ってください。
コストが決定的な制約なら、実際の入力対出力の比率で安いモデルから始め、品質が届かない場合にのみ上位へ移してください。応答性が優先なら——ユーザー向けチャット、agent、誰かが待っているあらゆる場面——わずかな価格差よりも p50 latency と throughput を重視してください。最も負荷の高い推論、コーディング、長 context の作業に取り組むなら、benchmark と context window の勝者を主役にし、割に合う場面では高いレートを受け入れてください。両モデルは同じ API の背後にあるため、低リスクな手は、実トラフィックの一部を両者に振り分け、自分のプロンプトでコスト・latency・回答品質を比較してから決めることです。よくあるパターンは階層化(tier)です。簡単で大量のリクエストの大半を安いか速いモデルに送り、より強力なモデルは本当に必要なリクエストのために取っておくことで、コストのごく一部で品質の恩恵の大半を得られます。どれを選んでも、切り替えは可逆に保ってください——モデル名を 1 行変えるだけで、数値や要件が変わった瞬間にトラフィックを元に戻せます。
過去7日間で、Google: Nano Banana Pro (Gemini 3 Pro Image Preview) の方が中央値応答レイテンシが低く保たれています。