HTML ファーストで公営企業のウェブサイトを倍増させる物語：Astro とバリデーションの真実

課題と背景

ユーティリティ（公営）企業が抱えていた深刻な問題とは、以下のような状況でした。

• 非効率なプロセス: サービス申し立て時に古い ASP 形式を使用したり、手作業による処理を行わざるを得なかった。
  • これにより企業としての経費が莫大にかかる。
• 規制とリスク: 規制下の独占企業であり、顧客満足度が 96% を下回ると数百万ポンドの罰金に直面する可能性があった。

従来のアプローチの失敗

問題解決に向けた過去の試みはすべて失敗に終わり、以下のような致命的な欠陥がありました。

• 高コスト・低品質: 莫大な予算を要したにもかかわらず成果が得られなかった。
• React アプリケーションの失敗事例:
  • 他国へコンプライアンス契約者を選任して開発したが、公開直後（3 日後）に顧客苦情によりサービス停止に追い込まれた。
• 致命的な技術的負債:
  • ロード­ingスピナーやグローバルな JavaScript ステートによる混乱。
  • アクセシビリティの未確保。
  • 画像アップロードなど重要な機能において、

    localStorage

    (上限5MB)にデータを格納しようとしていた（容量不足のリスク）。

解決策：Astro を用いた「HTML ファースト」アプローチ

私は大胆な決断を下し、Astroを使用してサイトの再構築を行いました。その哲学は「HTML ファースト」です。

• JavaScript も利用するが、あくまで ウェブコンポーネントとして実装。
• 本来 HTML で十分動作するサイトを基盤とし、そこにプログレシブエンハンスメントを施すのみ。

構築目標

私の論理に基づき、以下の要件を満たすことを最優先しました。

• 公共サービスとしての在り方。
• 可能な限りあらゆるデバイスでの動作。
• 悪劣なネットワーク環境下でもの動作。
• ユーザーが入力したデータの 一切の損失を回避する。

動機：実体験から得た教訓

政策調査官 Terence Eden 氏のエピソードに深く動かされました。

• 状況: ロンドンの住宅給付事務所。家庭内暴力からの救助者へのポスターや緊迫した空気の中、若い女性が固い椅子に座り PSP で『Candy Crush』をしていたように見えたが、実際は補完的な Wi-Fi で GOV.UK のページ（HTML 製） を閲覧し、自己防衛していた。
• 課題: PSP ブラウザは動作が遅く、メモリ不足を起こしやすく、タブ制限がある。しかし GOV.UK ページのような軽量な HTML は劣悪環境でも動作する。

必要とされる要件

これらから導き出した具体的な要件は以下の通りです。

• フォーム各セッションに 固有の ID を割り当てる。
• ウィザードのステップごとに提出されたデータ（画像含む）を バックエンドに即座に保存する。
• JavaScript なしでもフォームを完了できること。
• 古くさいブラウザや劣悪な環境下での動作保証。
• WCAG 準拠のアクセシビリティ（チームは AA レベルで合意）。
• UX 向上のため、必要最小限の JavaScript とモダンな CSS を使用する。

リダイレクト戦略による軽量化

フォームウィザードを独立したページとして実装し、ユーザーが「次へ」をクリックすると API 検証後にリダイレクトする手法を採用しました（Remix パターン）。

• 理由: リアルタイムデータ提示ではない単なるフォームに、20MB の JavaScript を配信するのは馬鹿げた行為。
  • 例: テスコで購入した 10 年前の Android フォンを使っているユーザーがいる場合、重厚なクライアントアプリは提供できない。

バリデーションの実装：HTML ウェブコンポーネント

React のバリデーションライブラリで人月単位を浪費する現状に対し、私は HTML のウェブコンポーネントを開発しました。

• 既存の HTML を取り囲むカスタム要素として機能し、生命あるものに変える。
• シャドウ DOM を使用せず、JavaScript によるレンダリングは最小限に抑える。

実装のポイント

• 標準的な HTML フォームを監視し、バリデーション情報を検知して現代的なデザインに変更する。
• 標準のバリデーションポップアップを抑制し、エラーメッセージを

  aria-describedby

  （推奨：

  aria-errormessage

  ）に配置。
• 入力中の即時検証: ユーザーが入力を正しく修正するとエラーが消える。
• 再検証: フォーカス外れた時および提出時に再度検証を行う。

堅牢なフェイルオーバー戦略

これこそがフォームに必要な UX で、1KB 以下のサイズで実現されました。

1. まずアプリ側で検証する。
2. 失敗した場合はブラウザ標準のバリデーションにフォールバック。
3. それでもダメならバックエンド API が最終検証を行う。

• これにより、ユーザーに早期フィードバックを提供しつつ、常に受容可能な経験を提供できる。

validation-enhancer

の開発とコード

私はこの技術を実用化し、一般用途向けのライブラリ **

validation-enhancer

極めてシンプルなコードで動作します：

<validation-enhancer>
  <form>
    <label for="my-email">Email</label>
    <input type="email" name="my-email" aria-errormessage="my-email-error" required />
    <div id="my-email-error"></div>
    
    <button type="submit">Submit</button>
  </form>
</validation-enhancer>

結果と学び

シグニフィカントな成果

• ユーザー数の倍増: ローンチ時、フォーム完了者の数が 2 倍になりました。分析担当者は「ユーザーがどこから来たのか」さえ把握できていないほどだった。
  • 注記: JavaScript ベースの分析ツールでは、JavaScript エラーでリダイレクトされたユーザーは検出されず、大量の見逃しが発生した。
• データ安全性の確認: 「バックエンドセッション保持」アプローチの実証により、1 ヵ月前に開始したフォームを完了させるなど、データ損失ゼロが達成された。

悲しいエピローグと業界への提言

契約終了後、同僚の反応は以下のようなものでした。

• 「それでも JavaScript なしで常に動作するのか？」（驚き）
• 「作業が増えるから嫌だ」（不満）

古くさいブラウザやネットワーク接続が悪そうなユーザー、あるいは支援技術利用者をリダイレクトさせる現状を決して許容できません。

• 特に独占公共サービスにおいては責任重大です。
• ソフトウェア業界の「無法地帯（cowboy phase）」は終焉すべきであり、成熟した産業としての責務を果たす必要があります。

結論

PlayStation Portable のようなデバイス上で 3G ネットワークを通じて動作する Web アプリケーションを構築してください。

• もしそれが成功すれば、それは すべてのユーザーにとって機能します。
• さらに 30 年後もまだ機能し続けるでしょう。