はじめに — 数値は教科書に載っている
シニア向けUIの数値は、もう公開仕様です。タップ領域は最小48px。コントラストはWCAG AA。本文は16pxから17pxあたり。見出しは本文の1.5倍。これらはApple HIGにもMaterial Designにもアクセシビリティガイドラインにも学術論文にも書いてあって、検索すれば数十秒で出てきます。だからこの記事に、コピーして使える数値表は載せません。
正直に書くと、私も最初は「数値を満たせばシニア向けになる」と思っていました。その思い込みが崩れたのは、72歳のらくらくフォン利用者に初回登録を試してもらったユーザーテストです。開発日記にはこう残しています。
1人での登録完了は不可能だった。付き添いのサポートがあって初めて完了
文字は大きかった。ボタンも大きかった。数値上は「シニア向け」を満たしていたのに、1人では完了できなかった。このとき気づいたのは、差がつくのは数値そのものではなく、その数値を「あったほうがいい指針」ではなく「絶対に手放さない拘束条件」として扱い続ける運用文化のほうだ、ということでした。この記事は、その文化の話です。
なぜ数値は差にならないのか
数値が公開仕様であることには、二つの含意があります。ひとつは、秘密にしても守れないこと。もうひとつは、知っていても差にならないことです。
ほとんどのチームは「48pxにすべき」を知っています。それでも実機でシニアが操作できないUIが量産されるのは、知識が無いからではありません。締切が迫ったとき、レビューで指摘されたとき、デザインの都合がついたとき、その数値が静かに「今回は例外」として手放されていくからです。知識はコモディティで、誰でも持てる。差がつくのは、その制約を手放させない仕組みと規律を組織が持っているかどうかでした。
以下は、私たちが特定の制約を「拘束条件」として扱い続けるために何をしたか、そしてそれがなぜ読んだだけでは身につかないのか、という話です。
拘束条件1: 「動いてしまう失敗」を見逃さない
最初の教訓は、らくらくフォンのシステムフォント拡大への対応で得ました。利用者が端末側でフォントを拡大していると、こちらが16pxのつもりで書いた本文が24px相当に膨らみ、レイアウトが崩れます。
clamp() で上限をかけようとして、最初の実装で罠を踏みました。これは、なぜこの種のバグを「拘束条件として潰す」のかをClaude Codeと言語化したやり取りです。
Zeronovaclamp() を入れて3値ともremで書いた。でも、らくらくフォンのフォント拡大設定にしても全然頭打ちにならない。普通のテスト環境では問題なく見えるんだが。clamp() は、システムフォント拡大時に3値とも同じ比率で膨らむため上限が一切効きません。しかも通常環境では正常に見えるので、ターゲットユーザーの端末でしか壊れません。「テストが通る」と「ターゲットで壊れない」が一致しない種類のバグです。Zeronovaこのやり取りで重要なのは clamp() の書き方そのものではありません。書き方はこの記事の主題ではなく、深掘りは別記事に分けてあります。重要なのは、「自分たちの環境では再現しない失敗」を、再現しないからこそ拘束条件として先に潰すという姿勢を組織の習慣にしたことです。数値を知っていても、この姿勢が無ければ同じ穴に落ちます。
拘束条件2: 自動評価を鵜呑みにせず、文脈で再評価する
私たちは設計知をチェックリスト化し、画面を機械的に評価する仕組みを持っています。便利ですが、ここに二つ目の拘束条件があります。チェックリストは判断の補助であって、判断そのものではない。これを規律として明文化しています。
象徴的だったのが色の扱いです。エラー表示の赤を、やわらかい色に変える評価が出ました。これは妥当でした。しかし評価はさらに「画面内のすべての赤を統一せよ」と踏み込んできた。ここで止まれるかどうかが文化です。安否確認画面の赤は、災害の深刻度を伝える意味を持った色です。穏やかにすると緊急性そのものが弱まる。エラーの赤だけを変え、意味のある赤は意図的に残しました。
開発日記には、自動評価の限界をこう残しています。
AIエージェントによるチェックリスト評価は「見落とし防止」に有効だが、文脈を理解した再評価が不可欠。今回P2・P3の5件中5件が再評価で判断変更になった。
5件中5件が、コードを読み直すとひっくり返った。ここで効くのは「ルールを守る」ことではなく「そのルールがこの場所で守るべきものかを読み取る判断」です。これは数値化できません。チェック項目に48pxと書くことはできても、「この画面ではスワイプが補助操作だから違反ではない」と読む判断は、項目の中には書けない。競合がチェックリストをコピーできても、この再評価の文化はコピーできないのは、それが成果物ではなく判断の蓄積だからです。
拘束条件3: 「管理者は操作に慣れている」という前提を許さない
三つ目の教訓は、自分たち自身が置いていた誤った前提から出ました。チェックリストを各画面に当てるとき、当初は「住民向け画面は厳しく、管理画面は管理者が操作に慣れている前提で緩めでよい」と線を引こうとしていたのです。一見もっともらしい区別でした。
それが誤りだと気づいたのは、誰が実際に管理画面を触るのかを具体的に思い浮かべたときでした。このプロジェクトの管理者は、自治会の理事です。輪番制で順番が回ってきた60代から80代の住民であって、ITに詳しいから管理者になったわけではありません。「管理者は操作に慣れている」という前提そのものが、最初から成り立っていなかった。
ここから決めたのは、住民向けと同じ水準のチェックリストを管理画面にも適用し、「管理画面は例外」を一度も許さない、という拘束条件でした。例外は一度認めると入口になり、そこから制約は静かに侵食されます。数値を知っているチームでも、「管理者は大丈夫だろう」という一見もっともらしい例外から崩れていく。崩さないのは知識ではなく、例外を許さないと決めた文化です。
拘束条件4: 利用者の言葉と恐怖を、こちらの都合より優先する
ユーザーテストで最も意外だったのは、数値ではなく言葉でつまずいたことでした。「LINEでログイン」のボタンの前で、手が止まったのです。開発日記にはこう書いています。
「ログイン」はシニアの語彙にない（YouTubeのログインも家族が代行している）
開発者にとって「ログイン」は空気のように当たり前の語です。しかし利用者の語彙には存在しなかった。ここで効いたのは「正しい用語を使う」ではなく「ボタンのラベルは技術的に正確である必要はなく、利用者の行動を示すものであるべき」という制約を、こちらの都合より優先すると決めたことでした。「LINEでログイン」を「登録をはじめる」に変える。同じ理屈で、登録途中の「本人確認」も、公的手続きを連想させて不安を煽るため「合言葉の入力」に変えました。機能はまったく同じで、変えたのは利用者が受け取る感情です。
ここには、もうひとつの拘束条件があります。安心は操作の「後」ではなく「前」に置く。操作してエラーが出てから「やり直せます」と伝えるのでは遅い。操作する前に「間違えても、いつでもやり直せます」と見せておく。エラーの色を、責められた印象を与える赤から、やり直しを促す穏やかな色に変えたのも同じ規律です。これらはどれも数値ではなく、「利用者の語彙と感情を、開発者の慣れより上に置く」という運用上の優先順位の問題でした。
自分たちの悪い修正を撤回できるか
文化が試されるのは、正しい修正をするときではなく、自分たちが入れた修正が間違っていたと気づいたときです。
「ログアウト」が通じないと分かったとき、最初は素直に「終了する」に変えました。ところが開発者レビューで、「終了する」は「アプリを閉じる」「退会する」と誤解される、と指摘を受けます。ここで「用語は変えたのだから一応対応済み」と流すこともできました。流さなかった。開発日記の学びにこうあります。
「ログアウト」→「終了する」は用語を変えただけで、意味が伝わっていない。シニア向けUXでは、操作の結果を具体的に説明する表現が必要。
用語を別の単語に置き換えただけでは意味は伝わらない。最終的に「このスマホでの利用を中断する」という操作結果を説明する表現に、確認ダイアログと目立たせない配置を組み合わせました。重要なのは着地点ではなく、自分たちの一手目を「不十分だ」と認めて撤回したことです。チェックリストや自動評価は「抵触」を教えてくれますが、「自分の修正が浅い」とは教えてくれません。それを認められるかどうかは、ルールではなく文化です。競合がUI/UXで弱いとき、その多くは知識ではなく、この「自分の修正を疑う習慣」が無いことに起因します。
直し方そのものを規律にする
拘束条件は「何を直すか」だけでなく「どう直すか」にも及びます。チェックリストが洗い出した課題のうち、操作の失敗を画面いっぱいのポップアップで知らせている箇所が多数ありました。これを画面内に静かに表示するエラーへ置き換える必要があり、対象は管理画面全体で多数に及びました。
ここで一度に全部直さなかったのは、意図的な規律です。開発日記にはこう残しています。
「実装→不具合チェック→修正→コミット」を1 Stepごとに繰り返すことで、不具合が蓄積しない。
まとまりごとに分割し、各まとまりで「実装し、不具合を確認し、修正し、コミットする」を1サイクルとして回しました。実際、最初のまとまりでエラー表示が領域外に出る不具合が見つかり、次のまとまりではキャンセル時の消し漏れが見つかった。一気に書き換えていたら、これらは混ざって切り分け不能になっていました。チェックリストは「何を直すべきか」を教えますが、「どう直すと安全か」までは書いてくれません。指摘が多いときほど修正を段階に割り、各段で検証してから次へ進む。これは成果物ではなく、運用の作法です。
同じ作法は、装飾の扱いにも及びます。タップできないカードに矢印アイコンが付いていたことがありました。実リンクは無いのに、押せそうに見える。シニア層は「タップしたのに反応しない、自分の操作が間違ったのか」と困惑します。装飾のつもりの要素が利用者に嘘の期待を与えるなら撤去する。見た目と動作を一致させることを、装飾より優先する。これも数値ではなく、何を優先するかという文化です。
拘束条件を生かし続ける機械
これらの拘束条件は、意志だけでは続きません。手放させないための仕掛けがあります。
ひとつは、チェック項目に必ず根拠を紐づけていることです。「なぜこのルールなのか」が切り離されたルールは、例外に直面した瞬間に形骸化します。根拠が同梱されていると、例外時に「機械的に従う」か「理解した上で外す」かを選べる。もうひとつは、基準値の正となる定義をコード側の一箇所に集約し、判断を一点伝播にしていること。さらに、実際のシニアに触ってもらう反復を回し続けること。72歳の利用者が1人で完了できなかったあの結果は、机上では永遠に出てこなかった数字です。
これらの仕掛けの設計思想は、それぞれ単独の記事に分けてあります。研究知見をどう運用資産に翻訳したかは21の学術研究を開発で使えるチェックリストに変換した話に、避けるべきパターンの具体はシニア向けUIで避けるべきパターンに、用語の言い換え運用はシニア向けUIでカタカナ語を全廃した話に、プロジェクト全体の判断は自治会DXで学んだシニア向けWebアプリ開発の設計判断にあります。
ここで正直に書いておきます。これらをすべて読んでも、運用文化はインストールできません。チェックリストの全文も、コード側の定義も、テストの台本も、この記事には載せていません。理由は秘密だからではなく、それらは「採用するだけ」の成果物であって、渡しても受け取った側に文化は生まれないからです。文化は、締切の前で制約を手放さなかった回数と、手放しそうになって踏みとどまった判断の蓄積でしか育ちません。
なぜ多くのチームは手放してしまうのか
競合がUI/UXで弱いのは、たいてい知識が無いからではありません。三つの理由のどれかです。第一に、締切圧の下で制約が「あったほうがいい指針」に格下げされる。第二に、数値だけ知っていて、その根拠が切り離されているため例外に直面すると判断できず形骸化する。第三に、自分たちの開発環境で再現しない失敗を、再現しないがゆえに拘束条件に組み込めていない。
どれも、数値を渡せば解決する問題ではありません。だから私は、この記事に数値表を載せないことに迷いがありませんでした。数値は誰でも30秒で手に入る。手に入らないのは、それを拘束条件として扱い続ける運用文化のほうです。そして文化は、記事を読んでコピーできるものではありません。
むすび
シニア向けUIの設計で学んだ一番大きなことは、技術ではなく姿勢でした。「48pxにする」と「48pxを締切の前でも手放さない」は、まったく別の難易度の問題です。前者は知識で、誰でも持てる。後者は文化で、回数でしか育たない。
らくらくフォン利用者が1人で登録を完了できなかったあの日から、私たちの問いは「どの数値にするか」ではなく「どうすればこの制約を例外なく守り続けられるか」に変わりました。数値は公開仕様です。隠す意味はありません。本当に守るべきは、それを拘束条件として扱い続ける運用そのものでした。
関連記事
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。