モデル比較

Gemini 3.7 Flash vs Qwen3.8 27B

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

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

スペックと料金

google logoGemini 3.7 Flashqwen logoQwen3.8 27B
提供元GoogleQwen
入力(100万トークンあたり)¥134.03¥80.41
出力(100万トークンあたり)¥670.13¥571.84
想定コスト(入力1,000・出力500トークン × 1,000回)¥469¥366
コンテキスト長1,048,576 トークン1,000,000 トークン
リリース日2026/8/132026/8/14
入力モダリティtext, image, video, file, audiotext, image, video
アリーナ 総合#9 · ELO 1,490#87 · ELO 1,436
アリーナ 日本語圏外圏外
アリーナ コーディング#24 · ELO 1,521#67 · ELO 1,498

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

どちらを選ぶべきか

  • 料金重視ならQwen3.8 27B。出力100万トークンあたり¥571.84で、Gemini 3.7 Flashより15%安くなります。
  • 総合の評価はアリーナ順位でGemini 3.7 Flashが上です(9位。Qwen3.8 27Bは87位)。
  • コーディングの評価はアリーナ順位でGemini 3.7 Flashが上です(24位。Qwen3.8 27Bは67位)。
  • 長い文書を扱うならGemini 3.7 Flash。コンテキスト長は1,048,576トークンで、Qwen3.8 27Bの1,000,000トークンより広くとれます。
  • 迷ったら両方を同じキーで試せます。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.7 Flash

発生しているエラーの原因と修正方法は以下の通りです。 --- ### 原因 データベースから取得した `order["price"]` の値が **文字列型 (`str`)** になっているためです。 Pythonでは文字列型と数値型の掛け算(数値計算)ができないため、`TypeError: unsupported operand type(s) for *: 'str' and 'int'` が発生しています。 --- ### 修正方法 用途(通貨の扱い)に応じて以下のいずれかの方法で修正します。 #### パターン1: `Decimal` を使う(推奨:金額計算で丸め誤差を防ぐ場合) 金融やECの金額計算では、浮動小数点数の誤差を避けるため `decimal.Decimal` を使うのが安全です。 ```python from decimal import Decimal def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) # price を Decimal に、quantity を int に変換して計算 total = sum(Decimal(str(order["price"])) * int(order["quantity"]) for order in orders) return {"user_id": user_id, "total":…
応答時間 8.4秒出力 1039 トークン

Qwen3.8 27B

## 原因 エラーの内容は以下です。 ```text TypeError: unsupported operand type(s) for *: 'str' and 'int' ``` これは、Pythonの`*`演算子で **文字列`str`** と **整数`int`** を掛けようとしているために起きます。 該当箇所はこれです。 ```python total = sum(order["price"] * order["quantity"] for order in orders) ``` エラーの型表示が `'str' and 'int'` になっているため、まず考えられるのは: ```python order["price"] が文字列 order["quantity"] が整数 ``` ということになります。 つまり、DBから取得した `price` が数値ではなく文字列として返ってきている可能性があります。 例えば: ```python order["price"] == "10.50" order["quantity"] == 2 ``` この場合: ```python "10.50" * 2 ``` となり、Pythonではエラーになります。 --- ## 修正方法 計算前に `price` を数値型に変換してください。 金額の計算には `float` よりも `decimal.Decimal` を使うことをおすすめします。 ### 修正例 ```python from decimal import Decimal…
応答時間 43.4秒出力 2428 トークン

コードレビュー

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

Gemini 3.7 Flash

ご提示いただいたコードは意図が明確でわかりやすいですが、**型安全性**、**エラーハンドリング**、**モダンな構文(可読性)**、**大規模データ時のパフォーマンス**の観点からいくつかの改善余地があります。 --- ### 主な改善ポイント 1. **型安全性の向上(`any` の排除)** - APIレスポンスの型(`ApiUser`, `ApiResponse`)と、関数が返す型(`User`)を明示的に定義します。 2. **エラーハンドリングの追加** - `fetch` は HTTP 4xx/5xx エラーでも例外を投げないため、`response.ok` の確認が必要です。 3. **可読性とモダンな記法の導入** - マジックナンバー `100` を定数化。 - 昔ながらの `for` ループを `filter` + `map`、あるいは `for...of` に置き換え。 - 文字列結合をテンプレートリテラルに変更。 - `hasMore` フラグ変数を減らし、ループ制御をシンプルに。 4. **URLパラメータの安全な構築** - `URLSearchParams` を使用することで、クエリパラメータの構築が安全かつ保守しやすくなります。 --- ### 改善後のコード ```typescript // 1. 型定義 interface ApiUser { id: string; first_name: string; last_name: string; email: string;…
応答時間 10.5秒出力 1571 トークン

Qwen3.8 27B

以下、指定された `fetchAllUsers` 関数について、**可読性・パフォーマンス・ベストプラクティス・堅牢性**の観点から改善点を整理します。最後に改善版コード例も提示します。 --- ## 1. 型安全性の欠如 ### 問題点 - 戻り値が `Promise<any[]>` になっており、呼び出し側で型を信頼できません。 - `response.json()` の結果 `data` も `any` 扱いになっており、APIのスキーマが型で表現されていません。 - `data.users` が `undefined` / `null` / 配列でない場合の防御がありません。 - `first_name` / `last_name` が `null` だと `undefined undefined` のような文字列になる可能性があります。 ### 改善案 - `RawUser`(APIレスポンス型)と `User`(表示用型)を分離し、型を定義する。 - `any` を避け、`unknown` を使い `typeof` / `Array.isArray` で検証する。 - 戻り値は `Promise<User[]>` にする。 ```typescript interface RawUser { id: string | number; first_name: string; last_name: string; email: string; status: string; } interface UsersResponse { use…
応答時間 83.7秒出力 5240 トークン

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.7 Flash

このクエリが遅い(および**集計結果が誤っている**)主な原因は、**「結合による行の爆発(デカルト積)」**と**「適切なインデックスの不足」**です。 --- ### 主な問題点 1. **集計の不整合と中間データの爆発(最大のボトルネック)** - 1つの商品に対して「注文(`order_details`)」と「レビュー(`reviews`)」を同時に結合しているため、**行数が「注文数 × レビュー数」に膨れ上がります**。 - 例: 注文100件、レビュー10件の商品がある場合、中間行は1,000行になり、`SUM(o.amount)` は正しい売上の10倍に計算されてしまいます。また、500万行規模では数千万〜数億行の中間テーブルがメモリ上に生成され、劇的に遅くなります。 2. **LEFT JOIN が INNER JOIN 化している** - `WHERE o.created_at >= '2024-04-01'` により、売上がない商品(`o.created_at` が NULL の行)は除外されます。 3. **インデックスの欠如** - 結合キー(`product_id`, `category_id`)や絞り込み条件(`is_active`, `status`, `created_at`)にインデックスがないため、全テーブルでフルスキャンが発生しています。 --- ### 最適化されたSQL 注文データとレビューデータを**事前にサブクエリ(CTE)で商品ごとに集計**してから結合します。これにより、行の爆発を防ぎ、計算…
応答時間 13.4秒出力 1924 トークン

Qwen3.8 27B

以下は **PostgreSQL 前提**の最適化です。 結論から言うと、このクエリは「インデックス不足」だけでは解決しにくく、**結合で行数が増える順番**と**集計の粒度**を直すのが効果的です。 --- ## 1. 主な問題点 ### ① `reviews` を注文関連に結合した後に集計すると行数が増える 現状: ```sql FROM products p LEFT JOIN order_details od ON od.product_id = p.id LEFT JOIN orders o ON o.order_id = od.order_id AND o.status = '完了' LEFT JOIN reviews r ON r.product_id = p.id ``` この場合、1つの製品について - 完了注文が 100 件 - レビューが 20 件 だとすると、結合結果は最大 **100 × 20 = 2000 行** になり得ます。 すると: ```sql COUNT(o.order_id) SUM(o.amount) ``` がレビュー数分だけ重複して集計され、**結果が正しくなくなる場合**があります。 また、行が増えるため処理時間も伸びます。 --- ### ② `order_details` を経由して `orders.amount` を合計している点 現状は: ```sql SUM(o.amount) ``` です。 ここで注意すべきは: - `orders.amount` が「受注単位の総額」である…
応答時間 407.1秒出力 22483 トークン

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

よくある質問

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

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

アカウントを作成してクレジットをチャージすれば、Gemini 3.7 FlashとQwen3.8 27BをブラウザのチャットとAPIの両方から呼び出せます。月額料金はありません。

Gemini 3.7 Flashの他の比較

Qwen3.8 27Bの他の比較