本文へスキップ

Grok 4.7 は xAI のチャットモデルで、OpenAI 互換の呼び出しと SSE ストリーミングに対応します。コンテキストは 500,000 トークン、返答は最大 450,000 で、推論強度は low から xhigh、このプラットフォームではフィルターを追加しません。

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

プレイグラウンド

Grok 4.7

Grok 4.7 に何を頼みますか?

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

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

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

無検閲のロールプレイと長編創作のための安定したメッセージ設計

Grok 4.7 は xAI が 2026 年 9 月に公開した最上位モデルで、前世代と同じ価格のままベースモデルが大きくなりました。「Grok は制限のある内容をブロックする」と書く記事の多くは、一般向けアプリの話をしています。このルートでは 3 種類の問い方で、当社のコンテンツ段階の最上位にあたる創作テストを 9 回行い、9 回とも完結した場面が返りました。当社側で足しているフィルターはありません。

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

統合の原則

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

無検閲のロールプレイと長編創作に再現できるワークフローを組む

Grok 4.7 は xAI が 2026 年 9 月に公開した最上位モデルで、前世代と同じ価格のままベースモデルが大きくなりました。「Grok は制限のある内容をブロックする」と書く記事の多くは、一般向けアプリの話をしています。このルートでは 3 種類の問い方で、当社のコンテンツ段階の最上位にあたる創作テストを 9 回行い、9 回とも完結した場面が返りました。当社側で足しているフィルターはありません。

  • 推測ではなく測定

    9 回のテストで 9 本とも完結

    物語の枠のない直球の依頼、場面を最後まで続けるよう指示した小説の一章、無検閲の system プロンプト。2026 年 9 月 22 日にそれぞれ 3 回ずつ実行し、拒否はゼロでした。9 本のうち最も控えめだった 1 本でも、場面を最後まで書き切っています。

  • ガードレールの向き

    安全機構が向いているのは兵器

    この世代は LatchBio のバイオセーフティ・ベンチマークで 62.4% の首位に立ち、危険な軍民両用プロンプトの通過をわずか 3.3% に抑えています。これらが測っているのは病原体と侵入用のツールで、創作ではありません。

  • system ロールは効く

    前提にせず、意図して確かめた

    system ロールを黙って無視するモデルは、動いているように見えながら、あらゆるロールプレイの枠を無意味にしてしまいます。会話の冒頭で一度置いたペルソナは文体を変え、そのまま会話全体に効き続けます。

  • 同価格で大型化

    前世代からの値上げなし

    入力・キャッシュ入力・出力のいずれも、4.6 世代と同じ単価で課金されます。長コンテキスト料金は、入力の合計が 200,000 トークンに達したところから適用されます。

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

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

  1. 4.7 を選ぶ

    40 ターン目を越えても崩れてほしくないとき

    ロールプレイの会話を終わらせるのは、1 通目での拒否であることはまれで、たいていは会話の奥で場面が不意に途中で止まることです。ここで最も重要だったテストは、最後まで続けるよう指示した一章で、3 回とも完結した形で返りました。

  2. 4.3 を検討する

    100 万トークンか none が必要なとき

    4.3 はコンテキストウィンドウが 1,000,000 トークンで、このファミリーで唯一 reasoning_effort: none を選べます。より安く、ウィンドウも広い兄弟モデルです。

  3. 向かない用途

    長時間の自律的なツールループ

    ターミナル操作型のエージェント系ベンチマークでは、この世代は上位勢に大きく水をあけられています。執筆と推論のためのモデルで、エージェントを動かす役には向きません。

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

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

  • 途中で壊れない場面

    長く続くロールプレイ

    途中で壊れない場面

    過去のターンは要約せず、原文のまま残してください。要約は、その会話が積み上げてきた具体的な細部をよりによって落とします。500,000 トークンのコンテキストウィンドウが、履歴をどこまで原文のまま残せるかを決めます。

  • 中編 1 本を 1 回の応答で

    長編創作

    中編 1 本を 1 回の応答で

    出力の上限が 450,000 トークンあるので、続きを書かせるたびに文体がずれていく章ごとのループに頼らず、1 回の呼び出しで全体を書き切れます。max_tokens は意識して引き上げてください。既定の 4,096 のままだと、警告なしに途中で切れます。

  • 数十往復くずれないペルソナ

    キャラクター

    数十往復くずれないペルソナ

    キャラクターシートは、冒頭の system メッセージ 1 通にまとめてください。口調、語彙、越えない一線は言い直さなくても会話全体に効き、temperature を 0.9 前後にすると表現の幅が保てます。

  • この世代が本当に強い分野

    専門分野の推論

    この世代が本当に強い分野

    公開ベンチマークでは、法務分析と電気工学で先行しています。契約書や仕様書をそのままコンテキストウィンドウに入れ、条項単位で質問してください。文書は 1 ターンで丸ごと入ります。

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

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

  1. 推論強度

    上げるのではなく下げる

    reasoning_effort の既定値は high ですが、対話には合いません。モデルが出力トークンを熟考に費やし、文章が生き生きとせず慎重すぎるものになります。low か medium のほうが読み味が良く、費用も抑えられます。推論は出力として課金されるからです。

  2. 枠

    冒頭で一度だけ置く

    ペルソナ、登場人物が成人であること、視点、どこまで踏み込んで書くかを、system メッセージ 1 通にまとめます。毎ターン言い直すとコンテキストを浪費するうえに、モデルが自分自身と交渉しているような口ぶりになります。

  3. 幅

    動かすのは top_p ではなく temperature

    文章に幅を出したいときは temperature を 0.9 あたりまで上げ、top_p はそのままにしてください。0 まで下げるのは、2 回の実行結果の違いを一つの要因だけに絞りたいときに限ります。

  4. 予算

    200,000 トークンの境界に注意

    入力とキャッシュ入力は合算され、合計が境界に達すると、超えた部分だけでなくリクエスト全体に長コンテキスト料金が適用されます。どちらの料金になるかは、送信前の見積もりでわかります。

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

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

  1. 01 · ベースライン

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

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

  2. 02 · 境界

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

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

  3. 03 · 統合

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

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

  4. 04 · 運用

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

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

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

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

  • 共通仕様

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

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

  • 最新のスキーマ

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

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

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

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

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

  • 移植しやすい統合

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

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

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