本文へスキップ

Anthropic の Claude Sonnet 5 を OpenAI 互換エンドポイントで使えるチャットです。テキストと画像で最大 1,000,000 トークンを読み、最大 64,000 を返し、推論強度は low・medium・high、ツール定義 128 個まで、SSE に対応します。

入力 $1.90出力 $9.50100 万トークンあたり公式価格より 5% 安いキャッシュ入力 $0.19キャッシュ書き込み $2.375Anthropic 公式価格入力 $2出力 $10

プレイグラウンド

Claude Sonnet 5

Claude Sonnet 5 に何を頼みますか?

関連モデルと次のステップ

お探しのモデルが見つかりませんか?

必要なモデルと用途をお知らせください。次に何を追加するかを決めるチームに直接届きます。

100 万トークンの窓で回す大量の Claude 処理のための安定したメッセージ設計

Sonnet 5 は、ここでは 100 万トークンあたり Opus 5 のおよそ 42% のレートで、100 万トークンの窓と reasoning_effort のダイヤルをそのまま保っています。譲っているのは返答の上限で、1 ターンあたり 128,000 ではなく 64,000 トークンです。

チャットプレイグラウンドを開く
100 万トークンの窓で回す大量の Claude 処理のための安定したメッセージ設計
モデル
Claude Sonnet 5
適した用途
100 万トークンの窓で回す大量の Claude 処理
メッセージ構成
システム規則 → 証拠と状態 → 今回のタスク → 出力仕様
事実の範囲
機能・パラメータ・価格は最新のスキーマから取得

統合の原則

まず最小のメッセージ構成でタスクを検証し、必要な文脈だけを足していきます。事実・仮定・制約を分け、中断、再試行、精算、人手によるレビューの経路も設計してください。

100 万トークンの窓で回す大量の Claude 処理に再現できるワークフローを組む

Sonnet 5 は、ここでは 100 万トークンあたり Opus 5 のおよそ 42% のレートで、100 万トークンの窓と reasoning_effort のダイヤルをそのまま保っています。譲っているのは返答の上限で、1 ターンあたり 128,000 ではなく 64,000 トークンです。

  • Sonnet 帯のレート

    100 万あたり Opus 5 の約 42%

    同じ効きしろのダイヤルと同じ窓を、量を扱えるかどうかが変わるレートで。

  • 窓はそのまま

    入力 1,000,000 トークン

    節約は文脈から取られていません。長い書き起こしや文書一式は Opus ルートと同じように収まります。

  • 1 回の返答は 64,000

    Opus の上限の半分

    長い構造化回答には十分です。100,000 トークンの文書には、上限 128,000 のルートか 2 ターン目が要ります。

Claude Sonnet 5 をタスクの重さと対話の形から選ぶ

汎用のランキングに頼らず、同じ実タスクで品質、検証しやすさ、遅延、販売価格の見合いを確かめてください。

  1. Sonnet 5 を選ぶ

    長い文脈を伴う大量処理

    大きな入力に対する高頻度の仕事。Opus のレートでは品質より先に予算が結論を出してしまう場面です。

  2. Opus 5 を選ぶ

    1 回の返答が 64,000 を超える必要がある

    窓もダイヤルも同じで返答上限は 2 倍、レートはおよそ 2.4 倍です。

  3. Sonnet 4.6 を選ぶ

    temperature のほうがよい

    同じ窓・同系のレートで、効きしろのダイヤルの代わりに temperature と top_p。

Claude Sonnet 5 を抽象的なラベルではなく具体的な仕事に落とす

どの場面にも入力の境界、検証、復帰が要ります。公式能力、ベンチマーク、ツール対応を作り話で補うことはしません。

  • 1 会話あたりの費用が設計を決める

    量のある本番対話

    1 会話あたりの費用が設計を決める

    長い履歴を文脈に置いたままでも、レートのせいで毎ターンが高くつくことがありません。

  • 長い入力が多数、答えは普通

    大量の文書処理

    長い入力が多数、答えは普通

    大きな文書を読んで 1 ページの所見を返す——低いレートが積み上がるのはこの形です。

  • 呼び出しは多く、返答は短い

    エージェントのループ

    呼び出しは多く、返答は短い

    ツールを使うループはトークンの大半を入力に使います。入力レートの低さは反復のたびに効きます。

  • 成人の登場人物と明確な境界

    制約の少ない物語制作

    成人の登場人物と明確な境界

    長時間のセッションが現実的になるレートで、長編の連続性を保てます。当社はコンテンツフィルタを追加しません。

文脈を Claude Sonnet 5 が検査できる入力に整理する

目的、証拠、状態、制約、出力仕様はそれぞれ別の役割を担ってこそ、圧縮も、デバッグも、再現もできます。

  1. 効きしろ

    low から始め、必要が見えたら上げる

    このルートでは大半のターンに熟慮は要りません。要るターンはプロンプトではなく作業内容から分かるのが普通です。

  2. 履歴

    答えに使えないものは削る

    窓が長いことは全部を送り直す理由になりません。多くの請求では入力のほうが依然として大きい半分です。

  3. キャッシュ

    変わる部分を最後に置く

    入力レートの 1/10 で効く安定した前置きこそ、このルートの節約が実際に着地する場所です。

  4. 出力

    128,000 ではなく 64,000 を前提に設計する

    1 ターンに収まる構造を求めるか、成果物を意図的に分けてください。上限に気づいてから分けるのでは遅いです。

Claude Sonnet 5 で再現できる一件を示してから製品コードへ

最新のスキーマ、見積もり、ストリーミング、エラー時の挙動を確かめてから、統一リクエストを使い回します。

  1. 01 · ベースライン

    最小のリクエストを プレイグラウンド で確かめる

    メッセージの層、出力の形、ストリーミング、現在の制御項目を確認します。

  2. 02 · 境界

    失敗・取り消し・再試行を試す

    タイムアウト、途切れたストリーム、長すぎる入力、再生成、二重送信を検証します。

  3. 03 · 統合

    統一 API リクエストをそのまま写す

    公開モデル id と messages の仕様を使い、モデル固有のパラメータは最新のスキーマから読みます。

  4. 04 · 運用

    使用量を計測し、評価を続ける

    状態、最終使用量、失敗理由、品質フィードバックを保存し、高コストな呼び出しは先に見積もりを出します。

Claude Sonnet 5 の能力を明確な契約に載せる

プレイグラウンド、API 例、リクエストの状態、使用量の記録が一貫しているので、評価から本番統合まで同じ理解で進めます。

  • 共通仕様

    メッセージ・ストリーム・エラーの形はひとつ

    モデルを替えても、リクエストの組み立て、状態処理、エラー復帰の書き方は変わりません。

  • 最新のスキーマ

    現在のエンドポイントの制御項目を使う

    プレイグラウンド と API 例が、使えるフィールド、上限、既定の挙動をまとめて示します。

  • 観測できるライフサイクル

    どのリクエストにも明確な状態がある

    送信、ストリーミング、失敗、取り消し、使用量は、検査できる公開セマンティクスで表されます。

  • 移植しやすい統合

    モデル更新時の作り直しを減らす

    契約が明確なら、製品コードは入力、結果、体験に集中できます。

Claude Sonnet 5 API を組み込む前に確かめる境界

Claude のすべてのモデル10