Perplexityの障害を確認する方法｜4つの行の読み方

「Perplexityで検索しても答えが出てこない」「Computerに任せた作業がエラーで止まった」——調べものの途中でPerplexityが動かなくなると、Perplexity側の障害なのか、自分の回線や設定の問題なのかが分からず、まず手が止まります。

結論から言うと、Perplexityの障害は公式のステータスページ（status.perplexity.com）で確認できます。ページの行は「Website」「App」「Computer」「API」の4つだけです。ただし行だけを見ていると読み違えることがあります。私たちが公開されている障害の記録25件（2025年4月〜2026年10月）を1件ずつ読んだところ、APIの障害なのに「App」の行に付けられていた記録が少なくとも4件ありました。行の表示と一緒に、掲示のタイトルと本文を読むのが確実です。公式が正常なら、次に疑うのは自分のブラウザ・アプリ・VPNです。

株式会社Fyveは、AIの回答に自社の名前が出るかを測る研究のために、複数のAIに同じ質問を何十回も投げて回答を集めています。この記事では、Perplexityの公式ページと障害の記録をもとに、Perplexityが落ちたかを確かめる手順と、記録から分かる止まり方の傾向、止まっても仕事を止めないための備えをお伝えします。

結論：Perplexityが落ちたかは3ステップで確認する

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

1. status.perplexity.com を開き、自分が使っている入口の行を見る（下の表）。あわせて、ページ上部に掲示が出ていないか、出ていればタイトルと本文を読む
2. 行が正常でも、掲示のタイトルに「API」「connector」「sandbox」などの言葉が入っていないかを見る。行の付け方と実際の影響がずれることがあるため
3. 公式が正常なら、自分側を順に確かめる（強制再読み込み → アプリの更新 → VPNを切る → 30分ほど待つ）

2026年10月23日22時（日本時間）に私たちが確認した時点で、ステータスページの行はこの4つでした。全体の表示は「All Systems Operational」（すべて正常）です。ページは英語ですが、読むところは行の右側の表示と、上部の掲示の2つだけです。

なお、Perplexityのブラウザ「Comet」や、ほかのサービスとつなぐコネクタの行はありません。コネクタの障害は、これまで「Website」か「Computer」の行に付けられていました（後述）。

ステータスページそのものが開けないときは、まずほかのサイトが開けるかを確かめてください。ほかも開けないなら、原因はPerplexityではなく自分の回線です。

公式ヘルプが案内している確認の順番

Perplexityのヘルプセンターには、サポートに連絡する前に試すことをまとめた記事「Need support?」があります。そこに書かれている内容を、そのまま手順に直すと次のようになります。

止まって見えるときは、まず待つ

公式ヘルプは、会話の履歴が見えない・回答が生成されない・遅いといった問題は、たいてい30分から数時間で解消すると書いています。そのうえで、止まっているかどうかはステータスページで先に確かめるよう案内しています。

私たちが記録25件で、最初の掲示から解決の掲示までの時間を数えたところ、真ん中の値は約1時間40分でした。最も長かったのは、Sonar Proというモデルの応答の遅れ（2025年4月28日）で約20時間です。多くは公式の言う「30分から数時間」に収まっています。

自分側で試す3つのこと

公式ヘルプが挙げている、自分で試せることは次の3つです。

• ブラウザの強制再読み込み：Windowsは Ctrl + F5、Macは Command + Shift + R
• スマホのアプリの更新：アプリストアで新しい版が出ていないかを確かめる
• VPNを切る：VPNを使っている場合は、いったん切って試す

会社のパソコンで使っている場合は、社内のネットワークの制限やセキュリティソフトでつながらないこともあります。私用のスマホの回線で同じ質問を試し、動くなら原因は社内側です。

サポートに伝えること

それでも直らないときは、Perplexityの画面の「Help」から「Contact Support」に進みます。公式ヘルプが連絡に含めるよう求めているのは次の3つです。

• 使っている端末（Mac・Windows・iPhone・Android）
• ブラウザかアプリの版
• 問題が起きている会話の共有リンク

回答の中身が間違っている場合は、障害ではありません。回答の下のメニュー（「…」）から「Report」で報告するよう案内されています。

25件の記録から分かること

ステータスページの記録は、機械が読むための形式（JSON）でも公開されています。私たちはこれを取り出し、2025年4月2日〜2026年10月10日の25件を1件ずつ読みました。数字で見ると、Perplexityの止まり方の傾向がはっきりします。

最近の障害は、ほとんどがComputer

25件の掲示で、影響を受けた行として挙がった回数は次のとおりでした（1件で複数の行に影響したものは、それぞれ数えています）。

注目したいのはComputerです。行ができたのは2026年6月末で、そこから10月10日までの障害は10件ありました。そのうち9件がComputerの行に影響しています。タイトルを見ると「Computer Sandbox Issue」（Computerの作業環境の問題）が繰り返し出てきます。作業ごとに用意される隔離された環境（サンドボックス）が、うまく動かなかった記録です。

Computerは、ファイルの作成やコードの実行など何段もの作業を長い時間かけて進める機能です。普通の検索より部品が多く、止まる場所も多くなります。検索が動いているのにComputerだけが止まる、という状況は珍しくありません。

APIの障害が「App」の行に付けられていた

表で「API」が1件しかないのは、APIの障害が少ないからではありません。APIの行ができたのが2026年5月中旬で、それより前の記録にはAPIの行が無かったためです。

実際に、タイトルにAPIと入っている障害の行を確かめると次のようになっていました。

• 2025年4月28日「P99 First Token Latency of Sonar Pro is elevated」（Sonar Proの最初の応答が遅い）：App
• 2025年5月7日「Investigating increased API latency」（APIの応答の遅れを調査中）：App
• 2026年2月17日「Sonar API incident」（Sonar APIの障害）：App
• 2026年8月13日「Investigating API issue」（APIの問題を調査中）：App

4件目は、APIの行ができた後の記録です。それでも付けられた行はAppでした。APIを使っている人がAPIの行だけを見ていると、障害を見落とすことになります。行の表示に加えて、掲示のタイトルに「API」や「Sonar」（PerplexityのAPIで使うモデルの名前）が入っていないかを読むのが確実です。

最初の掲示は、あとで直されることがある

いちばん新しい2026年10月10日の記録は、掲示が途中で訂正された例です。時刻は日本時間に直しています。

• 7時38分：「Elevated API errors and timeouts」（APIのエラーとタイムアウトの増加）の掲示。このとき4つの行すべてが「性能低下」になっていた
• 8時01分：原因を抑えた、と様子見に入る
• 8時10分：「これまでの掲示の訂正：APIは影響を受けておらず、正常に動いている」
• 8時15分：解決。影響があったのはWebsite・App・Computerで、APIは通して正常だった、と締めくくっている

タイトルはAPIの障害なのに、実際に止まったのはAPI以外でした。障害が起きた直後の掲示は、原因も範囲もまだ確かでないということです。最初の掲示だけを見て「APIが止まったので自社のシステムを止める」と判断すると、止める必要のないものまで止めることになります。急ぎでなければ、次の掲示を待ってから判断するほうが安全です。

「クレジットが足りない」が障害だったこともある

2026年9月4日5時30分の掲示は「Issue with usage based billing」（利用量に応じた課金の問題）でした。本文には、Computerが「クレジットが足りない」と誤って表示していると書かれています。40分後に解決しました。

利用の上限や残高の表示が急におかしくなったときは、自分の契約やチャージを疑う前に、ステータスページを一度見てください。残高が足りないという表示そのものが、障害の症状だったことがあります。

Perplexityの外の障害でも止まる

25件のうち4件は、Perplexityが自分で使っている基盤のサービスの不調が原因だと、掲示の中で説明しています。

• 2025年10月20日：Amazonのクラウド（AWS）の障害に関連して、Webサイトでエラーが増えた（15時54分〜18時55分）。日付が変わった21日0時53分からも、同じAWSの不調に関連する障害として約5時間続いた（2件として記録）
• 2025年12月5日：「Service outage」。基盤の提供元の問題が原因で、約35分
• 2026年5月8日：AWSの基盤に原因があり、AWSと協力して直していると説明

こうした日は、Perplexityだけでなく、同じ基盤を使うほかのサービスも同時に止まっていることがあります。Perplexityの代わりに別のAIで調べようとして、そちらも動かない、ということも起こりえます。

コネクタの障害は2回

ほかのサービスとつなぐコネクタの障害は、2026年6月5日（約4時間半）と9月5日（約2時間20分）の2回でした。6月はWebsiteの行、9月はComputerの行に付けられています。どちらも「一部のコネクタ」の問題で、検索そのものは動いていた可能性があります。

コネクタを通して社内の資料やメールを読ませている場合は、コネクタを外した普通の検索で動くかを試すと、どこが止まっているかの切り分けになります。

日本では早朝と金曜に重なりやすい

25件の始まりの時刻を日本時間に直すと、6時〜12時が9件と最も多くありました。曜日では金曜が9件です。米国の平日の日中が、日本の早朝から朝にあたるためと考えられます。

朝いちばんに調べものをしてPerplexityが動かない、という場面は、記録の上でも起こりやすい時間帯です。出社直後に急ぎの調べものがある日は、別の手段も頭に入れておくと慌てずに済みます。

症状別：Perplexity側か自分側かの切り分け

ここまでの記録と公式ヘルプをもとに、よくある症状ごとの切り分けを表にまとめます。

APIを使っている人の切り分け：429は障害とは限らない

自社のシステムからPerplexityのAPIを呼び出している場合は、エラーの種類を見ると障害かどうかの見当がつきます。Perplexityの開発者向けの文書（Rate Limits and Usage Tiers）によると、呼び出しが多すぎるときは429（Too Many Requests）が返ります。429で断られた呼び出しには料金がかかりません。

429の中身は3種類に分かれています。

前の2つは自分の使い方が原因で、障害ではありません。3つ目の「overloaded」は、Perplexity側が混み合っている状態です。これが続くときはステータスページを見に行く価値があります。

文書には、やり直しの回数を絞ることも書かれています。文字量の上限で断られた呼び出しも、回数の上限には数えられるためです。すぐにやり直す処理を何本も同時に走らせると、それ自体が新しい429を呼びます。

上限の段階（Tier）は、これまでの購入額の合計で決まります。2026年10月23日時点の公式文書では、0ドルのTier 0から、5,000ドル以上のTier 5までの6段階です。今の残高ではなく合計で決まり、一度上がった段階は下がりません。上限に当たり続けるなら、まず自分の段階を確かめてください。最新の条件はPerplexityの公式文書で確認してください。

止まったことに早く気づく：通知の受け取り方

ステータスページを毎回開きに行くのは手間です。status.perplexity.com は障害の掲示を配信する仕組みを持っています。

• メールで受け取る：ページの「Subscribe to updates」から登録できる
• RSS・Atomで受け取る：status.perplexity.com/feed.rss と status.perplexity.com/feed.atom が公開されている（2026年10月23日に私たちが取得して確認）。RSSを読めるツールやチャットツールの連携に登録すれば、掲示が出たときに知らせが届く

2026年10月23日時点では、ショートメッセージ（SMS）での通知は有効になっていませんでした。

私たちは、AIの回答を自動で集める処理を動かしています。この仕事で困るのは、止まったこと自体より、止まったことに気づかずに結果を読んでしまうことです。たとえば「自社の名前が出たか」を数えるとき、障害で回答が返ってこなかった回を「名前が出なかった」と数えると、結果がそのまま歪みます。

そのため私たちの計測では、混雑や一時的なエラー（429や500番台）のときは間隔を空けて数回やり直し、それでも返ってこなかった回は「失敗」として別に記録しています。0件と失敗を混ぜないことが、障害の日の結果を後から読み直せる条件です。Perplexityを業務の処理に組み込むなら、同じ考え方が使えます。

Perplexityが止まっても仕事を止めない備え

障害そのものは利用者には防げません。できるのは、止まったときの影響を小さくしておくことです。

調べものの代わりの手段を1つ決めておく

Perplexityが止まったときに使う別のAI検索を、あらかじめ1つ決めておきます。ChatGPTやGeminiの検索機能、Claudeの検索機能などです。ただし前述のとおり、基盤のクラウドの障害の日は複数のサービスが同時に止まることがあります。代わりの手段が動かないときは、普通の検索エンジンで一次情報を直接読むのが最後の逃げ道です。

代わりの手段の障害の確かめ方は、それぞれ別の記事にまとめています。

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

AI業務効率化Geminiの障害を確認する方法｜3つの公式ページの使い分け

Claudeの障害を確認する方法｜落ちた時に業務を止めない手順

Computerに任せる作業は、やり直せる単位に分ける

Computerの障害は、作業の途中で起きることが多いと考えられます。何時間もかかる作業を1回で任せていると、途中で止まったときにどこまで進んだかが分からなくなります。

作業を「調べる」「まとめる」「ファイルにする」のように区切り、区切りごとに結果を残しておくと、止まった場所からやり直せます。障害の掲示が出ている間に投げ直すと、同じところでまた止まることがあるため、やり直しは解決の掲示を見てからにします。

大事な答えは、出典を開いて確かめる

障害の日に限らず、Perplexityの回答には出典のリンクが付きます。急いでいるときほど回答だけを読みがちですが、仕事に使う数字や日付は、出典のページを開いて確かめてください。障害で一部の処理だけが失敗した日は、回答の質が落ちていても見た目では分かりにくいためです。

Perplexityが答えの中でどんな情報を引いているかを知っておくと、確かめる手間も減ります。Perplexityに引用される側の視点でまとめた記事もあります。

Perplexityに自社情報を引用させるには？企業向けAI検索対策ガイド

まとめ：行だけでなく、掲示の文字を読む

Perplexityの障害の確かめ方を、もう一度まとめます。

• 確認先は status.perplexity.com。行は Website・App・Computer・API の4つ（2026年10月23日時点）
• 行の表示だけで判断しない。APIの障害が「App」の行に付けられていた記録が少なくとも4件ある。掲示のタイトルの「API」「Sonar」「connector」「Sandbox」を読む
• 最初の掲示は訂正されることがある。2026年10月10日は、APIの障害として掲示されたあと「APIは影響なし」と訂正された
• 最近の障害はComputerに集中。行ができた2026年6月末以降の10件のうち9件
• 公式が正常なら自分側。強制再読み込み → アプリの更新 → VPNを切る。公式ヘルプは「30分から数時間で解消することが多い」としている
• APIの429は障害とは限らない。overloaded 以外は自分の呼び出し方の問題

Perplexityのステータスページは行が4つしかなく、読むところは少ないぶん、行の付け方のずれが判断に響きます。行の色だけで済ませず、掲示の本文まで読む習慣が、いちばん確実な見分け方です。

株式会社Fyveでは、こうしたAIの道具を業務に組み込むときに、止まったときの備えまで含めて設計しています。障害の確かめ方は、道具を選ぶときにはあまり気にされませんが、毎日使うほど効いてくる部分です。