複雑性保存の法則とUIの関係のメモ
これまでの記事で、フィッツの法則、ヒックの法則、認知負荷理論を取り上げてきました。フィッツの法則は到達までの運動時間、ヒックの法則は選択肢からの判断時間、認知負荷理論はそれ らを内包する認知資源の構造。一貫していたのは、ユーザーの認知資源をどう節約するかという視点です。
ただ、認知負荷理論の記事の最後に書いた「外在的負荷を削る」という方針には、暗黙の前提があります。削れる複雑性と、削れない複雑性が分かれているという前提です。削れない複雑性はどこへ行くのか。誰がそれを引き受けるのか。
今回は、この問いを正面から扱う原則として知られる複雑性保存の法則について整理してみます。フィッツやヒックが時間を予測する数式モデルだったのに対し、この法則は性格が違います。同じ「UIの法則」として並べて語られがちですが、その立ち位置の違いまで含めて見ておきたいと思います。
この記事のターゲット
これまでのUI法則記事を読んで、不可削減な複雑性の扱いを整理したい方
「もっとシンプルに」という要望に対して構造的な根拠を持って応答したい方
B2B SaaSや業務システムで、過度な単純化の落とし穴を避けて設計したい方
複雑性保存の法則とは
複雑性保存の法則は、初期のGUI開発に関わった研究者ラリー・テスラーが1980年代半ばに整理したとされる経験則です。法則の中身は、次の一文に集約されます。
Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it—the user, the application developer, or the platform developer?
直訳すると、あらゆるアプリケーションにはそれ以上削減できない固有の複雑性があり、問題はただひとつ、誰がそれを引き受けるかになります。ユーザーか、アプリケーション開発者か、それともプラットフォーム開発者か、ということのようです。
削減不可な複雑性という考え方
複雑性保存の法則を象徴的に説明するための思考実験があります。要旨は次のとおりです。
100万人のユーザーが毎日1分余分に複雑さに付き合うことを、エンジニアが1週間かけて取り除けるとすれば、それを怠るのはユーザーを犠牲にしてエンジニアを楽にしていることになる。
数の対比から読み取れるのは、この法則が単なる「ユーザーに優しくしよう」という規範ではなく、複雑性を「誰の時間で支払うか」という資源配分の問題として捉えていることです。総量は同じでも、引き受け手によって社会的なコストが大きく変わる。エンジニアの1週間と、100万人の1分×365日を比較しているのです。
保存という呼称は、エネルギー保存の法則になぞらえた含意とされています。複雑性は消えず移動するだけだという見立てが、この法則の肝です。
補足として、これはフィッツやヒックのような実験データから導かれた予測モデルではなく、設計判断のための規範に近いものです。形式的に証明されたわけでもなく、反証可能な仮説でもありません。あくまでテスラー氏の経験則であり、設計者に問いを立てさせるためのフレームワークと考えると良いかもしれません。
UIデザインへの応用
複雑性保存の法則を実際に使えそうな場面をいくつか整理してみます。
システム側で吸収する
最も直接的な応用は、ユーザーが負っていた操作の複雑性を、システム側の処理に移すことです。
メールアドレスや住所の自動補完、日付選択のためのデートピッカー、検索条件のサジェスト、ログイン情報の保持。いずれも「ゼロから入力する」というユーザー側の複雑性を、過去データやコンテキストから推定するシステム側の複雑性に置き換えています。それらが本質的にもつ、複雑性そのものは消えていません。推定ロジックを書く労力、誤推定をハンドリングする労力、ユーザーが推定結果を修正する手間という形で、別の場所に移動しています。
実装側の感覚で言えば、こうした自動化機能はリリース後の保守が地味に重くなる箇所でしょう。更新住所のフォーマット差異、姓名分割、外字、海外住所、変換ミス。あてにしていたOSSがなくなって、仕方なく自前で独自実装をしてその複雑性を業として背負った経験のある方もいるのでは無いでしょうか。
プラットフォーム層に押し付ける
最近とくに注目したいのが「プラットフォーム開発者」が引き受ける複雑性です。
iOSやmacOSが提供するテキスト編集、共有メニュー、写真ピッカーなどは、個々のアプリ開発者が複雑性を引き受けなくて済むようにOS側が標準を整えた領域です。ブラウザのフォーム自動入力やパスワード管理も同じ構造です。最近ではReactのようなUIフレームワーク、Tailwind CSSのようなスタイル基盤、shadcn/uiのようなコンポーネントライブラリが、アプリ開発者から見たときの複雑性をプラットフォーム側に肩代わりさせています。
AIが生成するUIや、LLMがコードを書く時代には、この「プラットフォーム開発者」という立場が新しい意味を持ち始めています。アプリ開発者が書かなくなったコードの複雑性は、モデルの学習プロセス、推論コスト、生成物の検証プロセスといった、見えに くい場所に移動しています。
時間方向に分散する
ヒックの法則の記事で扱った情報を折りたたんだ段階的なUIも、複雑性保存の法則の文脈で見ると違った姿に見えます。
すべての選択肢や設定を一度に提示せず、ユーザーの進行に合わせて段階的に出していく設計は、表面的にはユーザーの認知負荷を下げる一方で、複雑性保存の法則の枠組みで眺めると、これは複雑性をユーザーの時間方向に再配置している、と捉えることもできます。
トータルで触る項目数は変わらず、いつ触るかが分散されている。一度に処理しなくてよくなったぶん、いつ何が出てくるかという見通しの悪さや、初心者向けの順序が熟練者には冗長になるといった別の負担が発生します。
「複雑性を時間方向に薄く塗り広げた」と理解しておくと、ユーザーが熟達したときに段階表示が邪魔になるという、よくある現象の説明がつきます。
シンプルさのパラドックス
ここまでは「複雑性を移すことで体験を整える」話でした。実務ではその逆、つまり移しすぎてかえって複雑になる例にも頻繁に出会います。
ブルース・トグナッツィーニ氏が示した観察は、複雑性保存の法則とよく対で引用されます。ユーザーは複雑さの削減を必ずしも歓迎せず、操作が簡単になるとより複雑なタスクを試みるようになる、というものです。表計算ソフトはシンプルな四則演算から始まり、すぐに数式とマクロとスクリプトまで使われ始めます。SNSの無限スクロールは1スクロールの摩擦をゼロに近づけた結果、滞在時間が制御不能になり、認知資源を消耗させます。
エクスペディアの旅行検索の事例も示唆に 富んでいます。検索結果の表示時間を短縮しすぎたところ、ユーザーが「システムが何もしていない」と感じ、信頼性が下がった。意図的に2秒の遅延を入れたほうがUXが改善したという報告があります。複雑性を完全に隠すことが必ずしも正解にならない、という反例として読めます。
ドン・ノーマン博士の整理を借りれば、シンプルさの本質は表面上の見た目を最小化することではなく、ユーザーが頭の中に作るメンタルモデルと良く噛み合うことです。以前の記事で取り上げたメンタルモデルの議論と、ここで合流します。
Photoshopは初心者から見れば複雑きわまりないツールですが、プロにとっては必要な機能が必要な場所に揃っている。それが「シンプル」と呼ぶに値する状態である、というのが本質的にメンタルモデルと噛み合っている状態という考え方です。
複雑性保存の法則は、「見た目のシンプルさ」と「操作のシンプルさ」は区別した上で、後者を保ったまま前者をどこまで追求できるかを問う原則と言えます。
3つの視点を取り戻す
業務システムやB2B SaaSの設計に関わっていると、ユーザー、アプリ開 発者、プラットフォーム開発者という3つの視点で分ける考え方が役立つシーンがあります。たとえば「情報区分の入力をもっとシンプルに」という要望があったとき、選択肢としては次のような分解が可能です。
入力時の選択肢を減らす（ユーザー負担を直接減らす）
過去入力や類似データから推定して初期値を入れる（アプリ開発者が引き受ける）
共通の会計マスタやデフォルトを業界標準として整え、各アプリが同じ前提を共有する（プラットフォーム開発者が引き受ける）
3つのうちどれを選ぶかで、アプリの寿命や保守コストや業界全体の標準化への影響が変わることから、意思決定の判断がしやすくなる場合もありそうです。
まとめのメモ
複雑性保存の法則を明示的に理解しておく意味は、これまでの記事と同じく2つあると思います。
1つは、「シンプルにしてほしい」というフィードバックに対して、構造的に応答できることです。シンプルさは目的ではなく、複雑性配置の結果として現れる現象だと言えます。一見シンプルなUIは、その複雑性を別のどこか、しばしば開発側やプラットフォーム側に押し付けることで成立しています。「もっとシンプルに」と言われたときに、それが本当に総量を減らせる話なのか、それとも誰かに転嫁する話なのか。両者を区別したうえで議論できるかどうかは、設計判断の質に直結します。
もう1つは、これまでと同じく、生成されたUIを評価する基準になることです。AIが出力した画面を見たときに「ここで隠されている複雑性は誰が引き受けているのか」「移動先のコストはペイするのか」と問 えるかどうか。シンプルに見える出力ほど、移動先に押し付けられたものが大きい可能性があります。3つの視点で問うことで、その移動先まで含めて評価できます。
フィッツの法則がUIの「操作のしやすさ」を、ヒックの法則が「選びやすさ」を、認知負荷理論が「処理のしやすさ」を扱う法則だとすれば、複雑性保存の法則はUIの「複雑性の置き場所」を扱う法則と言えるのではないかと思います。
シンプルさは、それ自体が善ではありません。複雑性を上手に置き直した結果として、ユーザーから見たときにシンプルに見える状態が現れる。複雑性保存の法則は、その「置き直す」という設計行為の存在を認識するためのフレームワークです。
あなたは、そのUIが本来担うべき複雑性を、何も考えずにエンジニアやAIに預けて（押し付けて）いませんか？
