モデル比較

Gemini 3.1 Pro Preview vs Gemini 3.5 Flash

料金・コンテキスト長・実際の回答で比較(2026年9月時点)

Gemini 3.1 Pro Preview(Google)とGemini 3.5 Flash(Google)を、FastMetalのゲートウェイで実際に呼び出せる条件で比較します。どちらも同じOpenAI互換エンドポイントとAPIキーから利用でき、切り替えは model の文字列を変えるだけです。

スペックと料金

google logoGemini 3.1 Pro Previewgoogle logoGemini 3.5 Flash
提供元GoogleGoogle
入力(100万トークンあたり)¥357.4¥268.05
出力(100万トークンあたり)¥2,144.4¥1,608.3
想定コスト(入力1,000・出力500トークン × 1,000回)¥1,430¥1,072
コンテキスト長1,048,576 トークン1,048,576 トークン
リリース日2026/2/192026/5/19
入力モダリティaudio, file, image, text, videotext, image, video, file, audio
生成速度 (p50)
アリーナ 総合#15 · ELO 1,487#25 · ELO 1,478
アリーナ 日本語#9 · ELO 1,494#19 · ELO 1,468
アリーナ コーディング#28 · ELO 1,520#55 · ELO 1,506

料金はFastMetalの円建て単価(税別)。アリーナ順位は公開リーダーボードの最新取得時点の値です。

どちらを選ぶべきか

  • 料金重視ならGemini 3.5 Flash。出力100万トークンあたり¥1,608.3で、Gemini 3.1 Pro Previewより25%安くなります。
  • 総合の評価はアリーナ順位でGemini 3.1 Pro Previewが上です(15位。Gemini 3.5 Flashは25位)。
  • 日本語の評価はアリーナ順位でGemini 3.1 Pro Previewが上です(9位。Gemini 3.5 Flashは19位)。
  • コーディングの評価はアリーナ順位でGemini 3.1 Pro Previewが上です(28位。Gemini 3.5 Flashは55位)。
  • 迷ったら両方を同じキーで試せます。model の文字列を変えるだけで切り替わり、料金はそれぞれの単価で従量課金されます。

同じプロンプトへの実際の回答

FastMetalのゲートウェイが返した回答をそのまま並べています。ベンチマークの数字ではなく、実際の出力です。

このエラーをデバッグして

以下のエラーがPythonアプリケーションで発生しています。原因を特定して修正してください。 Traceback (most recent call last): File "app.py", line 23, in get_user_orders total = sum(order["price"] * order["quantity"] for order in orders) TypeError: unsupport…

Gemini 3.1 Pro Preview

このエラーの**原因**と**修正方法**について解説します。 ### 1. 原因:取得したデータが「文字列(str)」になっている エラーメッセージの `TypeError: unsupported operand type(s) for *: 'str' and 'int'` は、**「文字列(`str`)と数値(`int`)で掛け算などの算術演算を行おうとした」**ということを意味しています。 データベース(MySQLやSQLiteなど)からデータを取得した際、`price`(価格)や `quantity`(数量)のカラムが数値型ではなく、**文字列としてPythonに渡されている**ことが根本的な原因です。 ※Pythonでは文字列と整数の掛け算(例: `"100" * 2`)を行うと `"100100"` という文字列の繰り返しになり、その後 `sum()` で合算しようとした際に型エラーを引き起こします。 ### 2. 修正方法:数値型(int や float)に変換する 計算を行う前に、取得したデータを正しい数値型に変換(キャスト)してあげる必要があります。 - `price`(価格)は小数が含まれる可能性があるため `float` - `quantity`(数量)は整数のため `int` #### 修正例 1(最もシンプルな修正) ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id…
応答時間 31.5秒出力 3663 トークン

Gemini 3.5 Flash

このエラーの原因は、データベースから取得した `price`(価格)または `quantity`(数量)のいずれか(あるいは両方)が、**数値(intやfloat)ではなく文字列(str)としてPython側に渡されているため**です。 Pythonでは、文字列型(`str`)と数値型(`int`)を直接掛け算しようとすると、この `TypeError` が発生します。 --- ### 解決策 この問題を解決するには、主に3つのアプローチがあります。 #### 解決策1:Python側で型変換(キャスト)する(最も手軽な修正) 計算する直前に、Pythonの `float()` や `int()` を使って明示的に数値型に変換します。 **修正後のコード:** ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) # price を float に、quantity を int に変換して計算する total = sum(float(order["price"]) * int(order["quantity"]) for order in orders) return {"user_id": user_id, "total": total, "orders": orders} ``` > **💡 金額計算のベストプラク…
応答時間 27.0秒出力 3911 トークン

コードレビュー

以下のTypeScript関数をレビューして、可読性・パフォーマンス・ベストプラクティスの観点から改善点を提案してください。 async function fetchAllUsers(page: number = 1): Promise<any[]> { let allUsers: any[] = []; let hasMore = true; let currentPage = page; while (hasMo…

Gemini 3.1 Pro Preview

ご提示いただいたTypeScript関数は、ページネーションされたAPIからデータを取得し、フィルタリングと整形を行うという基本的な要件を満たしていますが、**型安全性の欠如、エラーハンドリングの漏れ、モダンなJavaScript/TypeScriptの記法を活用しきれていない点**など、いくつかの改善の余地があります。 「ベストプラクティス」「可読性」「パフォーマンス」の3つの観点からレビューと改善案を提案します。 --- ### 1. ベストプラクティス(TypeScript・堅牢性)の改善 * **`any` の排除:** 戻り値や変数に `any[]` が使われており、TypeScriptの最大のメリットである型安全性が失われています。APIからのレスポンス型と、整形後のユーザー型を `interface` または `type` で定義するべきです。 * **エラーハンドリングの追加:** ネットワークエラーや、サーバーからのエラーレスポンス(500や404など)が発生した場合、現在のコードではアプリケーションがクラッシュするか、予期せぬ動作をします。`try...catch` と `response.ok` のチェックが必要です。 * **マジックナンバーの排除:** `100` という制限値がURLと判定条件の2箇所にハードコードされています。定数として切り出すことで、仕様変更時のバグを防ぎます。 ### 2. 可読性の改善 * **モダンな配列操作メソッドの利用:** 伝統的な `for` ループと `dat…
応答時間 23.0秒出力 2782 トークン

Gemini 3.5 Flash

ご提示いただいたTypeScript関数は、ページネーションを用いて全ユーザーを再帰的に取得する実用的なコードです。 このコードをより良くするために、**「型安全性(TypeScriptの強み)」「エラーハンドリング」「可読性(モダンJS/TS構文)」「堅牢性」**の観点からレビューし、改善点を提案します。 --- ### 主な改善点 #### 1. 型安全性 (TypeScript ベストプラクティス) * **問題点**: `any[]` や暗黙の `any` が使われており、型安全性が失われています。 * **改善策**: APIのレスポンス型(`ApiUser`)と、この関数が返すユーザー型(`User`)を明示的に定義します。 #### 2. エラーハンドリング (堅牢性) * **問題点**: `fetch` の失敗(ネットワークエラー)や、ステータスコードが 200 以外(404, 500など)の場合の考慮がありません。また、`response.json()` が失敗した際、アプリケーションがクラッシュする可能性があります。 * **改善策**: `try-catch` ブロックを追加し、`response.ok` をチェックします。 #### 3. 可読性の向上 (モダンなJavaScript/TypeScript) * **問題点**: 昔ながらの `for` ループが使われており、コードが冗長です。また、文字列結合 `+ " "` が使われています。 * **改善策**: * 配列の `filter` と `…
応答時間 19.2秒出力 2904 トークン

SQLクエリの最適化

以下のSQLクエリは500万行のテーブルに対して実行すると30秒以上かかります。最適化してください。 SELECT p.product_name, c.category_name, COUNT(o.order_id) as order_count, SUM(o.amount) as total_sales, AVG(r.rating) as avg_rating FROM products p LEFT JOIN…

Gemini 3.1 Pro Preview

500万行規模のテーブルで30秒以上かかる場合、**「インデックスの不足」**だけでなく、SQLの構造そのものによる**「行数の爆発(直積/Fan-out)」**と**「誤ったJOINの解釈」**が大きな原因となっています。 特に元のクエリは、パフォーマンスが悪いだけでなく、**集計結果(売上やレビューの平均)が間違った数値になるバグ**を抱えています。 以下に最適化したクエリと、その改善点(インデックス追加含む)を解説します。 --- ### 1. 最適化したSQLクエリ 集計処理をサブクエリ(CTE)に分割し、結合前に行数を圧縮するアプローチに変更します。 ```sql WITH target_orders AS ( -- ① 必要な注文データだけを先に絞り込む SELECT order_id FROM orders WHERE status = '完了' AND created_at >= '2024-04-01' ), product_sales AS ( -- ② 商品ごとの売上・注文数を集計する SELECT od.product_id, COUNT(DISTINCT od.order_id) AS order_count, -- ※もしamountがorder_detailsにあるなら SUM(od.amount) とするべきです SUM(o.amount) AS total_sales FROM order_details od INNER JOIN orders o ON o.…
応答時間 33.1秒出力 4040 トークン

Gemini 3.5 Flash

提供されたクエリが低速な理由は、**「インデックスの不足」**だけでなく、**「データ構造の掛け算(ファンアウト)による中間データの爆発」**および**「LEFT JOINの不適切なフィルタリング」**という致命的な構造的問題があるためです。 このクエリを最適化し、数秒〜ミリ秒単位まで高速化するための改善策と、修正版のSQLを提案します。 --- ### 主な問題点 1. **ファンアウト(重複カウント)によるパフォーマンス低下とデータ不整合** `order_details`(1対多)と `reviews`(1対多)を同時に `LEFT JOIN` してから `GROUP BY` しているため、1つの商品に対して「注文数 × レビュー数」の掛け算(デカルト積)が発生します。 * **性能への影響:** 500万行のデータに対してこれを行うと、中間メモリが破裂し極端に遅くなります。 * **データ整合性のバグ:** `SUM(o.amount)` や `COUNT(o.order_id)` の値が、レビューの件数分だけ倍増し、**不正確な集計値**になります。 2. **WHERE句による LEFT JOIN の無効化(インナージョイン化)** `LEFT JOIN orders` としているにもかかわらず、`WHERE o.created_at >= '2024-04-01'` と指定しているため、注文がない商品(`o.created_at` が NULL になるもの)がすべて除外されてしまい、実質的に `INNER JOIN` になっていま…
応答時間 27.4秒出力 4048 トークン

他のプロンプトでも比較する →

よくある質問

Gemini 3.1 Pro PreviewとGemini 3.5 Flash、料金はどちらが安いですか?
出力100万トークンあたりGemini 3.1 Pro Previewは¥2,144.4、Gemini 3.5 Flashは¥1,608.3で、Gemini 3.5 Flashの方が安くなります(FastMetalの円建て単価・税別)。
Gemini 3.1 Pro PreviewとGemini 3.5 Flashのコンテキスト長の違いは?
Gemini 3.1 Pro Previewは1,048,576トークン、Gemini 3.5 Flashは1,048,576トークンです。
Gemini 3.1 Pro PreviewとGemini 3.5 Flash、評価が高いのはどちらですか?
公開アリーナの順位ではGemini 3.1 Pro Previewが上です(Gemini 3.1 Pro Preview 9位、Gemini 3.5 Flash 19位)。順位はリーダーボードの更新で変わります。
Gemini 3.1 Pro PreviewとGemini 3.5 Flashを同じAPIキーで使えますか?
はい。FastMetalのOpenAI互換エンドポイントで、model に "gemini-3.1-pro-preview" または "gemini-3.5-flash" を指定するだけで切り替えられます。料金はそれぞれの単価で、同じ前払い残高から従量課金されます。

どちらも同じAPIキーで試せます

アカウントを作成してクレジットを追加すれば、Gemini 3.1 Pro PreviewとGemini 3.5 FlashをブラウザのチャットとAPIの両方から呼び出せます。月額料金はありません。

Gemini 3.1 Pro Previewの他の比較

Gemini 3.5 Flashの他の比較