この記事の要点（UIXHERO視点） UIXHEROでは、再認を「見れば思い出せる」、再生を「ゼロから思い出す」と定義し区別する。 ニールセンの10ヒューリスティクスで「Recognition over Recall」が原則とされる理由は、再生は認知負荷が高く、エラーを誘発するからである。
導入：「あのコマンド、何だっけ？」
「このアプリの保存ショートカット、Ctrl+S？ Cmd+S？ それとも別のキー？」 「さっき見たあの設定、どこにあったっけ？」
こんな経験はないでしょうか。これは再生（Recall）を要求されている状態です。
一方、メニューを開けば「保存」ボタンがあり、クリックすれば保存できる。これは再認（Recognition）で済む状態です。
ユーザーに「思い出させる」UIは、認知負荷を上げ、エラーを誘発する。
この問題を解く鍵が、再認（Recognition）と再生（Recall）です。これらは認知心理学の基本概念であり、UIデザインの根幹を成す原則です。
再認と再生の違い（定義）
再認は「手がかりがあれば思い出せる」であり、再生は「手がかりなしに思い出す」である。
| 項目 | 再認 (Recognition) | 再生 (Recall) |
|---|---|---|
| 定義 | 以前見た情報を「それだ」と認識する | 手がかりなしに情報を取り出す |
| 認知負荷 | 低い | 高い |
| 例（テスト） | 選択式問題 | 記述式問題 |
| 例（UI） | ドロップダウンメニュー | コマンドライン入力 |
語源と背景
この区別は認知心理学の記憶研究に由来します。ヘルマン・エビングハウスの忘却曲線研究以来、人間の記憶は「保存」より「検索」で失敗することが知られています。
ヤコブ・ニールセンは、ユーザビリティの10ヒューリスティクス（第6原則）で「Recognition rather than recall（再生より再認）」を掲げました。これは「ユーザーに記憶を強いるな」という設計原則です。
研究からの引用: 「ユーザーの記憶負荷を最小化せよ。オブジェクト、アクション、オプションを可視化せよ。ユーザーが対話の一部から別の部分へ情報を記憶しなければならないようにしてはならない。」（Jakob Nielsen）
なぜ重要なのか
1. 再生は認知負荷が高い
心理学の実験では、再認テスト（選択式）の正答率は再生テスト（記述式）より常に高くなります。これは、再認が「マッチング」であるのに対し、再生は「検索＋構築」を要するからです。
- 再認: 提示された選択肢と記憶を照合するだけ
- 再生: 記憶から情報を取り出し、言語化する
UIで再生を要求すると、ユーザーの脳は「検索＋構築」を強いられ、疲労します。
2. 再生はエラーを誘発する
記憶は不完全です。再生を要求すると、以下のエラーが起きます：
- 想起失敗: そもそも思い出せない
- 誤記憶: 間違った情報を思い出す
- 混同: 似た情報と取り違える
UIでこれが起きると、ユーザーは「自分が悪い」と感じますが、実際は設計の問題です。
具体例・ケース比較
ケース1：コマンド入力 vs メニュー選択
| 観点 | 再生（NG） | 再認（OK） |
|---|---|---|
| UI | コマンドラインで git commit -m "message" を入力 | GUIで「コミット」ボタンをクリック |
| 認知負荷 | コマンド構文を記憶している必要がある | ボタンを見れば何ができるかわかる |
| エラー率 | タイプミス、構文エラーが頻発 | クリックミス以外のエラーは起きにくい |
※ パワーユーザー向けにコマンドを残すのは良い設計。ただし、初心者には再認で済む選択肢を用意すべき。
ケース2：パスワード入力 vs パスワードマネージャー
| 観点 | 再生（NG） | 再認（OK） |
|---|---|---|
| UI | 毎回パスワードを手入力 | パスワードマネージャーが候補を表示 |
| 認知負荷 | 複雑なパスワードを記憶する負担 | 表示された候補をタップするだけ |
| セキュリティ | 覚えやすい簡単なパスワードを使いがち | 複雑なパスワードでも問題なし |
ケース3：住所入力 vs 郵便番号自動補完
| 観点 | 再生（NG） | 再認（OK） |
|---|---|---|
| UI | 都道府県・市区町村・番地をすべて手入力 | 郵便番号を入れると住所が自動補完 |
| 認知負荷 | 正式な住所表記を記憶している必要がある | 候補から選ぶだけ |
| エラー率 | 「丁目」「番地」の書き方を間違える | 正式表記が自動で入る |
実務でなぜ区別すべきか
UIXHEROがこの2つを厳密に区別する理由は3つあります。
1. 認知負荷の設計に直結する
UIの複雑さは「機能の数」ではなく「ユーザーが記憶すべき量」で決まります。再生を要求するUIは、機能が少なくても複雑に感じます。
2. エラー防止の根幹である
ニールセンの「エラー防止」原則と「Recognition over Recall」は表裏一体です。再生を減らせば、記憶エラー由来のミスが減ります。
3. アクセシビリティに影響する
記憶障害、注意障害、加齢による認知機能低下——これらのユーザーにとって、再生を要求するUIは致命的なバリアになります。再認で済むUIは、より多くの人に使いやすいUIです。
改善のための設計原則と対策
具体的な改善策（OK/NG比較）
| 項目 | NG（再生を要求） | OK（再認で済む） |
|---|---|---|
| ナビゲーション | メニュー項目を記憶させる | 常にナビゲーションを表示 |
| 検索 | 正確なキーワードを要求 | サジェスト、オートコンプリートを表示 |
| フォーム | 入力形式を記憶させる | プレースホルダー、例文を表示 |
| ショートカット | キーを暗記させる | ツールチップでショートカットを表示 |
| 履歴 | 過去の操作を記憶させる | 最近使った項目を表示 |
原則1：オプションを見せる
ユーザーが「何ができるか」を記憶しなくて済むように、利用可能なアクションを可視化します。
- NG: 右クリックメニューしかない（存在を知らないと使えない）
- OK: ツールバーにアイコンを表示＋右クリックでも同じ操作が可能
原則2：コンテキストを維持する
画面遷移で情報が消えると、ユーザーは前の画面の情報を「再生」しなければなりません。
- NG: 設定画面に遷移すると、元の画面の状態が見えなくなる
- OK: サイドパネルやモーダルで、元の画面を見ながら設定できる
原則3：入力を支援する
ユーザーが「何を入力すべきか」を記憶しなくて済むように、ヒントや候補を提供します。
- NG: 空のテキストフィールドだけ
- OK: プレースホルダー、入力例、オートコンプリート、バリデーションメッセージ
よくある質問 (FAQ)
Q1. 再生を要求するUIは常に悪いのですか？
常に悪いわけではありません。以下の場合は再生が適切なこともあります：
- パワーユーザー向けの効率化: キーボードショートカット、コマンドパレット
- セキュリティ要件: パスワード入力（ただし、パスワードマネージャー連携は提供すべき）
- 学習目的: あえて記憶させることで定着を促す
ただし、初心者やカジュアルユーザーには、常に再認で済む選択肢を用意すべきです。
Q2. 選択肢が多すぎると再認も難しくなりませんか？
その通りです。選択肢が多すぎると「探す」という認知負荷が発生します。これはヒックの法則（選択肢が増えると決定時間が増える）と関連します。
対策：
- カテゴリ分け: 選択肢をグループ化する
- 検索・フィルター: 絞り込み機能を提供する
- 最近使った項目: よく使う選択肢を上位に表示する
Q3. コマンドラインは悪いUIですか？
いいえ。コマンドラインは「再生」を要求しますが、熟練者にとっては最も効率的なインターフェースです。問題は「コマンドラインしかない」設計です。
良い設計は、再認（GUI）と再生（CLI）の両方を提供し、ユーザーが選べるようにします。
関連リンク
UIXHEROの関連記事
- 記憶に頼らせない (Recognition over Recall) — UI原則としての詳細解説
- 認知負荷 — なぜ「考えさせない」ことが重要か
- ヒックの法則 — 選択肢と意思決定時間の関係
用語集
再認は「見れば思い出せる」——UIが記憶を代行する。 再生は「ゼロから思い出す」——ユーザーに記憶を強いる。
まとめ
- 再認 (Recognition): 手がかりがあれば思い出せる（認知負荷：低）
- 再生 (Recall): 手がかりなしに思い出す（認知負荷：高）
- 使い分け: UIはできる限り再認で済むように設計する。再生はパワーユーザー向けのオプションとして残す。
UIはユーザーに思い出させるのではなく、見ればわかる状態をつくるべきである。記憶を代行するUIが、良いUIである。
