AIエージェントを試作するときは、ユーザーの指示をLLMへ送り、モデルが返したツール名を実行し、その結果をもう一度モデルへ渡すだけでも十分に動作する場合があります。数十行のコードで検索、メール作成、データ取得などを組み合わせれば、従来のチャットボットより自律性の高い体験を短期間で実現できます。しかし、この仕組みを実際の顧客業務や社内オペレーションへ投入すると、モデル性能とは別の問題が急速に増えます。ツール呼び出しが途中で失敗したらどこから再開するのか、同じ支払処理を二回実行しないためにどうするのか、長時間タスクの状態をどこへ保存するのか、ユーザーAの権限をユーザーBのエージェントが誤って使わないようどう隔離するのかといった問題です。こうした「エージェントを継続的かつ安全に実行するための仕組み」を受け持つのがエージェントランタイムです。

長期間運用されているデジタル製品では、最初から意図的に不統一な画面を作っているわけではなくても、機能追加、組織変更、納期優先の改修、ブランド刷新、担当者交代、技術移行などが積み重なることで、少しずつデザイン上の不整合が生まれます。同じ役割のボタンなのに高さが違う、似た意味の色が複数登録されている、設定画面だけ古いナビゲーションを使っている、あるフォームではエラー表示が丁寧なのに別のフォームでは技術的な文言しか表示されない、といった小さな差異が代表例です。一つひとつは致命的な問題に見えなくても、製品全体へ広がるとユーザーの学習負担が増え、チーム側では修正箇所や判断基準が増えるため、開発速度と品質の両方を下げる原因になります。

デザイン負債監査では、こうした問題を感覚的に「古い」「統一されていない」と指摘するだけではなく、どこに、どの種類の問題が、どれだけ存在し、何を原因として発生しているのかを体系的に確認します。画面の見た目だけではなく、コンポーネント、デザイントークン、文言、ナビゲーション、情報構造、アクセシビリティ、デザインファイル、実装コード、ドキュメント、レビュー方法まで対象にすることで、表面的な症状だけではなく、負債を生み続けている構造そのものを見つけることができます。

Webサイトやアプリを利用する人は、年齢、身体能力、視力、聴力、認知特性、利用している端末、入力方法、通信環境、利用場所などがそれぞれ異なります。同じ画面を見ていても、マウスで操作する人、キーボードだけで操作する人、画面読み上げソフトを利用する人、拡大表示を利用する人では、必要となる設計上の配慮が変わります。

ユニバーサルデザインシステムは、こうした違いを例外として後から処理するのではなく、最初から多様な利用条件を想定してUI、コンテンツ、コンポーネント、実装ルールを構築する考え方です。一部の画面だけを使いやすくするのではなく、製品全体で一貫した利用しやすさを再現できる状態を目指します。

特に複数のデザイナーや開発者が参加するサービスでは、個人の知識や善意だけに依存すると品質にばらつきが生まれます。そこで重要になるのが、利用しやすさを設計資産として体系化し、繰り返し利用できるデザインシステムへ組み込むことです。

1. 誰もが利用できる体験を設計の出発点にする

ユニバーサルデザインシステムを構築するとき、最初に考えるべきなのは特定の画面やボタンではありません。利用者が置かれるさまざまな条件を想定し、その条件が変化しても主要な操作を完了できる設計にすることが重要です。

ウェブサイトやアプリケーションが一般的なマウス操作で利用できても、すべての利用者が同じように目的を達成できるとは限りません。キーボードだけではメニューを開けない、読み上げソフトでは入力欄の目的が分からない、文字を拡大すると申込みボタンが画面外へ隠れる、色の違いだけでエラーを示しているといった問題があれば、一部の利用者は情報を理解できず、手続を完了できません。画面の一部が読みにくいという軽微な問題に見えても、ログイン、購入、予約、申請などの主要経路を完全に遮断する場合があります。

アクセシビリティ監査とは、ウェブサイト、アプリケーション、文書などが、多様な身体・感覚・認知・操作条件を持つ利用者にとって、知覚可能、操作可能、理解可能であり、支援技術を含む環境で堅牢に動作するかを評価する活動です。WCAG 2.2は、これら四つの原則の下に達成基準を整理したウェブアクセシビリティの国際的な技術標準です。WCAG 2.2は2023年10月5日にW3C勧告として公開され、フォーカスが隠れないこと、ドラッグ操作の代替、操作対象の大きさ、認証支援などに関する達成基準が追加されました。

ウェブアプリケーションを開いた直後は軽快に動作するのに、一覧と詳細を何度も往復する、モーダルを繰り返し開閉する、検索条件を変更する、画像を切り替えると、少しずつ画面が重くなることがあります。スクロールが引っ掛かり、文字入力が遅れ、ファンが回り始め、最終的にはタブが応答しなくなる場合もあります。このような問題は、一回の操作確認や短時間の性能計測では見つけにくく、長時間利用される業務システム、管理画面、チャット、地図、動画編集、画像処理などで深刻になりやすい特徴があります。

JavaScriptは、作成されたオブジェクトが不要になれば、ガベージコレクションによって自動的にメモリを回収します。しかし、自動管理だから開発者がメモリを意識しなくてよいわけではありません。不要になった画面やデータへ、イベントリスナー、タイマー、グローバル変数、購読処理、閉じたウィンドウなどから参照が残っていれば、ブラウザーはそのオブジェクトが今後も使われる可能性があると判断し、回収できません。MDNも、JavaScriptの自動的なメモリ管理は、開発者がメモリ管理を考慮しなくてもよいという誤解を生みやすいと説明しています。

AIは、従来の条件分岐型システムとは異なり、同じ種類の入力に対して常に完全に正しい結果を返すとは限りません。画像を分類するAIは複数の候補の中から最も可能性が高いものを選び、需要予測AIは将来値を一定の幅で推定し、生成AIはもっともらしい文章を生成します。画面上に一つの答えだけを断定的に表示すると、利用者はAIが確実な事実を提示していると誤解する可能性があります。一方で、すべての出力へ細かな確率や警告を付ければ、情報量が増え、利用者が何をすべきか分からなくなることもあります。

AI信頼度可視化とは、モデルが出力する得点をそのまま割合として表示することではありません。モデルがどの程度不確実であるか、その数値が現実の正解率とどの程度一致しているか、どの代替候補が存在するか、利用者が確認・修正・保留すべき状況かを、判断可能な形で伝える設計です。GoogleのPeople + AI Guidebookでは、信頼度表示として数値、高・中・低などの区分、上位候補、予測区間などが紹介されていますが、細かな信頼度が利用者の行動に影響しない場合や、誤解を生む場合には表示しない選択も必要だと説明されています。

角丸は、現在のウェブサイト、スマートフォンアプリ、業務システム、デザインシステムなどで広く使われている視覚表現です。ボタン、カード、入力欄、画像、通知、モーダル、タグなど、多くの部品で四隅をわずかに丸めるデザインが採用されています。しかし、角丸は単に画面を柔らかく見せるための装飾ではありません。角の半径を変えることで、部品の境界、操作可能性、情報のまとまり、視覚的な強さ、ブランド印象なども変化します。

角を丸くすれば、すべての画面が使いやすくなるわけではありません。半径が小さすぎれば、直角との差がほとんど分からず、設計上の意味を持ちません。反対に、すべての部品へ大きな角丸を適用すると、ボタン、カード、入力欄、通知などの役割が似て見え、情報階層が弱くなることがあります。複数の部品が隣接する表や一覧では、角丸によって不要な隙間が生まれ、情報密度や比較のしやすさが低下する場合もあります。

縦方向のリズムと横方向のリズムは、利用者インターフェースの整然さ、読みやすさ、情報の見つけやすさを支える基本的なレイアウト設計です。縦方向のリズムは、行間、段落間隔、見出し前後、カードの上下余白、セクション間隔など、画面を上から下へ読み進める際に繰り返される間隔の規則を表します。横方向のリズムは、列幅、左右余白、要素間隔、グリッド、文字列の整列、ボタン群の配置など、画面を左から右へ見たり比較したりするときの規則を表します。

画面内の各要素を個別に美しく整えても、縦横の間隔に共通性がなければ、全体として落ち着かない印象になります。ある見出しの下は24ピクセル、別の見出しの下は27ピクセル、似たカードの左右余白が画面ごとに異なると、利用者は意識していなくても構造を把握しにくくなります。逆に、一定の基準から間隔を組み立てると、利用者は繰り返される規則を自然に学習し、どこからどこまでが一つの情報なのか、どの要素が同じ階層なのかを素早く理解できます。

シャープUIとソフトUIは、利用者インターフェースの印象を大きく左右する二つの代表的な表現方向です。シャープUIでは、直線、直角、小さな角丸、明確な境界、強いコントラスト、密度の高い配置などを使い、正確さ、機能性、速度、専門性を感じさせます。一方、ソフトUIでは、大きな角丸、穏やかな配色、広い余白、柔らかい影、曲線的な部品を使い、親しみやすさ、安心感、軽さ、気軽さを表現します。

しかし、シャープな画面は使いにくく、柔らかい画面は使いやすいという単純な関係ではありません。金融取引、分析、業務管理、開発支援などでは、情報を厳密に比較できるシャープな構造が適している場合があります。反対に、健康管理、学習、交流、生活支援などでは、利用者の緊張を和らげるソフトな表現が製品目的と合うことがあります。重要なのは、見た目の好みではなく、どの印象と操作特性が利用者の目的を支えるかを考えることです。