Grokを実装で選ぶときは、最初にバージョン名ではなく用途の経路を決めます。通常のテキストAPI、旧モデルからの移行、抽出、要約、RAG、業務自動化ならGrok 4.3を先に試します。Grok 4.20は、reasoning、non-reasoning、2M context、provider上の別名、multi-agentが必要な場合にだけ比較表へ入れます。Grok ImagineとGrok Voiceは画像/動画と音声のAPIファミリーであり、テキストモデルの上位モードではありません。
| 経路 | 使う場面 | 確認すること | 注意点 |
|---|---|---|---|
| Grok 4.3 | 新規または移行中のテキストAPI | xAI model page、alias、reasoning effort、context、price | 価格、context、利用可否は日付付きで再確認する |
| Grok 4.20 reasoning / non-reasoning | 深い推論、低遅延直答、2M context、provider指定がある | xAIまたはproviderのmodel IDとmode | 4.20という名前だけで4.3の全面後継と見ない |
| Grok 4.20 multi-agent | 並列調査、tool use、coding、複雑な判断がある | Responses API、agent数、tool、billing | leader、sub-agent、tool callで費用面が変わる |
| Grok Imagine | 画像生成や動画生成 | image/video model、endpoint、quality、duration、resolution | media routeでありtext modelではない |
| Grok Voice | realtime voice、TTS、STT、custom voices | Voice Agent API、realtime、TTS、STT docs | audio routeはendpointとlatencyが別 |
| Provider経由 | Vercel、Oracle、OpenRouterなどの基盤で使う | provider model name、region、limit、price、lifecycle | providerの事実はprovider経路に限定する |
停止線は明確です。owner、endpoint family、cost surface、lifecycle、availability、rollbackが揃うまで、multi-agentやprovider aliasをproductionの既定値にしないこと。画像や動画ならImagineを確認し、音声ならVoiceを確認し、テキストならGrok 4.3と必要なGrok 4.20分岐だけを比較します。
まず経路を決めてから名前を見る
Grokという名前は、xAIのfirst-party text model、Grok 4.20の専門分岐、multi-agent orchestration、image/video generation、voice/realtime audio、providerが独自に提供するmodel aliasを同時に含んでいます。これを一つのリリース番号の列として見ると、数字が大きいものや派手な名前を選びがちです。実装では、どの経路がworkloadを所有するのか、どのmodel IDまたはendpointが必要なのか、availabilityとpriceを誰が保証しているのかを先に決めます。
2026年5月8日に確認したxAI docsでは、Grok 4.3のページにGrok 4.3、grok-4.3-latest、grok-latestが載り、reasoning effortとしてnone、low、medium、highが示されていました。5月15日のretirement migration guideでも、複数の旧Grok 4、Grok 3、reasoning、non-reasoning、coding modelsのreplacement pathとしてGrok 4.3が示されています。通常のtext APIでは、これが最初のテスト候補になります。
一方でGrok 4.20が消えるわけではありません。xAIのGrok 4.20 reasoning pageは2M context windowとreasoning capabilityを示し、VercelやOracleのようなproviderは4.20のreasoning、non-reasoning、multi-agent variantを見せます。重要なのは、4.20を万能の後継にしないことです。必要な経路が4.20を所有している場合だけ、4.20を選択肢として残します。
Grok 4.3を先に試すべき場面
Grok 4.3は、普通のtext API integrationで最初に置くと判断しやすくなります。customer support、classification、extraction、summarization、RAG answer generation、workflow automation、旧model IDからの移行などでは、documented aliasesとreasoning effortのある現在のfirst-party routeが、beta aliasやprovider-only routeより運用しやすいからです。
実務テストは小さく作れます。Grok 4.3またはgrok-4.3-latestを選び、reasoning effortを明記し、同じprompt setでlatency、accepted answer rate、token usage、refusal behavior、error handling、rollback pathを測ります。workloadが超長文、multi-agent、media generation、voiceを必要としないなら、全名称を比較するよりこの検証のほうが早く結論を出します。
non-reasoning taskも別familyを探す前にGrok 4.3で試します。migration guidanceでは、non-reasoning workloadをGrok 4.3に寄せ、reasoning effortをnoneにする形が示されています。短い分類、formatting、direct answer、軽い要約なら、このルートを先に測るほうがconfigの分岐を増やしません。providerがdeployment ownerで、provider自身が4.20 non-reasoningを文書化している場合だけ、そのprovider routeを別枠で評価します。
priceやcontextの数値はownerに近い場所で扱います。2026年5月8日時点のGrok 4.3 pageには1M context windowとtoken pricingがありましたが、これらはbudget noteであって永続的な約束ではありません。production前にはxAI model page、Console、rate limit、account access、statusを再確認する必要があります。
Grok 4.20を残すべき場面
Grok 4.20は、reasoning branch、2M-context experiment、provider catalog、beta surface、または既に検証済みのspecialized routeがあるときに残します。4.20という表示は存在しますが、それがすべてのテキスト処理でGrok 4.3より安全という意味ではありません。workload ownerでないなら、設定はGrok 4.3のほうが単純です。
reasoning branchは、複雑なlogic、long analysis、research-style work、code reasoningで使う価値があります。Oracle OCI documentationはreasoningとnon-reasoningのGrok 4.20 modeを分け、reasoningをcomplex analysis向けに置いています。ただしこれはOCI routeの証拠です。xAI first-party accountや別providerで同じ名前、価格、region、lifecycleが成立するとは限りません。
non-reasoning branchはさらに狭い選択です。Vercel AI GatewayはGrok 4.20 Non-Reasoningをbetaのspeed/direct-answer routeとして説明し、provider-specific model stringを使います。Vercel AI SDKを使う開発者には有用ですが、xAI first-party routeの既定値を置き換える根拠にはなりません。
| 要件 | 先に試す経路 | 追加評価する条件 |
|---|---|---|
| current first-party text API | Grok 4.3 | Grok 4.3がacceptance testを満たさない |
| low-latency direct output | Grok 4.3 with reasoning off | providerがdeployment ownerでnon-reasoning 4.20を文書化している |
| 2M-context analysis | Grok 4.20 reasoning route | extra contextが実際に使われrecallを測った |
| gateway deployment | provider model ID | provider price、limits、data policy、regionが許容できる |
ここで大切なのは測定です。2M contextは完全なrecallを保証しません。non-reasoning labelはaccepted outputの最安値を保証しません。beta aliasは長期のproduction defaultを保証しません。同一workloadをquality、latency、cost、fallbackで比べてから決めます。
Multi-agentはworkloadで選ぶ
Grok 4.20 multi-agentは最も過剰採用されやすい分岐です。xAI docsでは、Grok 4.20 multi-agentはbeta routeであり、複数のagentsを調整し、built-in toolsを使い、デフォルトではleader outputを返し、4-agentまたは16-agent configurationを扱えるとされています。research、coding、広い情報収集、tool-heavy reasoningには意味がありますが、routine chatやsimple extractionには重すぎます。
multi-agentの判断軸は、総失敗コストを下げるかどうかです。xAI docsではleader tokens、sub-agent tokens、server-side tool callsが課金対象であることが示されています。強力かどうかより、追加agentによってhuman review、調査漏れ、誤答の修正コストがどれだけ下がるかを見ます。
| 条件 | 理由 |
|---|---|
| タスクが並列subproblemsを持つ | agentsに独立した仕事がある |
| toolsまたはlive researchが答えを変える | そうでなければsingle modelが簡単 |
| outputにreviewやacceptanceがある | 生成量が増えるほど検証が必要 |
| budgetがleader、sub-agent、toolsを許容する | 通常のcompletionとcost surfaceが違う |
API形状も確認します。multi-agentはResponses API routeに属し、古いchat-completions wrapperにそのまま入るとは限りません。SDK、provider、observability、retry、billing attribution、response parsingが対応しているかをproduction前に確認します。
ImagineとVoiceは別の能力経路
Grok ImagineはGrok 4.3のimage modeではありません。image/video generation routeであり、grok-imagine-image、grok-imagine-video、OpenAI-compatible image endpoint、async video polling、temporary asset、quality、duration、resolution、pricingを持ちます。2026年5月8日に確認したxAI image docsでは、grok-imagine-image-proが2026年5月15日にdeprecation予定で、新しいimage generationにはquality routeが推奨されていました。これは日付付きのmigration cueとして扱います。
VideoはImagine family内でも実装が違います。grok-imagine-videoはasync generation、polling、temporary video URL、duration、resolution、input media pricingを持ちます。media要件なら、Grok 4.3かGrok 4.20かではなく、image endpoint、video endpoint、quality、duration、asset retention、policy boundary、costを確認します。
Grok Voiceはさらに別です。Voice overviewはVoice Agent API、Text to Speech、Speech to Text、Custom Voicesを含み、realtime voiceは別endpoint familyとlatency budgetを持ちます。spoken agent、live voice interaction、transcription、TTS、custom voiceなら、text model比較ではなくaudio architectureの判断になります。
消費者向けのGrok Imagine問題とも分けます。Spicy Mode availability、NSFW image policy、free alternatives、heavy usage errorsは別の読者課題です。ここで扱うのはdeveloper APIのroutingであり、text、multi-agent、media、audio、providerの境界です。
Provider経由は便利だが一方の事実ではない
Vercel、Oracle、OpenRouterなどは既存のSDK、deployment、billing、loggingにGrokを入れるために有用です。provider pagesは、そのproviderがどのmodel alias、region、price、limit、SDK pathを提供しているかを証明できます。しかし、それはxAI first-party availability、permanent price、feature parity、account accessを自動的に証明しません。
| provider evidenceが証明できること | 証明できないこと |
|---|---|
| providerが特定のmodelまたはaliasを公開している | xAI Consoleで全accountに同じrouteがある |
| providerのprice、gateway ID、SDK、limits | xAI first-party price、lifecycle、context |
| providerのobservability、retry、billing behavior | 他providerやxAI APIの同等性 |
| 既存stack内での実験経路 | beta labelを長期defaultにできること |
OracleのdocsがOCI内でreasoning/non-reasoningを分け、multi-agentをAPI-onlyと示すのはOCIユーザーに有用です。VercelのAI Gateway model pageもVercel利用者に有用です。claimの横にprovider名を残すことが、誤設定を防ぎます。
production checklistは、owner、model ID、endpoint、price、rate limits、data policy、region、lifecycle note、status、account access、fallbackです。provider由来の項目はprovider routeとして扱い、first-party xAI configに移す前に確認します。
Grok変更前のチェックリスト
設定を変える前にroute decisionを一文で書きます。これだけでGrok 4.3、Grok 4.20、Imagine、Voice、provider labelsの混線をかなり防げます。
| 確認項目 | pass条件 |
|---|---|
| workload owner | text、multi-agent、image/video、voice、providerが明確 |
| modelまたはendpoint | Grok 4.3、documented 4.20 variant、Imagine、Voice、provider aliasのいずれか |
| retirement/deprecation risk | old Grok IDsとImagine changesをcurrent docsで確認 |
| reasoning setting | direct tasksにexplicit settingまたはdocumented routeがある |
| cost surface | tokens、sub-agents、tools、images、video、voice、provider billingを分離 |
| availability proof | xAI docs、Console、status、provider docsが具体claimを支える |
| rollback | previous model、acceptance set、rollback stepが記録済み |
Status pageはtimestamped health signalです。APIがgreenでもaccount-specific accessを保証しません。provider listingもfirst-party statusを保証しません。consumer high-demand bannerやaccount issueが疑われるなら、model nameを変更する前にtimestamp、request ID、active routeを保存します。
よくある質問
Grok 4.3はGrok 4.20より新しいですか？
多くのfirst-party text APIでは、Grok 4.3がxAI model pageとmigration docsの示す現在の入口です。Grok 4.20はreasoning、non-reasoning、2M context、provider、multi-agentで残ります。数字順だけでは判断しません。
Grok 4.3はGrok 4.20を置き換えますか？
多くの移行済みtext tasksではGrok 4.3が置き換え先になりますが、4.20のすべての分岐を消すわけではありません。documented routeが必要なときだけ4.20を残します。
新しいGrok APIアプリは何から始めるべきですか？
Grok 4.3を選び、reasoning effortを明示してacceptance setを走らせます。multi-agent research、image/video、realtime voice、provider-owned deploymentだけが例外です。
Grok 4.20 multi-agentはいつ使うべきですか？
parallel subproblemsがあり、toolsが答えを変え、outputをreviewでき、budgetがleader、sub-agent、tool usageを許容する場合です。routine chatやsimple extractionでは最初の選択肢ではありません。
Grok ImagineはGrok 4.3の一部ですか？
いいえ。Grok Imagineはimage/video routeで、別のmodel ID、endpoint behavior、asset lifecycle、quality、duration、resolution、pricingを持ちます。
Grok Voiceはtext modelですか？
いいえ。Grok Voiceはrealtime voice agent、TTS、STT、custom voicesのaudio capability familyです。音声要件で選びます。
VercelやOracleのGrok model nameを信用してよいですか？
そのprovider routeについては信用できます。provider pageはprovider alias、price、SDK path、availabilityを示せますが、xAI first-party parityは別途確認します。
production前に何を再確認しますか？
xAI model docs、Console access、migration notes、Imagine/Voice docs、provider model pages、current prices、rate limits、status、account-specific availabilityを確認します。volatile factはownerとchecked dateに紐づけます。
