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