モデル比較

Claude Fable 5.1 vs Claude Opus 5

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

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

スペックと料金

anthropic logoClaude Fable 5.1anthropic logoClaude Opus 5
提供元AnthropicAnthropic
入力(100万トークンあたり)¥1,787¥893.5
出力(100万トークンあたり)¥8,935¥4,467.5
想定コスト(入力1,000・出力500トークン × 1,000回)¥6,255¥3,127
コンテキスト長1,000,000 トークン1,000,000 トークン
リリース日2026/9/12026/7/24
入力モダリティtext, image, filetext, image, file
アリーナ 総合#3 · ELO 1,504#9 · ELO 1,493
アリーナ 日本語圏外#6 · ELO 1,500
アリーナ コーディング#34 · ELO 1,517#11 · ELO 1,533

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

どちらを選ぶべきか

  • 料金重視ならClaude Opus 5。出力100万トークンあたり¥4,467.5で、Claude Fable 5.1より50%安くなります。
  • 総合の評価はアリーナ順位でClaude Fable 5.1が上です(3位。Claude Opus 5は9位)。
  • コーディングの評価はアリーナ順位でClaude Opus 5が上です(11位。Claude Fable 5.1は34位)。
  • 迷ったら両方を同じキーで試せます。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…

Claude Fable 5.1

## 原因 エラーメッセージ `unsupported operand type(s) for *: 'str' and 'int'` は、`order["price"]` が **文字列(str)** として返ってきていることを示しています。`quantity` は int なので、`"1200" * 3` のような演算になり失敗しています。 `price` が文字列になる典型的な原因は次のいずれかです。 1. **DBのカラム型が `VARCHAR`/`TEXT` になっている**(本来は `DECIMAL` や `INTEGER` にすべき) 2. **DBドライバやラッパー(`db.query`)が値を文字列で返している**(例:SQLite で型宣言が曖昧、あるいは独自ラッパーが全部文字列化している) 3. データ投入時に文字列として `INSERT` された行が混在している ## 修正方法 ### 根本対策(推奨):DBスキーマを直す 金額を文字列で保存しているのが問題なら、カラム型を数値型に変更します。 ```sql -- MySQL / PostgreSQL の例 ALTER TABLE orders MODIFY price DECIMAL(10, 2) NOT NULL; -- MySQL ALTER TABLE orders ALTER COLUMN price TYPE DECIMAL(10, 2) USING price::DECIMAL; -- PostgreSQL ``` 金額計算には浮動小数点誤差を避けるため `DEC…
応答時間 21.8秒出力 1362 トークン

Claude Opus 5

# エラーの原因 `order["price"]` が **文字列型 (`str`)** で返ってきています。`order["quantity"]` は `int` なので、`str * int` の演算になり `TypeError` が発生しました。 Python では `"100" * 3` は `"100100100"` という文字列の繰り返しになり、`3 * "100"` も同様です。ただし今回は `str * int` の順で、かつエラーになっているので、内部的には `price` が `Decimal` ではなく `str` として渡り、`quantity` 側が `int` 以外(あるいは逆順)…という細かい話は置いておき、要点は **DB から取得した `price` が数値型になっていない** ことです。 ## なぜ文字列になるのか(典型的な原因) | 原因 | 説明 | |---|---| | カラム型が `VARCHAR`/`TEXT` | `price` が数値カラムとして定義されていない | | DB ドライバの型変換設定 | MySQL の `DECIMAL` を文字列で返すドライバがある(例: `mysqlclient` の一部設定、`PyMySQL` の `conv` 設定) | | SQLite の型の緩さ | SQLite は宣言型と実際の格納型が一致しないことがある | | ORM/ラッパー層の仕様 | 自前の `db.query` が全カラムを `str` で返している | まずは実際の型を確認してください。 ```pytho…
応答時間 34.2秒出力 2190 トークン

コードレビュー

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

Claude Fable 5.1

以下、観点ごとに指摘と改善案をまとめます。 ## 1. 型安全性(最優先) `any[]` だと戻り値の構造がまったく保証されず、呼び出し側でも補完・型チェックが働きません。API のレスポンス型と返却する型を分けて定義しましょう。 ```ts interface ApiUser { id: string; first_name: string; last_name: string; email: string; status: "active" | "inactive" | "deleted"; } interface ApiUsersResponse { users: ApiUser[]; // total や has_more が返るならここに追加 } export interface User { id: string; name: string; email: string; } ``` ## 2. エラーハンドリングの欠如 - `response.ok` を確認していないため、404/500 でも `.json()` を試みてしまい、意図しない例外や `data.users` が `undefined` で `TypeError` になります。 - ネットワークエラー時の挙動が未定義です。 - API 側の不具合でずっと 100 件返し続けると無限ループになります(安全弁がない)。 ## 3. 可読性 - インデックス付き `for` + `data.users[i]` の繰り返しは冗長。`filter` /…
応答時間 42.1秒出力 2619 トークン

Claude Opus 5

# コードレビュー ## 総評 ページネーションのロジック自体は正しく動作しますが、**型安全性の欠如**と**エラーハンドリングの不在**が最も重大な問題です。特に `any[]` の使用はTypeScriptを使う意義を大きく損なっています。以下、優先度順に指摘します。 --- ## 🔴 重大な問題 ### 1. `any` 型による型安全性の喪失 `Promise<any[]>` と `data.users[i]` の型が不明なため、コンパイラの検証が一切効きません。`data.users` が `undefined` の場合はランタイムエラーになりますが、コンパイル時には検出されません。 ```typescript // APIレスポンスの型を定義 interface ApiUser { id: string; first_name: string; last_name: string; email: string; status: "active" | "suspended" | "deleted"; } interface UsersResponse { users: ApiUser[]; } // 戻り値の型も明示 interface User { id: string; name: string; email: string; } ``` 外部入力を信頼できない場合は、zod などでランタイムバリデーションを併用するのが理想です。 ```typescript const UsersResponseSch…
応答時間 40.9秒出力 3042 トークン

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…

Claude Fable 5.1

## 問題点の整理 このクエリは「遅い」だけでなく**結果も正しくない**可能性が高いです。まずそこから整理します。 ### 1. 【最重要】JOIN のファンアウトで集計値が壊れている `order_details` と `reviews` を同じ商品に対して同時に JOIN しているため、行数が「注文明細数 × レビュー数」に膨張します。 - 注文10件・レビュー5件の商品 → 50行になり、`COUNT`/`SUM` は **5倍**に、`AVG(rating)` は注文数で重み付けされた値になる - パフォーマンス悪化の主因でもあり(中間結果が数億行になり得る)、正しさの面でも致命的です ### 2. LEFT JOIN が実質 INNER JOIN になっている `WHERE o.created_at >= '2024-04-01'` があるため、注文のない商品は NULL 判定で落ちます。`LEFT JOIN` にする意味がなく、オプティマイザの選択肢を狭めるだけです。`NULLS LAST` も意味を持ちません。 ### 3. インデックス不足 - `order_details(product_id)` / `order_details(order_id)` がない → 500万行の全件スキャン+Hash Join - `orders(status, created_at)` がない → 絞り込みに使えない - `reviews(product_id)` がない ### 4. GROUP BY が文字列カラム `product_name`, `cate…
応答時間 48.9秒出力 3436 トークン

Claude Opus 5

## まず結論 このクエリは「遅い」だけでなく **結果が間違っている(数値が水増しされている)** 可能性が高いです。原因は同じ根っこ(結合の多重展開)なので、正しく書き直すと速度も劇的に改善します。 以下 PostgreSQL 前提(`NULLS LAST` / `true` から判断)で説明します。 --- ## 1. 問題点の整理 ### ① 致命的:`order_details` と `reviews` の多重展開(fan-out) `products` に対して `order_details`(1商品にN明細)と `reviews`(1商品にMレビュー)を**並列に**LEFT JOINしているため、中間結果が **N × M 行** に爆発します。 - ある商品に明細100件・レビュー50件 → 中間行 5,000行 - `COUNT(o.order_id)` は **レビュー件数倍**、`SUM(o.amount)` も **レビュー件数倍** に膨張 - `AVG(r.rating)` は各評価が均等に複製されるため値は偶然合いますが、無駄な行を大量に平均している 500万行テーブルでこれをやると中間結果が数億行になり、ソート/ハッシュ集約が `work_mem` を溢れてディスクスピルします。**30秒の主因はほぼこれです。** ### ② `LEFT JOIN` + `WHERE o.created_at >= ...` が矛盾 `WHERE` で外側テーブルの列を非NULL条件にすると、LEFT JOIN は実質 INNER JOIN…
応答時間 90.2秒出力 6441 トークン

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

よくある質問

Claude Fable 5.1とClaude Opus 5、料金はどちらが安いですか?
出力100万トークンあたりClaude Fable 5.1は¥8,935、Claude Opus 5は¥4,467.5で、Claude Opus 5の方が安くなります(FastMetalの円建て単価・税別)。
Claude Fable 5.1とClaude Opus 5のコンテキスト長の違いは?
Claude Fable 5.1は1,000,000トークン、Claude Opus 5は1,000,000トークンです。
Claude Fable 5.1とClaude Opus 5、評価が高いのはどちらですか?
公開アリーナの順位ではClaude Fable 5.1が上です(Claude Fable 5.1 3位、Claude Opus 5 6位)。順位はリーダーボードの更新で変わります。
Claude Fable 5.1とClaude Opus 5を同じAPIキーで使えますか?
はい。FastMetalのOpenAI互換エンドポイントで、model に "anthropic-claude-fable-5-1" または "anthropic-claude-opus-5" を指定するだけで切り替えられます。料金はそれぞれの単価で、同じ前払い残高から従量課金されます。

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

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

Claude Fable 5.1の他の比較

Claude Opus 5の他の比較