この記事の要点（UIXHERO視点） UIXHEROでは、ユーザーエラーを「システムの敗北、設計の怠慢」と捉える。 本記事では、「ヒューマンエラー」という思考停止ワードを捨て、物理的な制約（強制機能）と寛容な回復手段（Undo）によって、失敗させないシステムを構築する責任論を整理する。

ユーザーは決して間違わない

「ユーザーが操作を誤った」。 開発現場やデザインのレビューで、このような言葉を耳にすることはないでしょうか？ しかし、認知心理学とUXデザインの観点において、「ユーザーの間違い」という概念は存在しません。

あるのは、「ユーザーのメンタルモデルと合致しなかったシステムのデザイン」 だけです。

「ヒューマンエラー」という言葉で片付けてしまうことは、デザインの敗北を意味します。なぜなら、そのラベルを貼った瞬間に「もっと注意書きを増やそう」「ユーザー教育を強化しよう」という、効果の薄い精神論的な対策に終始してしまうからです。 本稿では、ドン・ノーマン（Don Norman）やジェームズ・リーズン（James Reason）の理論を紐解きながら、エラーを個人の不注意ではなく、システムの構造的な欠陥として捉え直す「システム思考」のアプローチについて論じます。

1. 「ヒューマンエラー」という責任転嫁

事故調査やシステム障害の報告書で「ヒューマンエラー」が原因とされる場合、それは分析の 終着点ではなく出発点 でなければなりません。

スイスチーズ・モデルの教訓

心理学者のジェームズ・リーズンが提唱した「スイスチーズ・モデル」は、事故発生のメカニズムを鮮やかに説明しています。 事故は単一の原因で起こるものではありません。組織、監督、前提条件、そして不安全な行為といった複数の防御壁（チーズの層）に空いた穴が、偶然一直線に並んだ時に初めて発生します。

UIデザインにおいて、この「防御壁」は以下のように機能すべきです：

1. 知覚の壁 (Perception): 危険なボタンは赤く、安全なボタンは青く色分けされ、視覚的に区別できるか？
2. 認知的制約 (Cognitive Constraint): その条件下で押してはいけないボタンは Disabled（無効化）になっているか？
3. フィードバック (Feedback): 「本当に削除しますか？」という確認ダイアログ（モーダル）が出るか？
4. 回復性 (Recoverability): 万が一削除してしまっても、ゴミ箱から元に戻せる（Undo）か？

ユーザーが誤ってデータを削除してしまった場合、それはユーザーが不注意だったからではありません。これら4つの防御壁のすべてに穴が開いていた（例：削除ボタンが目立たず、確認もなく、Undoもできない）ことが真の原因です。これを「システムエラー」と呼ばずして何と呼ぶでしょうか。

2. エラーの心理学的分類：スリップとミステイク

ドン・ノーマンは、著書『誰のためのデザイン？』の中でエラーを大きく2つに分類しました。この区別は、対策を考える上で極めて重要です。

A. スリップ (Slips)：無意識の失敗

「やろうとしたことは正しかったが、手が滑った（実行段階の失敗）」 熟練者が慣れ親しんだ操作を行う際、無意識（自動化されたプロセス）で行動している時に起こります。注意力が散漫なときや、似たような手順が連続するときに発生します。

• 具体例:
  • 本当は「保存」を押したかったが、隣の「キャンセル」を押してしまった（近接性の問題）。
  • いつもの習慣で、確認ダイアログを読まずに「OK」を押してしまった（習慣化）。
• デザインによる対策:
  • フィッツの法則の応用: ボタン同士の距離を離し、クリック領域を十分に確保する。
  • アイソレーション: 破壊的な操作（削除など）のボタンを、肯定的な操作から隔離する。
  • Undo機能: スリップは生理現象のようなもので完全に防ぐことは不可能なため、「回復コスト」を極限まで下げるのが正解です。

B. ミステイク (Mistakes)：意識的な失敗

「やろうとしたこと自体が、システムの状態と合っていなかった（計画段階の失敗）」 ユーザーが状況を誤って解釈し、間違った目標を立てて行動した結果です。これは初心者に多く見られます。

• 具体例:
  • 「アーカイブ」機能を「削除」だと思い込んで実行し、データが見つからなくてパニックになる。
  • システムが「編集モード」だと思って入力したら「閲覧モード」で、入力されなかった。
• デザインによる対策:
  • メンタルモデルの整合: ユーザーが既に持っている知識と一致する用語やアイコンを使う（ゴミ箱アイコンなど）。
  • モードの可視化: 「現在編集モードです」と明確に表示し、状態（Consequences）を予測させるフィードバックを与える。

3. テキストによる警告の無力さ

「注意：この操作は二度と取り消せません。慎重に操作してください。」 このような赤字のテキスト警告は、残念ながらほとんど効果がありません。これには 「正常性バイアス (Normalcy Bias)」 が深く関わっています。

正常性バイアスと学習性無力感

人間は、予期しない異常事態に直面したとき、「これは正常な範囲内のことだ（大したことではない）」と過小評価して心を落ち着かせようとする心理メカニズムを持っています。 さらに、Webユーザーは日々数え切れないほどの「重要なお知らせ」「Cookieの同意」「利用規約の更新」にさらされ、それらを「読む必要のないノイズ」として処理することに慣れてしまっています（バナー・ブラインドネス）。

タスク遂行中のユーザーは「ゴール」しか見ていません。「自分は間違えないだろう」という強固な楽観バイアスの元で、警告文は脳内でフィルタリングされます。 したがって、「書いてあるから読んでいるはずだ」というのは、作り手の甘えに過ぎません。

制約 (Constraints) という解決策

警告文で「お願いします」と頼むのではなく、UIの構造で物理的に間違いを防ぐ 必要があります。

• GitHubの例: リポジトリ削除などの危険な操作時に、「リポジトリ名を入力してください」と強制するUIがあります。 これは単なる確認ではありません。「スリップ（無意識のクリック）」を物理的に不可能にし、強制的に意識的なプロセス（ミステイクの確認）を引き出す、極めて優れた「強制機能（Forcing Function）」の例です。

4. エラー・トレラントなシステムへ

「人は必ず間違える」という前提に立ち、エラーを許容（Tolerate）するシステムこそが、真に優れたUXです。

• 防止 (Prevention): エラーが起こりえないインターフェースにする（自由入力ではなくカレンダーピッカーを使うなど）。
• 検知 (Detection): 入力直後のインライン・バリデーションで、送信ボタンを押す前に気づかせる。
• 回復 (Recovery): 「ゴミ箱」機能、数秒間の「送信取り消し」トースト、無制限の編集履歴。

エラーメッセージが表示されたとき、ユーザーは「システムに怒られた」と感じ、ストレスを受けます。 しかし本来、バリデーションとはシステムとの「対話」であるべきです。「ダメです」と拒絶するのではなく、「こうすればうまくいきますよ」と導く案内人としての振る舞いが、システムの信頼性を決定づけます。

---