3行でわかるテスラーの法則
- テスラーの法則：どんなシステムにも消せない複雑さがあり、誰かが負担しなければならない
- UXでの活用：入力の自動化、デフォルト値、予測提案でユーザー負担を減らせる
- 設計の要点：複雑さを隠すのではなく、できる限りシステム側が引き受ける
テスラーの法則（Tesler's Law）とは、どんなシステムやプロセスにも削減できない「核となる複雑さ」が存在し、それを誰かが負担しなければならないという法則です。別名「複雑性保存の法則（Law of Conservation of Complexity）」とも呼ばれます。
良いUIとは、複雑さを消したUIではなく、複雑さの負担先を正しく設計したUIである。
メール送信を考えてみてください。「宛先を指定する」「送信ボタンを押す」という最低限の操作は、どんなに優れたUIでも消すことができません。この複雑さを「ユーザーにすべて手入力させる」か「過去の履歴から宛先を予測して提案する」かで、体験は全く異なります。
この記事でわかること
- テスラーの法則の意味
- UXで重要な理由
- 住所自動入力・デフォルト値・予測提案への活かし方
- ヒックの法則・認知負荷との違い
テスラーの法則とは
テスラーの法則（Tesler's Law）とは、1980年代にXerox PARCやAppleで活躍したコンピュータ科学者 Larry Tesler（ラリー・テスラー）が提唱した法則です。「複雑性保存の法則」とも呼ばれ、どんなプロセスにも取り除くことのできない「核となる複雑さ（Core Complexity）」が存在することを示しています。
| 項目 | 内容 |
|---|---|
| 英語名 | Tesler's Law / Law of Conservation of Complexity |
| 提唱者 | Larry Tesler |
| 時期 | 1980年代（Xerox PARC・Apple在籍時） |
| 分野 | HCI（ヒューマン・コンピュータ・インタラクション）・システム設計 |
| 一言で | 複雑さは消せない。ユーザーかシステムで分担する |
UIデザインの視点では、システム（開発者）が複雑さを引き受けることで、ユーザーの負担を減らすのが理想的な設計です。
タップして拡大表示クリックして拡大表示
なぜUXデザインで重要なのか
テスラーの法則がUXデザインで重要な理由は3つあります。
1. 「シンプルなUI」の落とし穴を回避できる
「シンプルにしよう」という掛け声だけでは、複雑さは消えません。見た目をシンプルにしても、ユーザーが頭の中で処理しなければならない複雑さが残っていれば、体験は悪化します。テスラーの法則は「複雑さは誰かが負担する」という現実を直視させ、表面的なシンプルさではなく本質的な負担軽減を目指す設計を促します。
2. 開発コストと体験のトレードオフを明確化できる
システム側で複雑さを引き受けるには、開発コストがかかります。住所自動入力にはAPI連携が必要ですし、過去の購入履歴からおすすめを出すにはレコメンドエンジンが必要です。テスラーの法則は「どこにコストをかけるべきか」を判断するフレームワークとして機能します。競合との差別化ポイントでは、ユーザーが楽になる方向にコストをかけるべきです。
3. 「なぜこの機能が必要なのか」を説明できる
プロダクトマネージャーやエンジニアに「なぜ住所自動入力を実装すべきか」を説明するとき、テスラーの法則は強力な論拠になります。「ユーザー体験を良くしたい」という曖昧な説明ではなく、「複雑さをシステム側に移すことで、ユーザーの脱落率を下げる」という明確な主張ができます。
UIデザインにおけるテスラーの法則の具体例
テスラーの法則は「入力の自動化」「デフォルト値の設計」「文脈の予測」で活用されます。
ケース1：住所自動入力（郵便番号 → 住所）
悪い例（ユーザー負担）: 都道府県・市区町村・番地をすべて手入力させる。 良い例（システム負担）: 郵便番号を入力すると、APIで住所が自動入力される。
郵便番号から住所を引く処理は、ユーザーにとっては「調べる → 入力する」という負担ですが、システムにとっては数百ミリ秒のAPI呼び出しです。この複雑さをシステム側に移すことで、入力ミスも減り、離脱率も下がります。
タップして拡大表示クリックして拡大表示
| パターン | 複雑さの負担者 | ユーザー体験 |
|---|---|---|
| 全項目手入力 | ユーザー | 「面倒だ、入力ミスしそう」 |
| 郵便番号から自動入力 | システム（API） | 「楽！一瞬で終わった」 |
ケース2：デフォルト値の設計
フォームの初期値を「空」にするか「よく選ばれる値」にするかで、ユーザーの負担は大きく変わります。大多数のユーザーにとって妥当で安全な値をデフォルトにしておけば、多くのユーザーは「何も選ばずに次へ進む」だけで済みます。
- 配送オプション: 「通常配送」をデフォルトに（急ぐ人だけが変更）
- 通知設定: 「重要な通知のみ」をデフォルトに（全部欲しい人だけが変更）
- 言語設定: ブラウザの言語設定を検出して自動選択
タップして拡大表示クリックして拡大表示
ケース3：文脈の予測（パーソナライズ）
ECサイトで「以前購入した商品」から「詰め替え用」を提案するのも、テスラーの法則の適用例です。ユーザーが「何を買ったか思い出す → 詰め替えを探す → カートに入れる」という複雑さを、システム側の購買履歴分析が肩代わりしています。
- Netflix: 視聴履歴からおすすめを提示（探す負担を軽減）
- Spotify: Discover Weeklyで新しい曲を提案（探索の複雑さを肩代わり）
- Gmail: スマートリプライで返信候補を提示（入力の負担を軽減）
タップして拡大表示クリックして拡大表示
テスラーの法則とヒックの法則・認知負荷の違い
テスラーの法則は、ヒックの法則や認知負荷と関連しますが、焦点が異なります。
| 項目 | テスラーの法則 | ヒックの法則 | 認知負荷 |
|---|---|---|---|
| 定義 | 削減できない複雑さは誰かが負担する | 選択肢が増えると意思決定に時間がかかる | 脳のワーキングメモリの使用量 |
| 焦点 | 複雑さの「責任分担」 | 選択肢の「数」 | 情報処理の「量」 |
| 対策 | システムで自動化・推論 | 選択肢を減らす・階層化 | チャンク化・段階的開示 |
| 問い | 「誰が複雑さを負担するか？」 | 「選択肢は何個が最適か？」 | 「脳の負担を減らせるか？」 |
テスラーの法則は「どんなシステムにも完全には取り除けない複雑さがある」という前提に立ち、その分担を設計します。ヒックの法則や認知負荷は「ユーザー側の処理能力」に焦点を当てますが、テスラーの法則は「システム側への責任転嫁」を積極的に推奨する点で異なります。
タップして拡大表示クリックして拡大表示
テスラーの法則をUIデザインに活かす方法
テスラーの法則を実務に持ち帰るための設計指針は、次の3つに集約できます。
タップして拡大表示クリックして拡大表示
- 入力させなくてよいことは入力させない — 住所・電話番号・日付など、API連携やオートコンプリートで自動化できる項目を手入力させない。
- 妥当な初期値を先に置く — 大多数のユーザーにとって適切なデフォルト値を設定し、「選ぶ」という判断負担をシステム側で引き受ける。
- 履歴や文脈から予測できることは提案する — 購買履歴、閲覧履歴、位置情報などから次のアクションを予測し、ユーザーの探索負担を減らす。
設計チェックリスト
- ユーザーが何度も同じ情報を入力させられていないか
- システム側で計算・推測できることを、ユーザーに質問していないか
- デフォルト値は、大多数のユーザーにとって妥当で安全な設定になっているか
- 住所・電話番号・日付など、API連携で自動入力できる項目を手入力させていないか
- 過去の行動履歴から、次のアクションを予測・提案できないか
よくある質問
複雑さをゼロにすることはできますか？
できません。これがこの法則の核心です。どんなシステムにも「宛先を指定する」「送信ボタンを押す」といった最低限必要な操作（複雑さ）があり、それは誰かが負担しなければなりません。目指すべきは「複雑さをゼロにする」ことではなく、「ユーザーが負担する複雑さを最小化する」ことです。
複雑さを隠しすぎるとどうなりますか？
ブラックボックス化のリスクがあります。システムが裏側で処理しすぎると、ユーザーは「何が起きているか」を理解できなくなります。すると、エラーが発生した時に対処不能になったり、コントロール感を失って不安を感じたりします。特に重要な操作（送金、契約など）では、ユーザーに適切な確認ステップを残すことも重要です。
開発コストとのバランスはどう取るべきですか？
競合との差別化ポイントでは、システム側にコストをかけるべきです。住所自動入力のような「多くのユーザーが毎回使う機能」は、開発コストをかけてでもシステム側で複雑さを引き受ける価値があります。一方、ごく一部のユーザーしか使わない機能では、マニュアル操作を残しても許容されます。
KISSの原則と矛盾しませんか？
矛盾しません。KISS（Keep It Simple, Stupid）は「設計をシンプルにする」ことを目指しますが、テスラーの法則は「ユーザーの負担を減らす」ことを目指します。ユーザーにとってシンプルに見せるために、裏側の設計が複雑になることは許容されます——むしろ推奨されます。
まとめ
- テスラーの法則: どんなシステムにも削減できない複雑さがあり、誰かが負担しなければならない。
- 設計原則: できる限りシステム側が複雑さを引き受け、ユーザーの負担を最小化する。
- 活かし方: 自動入力・デフォルト値・文脈予測で「ユーザーが考える・入力する・探す」負担を肩代わりする。
- 注意点: 隠しすぎるとブラックボックス化し、重要な操作では確認ステップを残すことも大切。
次に読む
- ヒックの法則とは？ — 選択肢が多いほど判断に時間がかかる心理法則
- 認知負荷とは？ — 脳のワーキングメモリと情報処理量の設計
- 入力の負担を減らす（フォーム設計） — フォームの入力項目を最小化するUI原則
- デフォルト値を設計する — 初期値設計で判断負担を減らすUI原則
