本文へスキップ

Anthropic の Claude Sonnet 4.5 を OpenAI 互換エンドポイントで使えるチャットです。テキストと画像で最大 198,000 トークンを読み、最大 64,000 を返し、temperature と top_p、ツール定義 128 個まで、SSE に対応します。

入力 $2.70出力 $13.50100 万トークンあたり公式価格より 10% 安いキャッシュ入力 $0.27キャッシュ書き込み $3.30Anthropic 公式価格入力 $3出力 $15

プレイグラウンド

Claude Sonnet 4.5

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

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

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

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

198,000 トークンの窓で temperature を使う中位レートの執筆のための安定したメッセージ設計

Sonnet 4.5 はサンプリング制御と小さめの窓を組み合わせています——temperature と top_p、入力 198,000、出力 64,000。プロンプトが temperature 前提で、扱う文書が収まり、Opus のレートがその作業に見合わないときに取るルートです。

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

統合の原則

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

198,000 トークンの窓で temperature を使う中位レートの執筆に再現できるワークフローを組む

Sonnet 4.5 はサンプリング制御と小さめの窓を組み合わせています——temperature と top_p、入力 198,000、出力 64,000。プロンプトが temperature 前提で、扱う文書が収まり、Opus のレートがその作業に見合わないときに取るルートです。

  • サンプリングを維持

    効きしろのダイヤルではなく temperature と top_p

    同系の Sonnet 5 は両方を reasoning_effort に置き換えました。ここでは較正済みのつまみがそのまま効きます。

  • 縁のある窓

    入力 198,000 トークン

    検索するかどうかの判断を迫る程度には小さく、単一の文書ならたいてい判断が要らない程度には大きい。

  • Opus 4.5 の 2 倍の上限

    1 回の返答で 64,000 トークン

    長い構造化回答が 1 ターンに収まります。しかも Opus のレートの何分の一かで。

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

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

  1. Sonnet 4.5 を選ぶ

    temperature 前提のプロンプトと、範囲の決まった入力

    組み合わせが具体的です——サンプリング制御と、見通せる窓を、Opus のレートを払わずに。

  2. Sonnet 4.6 を選ぶ

    同じ制御で 100 万トークン

    同系のレートとサンプリング制御はそのままに、窓が 1,000,000 に上がります。

  3. Sonnet 5 を選ぶ

    効きしろを宣言するほうがよい

    さらに低いレート、100 万トークンの窓、temperature の代わりに reasoning_effort。

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

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

  • 量があっても一貫した声

    サポートと対話

    量があっても一貫した声

    temperature を固定すれば、多数のセッションにまたがっても返答が同じ調子だと分かります。

  • 契約書、仕様書、書き起こし

    単一文書の仕事

    契約書、仕様書、書き起こし

    198,000 トークン未満なら丸ごと入り、検索層を設計から外せます。

  • 振る舞いの種を固定したスタイル移し

    構造のある書き換え

    振る舞いの種を固定したスタイル移し

    ハウススタイルへの書き換えは、自分で選んで変えるのをやめた temperature が効きます。

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

    制約の少ない物語制作

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

    信頼しているサンプリング制御のまま、場面と人物を作り込めます。長時間でも耐えるレートです。当社はコンテンツフィルタを追加しません。

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

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

  1. システム規則

    声と境界は冒頭で一度だけ

    ターンごとに繰り返すのは、システムメッセージが既に言ったことに入力トークンを使うことです。

  2. 証拠

    文書の境目を印付ける

    198,000 トークンの中でも、資料と指示を明示的に分ける価値はあります。

  3. サンプリング

    1 つの実験につき temperature は 1 つ

    異なる temperature の下でプロンプトを比べても、何も測れていません。

  4. 出力

    答えを 64,000 に合わせる

    節を求めてください。開いたままの依頼は、論の終わりではなく上限に到達します。

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

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

  1. 01 · ベースライン

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

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

  2. 02 · 境界

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

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

  3. 03 · 統合

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

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

  4. 04 · 運用

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

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

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

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

  • 共通仕様

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

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

  • 最新のスキーマ

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

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

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

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

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

  • 移植しやすい統合

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

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

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

Claude のすべてのモデル10