【HTTP 431】フォームが送信できない！Cookie肥大化で起きる「サイレント障害」とアクセシブルなエラー対応

Webサービスを利用中に、「画面には何のエラーも出ていないのに、ボタンを押しても次のページに進めない」という謎の不具合に遭遇したことはないでしょうか？

デベロッパーツールを開いて初めて、ネットワークタブにひっそりと浮かび上がる HTTP 431 Request Header Fields Too Large の文字。

今回は、外部マーケティングツール連携で実際に遭遇した生々しいトラブル事例をベースに、なぜこのエラーが発生し、どのようにユーザーの閲覧体験を脅かすのか、そしてフロントエンドとしてどう対処すべきかを解説します。

本記事は実際のトラブル事例をベースに再現・構成しています。
HTTP 431の原因はCookie肥大化に限らず、環境やリクエストヘッダー全体の構成によって異なります。

実体験：「ボタンを押しても進まない」サイレント障害

以前、あるSaaSサービスのフォーム周りを実装していた際、「フォームの送信ボタンを押してもサンクスページに遷移しない」 という不具合が発生しました。

画面上はレイアウト崩れもなく、ローディング表示が消えたあともエラーメッセージひとつ出ません。ユーザーからすると「自分のクリックが浅かったのか？」「サーバーが重いのか？」すら分からず、操作が完全に詰んでしまう状態です。

原因：外部ツール連携に伴うCookieの肥大化

原因を探ると、外部のマーケティングオートメーション（MA）ツールへデータを引き渡すため、フォームの入力データや行動ログをCookieに保持する実装になっていました。

ユーザーが入力や回遊を重ねるうちにCookieのサイズがチリツモで肥大化。最終的に、利用しているインフラ環境のヘッダーサイズ制限（環境によって8KBや16KB前後の閾値が存在します）を突破し、フォーム送信の非同期リクエスト（fetch / axios）が HTTP 431 で弾かれていたのです。

なぜHTTP 431の放置がアクセシビリティの阻害要因になるのか？

HTTP 431自体は「ヘッダーサイズオーバーでリクエストを拒否した」という純粋なサーバー側のレスポンスコードです。しかし、これが非同期通信（AJAX / fetch）で発生した際、フロントエンドで適切に処理されていないと深刻な閲覧障害を引き起こします。

1. エラーが可視化されない「サイレント障害」

fetch などのAPI通信で431が返ってきた際、JavaScript側でエラーをキャッチしてUIに反映しない限り、画面上は「完全な無反応」 になります。ユーザーは何が起きたのか、次にどうすればいいのかを把握する術がありません。
これは、Web Content Accessibility Guidelines（WCAG）が掲げる「操作可能」「理解可能」という原則を真っ向から阻害します。

2. ユーザー側で復旧できない

「シークレットモードで開く」「Cookieをクリアする」といった回避策は、エラーが発生していることすら分からないユーザーには不可能です。

結果として、「特定のユーザーのアクセス権やCV（コンバージョン）機会を無言で奪う」 という最悪の体験を作ってしまうのです。

なぜヘッダー（Cookie）は肥大化するのか？

今回の事例に限らず、Web開発においてヘッダー（特にCookie）が肥大化する主な要因には以下のようなものがあります。

1. 外部ツール導入に伴うCookieの蓄積
   • 計測や連携用に発行されるCookieが、ユーザーの行動に伴って増殖・長大化する
2. 親ドメイン指定による影響範囲の拡大
   • 親ドメインで発行されたCookieは、サブドメイン（app.example.com 等）への全リクエストにも合算して送信されるため、意図せず上限へ達しやすくなる
3. 状態データの詰め込みすぎ
   • 毎リクエストでサーバーへ送信する必要のない一時データまでCookieに持たせてしまう設計

フロントエンドエンジニアが取るべきアプローチ

HTTP 431はインフラ・バックエンド・タグ管理など複合的な要素が絡む問題ですが、「画面上で沈黙させず、ユーザーを復旧へ導くUIを作る」 のはフロントエンド側の重要な責務です。

対策1：データの保持先と設計の見直し

サーバーへ毎リクエスト送信する必要がないデータ（UIの一時的な状態保持など）は、要件に応じて localStorage や sessionStorage などの Web Storage の利用を検討します。

ただし、認証トークンや個人情報などを安易に localStorage へ移行するのはXSSリスク等の観点から危険です。サーバー側で保持すべきデータかどうかも含めた設計判断が不可欠です。

対策2：不要なCookieのピンポイント消去

不要になった古いCookieは、サーバーレスポンス時に Max-Age=0 を指定して消去します。
すべてのCookieを削除したり、ユーザーに「すべてのCookieを削除してください」と案内するのはログインセッションも切れてしまうため、最終手段と捉えるべきです。

/* 古い不要なCookieをピンポイントで消去するヘッダー例 */
Set-Cookie: _old_ma_data=; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Path=/; Domain=example.com

対策3：非同期通信のエラーハンドリングとアクセシブルな通知

万が一431が発生した場合でも、沈黙させずにユーザーへ状況と次のアクションを伝える画面フィードバックを実装します。

開発者ツールに console.error を吐くだけでなく、role="alert" などを活用して支援技術（スクリーンリーダー）利用者にも確実にエラーを通知します。

HTML側の記述例

動的に出現するエラー領域にはrole="alert"を付与します。これにより、要素が表示された瞬間にスクリーンリーダーへ割り込み通知され、視覚障害を持つユーザーにもエラーの発生が即座に伝わります。

<!-- 最初は hidden で隠しておくエラー領域 -->
<div
    id="error-banner" 
    role="alert" 
    tabindex="-1" 
    hidden
    class="error-message"
>
    <h2>送信を完了できませんでした</h2>
    <p>通信データの影響により処理を完了できませんでした。お手数ですが、一度ページの再読み込みをお試しください。</p>
</div>

JavaScript（fetch）の実装例

async function submitForm(data) {
    const errorBanner = document.getElementById('error-banner');

    try {
        const response = await fetch('/api/submit', {
            method: 'POST',
            body: JSON.stringify(data),
        });

        if (!response.ok) {
            throw new Error(`HTTP_ERROR_${response.status}`);
        }

        // 成功時の処理（完了画面への遷移など）
        console.log('SUCCESS!');
    } catch (error) {
        // サイレント障害にせず、ユーザーに視覚・音声の両方で通知する
        errorBanner.hidden = false;

        // 必要に応じてエラー領域へフォーカスを誘導
        // ※ユーザーの文脈を考慮したフォーカス設計が必要
        errorBanner.focus();

        // 開発者・運用側が追跡できるようログを残す
        console.error(`Submit Failed: ${error}`);
  }
}

まとめ

HTTP 431は、Cookie設計、サードパーティタグ、WebサーバーやCDNの設定など、アプリケーションの複数レイヤーにまたがる問題です。

システム全体でヘッダーの肥大化を防ぐ設計は大前提としつつも、通信エラーが起きた際に 「ユーザーを無反応で取り残さないUI」 を構築することは、フロントエンドエンジニアの大切な責務です。

予期せぬ通信エラーが発生した際、どうアクセシブルに復旧へ誘導するか。ユーザーの閲覧体験を損なわないための「堅牢なUI」を意識していきましょう。