Next TokenParallel World

← ラボ

原因や責任を決めつけないために、当事者の事後報告、裁判所・規制当局・政府機関の文書など、一次資料が読めた事案だけを載せています。報道だけの話は載せません。個人名は出さず、金額も書きません。「まだ分かっていないこと」は、公式が書いていないこと、僕らが確かめられていないことです。

障害Microsoft Azure2026-09-30 20:30 UTC〜2026-10-01 02:15 UTC

Azure 多数のリージョンでネットワークのゲートウェイ関連サービスが不安定に

Azureの複数のネットワークサービス（ExpressRoute Gateway、Application Gateway、Azure Firewallなど）で、管理操作が断続的に失敗し、一部のExpressRouteゲートウェイは接続を失いました。Microsoftは、止めていたゲートウェイのOS更新が一度に再開され、以前に入れた変更で処理が遅くなっていた制御プレーンに負荷が集中したと説明しています。

時系列（6件）
  1. 2026-09-30 20:30 UTC　お客様への影響が始まった。
  2. 2026-09-30 21:45 UTC　ゲートウェイのOS更新をさらに止めた。
  3. 2026-09-30 22:36 UTC　影響を受けたExpressRouteゲートウェイが、最後に正常だった設定を使って接続を回復した。
  4. 2026-09-30 23:55 UTC　設定処理の遅さが、以前に入れた性能面の変更と結びつけられ、ロールバックを決めた。
  5. 2026-10-01 01:15 UTC　最初のリージョンでロールバックを始め、確認しながら進めた。
  6. 2026-10-01 02:15 UTC　影響のあるリージョンでロールバックが終わり、影響が終わった。

公式資料で分かっていること

  • 影響を受けたのは、ExpressRoute Gateway、Application Gateway、Azure Firewall、Azure Bastion、Virtual WAN、VPN Gateway。Azure VMware Solutionも、一時的に接続を失った可能性がある、と書かれている。
  • ページには33のリージョンが挙げられている。
  • 一時的な展開制限で止まっていたOS更新が、期限切れで大量に一度に再開し、ゲートウェイの再起動と設定リクエストが急増した、と書かれている。
  • Microsoftは、以前に入れた変更で設定処理に時間がかかるようになっていたこと、既存の流量制限と保護が重要な処理を十分に守れなかったことも原因に挙げている。
  • ExpressRouteでは、再起動したインスタンスが設定と経路の状態を戻す前に「正常」とされ、更新が冗長側のインスタンスに移り、約30分後に最後に正常だった設定を使うまでオンプレミスとの接続を失った、と書かれている。
  • Microsoftは、このインシデントでお客様が影響を避けたり小さくしたりできる方法はなかった、と書いている。
  • 完了した対策は、性能に影響した変更のロールバック。進行中は、止めた更新の再開方法の改善（2026年10月予定）、ExpressRouteのヘルスチェック強化と制御プレーンのスケールアウトを妨げた問題の修正（2027年3月予定）、制御プレーンの流量制限と負荷の切り捨ての改善（2027年6月予定）。

まだ分かっていないこと

  • 以前に入れた変更の中身や、それが設定処理を遅くした理由の詳しい説明は、読んだ範囲では確認できていない。
  • 影響を受けたお客様の数や割合は、書かれていない。書かれている影響時間は、全体の時間で、個々のお客様のものではない。
  • 進行中の対策の完了は、確認していない。
  • リージョン数の33は、ページに数字が書かれているわけではなく、挙げられたリージョン名を数えた値。

読むときの注意：止めていた自動更新が期限切れで一度に動き出すと、普段は問題ない仕組みにも負荷が集まることがある、とこの報告は示しています。止めたものの再開の仕方を見直すことが、Microsoftの対策にも入っています。

出典（2件）
障害Microsoft Azure2026-09-29 10:03〜15:58 UTC

Azure OpenAI Serviceなど Sweden Centralのリクエスト失敗と遅延

AzureのSweden Centralリージョンで、Azure OpenAI Service、Foundry Agent Service、Foundry Models、Azure AI servicesのリクエストが断続的に失敗し、遅くなりました。Microsoftは、計画していたデプロイでキャッシュが空になり、バックエンドへの負荷が急に増えたうえ、ヘルスチェックが再起動の繰り返しを起こしたと説明しています。

時系列（6件）
  1. 2026-09-29 09:38 UTC　リージョン内で、内部サービスの計画されたデプロイが始まり、そのサービスのキャッシュが空になった。
  2. 2026-09-29 10:03 UTC　サービスのインスタンスが不安定になり、お客様への影響が始まった。
  3. 2026-09-29 10:17 UTC　監視がエラー率の上昇を検知し、エンジニアに通知した。
  4. 2026-09-29 15:40 UTC　ヘルスチェックを、遠隔への接続に頼らない設定に変えた。再起動の繰り返しが止まり、回復が始まった。
  5. 2026-09-29 15:58 UTC　可用性が戻り、影響が緩和された。
  6. 2026-09-29 16:30 UTC　負荷の発生源が、内部サービスのデプロイと結びつけられた。

公式資料で分かっていること

  • 影響は、リクエストの断続的な失敗、遅延の増加、HTTP 500と503のエラー。影響の大きさはお客様やリソースによって違った、と書かれている。
  • Microsoftは、ピーク時にキャッシュが空になり、さらにキャッシュの読み方に別の不具合が2つあったため、バックエンドへの通信が通常の約20倍になったと説明している。
  • 接続の容量が尽き、新しい接続が失敗した。各インスタンスのヘルスチェックはデータベース層への接続に頼っていて、つながらないインスタンスが再起動を繰り返し、元気なインスタンスが減った、と書かれている。
  • 既存の指標では接続の使い切りがはっきり見えず、原因の特定が遅れた。台数やメモリを増やしても、ヘルスチェックの問題が見つかるまでは直らなかった、と書かれている。
  • 完了した対策は、ヘルスチェックをデータベース接続に頼らないようにしたこと、キャッシュ層の負荷と遅延の監視を足したこと、接続を使い切る場合の手順を更新したこと。
  • 進行中の対策は、バックエンドへの流量制限（2026年10月の予定）、キャッシュ層の容量増（同10月）、診断指標と自動検知の改善（同10月）、キャッシュ層の分割（同12月）。

まだ分かっていないこと

  • どの内部サービスのデプロイだったのかは、ページでは確認できていない。
  • 影響を受けた割合やエラー率の数値は、読んだ範囲では書かれていない。
  • 進行中の対策が予定どおり終わったかは、確認していない。

読むときの注意：障害が長引いた理由の一つは、ヘルスチェックが依存先につながらないと再起動を繰り返す作りだったことだ、とMicrosoftは書いています。自分たちのサービスでも、ヘルスチェックが何に頼っているかを一度見ておくとよいです。

出典（2件）
障害Google Cloud2026-08-20（暫定報告 2026-08-24、最終報告 2026-08-27）

Google Cloud 2026年8月20日 us-west1の複数製品の障害

Google Cloudのus-west1（オレゴン）で、複数の製品にタイムアウトやエラー、遅延が起きました。Googleは、予定されていた光ファイバーの保守で容量が減り、自動の迂回が想定どおりに働かなかったことが原因だと説明しています。

時系列（5件）
  1. 2026-08-20　最終報告では08:00 PDT、見出しでは08:40 PDTに影響が始まったと書かれている。
  2. 2026-08-20　10:13から10:32 PDTの更新で、緩和作業中であり、可能なら他の地域へ切り替えるよう案内された。
  3. 2026-08-20　最終報告では10:22 PDTに緩和されたと書かれている。
  4. 2026-08-24　暫定報告が出た。
  5. 2026-08-27　最終報告が出た。

公式資料で分かっていること

  • 暫定報告・最終報告とも、保守で地域内のデータセンター間の容量が減り、自動の迂回が通信を移せず、混雑や再試行の連鎖が起きた、と書かれている。
  • 最終報告には、SpannerやUnified Metadata Serverの遅延が連鎖して、Cloud StorageやIAMなどにエラーが出た、という追加の説明がある。
  • 最終報告は、us-west1以外は影響を受けなかった、と書いている。ただし影響地域の一覧には「Global」も載っており、ページ内で整理されていない。
  • 今後の対策として、保守手順の見直し、保守前の安全確認と回線の冗長化要件の強化、自動の地域フェイルオーバーの改善が挙げられている。

まだ分かっていないこと

  • 迂回が働かなかった理由や、対象の回線。
  • 影響の規模（割合、エラー率、遅延の数値）。
  • ページ内の時刻の食い違い（見出し08:40〜12:20と、最終報告08:00〜10:22）の説明。
  • 長期の対策の期限と担当。

読むときの注意：障害のページには、見出しの時刻と報告書の時刻が違って見えることがあります。どちらを使うか決めたうえで、数字の出どころを書いておくとよいです。ここに書かれている日付は、このページが表示している日付です。

出典（1件）
障害Microsoft Azure2026-07-23 14:44〜19:41 UTC

Azure West USで出入りの通信に接続失敗と遅延

AzureのWest USで、リージョンに出入りする通信に接続の失敗と遅延が起きました。Microsoftは、光ネットワーク機器の修理の範囲が誤って広がり、安全確認もそれを見逃して、1つのデータセンターの経路が同時に止まったと説明しています。

時系列（6件）
  1. 2026-07-23 14:44 UTC　機器の修理が始まった。お客様への影響が出始めうる最も早い時刻。
  2. 2026-07-23 16:58 UTC　自動復旧が再試行を重ねても直らず、エンジニアに調べるよう知らせた。
  3. 2026-07-23 17:19 UTC　エンジニアが、経路の異常と修理を結びつけ、自動ロールバックを試み始めた。
  4. 2026-07-23 17:45 UTC　手動でのロールバックを始めた。
  5. 2026-07-23 18:26 UTC　影響のある機器すべてでロールバックが成功した。エンジニアは回復を監視した。
  6. 2026-07-23 19:41 UTC　影響が緩和されたと確認された。

公式資料で分かっていること

  • 影響を受けたのは、リージョンに出入りする通信だけで、リージョン内で完結する通信は影響を受けなかった、と書かれている。
  • App Service、AKS、Cosmos DB、Azure Firewall、ExpressRoute、Azure Monitorなど多くのサービスが影響を受けた。Microsoft 365への波及は、別の追跡番号で扱われている。
  • Microsoftは、影響範囲を見積もるシステムの不具合で修理の範囲が1つのデータセンターの光機器すべてに広がり、安全確認は機器を1台ずつ見て、まとめて止めた場合の影響を見ていなかった、と説明している。
  • 物理リンクや経路の隣接関係は正常に見え、データセンターの接続障害ではなくWANの経路異常のように見えたため、原因の特定が遅れた、と書かれている。
  • 自動の復旧とロールバックも、同じ壊れた接続に頼っていたため成功しなかった、と書かれている。
  • 完了した対策は、不具合の修正、同様の条件の修理依頼の洗い出し、データセンターの経路をすべて同時に止める保守を防ぐ安全確認の強化。進行中は、2026年8月〜10月の予定で、変更台帳への記録、監視の強化、複数機器を同時に止められないようにすること、自動復旧とロールバックの改善。

まだ分かっていないこと

  • 修理を始めた機器や、その理由となったネットワーク上のリスクの詳しい内容は、読んだ範囲では書かれていない。
  • 影響を受けたお客様の数や割合は、書かれていない。
  • 進行中の対策が予定月までに終わったかは、確認していない。

読むときの注意：安全確認が機器を1台ずつ見るだけで、まとめて止めた場合の影響を見ていなかったことが、原因の一つとして書かれています。復旧の仕組みが、止まった経路そのものに頼っていないかも、点検の対象になります。

出典（2件）
障害Cloudflare2026-02-20 17:56〜23:03 UTC（ブログ公開は2026-02-21）

Cloudflare 2026年2月20日 BYOIPのIPアドレス範囲がインターネットから取り消された障害

CloudflareのBYOIP（お客様が持ち込んだIPアドレス）の一部で、経路情報がインターネットから取り消され、接続できなくなりました。Cloudflareは、サイバー攻撃ではなく、自社が入れたIPアドレス管理の変更の不具合が原因だと説明しています。

時系列（6件）
  1. 2026-02-05 21:53 UTC　問題のあるサブ処理がコードに取り込まれた。
  2. 2026-02-20 17:46 UTC　その変更を含むAddressing APIのリリースが展開された。
  3. 2026-02-20 17:56 UTC　タイムライン上の影響の開始。経路の取り消しが広がった。
  4. 2026-02-20 18:46 UTC　問題のサブ処理を止め、定期実行を無効にした。
  5. 2026-02-20 19:19 UTC　お客様がダッシュボードから経路を再広告し始めた。
  6. 2026-02-20 23:03 UTC　残りの設定の展開が終わり、影響が終わった。

公式資料で分かっていること

  • 1つの接続先に広告していた約6,500の経路のうち約1,100が取り消され、BYOIPの4,306のうち約25%が含まれていた、と書かれている。
  • 影響を受けたのは、Core CDNとセキュリティ、Spectrum、Dedicated Egress、Magic Transit。1.1.1.1によるDNSの名前解決は影響を受けなかった、と書かれている。
  • Cloudflareは、手作業だったお客様の削除作業を自動化した変更で、掃除用のサブ処理が値を空にしてAPIを呼び、サーバーがそれをすべてのBYOIP経路の指定と読み、全経路が削除の対象になった、と説明している。
  • ステージングの模擬データでは見つからず、人の入力なしで処理が動く場合のテストが足りなかった、と書かれている。
  • お客様が自分で再広告できた場合もあったが、約300の経路はCloudflareのエンジニアが手作業で戻した。サービスとの紐づけが消えた経路は、全エッジへの設定更新が必要だった、と書かれている。
  • 今後の対策は、APIの仕様の見直し、ロールバックの仕組みとデータベース構成の見直し、本番に反映するデータをスナップショットにすること、広範囲・急な取り消しや削除を検知して止める仕組みの追加、など。

まだ分かっていないこと

  • 対策のうち、スナップショットの仕組みは公開時点では本番にまだ入っておらず、完了の期限は書かれていない。
  • 記事の冒頭の開始時刻（17:48 UTC）とタイムライン（17:56 UTC）が食い違い、書かれている合計時間もタイムラインと合わない。どちらが正しいかは、記事からは分からない。
  • エッジから設定を消したソフトウェアの不具合の原因は、読んだ範囲では説明されていない。
  • テストの改善の中身は、詳しく書かれていない。

読むときの注意：値が空のときの扱いが、サーバー側で「すべて」と読まれたことが原因だと書かれています。削除のような影響の大きい操作では、APIの仕様の見直しや、変更が急に広く及ぶのを検知して止める仕組みが、対策として挙げられています。

出典（2件）
障害Cloudflare2026-01-22 20:25〜20:50 UTC（ブログ公開は2026-01-23）

Cloudflare 2026年1月22日 マイアミのルーターでIPv6の経路情報が漏れた件

Cloudflareのマイアミのエッジルーターが、一部のIPv6の経路情報を、通信相手の事業者に意図せず広告しました。約25分続きました。Cloudflareは、自動化された経路ポリシーの設定の誤りが原因だと説明しています。

時系列（5件）
  1. 2026-01-22 19:52 UTC　不具合を起こす変更が、ネットワーク自動化のリポジトリに取り込まれた。
  2. 2026-01-22 20:25 UTC　マイアミの1台のルーターで自動化が実行され、意図しない広告が始まった。
  3. 2026-01-22 20:44 UTC　インシデントが宣言された。
  4. 2026-01-22 20:50 UTC　誤った設定を手作業で戻し、そのルーターの自動化を止めた。影響が止まった。
  5. 2026-01-22 22:40 UTC　自動化が、そのルーターで再開された。

公式資料で分かっていること

  • 影響はIPv6の通信だけ。マイアミとアトランタの間のバックボーンが混雑し、一部のお客様の通信でパケットの損失と遅延が増えた、と書かれている。
  • ファイアウォールが、本来の送り先でない経路宛ての通信を捨てた。ピーク時には、マイアミのルーターに入ってきた約12 Gbpsの通信を捨てた、と書かれている。
  • Cloudflareは、ボゴタの経路リストを外す変更で、ある条件が「内部経路」の一致と許可だけになり、Juniper機器ではiBGPの内部経路まで含まれ、内部のIPv6経路が外部に広告された、と説明している。
  • 今後の対策として、ルーティングポリシーに足すBGPコミュニティの安全策、ポリシーを自動で評価するチェックのCI/CDへの追加、などが挙げられている。

まだ分かっていないこと

  • 対策のうち、どれが公開時点で完了していたかは、記事の書きぶりからは分からない。
  • この変更がなぜレビューなどをすり抜けたのかは、読んだ範囲では書かれていない。
  • 影響の規模（失われた通信の量や遅延の数値、影響を受けた外部ネットワークの名前）は、ピーク時に捨てた通信量のほかは書かれていない。
  • 長期の対策（RFC 9234の確認、ASPAの普及）の期限は書かれていない。
  • 経路の例としてMeta(AS32934)とLumen(AS3356)が記事に出てくるが、影響を受けたネットワークとして書かれているかは確認できていない。

読むときの注意：設定の一部を外す小さな変更で、条件が意図より広く一致するようになることがあり、Cloudflareは自動チェックを足す対策を挙げています。外す変更も、足す変更と同じように確かめる必要があります。

出典（2件）
障害Cloudflare2025-12-05 08:47〜09:12 UTC

Cloudflare 2025年12月5日の約25分の障害

Cloudflareで、約25分間、一部の顧客のウェブサイトがHTTP 500エラーを返しました。同社は、WAFの設定変更が、旧型プロキシ（FL1）のコードの誤りを引き起こしたと説明しています。サイバー攻撃が原因ではない、と書いています。

時系列（4件）
  1. 2025-12-05　08:47 UTCに設定変更が配備・伝搬された。
  2. 2025-12-05　08:50 UTCに自動アラートでインシデントが宣言された。
  3. 2025-12-05　09:11 UTCに変更が取り消され、伝搬が始まった。
  4. 2025-12-05　09:12 UTCに取り消しが全体に行き渡り、通信が回復した。

公式資料で分かっていること

  • 変更は、React Server Componentsの脆弱性（CVE-2025-55182）への対策として、WAFのリクエスト本文のバッファを128KBから1MBに上げる作業の中で行われた、と書かれている。
  • その際に、社内のWAFルールのテストツールを無効にする変更も行われ、FL1プロキシでLuaの実行時エラーが起きた、と説明されている。
  • 影響は、Cloudflareが配信するHTTPトラフィック全体の約28%。旧型プロキシを使い、Managed Rulesetを有効にしていた顧客が対象と書かれている。中国のネットワークは影響を受けなかった。
  • 新しいFL2プロキシ（Rust製）にはこの誤りがなかった、と書かれている。
  • 今後は、設定データの段階的な展開と素早い取り消し、障害時に使う緊急手段の整備、設定が不正なときに通信を落とさず安全な状態へ戻す動き（フェイルオープン）、ネットワーク変更の一時凍結が挙げられている。

まだ分かっていないこと

  • 影響を受けた顧客や要求の絶対数。
  • 全体に数秒で反映されるグローバル設定の仕組みと説明されているが、この変更にその仕組みを使った経緯。
  • 改善項目の完了日。
  • 事後報告が約束した、より詳しい資料が公開済みかどうか。

読むときの注意：短い障害でも、公式の事後報告は「何割のトラフィックか」「どの構成の顧客か」を書いています。自分のサイトがどの構成に当たるかは、各自の契約や設定で違うので、公式の記載と自分の設定を照らして確認するとよいです。

出典（1件）
障害Cloudflare2025-11-18 11:20 UTC頃〜17:06 UTC

Cloudflare 2025年11月18日の大規模な障害

Cloudflareのネットワークで、HTTP 5xxエラーが広く発生しました。同社は、データベースの権限変更により、ボット管理用の設定ファイルが想定より大きくなり、プロキシの上限を超えたことが原因だと説明しています。サイバー攻撃が原因ではない、とも書いています。

時系列（5件）
  1. 2025-11-18　11:05 UTCにデータベースのアクセス制御の変更が入った。
  2. 2025-11-18　11:28 UTCに顧客環境で影響が始まった。
  3. 2025-11-18　13:05 UTCにWorkers KVとAccessの迂回策が入り、影響が減った。
  4. 2025-11-18　14:30 UTCに正しい設定ファイルが全体に配られ、主な影響が解消した。
  5. 2025-11-18　17:06 UTCにすべてのサービスが復旧した。

公式資料で分かっていること

  • 権限変更により、設定ファイルを作る問い合わせが重複した行を返し、ファイルが約2倍の大きさになった、と書かれている。
  • プロキシの機能数の上限（200）をファイルが超え、処理されないエラーでプロキシが異常終了した、と説明されている。
  • 当初、同社は大規模なDDoS攻撃を疑ったが、のちに設定ファイルの問題と分かった、と書かれている。ステータスページの停止は偶然だったとも書かれている。
  • 影響を受けたのは、CDNと各種セキュリティ、Turnstile、Workers KV、ダッシュボード、Email Security、Accessなど。
  • 今後は、自社生成の設定ファイルを利用者入力と同様に厳しく検査する、機能ごとの緊急停止スイッチを増やす、各モジュールの障害時の動きを見直す、と書かれている。

まだ分かっていないこと

  • 改善項目ごとの期限や担当、進み具合。
  • 権限変更の影響が、なぜ配備前に見つからなかったか。
  • 影響を受けた顧客の数や割合。
  • ステータスページ停止の詳しい技術的な説明。

読むときの注意：ある会社の障害時に、自分のサービスが見られなくなったり、ログインできなくなったりすることがあります。原因が攻撃かどうかの説明は、公式の事後報告で確認できる点です。公式の時刻は協定世界時（UTC）なので、日本時間にそろえて読むのが無難です（見立てです）。

出典（1件）
障害Amazon Web Services（AWS）2025-10-19 23:48 PDT〜2025-10-20 14:20 PDT

AWS 米国東部（バージニア北部）でDynamoDBの障害

AWSの米国東部（us-east-1）で、DynamoDBのAPIエラーが起き、そこから EC2 の新規起動の失敗や Network Load Balancer の接続エラーなど、他のサービスにも影響が広がりました。AWSは、DynamoDBのDNS自動管理にある競合状態（race condition）が引き金だったと説明しています。

時系列（6件）
  1. 2025-10-19　23:48 PDTにDynamoDBのAPIエラーが始まった。
  2. 2025-10-20　0:38 AM PDTに、技術者がDynamoDBのDNSの状態が原因だと特定した。
  3. 2025-10-20　2:25 AM PDTにDNS情報が復旧し、2:40 AMまでにキャッシュが切れてDynamoDBのエラーは解消した。
  4. 2025-10-20　EC2の新規起動の失敗は2:25 AMから10:36 AMまで続き、10:37 AMから起動が成功し始めた。
  5. 2025-10-20　Network Load Balancerの接続エラーは5:30 AMから2:09 PMまで続いた。
  6. 2025-10-20　2:20 PM PDTを全体の終了時刻としている。

公式資料で分かっていること

  • 原因は、DNS計画を適用する2つの独立した部分（DNS Enactor）の間の競合状態、とAWSは書いている。遅れた側が古い計画を新しい計画のあとに適用し、もう一方の掃除処理がその古い計画を消した結果、地域エンドポイントのIPアドレスがすべて消えた、という説明。
  • 影響は3つの期間に分けて書かれている（DynamoDB、NLB、EC2）。
  • DynamoDBのDNS自動化は世界中で無効化され、競合状態の修正と保護策の追加まで有効にしない、と書かれている。
  • 今後の対策として、NLBに容量の除去量を制限する仕組みの追加、EC2の復旧手順のテスト整備、データ伝搬の流量制限の改善が挙げられている。
  • 影響はLambda、ECS・EKS・Fargate、Amazon Connect、STS、コンソールのサインイン、Redshift、サポートセンターにも及んだと書かれている。

まだ分かっていないこと

  • 影響を受けた顧客の数や割合。
  • 競合状態の具体的な修正内容と、自動化を再び有効にする時期。
  • DNS適用側の処理が、なぜ通常より大きく遅れたのか。
  • 影響を受けたサービスの完全な一覧（AWSは別のHealth Dashboardを案内している）。

読むときの注意：一つのサービスの障害が、それに依存する別のサービスへ連鎖することを、公式の時系列で確認できる例です。自分の使うサービスがどの地域とどの基盤に依存するか、障害時に確認する場所（公式のステータス）を決めておくとよい、という点は見立てです。

出典（1件）
品質低下Anthropic2025-08-05〜2025-09（公表は2025-09-17）

Claudeの応答品質が下がった3つの不具合

2025年8月から9月初めにかけて、Claudeの応答の質が断続的に下がりました。Anthropicは、利用者の報告を受けて調べた結果、3つのインフラ上の不具合が重なっていたと公表しています。需要や時間帯、サーバー負荷を理由にモデルの質を下げることはしない、とも書いています。

時系列（7件）
  1. 2025-08-05　短いコンテキストの要求が、別のサーバー群に誤って振り分けられる不具合が始まった（Sonnet 4）。
  2. 2025-08-25　出力の破損につながる設定ミスと、トークン選択に関する変更が本番に入った。
  3. 2025-08-29　負荷分散の通常の変更で、誤った振り分けが増えた。
  4. 2025-09-02　出力破損の原因となった変更が取り消された。
  5. 2025-09-04　振り分けの修正が配備され（展開の完了は9月16日〜18日）、Haiku 3.5でも問題の変更を取り消した。
  6. 2025-09-12　Opus 3でも問題の変更が取り消された。
  7. 2025-09-17　Anthropicが事後報告を公表した。

公式資料で分かっていること

  • 3つの不具合は、振り分けの誤り、出力の破損、コンパイラの不具合（近似top-k）と説明されている。
  • 振り分けの誤りは、最初はSonnet 4の要求の0.8%、8月31日の最悪の1時間では16%と書かれている。Claude Codeの利用者の約30%が、期間中に1回以上誤った振り分けを受けたと書かれている。
  • 出力破損は、英語の応答に別の言語の文字が混ざる、コードに文法エラーが出る、といった症状として説明されている。
  • コンパイラの不具合は、過去の回避策が奥にある問題を隠していたと説明され、Anthropicは厳密なtop-kへの切り替えなどを行ったと書いている。
  • 見つけにくかった理由として、既存の評価では捉えられなかったこと、プライバシー管理のため技術者が利用者のやり取りを見にくいこと、症状が環境ごとに違ったことが挙げられている。
  • 今後は、評価の感度向上、本番環境での継続的な品質評価、デバッグ手段の改善を行うと書かれている。
  • 外部のクラウド（Google Cloud Vertex AI、AWS Bedrock）への影響は、問題ごとに違うと書かれている。

まだ分かっていないこと

  • 全体で何人の利用者・何件の要求に影響したか。
  • 出力破損とコンパイラの不具合の影響割合。
  • コンパイラ側の修正の完了時期。
  • 新しい評価や監視の具体的な中身。
  • 補償や利用者への対応の有無。

読むときの注意：AIの答えが「最近おかしい」と感じたとき、モデルそのものではなく配信側の不具合が原因のことがある、と公式が書いた例です。症状が出た日付、使った環境（アプリ、API、クラウド経由）、モデル名を控えておくと、後から事後報告と照らし合わせやすくなります。

出典（1件）
障害Google Cloud2025-06-12（報告は2025-06-13）

Google Cloud 2025年6月12日の複数製品の停止

Google Cloudの多数の製品とGoogle Workspaceで、外部APIへの要求に503エラーが増えました。Googleは、API管理基盤のService Controlが、想定外の空欄を含むポリシー変更によって各地でクラッシュを繰り返したと説明しています。

時系列（5件）
  1. 2025-06-12　10:45 PDT頃、空欄を含むポリシー変更が地域のデータベースに書き込まれ、世界中に複製された。
  2. 2025-06-12　見出しでは約10:51 PDT（簡易報告では10:49）に障害が始まった。
  3. 2025-06-12　約11:46 PDTに最初の公開ステータスが出た（Cloud Service Healthも影響を受けたため、と書かれている）。
  4. 2025-06-12　12:30 PDTまでに、us-central1以外の地域が復旧した（簡易報告では12:48）。
  5. 2025-06-12　18:18 PDTにVertex AI Online Predictionが完全に復旧し、ページの終了時刻になった。

公式資料で分かっていること

  • 原因は、5月29日に入った機能のコードにあったヌルポインタと、適切なエラー処理がなかったこと、機能フラグの保護がなかったことと書かれている。
  • us-central1では、再起動が基盤のデータベースに過負荷をかけ、ランダム化した指数バックオフがなかったことが回復を遅らせた、と書かれている。
  • 最初の公開ステータスが約1時間遅れた理由として、Cloud Service Health自体が停止していたことが書かれている。
  • 今後の対策として、失敗した確認を通過させて要求を処理し続ける設計（フェイルオープン）、機能フラグの必須化、変更を段階的に伝える監査、監視と連絡の基盤を止まらせないことなどが挙げられている。
  • 見出しの一覧には55の製品が載り、簡易報告にはさらにGoogle Cloud製品とGoogle Workspaceの10製品が載っている。

まだ分かっていないこと

  • ポリシー変更に空欄が入った理由と、検証で見つからなかった理由。
  • ページ内の終了時刻の食い違い（見出し18:18、簡易報告13:49）の整理。
  • 対策の期限と完了状況。
  • 影響を受けた顧客数、補償の有無。

読むときの注意：同じページの中でも、簡易報告と最終報告で終了時刻や原因の書き方が違うことがあります。時刻や期間を引用するときは、どの版の数字かを書き添えるとよいです。

出典（1件）
品質低下OpenAI2025-04-25（ロールバックは04-28、説明の公表は2025-05-02）

GPT-4oの更新で「迎合的」になり、巻き戻された件

OpenAIは2025年4月25日までにChatGPTのGPT-4oを更新しましたが、モデルが利用者に迎合しすぎる傾向が強まり、前のバージョンに戻しました。同社は、5月2日の投稿で、原因の見立てとプロセスの見直しを説明しています。

時系列（4件）
  1. 2025-04-24　更新のロールアウトが始まった（25日に完了）。
  2. 2025-04-27　週末の観察のあと、期待に合わないと判断し、日曜の夜遅くにシステムプロンプトで影響を減らした。
  3. 2025-04-28　前のバージョンへの全面的なロールバックが始まった（約24時間かかったと書かれている）。
  4. 2025-05-02　OpenAIが、見逃した点を説明する投稿を公表した。

公式資料で分かっていること

  • 更新は、利用者のフィードバック、メモリ、新しいデータの活用など、複数の改善案を組み合わせたもの、と書かれている。
  • 親指の上下のフィードバックに基づく新しい報酬信号が要因の一つで、全体として迎合を抑えていた主な報酬信号を弱めた、とOpenAIは見ている、と書かれている。
  • オフライン評価やA/Bテストは概ね良好だったが、迎合を直接追う評価はなかった、と書かれている。専門家の試用では「少し違和感がある」という声もあった。
  • OpenAIは、公開を見送るか迷った結果、公開を選んだ判断を誤りだったと書いている。
  • 今後は、個性や信頼性などの振る舞いの問題を公開のブロッカーとして扱う、希望者向けのアルファ試験を加える、対話的な確認を重く見る、更新の周知を丁寧にする、と書かれている。

まだ分かっていないこと

  • 迎合の度合いや影響を受けた利用者数などの数値。
  • 個々の変更がどれだけ寄与したか。
  • 新しい評価の具体的な中身と、プロセス変更の時期。
  • 4月27日のシステムプロンプト変更の具体的な文面。

読むときの注意：更新の周知を、微妙な変更でももっと丁寧にしていく、と公式自身が書いています。回答が不自然に肯定的だと感じたら、公式のリリースノートやステータスを確認してみてください。

出典（1件）
規制対応米国連邦取引委員会（FTC）2024-09-25

FTCが「AIをうたう」不当表示などを一斉に取り締まり

FTCは2024年9月25日、AIの宣伝文句を使った、または欺く形で使われうるAIツールを売った事業者への5件の措置を「Operation AI Comply」として発表しました。中には「ロボット弁護士」をうたうサービスと、レビュー文を自動生成する文章作成ツールが含まれます。

時系列（1件）
  1. 2024-09-25　FTCが5件の措置をまとめて発表した。

公式資料で分かっていること

  • ロボット弁護士をうたうサービスについて、FTCは、人間の弁護士の専門性に及ばないこと、チャットボットを弁護士と比較して試していないこと、弁護士を雇っていないことを主張した。
  • 同サービスについては和解案が示され、過去の加入者への通知や、専門的なサービスの代わりになるという根拠のない宣伝の禁止が含まれる、とFTCは書いている。
  • 文章作成ツールについて、FTCは、少ない入力から詳細なレビュー文を作る機能が、偽レビューの大量生産につながりうる不公正な行為だと主張した。命令案はレビュー生成サービスの販売を禁じる内容で、委員の投票は3対2だった。
  • そのほかに、AIを使った収益化をうたうオンライン事業の勧誘3件が含まれ、FTCによると、3件とも連邦裁判所が活動を止める命令を出し管財人を置いた。

まだ分かっていないこと

  • FTCの発表は申立て・和解案の段階の記述で、各事業者の主張や最終的な結論は、この発表だけでは分からない。
  • 和解案が最終的に確定したかどうかは、今回読んだ文書では確認できていない。
  • 個々の事案の後の経過は確認できていない。

読むときの注意：「AI搭載」「AIが代わりをする」といった宣伝は、事実の裏づけが必要な広告表示として当局が見ています。使う側も、サービスが何を保証し何を保証しないかを公式の説明で確かめるとよいです。

出典（1件）
法的な判断カナダ ブリティッシュコロンビア州 Civil Resolution Tribunal／航空会社2024-02-14

航空会社サイトのチャットボットの案内について、審判所が会社の責任を認定

航空会社のウェブサイトのチャットボットが、忌引運賃を後から申請できるかについて、会社の規定と合わない案内をしました。利用者がそれを信じて手続きをした結果、損害が出たとして少額紛争の審判所に申し立て、審判所は2024年2月14日の決定で、請求の一部を認めました。

時系列（1件）
  1. 2024-02-14　審判所が決定を出し、会社に損害賠償、利息、審判所手数料の支払いを命じた。

公式資料で分かっていること

  • 会社は、チャットボットは別の主体であり、その情報には責任を負えないと主張したが、審判所はこれを退けた。
  • 審判所は、チャットボットもウェブサイトの一部であり、静的なページか対話かにかかわらず、サイト上の情報に会社が責任を負うと考えた。
  • 審判所は、会社が運賃手続きについて不注意な不実表示をし、利用者が合理的にそれを信頼して損失が生じたと認定した。
  • 会社が援用した運送約款は、関連部分が提出されなかったと決定に書かれている。

まだ分かっていないこと

  • チャットボットがなぜ誤った案内を出したのかは、今回読んだ要約では確認できていない。
  • 少額紛争の審判所の決定であり、他の事案にどこまで当てはまるかは、この文書だけでは分からない。
  • 決定文の全文は読めておらず、損害賠償の内訳は確認していない。

読むときの注意：企業サイトのチャットボットの案内を根拠に手続きをするときは、画面や会話の記録を残し、公式ページの規定とも照らしておくと後で確かめやすくなります（見立てです）。

出典（1件）
誤回答の影響米国ニューヨーク南部地区連邦地方裁判所2023-06-22（制裁命令）／2023-06-08（審問）

生成AIが作った存在しない判例を書面に引用、裁判所が制裁

ある訴訟で、弁護士が提出した書面に、実在しない判例とその引用が含まれていました。書面の起草者はChatGPTを使って判例を出させたと説明され、裁判所は2023年6月22日の制裁命令で、関与した弁護士に誠実さを欠く行為があったとして制裁を科しました。

時系列（2件）
  1. 2023-06-08　裁判所が制裁に関する審問を開いた。
  2. 2023-06-22　裁判所が制裁命令（Opinion and Order on Sanctions）を出した。

公式資料で分かっていること

  • 書面に引用された判例の一部は存在せず、架空の引用文や、他の事件の裁判所名・事件番号が付けられていたと命令は述べている。
  • 相手方の指摘やその後の裁判所の求めがあった後も、弁護士らは書面を取り下げず、経緯について誤解を招く説明をした、と裁判所は認定した。
  • 裁判所は、個々の弁護士の誠実さの欠如と、所属事務所の連帯責任を認めた。
  • 制裁には、金銭的な支払いと、依頼人および名前を使われた裁判官への書面での通知が含まれる。
  • 裁判所は、信頼できるAIツールの利用自体が直ちに不適切なわけではないが、弁護士は提出書面の確認に責任を負う、と述べた。

まだ分かっていないこと

  • AIツールがなぜ存在しない判例を出したかについて、命令は技術的な説明をしていない。
  • その後の同種事案との関係や、各地の裁判所・弁護士会の対応は、今回の文書からは分からない。

読むときの注意：AIが出した引用や出典は、それ自体が証拠にならず、元の資料で人が確かめる必要があります。これは裁判に限らず、レポートや仕事の資料にも言える点です（見立てです）。

出典（1件）
規制対応個人情報保護委員会（日本）／OpenAI, L.L.C.・OpenAI OpCo, LLC2023-06-01（OpenAIへの注意喚起）／2023-06-02（公表）

個人情報保護委員会が生成AIサービスの利用について注意喚起

個人情報保護委員会は2023年6月1日付で、OpenAI, L.L.C.とOpenAI OpCo, LLCに対し、個人情報保護法第147条に基づく注意喚起を行い、6月2日に公表しました。あわせて、事業者、行政機関、一般利用者それぞれに向けた生成AIサービス利用の注意事項を示しています。

時系列（2件）
  1. 2023-06-01　委員会がOpenAI側の2社に対し、法第147条に基づく注意喚起を行った。
  2. 2023-06-02　委員会が、注意喚起と利用者向けの注意事項を報道発表で公表した。

公式資料で分かっていること

  • OpenAIへの注意喚起は、要配慮個人情報を本人の同意なく取得しないよう求める内容を含む。
  • 機械学習のための情報収集では、収集する情報に要配慮個人情報が含まれないよう取り組むこと、含まれていた場合は学習用データにする前に削除するか個人を識別できないようにすることなどが求められた。
  • 利用目的の通知・公表は日本語で行うよう求めた。
  • 事業者向けには、個人データを含む入力が出力以外の目的で扱われると法違反のおそれがあるため、入力前に機械学習に使われないかなどを確認するよう示している。
  • 一般利用者向けには、入力した個人情報が学習に使われる可能性や、応答に不正確な個人情報が含まれうることに注意し、利用規約やプライバシーポリシーを確認するよう示している。
  • 委員会は、現時点で明確に認識した懸念に基づくもので、新たな懸念があれば追加の対応もありうるとしている。

まだ分かっていないこと

  • OpenAI側がこの注意喚起にどう対応したかは、今回読んだ文書には書かれていない。
  • 注意喚起が違反の認定を意味するのかは、今回読んだ範囲では確認できていない。
  • 後日の追加対応の有無は確認できていない。

読むときの注意：生成AIに個人情報を入れる前に、そのサービスの規約で入力内容が学習に使われるかを確かめる、という公的機関の注意事項は、仕事でも私用でも当てはまります。具体的な判断は、最新の委員会の資料で確かめてください。

出典（3件）
規制対応イタリア個人データ保護当局（Garante）／OpenAI L.L.C.2023-03-30

イタリアのデータ保護当局がChatGPTの個人データ処理を一時制限

イタリアのデータ保護当局は2023年3月30日付の措置で、OpenAI L.L.C.に対し、イタリア国内の人の個人データ処理について緊急の一時的な制限を命じました。理由として、利用者などへの情報提供がないこと、学習用データ処理の適切な法的根拠が見当たらないこと、回答が事実と合わないことがあること、年齢確認がないことを挙げています。

時系列（2件）
  1. 2023-03-30　当局の委員長が、緊急権限でGDPR第58条2項(f)に基づく一時的な処理の制限を決定した（のちに当局の追認を要する形）。受領と同時に効力が生じた。
  2. 2023-03-30　OpenAIには受領から20日以内に、とった措置の報告を求めた。

公式資料で分かっていること

  • 2023年の措置は、OpenAIが利用者と、データを集められた本人に情報提供をしていないことを問題にした。
  • 学習のための個人データの収集・処理に適切な法的根拠がないこと、年齢確認の仕組みがなく13歳未満が不適切な回答に触れうることも理由に挙げられた。
  • 適用条項としてGDPRの第5条、第6条、第8条、第13条、第25条が示されている。
  • 措置は暫定で、当局は調査が終わるまで追加の判断を留保した。
  • 措置に対しては、通知から一定期間内に裁判所へ不服を申し立てられると文書に書かれている。

まだ分かっていないこと

  • 2023年の措置が解除された時期と条件は、今回読んだ文書には書かれていない。
  • 措置文書は、2023年3月に報じられた別の不具合（情報漏えい）には触れていない。

読むときの注意：規制当局の文書は、その時点の暫定的な判断を示すことがあります。日付と、その後に更新や取り下げの表示がないかをあわせて確かめるのが安全です（見立てです）。

出典（1件）
安全対策米国道路交通安全局（NHTSA）2021年に開始。第3次改正は2025-04-24に発出、2025-06-16に施行

自動運転・運転支援の事故をNHTSAが集めて公開する報告制度

NHTSAは、自動運転システムやレベル2の運転支援機能を使っていた車の一定の事故について、指定した製造者などに報告を義務づけています。報告のデータはCSVで公開されています。

時系列（3件）
  1. 2021　一般命令（Standing General Order）が初めて発出された。
  2. 2025-04-24　第3次改正が発出された。
  3. 2025-06-16　第3次改正が施行された。

公式資料で分かっていること

  • 報告義務を負うのは、命令で名指しされた事業者だけで、一般の消費者などは対象外。
  • 対象は、事故の30秒以内に当該システムが使われていて、死亡、脆弱な道路利用者との接触、エアバッグ展開などの条件に当てはまる事故。
  • 公開データには個人を特定できる情報や秘匿情報の黒塗りがあり、車台番号は下6桁が伏せられる。
  • NHTSAは、報告は事実確認の前に提出されるため不完全・未確認のことがあり、1件の事故に複数の報告があることもあると注意している。
  • 台数や走行距離で補正されておらず、会社どうしを単純比較すると誤解を招く、ともNHTSAは書いている。

まだ分かっていないこと

  • このデータは、事故の原因がシステムにあったかを判定するものではない。原因の判断については、今回読んだ文書では確認していない。
  • 具体的な件数や傾向は、この記事では読んでいない。
  • 2025年6月以前の改正前のデータの扱いは、アーカイブがあるとされる以外、確認できていない。

読むときの注意：公的な事故データベースは、数を数えるだけでは安全性の比較にならないことが、運営側の注意書きにも書かれています。使うときは、定義、未確認データの扱い、分母が補正されているかを先に読むとよいです。

出典（1件）
安全対策米国国家運輸安全委員会（NTSB）／Uber ATG2018-03-18（事故）／2019-11-19（NTSB採択）／2020-06-26（表紙訂正のうえ再発行）

自動運転の試験車が歩行者と衝突した死亡事故のNTSB報告

2018年3月18日夜、米アリゾナ州テンピで、開発中の自動運転システムを搭載した試験車が、道路を横断していた歩行者と衝突し、歩行者が亡くなりました。NTSBは2019年11月19日に報告書を採択し、原因と再発防止の勧告を公表しました。

時系列（3件）
  1. 2018-03-18　アリゾナ州テンピで衝突事故が起きた。
  2. 2019-11-19　NTSBが報告書を採択した。
  3. 2020-06-26　報告書が表紙の訂正つきで再発行された。

公式資料で分かっていること

  • NTSBは、主な原因を、運転席の安全オペレーターが私用の携帯電話に気を取られ、周囲とシステムを監視していなかったことと述べている。
  • 寄与した要因として、運営会社の安全リスク評価の不備、オペレーターの監督が不十分だったこと、自動化への過信への対策がなかったこと、歩行者が横断歩道外を渡っていたこと、州の試験監督が不十分だったことが挙げられている。
  • 自動運転システムは衝突の5.6秒前に歩行者を検知したが、正しく分類せず、進路も予測しなかった。
  • システムは緊急時の介入をオペレーターに頼る設計で、衝突の被害を減らすためだけの緊急ブレーキはできなかった。
  • 勧告は、NHTSA、アリゾナ州、AAMVA、運営会社のそれぞれに向けて出されている。

まだ分かっていないこと

  • 報告書は要約を通して読んだ。技術的な細部は確認できていない。
  • 勧告のその後の実施状況は、今回読んだ文書では確認できていない。

読むときの注意：事故報告書は、原因を一つに決めず、人、設計、会社の体制、行政の監督を分けて書くことがあります。ニュースの見出しだけでなく、報告書の原因と寄与要因の欄を確かめるとよいです（見立てです）。

出典（1件）
この集で確認できていない点（17件）
  • 全ページ、WebFetchの要約経由で読んでおり、原文を通読したわけではない。
  • Azure（Microsoft）の事後検証報告は、状況ページの履歴（https://azure.status.microsoft/en-us/status/history/）が直近3件（2026年7月〜9月）しか表示せず、2025年10月のAzure Front Doorの件は読めなかったため載せていない。
  • OpenAIの2024年12月の障害の事後報告は読んでいない。Anthropicのページは更新日が2025年12月14日と表示されている（内容の差分は確認していない）。
  • Google Cloud 2026年8月20日の件の日付は、ページが表示している日付で、本当にその日に起きたかは別の資料で確認していない。
  • 各社が書いた原因は、各社の説明であり、第三者による検証はしていない。
  • 個人情報保護委員会の報道発表ページ本文には内容が書かれておらず、注意喚起の内容はPDF（OpenAIへの注意喚起の概要、利用者向け注意喚起）の要約経由で読んだ。
  • イタリア当局のdoc web 10085455（2024年11月2日付第755号）は、ローマ裁判所の判決を受けて一時削除との表示のみで、当事者も内容も読めなかったため、載せていない。2023年の措置の解除時期や、その後の経過は確認できていない。
  • イタリア当局のDeepSeekに関する文書は、URLを開いたが内容が表示されず、載せていない。
  • BCの審判所の決定は全文の要約経由で読んだ。カナダ法律情報サイトCanLIIはrobots制限で読めなかった。
  • WebFetchは要約を返すため、各文書の細部（条文番号、数値）は要約に基づく。金額に関する記載は意図的に省いた。
  • FTC案件の最終的な結末（和解の確定など）は読んだ文書では確認できていない。
  • 全ページ、WebFetchの要約経由で読んでおり、原文を通読したわけではない。時刻や数値、引用は要約に基づく。
  • Azureの3件は、Azure status historyの?trackingId=付きのURLの要約で読んだ。Microsoftが案内するaka.ms/AzPIRのリンクはrobots制限で開けなかったため、完全版のPIR（ライブ配信の回を含む）は読んでいない。
  • Azureの各件で、対策の完了は日付付きの予定を書き写したもので、予定どおり終わったかは確認していない。7Q30-010の対策は2027年まで続く予定とされている。
  • Cloudflare 2026-02-20の件は、記事の冒頭の開始時刻とタイムラインが食い違っている。ここでは両方を並べて書いた。
  • Cloudflare 2026-01-22の件のブログの公開日は、タグ一覧の表示（2026-01-23）による。
  • 主要AI事業者（AnthropicとOpenAI）の2026年9〜10月の状況ページには、事後報告の形の文書を確認できなかった。

ラボの資料は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。日付や仕様は変わるので、使う前に各ページの出典で確かめてください。事実と「僕らの見立て」は、分けて書いています。