Geb's Moon Logo

Geb's Lab

「マニュアルのいらないUI」とは何か

6/14/2026

良いUIの条件として「マニュアルのいらないUI」がよく言われます。 ユーザーがマニュアルを見なくても使い方がわかるUIのことです。 iOSのUIなどが具体例としてよく挙げられます。

しかし、どうすれば「マニュアルのいらないUI」になるのかは、自明ではありません。 「iOSにマニュアルがいらない」というのはなんとなく納得できます。 逆に、ずっとマニュアルが手放せないツールも、確かにあります。 しかし、その決定的な差が何なのかは、なかなか言語化できません。

「マニュアルのいらないUI」とは、いったい何なのでしょうか？

書籍『モードレスデザイン 意味空間の創造』と『オブジェクト指向UIデザイン――使いやすいソフトウェアの原理』を読んで、この問いに対する回答が自分の中ではっきりしました。 本記事では、両書の議論を手がかりに、「マニュアルのいらないUIとは何か」を、iOSや電子レンジなどの具体例を使って自分なりに再構成します。

マニュアルのいらない状態

「マニュアルのいらないUI」であるためには、道具を構成する対象と関係が画面に現れ、ユーザーがそこへ直接働きかけられる必要があります。 道具の構造がそのまま画面に現れ、直接操作できること 例えばiOSのUIでは、アプリ、それが並ぶホーム画面、アプリを入手するストアなど、道具を構成する対象とその関係がそのまま画面に現れています。 ユーザーは、アプリをタップして開いたり、掴んで移動したり、ストアから入手してホーム画面に追加したりできます。 UIが用意した操作手順を覚えて実行するのではなく、画面上に存在する道具の構造へ直接働きかけられます。

道具の構造を直接操作できると、ユーザーは使いながら、その構造と関わり方を体得できます。 道具の構造を直接操作できると、ユーザーは使いながら、その構造と関わり方を体得できます。 例えばアプリをタップし、アプリが開く様子を見ることで、「アプリは開くことのできる対象である」とわかります。 アプリを掴んで動かし、画面上の配置が変わる様子を見ることで、「アプリはホーム画面上を移動できる対象である」とわかります。 ストアからアプリを入手し、それがホーム画面やアプリライブラリに現れる様子を見ることで、ストア、アプリ、ホーム画面の関係がわかります。 このように、使うこと自体が、道具の構造と関わり方を学ぶことになります。

こうして構造と関わり方を理解すると、目的ごとの手順を個別に暗記しなくても、画面を手がかりに達成できるようになります。 その構造の範囲にある目的を、画面を手がかりに達成できるようになります 「アプリを開きたい」と思ったら、画面に並んでいるアプリを押せばよい。 「新しいアプリが欲しい」と思ったら、アプリを入手する場所であるストアへ行けばよい。 操作方法を忘れたり、初めての操作をする場合でも、画面上に表れている道具の構造を手がかりに操作を組み立てられます。

この「使いながら道具の構造と関わり方を理解し、画面を手がかりに操作を組み立てられる状態」が、「マニュアルのいらない」状態です。 マニュアルが要らなくなる過程 マニュアルのいらないUIでも、初めは道具の構造や基本的な関わり方を知るために、説明やマニュアルが必要になることがあります。 しかし一度基本的な関わり方を理解すれば、その後は対象を見て、働きかけ、その変化を確認する中で、さらに理解を深めていけます。 一度使い始めた後は、マニュアルに戻らなくても、画面上の構造との相互作用を通じて使い続けられるのです。

『モードレスデザイン 意味空間の創造』では、この状態を「道具とユーザーの間にインターフェイスが存在しない」状態というように表現しています。

ヒューマンインターフェースデザインの一番重要なテーマは（中略）ヒューマンインターフェースの概念が不要になる場所を見極めることである。ヒューマンインターフェースは、使用者と処理機能を繋ぐものとしてではなく、行為者と行為対象の境界を透過的にするものとして捉えなければならない。

——上野学『モードレスデザイン 意味空間の創造』、p.189

マニュアルが手放せない状態

逆に、マニュアルが手放せないUIでは、UIが道具の構造をインターフェイスの裏に隠しています。 電子レンジのオートメニュー 例えば電子レンジは、加熱の強さと加熱時間という2つのパラメータを動かす構造の道具です。 しかし多くの電子レンジでは、それらとは別に、「お弁当あたため」「牛乳」「さしみ解凍」といったオートメニューが提示されます。 オートメニューを選んだ後、電子レンジがどのように強さと時間を決めるのかは、画面に現れません。 道具の構造はオートメニューの裏側に隠され、ユーザーから切り離されています。

道具の構造に直接触れないと、ユーザーは道具の構造ではなく、指示と結果の対応関係を覚えなければなりません。 指示と結果の対応関係を覚える 例えば、「お弁当あたため」は、どのくらいの大きさや量のお弁当に使えるのか、「牛乳」は、何ミリリットルを、どのような容器に入れた場合を想定しているのかを知る必要があります。 望む温かさに加熱するために、ワット数や時間を直接指定するのではなく、「この目的にはどのオートメニューを選べばよいか」を判断しなければなりません。 これらは電子レンジの動きを構成する要素そのものではなく、UIが用意した指示と、その指示がうまく働く条件との対応関係です。 ユーザーは道具との関わり方を体得する代わりに、インターフェイス固有の翻訳規則を学ぶことになります。

指示と結果の対応関係は指示ごとに異なるため、一つの関係を覚えても、別の関係を推測できません。 指示ごとに独立した対応関係 「お弁当あたため」を何度使っても、「牛乳」や「さしみ解凍」が、どのような条件で適切に働くのかはわかりません。 このように、あるメニューについて得た経験が、別のメニューを理解するための構造として再利用されません。 そのため、ユーザーは目的やメニューごとに、指示と結果の対応関係を個別に学習しなければなりません。 これでは、使うこと自体が電子レンジ全体への理解につながらず、経験が積み上がりにくいのです。

その結果、未知の操作や久しぶりの操作を行うたびに、マニュアルが必要になります。 記憶にない操作をするたびにマニュアルが必要 記憶にないオートメニューでは、どのような食品や量を想定しているのかを画面から推測できません。 電子レンジの動きや、メニューが成立する条件が手がかりとして画面に現れていないため、ユーザー自身で操作方法を組み立て直すことも難しいです。 そこでユーザーは、目的に対応するメニューと、その正しい使い方を、再びマニュアルから探さなければなりません。 この「使っても道具との関わり方を体得できず、目的のたびに指示方法を調べ直す状態」が、マニュアルが手放せない状態です。

『モードレスデザイン 意味空間の創造』では、この状態を避けるべき理由を的確に表現しています。

デザイナーは特定された用途に対応するように機能をデザインしようとする。特にソフトウェアにおいては、その用途に対して目的合理性の高い複数の処理をひとつのボタンで実行できるようなインターフェースが考案される。しかしそこで実際に起こることは、用途がはっきりしたボタンほど使用者にとっては理解しづらいものになるということだ。限定的な用途に向けて作られたボタンほど、それはデザイナーの限定的な先入観に従って動作する。その分、使用者の先入観との間にズレが生じるのである。デザインにおいて「気の利いた工夫」はつねに「余計なお世話」になる恐れがある。より便利にしようとして却って扱いづらいものにしてしまう。だから、気の利いた工夫を加えようとする前にまず、動かしたとおりにただ動く（あるいはそのように感じられる）ものを作るべきだ。

—— 上野学『モードレスデザイン 意味空間の創造』、p.402

ここまでで、マニュアルのいらないUIと、マニュアルが手放せないUIの違いは確認できました。 では、「道具の構造を直接触れる」UIは、どのように作るのでしょうか？

道具の構造を直接触れるUIの条件

ソフトウェアのUIにおいて「道具の構造を直接触れる」ようにすることは、実は「言うは易し、行うは難し」です。 情報空間にある構造を自分で画面に表さなければならない ソフトウェアの場合、構造が情報空間の中にしか存在せず、そのままでは知覚も操作もできません。 構造をユーザーが直接触れるようにするには、情報空間の中に作った構造を、エンジニアが自分の手でUIに表現することが必要です。 この表現を誤ると、簡単に「構造の直接操作を邪魔する」UIになってしまいます。

この課題を解決する方法論の一つが、「オブジェクト指向UI (OOUI) 」の設計手法です。

書籍『オブジェクト指向UIデザイン』では、オブジェクト指向UIの原則として、次の4つが挙げられています。本記事では、これらを「道具の構造を直接触れるUI」の条件として捉えます。

  • オブジェクトを知覚でき直接的に働きかけられる
  • オブジェクトは自身の性質と状態を体現する
  • オブジェクト選択→アクション選択の操作順序
  • すべてのオブジェクトが互いに協調しながらUIを構成する

—— ソシオメディア株式会社ほか『オブジェクト指向UIデザイン――使いやすいソフトウェアの原理』、p.11

iPhoneのホーム画面は、この4条件を満たしています。 iPhoneが4条件を満たしている 操作対象であるアプリがアイコンと名前を持って画面上に現れ、通知やダウンロードの状態もアプリ自身に表示されます。 ユーザーはまずアプリを選び、それから開く、移動する、削除するといった操作を行います。 アプリはホーム画面上に並び、フォルダに入れればその内側に表示されるため、対象同士の並列関係や包含関係も空間として理解できます。

このように対象と関係を画面に表現することで、ユーザーは道具の構造へ直接働きかけられます。 オブジェクト指向UIデザインの具体的な設計方法は、別記事 「使いやすいUIを作る最強の方法『オブジェクト指向UIデザイン』」 で実例を使って紹介しています。 より体系的に学びたい場合は、『オブジェクト指向UIデザイン』を参照してください。

最後に、「マニュアルが手放せないUI」の典型的なパターンを、この4条件に照らして改善してみます。

マニュアルが手放せないTODOアプリを改善する

ここからは、架空の「マニュアルが手放せないTODOアプリ」を、OOUIの4条件に照らして改善してみます。

バリデーション結果が、作成ボタンを押すまで表示されない

このTODOアプリでは、入力内容に問題があっても、「作成」ボタンを押すまで何も表示されません。 作成を押すまでわからないルール タイトルが空欄だったり、期限に過去の日付が入力されていたりしても入力欄は変化せず、作成時に初めてエラーダイアログが表示されます。 ユーザーはダイアログの文章から問題のある項目を読み取り、フォームへ戻って修正しなければなりません。

これは、第二条件の「オブジェクトは自身の性質と状態を体現する」を満たしていません。 入力欄自身が、現在の値を受け付けられるのか、どの制約に違反しているのかを示していないからです。 そのためユーザーは、入力欄を見て状態を判断する代わりに、「タイトルは必須」「期限は今日以降」といった入力規則と修正手順を覚える必要があります。

改善するには、バリデーション結果を該当する入力欄自身に、即座に表示します。 バリデーションを即表示 タイトルが空欄ならその入力欄の近くに必須であることを示し、期限が不正なら理由と修正方法を期限欄の近くに表示します。 入力を修正すると表示も即座に変化するようにすれば、ユーザーは規則を暗記せず、入力欄の反応を見ながらTODOを完成させられます。

「削除」を選んでから、削除するTODOを指定する

このTODOアプリでは、先に画面上部の「削除」ボタンを押し、その後で削除するTODOを選びます。 削除を選んでから対象選択 ユーザーは削除したいTODOを起点に操作を探すのではなく、「削除するときは最初に上部のボタンを押す」という手順を覚えなければなりません。 操作方法を忘れてTODOの周囲を探しても、削除にはたどり着けません。

これは、第三条件の「オブジェクト選択→アクション選択」と逆の順序です。 このUIでは、「削除する」という動詞を先に選び、後から対象となるTODOを指定します。 そのためユーザーは、TODOに何ができるかではなく、削除機能をどこから呼び出すかを記憶することになります。

改善するには、削除操作を各TODOに付随させます。 対象を選んでから削除 TODOを選択すると操作メニューが現れる、横へスワイプすると削除が現れる、詳細画面から削除できる、といった方法が考えられます。 まず削除したいTODOを選び、その対象に可能な操作として削除を選べれば、ユーザーは対象を起点に操作方法を探せます。

完了にしたTODOが、即座に画面から消える

このTODOアプリでは、TODOに完了マークを付けると、そのTODOが一覧から即座に消えます。 完了後即座に消えて見失う 完了したことを示す見た目の変化や、移動先の表示はありません。 初めて操作したユーザーは、完了したのか、削除されたのか、操作に失敗したのかを判断できず、完了したTODOを見直す場所も覚えなければなりません。

これは、第二条件と第四条件を満たしていません。 TODO自身が「未完了から完了へ変わった」という状態を示さず、未完了TODOと完了TODOの関係や移動先も画面上に表現されていないからです。 操作前後の構造が断絶しているため、ユーザーは自分の操作と結果を対応づけられません。

改善するには、TODO自身に完了状態を示し、その後の行き先も見えるようにします。 状態可視化 チェックや取り消し線によって同じTODOが完了状態へ変化したことを見せ、同じ画面内の「完了済み」領域へ移動させます。 別画面へ移す場合も、移動したことを通知し、その場から移動先を開けるようにすれば、ユーザーはTODOがどうなったのかを画面上の変化から理解できます。

TODOの作成が、複数画面のウィザードに分割されている

このTODOアプリでは、新しいTODOを作るために、複数の画面を決められた順序で進む必要があります。 ウィザード型で作るTODO 最初の画面でタイトルや期限を入力し、次の画面でプロジェクトを選び、さらに次の画面でタグを設定します。 作成中のTODO全体はどの画面にも現れないため、ユーザーは現在どこまで設定したのかを一覧できず、内容を確認したり修正したりするたびに、ウィザードを前後しなければなりません。

これは、第二、第三、第四条件を損なっています。 作成中のTODOが、現在のタイトル、期限、プロジェクト、タグといった自身の状態を一つの画面上に体現していません。 また、プロジェクトとの紐付けを変更したい場合も、TODO上のプロジェクト情報を選ぶのではなく、ウィザード内の「プロジェクトを選ぶ画面」まで移動する必要があります。 さらに、TODOにプロジェクトやタグが紐づくというオブジェクト同士の関係も、画面上の構造として表現されていません。

改善するには、最初に作成中のTODO全体を表示し、複雑な操作だけをダイアログへ分離します。 構造が見える部分編集 タイトルや期限はその画面上で直接入力できるようにし、プロジェクトとタグは現在の設定状態を同じ画面内に表示します。 プロジェクト欄を選ぶと紐付け用のダイアログが開き、タグ欄を選ぶとタグ付け用のダイアログが開くようにします。 これにより、TODO自身が現在の状態を示し、対象を選んでから操作する順序になり、TODOにプロジェクトやタグが紐づく構造も画面から理解できます。

おわりに

「マニュアルのいらないUI」とそれ以外を分ける決定的な差は、「道具の構造をUIが隠しているか/いないか」でした。 「マニュアルのいらないUI」とは、道具とユーザーの間にインターフェイスが存在しないように感じるUIです。 逆に、マニュアルが手放せないUIでは、UIが道具の構造をインターフェイスの裏に隠しています。

ところで最近、この「道具の構造を後ろに隠すUI」が新たに大量発生しています。

それは、「AIエージェントとの対話型UI」です。 AIエージェント、すなわち何らかの作業をAIに指示して行わせるシステムでは、往々にして、AIエージェントというインターフェイスの裏に作業対象（道具の構造の大部分）が隠されます。 これは、AIに任せることで便利になる一方で、先に述べたように、ユーザーが道具の構造を理解し、目的に向かって使い方を考える機会を奪うことになります。

「AIエージェントの対話型UI」の問題点と改善方法については、別の記事でご紹介します。

参考文献

  • 上野学『モードレスデザイン 意味空間の創造』ビー・エヌ・エヌ、2025年。
  • ソシオメディア株式会社・上野学・藤井幸多 著、上野学 監修『オブジェクト指向UIデザイン――使いやすいソフトウェアの原理』技術評論社、2020年。