AIツール障害切り分けチェックリスト（TCP/TLS/HTTP）

「落ちた気がする」をチケット化すると、再現手順のないノイズが増えます。このメモは、開発・運用デスク向けの短いチェックリストです。監視製品の代替ではなく、黒箱シグナルの読み順の共有が目的です。

横断の入口には getstatus.ai を使っています（複数サービスの稼働・応答・インシデント文脈）。

チェックリスト

• 症状開始の壁時計時刻を残した
• 同一端末の別プロファイル / 別回線で再現を試した
• 公式ステータスと、独立チェッカーの両方を見た
• TCP → TLS → HTTP の順で読んだ（逆順にしない）
• 「接続健全」を機能保証と混同していない
• 403/429 を即アウトージと書いていない
• チャートの時間窓と自分の症状時刻を重ねた

SRE の基本文献でも、症状と原因を混ぜないことが強調されます（Monitoring Distributed Systems）。

プラットフォーム系ホストを先に見る場面

チャット UI ではなく API キー・請求・ダッシュボード側が怪しいとき、先に OpenAIのステータス を見ます。UI とプラットフォーム経路は別々に劣化することがあるためです。

クリエイティブ系 SaaS も同じ型

デザイン／ドキュメント系が巻き込まれた日は、同型で Adobeの稼働状況 を開きます。「AI だけ」「Adobe だけ」と決め打ちせず、午前中に触った面を列挙してから照合すると、ローカル拡張の切り分けが早くなります。

補足の外部視点として、Cloudflare Radar の障害データの見方は公式ドキュメント Outages が簡潔です（アプリ機能障害というよりネット規模の話ですが、独立観測の癖づけに使えます）。

チケットに書いてよい一文テンプレ

HH:MM に現象開始。別回線でも再現 / 非再現。独立チェッカーでは TCP/TLS=…、HTTP=…。公式ステータスは…。影響機能は（ログイン / 生成 / アップロード）。

これだけで、午後の「気のせい？」議論がかなり減ります。