AIに仕事を預けた日に、AIが止まる。19項目が同時に赤くなった2時間の記録

まず初めに

AIに仕事を任せる、という話をするとき、我々はたいてい「AIが間違えたらどうするか」を心配する。だが現実に起きたのは、もっと素朴な事故だった。AIが、いない。

賢さの議論の前に、そこに居るかどうかという問題がある。優秀な同僚も、出社しなければゼロだ。9月3日のおよそ2時間、19の項目が同時に不調になった。頼りにしていた側からすれば、突然オフィスが空になったようなものである。

もっとも、止まらないシステムなど存在しない。大事なのは、止まった日に自分が何もできなくなるかどうかだ。※個人の感想です

何が記録されたのか

OpenAIは、自社サービスの稼働状況を公開するステータスページを運用しています。障害や性能劣化が発生した際は、そこにインシデントとして記録し、経過を更新していく仕組みです。

9月3日に記録されたインシデントの名称は「Elevated errors across ChatGPT and Codex」でした。エラーの増加を意味します。影響を受けた項目として、ChatGPTのグループで15、Codexのグループで4、合計19が挙げられています。

経過は三段階で記録されています。まず調査の開始、次に緩和策の適用と復旧の監視、そして解決です。記録された時刻の差から見ると、調査開始から緩和策の適用までがおよそ34分、解決までがおよそ2時間12分です。

解決の記録には、補足があります。Codexのリモート操作機能を使っていた一部の利用者について、モバイル端末の再ペアリングが必要になる場合がある、というものです。障害そのものは復旧しても、利用者側で一手間が残るという形です。

「劣化」と「停止」は同じではない

ステータスページに記載される状態には、いくつかの段階があります。完全に使えなくなる停止と、遅くなったり一部の操作が失敗したりする劣化は、区別されます。

今回のインシデントは、エラーの増加として記録されています。利用者から見れば、送った要求が失敗して再送が必要になったり、応答が返るまでの時間が延びたりする状態です。ずっと画面が真っ白になるのとは異なります。

この違いは、実務上は厄介な面もあります。完全に止まっていれば、誰でもすぐに気づいて別の手段に切り替えられます。断続的に失敗する状態は、自分の設定の問題なのか、通信の問題なのか、サービス側の問題なのかが判断しにくいためです。

作業中に不審な挙動が続いたときは、まずサービス提供元のステータスページを確認するのが早道です。OpenAIの場合、ステータスページのアドレスは公開されており、過去のインシデントの記録も残ります。

原因について、公表されていること

今回の記録において、OpenAIはエラー増加の原因を、サイバー攻撃、情報漏えい、基盤設備の障害、外部サービスへの依存の問題といった特定の要因に結び付ける説明を行っていません。

ここは慎重に読む必要があります。「攻撃ではないと発表された」のではなく、「原因を特定の要因に帰する説明が示されていない」という状態です。障害の記録は、まず復旧を優先して簡潔に書かれることが多く、詳細な原因分析は別途行われる場合もあれば、公開されない場合もあります。

利用者としてできることは、憶測で原因を語ることではなく、記録に残っている事実を押さえておくことです。日時、影響範囲、所要時間、そして復旧後に必要になった作業。この四つが分かっていれば、次に同種の事象が起きたときの備えを考える材料になります。

IT Postの見方――止まる前提で組むかどうかが、実力の差になる

IT Postでは、この2時間から学べることは「OpenAIが不安定だ」ではなく、「どこに依存しているかを把握しているか」だと考える。

そもそも、止まらないサービスは無い。自社で運用するサーバーだって止まる。電気も止まる。問題は、止まった瞬間に何が連鎖して止まるかを、事前に把握しているかどうかだ。今回のインシデントで劣化した項目は19。この数字が示しているのは障害の大きさだけではなく、ひとつのサービスの下にどれだけの機能がぶら下がっているか、という構造でもある。

そして、いま企業が導入しているAI活用の多くは、この構造の上に乗っている。文書の要約も、問い合わせの下書きも、コードの生成も、同じ蛇口から出ている。蛇口をひとつにまとめると便利だが、その蛇口が閉じた日には全部が止まる。便利さと脆さは、たいてい同じ設計から生まれる。

さらに厄介なのが、AIエージェントと呼ばれる仕組みだ。人間が一つずつ指示を出すのではなく、AIが手順を組み立てて連続で作業する。途中でサービスが不調になると、どこまで進んだのかが分かりにくい。今回、リモート操作の再ペアリングが必要になった利用者がいたのも、こうした「つながり続けること」を前提にした機能ならではの後始末と言える。

日本の読者にとって、何をしておけばよいか

大がかりな備えは要らない。三つだけ決めておけば足りる。

第一に、使っているサービスのステータスページの場所を控えておく。作業が止まったとき、自分の設定を疑って30分溶かすか、5秒で外部要因だと分かるかの差は大きい。

第二に、止まったときの代替手順を一行でいいので決めておく。AIに要約させていた作業を、その日は自分で読む。生成に頼っていた下書きを、雛形から書く。完璧な代替でなくていい。「今日はここまでにする」という判断も立派な代替手順だ。

第三に、AIに連続作業をさせる使い方をしている場合、途中で止まったときに何が中途半端に残るかを一度確かめておく。ファイルが半分書き換わった状態、送信済みと未送信が混ざった状態。復旧してから困るのは、たいていこの手の残骸である。

よくある疑問

Q. 私のデータが漏れた可能性はありますか。 今回の記録は、エラーの増加という稼働上の事象として記載されています。OpenAIは、この事象を情報漏えいによるものとして説明していません。

Q. なぜ再ペアリングが必要になったのですか。 記録には、Codexのリモート操作の利用者について、解決後にモバイル端末の再ペアリングが必要になる場合があると記されています。理由の詳細は記録されていません。

Q. 同じことがまた起きますか。 どのサービスでも、障害が二度と起きないという保証はありません。頻度を心配するより、起きた日に自分の作業が何分止まるかを把握しておくほうが実用的です。

賢いAIを選ぶ話は毎日どこかで行われている。だが、そのAIが今日いなかったらどうするかを決めている職場は、まだ多くない。9月3日の2時間は、その質問を出しただけでも役に立つ記録だ。