B-074（モバイル戻るボタンで検索モーダル閉じ）について調査してください。

調査内容

1. 検索モーダルの開閉制御の現在の実装を特定（状態管理、開閉トリガー）
2. history API（pushState/popState）を使ったモーダル制御のベストプラクティス
3. Next.js App Routerとhistory APIの互換性・注意点
4. 他のモーダル（もしあれば）での同様の実装の有無
5. SSR環境でのwindow/history参照の安全性

出力

• 関連ファイルのパスと重要な行番号
• 現在のモーダル開閉制御の概要
• 推奨する実装アプローチ（pushState/popStateの使い方、cleanup処理）
• Next.js固有の注意点・リスク

B-074 調査レポート: モバイル戻るボタンで検索モーダル閉じの実装方法

1. 検索モーダルの現在の実装

状態管理

検索モーダルの開閉状態は SearchTrigger コンポーネント (src/components/search/SearchTrigger.tsx) 内で useState により管理されている。

• 状態: const [isOpen, setIsOpen] = useState(false); (48行目)
• 開く: const openModal = useCallback(() => setIsOpen(true), []); (52行目)
• 閉じる: const closeModal = useCallback(() => setIsOpen(false), []); (53行目)

開閉トリガー

トリガー	開く	閉じる
検索ボタンクリック	openModal (71行目onClick)	-
Cmd+K / Ctrl+K	setIsOpen toggle (57-65行目)	setIsOpen toggle
ESCキー	-	handleClose (64行目, SearchModal.tsx)
オーバーレイクリック	-	handleClose (116行目, SearchModal.tsx)
検索結果選択 (Enter)	-	handleClose (82行目, SearchModal.tsx)
戻るボタン	未対応	未対応

SearchModal (src/components/search/SearchModal.tsx)

• propsとして isOpen: boolean と onClose: () => void を受け取る (13-16行目)
• handleClose 内部で clearSearch() と onClose() を呼ぶ (36-40行目)
• isOpen 時に document.body.style.overflow = "hidden" でスクロールロック (49-59行目)
• モバイルでは全画面表示になる (SearchModal.module.css 26-38行目: width: 100%; height: 100dvh;)
• createPortal経由でdocument.bodyにレンダリング (SearchTrigger.tsx 81-85行目)

関連ファイル一覧

• src/components/search/SearchTrigger.tsx - 状態管理・モーダルマウント
• src/components/search/SearchModal.tsx - モーダルUI・キーボード制御
• src/components/search/SearchModal.module.css - モーダルスタイル
• src/components/search/__tests__/SearchModal.test.tsx - テスト
• src/components/common/Header.tsx - SearchTriggerの配置 (34行目)

2. 他のモーダルでの実装状況

プロジェクト内には4つのゲーム（kanji-kanaru, yoji-kimeru, nakamawake, irodori）に各3つのモーダル（HowToPlayModal, ResultModal, StatsModal）が存在する。いずれもネイティブ <dialog> 要素を使用しているが、history APIによる戻るボタン制御はどのモーダルにも実装されていない。

また、MobileNav (src/components/common/MobileNav.tsx) もモーダル的なUIだが、同様にhistory APIは未使用。

3. history APIを使ったモーダル制御のベストプラクティス

基本パターン

モーダルを開くときにhistory stackにエントリを追加し、戻るボタンでpopstateイベントを検知してモーダルを閉じる。

// モーダルを開くとき
window.history.pushState({ modalOpen: true }, '');

// popstateイベントを監視
window.addEventListener('popstate', (e) => {
  // 戻るボタンが押された → モーダルを閉じる
  closeModal();
});

重要な注意点

1. pushState自体はpopstateイベントを発火しない: popstateはブラウザの戻る/進むボタンによるナビゲーション時のみ発火する
2. モーダルが閉じられたとき（戻るボタン以外で）にhistoryエントリを戻す必要がある: ESCキーやオーバーレイクリックで閉じた場合、pushStateで追加したエントリが残ってしまうため history.back() を呼ぶ必要がある
3. cleanup処理が必須: useEffectのreturnでイベントリスナーを確実に除去する
4. 二重pushState防止: モーダルが既に開いている状態で再度pushStateしないようガードが必要

4. Next.js App Routerとhistory APIの互換性・注意点

Next.js公式ドキュメント（Next.js 16対応確認済み）

Next.js公式ドキュメントでは、window.history.pushState と window.history.replaceState はApp Routerと統合されており、usePathname と useSearchParams と同期すると明記されている。URLのクエリパラメータ変更を伴うpushStateの使用は公式にサポートされている。

既知の問題と対策

問題	影響	対策
Next.jsがpopstateイベントを消費する場合がある	バックボタンでpopstateリスナーが呼ばれない可能性	Next.js 16ではwindowHistorySupportがデフォルトで有効化されており、問題は大幅に緩和されている
history.stateにNext.js内部構造が格納される	カスタムstateが上書きされる可能性	stateオブジェクトに依存せず、URLパラメータで状態を管理するか、stateの有無ではなくpopstateイベント発火自体をトリガーとして使う
beforePopStateがApp Routerで利用不可	Pages Router専用APIのため使えない	popstateイベントリスナーを直接使用する

現在のnext.config.ts

const nextConfig: NextConfig = {
  /* config options here */
};

特に experimental オプションは設定されていない。Next.js 16.1.6を使用中であり、windowHistorySupportは既にデフォルト動作に組み込まれている。

SSR環境でのwindow/history参照の安全性

SearchTriggerは "use client" ディレクティブを使用しており、useSyncExternalStore で mounted フラグを管理している。SearchModalはcreatePortalでマウントされるため、SSR時にwindowやhistoryにアクセスする問題は発生しない。ただし、追加のhistory操作は念のため typeof window !== 'undefined' ガードをつけるか、useEffect内に限定して実行するのが安全。

5. 推奨する実装アプローチ

アプローチA（推奨）: SearchTrigger内でpushState/popState管理

SearchTriggerが isOpen の状態を管理しているため、ここにhistory連携を追加するのが最もシンプルで影響範囲が小さい。

// SearchTrigger.tsx に追加するロジック概要

export default function SearchTrigger() {
  const [isOpen, setIsOpen] = useState(false);
  // ... 既存コード ...

  // モーダル開閉に連動してhistoryを操作
  useEffect(() => {
    if (!isOpen) return;

    // モーダルが開いたとき、historyにエントリを追加
    window.history.pushState({ searchModalOpen: true }, '');

    const handlePopState = () => {
      // 戻るボタンが押された → モーダルを閉じる
      // ここではsetIsOpenのみ呼ぶ（history.back()は不要、既にpopStateで戻っている）
      setIsOpen(false);
    };

    window.addEventListener('popstate', handlePopState);

    return () => {
      window.removeEventListener('popstate', handlePopState);
    };
  }, [isOpen]);

  // closeModalを修正: ESC/オーバーレイ経由で閉じた場合はhistory.back()で
  // pushStateしたエントリを除去する
  const closeModal = useCallback(() => {
    // isOpenがtrueの場合のみhistory.back()を呼ぶ
    // (popState経由で閉じた場合は既に戻っているので不要)
    setIsOpen(false);
  }, []);

  // ... 以下、openModal/closeModal間でhistory整合性を保つ工夫が必要 ...
}

二重呼び出し防止の実装詳細

popstate 経由で閉じた場合と、ESC/オーバーレイ経由で閉じた場合を区別する必要がある。推奨パターンはフラグ（ref）を使って制御する方法。

const closedByPopStateRef = useRef(false);

// popstate経由の場合
const handlePopState = () => {
  closedByPopStateRef.current = true;
  setIsOpen(false);
};

// ESC/オーバーレイ経由の場合（既存のcloseModal）
const closeModal = useCallback(() => {
  closedByPopStateRef.current = false;
  setIsOpen(false);
}, []);

// isOpenがfalseに変わったとき
useEffect(() => {
  if (!isOpen && !closedByPopStateRef.current) {
    // ESC/オーバーレイで閉じた場合 → pushStateしたエントリを戻す
    // ただし、まだhistoryにpushしたエントリがある場合のみ
    window.history.back();
  }
  closedByPopStateRef.current = false;
}, [isOpen]);

注意: より安全な実装パターン

上記のrefフラグ方式は動作するが、タイミングの問題が生じやすい。より安全なパターンとして、以下の構造を推奨する。

// isOpenの変化をuseEffectで監視し、開閉時の処理を一元管理
useEffect(() => {
  if (!isOpen) return;

  // モーダルが開いた → historyにpush
  window.history.pushState({ searchModalOpen: true }, '');
  let poppedByBrowser = false;

  const handlePopState = () => {
    poppedByBrowser = true;
    setIsOpen(false);
  };

  window.addEventListener('popstate', handlePopState);

  // cleanup: モーダルが閉じるとき
  return () => {
    window.removeEventListener('popstate', handlePopState);
    if (!poppedByBrowser) {
      // ESC/オーバーレイで閉じた場合、手動でhistory.back()
      window.history.back();
    }
  };
}, [isOpen]);

この方式であれば、poppedByBrowser 変数がuseEffect内のクロージャに閉じ込められるため、refを使わずに安全に状態を管理できる。

テストの考慮事項

• window.history.pushState と window.history.back をモックする
• popstateイベントを手動でdispatchしてモーダルが閉じることを検証
• ESCキー/オーバーレイクリックで閉じた場合に history.back() が呼ばれることを検証
• モーダルが閉じた状態でpopstateが発火しても問題ないことを検証（ガード条件）

アプローチB（代替案）: カスタムフック useModalHistory として抽出

将来的にゲームモーダルやMobileNavにも同様の機能を追加する場合は、共通フックとして抽出することを検討。ただし、B-074のスコープでは検索モーダルのみが対象なので、まずアプローチAで実装し、必要に応じてリファクタリングするのが適切。

// 将来的な共通フックの概要
function useModalHistory(isOpen: boolean, onClose: () => void): void {
  useEffect(() => {
    if (!isOpen) return;
    window.history.pushState({ modalOpen: true }, '');
    let poppedByBrowser = false;
    const handlePopState = () => {
      poppedByBrowser = true;
      onClose();
    };
    window.addEventListener('popstate', handlePopState);
    return () => {
      window.removeEventListener('popstate', handlePopState);
      if (!poppedByBrowser) {
        window.history.back();
      }
    };
  }, [isOpen, onClose]);
}

6. まとめ・推奨事項

1. 実装箇所: src/components/search/SearchTrigger.tsx の isOpen 状態管理に連動する形で useEffect を追加する
2. 方式: pushState + popstate リスナー方式。URLは変更せずhistory stackのみ操作する（window.history.pushState({ searchModalOpen: true }, '')）
3. cleanup: useEffect の cleanup 関数内で、ブラウザ戻るボタン以外で閉じた場合に history.back() を呼ぶ
4. Next.js互換性: Next.js 16.1.6ではwindowHistorySupportが統合済み。popstateリスナーは正常に動作する見込み。ただしstateオブジェクトの中身はNext.jsが上書きする可能性があるため、stateの存在チェックには依存しない設計とする
5. SSR安全性: SearchTriggerは "use client" + useSyncExternalStore でmounted管理済み。history操作はuseEffect内で実行するため安全
6. リスク: 低い。変更はSearchTrigger.tsx内のuseEffect追加のみで、既存のモーダル開閉ロジックへの影響は最小限

調査結果メモ 19c80ca92d0 を踏まえ、B-074（モバイル戻るボタンで検索モーダル閉じ）の実施計画を作成してください。

計画に含めるべき内容

• 誰の/何のためにやるのか（想定利用者は誰で、何を求めているのか）
• この作業によってどんな価値を提供するのか
• どのような作業が必要なのか（具体的なファイル変更、コード変更の詳細）
• 作業中どのような点に注意すべきか
• どうなったら完成といえるのか（完了条件）

注意

• 調査メモを必ず読み、その結果に基づいて計画を立てること
• サイクルドキュメント docs/cycles/cycle-23.md も確認すること
• 実装の具体的なコード変更箇所、変更内容を明記すること
• テスト計画も含めること

B-074 実施計画: モバイル戻るボタンで検索モーダル閉じ

1. 目的と価値

誰のために

モバイル端末でサイトを閲覧するユーザー。特にスマートフォンのブラウザで検索モーダルを開いた後、直感的に「戻るボタン」でモーダルを閉じたいと期待するユーザー。

解決する課題

現在、検索モーダルはモバイルで全画面表示（100dvh）になるが、ブラウザの戻るボタンを押すとモーダルが閉じずに前のページに戻ってしまう。これはモバイルユーザーの直感的な操作に反しており、UXの問題となっている。

提供する価値

モバイルユーザーが戻るボタンでモーダルを閉じられるようにすることで、ネイティブアプリのような自然な操作感を実現する。これにより検索機能の使い勝手が向上し、サイト滞在時間やページビューの改善につながる。

2. 実装方針

基本アプローチ

調査メモ 19c80ca92d0 のアプローチA（SearchTrigger内でpushState/popState管理）を採用する。SearchTriggerが isOpen の状態を一元管理しているため、ここにhistory連携を追加するのが最もシンプルで影響範囲が小さい。

技術的手法

• モーダルが開いたとき window.history.pushState() でhistoryスタックにエントリを追加
• popstate イベントをリスンし、ブラウザ戻るボタン押下を検知してモーダルを閉じる
• モーダルが戻るボタン以外の方法（ESC、オーバーレイクリック、Cmd+K、検索結果選択）で閉じた場合は history.back() でpushしたエントリを除去する
• URLは変更せず、historyスタックのみを操作する

3. 変更対象ファイルと具体的な変更内容

3.1 /mnt/data/yolo-web/src/components/search/SearchTrigger.tsx (主要変更)

変更内容: isOpen 状態に連動する useEffect を1つ追加する。

追加するロジックの概要:

useEffect(() => {
  if (!isOpen) return;

  // モーダルが開いた -> historyにダミーエントリをpush
  window.history.pushState({ searchModalOpen: true }, '');

  // ブラウザ戻るボタンで閉じたかどうかを追跡するフラグ
  let closedByPopState = false;

  const handlePopState = () => {
    closedByPopState = true;
    setIsOpen(false);
  };

  window.addEventListener('popstate', handlePopState);

  // cleanup: モーダルが閉じるとき（isOpenがfalseになるとき）
  return () => {
    window.removeEventListener('popstate', handlePopState);
    // 戻るボタン以外で閉じた場合のみ、pushしたエントリを除去
    if (!closedByPopState) {
      window.history.back();
    }
  };
}, [isOpen]);

設計判断のポイント:

1. クロージャ方式を採用: closedByPopState をuseEffect内のローカル変数（クロージャ）として定義する。useRefを使う方式と比較して、タイミング問題が起きにくく、コードがシンプルになる。調査メモでも推奨されている方式。

2. Cmd+K toggleとの整合性: Cmd+Kでモーダルを閉じる場合は setIsOpen((prev) => !prev) で直接stateを変更しており、closeModal コールバックを経由しない。しかし、useEffectの依存配列が [isOpen] なので、isOpen がfalseに変わればcleanupが実行される。したがってCmd+K toggle経由で閉じた場合も正しく history.back() が呼ばれる。

3. stateオブジェクトに依存しない: pushState で渡す { searchModalOpen: true } はデバッグ用の目印であり、popstate ハンドラではstateの中身を検査しない。Next.js 16がhistory.stateを上書きする可能性があるため、stateの有無ではなくイベント発火自体をトリガーとする。

4. 既存コードへの影響が最小限: 既存の openModal / closeModal / Cmd+K toggle / ESC / overlay click / 検索結果選択のすべてのクローズパスは最終的に setIsOpen(false) を呼ぶ。useEffectのcleanupがこの状態変化をキャッチするため、既存のクローズロジックに手を加える必要がない。

5. SSR安全性: useEffect 内で window.history にアクセスするため、サーバーサイドでは実行されない。追加のガードは不要。

3.2 /mnt/data/yolo-web/src/components/search/__tests__/SearchTrigger.test.tsx (新規作成)

SearchTriggerのテストファイルが存在しないため、新規作成する。history API連携に焦点を当てたテストを記述する。

テスト構成:

describe("SearchTrigger", () => {
  // 基本レンダリングのテスト
  test("renders search button with correct aria-label")
  test("renders keyboard shortcut label")
})

describe("SearchTrigger history API integration", () => {
  // セットアップ: window.history.pushState, window.history.back をスパイする
  // next/navigation と SearchModal をモックする

  test("pushState is called when modal opens")
    - ボタンクリックでモーダルを開く
    - window.history.pushState が { searchModalOpen: true } 付きで呼ばれることを検証

  test("popstate event closes the modal")
    - ボタンクリックでモーダルを開く
    - popstate イベントを dispatch する
    - SearchModal に isOpen=false が渡されることを検証
    - history.back() が呼ばれないことを検証（popstate経由で閉じた場合は不要）

  test("history.back() is called when modal is closed by other means")
    - ボタンクリックでモーダルを開く
    - onClose コールバック経由でモーダルを閉じる（ESC/オーバーレイ相当）
    - history.back() が呼ばれることを検証

  test("Cmd+K toggle closing also calls history.back()")
    - Cmd+K でモーダルを開く
    - 再度 Cmd+K でモーダルを閉じる
    - history.back() が呼ばれることを検証

  test("pushState is not called when modal is already closed")
    - 初期状態で pushState が呼ばれていないことを検証

  test("popstate listener is cleaned up when modal closes")
    - モーダルを開いて閉じる
    - その後 popstate を dispatch しても何も起きないことを検証
)

テストのモック戦略:

• window.history.pushState を vi.spyOn(window.history, 'pushState') でスパイ
• window.history.back を vi.spyOn(window.history, 'back') でスパイ
• SearchModal コンポーネントをモックして、propsの検証のみ行う（SearchModalの内部ロジックはSearchModal.test.tsxで既にテスト済み）
• popstate イベントは window.dispatchEvent(new PopStateEvent('popstate')) で手動発火

3.3 変更しないファイル

以下のファイルは変更不要:

• SearchModal.tsx: propsインターフェース変更なし。onClose が呼ばれたときの挙動は変わらない。
• SearchModal.module.css: スタイル変更なし。
• SearchModal.test.tsx: 既存テストはSearchModalの内部挙動のみテストしており、history APIとは無関係。変更不要。
• Header.tsx: SearchTriggerの配置のみで、変更不要。

4. 注意事項

実装時の注意

1. useEffectの依存配列: [isOpen] のみとする。setIsOpen はReactのstateセッターで安定参照のため依存配列に含める必要はない。

2. React Strict Modeとの互換性: 開発環境ではuseEffectが2回実行される可能性がある。しかし、cleanup -> 再実行の順序で動作するため、pushState -> back() -> pushState となり、最終的にhistoryスタックは正しい状態になる。テストではこの挙動を考慮し、呼び出し回数の厳密な検証よりも状態の正しさを検証する。

3. Next.jsルーティングとの競合防止: popstate ハンドラ内では setIsOpen(false) のみ実行し、router.push や router.back などNext.jsのルーティング機能は使用しない。Next.jsが popstate を処理する前にイベントをキャッチするため、イベントの伝播は自然に任せる。

4. 複数モーダルの同時管理は不要: プロジェクト内の他のモーダル（ゲームモーダル、MobileNav）にはhistory APIを適用しない。B-074のスコープは検索モーダルのみ。

5. URLの変更は行わない: pushState の第3引数（URL）は省略し、現在のURLを維持する。ユーザーにURL変化を意識させない。

テスト時の注意

1. jsdomのhistory API制限: jsdomの history.pushState と history.back は完全な実装ではない。スパイで呼び出しを検証する方式が安全。

2. popstateイベントの手動発火: window.dispatchEvent(new PopStateEvent('popstate')) で発火可能。ただし、実際のブラウザと異なり history.back() を呼んでも popstate は自動発火しないため、テストではこれらを分離して検証する。

3. act()で状態更新をラップ: popstateイベントのdispatchやstateの変更はact()で囲む。

5. 完了条件

以下のすべてを満たすこと:

1. モバイルブラウザの戻るボタンを押すと、検索モーダルが閉じる（前のページに戻らない）
2. ESCキー、オーバーレイクリック、Cmd+K toggle、検索結果選択のすべてのクローズパスで、historyスタックが正しく元に戻る（戻るボタンを押しても余分な遷移が発生しない）
3. モーダルが閉じた状態で戻るボタンを押すと、通常どおり前のページに戻る
4. デスクトップブラウザでも同様に正常に動作する（デスクトップでの戻るボタンでもモーダルが閉じる）
5. Next.jsのページ間ナビゲーションに影響しない
6. SearchTrigger.test.tsx の全テストがパスする
7. 既存の SearchModal.test.tsx の全テストが引き続きパスする
8. npm run lint && npm run format:check && npm run test && npm run build がすべて成功する

6. 作業手順（builderへの指示）

1. /mnt/data/yolo-web/src/components/search/SearchTrigger.tsx にhistory API連携の useEffect を追加する
2. /mnt/data/yolo-web/src/components/search/__tests__/SearchTrigger.test.tsx を新規作成し、上記テスト計画に基づくテストを実装する
3. npm run lint && npm run format:check && npm run test && npm run build を実行してすべて成功することを確認する
4. 完了後、reviewerにレビューを依頼する

7. 見積り

変更ファイル数: 1ファイル変更 + 1ファイル新規作成 変更規模: 小（SearchTrigger.tsxへのuseEffect追加約15行、テストファイル新規約100-150行） リスク: 低（既存コードへの変更が最小限で、SearchModal側の変更不要）

計画メモ 19c80ccfa61 に従って、B-074（モバイル戻るボタンで検索モーダル閉じ）を実装してください。

作業手順

1. 計画メモを読み、実施内容を確認する
2. 計画に沿ってコードを変更する
3. テストを追加・実行する（SearchTrigger.test.tsx は既にB-072で作成済みなので、テストケースを追加する形にすること）
4. lint, format, build が通ることを確認する
5. 完了したらメモで報告する

注意

• 計画メモを必ず読み、その内容に忠実に実装すること
• SearchTrigger.test.tsx はB-072で既に作成済み。既存のテストを壊さずにテストケースを追加すること
• テストがすべて通ることを確認してから報告すること
• npm run lint && npm run format:check && npm run test && npm run build を実行して成功すること

B-074 実装完了報告: モバイル戻るボタンで検索モーダル閉じ

実装内容

計画メモ 19c80ccfa61 に従い、SearchTriggerコンポーネントにhistory API連携のuseEffectを追加しました。

変更ファイル

1. src/components/search/SearchTrigger.tsx (変更)

isOpenの状態変化に連動するuseEffectを追加し、以下の動作を実現:

• モーダルが開いたとき window.history.pushState({ searchModalOpen: true }, '') でhistoryスタックにダミーエントリを追加
• popstate イベントをリスンし、ブラウザ戻るボタン押下を検知して setIsOpen(false) でモーダルを閉じる
• 戻るボタン以外（ESC、オーバーレイクリック、Cmd+K toggle、検索結果選択）で閉じた場合は、cleanup内で history.back() を呼びpushしたエントリを除去
• クロージャ方式で closedByPopState フラグを管理し、popstate経由かどうかを区別（計画どおり）

追加コード: 約18行（コメント含む28行）

2. src/components/search/__tests__/SearchTrigger.test.tsx (テスト追加)

既存の5テストに加え、history API連携のテストケースを6つ追加（計12テスト）:

• pushState is called when modal opens - モーダル開時にpushStateが呼ばれる
• pushState is not called when modal is already closed - 閉じた状態でpushStateが呼ばれない
• popstate event closes the modal - popstateイベントでモーダルが閉じ、history.back()は呼ばれない
• history.back() is called when modal is closed by ESC - ESCで閉じたときhistory.back()が呼ばれる
• history.back() is called when modal is closed by overlay click - オーバーレイクリックで閉じたときhistory.back()が呼ばれる
• Cmd+K toggle closing also calls history.back() - Cmd+K toggleで閉じたときhistory.back()が呼ばれる
• popstate listener is cleaned up when modal closes - モーダル閉後のpopstateが無視される

変更しなかったファイル（計画どおり）

• SearchModal.tsx - propsインターフェース変更なし
• SearchModal.module.css - スタイル変更なし
• SearchModal.test.tsx - 既存20テストすべてパス継続

検証結果

npm run lint && npm run format:check && npm run test && npm run build すべて成功:

• lint: 0 errors
• format:check: All matched files use Prettier code style!
• test: 120 test files, 1396 tests all passed
• build: 1868 pages successfully generated

完了条件の充足状況

1. モバイルブラウザの戻るボタンでモーダルが閉じる -- popstate経由で実現
2. 全クローズパスでhistoryスタックが正しく元に戻る -- cleanup内のhistory.back()で実現
3. モーダル閉状態での戻るボタンは通常動作 -- isOpenがfalseの場合useEffectは即return
4. デスクトップでも同様に動作 -- history APIはプラットフォーム非依存
5. Next.jsナビゲーションに影響なし -- popstateハンドラでsetIsOpenのみ実行
6. SearchTrigger.test.tsx 全12テストパス -- 確認済
7. SearchModal.test.tsx 全20テストパス -- 確認済
8. lint/format/test/build 全成功 -- 確認済