GLM-5.2 APIの使い方：開発者向け2026年版完全ガイド

GLM-5.2 は、長いコンテキストと高度な推論が求められる AI アプリケーションを構築するチームにとって、最も興味深いモデルの一つです。大規模な入力を読み取り、マルチステップの指示に従い、コードを書き、ツールを使い、開発者にワークフローを細切れに分割させることなく有用な出力を生成するタスク向けに設計されています。

SaaS プロダクト、社内向け AI ツール、コーディングアシスタント、リサーチ用ワークフロー、ドキュメント分析システム、あるいは自律エージェントを作っている場合、実務上の問いは「GLM-5.2 とは何か？」だけではありません。より有用なのは、次の問いです。GLM-5.2 の API をどうすれば確実に呼び出し、コストを制御し、実際のプロダクトに組み込めるか？

本ガイドは、その問いに開発者およびプロダクトエンジニアリングの観点から答えます。curl、Python、JavaScript で GLM-5.2 API を使う方法、推論とストリーミングの設定、ツール呼び出しと構造化出力の考え方、そして CometAPI のような OpenAI 互換プロバイダ経由で呼ぶべきかモデルに直接呼ぶべきかの判断軸を学べます。

以下の例では CometAPI を使用しています。これは、GLM-5.2 を含む複数の AI モデルに対して、OpenAI 互換の統一 API レイヤーをチームに提供するためです。GLM-5.2 を他モデルと並行評価したい、SDK 連携を作り直したくない、請求を集約したい、コストや性能に応じてモデルを切り替えたい、といった場合に有用です。どのプロバイダを使う場合でも、エンジニアリング上の原則は同じです。

すでに OpenAI スタイルの API を使っている開発者にとって、統合パスは簡単です。多くの場合、base_url を変更し、API キーを更新し、既存のリクエスト形式を維持するだけでテストを開始できます。

クイックアンサー: GLM-5.2 API の使い方

GLM-5.2 API を使うには、API キーを作成し、OpenAI 互換のエンドポイントを選び、モデルを glm-5.2 に設定し、メッセージを添えてチャット補完リクエストを送信します。CometAPI を使う場合は、OpenAI SDK の base URL を https://api.cometapi.com/v1 に設定し、CometAPI のキーを渡し、chat.completions.create() を model: "glm-5.2" で呼びます。

最短の動作パターンは次のとおりです。

bash
curl https://api.cometapi.com/v1/chat/completions \
-H "Authorization: Bearer $COMETAPI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm-5.2",
"messages": [
{
"role": "user",
"content": "Explain how to design a token-efficient document analysis pipeline."
}
]
}'

最初のテストには十分です。プロダクションでは、タイムアウト、リトライ、ストリーミング、リクエストロギング、トークン予算、評価テスト、フォールバック戦略も追加しましょう。

GLM-5.2 とは？

GLM-5.2 は Z.ai の大規模言語モデルで、高度な推論、コーディング、長文コンテキストの理解、エージェント的ワークフローを狙っています。非常に大きなコンテキストウィンドウ、ツール使用、ストリーミング、推論制御をサポートします。実務的には、単なるチャットボット以上の応答が必要なアプリケーションで検討すべきカテゴリのモデルです。

特に、長い入力で作業する必要がある開発者に適しています。大きなコードファイル、技術文書、契約、調査レポート、サポート履歴、ログ、トランスクリプト、複数の文書で構成されたナレッジパックなど。少数の断片だけを取得するのではなく、モデルにより豊かなコンテキストを見せて横断的に推論させるワークフローを設計できます。

とはいえ、毎回 100 万トークンを貼り付けるべきではありません。長いコンテキストは強力ですが、プロダクト設計の代替ではありません。最良の GLM-5.2 連携は、検索（リトリーバル）、プロンプト圧縮、構造化出力、評価を組み合わせます。大きなコンテキストウィンドウは、正確性が向上する場面で使い、すべてを漫然と送る口実にしないことです。

主要機能

API ユーザーにとって特に重要な機能は次のとおりです。

AI プロダクトスタックにおける GLM-5.2 の位置づけ

GLM-5.2 は、AI スタックの「難しいタスク」層の候補と考えてください。小さな分類、タイトルの書き換え、低コストのオートコンプリートなど、すべてに必要なモデルではありません。次のようなニーズがあるときに魅力が増します。

• 長い入力に対する複雑な推論
• コード生成やコードベースの分析
• マルチステップのツール使用
• 長大な業務文書の構造化分析
• 長い会話履歴を伴うテクニカルサポートの自動化
• 多数のソースにまたがるリサーチの統合
• 浅い回答が「無回答より悪い」エンタープライズワークフロー

SaaS チームにとっては、GLM-5.2 は測定可能なタスクで評価すべきです。回答正確性、レイテンシ、1 ワークフローあたりのコスト、ツール呼び出し成功率、JSON 妥当性、拒否挙動、ユーザー満足度。コンテキストウィンドウが大きいからという理由だけで選ばないでください。エンドツーエンドのワークフローが改善するから選ぶべきです。

開始前に: 要件とセットアップ

コードを書く前に、最低限の統合要件を定義します。

API キー

CometAPI にアカウントを作成し、ダッシュボードから API キーを生成します。キーはコードに直書きせず、環境変数に保存します。

ローカル開発では:

export COMETAPI_API_KEY="your_api_key_here"

本番環境では、AWS Secrets Manager、Google Secret Manager、Azure Key Vault、Doppler、1Password、またはデプロイ基盤の暗号化済み環境変数などのシークレットマネージャに保管します。

モデル名

使用するモデル:

glm-5.2

デプロイ前に CometAPI のモデルページで最新のモデル ID を必ず確認してください。モデル ID、エイリアス、コンテキスト上限、価格は、プロバイダの更新で変動することがあります。

エンドポイント

チャット補完エンドポイントを使用します:

https://api.cometapi.com/v1/chat/completions

OpenAI 互換 API を使ったことがあれば見慣れた形です。主な違いは base URL と API キーです。

SDK の選択

すでに OpenAI SDK を使っているなら、それを使うのが近道です。base URL と API キーを変更し、モデルに glm-5.2 を指定するだけで済むことが多く、GLM-5.2 の評価をゼロからクライアントを書くよりもはるかに迅速に始められます。

ステップバイステップ: GLM-5.2 API の使い方

このセクションは実用的な例を示します。最初の叩き台として扱い、最終的な本番コードとは考えないでください。

1. curl で最初のリクエストを送る

SDK を入れる前に、API キー・エンドポイント・モデル名が正しいか確認したいときに curl を使います。

curl https://api.cometapi.com/v1/chat/completions \
  -H "Authorization: Bearer $COMETAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {
        "role": "system",
        "content": "You are a senior software architect. Give concise, implementation-ready advice."
      },
      {
        "role": "user",
        "content": "Design a retrieval pipeline for a SaaS help center with 50,000 articles."
      }
    ],
    "temperature": 0.2
  }'

アーキテクチャ、コーディング、業務クリティカルなワークフローでは低い temperature を使いましょう。名称検討や別案のコピー生成など多様性が欲しいときだけ高めにします。

2. Python で GLM-5.2 を使う

OpenAI Python SDK をインストールします:

pip install openai

次に、CometAPI の base URL でクライアントを設定します:

```python
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_API_KEY"],
base_url="https://api.cometapi.com/v1",
)

response = client.chat.completions.create(
model="glm-5.2",
messages=[
{
"role": "system",
"content": "You are a precise technical writer for developer documentation.",
},
{
"role": "user",
"content": "Write a short explanation of API idempotency for backend engineers.",
},
],
temperature=0.2,
)

print(response.choices[0].message.content)

これは、バックエンドサービス、CLI ツール、評価スクリプトに最適なベースラインです。最初の呼び出しが動いたら、リトライ・ロギング・エラーハンドリング・モデル選択を一元化できるよう、自前のサービスレイヤーでラップしましょう。

3. JavaScript / Node.js で GLM-5.2 を使う

OpenAI JavaScript SDK をインストールします:

npm install openai

クライアントを作成します:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_API_KEY,
  baseURL: "https://api.cometapi.com/v1",
});

const completion = await client.chat.completions.create({
  model: "glm-5.2",
  messages: [
    {
      role: "system",
      content: "You are a senior AI product manager. Be specific and practical.",
    },
    {
      role: "user",
      content: "List the risks of launching an AI spreadsheet assistant for finance teams.",
    },
  ],
  temperature: 0.3,
});

console.log(completion.choices[0].message.content);

SaaS アプリでは、ブラウザから GLM-5.2 API を直接呼ばないでください。API キーを保護し、ユーザー権限を強制し、アカウントのレート制限を行い、機密データをモデルに送る前にマスキングするため、バックエンドを経由させましょう。

4. ストリーミングレスポンスを有効化

ストリーミングはユーザー向けアプリで有用です。完全な応答を待つ前に出力を表示し始められるため、長い推論・コーディング・ドキュメント分析ワークフローでも体感が速くなります。

Python 例:

stream = client.chat.completions.create(
    model="glm-5.2",
    messages=[
        {"role": "user", "content": "Create a migration checklist for a monolithic Rails app."}
    ],
    stream=True,
)

for event in stream:
    delta = event.choices[0].delta
    if delta and delta.content:
        print(delta.content, end="")

JavaScript 例:

const stream = await client.chat.completions.create({
  model: "glm-5.2",
  messages: [
    { role: "user", content: "Explain how to test AI agent tool calls in production." },
  ],
  stream: true,
});

for await (const chunk of stream) {
  const token = chunk.choices[0]?.delta?.content;
  if (token) process.stdout.write(token);
}

本番では、ストリーミングに合わせた UI 設計が必要です。部分出力の表示に加え、キャンセル、リトライ、モデレーション、最終状態の永続化も扱いましょう。ストリーミング途中の回答を完了した業務処理として扱ってはいけません。

5. ディープシンキング / 推論コントロールを使う

GLM-5.2 は推論集約型タスク向けに設計されていますが、より深い推論はレイテンシとトークン使用量を増やします。タスクの価値に応じて推論の深さを制御すべきです。

たとえば、シンプルなサポート返信は、コード移行計画や法的契約のリスク要約ほどの推論予算は不要です。アプリケーション内に「タスクの複雑度」という内部設定を用意し、モデルのパラメータにマッピングできます。

パターン例:

response = client.chat.completions.create(
    model="glm-5.2",
    messages=[
        {
            "role": "user",
            "content": "Analyze this incident report and identify the likely root cause, missing evidence, and next debugging steps.",
        }
    ],
    temperature=0.1,
    reasoning_effort="high",
    extra_body={
        "thinking": {
            "type": "enabled"
        }
    },
)

特定の推論パラメータに本番で依存する前に、最新のプロバイダドキュメントを確認してください。OpenAI 互換プロバイダでも、推論コントロールをトップレベルのフィールド、追加のボディ、モデル固有のオプションなど、異なる形で提供することがあります。

プロダクト原則は単純です。ユーザーが目に見える価値を得る場面で推論トークンを使う。高コストなワークフローでは、モデルが人手の手戻りを防ぐなら費用に見合います。低価値のタスクには、より安価・高速なモデルを使いましょう。

6. エージェント的ワークフローのためのツール呼び出し

ツール呼び出しにより、モデルはアプリに関数の実行を依頼できます。モデルが DB、CRM、課金システム、コードランナーに直接アクセスするわけではありません。代わりに構造化されたツール呼び出しを返し、バックエンドが実行可否を判断します。

これは次のようなエージェント的 SaaS 機能の土台です。

• 社内ドキュメントの検索
• 顧客のサブスクリプション状況の照会
• サポートチケットの作成
• 分析クエリ
• コードテストの実行
• カレンダー空き状況の取得
• CRM フィールドの更新

簡略化したツール定義の例:

javascript
const completion = await client.chat.completions.create({
  model: "glm-5.2",
  messages: [
    {
      role: "user",
      content: "Find the customer's plan and explain whether they can use SSO.",
    },
  ],
  tools: [
    {
      type: "function",
      function: {
        name: "get_customer_plan",
        description: "Look up a customer's current subscription plan.",
        parameters: {
          type: "object",
          properties: {
            customer_id: {
              type: "string",
              description: "The internal customer ID.",
            },
          },
          required: ["customer_id"],
        },
      },
    },
  ],
});

ツール呼び出しを受け取ったら、他の信頼できない入力と同様に検証します。権限を確認し、要求されたレコードにアクセスできるかを確かめ、関数を実行し、結果をモデルに返して最終応答を生成します。決して、モデルが要求したからといって、不可逆な操作を直接実行させないでください。

GLM-5.2 のパラメータ解説

正確なパラメータ一覧はプロバイダにより異なりますが、開発者が理解すべき主要フィールドは次のとおりです。

最もありがちな誤りは、モデルパラメータを一度決めたら終わりと考えることです。成熟した AI プロダクトでは、パラメータはプロダクトの振る舞いの一部です。サポートのトリアージ、コードレビュー、契約分析が同じ設定である必然性はありません。

コスト計画とトークン予算

GLM-5.2 の長文コンテキストは魅力的ですが、コスト計画は重要です。不要なテキストを送ったり、静的な指示を毎回繰り返したり、過度に長い出力を求めたりすると、長いプロンプトは高くつきます。

CometAPI のモデルカタログには、GLM-5.2 の入出力トークンの価格が別々に記載されています。価格は変動し得るため、価格に敏感な記述を公開したり購買を決めたりする前に、常にライブのページで確認してください。以下の数値は 2026 年 6 月 17 日時点の記載です。

価格表

コスト戦略

GLM-5.2 のコストは、プロバイダ、入力トークン、出力トークン、キャッシュ挙動、推論設定に依存します。CometAPI の GLM-5.2 ページでは、当時は公式価格より割引された価格が記載されていましたが、AI API 市場では価格がすぐ変わり得ます。

本番計画では、コストを次のように見積もります:

Total cost = (input_tokens / 1,000,000 * input_price)+ (output_tokens / 1,000,000 * output_price)

長文コンテキストモデルは、呼び出しの繰り返しやエージェントの失敗ループ、複雑なリトリーバル設計を防げるなら、費用対効果が高くなり得ます。一方、毎回不要なファイルやログを含めるなら無駄になります。最善のコスト戦略は選択的なコンテキストです。タスクに必要なときだけリポジトリ全体を渡し、日常的なタスクには小さなプロンプトを使いましょう。

GLM-5.2 と他モデルの比較

モデル比較はタスク固有で行うべきです。コーディング系ベンチで強いモデルが、財務抽出に最適とは限りません。巨大なコンテキストウィンドウを持つモデルでも、小規模でレイテンシ重視のタスクでは劣ることがあります。正しい問いはこうです。このワークフローで、適切なレイテンシとコストで最良の結果を出すモデルはどれか？

GLM-5.2 対 GLM-5.1

すでに旧世代の GLM を使っている場合、より強い推論、長いコンテキスト、優れたツール使用、コーディング支援が必要なワークフローでは GLM-5.2 を試す価値があります。移行は当然視せず、測定しましょう。

GLM-5.2 対 汎用フロンティアモデル

CTO や AI プロダクトマネージャにとって、GLM-5.2 はモデルポートフォリオの一部であるべきです。長文コンテキストやエージェント的タスクでは最良の選択かもしれませんが、画像、超低レイテンシ、特定言語ペアでは別のモデルが適することもあります。

モデル選択の比較表

優れた AI チームは抽象的なモデル論争をしません。実ユーザーのタスクから評価セットを作り、完了品質を計測します。

トラブルシューティング

認証エラーが返る

API キーが存在するか、環境変数がロードされているか、Authorization ヘッダーが Bearer 形式になっているかを確認します。また、CometAPI のキーと CometAPI の base URL を組み合わせて使っているか（他プロバイダのキーやエンドポイントと混在していないか）を確認します。

モデル名が見つからない

CometAPI のモデルカタログで最新のモデル ID を確認します。glm-5.2 は、プロバイダのダッシュボードやドキュメントにアクティブな ID として表示されているときだけ使いましょう。

応答が遅すぎる

プロンプト長、出力長、推論設定、ストリーミングの有無を確認します。ユーザー向けアプリでは、ストリーミングにより総生成時間が同じでも体感レイテンシを改善できます。単純なタスクは小型モデルにルーティングします。

出力が高コスト

max_tokens を制限し、不要なコンテキストを減らし、繰り返し指示を圧縮し、リトリーバル品質を改善します。出力トークンは入力トークンより高いことが多く、長い生成が主要なコスト要因になりがちです。

JSON 出力が不正

スキーマを小さくし、例を示し、temperature を下げ、スキーマパーサで検証します。必要なら修復ステップを追加しますが、修復頻度を品質指標として追跡してください。

ツール呼び出しが不安全または不正確

許可リスト化したツール、厳格なスキーマ、権限チェック、不可逆操作の確認ステップを使います。モデルが要求したという理由だけでツール呼び出しを実行してはいけません。

GLM-5.2 のプロンプト設計

GLM-5.2 の 100 万トークン級のコンテキストウィンドウはプロンプト設計を変えますが、構造化の必要性をなくすわけではありません。最良のプロンプトは、モデルが何を最適化すべきか、どんな制約が重要か、どのファイルや文書が権威情報か、不確実性をどう報告するかを伝えます。

弱いプロンプト:

Review this code.

より強いプロンプト:

You are reviewing this repository for a production SaaS billing migration.

Objectives:
1. Identify correctness, data consistency, security, and migration risks.
2. Preserve existing public API behavior unless explicitly noted.
3. Prioritize issues that could cause billing errors, duplicate charges, data loss, or customer-facing downtime.
4. Return findings grouped by severity.
5. For each finding, include the affected module, why it matters, and a concrete fix.

Context:
- Billing provider: Stripe
- Database: PostgreSQL
- Backend: Node.js
- Deployment: Kubernetes
- Migration must be backwards compatible for 30 days.

長文コンテキストのプロンプトでは、冒頭近くにコンテキストマップを追加します:

Context order:
1. Product requirements
2. API contracts
3. Database schema
4. Current implementation
5. Test failures
6. Logs
7. Deployment constraints

これにより、モデルはどの資料を優先して信頼するか、どうプロンプト内をナビゲートするかを理解しやすくなります。

本番運用のベストプラクティス

1. 既定で 100 万トークンを使わない

100 万トークンのコンテキストウィンドウは強力ですが、毎回最大のコンテキストを送るのは非効率です。長いプロンプトはコスト・レイテンシ・失敗の表面積を増やします。本当にファイル横断・文書横断の推論が必要なタスクでだけ長文コンテキストを使いましょう。

長文コンテキストが適する例:

• リポジトリ全体の監査
• アーキテクチャ移行
• 複数モジュールのリファクタ
• 長い法務・コンプライアンス・技術文書の分析
• ログとコードを含むインシデントのタイムライン
• 永続状態が必要なエージェントワークフロー

不適な例:

• 単純なチャット回答
• 短い分類
• 基本的な要約
• 単一関数レベルのコード支援
• 高ボリュームで反復的なサポート返信

2. 出力トークンを上限設定

ワークフローに応じて max_tokens や max_completion_tokens を設定します。UI に 500 語の回答しか不要なら、20,000 トークンの出力を許可しないでください。エージェント的なコーディングでは大きな上限が正当化される場合もありますが、境界は設定しましょう。

3. 長い出力にはストリーミングを

ストリーミングは UX を改善し、ユーザーが「止まった」と感じにくくします。また、部分レンダリング、キャンセルボタン、進行ログの段階的表示を実装できます。

4. バックオフ付きリトライを追加

429、500、ネットワークタイムアウトを扱います。ジッタ付き指数バックオフを使いましょう。非冪等なツール操作では、計画（モデル）と実行を分け、リトライで副作用が繰り返されないようにします。

5. ツール呼び出しの検証

GLM-5.2 がツールを呼ぶなら、実行前に引数を検証します。任意の内部 API を、権限チェック・スキーマ検証・レート制限・監査ログなしで呼べるようにしてはいけません。

6. 自社データで評価

ベンチマークは有用ですが、実ワークロード評価の代替にはなりません。自社のプルリクエスト、インシデント、サポートチケット、文書、ユーザープロンプトからテストセットを作り、正確性、レイテンシ、コスト、拒否挙動、整形の信頼性、経時的な回帰を追跡します。

7. モデルのフォールバック戦略を維持

強力なモデルでも失敗します。プロダクションの SaaS では、フォールバックモデル、段階的な劣化、ハイリスク操作の手動レビューを備えるべきです。CometAPI のような統一 API レイヤーが役立つ理由の一つはここにあります。統合の手間を増やさずモデルを比較・切替できます。

最終的な推奨

GLM-5.2 は、長文コンテキスト推論、コーディング支援、リポジトリレベル分析、構造化された技術レビュー、複数ステップにまたがるエージェント的ワークフローが必要なプロダクトに適しています。OpenAI 互換の統合、モデル切替の容易さ、GLM-5.2 を他の主要モデルと一つの API レイヤーで比較したいなら、CometAPI 経由の利用が有効です。

開発者にとって最速の導入手順はシンプルです。

1. CometAPI のキーを作成する。
2. base_url を https://api.cometapi.com/v1. に設定する。
3. model を glm-5.2 に設定する。
4. 小さなプロンプトから始める。
5. ワークフローが必要とするときに、ストリーミング、構造化出力、ツール呼び出しを追加する。
6. スケール前に自社タスクで GLM-5.2 をベンチマークする。

玩具的なプロンプトではなく、実際のワークフローで CometAPI 上の GLM-5.2 を試しましょう。リポジトリレビュー、移行計画、インシデント分析、自社バックログのエージェントタスクなどです。そこでこのモデルの長文コンテキスト設計が真価を発揮します。

よくある質問（FAQ）

GLM-5.2 API とは？

GLM-5.2 API は、アプリケーションから GLM-5.2 言語モデルにプロンプト、会話、ツール使用リクエストを送るためのものです。長文コンテキストの分析、コーディング支援、推論ワークフロー、ドキュメント処理、エージェント的 SaaS 機能に利用できます。

CometAPI で GLM-5.2 API を使うには？

CometAPI のキーを作成し、SDK の base URL を https://api.cometapi.com/v1 に設定し、モデルに glm-5.2 を指定してチャット補完リクエストを送ります。すでに OpenAI SDK を使っている場合、主に base URL、API キー、モデル名の変更で統合できます。

GLM-5.2 は OpenAI 互換ですか？

GLM-5.2 は CometAPI のような OpenAI 互換 API プロバイダ経由で利用できます。これにより、馴染みのあるチャット補完パターンが使え、OpenAI の Python/JavaScript SDK を base URL の変更で再利用できる場合が多いです。

GLM-5.2 の得意分野は？

GLM-5.2 は、長文コンテキスト推論、コーディング支援、ツールを使うエージェント、文書分析、リサーチ統合、技術系 SaaS のワークフローなど、短いコンテキストの単純なチャットモデルでは力不足になりがちな領域に最適です。

SaaS の本番運用で GLM-5.2 を使えますか？

はい。ただし本番利用には、単に API 呼び出しを動かす以上の配慮が必要です。タイムアウト、リトライ、コスト監視、プロンプトのバージョニング、セキュリティコントロール、ツール呼び出しの検証、実顧客ワークフローに基づく評価を追加してください。

GLM-5.2 API の料金はいくらですか？

価格はプロバイダに依存し、変動します。執筆時点では、CometAPI における GLM-5.2 の価格は入力 100 万トークンあたり約 $1.12、出力 100 万トークンあたり約 $3.528 と記載されています。ローンチや購買前に必ずライブ価格を確認してください。

GLM-5.2 はストリーミングをサポートしますか？

はい。GLM-5.2 は互換プロバイダ経由でストリーミングをサポートします。チャット UI、コーディングアシスタント、ドキュメント分析など、部分出力の即時表示が有益なワークフローで有用です。

GLM-5.2 はツール呼び出しをサポートしますか？

はい。GLM-5.2 はツール呼び出しワークフローで利用できます。アプリが利用可能なツールを定義し、モデルが構造化されたツール呼び出しを返し、バックエンドがユーザーとワークフローの権限を検証してから実行します。

GLM-5.2 を直接使うべきですか？ それとも CometAPI 経由で？

チームが Z.ai のみを必要とし、プロバイダ固有のアクセスを望むなら直接の Z.ai API を。OpenAI 互換のインターフェース、統一請求、モデル比較の容易さ、GLM-5.2 を他モデルと並行評価するシンプルな道を求めるなら CometAPI を選びましょう。

GLM-5.2 API のコストを下げるには？

出力長の制限、リトリーバル品質の向上、不要な長文プロンプトの回避、繰り返しコンテキストのキャッシュ、単純タスクの小型モデルへのルーティング、ワークフロー完了あたりのコスト（トークン単価だけでなく）の監視でコストを削減します。