AI時代の使いやすさは、見た目ではなく「状態を減らす」設計から生まれる

Hatched by naoya

Aug 25, 2026

1 min read

0 views

72%

「この画面、なんとなく使いにくい」と感じたとき、私たちはまず色、余白、ボタンの形、文字の大きさを疑う。だが本当に壊れているのは、見た目ではないかもしれない。ユーザーとAIエージェントを同時に苦しめている、もっと深い問題がある。

それは、状態が増えすぎることだ。

画面のどこにいるのか。何を選択したのか。入力内容は保存されたのか。権限はあるのか。途中まで進めた作業は残っているのか。人間はこうした状態を頭の中で推測しながら操作し、AIは文脈の中から一時的に再構成しようとする。どちらも、状態が見えないまま増えると、次の一手を間違える。

ここから、UIデザインとAIエージェントの設計は意外なほど近い問題として見えてくる。使いやすいUIとは、単に美しい画面ではない。利用者が現在の状態を正しく理解し、少ない負担で次の状態へ移れる環境である。そして優れたAIエージェントも、何でも覚えている存在ではない。重要な状態を壊さず、不要な状態を増やさず、検証可能な遷移を積み重ねるシステムである。

本当の敵は、機能不足ではなく状態の爆発である

プログラムを考えるとき、状態とは挙動に影響する動的なデータのことだ。メモリ上の変数、データベースの値、ファイルの内容、ログイン情報、処理の進行状況。いずれも、システムが次に何をするかを変える。

通常のプログラムでは、設計者が状態の更新を明示的に定義する。ある処理が成功すれば、次にどの値がどう変わるかが決まっている。理想化すれば、状態から次の状態への遷移はほぼ確実に成功する。そのため、処理を百回、千回と積み重ねても、全体として大きなものを構築できる。

生成AIを使ってコードや文書を段階的に変更する場合、この前提が崩れる。各変更が正しい確率を仮に九十五パーセントとすると、十回連続で正しく遷移する確率は約六十パーセントに下がる。百回なら、理論上はほとんど成功しない。実際には修正によって誤りが発見されることもあるが、変更を重ねるほど、見えない不整合が蓄積するという傾向は変わらない。

この問題を、単に「AIの精度がまだ低い」と説明すると、本質を逃してしまう。問題は一回の回答が間違っていることだけではない。AIが変更する対象の状態を正確に把握できないまま、次の変更を加えることにある。

たとえば、AIに「このフォームへ住所入力欄を追加して」と依頼したとする。AIは画面を編集できる。しかし、そのフォームがどの画面から呼び出されるのか、入力値がどこに保存されるのか、未保存状態をどう表示するのか、過去の住所データとの互換性があるのかを完全に把握しているとは限らない。一つの変更が、別の場所にある状態との依存関係を壊す可能性がある。

ここで重要なのは、コードの量ではない。状態と依存関係の量である。

小さな機能でも、複数の画面、権限、保存先、通知、履歴、例外処理が絡めば、変更すべき状態は急激に増える。反対に、機能が多くても、状態が少なく依存関係が明確なら、意外なほど安定して運用できる。

システムの難しさは、持っている機能の数よりも、同時に整合させなければならない状態の数で決まる。

「ルックアンドフィール」は、見栄えではなく状態の翻訳である

UIの使用性を考えるとき、「ルックアンドフィール」はしばしば表面的な美観の話として扱われる。色は適切か、文字は読みやすいか、ボタンは自然に見えるか。もちろん、それらは重要だ。しかし、UIにおける見た目の本当の役割は、装飾ではなく内部状態を人間が理解できる形に翻訳することにある。

保存が完了したなら、そのことが見える必要がある。入力エラーがあるなら、どの項目をどう直せばよいかが見える必要がある。処理中なら、待つべきなのか、再操作すべきなのかが分からなければならない。ボタンの色や配置も、結局は「今、この操作は可能か」「押すと何が起きるか」という状態を伝えるために存在する。

使いにくいUIは、利用者に多くの記憶を要求する。さっき何を選んだか、どの条件で検索したか、どこまで入力したか、前の画面で何を確定したかを覚えさせる。画面を移動するたびに状態が隠れ、利用者は頭の中でシステムを再構築しなければならない。

これは、AIに長い会話履歴を与えて「覚えておいて」と頼む状況に似ている。文脈を大量に渡すことは、必ずしも記憶を与えることではない。情報が存在していても、どれが現在の正しい状態で、どれが古い状態で、どれが参考情報なのかが区別されていなければ、判断の材料はむしろ不安定になる。

人間向けのUIでは、状態を視覚的に外在化する。AI向けのシステムでは、状態を構造化し、境界を明確にし、検証できる形で保存する。表現は違っても、設計原理は同じだ。

たとえば、ECサイトの注文画面を考えてみよう。カートに商品が入っている状態、配送先が確定した状態、支払い方法が選択された状態、注文が送信された状態は、それぞれ異なる。これらを一つの曖昧な「注文中」という状態にまとめると、ユーザーもエージェントも混乱する。

「配送先は確定済みだが、支払い方法は未選択」「決済処理中で、二重送信は禁止」「注文は完了したが、在庫反映を待っている」といった具合に、状態を分解して表現すれば、次に許される操作が明確になる。良いUIは、これを画面で行う。良いエージェント基盤は、これをデータモデルと操作制約で行う。

使いやすさの核心は、選択肢を増やすことではなく遷移を安全にすること

多機能な製品は、価値を増やすために機能を追加し続ける。しかし機能が増えると、状態の組み合わせも増える。編集途中で共有できるのか。共有後に編集できるのか。権限を変更したら、開いている画面はどうなるのか。通信が切れたとき、どの状態が正しいのか。

この組み合わせの増加は、単純な足し算ではない。二つの状態がそれぞれ三通りの値を取るなら、組み合わせは九通りになる。状態が十個になれば、理論上の組み合わせは膨大になる。人間のテストだけで全てを確認するのは難しく、AIに任せても、暗黙の依存関係が多ければ誤りの検出は難しい。

だから設計の目標を、「できることを増やす」から「安全に遷移できる状態を増やす」へ変える必要がある。

この視点から見ると、UIの良し悪しを判断する質問も変わる。

「このボタンは目立つか」ではなく、「押せる状態と押せない状態が区別できるか」。

「画面はすっきりしているか」ではなく、「利用者が自分の現在位置を推測せずに済むか」。

「機能は見つけやすいか」ではなく、「その機能を使った後、何が変わったか確認できるか」。

そしてAIエージェントに対しては、次のように問うことができる。

「この操作を実行できるか」ではなく、「実行前に対象の状態を検証したか」。

「長い文脈を渡したか」ではなく、「現在の正規状態を短く取得できるか」。

「変更を自動化できるか」ではなく、「失敗したときにどの状態まで戻せるか」。

ここから、システム設計のための簡単な原則が導ける。私はこれを状態予算と呼びたい。製品やワークフローには、ユーザーとAIが安全に扱える状態の上限がある。状態を追加するなら、何を削除し、何を統合し、どの依存関係を切るかを同時に決める。

状態予算を管理する具体的な方法は四つある。

第一に、一時的な情報と永続的な情報を分ける。画面上の選択状態、作業の途中経過、正式に保存された記録を同じ場所で扱わない。何が確定値なのかを明示する。

第二に、状態の所有者を一つにする。同じ情報を画面、ブラウザ、複数のサービスがそれぞれ保持すると、どれが正しいか分からなくなる。複製が必要なら、更新の責任と同期方法を定義する。

第三に、不可逆な遷移を減らす。送信、削除、公開、決済のような操作は、確認、取り消し、履歴、試行環境を用意する。AIに任せるほど、戻れる設計が重要になる。

第四に、状態を観察可能にする。ユーザーには表示、通知、履歴で伝える。AIには構造化された読み取り機能、検証結果、変更差分で伝える。見えない状態は、存在しないのと同じくらい危険である。

AIに「記憶力」を足すより、記憶しなくてよい環境を作る

AIに長期記憶を持たせることは魅力的だ。過去の会話、好み、作業履歴、組織のルールを蓄積すれば、より賢く振る舞うように思える。しかし、記憶が増えるほど、古い情報と新しい情報の衝突も増える。何が事実で、何が一時的な希望で、何がすでに無効になった指示なのかを判断しなければならない。

つまり、記憶は無料ではない。記憶を一つ追加するたびに、状態の候補と依存関係が増える。

より堅牢な発想は、AIを「覚えている主体」にすることではなく、必要な状態を必要なときに取得し、操作後に検証する主体にすることだ。会話の中に重要な情報を埋め込むのではなく、顧客情報、作業チケット、権限、進行状況をそれぞれ正規の場所に置く。AIはそこから現在値を読み、許可された操作だけを実行し、結果を記録する。

これは人間の働き方にも似ている。優れた外科医は、全てを暗記しているから安全なのではない。チェックリスト、画像、記録、役割分担、確認手順によって、個人の記憶に依存しないから安全なのである。使いやすいUIも、ユーザーに画面構造を暗記させない。状態を適切な場所に表示し、次の行動を自然に導く。

AI時代のインターフェースは、チャット画面だけではない。エージェントが扱う状態を、利用者とAIの双方にとって理解可能にする一連の仕組みである。たとえば、AIがプロジェクト管理ツールを操作するなら、単に「タスクを更新しました」と返すだけでは不十分だ。

どのタスクを対象にしたのか。変更前と変更後は何か。誰の権限で実行したのか。関連する期限や依存タスクに影響はあるか。失敗した場合、再実行しても二重登録にならないか。これらが見えれば、AIの出力は会話ではなく、検証可能な状態遷移になる。

ここでUIの美しさとAIの信頼性が交差する。整った画面とは、情報が少ない画面ではない。重要な状態が、誤解なく、適切なタイミングで、利用者の視界に入る画面である。同じことがAIにも言える。短い回答とは、情報を削った回答ではない。次の判断に必要な状態を、曖昧さなく提示する回答である。

今日から使える「状態中心設計」のチェックリスト

新しいUIを設計するときも、AIに業務を任せるときも、次の問いを使える。

Key Takeaways

現在の状態を一文で言えるか確認する
「編集中」「保存済み」「承認待ち」のような言葉で、システムの現在位置を表せるか。説明できない状態は、設計上も管理しにくい。
次に可能な操作を限定する
あらゆる操作をいつでも許すのではなく、状態ごとに許可された遷移を定義する。押せないボタンを隠すだけでなく、なぜ押せないのかも必要に応じて伝える。
一つの情報に一つの正規の保存先を与える
会話、画面、メモ、データベースに同じ情報を重複させない。複製する場合は、どれが原本かを決める。
変更の前後を見えるようにする
AIの編集でも人間の操作でも、差分、履歴、実行者、実行時刻を残す。結果だけを表示するより、検証可能性が大きく高まる。
機能追加の前に、状態予算を見積もる
新機能が増やす状態、依存関係、例外ケースを書き出す。そのコストを払えないなら、機能を減らすか、状態を統合してから実装する。