Grokのモデル廃止で何を直す？自動転送と移行チェック表

Grokの古いモデル名が廃止対象に入っていても、すべてのリクエストが直ちにエラーになるとは限りません。公式の移行案内に自動転送がある場合は、名前を変えていないのに別のモデルが処理を担当します。確認すべきなのは「まだ動くか」に加えて、出力、利用料金、推論設定が業務の条件を満たすかです。

モデル名の固定と、動作の固定を分けて考える

xAIのモデル一覧では、モデル名・latest付きの別名・日付付きのリリース名という考え方が説明されています。ただし、任意の名前に日付を足せば使えるわけではありません。提供されているIDと、そのIDに適用される移行案内を確認します。

2026年5月15日の移行案内では、たとえばgrok-3はgrok-4.3の推論noneへ振り向けられると説明されています。この記事では、このような転送があるときの確認手順を扱います。最新モデルへの移行を実測した比較結果ではありません。確認日は2026年9月5日です。

最初に、モデルを指定している場所を棚卸しする

コードだけを検索しても、管理画面や自動化サービスの設定を見落とすことがあります。一つの業務について、実行経路を一列に書きます。人が使う画面、定時実行、失敗時の再実行が別設定なら、それぞれを台帳に残します。

記入欄	説明用の記入例
処理の用途	問い合わせ内容の分類。返信は人が承認
設定場所	実行ジョブAのモデル設定欄
指定しているID	現在の設定値をそのまま転記
移行後の処理先	公式案内の対象行と確認日
変更できる担当	運用責任者
再実行の設定	通常実行とは別に確認する

キーそのものはこの表に書きません。必要なら、秘密情報の保管場所を担当者が識別できる管理番号だけを記録します。モデルID、APIの種類、SDKのバージョンを別欄にすると、どこを変更したのかが明確になります。

同じ入力で、業務に必要な性質を比べる

モデルが変わるときに指示文も全面改稿すると、結果の差の理由が分かりません。指示と入力をそろえ、まずモデルの変更だけを比べます。入力には通常の依頼だけでなく、不明点がある依頼、回答してはいけない依頼も含めます。

移行確認シート
対象業務：
元の指定ID／移行先ID：
公式移行案内のURLと確認日：
変更した設定：
入力セットの版：
必須の出力項目：
人への差し戻し条件：
件数／誤分類数／空欄数：
処理時間の測り方：
使用量の確認先：
採用判断と承認者：

たとえば分類業務なら、「分類名が許可した一覧に収まる」「判断材料が足りないときは要確認へ回る」「入力にない顧客属性を足さない」を判定します。文章の読みやすさだけで採用すると、自動処理との接続が壊れても気づきにくくなります。

旧モデルへ戻せない場合に備える

廃止後に旧IDへ戻しても、転送が続く場合は元の実体へは戻れません。切り戻し案は「古い文字列へ戻す」だけでなく、利用可能な代替モデル、人による一時処理、自動送信の停止を含めて決めます。候補モデルでも必要な機能が同じか確認してください。

移行直後は少量を担当者が確認し、誤りがどの入力で起きたか記録します。定時実行も一巡してから切り替えを完了扱いにします。料金は移行先の公式料金と実際の使用量で確認し、旧モデルの単価のままで見積もらないようにします。

APIからエラーが返る場合はHTTPコード別の切り分けへ進みます。複数のAIを使う社内運用は、Claude Code・Codex・Grokの使い分けも参考にしてください。

参照した資料

• xAI：モデル移行案内
• xAI：モデル一覧