Grokが使えない原因と解決策｜エラー別トラブルシューティング

はじめに

Grokを使おうとした際にエラーが表示されたり、応答が返ってこなかったりするトラブルは、無料ユーザーから有料プランの契約者まで幅広く報告されています。Grokが使えない状態が続くと、作業の遅延だけでなく、代替手段への切り替え判断も迫られます。

Grokが使えない原因は、サーバー側の障害からローカル環境の設定不備、プランごとの利用制限まで多岐にわたります。この記事では、Grokが使えない主な原因の分類、エラーメッセージごとの対処法、公式ステータスページの活用方法、そして待つか別のツールに切り替えるかの判断基準までを順を追って解説します。

Grokが使えない主な原因

サーバー側障害とサービス停止

Grokが使えない原因として最初に疑うべきなのは、サーバー側の障害です。xAI側のシステムに問題が発生すると、個人の環境にかかわらず全ユーザーが影響を受けます。実際に、チャット応答と音声モードの両方が利用できなくなり、公式ステータスページで「Grok is Temporarily Unavailable」と表示された事例がありました（参照*1）。

サーバー側の停止は、ユーザーの操作では解決できません。障害が起きているかどうかは、公式のステータスページや外部のダウン検知サイトで確認できます。まず自分の環境を疑う前に、サービス全体の稼働状況を確かめることが切り分けの第一歩です。

高負荷による一時的な利用制限

サーバーが完全に停止しているわけではなくても、アクセスの集中によってGrokが使えない状態に陥ることがあります。接続はできるのに2回目のメッセージで「high demand」のエラーが返される、といった報告が複数のユーザーから上がっています（参照*2）。

xAIから公式な説明は出ていなかったものの、利用者の増加がサーバー容量を圧迫している可能性を示す見方が紹介されています（参照*2）。高負荷による制限は障害とは異なり、時間をずらすだけで解消する場合もあるため、完全停止との区別がポイントです。

サブスクリプションとプラン上の制約

Grokが使えない原因は、契約しているプランの利用上限に達している場合もあります。無料ユーザーでも利用できますが、プロモーション期間などでは2時間あたり2回のプロンプトに制限される場合があります（参照*3）。この上限を超えると、エラーではなく単にリクエストが受け付けられなくなります。

一方、Premium+の契約者はより高い利用上限と新機能への早期アクセスが提供されます（参照*4）。頻繁に上限に達してGrokが使えない状況に遭遇する場合は、利用中のプランと制限内容を確認することで問題の所在がはっきりします。

エラーメッセージ別の対処法

「high demand」「try again later」

「high demand」や「try again later」と表示される場合、Grokのサーバーがアクセス集中により一時的にリクエストを受け付けられない状態です。あるユーザーは接続には成功したものの、2回目のメッセージを送った時点でこのエラーが返されたと報告しています（参照*2）。

このエラーはサーバー側の要因であるため、ユーザー側の設定変更では解消しないことがあります。数分から数十分ほど時間を空けて再度試すのが基本的な対応です。もしXアプリで発生した場合はGrokのWebサイトで試す、あるいはその逆を行うと接続できることもあります。

「temporarily unavailable」

「temporarily unavailable」は、Grokのサービス自体が一時的に停止している際に表示されるメッセージです。公式ステータスページでは「Grok in X is currently unavailable for most users. Our team is working to restore service.」と案内された事例があります（参照*5）。

このメッセージが出ているときは、xAI側で復旧作業が進行中であることが多いです。ユーザーが試せるのは、公式ステータスページで障害情報と復旧見込みを確認し、状況が改善するまで待つことです。別の利用面（Web版やモバイルアプリ）では使える場合もあるため、複数の接続経路を試す価値はあります。

HTTPステータス 401・403・429

API経由でGrokを使えない場合、HTTPステータスコードが原因の特定に役立ちます。401 Unauthorizedは、認証ヘッダーが送信されていないか、APIキーが無効な場合に返されます。リクエストヘッダーに「Authorization: Bearer」形式で有効なキーを指定し、必要に応じてxAIコンソールでAPIキーを取得し直すことで解決できます（参照*6）。

429 Too Many Requestsは、レート制限（一定時間あたりのリクエスト上限）または利用枠を超えた場合に発生します。対処としては、累積利用額に応じたティアで上限が決まることを踏まえて利用状況を見直すことと、リクエストのバッチ処理や指数バックオフの実装で消費パターンを調整する方法があります（参照*7）。403 Forbiddenが返される場合も、アクセス権限やキーの有効範囲を見直すことが最初の確認事項です。

HTTPステータス 500・503

500 Internal Server Errorは、Grok側の内部処理で予期しない問題が起きたことを示します。X APIの公式ドキュメントでは、このエラーに対して「待ってからリトライし、ステータスページを確認する」ことが推奨されています（参照*8）。

503 Service Unavailableは、サーバーが過負荷の状態にあるときに返されるコードです。断続的なエンジンクラッシュに起因する503やタイムアウトが発生しており、xAIチームと連携して調査が進められた事例もあります（参照*9）。500・503のいずれも、ユーザー側で直接解消する手段はなく、時間を置いて再試行するのが基本です。

公式ステータスページの活用

status.x.aiの見方と注意点

Grokが使えないときは、まず公式のstatus.x.aiを確認するのが基本です。このサイトでは、Grok Web、Grok in X、iOS版、Android版といった利用面ごとの稼働状況が確認でき、障害が表示されていれば原因の切り分けに役立ちます（参照*10）。進行中の障害がある場合は、status.x.aiで最新情報が更新されるほか、RSSフィード（status.x.ai/feed.xml）でも配信されます（参照*6）。

ただし、ステータスページの表示が常に実態と一致するわけではありません。status.x.aiが「fully operational」と表示しているにもかかわらず、外部のダウン検知サイトではGrokに関する報告が急増していた事例が確認されています（参照*2）。公式ページだけでなく、外部の検知サービスも併用することで、状況を把握しやすくなります。

サーフェス別の障害切り分け

Grokの障害は、すべての利用面で同時に発生するとは限りません。status.x.aiでは、Grok Web、Grok in X、iOS、Androidの各サーフェス（利用面）ごとにステータスが表示されるため、どの経路に問題があるのかを個別に確認できます（参照*10）。

たとえば、Xアプリ内のGrokだけが停止している場合は、Web版に切り替えれば引き続き利用できる可能性があります。障害の影響範囲を把握することは、Grokが使えない状態を「待つ」か「別の方法で回避する」かの判断に直結します。

ローカル環境の切り分け手順

ブラウザ・拡張機能・VPNの検証

公式ステータスページに障害が表示されていないのにGrokが使えない場合、問題は自分の端末やブラウザ環境にある可能性があります。まず試すべきは、ページの強制再読み込みと、プライベートウィンドウ（シークレットモード）でのアクセスです。認証周りの問題はサービスエラーのように見えることがあり、ログアウトしてから再度ログインすると解消するケースもあります（参照*10）。

次に、ブラウザの拡張機能を一時的に無効にします。プライバシー保護系の拡張、広告ブロッカー、スクリプトブロッカー、そして一部のVPN経路は、Grokのような最新のWebアプリの通信を妨げ、サービス側の障害のように見える症状を引き起こすことがあります。すべてを恒久的に無効にする必要はなく、クリーンなブラウザ状態でエラーが消えるかどうかを確認するのが目的です。

アプリ更新・再インストール

モバイルアプリやデスクトップアプリでGrokが使えない場合は、アプリの再起動や新しいブラウザウィンドウでの起動が有効です。Xアプリで動作しないときはGrokのWebサイトを試し、Web版で動作しないときはXアプリを試すという方法が案内されています（参照*2）。

アプリが古いバージョンのままだと、API仕様の変更やセキュリティ更新に対応できず、接続エラーが発生する場合があります。アプリストアで最新バージョンへの更新がないか確認し、改善しなければ一度アンインストールしてから再インストールすることで、キャッシュや設定ファイルの不整合を解消できます。

過去の障害事例と復旧傾向

過去の障害事例を知っておくと、Grokが使えない状況でおおよその復旧時間を見積もる手がかりになります。2026年3月10日に発生した障害では、Grok Web、Grok in X、iOS、Androidのすべてのサーフェスがほぼ同時に影響を受けました。復旧までの時間は各サーフェスでほぼ一定しており、約2時間23分から2時間25分の範囲で収束しています（参照*10）。

一方、2026年1月27日の障害は大幅に長引きました。公式ページでは「Grok is experiencing an outage. We are working to restore service.」と表示され、Xでの復旧には約6時間32分、Web版とモバイル版では約7時間25分から7時間26分を要しています。このほか、Grok.comを提供するモデルに問題が特定され、応答の遅延や中断が発生した事例もあります（参照*11）。

これらの事例から読み取れるのは、障害の種類によって復旧時間に大きな幅があるということです。数時間で収まるケースもあれば、半日近くかかるケースもあるため、障害発生からの経過時間と公式ページの更新頻度を照らし合わせながら、対応方針を調整する必要があります。

待つか切り替えるかの判断基準

Grokが使えない状態に遭遇したとき、復旧を待つか別のツールに切り替えるかは、障害の規模と自分の作業の緊急度で決まります。障害が1時間以内で、公式ページがすでに調査中または復旧中と表示している場合は、そのまま待つのが合理的です。2026年3月の障害事例もこのパターンに該当しました。また、影響が1つのサーフェスだけに限られている場合は、待つよりも別の接続経路に切り替えるほうが効率的です。XからWebへ、あるいはモバイルアプリからブラウザへ移るだけで作業を続行できます（参照*10）。

障害が全サーフェスに及び、2から3時間を超えて続いている場合は、軽い中断とは捉えず、別のAIアシスタントへの切り替えや、Grokに依存する作業の後回しを検討すべき段階です。信頼性を重視する場合や、幅広い機能群を必要とする場合、あるいはコスト効率を優先する場合には、それぞれ異なるAIサービスが選択肢に入ります（参照*3）。Grokが使えない時間を無駄にしないためにも、普段から代替手段を1つは確保しておくと、障害発生時の対応がスムーズになります。

おわりに

Grokが使えないときの原因は、サーバー側の障害、アクセス集中による一時制限、プランの利用上限、そしてローカル環境の問題に大別できます。エラーメッセージやHTTPステータスコードごとに対処法が異なるため、まず原因の切り分けを正しく行うことが最短の解決につながります。

公式ステータスページと外部の検知サービスを併用し、障害の規模と経過時間に応じて「待つ」か「切り替える」かを判断する習慣を持つことで、Grokが使えない場面でも作業全体の影響を最小限に抑えられます。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））