Geminiの障害を確認する方法｜3つの公式ページの使い分け

「Geminiが急に返事をしなくなった」「『Something went wrong』が出て先へ進めない」——仕事の途中でGeminiが止まると、自分の設定のせいなのか、Google側の障害なのか、まず判断できずに手が止まります。

結論から言うと、Geminiの障害は「どの入口でGeminiを使っているか」で見るべき公式ページが変わります。GeminiアプリはGoogle Workspace Status Dashboard、Gemini APIとGoogle AI StudioはAI Studioのステータスページ、Vertex AI系やGemini EnterpriseはGoogle Cloud Service Healthです。同じ「Gemini」でも系統が別なので、違うページを見ると「正常」と表示されていて判断を誤ります。

株式会社Fyveは、Gemini APIを動画の読み上げや音声の聞き取り照合に組み込んで毎日動かしています。この記事では、Googleの公式ページと公開されている障害記録をもとに、Geminiの障害を確認する手順と、止まったときに業務を止めないための備えを、私たちの運用で実際に起きたことと合わせて整理します。

結論：Geminiが落ちたかは「入口」を決めてから3ステップで確認する

先に手順だけをまとめます。

1. 自分がどの入口で使っているかを決める（Geminiアプリ／Gemini APIとAI Studio／Google Cloud経由）
2. その入口に対応する公式ページを開く（下の表）
3. 公式ページが正常なら、自分側の原因を順に切り分ける（エラーコード・アカウント・回線）

ChatGPTやClaudeは公式のステータスページが1つにまとまっていますが、Geminiは提供の系統ごとにページが分かれています。ここを最初に押さえておくだけで、確認にかかる時間がかなり縮みます。

2026年6月10日に実際に起きたこと

抽象的な説明より、実際の障害記録を1つ読むほうが早く理解できます。Google Workspace Status Dashboardには、2026年6月10日のGemini障害の記録と、Googleが後から出した障害報告（Incident Report）が残っています。

公式に記録された経過

障害報告によると、2026年6月10日の米国太平洋時間3時30分（日本時間19時30分ごろ）に、Webアプリ・スマホアプリ（iOSとAndroid）・Google Chromeの中のGeminiを含む、すべての面で可用性に影響が出ました。

• エラー率が高い状態が続いたのは約6時間55分
• 完全な復旧が確認されるまでの総時間は14時間49分
• Workspaceの利用者には「Something Went Wrong」のエラーが表示された（ダッシュボードの掲示のタイトルによる）

報告にある原因は、ツールの配備情報を管理するデータベースへの読み込みが一部の区画に集中し、処理しきれなくなったことでした。フロントエンドからの問い合わせ数が急に増え、もともと上限近くで動いていた仕組みが限界を越えた、と説明されています。

「エラーが減った時刻」と「完全に戻った時刻」は違う

この記録で押さえておきたいのは、約7時間でエラーは減ったが、完全な復旧の確認までは約15時間かかっている点です。途中で「動くようになった」と感じても、その後しばらくは不安定な状態が続きうる、ということです。

業務で言えば、エラーが減った時点ですぐに大量の作業を流し直すのではなく、まず小さな作業で動くことを確かめてから戻すのが安全です。

掲示が出るまでには時間差がある

ダッシュボードのJSON履歴を見ると、この障害の開始時刻は10:20（UTC）として記録されていますが、更新履歴に残っている最初の記録は12:40（UTC）です。日本時間に直すと、開始が19時20分ごろ、最初の更新記録が21時40分ごろです。

更新履歴に残る記録が掲示のすべてとは限らないので「必ず2時間遅れる」とは言えません。ただ、障害が起きた直後に公式ページを見ても、まだ何も出ていないことがあるのは確かです。「公式ページが正常＝自分側の問題」と即断しないための根拠として覚えておく価値があります。

9月11日には「一部のモデルだけ」の障害もあった

同じダッシュボードには、2026年9月11日の記録もあります。米国太平洋時間6:00〜13:22（日本時間では9月11日22時〜9月12日5時22分）に、Gemini 3.1 ProモデルをWebとアプリで使っていた一部の利用者で、エラー率が上がっていました。原因は直前の更新の展開で、コードの変更で収まったと記されています。

このときの区分は「Service information」で、全面的な停止ではありません。特定のモデルだけが不安定になる型もあるので、モデルを切り替えると動くかどうかは、切り分けの手がかりになります。

①Google Workspace Status Dashboardの読み方（Geminiアプリ・NotebookLM）

Geminiアプリと、GmailやGoogleドキュメントの中で使うGeminiは、Google Workspace Status Dashboardで確認します。Workspaceを契約していない個人アカウントでも、ページは誰でも開けます。

行を見る：「Gemini」と「Gemini Notebook」

ダッシュボードにはGmailやGoogle Meetなどと並んで、「Gemini」と「Gemini Notebook」の行があります。2026年5月19日のNotebookLMの障害（有料プランの利用者が無料プランの機能しか使えなくなった件）は「Gemini Notebook」の行に記録されていたので、NotebookLMの不具合はこちらの行を見ます。

4つの段階が意味すること

ダッシュボードの凡例は4段階です。

表示の名前はダッシュボードの凡例のとおりですが、「読み方」と「取るべき行動」は私たちが業務で判断するときの目安です。Googleが定めた定義や対応ではありません。

時刻はUTC表記なので、日本時間は9時間足す

ダッシュボードには「Times are listed in Coordinated Universal Time (UTC)」と書かれています。日本時間はUTCに9時間を足した時刻です。掲示の本文には米国太平洋時間（PDT）で書かれた箇所もあり、こちらは夏時間の期間なら16時間を足します。同じ掲示の中で時刻の基準が混ざるので、社内に共有するときは日本時間に直して書くと誤解がありません。

RSSとJSONで「先に気づく」

ページ下部には「RSS Feed」と「JSON History」のリンクがあります。RSSをSlackやメールに流しておけば、障害の掲示を自分から見に行かなくても気づけます。JSONには過去の障害の開始時刻・終了時刻・影響範囲・本文がまとまっているので、「前にも同じことがあったか」を後から確かめるときに便利です。この記事の6月10日と9月11日の時刻も、このJSONから読んでいます。

②AI Studioのステータスページの読み方（Gemini API・Google AI Studio）

APIキーでGeminiを呼んでいる場合や、Google AI Studioを使っている場合は、aistudio.google.com/statusを見ます。Gemini APIの公式ドキュメントの上部メニューにある「Status」もこのページにつながっています。

過去の障害は「API側だけ」のものが多い

このページの過去の障害一覧（2026年10月18日時点）には、次のような記録が並んでいます。

この一覧には、先に紹介した6月10日のGeminiアプリの障害は載っていません。アプリが止まった日でもAPIの側には掲示が出ていない、ということはアプリとAPIは別の系統として扱われていると読めます。逆に、APIに障害が出ている日に、アプリのダッシュボードは「Available」のままのこともありえます。

404でも「自分の間違い」とは限らない

10月1日の記録は覚えておく価値があります。404「Requested entity was not found.」は、普通に読めば「モデル名やリソースの指定を間違えた」というエラーです。実際、公式のエラー一覧でも404は「指定したリソースが見つからない」「指定したモデルが見つからない」という意味で載っています。

しかしこの日は、Google側の不具合で404が返っていました。昨日まで同じコードで動いていたのに急に404が出たなら、自分のコードを疑う前にステータスページを開くほうが早く答えに着けます。

バッチ処理は「失われた分」を自分で拾い直す

9月のバッチ障害では、特定の期間に予約されたバッチが失われた可能性があると掲示されました。課金されないのは助かりますが、処理されなかった仕事は自動では戻ってきません。夜間にバッチを流している場合は、障害の期間に入れた依頼を自分で洗い出して流し直す必要があります。

③Google Cloud Service Healthの読み方（Vertex AI・Gemini Enterprise）

Google Cloudのプロジェクト経由でGeminiを使っている場合は、status.cloud.google.comを見ます。2026年10月18日時点で、このページには「Gemini on Agent Platform」「Gemini Enterprise」「Gemini Code Assist」「Gemini Live Translate」などの行があります。旧来の「Vertex AI」の名前は、多くが「Agent Platform」の名前に置き換わっています。

• 地域ごとに表示される：凡例には「Available」と「Multiple regions affected」があり、自分が使っているリージョンに影響があるかを見ます
• 自分のプロジェクトに絞った通知：ページ自身が、自分のGoogle Cloudプロジェクトに影響する障害を詳しく見るには「Personalized Service Health」を使うよう案内しています
• RSSとJSON：こちらにも「RSS Feed」と「JSON History」があります

同じモデルでも、AI StudioのAPIキーで呼ぶ場合とVertex AI経由で呼ぶ場合では、見るページが違います。社内で両方を使っているなら、どの業務がどちらの経路かを一覧にしておくと、障害のときに迷いません。

公式ページが正常なのにエラーが出るときの切り分け

公式ページに何も出ていないときに考えられるのは、次の3つです。

• まだ掲示されていない：6月10日の例のように、発生から掲示までに時間差がある
• 一部の利用者・一部のモデルだけの劣化：9月11日の例のように、全体の停止ではない
• 本当に自分側の問題：利用上限・アカウント・回線・ブラウザ

Gemini APIはエラーコードで見分ける

APIを使っている場合は、返ってきたエラーコードがいちばんの手がかりです。Gemini APIの公式のエラー一覧（2026年9月20日更新）から、障害の判断に関係するものを抜き出しました。

公式のトラブルシューティングのページも、429や503のような「再試行してよい」エラーには間隔を指数関数的に広げる再試行（エクスポネンシャルバックオフ）を勧め、400・402・403のようなクライアント側のエラーは再試行しないよう書いています。403や402を再試行し続けても直らないので、ここで仕分けるだけで無駄な待ち時間が減ります。

Geminiアプリは「ほかの人も止まっているか」で見分ける

アプリにはエラーコードが出ないことが多いので、私たちは次の順番で切り分けています。

1. 新しいチャットで短い質問を1つ送る：長い会話や大きなファイルを添付した会話だけが失敗しているなら、障害ではなくその会話の問題の可能性があります
2. モデルを切り替える：9月11日のように特定のモデルだけが不安定なこともあります
3. ログインしているアカウントを確かめる：会社のWorkspaceアカウントでは、管理者がGeminiを有効にしていないと使えないことがあります。個人のアカウントと取り違えていないかも見ます
4. 別のブラウザ・スマホのアプリ・別の回線で試す：ここで動くなら、元の環境（拡張機能・社内ネットワーク）側の問題です
5. 同僚にも同じ操作をしてもらう：同じ時刻に複数人が止まっているなら、掲示がなくても障害を疑ってよい段階です

無料プランや有料プランで使えるモデルの範囲が変わったときも「急に使えなくなった」と感じます。2026年10月9日の変更で無料プランから使えるモデルが変わった件は、障害ではなく仕様の変更でした。

AI業務効率化Gemini無料でProが使えない｜10/9の変更

私たちの運用で起きたこと：429と503は分けて扱う

ここからは、私たちがGemini APIを業務に組み込んで分かったことです。

「障害だと思ったら、ただの上限だった」

動画の読み上げにGeminiの音声合成（TTS）モデルを使い始めたとき、声の候補を順番に試していたら、6声目で429が返って止まりました。最初は混雑を疑いましたが、調べると無料枠のAPIキーでは、そのモデルを呼べるのが1日10回までで、そこで打ち止めになっていただけでした。同じ時刻でも、軽量版の音声合成モデルは別枠で呼べました。

この経験から、私たちは429が出たら最初に「自分の上限に当たっていないか」を見るようにしています。429は「待てば戻る障害」ではなく「上限を超えた」という合図であることが多く、1日の上限なら何時間待っても当日中は戻りません。結局、1文ずつ読ませる作りをやめ、台本全体を1回で読ませてから無音の位置で切り分ける作りに変えて、呼ぶ回数そのものを減らしました。

音声合成の料金と、無料枠・有料枠の違いは別の記事でまとめています。

AI業務効率化Gemini 3.8 Flash TTSとは｜1分の料金と選び方

503は「別のモデルへ逃がす」

一方、503は本当に混雑していることが多いエラーです。私たちは、読み上げた音声を別のGeminiモデルに聞き取らせて読み間違いを確かめる工程を自動で回していますが、そのスクリプトではモデルを4つ並べておき、503や429などが返ったら次のモデルへ移る作りにしています。1つのモデルが混雑していても、工程全体は止まりません。

ただし、逃がし先のモデルに切り替わると結果の質が変わることがあります。そのため、どのモデルで処理したかを記録に残し、後から見返せるようにしています。

測れなかった数字は、埋めずに空けておく

記事のためにAPIの挙動を測っていたときに、429と503が続いて、予定していた条件の一部を測れなかったことがあります。そのときは、取れた条件だけで記事を書き、取れなかった条件の数字は推測で埋めませんでした。障害や上限で処理が途中で止まったときに大事なのは、どこまで終わって、どこから終わっていないかを記録しておくことです。後でやり直すときの手間が大きく変わります。

落ちている間に業務を止めないための備え

経路を2つ持っておく

6月10日の障害のように、アプリが止まった日にAPIの側には掲示がないこともあります。アプリが止まったらAI Studioで続ける、Geminiが止まったらChatGPTやClaudeで続ける、というように同じ作業を別の経路でできる状態にしておくと、止まる時間を短くできます。ほかのAIの障害の確認手順は、それぞれの記事にまとめています。

ChatGPTの障害を確認する方法｜Workが止まった時の手順

締切のある仕事ほど、時間を前に寄せる

6月10日の障害は、日本時間の夜から翌朝にかけて続きました。夜に仕上げる前提でAIに頼る作業を組んでいると、こうした障害でそのまま締切を越えます。AIに頼る工程は締切の前日までに一度通しておくと、障害が来ても手作業で間に合わせる時間が残ります。

無人で回す処理は「流し直せる」形にしておく

夜間のバッチや定期実行の処理は、障害で止まったときに気づきにくく、失われた仕事も勝手には戻りません。私たちは、処理ごとに「何を受け取り、何を出したか」を記録し、止まった処理だけをもう一度流せる作りにしています。9月のバッチ障害のように「一部が失われた可能性がある」と掲示されたときも、記録があれば対象を洗い出せます。

チームで使っているなら、最初にやるのは共有

社内の複数人がGeminiを使っているなら、1人が気づいた時点で「いまGeminiが不安定です。公式ページにはまだ掲示なし」と共有するだけで、全員がそれぞれ設定を疑って時間を使う事態を防げます。WorkspaceのRSSを社内のチャットに流しておけば、掲示が出た時点で全員に届きます。

復旧したあとにやること

• 小さな作業で動くことを確かめてから戻す：エラーが減ってから完全な復旧の確認までに時間がかかった例があります
• 止まっていた間の作業を洗い出す：送ったつもりの依頼・バッチ・定期処理が、本当に終わっているかを見ます
• 公式の障害報告を読む：大きな障害では、6月10日のように後から原因と再発防止策が掲示されます。同じ型の障害が起きたときの判断材料になります
• 社内の手順を直す：見るページを間違えた、共有が遅れた、といった気づきは、その日のうちに手順に足しておきます

よくある質問

公式ページが正常なのにエラーが出ます。どちらを信じればいいですか

まず、自分の入口に合ったページを見ているかを確かめてください。APIを使っているのにWorkspaceのダッシュボードを見ている、といった取り違えがよくあります。合ったページを見ていて正常なら、発生直後でまだ掲示されていない可能性と、自分側の原因の両方を並行して確かめます。複数人が同時に止まっているなら、掲示がなくても障害を疑ってよい段階です。

GeminiアプリとGemini APIは同時に止まりますか

同時に止まることもありえますが、別々に止まることもあります。2026年6月10日のGeminiアプリの障害は、AI Studioのステータスページの過去の障害一覧には載っていません。片方が止まっても、もう片方で作業を続けられる場合があります。

429が出ました。障害ですか

多くの場合は障害ではなく、自分のAPIキーの上限に当たっています。公式のエラー一覧でも、429は1分あたりの上限や1日のクォータを超えたときのエラーとして説明されています。1分あたりの上限なら少し待てば戻りますが、1日の上限なら翌日のリセットまで戻りません。AI Studioで自分の上限と使用量を確かめてください。

NotebookLMの障害はどこで確認できますか

Google Workspace Status Dashboardの「Gemini Notebook」の行です。2026年5月19日のNotebookLMの障害も、この行に記録されていました。

過去に障害があったかを後から調べられますか

調べられます。Workspaceのダッシュボードは「View incident history」とJSON履歴、AI Studioのステータスページは過去の障害一覧、Google Cloud Service HealthはJSON履歴から過去の記録を見られます。

まとめ

• Geminiの障害は、入口ごとに見る公式ページが違う（アプリ＝Workspace Status Dashboard、APIとAI Studio＝aistudio.google.com/status、Vertex AI系＝Google Cloud Service Health）
• 2026年6月10日の障害では、エラー率が高い状態が約6時間55分、完全な復旧の確認まで14時間49分かかった。エラーが減っても、すぐに全量を戻さない
• 掲示には時間差があり、一部のモデルだけの障害もある。公式ページが正常でも、自分側の問題と即断しない
• APIはエラーコードで仕分ける。503と500は障害の可能性が高く、429は多くが自分の上限、402と403は再試行しても直らない
• 備えは、経路を2つ持つこと、締切前にAIの工程を一度通しておくこと、無人の処理を流し直せる形にしておくこと

株式会社Fyveでは、AIを業務に組み込むときに、こうした「止まったときにどうするか」も含めて設計しています。障害は避けられませんが、止まったときの手順を決めておけば、止まる時間は短くできます。

参考にした情報源

• Google Workspace Status Dashboard（2026年10月18日に確認）
• Google Workspace Status Dashboard JSON History（2026年6月10日・9月11日・5月19日の記録）
• Google AI Studio Status（2026年10月18日に確認）
• Google Cloud Service Health（2026年10月18日に確認）
• Gemini API：API errors（2026年9月20日更新）
• Gemini API：Troubleshooting guide（2026年10月13日更新）