モデル比較

Fugu Max vs Qwen3.8 27B

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

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

スペックと料金

Fugu Maxqwen logoQwen3.8 27B
提供元Sakana AIQwen
入力(100万トークンあたり)¥357.4¥33.6
出力(100万トークンあたり)¥1,072.2¥420
想定コスト(入力1,000・出力500トークン × 1,000回)¥894¥244
コンテキスト長1,000,000 トークン1,000,000 トークン
リリース日2026/9/112026/8/14
入力モダリティtext, image, filetext, image, video
生成速度 (p50)1278 トークン/秒 (n=26)46 トークン/秒 (n=25)
アリーナ 総合圏外#102 · ELO 1,437
アリーナ 日本語圏外#92 · ELO 1,397
アリーナ コーディング圏外#82 · ELO 1,499

料金はFastMetalの単価(税別)です。

順位データ: LMArena leaderboard dataset(lmarena-ai/leaderboard-dataset、CC BY 4.0、2026-10-22時点)。カテゴリ名の対応付けとスコアの丸めはFastMetalによる。

どちらを選ぶべきか

  • 料金重視ならQwen3.8 27B。出力100万トークンあたり¥420で、Fugu Maxより61%安くなります。
  • 迷ったら両方を同じキーで試せます。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…

Fugu Max

### エラーの原因 データベースから取得した `order["price"]` の値が **文字列型(`str`)** になっているためです。 Pythonでは文字列(`str`)と数値(`int`)をそのまま掛け算(`*`)することができず、`TypeError: unsupported operand type(s) for *: 'str' and 'int'` が発生しています。 主な要因として以下のいずれかが考えられます。 1. データベースの `price` カラムが `VARCHAR` や `TEXT` などの文字列型で定義されている。 2. データベースの `DECIMAL` / `NUMERIC` 型が、利用しているDBライブラリの設定により文字列として取得されている。 --- ### 修正方法 #### 1. Python側で数値型に変換する(即時修正) 金額の計算では、浮動小数点誤差を防ぐために **`Decimal`**(小数を扱う場合)または **`int`**(日本円など小数を扱わない場合)へのキャストが推奨されます。 ##### パターンA: 小数を扱う可能性がある場合(`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)…
応答時間 9.0秒出力 1250 トークン

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…

Fugu Max

# レビュー結果 ## 1. 型安全性(最優先) `any[]` と `data: any` により、型チェックが完全に無効化されています。APIレスポンスの形・返り値の形を明示すべきです。 - 返り値 `Promise<any[]>` → 専用の `User` 型を定義 - `data` → APIレスポンス型(`UsersResponse`)を定義 - そうすることで `first_name` のtypoなどをコンパイル時に検出できます ## 2. エラーハンドリング - `response.ok` のチェックがありません。404や500でもそのまま `json()` を呼び、`data.users` が `undefined` になって実行時エラーになります - `fetch` / `json()` の失敗をハンドリングしていません(呼び出し側で catch する設計ならコメントで明示を) - キャンセル用 `AbortSignal` を受け取れるようにすると、アンマウント時のリーク防止に有効です ## 3. 可読性 - `data.users[i]` の3回参照 → `for...of` で変数化 - 文字列連結 `+ " "` → テンプレートリテラル - `if (status !== "deleted")` よりも `if (status === "deleted") continue;` の早期 continue の方がネストが浅い - マジックナンバー `100` が3箇所に散在 → 定数 `PAGE_SIZE` に - `let hasMore…
応答時間 16.6秒出力 1931 トークン

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…

Fugu Max

PostgreSQL 前提で説明します。まず大きな問題は **`reviews` を同時に LEFT JOIN しているため、注文行がレビュー件数分だけ増殖する** ことです。たとえば注文が100行、レビューが20件ある商品では、集計前に 100×20=2000 行になり、`COUNT(o.order_id)` や `SUM(o.amount)` がレビュー件数倍に膨らみます。`AVG(r.rating)` は同じ評価が同じ回数だけ繰り返されるため見かけ上は変わりませんが、COUNT/SUM は誤りになります。 また、 - `LEFT JOIN ... orders o` に対して `WHERE o.created_at >= ...` を書いているため、実質 `INNER JOIN` になっています。 - `GROUP BY p.product_name, c.category_name` は同名商品・同名カテゴリをまとめてしまいます。`p.id, c.id` で集計すべきです。 - `o.amount` が「注文全体の金額」なら、`order_details` と結合すると注文金額が明細行数分重複します。売上は `od.amount` や `od.quantity * od.unit_price` を使うべきか確認してください。 - インデックスが `products(id)` と `orders(order_id)` しかなく、結合・絞り込みに不足しています。 --- ## 改善クエリ例 売上集計を先に商品単位で行い、上位50商品に絞ってからレビュー平均を取りま…
応答時間 101.9秒出力 12432 トークン

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 トークン

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

よくある質問

Fugu MaxとQwen3.8 27B、料金はどちらが安いですか?
出力100万トークンあたりFugu Maxは¥1,072.2、Qwen3.8 27Bは¥420で、Qwen3.8 27Bの方が安くなります(FastMetalの円建て単価・税別)。
Fugu MaxとQwen3.8 27Bのコンテキスト長の違いは?
Fugu Maxは1,000,000トークン、Qwen3.8 27Bは1,000,000トークンです。
Fugu MaxとQwen3.8 27Bを同じAPIキーで使えますか?
はい。FastMetalのOpenAI互換エンドポイントで、model に "fugu-max" または "qwen3.8-27b" を指定するだけで切り替えられます。料金はそれぞれの単価で、同じ前払い残高から従量課金されます。

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

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

Fugu Maxの他の比較

Qwen3.8 27Bの他の比較