【ITニュース解説】Your Template Set the Title. Something Else Decided What Shipped.

Webサイト開発では、私たちが書いたコードが期待通りに動いているか、テストで確認することが非常に重要だ。しかし、今回のニュース記事は、内部で「完璧だ」と思い込んでいたWebページが、実は外部から見ると深刻な問題を抱えていたという、衝撃的な事例を紹介している。しかもその問題は、システム内部のあらゆるチェックでは一切検出されなかった、というやっかいなものだった。

あるWebサイトで、検索エンジンの結果に表示されるページのタイトルが期待通りに表示されず、クリック率が極端に低くなる事態が発生した。このページは検索結果で毎月約1,580回表示されながら、クリック数はわずか1回だった。これは、通常期待されるクリック率から見て明らかに異常な数値である。しかし、この異常はシステム内部からは全く見えなかった。Webサーバーはページを正常に返し、HTML記述も正しく、開発者が書いたテストはすべて合格していた。ページのメイン見出しである<h1>タグの内容も意図通りだった。唯一の問題は、ブラウザのタブや検索結果に表示される重要な要素である<title>タグの中身だったのだ。

開発チームは、ページのタイトル文字列を一つ作成し、メイン見出し（<h1>）、SNS共有時のタイトル（Open Graph title）、そしてブラウザのタブや検索結果に表示される<title>タグの三か所に渡して使っていた。しかし、実際に生成されたHTMLを確認すると、<h1>とOpen Graph titleは意図通りの完全な文字列だったのに対し、<title>タグだけは途中で短く切り詰められていたのだ。例えば、「TypeError: Failed to Fetch - What It Means and How to Find the Cause」というタイトルが、<title>タグでは「TypeError: Failed to Fetch - What It Means and How to Find」と、「the Cause」という最も重要な部分が欠落していた。この切り詰めは、Webサイトの表示を最適化するため、タイトル要素を文字数制限に合わせて短くする処理が、HTML出力直前で行われていたことが原因だ。しかし、この処理が行われることが、タイトルを渡す側のコードからは全くわからず、他の二つの出力には影響しなかったため、開発者は現象に気づかなかった。結果として、重要な情報が欠落したタイトルが検索結果に表示され、ユーザーがクリックする意欲を失わせていたのである。

なぜこのような問題がテストで検出されなかったのだろうか。それは、開発者が書いたテストが、実際にユーザーに見える最終的な「出力」ではなく、アプリケーションの内部で設定された「値」」を検証していたためだ。Webアプリケーションでは、データが複数の処理層を通過し、最終的にHTMLとしてWebブラウザに送られる。開発チームのテストは、より上位の層で、正しい文字列が設定されていることを確認していたが、文字列が切り詰められる処理は、HTMLを生成し、Webブラウザに送信される直前の、テストの検証対象よりも「低い層」で発生していたのだ。そのため、テストはすべて合格し、開発者は問題がないと信じ込んでいた。この問題から得られる重要な教訓は、アプリケーションの外部に影響を与える出力（検索結果、メール、SNSカードなど）に対しては、設定された「意図」だけでなく、実際に「出力されたバイト列」（Webサイトの場合はレスポンスボディ）を検証するテストが必要だということだ。具体的には、Webサーバーから返されるHTMLの完全な内容（レスポンスボディ）を取得し、それを解析ツールで解析して、<title>タグの中身を抽出し、期待通りの文字列と完全に一致するかを検証するテストが求められる。

この種の問題が厄介なのは、それがシステム内部で何のエラーも発生させない点にある。通常、バグが発生すれば、エラーメッセージが表示されたり、ログに記録されたり、システムが異常終了したり、監視ツールがアラートを発したりするものだ。しかし、この問題の場合、Webページは正常に配信され、システムは意図した通りに機能していると判断される。監視ツールも、Webページが正しく「提供された」ことを測定するだけで、その内容がユーザーにとって「適切であるか」までは判断できない。そのため、すべてのシステム的な信号は「問題なし」と伝え続けるのだ。この問題の唯一の証拠は、システムの外側にしか存在しない。それは、検索エンジンの分析ツールに表示されるクリック率のデータなど、誰かが意識的に調べなければ見つからない情報である。今回の事例では、数週間後に実行されたデータ分析ジョブによって、ようやくこの異常なクリック率が発見された。つまり、問題発生から解決までに、膨大な時間がかかる可能性があるのだ。

システムが内部から観察できない失敗は、エラーを吐き出すような顕在的な問題よりも、実は深刻な場合がある。なぜなら、このような「見えない問題」は、外部の誰かが気づいて報告してくれない限り、私たちはその存在を知ることさえできないからだ。多くのユーザーは、Webページが途中で壊れていたり、画像が表示されなかったりしても、わざわざ開発者に報告することなく、ただページを閉じたり、別のサイトへ移動したりするだけだ。これにより、私たちは顧客を失っていることにも気づかない。今回のタイトル切り詰め問題のように、数字に残るわずかな手がかりが残される場合はまだ幸運な方かもしれないが、何も痕跡を残さず、ただユーザーが離れていくだけのケースも非常に多い。この教訓は、システム開発において非常に重要である。私たちは、自分たちの書いたコードが内部で正しく動作しているかだけでなく、それが最終的にユーザーにどのように見えるか、そして外部のサービス（検索エンジン、SNSなど）にどのように解釈されるかまでを考慮し、検証する視点を持つ必要がある。内部的な「意図」の正しさだけでなく、最終的な「結果」の正しさを確認するテストと、外部からのフィードバックを積極的に収集する仕組みこそが、ユーザーに価値を届け続けるための鍵となる。