モーダル vs. 別ページ：UX決定木で完璧に整理する実践ガイド

はじめに：UXデザイナーなら誰もが悩む瞬間

「この機能はモーダルで表示するべきか、それとも新しいページに遷移させるべきか？」

プロダクト開発をしていると、この判断で迷うことがよくあります。一見シンプルですが、ユーザーフロー、コンテキストの維持、作業効率に大きな影響を与えます。特に日本のように複雑な情報構造と多様なユーザーシナリオを持つ環境では、より慎重な判断が求められます。

この記事では、Smashing Magazineの詳細な分析をもとに、モーダルとページ遷移を選択するUX決定木(Decision Tree) を紹介し、実務ですぐに使える基準を整理します。

参考資料：原文を読む

モーダルの種類：似ているようで違うUIコンポーネント

よく「モーダル」と呼ばれますが、実際にはいくつかの種類があります。それぞれの特性を理解することが第一歩です。

💡 コアインサイト： Anna Kaleyの研究によると、ほとんどのオーバーレイは間違ったタイミングで表示され、ユーザーの重要な作業を妨害します。デフォルトとしては Nonmodal を優先的に検討するのが良いでしょう。

// 例：ReactでNonmodalを実装（背景クリック可能）
const Nonmodal = ({ isOpen, onClose, children }) => {
  if (!isOpen) return null;
  return (
    <div style={{
      position: 'fixed', top: 0, left: 0, right: 0, bottom: 0,
      display: 'flex', justifyContent: 'center', alignItems: 'center',
      pointerEvents: 'none' /* 背景イベントを許可 */
    }}>
      <div style={{
        background: 'white', padding: '20px', borderRadius: '8px',
        boxShadow: '0 4px 12px rgba(0,0,0,0.15)',
        pointerEvents: 'auto' /* モーダル内部のみクリック可能 */
      }}>
        {children}
        <button onClick={onClose}>閉じる</button>
      </div>
    </div>
  );
};

モーダルを選ぶべき場合：単一・独立タスクに最適

モーダルはユーザーにとって邪魔になる可能性がありますが、以下のような状況ではむしろ強力なツールになります。

モーダルが有利なシナリオ

• 単一タスクの完了： 素早い確認、選択、簡単な入力（例：フィルター適用、削除確認）
• コンテキストの維持： 現在のページのスクロール位置、入力値、状態を保持したい場合
• 取り返しのつかないエラーの防止： 重要な作業前の警告（例：「本当に削除しますか？」）
• 新しいページへの移動がかえって邪魔になる場合： データ比較なしで素早いアクションのみが必要な場合

// 例：モーダルで実装した削除確認ダイアログ
const DeleteModal = ({ isOpen, onConfirm, onCancel }) => {
  if (!isOpen) return null;
  return (
    <div style={{
      position: 'fixed', top: 0, left: 0, right: 0, bottom: 0,
      background: 'rgba(0,0,0,0.5)',
      display: 'flex', justifyContent: 'center', alignItems: 'center'
    }}>
      <div style={{ background: 'white', padding: '24px', borderRadius: '8px' }}>
        <h3>投稿を削除しますか？</h3>
        <p>この操作は元に戻せません。</p>
        <button onClick={onConfirm} style={{ background: 'red', color: 'white' }}>削除</button>
        <button onClick={onCancel}>キャンセル</button>
      </div>
    </div>
  );
};

⚠️ 注意点： モーダルはユーザーに「邪魔」というコストを支払わせます。したがって、ユーザーがその邪魔を価値あると感じる場合にのみ使用すべきです。デフォルトはNonmodalをおすすめします。

ページ遷移が必要な場合：複雑・マルチステップタスクに最適

モーダルの中にウィザードやタブを入れるのは良いUXではありません。特にエンタープライズ製品では顕著です。

ページが有利なシナリオ

• 複雑なマルチステッププロセス： 会員登録、決済、設定ウィザード
• データ参照/比較が必要： 以前のデータを見ながら入力する必要がある場合
• 全体集中が必要： ユーザーのすべての注意が必要な作業
• 長いフォーム： スクロールが必要な長い入力フォーム

// 例：React Routerを使ったページ遷移（マルチステップ設定）
import { BrowserRouter, Routes, Route, useNavigate } from 'react-router-dom';

function SetupWizard() {
  const navigate = useNavigate();
  return (
    <div>
      <h1>サービス設定</h1>
      <button onClick={() => navigate('/setup/step1')}>開始する</button>
      <Routes>
        <Route path="step1" element={<Step1 />} />
        <Route path="step2" element={<Step2 />} />
        <Route path="step3" element={<Step3 />} />
      </Routes>
    </div>
  );
}

💡 ドロワー(Drawer)の活用： モーダルよりは複雑だが、ページ全体までは必要ないサブタスクには ドロワー が良い代替案です。例：設定パネル、詳細情報表示

繰り返し作業では両方を避ける

ユーザーが同じ作業を繰り返し行う必要がある場合、モーダルとページ遷移の両方が不便をもたらします。この場合は インライン編集(Inline Editing) または 展開可能セクション(Expandable Section) がより良い選択です。

// 例：インライン編集で繰り返し作業を最適化
const InlineEdit = ({ value, onSave }) => {
  const [isEditing, setIsEditing] = React.useState(false);
  const [editValue, setEditValue] = React.useState(value);

  if (!isEditing) {
    return (
      <span onClick={() => setIsEditing(true)} style={{ cursor: 'pointer' }}>
        {value} ✏️
      </span>
    );
  }
  return (
    <span>
      <input
        type="text"
        value={editValue}
        onChange={(e) => setEditValue(e.target.value)}
        onBlur={() => { onSave(editValue); setIsEditing(false); }}
        autoFocus
      />
    </span>
  );
};

UX決定木：4ステップで終わる選択ガイド

Ryan Neufeldがまとめた決定木をもとに、実務ですぐに使えるように簡略化しました。

ステップ1：現在の画面のコンテキスト(Context)を維持する必要があるか？

• はい → モーダル/オーバーレイを検討
• いいえ → ページ遷移を検討

ステップ2：タスクの複雑さと所要時間は？

• 単純/短い（例：確認、選択）→ モーダル
• 複雑/長い（例：マルチステップ入力）→ ページ

ステップ3：背景データの参照が必要か？

• はい（比較、コピーが必要）→ Nonmodal または ドロワー
• いいえ（単純な確認）→ Modal

ステップ4：適切なオーバーレイタイプを選択

• デフォルト: Nonmodal（背景有効）
• 強制集中が必要: Modal
• 画像/メディア: Lightbox

📌 日本の開発現場での適用コンテキスト： 日本のサービスは複雑なメニュー構造と多くのデータを1画面に表示することがよくあります。こうした環境ではモーダルを乱用するとユーザーが迷子になりやすいです。特に管理画面やダッシュボードではNonmodalやドロワーを優先的に検討し、本当に重要なアクション（データ削除、ステータス変更）にのみModalを使用するのが良いでしょう。

モーダル使用時に避けるべき7つの間違い

1. エラーメッセージにモーダルを使用 → インラインエラーで十分
2. 機能通知(Feature Notification)にモーダルを使用 → トースト(Toast)で代替
3. オンボーディング体験にモーダルを使用 → 段階的開示(Progressive Disclosure)を活用
4. 長く複雑なマルチステップタスクにモーダルを使用 → ページまたはドロワーを使用
5. ネストされたモーダル(Nested Modal) → 前へ/次へボタンで代替
6. 自動トリガーモーダル → 本当に必要な場合のみ、ユーザーアクションの後に
7. ESCキーや外部クリックで閉じられないモーダル → 常に閉じる方法を提供

技術の限界と注意点

• アクセシビリティ(Accessibility): モーダルはスクリーンリーダーユーザーに混乱を与える可能性があります。role="dialog"、aria-modal="true" 属性とフォーカストラップ(Focus Trap)を必ず実装してください。
• モバイル環境: 小さな画面ではモーダルがコンテンツを隠しやすいです。モバイルでは画面全体を覆うシート(Bottom Sheet)の方が良い場合があります。
• パフォーマンス: モーダル内部に重いコンポーネントをレンダリングするとページのパフォーマンスに影響を与える可能性があります。遅延ローディング(Lazy Loading)を検討してください。

合わせて読みたい記事：

• CSSでselectを完全にカスタマイズする3つの実践例（フォルダ、カード、絵文字）
• Metaが公開したRCCLX AMDプラットフォームGPU通信性能を革新

まとめ：UX決定の核心は「邪魔」の価値

モーダルとページ遷移のどちらを選ぶかは、「ユーザーが支払う邪魔のコスト」 と 「その邪魔がもたらす価値」 のバランスにかかっています。

• モーダルはユーザーを遅くし、集中を束ね、ミスを防ぎます。
• ページはユーザーに自由を与え、複雑な作業を可能にします。

Therese Fessendenが言うように、誰も邪魔されることを好みません。しかし、どうしても邪魔しなければならないなら、その価値があるかどうかを自分自身に問いかけてください。

次のステップ学習方向

1. ユーザーテスト： 決定木で選択した後、実際のユーザーテストで検証しましょう。
2. アクセシビリティ監査： モーダル/ページがWCAG 2.1基準を満たしているか確認しましょう。
3. パターンライブラリ構築： プロジェクトに適したモーダル/ページパターンを標準化し、ドキュメント化しましょう。

参考： この記事は Smashing Magazineの原文 をもとに、日本の開発環境に合わせて再構成しました。