xAIは、Grok 4.7 をコーディング、エージェントタスク、ナレッジワーク向けの最先端モデルと位置付け、500Kトークンのコンテキストウィンドウを備えると説明しています。xAIの現在の料金ページによると、プロンプトトークンが200,000未満の場合のダイレクトAPIレートは、入力トークンが100万トークンあたり$2.00、キャッシュトークンが$0.50、出力トークンが$6.00です。プロンプトが200,000トークン以上に達すると、xAIはそれぞれ$4.00、$1.00、$12.00を掲示しています。これらはxAIのダイレクトレートであり、サードパーティプラットフォームに共通の価格ではありません。
実際の支出は、見出しの入力レートだけでなく、未キャッシュの入力、キャッシュ済みの入力、出力、リトライ、ツール呼び出し、エージェントワークフロー内のモデル呼び出し回数などにも左右されます。特に200Kプロンプトの境界は重要で、xAIとCometAPIの双方が、その境界に達した場合にロングコンテキストの高いレートを公表しています。
このガイドはまずxAIの価格基準を定め、その後、現在のCometAPIの Grok 4.7 掲載ページと比較します。2026年9月28日時点で、CometAPIの標準ティアは新規入力/キャッシュ入力/出力トークンがそれぞれ100万トークンあたり$1.60 / $0.40 / $4.80、ロングコンテキストティアは$3.20 / $0.80 / $9.60と記載されており、対応するxAIダイレクトレートより20%低く設定されています。以下のセクションでは、ワークロードコストの計算方法、ムダの削減方法、CometAPI経由でのモデル利用方法を説明します。すべての価格は時点のスナップショットであり、本番利用前に再確認してください。
xAIダイレクト vs. CometAPI における Grok 4.7 の料金
xAIダイレクト料金（USD/100万トークン）
| トークン区分 | プロンプト200Kトークン未満 | ロングコンテキスト（≥200K） |
|---|---|---|
| 新規入力 | $2.00 | $4.00 |
| キャッシュ入力 | $0.50 | $1.00 |
| 出力 | $6.00 | $12.00 |
CometAPI料金（USD/100万トークン）
| トークン区分 | CometAPI：プロンプト200Kトークン未満 | CometAPI：ロングコンテキストティア |
|---|---|---|
| 新規入力 | $1.60 / 1M tokens | $3.20 / 1M tokens |
| キャッシュ入力 | $0.40 / 1M tokens | $0.80 / 1M tokens |
| 出力 | $4.80 / 1M tokens | $9.60 / 1M tokens |
200Kプロンプトの境界が重要なのは、両プラットフォームが現在、Grok 4.7に関して標準ティアの2倍のロングコンテキストレートを掲示しているためです。これは各APIプラットフォームの価格ルールであり、モデルの能力が変わるわけではありません。アプリケーションが大きなプロンプトを繰り返し送ったり、エージェントの履歴を制御せずに増やしたりすると、Grok 4.7が500Kのコンテキストウィンドウをサポートしているからという理由ではなく、請求額が高くなるのです。
予算策定では、境界に達すると見込まれるリクエストは、実運用での課金挙動が確認できるまではロングコンテキストとして扱ってください。モデルの提供状況や価格は変動するため、プロダクションの計算機はxAIのダイレクト料金と、現在のCometAPIのモデルページを都度確認し、固定値を埋め込み続けないようにしてください。
Grok 4.7 コスト見積もりの式
1回のリクエストは、各トークン区分を個別に計算して見積もります。
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
次に、リクエスト見積もりをワークロード見積もりに変換します。
monthly cost = request cost × requests per user × active users × days in billing period
平均ひとつではなく、現実的なパーセンタイルを使ってください。p50は通常のリクエストを表しますが、p95の入力・出力長は、請求を左右しがちな高コストの裾を露わにします。エージェントワークフローでは、完了タスクあたりのモデル呼び出し回数を掛けます。5ステップのワークフローは1回ではなく5回の課金対象呼び出しです。
例題1：サポートコパイロット
1回のサポートリクエストで6,000トークンの新規入力を送り、800トークンの出力が生成されるとします。200Kの閾値を下回り、キャッシュ割引はありません。
- 入力: 6,000 × $1.60 ÷ 1,000,000 = $0.00960
- 出力: 800 × $4.80 ÷ 1,000,000 = $0.00384
- 合計: 1リクエストあたり $0.01344
月間100,000リクエストなら、推定トークンコストは$1,344です。評価の結果、800トークンの回答と同等の性能を400トークンで達成できるなら、見積もりは1リクエストあたり$0.01152、月額$1,152に下がります。この出力上限の設定だけで、約$192（14.3%）の削減になります。モデル自体を変更せずに済みます。
これが出力制御に注目すべき理由です。CometAPIの掲示レートでは、同じティア内で出力トークンは新規入力トークンの3倍の単価です。
例題2：安定した20Kトークンのプレフィックスを再利用
各リクエストに20,000トークンの製品マニュアル、2,000トークンの新規コンテキスト、600トークンの応答が含まれるとします。
キャッシュヒットなしの見積もりは:
- 新規入力 22,000トークン: $0.03520
- 出力 600トークン: $0.00288
- 合計: 1リクエストあたり $0.03808
20,000トークンの安定プレフィックスがキャッシュ入力として課金され、2,000トークンのみが新規入力と見なされる場合、見積もりは次のようになります:
- キャッシュ入力 20,000トークン: $0.00800
- 新規入力 2,000トークン: $0.00320
- 出力 600トークン: $0.00288
- 合計: 1リクエストあたり $0.01408
100,000リクエストでは$1,408となり、$3,808ではなくなります。推定削減額は$2,400、つまり63.0%です。なお、これは自動的な削減ではありません。初回リクエスト、プレフィックスの変更、またはキャッシュヒットを生まないルートでは、新規入力レートで課金される可能性があります。実際の使用データでキャッシュトークン数を確認し、達成済みの削減として扱う前に裏付けを取りましょう。
例題3：200Kを超えるコスト
210,000トークンのプロンプトと2,000トークンの出力を伴う長時間のエージェントリクエストを考えます。掲示されたロングコンテキストレートを用いると:
- 新規入力 210,000トークン: $0.67200
- 出力 2,000トークン: $0.01920
- 合計: 1回あたり $0.69120
コンテキスト圧縮、検索結果のフィルタリング、サマリチェックポイントにより、プロンプトを180,000トークンへ抑え、出力2,000トークンは同一と仮定すると、標準ティアでの見積もりは:
- 新規入力 180,000トークン: $0.28800
- 出力 2,000トークン: $0.00960
- 合計: 1回あたり $0.29760
差額は1回あたり$0.39360、約56.9%です。10,000回では推定$3,936の削減になります。教訓は有用なコンテキストを削除することではありません。回答に影響するコンテキストだけを保持し、それ以外は要約や検索で取り込むことで、価格の境界を越えないようにすることです。
呼び出し前見積もり用のPython計算ツール
以下の関数は、CometAPIに現在掲示されているGrok 4.7のレートを使用します。合計プロンプトが200,000トークンに達した場合は、保守的にロングコンテキストティアを適用します。
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")
これは計画用のガードであり、請求書ではありません。最終的なコストは、実際の入力、キャッシュ入力、出力、リトライ、ツール呼び出し、そして実行時の有効価格に依存します。各レスポンス後に、返却されたトークン使用量、モデルID、リクエストステータス、タスク結果を保存し、プロバイダの請求記録と照合してください。
影響度順の Grok 4.7 コスト管理5項目
1. 繰り返しのコンテキストをキャッシュ可能なほど安定化
静的な指示、製品ドキュメント、スキーマ、再利用可能な例は、リクエスト固有の内容より前に配置します。大きな共有プレフィックス内のタイムスタンプ、ID、空白、順序は、必要な場合を除き変更を避けます。xAIのGrok 4.7ガイダンスは、会話に安定したキャッシュルーティング識別子を推奨しています。仲介ルートを使う場合は、そのルートでサポートされるキャッシュ制御や使用フィールドを確認し、それらに依存する前に検証してください。
ワークロード別にキャッシュヒットトークンとキャッシュヒット率を計測します。理論上のキャッシュ割引も、アプリケーションがプレフィックスを常に変更しているなら価値はありません。
2. 200Kは目標ではなくエンジニアリング上の予算とみなす
閾値の下に、システム指示、検索で取得したパッセージ、ツールの結果、次のユーザーターンのための余裕を確保します。エージェントでは、古いターンを検証済みサマリに圧縮し、元のトランスクリプトはモデルコンテキスト外に保持します。検索では、挿入前にパッセージのランク付けと重複排除を行い、ヒットしたものすべてを送らないようにします。
プロンプト長の分布をトラッキングし、p95が閾値に近づく前にアラートを出します。xAIの公式スケジュールでは、プロンプトが200Kトークンに達すると、そのリクエストのすべてのトークンにロングコンテキストレートが適用されます。CometAPIも同様に、Grok 4.7のロングコンテキストティアを別枠かつ高いレートで掲示しています。これらはモデル能力ではなく、プラットフォームの価格条件です。
3. 出力を上限設定し、推論負荷を評価セットに合わせて調整
製品に合わせたアプリケーションレベルの出力上限を設定します。分類結果なら数十トークンで足りるかもしれません。サポート回答なら数百、調査レポートならより多くが必要かもしれません。この上限は予算とUXのコントロールであり、Grok 4.7モデルのハード制限ではありません。xAIの9月21日のリリースノートでは、Grok 4.7にテキスト出力上限はないと記載されていますが、アプリケーションや特定のAPIルートが独自にリクエスト上限を設けることを妨げるものではありません。実際に使用するルートで、エンドポイントやSDKが課すリクエスト制限を確認してください。
Grok 4.7は複数の推論負荷レベルをサポートします。代表的な評価セットを通過する最も低いレベルを用い、実測で改善が得られるタスクに限って高い負荷を使いましょう。評価なしに推論や出力を減らすと、リトライを招き、削減効果を相殺する可能性があります。
4. API呼び出し前に高コストなリクエストを拒否・再構成
入力サイズと設定した出力上限から上限見積もりを算出します。リクエストが製品の予算を超える場合、ユーザーにタスクの絞り込み、アップロード素材の要約、取得コンテキストの削減、承認済みの非同期ワークフローへの移行を促すことができます。生成後にコストが判明するよりも予測可能です。
ざっくりした文字数→トークン換算は早期ガードとして有用ですが、トークナイザーや実使用データの代替にはなりません。言語、コード、JSON、整形によりトークン密度は大きく変わります。
5. 呼び出しあたりのコストではなく、成功タスクあたりのコストを最適化
安い呼び出しでも検証に2回失敗すれば、成功した1回より高くつくことがあります。以下をトラックしてください。
- 受け入れられた回答あたりのコスト
- 完了したエージェントタスクあたりのコスト
- リトライとフォールバックのコスト
- キャッシュヒット率とキャッシュトークン比
- プロンプトと出力トークンのp50・p95
- 品質スコア、レイテンシ、人手エスカレーション率
定常トラフィックにGrok 4.7の品質やコンテキスト容量が不要であれば、CometAPIの統合モデルカタログにより、アプリケーション側のモデル切替を容易にできます。ルーティングルールは明示的に保ち、同一タスクセットで各モデルを評価し、Grok 4.7の恩恵があるリクエストのみをこのルートに送ってください。
実践的な月次コストレビュー
週1回、トラフィックを機能別にグルーピングし、推定コストと実使用を比較します。まず、出力トークンが最多、プロンプトが巨大、キャッシュヒット率が低い機能から確認します。その後、高コストの外れ値をレビューし、中央値だけを闇雲に最適化しないようにします。
| シグナル | 想定される問題 | 最初の対処 |
|---|---|---|
| キャッシュトークン比が低い | 共有プレフィックスが頻繁に変化している | 再利用コンテキストを安定化・バージョン管理 |
| プロンプトが200K付近に集中 | 履歴や検索挿入が無制限 | 圧縮・ランク付け・ヘッドルーム確保 |
| 出力が支出の大半を占める | 製品に不要な長文になっている | 上限を下げて回答品質を検証 |
| リトライコストが高い | 検証失敗、タイムアウト、プロンプト不安定 | 初回失敗の原因を修正 |
| コストは低いがタスク完了率が低い | 最適化が有用な品質を落とした | 受理結果あたりのコストで測定 |
Grok 4.7 コストモデルにおける CometAPI の位置付け
CometAPIの役割はAPIプラットフォームレベルにあります。Grok 4.7へのアクセスを提供し、独自のトークンレートを公表し、OpenAI互換のエントリポイントを文書化します。Grok 4.7のモデル能力自体を変更するものではありません。既にOpenAIスタイルのクライアントを利用しているチームは、エンドポイント互換性の範囲で、APIキー、ベースURL、モデルIDを差し替えるだけで同じクライアントパターンを維持できる可能性があります。
2026年9月28日時点で、CometAPIに掲示されたGrok 4.7のレートは、標準・ロングコンテキストの両ティアで、対応するxAIダイレクトレートより20%低く設定されています。これはプラットフォーム間の価格比較であり、モデル品質の主張ではありません。本番展開前に、実際のモデルID、エンドポイントパラメータ、キャッシュ挙動、レート制限、信頼性、サポート、請求条件も検証してください。
モデルを試すには、CometAPIのGrok 4.7モデルページで最新の価格とアクセス詳細を確認します。価格表は設定で管理し、各呼び出し後に実使用を記録し、モデルや製品の挙動が変わるたびにワークロード見積もりを再実行してください。
FAQ
CometAPIでのGrok 4.7のトークン単価は？
プロンプトが200Kトークン未満の場合、CometAPIの現在の掲示は、新規入力が100万トークンあたり$1.60、キャッシュ入力が$0.40、出力が$4.80です。ロングコンテキストの掲示レートは、それぞれ$3.20、$0.80、$9.60です。
Grok 4.7のAPIリクエスト1回はいくらか？
新規入力、キャッシュ入力、出力、そして有効なコンテキストティアに依存します。各トークン数に対応する100万トークンあたりのレートを掛け、合計して100万で割ります。リトライやマルチステップワークフロー内の各モデル呼び出しも含めてください。
Grok 4.7のAPIコストを最も簡単に下げる方法は？
測定された最大のコストドライバから着手します。繰り返される長い指示はキャッシュが有効、増大するエージェント履歴は圧縮が有効、冗長な回答は出力上限の引き下げが有効です。各変更後に品質が許容範囲内かを確認してください。
500Kのコンテキストウィンドウがあるなら、500Kトークンを送るべき？
いいえ。コンテキストウィンドウは容量上限であり、推奨値ではありません。xAIのダイレクト料金とCometAPIの現在の掲示は、200Kプロンプトの閾値でより高いロングコンテキストレートを適用するため、アプリケーションはタスクに必要なコンテキストのみを送るべきです。
Grok 4.7の呼び出し前にコストを見積もれる？
はい。入力トークンを見積もり、適切なコンテキストティアを選び、現実的な出力上限を加え、上限値を算出します。呼び出し後は、レポートと最適化のために推定値を実使用データに置き換えてください。