モデル一覧に戻る
z-ai logo
z-ai/glm-5-2

GLM 5.2

GLM 5.2はZ.aiの大規模推論モデルです。テキスト入力・出力に対応し、100万トークンのコンテキストウィンドウを備えており、長期的なエージェントワークフロー、プロジェクトレベルのソフトウェアエンジニアリングなどに適しています。

2026/6/16
1,048,576 トークン
入力: ¥250.18/M
出力: ¥786.28/M
仕様

モダリティ

入力
text
出力
text

サポートされているパラメータ

frequency_penalty
include_reasoning
logit_bias
logprobs
max_tokens
min_p
parallel_tool_calls
presence_penalty
reasoning
reasoning_effort
repetition_penalty
response_format
seed
stop
structured_outputs
temperature
tool_choice
tools
top_k
top_logprobs
top_p

最大出力トークン

131,072
コード例
curl https://api.fastmetal.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "glm-5.2",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

GLM 5.2の実際の回答

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…

## エラーの原因 エラーメッセージ `TypeError: unsupported operand type(s) for *: 'str' and 'int'` は、「文字列型と整数型を掛け算(`*`)しようとしました」という意味です。 該当コードの `order["price"] * order["quantity"]` の部分において、データベースから取得した `price` または `quantity` のどちらか(あるいは両方)が数値ではなく**文字列(String)**として取得されていることが原因です。 これはよくある落とし穴で、以下のような理由で発生します。 1. データベースの該当カラム(`price` や `quantity`)が、数値型(INTやDECIMAL)ではなく、文字列型(VARCHARやTEXT)で定義されている。 2. データベースのカラムは数値型だが、使用しているデータベースドライバの仕様や設定により、Python側に文字列として渡されている。 ## 修正方法 ### 1. Pythonコード側で型変換を行う(一時的な対応) Pythonコード側で明示的に数値型(`int` または `float`)に変換してから計算を行います。 ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) # priceを float、…
応答時間 23.4秒出力 2031 トークン
コードレビュー

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

ご提示いただいたTypeScriptのコードは動作しますが、可読性・パフォーマンス・ベストプラクティスの観点からいくつか改善の余地があります。 以下に主な改善点と、それを反映した修正版のコードを提案します。 ### 主な改善点 1. **型安全性の向上(ベストプラクティス)** - 戻り値や配列の型が `any[]` になっています。TypeScriptの利点を活かすため、APIのレスポンスや返却するユーザーの型(Interface)を明示的に定義すべきです。 2. **エラーハンドリングの追加(ベストプラクティス・堅牢性)** - `fetch` はHTTPエラー(4xx, 5xx)が発生しても例外をスローしません。`response.ok` をチェックし、エラー時には例外をスローする処理を追加すべきです。 3. **配列操作のモダン化(可読性・パフォーマンス)** - `for` ループによるインデックスアクセスは冗長です。`filter` と `map` を組み合わせることで、何をしているのかが直感的にわかるようになります。 4. **変数のスコープと宣言(ベストプラクティス)** - ループ内で値が変わらない `user` オブジェクトは `let` ではなく `const` で宣言すべきです。 - `currentPage = currentPage + 1` は `currentPage++` のように簡潔に記述できます。 5. **ハードコーディングの回避(可読性・保守性)** - `100` というマジックナンバーが複数…
応答時間 10.4秒出力 2232 トークン
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…

500万行のテーブルに対して30秒かかる原因は、主に**インデックスの不足**と**結合によるファンアウト(直積)の発生**、そして**LEFT JOINとWHERE句の論理的矛盾**にあります。 以下に最適化したクエリと、推奨されるインデックス、そして改善点の解説を記載します。 ### 最適化後のクエリ案 ```sql WITH ProductSales AS ( -- 注文データの事前集計 SELECT od.product_id, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total_sales FROM order_details od JOIN orders o ON o.order_id = od.order_id WHERE o.status = '完了' AND o.created_at >= '2024-04-01' GROUP BY od.product_id ), ProductRatings AS ( -- レビューデータの事前集計 SELECT product_id, AVG(rating) AS avg_rating FROM reviews GROUP BY product_id ) SELECT p.product_name, c.category_name, COALESCE(ps.order_count, 0) AS order_count, COALESCE(ps.tota…
応答時間 16.7秒出力 2525 トークン

他のモデルと並べて比較する →

GLM 5.2を今すぐ試す

GLM 5.2はFastMetalのAPIキー1つで利用できます。ブラウザですぐに試す、またはOpenAI SDKからそのまま呼び出せます。