モデル比較

GPT-4.1 Mini vs Qwen3.7 Max

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

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

スペックと料金

openai logoGPT-4.1 Miniqwen logoQwen3.7 Max
提供元OpenAIQwen
入力(100万トークンあたり)¥71.48¥263.58
出力(100万トークンあたり)¥285.92¥790.75
想定コスト(入力1,000・出力500トークン × 1,000回)¥214¥659
コンテキスト長1,047,576 トークン1,000,000 トークン
リリース日2025/4/142026/5/21
入力モダリティimage, text, filetext
生成速度 (p50)
アリーナ 総合#172 · ELO 1,383#34 · ELO 1,473
アリーナ 日本語#135 · ELO 1,330圏外
アリーナ コーディング#164 · ELO 1,433#21 · ELO 1,525

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

どちらを選ぶべきか

  • 料金重視ならGPT-4.1 Mini。出力100万トークンあたり¥285.92で、Qwen3.7 Maxより64%安くなります。
  • 総合の評価はアリーナ順位でQwen3.7 Maxが上です(34位。GPT-4.1 Miniは172位)。
  • コーディングの評価はアリーナ順位でQwen3.7 Maxが上です(21位。GPT-4.1 Miniは164位)。
  • 長い文書を扱うならGPT-4.1 Mini。コンテキスト長は1,047,576トークンで、Qwen3.7 Maxの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…

GPT-4.1 Mini

エラーメッセージ ``` TypeError: unsupported operand type(s) for *: 'str' and 'int' ``` は、`order["price"]` が文字列 (`str`) 型であり、数値型 (`int`) との乗算ができないために発生しています。 原因は、`db.query` で取得した `price` がデータベース上では数値型であっても、Python側に渡る際に文字列として扱われていることが多いことです。 --- ### 修正方法 `order["price"]` を明示的に数値(たとえば `float`)に変換すればこの問題は解決します。 ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) total = sum(float(order["price"]) * order["quantity"] for order in orders) return {"user_id": user_id, "total": total, "orders": orders} ``` もし `quantity` も文字列なら同様に変換が必要です。 --- ### 補足 - `price` は通常小数点付き価格なので `float` に変換するのが自然です。 - `quantity` が整数型の場合は変換…
応答時間 2.8秒出力 325 トークン

Qwen3.7 Max

### 結論:エラーの原因 このエラーの原因は、**データベースから取得した `order["price"]`(または `order["quantity"]`)が数値型(`int` や `float`)ではなく、文字列型(`str`)として返ってきている**ことです。 Pythonでは本来 `"100" * 2` のような「文字列 × 整数」の演算は `"100100"` という文字列の繰り返しとして処理されますが、フレームワークやORMの内部処理、あるいは実際には `float` と `str` の演算であった場合などに `TypeError` として数学的な乗算エラーが送出されます。 いずれにせよ、**「数値計算をしたいのに、データが文字列になっている」** ことが根本原因です。これは、データベース側の `price` カラムが `VARCHAR` や `TEXT` 型で定義されている場合によく起こります。 --- ### 修正方法 アプローチは3つあります。状況に合わせて選択してください。 #### 1. Python側で型変換する(即効性のある修正) コード上で明示的に数値(`float` または `int`)にキャストします。価格には小数が含まれる可能性があるため、`float()` を使うのが安全です。 ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id…
応答時間 59.2秒出力 3324 トークン

コードレビュー

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

GPT-4.1 Mini

以下に、あなたの関数 `fetchAllUsers` に対する可読性・パフォーマンス・ベストプラクティスの観点からの改善点を提案します。 --- ## 1. 可読性の改善 - **型定義の追加** `any[]`は避け、APIのレスポンスやユーザー型に対して適切な型を定義しましょう。型が明確になると、コードの意図が分かりやすくなり保守性が向上します。 - **変数名の見直し** 例えば`data`よりは`responseData`の方が何のデータか伝わりやすいです。 - **forループより高階関数を活用** `for`ループでインデックスを使うより、`filter`+`map`の組み合わせの方が目的が明確になります。 --- ## 2. パフォーマンス(効率化) - **不要な変数の削減** `hasMore`や`currentPage`より、`while (true)`でbreak条件を書く形にすればシンプルです。 - **並列化の検討** もしページ数が多い場合は、全ページ数が分かるAPIであれば複数ページを並列リクエストする方が早くなります。ただし今回のAPI仕様ではページ数がわからないので現状は難しいです。 - **配列連結方法の見直し** `allUsers.push(...newUsers)`の方が効率的かつ簡潔です。 --- ## 3. ベストプラクティス - **エラーハンドリング** `fetch`や`response.json()`が失敗する可能性があるので、`try-cat…
応答時間 7.0秒出力 963 トークン

Qwen3.7 Max

ご提示いただいたコードは、ページネーションの処理やデータの整形など、基本的なロジックは正しく実装されています。 しかし、**TypeScriptの型安全性、エラーハンドリング、可読性、そして大規模データ時のパフォーマンス(メモリ消費)** の観点から、いくつか重要な改善点があります。 以下にレビュー結果と、改善後のコードを提案します。 --- ### 🔍 レビューポイント #### 1. 型安全性 (TypeScriptベストプラクティス) * **`any` の多用:** `Promise<any[]>` や `data` が `any` になっているため、TypeScriptの恩恵(補完やコンパイル時のエラー検知)が得られていません。APIレスポンスと返却用のインターフェースを定義すべきです。 * **プロパティアクセスの危険性:** `data.users` が存在しない(または `null` / `undefined`)場合にランタイムエラー(`TypeError`)が発生するリスクがあります。 #### 2. エラーハンドリングと堅牢性 * **HTTPステータスコードの未確認:** `fetch` はネットワークエラー(オフライン等)以外ではエラーを投げません(404や500でも成功とみなされます)。`response.ok` のチェックが必須です。 * **無限ループのリスク:** サーバー側のバグで常に100件返却され続けた場合、無限ループに陥ります。セーフティネット(最大ページ数や総件数のチェック)があると安心です。 #### 3. 可読性 *…
応答時間 73.1秒出力 3915 トークン

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…

GPT-4.1 Mini

このSQLは500万行の大規模なテーブルに対して複数のJOINを行い、さらに集計やフィルタリングをしているためパフォーマンスが悪いです。以下に改善点と最適化の提案を記載します。 --- ## 1. 適切なインデックスの追加 - **productsテーブル** - `is_active`にフィルタがあるため、 `(is_active, id, category_id, product_name)` を含むインデックスを検討。 —> `is_active`を効率よくフィルタリング+キーの読み込みを効率化 - **ordersテーブル** - `status`および `created_at`にフィルタがあるため `(status, created_at, order_id)` の複合インデックスを追加。 —> WHEREで絞ってJOINの絞り込みを効率化 - **order_detailsテーブル** - `product_id`, `order_id`の両方に結合条件があるため、 `(product_id, order_id)`か少なくとも`product_id`の索引を作成。 - **reviewsテーブル** - `product_id`にJOINしているのでインデックスを作成 `(product_id)` - **categoriesテーブル** - `id`が主キーなら問題なし。 --- ## 2. JOIN順序の見直し - 現状、`orders`表をL…
応答時間 8.7秒出力 1247 トークン

Qwen3.7 Max

提示されたSQLクエリには、**パフォーマンスを著しく低下させる構造的な問題(直積の発生)**と、**意図しないデータ抽出(暗黙のINNER JOIN)**、そして**インデックスの不足**という3つの重大な問題があります。 以下に最適化されたクエリと、必要なインデックス、そして改善点の詳細な解説を提示します。 --- ### 1. 最適化されたSQLクエリ ```sql WITH SalesAgg AS ( -- 1. 注文と注文詳細を先に集計し、商品IDごとの売上を作る SELECT od.product_id, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total_sales FROM orders o INNER JOIN order_details od ON od.order_id = o.order_id WHERE o.status = '完了' AND o.created_at >= '2024-04-01' GROUP BY od.product_id ) SELECT p.product_name, c.category_name, s.order_count, s.total_sales, -- 3. レビューの平均はLIMIT 50件に対してのみ計算する(相関サブクエリ) (SELECT AVG(r.rating) FROM reviews r WHERE r.product_id = p.id) AS a…
応答時間 81.9秒出力 4393 トークン

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

よくある質問

GPT-4.1 MiniとQwen3.7 Max、料金はどちらが安いですか?
出力100万トークンあたりGPT-4.1 Miniは¥285.92、Qwen3.7 Maxは¥790.75で、GPT-4.1 Miniの方が安くなります(FastMetalの円建て単価・税別)。
GPT-4.1 MiniとQwen3.7 Maxのコンテキスト長の違いは?
GPT-4.1 Miniは1,047,576トークン、Qwen3.7 Maxは1,000,000トークンです。
GPT-4.1 MiniとQwen3.7 Max、評価が高いのはどちらですか?
公開アリーナの順位ではQwen3.7 Maxが上です(GPT-4.1 Mini 135位、Qwen3.7 Max 34位)。順位はリーダーボードの更新で変わります。
GPT-4.1 MiniとQwen3.7 Maxを同じAPIキーで使えますか?
はい。FastMetalのOpenAI互換エンドポイントで、model に "gpt-4.1-mini" または "qwen3.7-max" を指定するだけで切り替えられます。料金はそれぞれの単価で、同じ前払い残高から従量課金されます。

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

アカウントを作成してクレジットを追加すれば、GPT-4.1 MiniとQwen3.7 MaxをブラウザのチャットとAPIの両方から呼び出せます。月額料金はありません。

GPT-4.1 Miniの他の比較

Qwen3.7 Maxの他の比較