本文へスキップ

Grok 4.6 は xAI のマルチモーダルなチャットモデルで、OpenAI 互換の呼び出しから 1 ターンにテキストと画像を渡せます。1 リクエストは最大 500,000 トークン、返答は最大 450,000 で、推論強度は 4 段階です。

入力 $2出力 $6100 万トークンあたりキャッシュ入力 $0.50200K トークン以上のプロンプト入力 $4出力 $12

プレイグラウンド

Grok 4.6

Grok 4.6 に何を頼みますか?

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

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

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

実装、エージェント作業、知識労働のための安定したメッセージ設計

Grok 4.6 はカタログ上の xAI 最上位モデルです。コンテキストは 500,000 トークン、一度の返答は最大 450,000 トークン、推論の強度は low から xhigh まで(既定は high)。入力はテキストと画像で、このルートは file / PDF のパートを受け付けません。

チャットプレイグラウンドを開く
実装、エージェント作業、知識労働のための安定したメッセージ設計
モデル
Grok 4.6
適した用途
実装、エージェント作業、知識労働
メッセージ構成
システム規則 → 証拠と状態 → 今回のタスク → 出力仕様
事実の範囲
機能・パラメータ・価格は最新のスキーマから取得

統合の原則

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

実装、エージェント作業、知識労働に再現できるワークフローを組む

Grok 4.6 はカタログ上の xAI 最上位モデルです。コンテキストは 500,000 トークン、一度の返答は最大 450,000 トークン、推論の強度は low から xhigh まで(既定は high)。入力はテキストと画像で、このルートは file / PDF のパートを受け付けません。

  • ウィンドウ配分

    入力 500,000、出力 450,000

    ウィンドウのほぼ全量を一度の返答に使えます。長い入力を読むだけでなく、長い答えを書くこと自体が主役の仕事に向きます。

  • 推論の強度

    4 段階、既定は high

    low / medium / high / xhigh が開放されています。推論トークンは出力として数えられるため、強度を上げるときは max_tokens の上限も一緒に上げてください。

  • 入力パート

    テキストと画像、ファイルは不可

    1 つのメッセージにテキストと image_url(detail は auto / low / high)を混ぜられます。file / PDF のパートはこのルートでは拒否されるので、文書は先にテキストかページ画像に変換してください。

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

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

  1. 4.6 を選ぶ

    答えそのものが長くて難しい

    大きなリファクタ、コードを大量に書くエージェント実行、証拠一式を一度に抱えたまま結論を出す知識労働に向きます。

  2. 4.5 を検討する

    同じ長いプロンプトを一日中回す

    先頭ブロックを毎回送り直すループは、兄弟モデルのほうがキャッシュ入力の単価が低くなります。両方の価格カードを見比べてから決めてください。

  3. 4.3 を検討する

    深さより処理量

    分類、抽出、振り分けは、ウィンドウがさらに広く推論そのものを止められる兄弟モデルの担当です。

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

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

  • リポジトリ規模の変更を一度で

    実装

    リポジトリ規模の変更を一度で

    インターフェース、不変条件、テストを渡し、計画と差分、そしてその変更が生む移行時の危険を出させます。

  • 計画の広いツール呼び出し

    エージェント

    計画の広いツール呼び出し

    最大 128 個の関数定義と tool_choice が使えます。不可逆な操作は自社側の承認ゲートの後ろに置いてください。

  • 長い証拠一式を判断で締める

    知識労働

    長い証拠一式を判断で締める

    出典に名前を付け、出典から結論までの道筋を求め、どの前提が覆れば推奨が変わるのかも書かせます。

  • 画像は飾りではなく証拠

    画面と図

    画像は飾りではなく証拠

    細かい文字が効くときはスクリーンショットや構成図を detail: high で送り、そこから何を読み取ってほしいのかを明示します。

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

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

  1. system

    変わらない規則は固定ブロックに

    人物設定、出力仕様、規約は実行のたびに動かさないでください。先頭が安定していることが、そもそもキャッシュの前提です。

  2. 証拠

    出典はすべて区切って名付ける

    テキストのパートも画像のパートも名前が要ります。結論が元の資料を指し示せるようにするためです。

  3. 強度

    強度はタスクに合わせる

    制約が絡み合うときは上げ、下書きや書き換えのように遅延が体感を決める場面では低めに保ちます。

  4. 出力

    こちらが解析する形を先に言う

    response_format で JSON オブジェクトを要求できます。必須フィールドと、結果が空のときの形を決めておいてください。

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

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

  1. 01 · ベースライン

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

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

  2. 02 · 境界

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

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

  3. 03 · 統合

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

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

  4. 04 · 運用

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

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

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

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

  • 共通仕様

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

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

  • 最新のスキーマ

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

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

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

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

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

  • 移植しやすい統合

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

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

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