Yandex Cloud の障害ページを開いたら、障害内容ではなく「Are you not a robot?」という確認画面が出ていた。サービスの可用性を知らせるはずの場所で、アクセスした側が bot かどうかを確かめるページに飛ばされるのは、少し妙に見える。だが、こうした表示は単なる見た目の不具合ではなく、アクセス制御や自動送信の判定が前面に出た結果でもある。今回の件は、Yandex が外部からの問い合わせやページ閲覧をどのように扱っているかを、そのまま見せている。
元記事として示されている Yandex Cloud のステータスページには、本来なら障害やメンテナンスの説明が載るはずだが、実際に表示されているのは「Are you not a robot? Please confirm that you are not a robot」という文言だった。続けて、送信元のデバイスからのリクエストが自動化されているように見える、という案内が出る。理由として挙げられているのは、JavaScript が無効になっている場合などだ。
画面には「I’m not a robot」のチェックボックスがあり、押すと追加の確認が行われると書かれている。下には「How to enable JavaScript?」という導線もあり、JavaScript を有効にするよう促している。認証の仕組みとしては Yandex SmartCaptcha が使われており、問題がある場合は feedback form を使ってほしいという案内もある。ページ末尾には 9562760371643850386 : 1791763675 という識別子らしき数字列が表示されている。
つまり今回のページは、障害の原因や影響範囲を説明するレポートではなく、まず人間かどうかを確認するためのゲートになっていた。ステータスページを見に来た人に対して、サービスの状況を返す前に「あなたは bot ではないか」を確かめる構造だ。少なくともこの抜粋から読み取れるのは、Yandex Cloud 側が自動化されたアクセスを強く警戒しており、その判定が一般の閲覧にも影響しているということだ。
この表示を見てまず感じるのは、インフラの説明ページとしてはかなり相性が悪いということだ。障害や遅延が起きた時に見るのは、まさに人が困っている瞬間だろう。その場で CAPTCHA を要求されると、原因を知りたい人がさらに足止めされる。しかも、アクセスしているのは自動監視のスクリプトではなく、ブラウザでページを開いた運用担当者かもしれない。そういうケースまで一律に「自動化されている」と扱うと、情報の届け方としては雑に見える。
もっとも、これは単純な失敗とも言い切れない。ステータスページは外部に公開されているぶん、スクレイピングや過剰なポーリングの対象になりやすい。公開状況を人間向けに保ちたい、あるいは攻撃や濫用を減らしたい、という事情は十分ありそうだ。SmartCaptcha を前面に置くのは、その防波堤としては分かる。ただ、障害時に真っ先に守るべきものが「アクセスの正当性」なのか「情報の即時性」なのかは、運用哲学がはっきり出るところだと思う。
画面には JavaScript が無効だとこうなる、という説明がある。ここで面白いのは、単に「動かない環境がある」と案内しているだけではなく、JavaScript の有無そのものを判定材料にしている点だ。昔なら、ステータスページは軽い HTML だけで誰でも見られるのが当然だった。だが今は、ブラウザが本当に人間の操作をしているかを判断するために、JavaScript がかなり重要な役目を持つ。つまり、表示のための技術が、そのまま信頼性の判定材料に変わっている。
これは便利でもあるが、同時に排除も生む。たとえばセキュリティの都合でスクリプトを切っている環境、古い端末、特殊なブラウザ、企業の厳しい設定下では、こうした確認に引っかかりやすい。障害情報は本来、接続が重い時や環境が不安定な時ほど見たいものだ。それなのに、閲覧条件を増やしてしまうのは逆説的だ。Yandex 側からすれば bot 対策として合理的でも、利用者側から見ると「知りたい時ほど届きにくい」設計に見えてしまう。
ステータスページは、普段は裏方のシステムが表に出る場所だ。障害がある時には、何が壊れたのか、どこまで影響があるのか、復旧見込みはどうかを短く明確に出すだけで価値がある。そこに CAPTCHA を挟むと、単なる防御策以上に「この会社は外部からのアクセスをかなり厳しく見る」という印象を残す。実務上は小さな差でも、ユーザーの受け取り方は大きく変わるはずだ。
私は、こうした判断はセキュリティと可用性の天秤の置き方として興味深いと思う。bot を減らしたい気持ちは分かるし、問い合わせ窓口やステータスの見せ方を守りたい意図も理解できる。ただ、障害情報は信頼を支える最後の窓口でもある。そこが「まず証明してから読め」と言ってくると、情報公開より先に防御が来る会社だという印象が残る。クラウド事業者にとって、その印象は軽くない。技術的には正しくても、運用として親切かどうかは別問題だ。
画面下部の 9562760371643850386 : 1791763675 は、利用者向けの説明というより内部識別子に近い。こういう数字列がそのまま見えると、サービスが人間向けの案内文だけでなく、機械処理やログ追跡を強く意識して作られていることが分かる。ユーザーにとっては意味のない文字列でも、運用側にはトラブルの切り分けに使えるのだろう。
ただ、そのまま露出すると少し冷たい印象もある。障害ページは、事情を共有する場でもある。そこに内部向けの痕跡が残ると、読み手は「まだ途中なのか」「裏側の仕組みがそのまま漏れているのか」と感じやすい。私は、こうした表示は完全に悪いとは思わないが、対外的な説明文としてはもう少し整えた方がよいのではないかとも思う。利用者が見たいのは識別子ではなく、いま何が起きていて、いつ頃戻りそうかだからだ。
参考: Yandex
