本文へスキップ

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

入力 $5出力 $25100 万トークンあたりキャッシュ入力 $0.50キャッシュ書き込み $6.25

プレイグラウンド

Claude Opus 4.6

Claude Opus 4.6 に何を頼みますか?

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

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

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

サンプリング制御を保ったままの 100 万トークン文脈のための安定したメッセージ設計

Opus 4.6 は、この目録の他の Claude ルートが分け持っている二つを一つにまとめています——1,000,000 トークンの窓と 128,000 トークンの返答上限、そして reasoning のダイヤルではなく temperature と top_p。サンプリングを調整済みで、しかも長い窓が要るなら、両方揃うのはこの目録でこのルートだけです。

チャットプレイグラウンドを開く
サンプリング制御を保ったままの 100 万トークン文脈のための安定したメッセージ設計
モデル
Claude Opus 4.6
適した用途
サンプリング制御を保ったままの 100 万トークン文脈
メッセージ構成
システム規則 → 証拠と状態 → 今回のタスク → 出力仕様
事実の範囲
機能・パラメータ・価格は最新のスキーマから取得

統合の原則

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

サンプリング制御を保ったままの 100 万トークン文脈に再現できるワークフローを組む

Opus 4.6 は、この目録の他の Claude ルートが分け持っている二つを一つにまとめています——1,000,000 トークンの窓と 128,000 トークンの返答上限、そして reasoning のダイヤルではなく temperature と top_p。サンプリングを調整済みで、しかも長い窓が要るなら、両方揃うのはこの目録でこのルートだけです。

  • どちらかではなく両方

    長い窓とサンプリング制御

    Opus 4.5 はつまみはあるが 198,000 トークンで止まり、Opus 5 は窓はあるがサンプリングを効きしろに置き換えています。このルートは重なっている部分です。

  • 答えるための余地

    1 回の返答で最大 128,000 トークン

    Opus 4.5 の 4 倍の上限です。出力が「答え」ではなく「文書」のときに効いてきます。

  • 長い入力はトークンで課金

    このルートに長文脈の別レートはない

    入力・キャッシュ入力・出力それぞれ 1 レートです。長い呼び出しが高いのは長いからで、閾値を越えたからではありません。

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

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

  1. 4.6 を選ぶ

    窓もつまみも要る

    リポジトリ全体、長い書き起こし、文書一式を、すでに決めた temperature のまま扱えます。

  2. Opus 5 を選ぶ

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

    窓と上限は同じで、temperature と top_p の代わりに reasoning_effort の low / medium / high を取ります。

  3. Sonnet 4.6 を選ぶ

    長いが難しくはない仕事

    同じ 100 万トークンの窓とサンプリング制御を、100 万トークンあたりおよそ 6 割の価格で。出力上限は 64,000 です。

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

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

  • コードベース全体を 1 回で

    リポジトリレビュー

    コードベース全体を 1 回で

    100 万トークンあれば検索層のほとんどが不要になります。ツリーを送り、必要な判断だけを求めてください。

  • 多数の資料から 1 本の成果物

    長文の統合

    多数の資料から 1 本の成果物

    長い文書の集合を読み、100,000 トークン規模の報告を書くところまでが 1 回の呼び出しに収まります。

  • 新旧を並べて

    移行の計画

    新旧を並べて

    仕様やスキーマの両方の版が同時に入るので、差分を用意するのはこちらの仕事ではなくモデルの仕事になります。

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

    制約の少ない物語制作

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

    既存の大量のテキストを跨いだ長編の連続性を、較正済みのサンプリング制御のまま扱えます。当社はコンテンツフィルタを追加しません。

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

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

  1. 順序

    規則、証拠、タスクの順に

    長い入力の中では、真ん中に埋もれた指示は周囲の資料と競合します。

  2. キャッシュ

    安定した前置きは動かさない

    キャッシュ入力は入力レートの約 1/10 です。呼び出しごとに前置きを並べ替えると、その分が失われます。

  3. サンプリング

    一度に一つだけ変える

    temperature とプロンプト構造は、後から切り分けにくい形で結果を動かします。

  4. 出力

    返してほしい節を名指しする

    128,000 トークンの上限は余地であって計画ではありません。構造を求めることで、長い答えがレビュー可能になります。

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

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

  1. 01 · ベースライン

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

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

  2. 02 · 境界

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

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

  3. 03 · 統合

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

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

  4. 04 · 運用

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

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

Claude Opus 4.6 の能力を明確な契約に載せる

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

  • 共通仕様

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

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

  • 最新のスキーマ

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

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

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

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

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

  • 移植しやすい統合

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

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

Claude Opus 4.6 API を組み込む前に確かめる境界

Claude のすべてのモデル10