モデル比較

Claude Haiku 4.5 vs GLM 5.3 Flash

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

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

スペックと料金

anthropic logoClaude Haiku 4.5z-ai logoGLM 5.3 Flash
提供元AnthropicZ.ai
入力(100万トークンあたり)¥184.8¥13.19
出力(100万トークンあたり)¥924¥43.98
想定コスト(入力1,000・出力500トークン × 1,000回)¥647¥35
コンテキスト長200,000 トークン1,310,720 トークン
リリース日2025/10/152026/8/26
入力モダリティimage, texttext, image, video
アリーナ 総合#129 · ELO 1,413#38 · ELO 1,469
アリーナ 日本語#112 · ELO 1,357圏外
アリーナ コーディング#95 · ELO 1,480#11 · ELO 1,531

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

どちらを選ぶべきか

  • 料金重視ならGLM 5.3 Flash。出力100万トークンあたり¥43.98で、Claude Haiku 4.5より95%安くなります。
  • 総合の評価はアリーナ順位でGLM 5.3 Flashが上です(38位。Claude Haiku 4.5は129位)。
  • コーディングの評価はアリーナ順位でGLM 5.3 Flashが上です(11位。Claude Haiku 4.5は95位)。
  • 長い文書を扱うならGLM 5.3 Flash。コンテキスト長は1,310,720トークンで、Claude Haiku 4.5の200,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…

Claude Haiku 4.5

# エラー原因と修正方法 ## 原因 **`order["price"]`が文字列型(str)で返されているため、整数との乗算ができない**ことが原因です。 データベースから取得したデータが文字列として返されており、数値計算ができない状態になっています。 ## 修正方法 ### **方法1: 型変換(推奨)** ```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"]) * int(order["quantity"]) for order in orders) return {"user_id": user_id, "total": total, "orders": orders} ``` ### **方法2: 各要素を個別に変換** ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) total = 0 for order in orders: price = float(order["price"]) quantity = int(order…
応答時間 4.4秒出力 729 トークン

GLM 5.3 Flash

## 原因 エラーメッセージ `unsupported operand type(s) for *: 'str' and 'int'` の左側が `order["price"]` なので、**`price` が文字列(str)として取得されている**のが原因です。`quantity` は int なので、数値カラムは正常に取得できています。 考えられる原因は次のとおりです(可能性が高い順): 1. **DBの `price` カラムが VARCHAR / TEXT 型で定義されている**(最も可能性が高い) 2. 使用しているDBドライバやラッパーの設定により、文字列として返されている 3. JSONなど経由でデータを取得していて、priceだけ文字列化されている ### 確認方法 ```python orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) print(type(orders[0]["price"])) # <class 'str'> が出れば確定 print(type(orders[0]["quantity"])) ``` MySQLなら `DESCRIBE orders;` で、PostgreSQLなら `\d orders` でカラム型を確認してください。 ## 修正方法 ### 根本対策: DBスキーマを修正する(推奨) 金額は数値型で持つべきです。既存データに変換できない値(空文字、カンマ付きなど)がないか先に確認してく…
応答時間 45.3秒出力 2329 トークン

コードレビュー

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

Claude Haiku 4.5

# TypeScript関数のレビューと改善案 ## 🔴 主な問題点 ### 1. **型安全性の欠如** ```typescript // ❌ `any[]` は危険 async function fetchAllUsers(page: number = 1): Promise<any[]> // ✅ 改善: 型を定義 interface User { id: string; name: string; email: string; } interface ApiResponse { users: RawUser[]; } interface RawUser { id: string; first_name: string; last_name: string; email: string; status: string; } ``` ### 2. **エラーハンドリングがない** ```typescript // ❌ fetch失敗時の処理がない const response = await fetch(`/api/users?page=${currentPage}&limit=100`); // ✅ 改善 const response = await fetch(`/api/users?page=${currentPage}&limit=100`); if (!response.ok) { throw new Error(`Failed to fetch users: ${response.status}`); }…
応答時間 8.7秒出力 1343 トークン

GLM 5.3 Flash

# コードレビュー 全体的な構造は分かりやすいですが、**型安全性・エラーハンドリング・可読性**に改善の余地がかなりあります。重要度順に挙げます。 --- ## 1. 重大な問題(ベストプラクティス) ### `any[]` による型情報の喪失 戻り値が `any[]` だと、呼び出し側でタイプミスやプロパティ変更がコンパイル時に検出できません。インターフェースを定義すべきです。 ### HTTPエラーの未チェック `fetch` は 404 や 500 でも例外を投げません。`response.ok` を確認しないと、エラーレスポンスの JSON をパースしようとして謎のエラーになります。 ### `data.users` の防御チェックなし APIの仕様変更やエラー時に `data.users` が `undefined` だと、`.length` で即座にクラッシュします。 ### 無限ループのリスク API 側のバグで常に100件返る場合、ループが終わりません。最大ページ数やタイムアウト(AbortSignal)の考慮があると安全です。 --- ## 2. 可読性 | 現状 | 改善案 | |---|---| | `data.users[i].xxx` の繰り返し | `for...of` でオブジェクトを直接受け取る | | `first_name + " " + last_name` | テンプレートリテラル `` `${a} ${b}` `` | | `currentPage = currentPage + 1` | `currentPage…
応答時間 85.2秒出力 3638 トークン

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 Haiku 4.5

# SQLクエリ最適化案 ## 🔴 主な問題点 1. **不適切なJOIN順序** - 大量データをJOINしてからFILTER 2. **インデックス不足** - WHERE/ON句のカラムにインデックスなし 3. **重複集計** - reviews テーブルとの LEFT JOIN により行が増幅 4. **GROUP BY非効率** - product_name で集計(IDの方が効率的) --- ## ✅ 最適化クエリ ```sql SELECT p.product_name, c.category_name, stats.order_count, stats.total_sales, stats.avg_rating FROM products p LEFT JOIN categories c ON c.id = p.category_id LEFT JOIN ( -- サブクエリで先に集計・フィルタリング SELECT od.product_id, COUNT(DISTINCT o.order_id) as order_count, SUM(o.amount) as total_sales FROM order_details od INNER JOIN orders o ON o.order_id = od.order_id WHERE o.status = '完了' AND o.created_at >= '2024-04-01' GROUP BY od.product_i…
応答時間 7.4秒出力 1184 トークン

GLM 5.3 Flash

# ボトルネックの分析 ## 1. 最重要:ファンアウトで集計値が壊れている(性能以前のバグ) `order_details`(注文経由)と `reviews` を**同レベルで** products に LEFT JOIN すると、両者の組み合わせで行が直積的に増殖します。 例:商品Aに注文明細10件・レビュー3件 → 結合後30行 - `SUM(o.amount)` → 注文1件あたりレビュー数(3倍)に水増し - `AVG(r.rating)` → 注文数で重み付けが変わり不正確 - `COUNT(o.order_id)` → 明細行数を数えている **インデックスを追加して速くしても、数値は誤ったまま**なので、まず構造を変える必要があります。 ## 2. WHERE 句が LEFT JOIN を無効化している `o.created_at >= '2024-04-01'` が WHERE 句にあるため、NULL 行が除去され、LEFT JOIN が実質 INNER JOIN になります。「売上0の商品も表示したい」意図ならバグです。 ## 3. インデックス不足 `order_details(product_id)`、`reviews(product_id)` などの結合キーにインデックスがないため、5M行のテーブルに毎回シーケンシャルスキャン+ハッシュ結合が発生します。 --- # 修正版クエリ(先に集計してから結合) ```sql WITH sales AS ( SELECT od.product_id, COUNT(DI…
応答時間 116.2秒出力 5554 トークン

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

よくある質問

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

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

アカウントを作成してクレジットをチャージすれば、Claude Haiku 4.5とGLM 5.3 FlashをブラウザのチャットとAPIの両方から呼び出せます。月額料金はありません。

Claude Haiku 4.5の他の比較

GLM 5.3 Flashの他の比較