Share
Embed
Slide 1
Slide 1 text
AI に Inclusive UI を書かせよう
— Design Rules Skill で Compose UI を作り直す
bami / テオリア‧テクノロジーズ DroidKaigi 2026
Slide 2
Slide 2 text
資料を公開しています
このQRから、スライドを⼿元で⾒ながら聞けます
※QRコードはデンソーウェーブの登録商標です。
2
Slide 3
Slide 3 text
⾃⼰紹介
bami
テオリア‧テクノロジーズ
— アプリエンジニア
合同会社 CoBrews — 代表社員
（クラフトビール販売）
X: @rs_bami ‧ GitHub: @bami-oxaliser
3
Slide 4
Slide 4 text
テオリア‧テクノロジーズ株式会社
「認知症との向き合い⽅を、テクノロジーで変えていく」
認知症にかかわるすべての⼈が、
⾃分らしくいられる ための「羅針盤」になる
エーザイグループのデジタル事業会社として 2023 年に設⽴した、
ブレインヘルステックの会社
4
Slide 5
Slide 5 text
プロダクト「ササエル」
MCI（軽度認知障害）‧認知症の当事者と
介護者のためのコミュニケーションアプリ
使うのは、当事者‧ご家族‧医療関係者
⽇常のご様⼦を記録し、診察での会話を⽀
える
※「ササエル」は医療機器ではありません
5
Slide 6
Slide 6 text
認知症へのやさしさは、全ユーザーに響く
年齢や体調によって、UIが「⾒えにくい‧操作しづらい」と
感じる場⾯は誰にでもある
そうした場⾯に直⾯する⼈は、あなたのアプリの中にも必ずいる
6
Slide 7
Slide 7 text
AI に Inclusive UI を
書かせる仕組みを作った
7
Slide 8
Slide 8 text
Before / 今
After / 聞き終わったら
AI に、
ルールを渡さずに UI を
書かせている
AI に、
ルールを渡して、やさしい UI を
書かせている
8
Slide 9
Slide 9 text
アジェンダ
A.
問題の所在 — 「それっぽい」は、「やさしい」ではない
B.
経緯と背景 — 『認知症の⼈にもやさしいデザインの⼿引き』と輪読会
C.
Skill 設計 — AI に読ませるルールの作り⽅
D.
Compose 実装 — 実コードと録画デモ
E.
Skill を育てるループ — ⼿動‧⾃動‧CI で確かめて、ルールを強くする
F.
まとめ
9
Slide 10
Slide 10 text
A. 問題の所在
素のAIは"それっぽく"書ける。
ただし、やさしいUIではない
Slide 11
Slide 11 text
ただし"それっぽい"は"保証"されていない
① 未検証 — "綺麗に⾒える"は"読める"の保証ではない。
読める下限を WCAG が 4.5:1 と定めているが、AI は計算して確かめない
② 運任せ — 同じ依頼でもプロンプト‧モデルの引きで揺れる
WCAG 2.2 コントラスト最低限（1.4.3）∕ 実測でも semantics を保つ⽣成と落とす⽣成があった
11
Slide 12
Slide 12 text
なぜこうなるのか
AI が最適化しているのは 「⾒た⽬で良さそうに動く UI」
（⾃由に書かせたときは標準部品‧状態保持まで⾃然に書く）
ただし⽬に⾒えない層は、指⽰しなければ抜ける
①コントラスト⽐の計算 ②⾒出しを意味づけ（TalkBack ⽤） ③⼤画⾯で作り直す
「⾒た⽬ OK」≠「基準を満たすと確認済み」
12
Slide 13
Slide 13 text
「トイレ」のピクトグラム理解度
92
⼀般（点）
→
35
認知症（点）
福岡市『認知症の⼈にもやさしいデザインの⼿引き』（令和5年9⽉ 第2版）
p.36「ピクトグラム理解度調査」（認知症の⼈97名‧2019年）
13
Slide 14
Slide 14 text
つながっていない2つの世界
AIコーディングの普及
⇔
認知特性のある
ユーザーの増加
書ける AI と、伝わるルールが、まだ別々に存在している
出典＝認知症‧MCI 有病率の将来推計（厚⽣労働省研究班∕九州⼤学 ⼆宮利治教授ら‧2024年公表）。
認知症‧MCI とも今後増加が⾒込まれる
14
Slide 15
Slide 15 text
accessibility は、後回しにされがち
「リリース優先で、あとで」→ その "あとで" は、たいてい永遠に来ない
理由の⼀つは、何をどうやればいいか具体的に分からないから
15
Slide 16
Slide 16 text
ルールを AI に渡して、書かせる
⼿法⾃体はありふれている（CLAUDE.md やルールファイルと同じ）。
肝は"中⾝"（何を渡すか）と"検証"（どう確かめるか）
16
Slide 17
Slide 17 text
B. 経緯と背景
なぜ
『認知症の⼈にもやさしいデザインの⼿引き』
だったのか
Slide 18
Slide 18 text
起点は、社内の輪読会で読んだ⼿引き
アプリユニットで、福岡市の⼿引きを輪読
もとは施設や住まいなど物理空間向け
（DSDC＝英‧スターリング⼤学の協⼒）
毎回 「うちのアプリだったらどうなるか」 に引き当てて
アクションカード化
出典：福岡市『認知症の⼈にもやさしいデザインの⼿引き』
（発⾏：福岡市福祉局 ⾼齢社会部 認知症⽀援課∕令和5年9⽉ 第2版）
18
Slide 19
Slide 19 text
認知症の当事者の⾏動は、3つの要因で起きる
個⼈の内⾯
物理的な環境
社会的な環境
物理的な環境＝アプリ UI ＝ユーザーの⾏動環境
『認知症の⼈にもやさしいデザインの⼿引き』第2章「認知症の⼈の⾏動や⼼理状態」（P.4）
19
Slide 20
Slide 20 text
「うちのアプリには関係ない」と思いますか？
認知症という取りこぼされがちな起点から設計する ＝ Inclusive Design
その原理が Universal Design
限定的な⼊⼝の⼯夫が、全ユーザーに広がる
Inclusive Design（⽅法）
→
Inclusive UI（成果物）
⽀える原理 ＝ Universal Design
Inclusive Design Principles（7原則‧⽇本語訳あり）∕
Universal Design＝Ronald Mace「⼀つの設計で全員に」の原理（7原則）
20
Slide 21
Slide 21 text
⼿引きの基本：2つの考え⽅の上に、5つの視点
① 記憶に頼らず⾏動できる空間づくり
— その場の⼿がかりで分かる
② 安⼼して⾃分で選べる居場所づくり
— 迷わず、間違えても戻れる
⼿引きの5視点
アプリでの配慮
A ⾊‧明度
コントラスト
B サイン
⽂字併記‧ことば
C 明るさ
テーマ∕ダークモード追従
D 親しみ‧安⼼
現在地‧戻れる安⼼
E 安全な屋外
危険な操作からさりげなく守る（破壊的操作の確認）
『認知症の⼈にもやさしいデザインの⼿引き』第3章「デザインの基本的な考え⽅」「5つの視点」（P.6〜）
21
Slide 22
Slide 22 text
第4章：改善前 → 改善後の実例
改善前
改善後
『認知症の⼈にもやさしいデザインの⼿引き』第4章「デザインの導⼊実践例」
（堤公⺠館‧城南区∕2019年導⼊‧P.28〜31）
22
Slide 23
Slide 23 text
トイレの認識率
13%
→
100%
出典＝『認知症の⼈にもやさしいデザインの⼿引き』第4章「認知症の⼈に対する調査の結果」
P.31（堤公⺠館‧城南区∕2019年導⼊‧回答者数30名）
サイン改善（強コントラスト＋⼤きなピクトグラム＋⽂字併記）による
23
Slide 24
Slide 24 text
なぜ改善前は伝わらなかったのか
⸺記号だけでは伝わらない
トイレの男⼥マーク単体の理解度＝⼀般92 / 認知症35（点）
「⾒れば分かる」記号が、伝わっていなかった
だから記号だけに頼らず、⾔葉を添える
出典＝『認知症の⼈にもやさしいデザインの⼿引き』第4章コラム「認知症の⼈にもやさしいピクトグラム理解度調査」P.36
（認知症の⼈97名‧2019年）。学習が必要な7サインの平均は⼀般91.8‧認知症57.8
24
Slide 25
Slide 25 text
認知症から始めた⼯夫が、みんなに届く UI になる
⼿引きが物理空間で実証した効果
（トイレ認識率 13%→100%∕記号の理解度 ⼀般92点‧認知症35点）
⾒えにくい‧伝わりにくい場⾯は、
加齢‧疲労‧⽚⼿での操作‧屋外の光が重なって誰にでも起こり得る
認知症の当事者
→
Inclusive Design（⽅法）
→
Inclusive UI（成果物）
→
全員に届く
25
Slide 26
Slide 26 text
C. Skill 設計
AI が実装で使える Skill にする
Slide 27
Slide 27 text
公式ガイドも Skill も、あるにはある
公式ガイド（Material Design 3‧Android Accessibility）はある
＝AI も Android Knowledge Base 経由で引ける
公式 Skill もある（android/skills）
＝ただしアクセシビリティを主題にした Skill は無い
Google ⽅針「docs にあることは Skill 化しない」
＝我々が⾜す知識は docs に無い
Material Design 3∕Android Accessibility ガイド（developer.android.com）∕android/skills（2026-08 v1.0.7 実確認）
∕Google philosophy「Built for deprecation」2026-08
27
Slide 28
Slide 28 text
公開されている AI 向けリソースを調べた（2026年8⽉）
リソース
Compose 固有
認知負荷
実機検証
Web 向け a11y lint
（eslint-plugin-jsx-a11y 等）
✕
—
✕
material-3-skill
◎
✕
✕
aldefy / Meet-Miyani
○
✕
✕
inclusive-design-skills
✕
◎
audit
我々
◎
◎
◎
出典
eslint-plugin-jsx-a11y（Web 向け a11y lint）: https://github.com/jsx-eslint/eslint-plugin-jsx-a11y
material-3-skill（Ivan Morgillo）: https://github.com/hamen/material-3-skill
compose-skill（aldefy）: https://github.com/aldefy/compose-skill
compose-skill（Meet-Miyani）: https://github.com/Meet-Miyani/compose-skill
inclusive-design-skills（Owl-Listener）: https://github.com/Owl-Listener/inclusive-design-skills
WCAG＝公式の国際アクセシビリティ基準（個⼈ OSS とは権威レベルが異なる）
28
Slide 29
Slide 29 text
どれも「書いた時点のチェック」で⽌まっている
既存の多くは「書く時に基準と突き合わせる」
静的な準拠チェック（＝lint 型）
無いのは 実機（on-device）で動かして確かめる検証
material-3-skill ⾃⾝が README で
「ズレるかもしれない（"may drift"）」と明記
"may drift"＝material-3-skill README（"best-effort distillation … may drift as Google updates the spec"）
29
Slide 30
Slide 30 text
認知負荷を、Compose に落として、確かめて育てる
⼿引きにもとづく
認知負荷への配慮
Compose 固有への
落とし込み
実機で確かめて
育てる
この3つを、既存の上に⾜す
30
Slide 31
Slide 31 text
いまの Skill も、DESIGN.md も、捨てない
役割
内容
担い⼿
⾜す
認知負荷×Compose（コントラスト∕テーマ∕ナビ
∕⽂⾔∕エラー∕ピクト∕48dp）
我々
借りる
Material Design の⾒た⽬（トークン‧配⾊‧コン
ポーネント）
material-3-skill
乗る
Compose の⼟台（XML移⾏‧ナビ‧テスト環境）
android/skills
委譲
ブランドテーマなどの意匠
DESIGN.md
順位：inclusive の [must]（＝必ず守る⼀線） ＞ Figma‧DESIGN.md 忠実 ＞ 余計な装飾を⾜さない
31
Slide 32
Slide 32 text
Skill の全体像
inclusive-compose-skill/
── 自分で書く ──
├── .rulesync/
│
├── rules/
│
└── skills/inclusive-compose/
├── rulesync.jsonc
├── verification.md
├── .github/workflows/verify.yml
└── README.md・LICENSE
← Skill の単一ソース（ここを直す）
overview ＋ 14カテゴリ
SKILL.md ＝ いつ使うか
生成の設定
検証手順
CI（ドリフト検知＋connectedCheck）
（通常のリポファイル）
── npx rulesync@16 generate（生成物・触らない・delete:true）──
├── CLAUDE.md
Claude Code の入口
├── .claude/
rules ／ skills
├── .cursor/
rules ／ skills
└── .github/
copilot-instructions ／ skills
別リポ（借りる）── material-3-skill … Material Design 3 の見た目
32
Slide 33
Slide 33 text
ルールの中⾝
① ルールの中⾝
② Skill の仕組み ③ 検証と運⽤
Slide 34
Slide 34 text
ルールの全体像（14カテゴリ）
群
カテゴリ
⾒える‧読める
visual-contrast／visual-theme／color-semantics／pictogramicon／personalization
ことばで伝える
copy-language／signage／error-handling／notification-sound
操作できる
touch-accessibility／navigation／adaptive-layout
迷わせない
information-density／support
34
Slide 35
Slide 35 text
must と nice-to-have で階層化
# 情報の量（手引き：記憶に頼らせない）
## must
- 1画面1タスクを基本にする。関係ない情報を同時に出さない
- 選択肢は折り返して全文を見せる（切らない）
## nice
- 段階的開示（必要になったら追加情報を出す）
35
Slide 36
Slide 36 text
実物：ルール本体
# 情報の量（手引き：記憶に頼らせない）
## must
／
## nice
## Compose Text(choiceLabel)
// maxLines / Ellipsis で切らない＝全文が折り返る
var expanded by rememberSaveable { mutableStateOf(false) }
if (expanded) Text(detail)
// 必要になってから追加情報を出す
## 検証
フォントスケール 200% で全文が見切れないか確認
36
Slide 37
Slide 37 text
深掘り①コントラスト｜⼿引きの視点A
⼿引きの視点A『⾊（明度）の組み合わせ』
明度の差が⼩さいと、形や⽂字そのものを捉えにくくなる
アプリでは「主役の要素を背景から浮かせる」
「画⾯が変わっても背景の明るさを⼤きく変えない」
『認知症の⼈にもやさしいデザインの⼿引き』第3章「5つの視点」（P.6〜）∕実践例『床の⾊を統⼀する』P.29 に対応
37
Slide 38
Slide 38 text
深掘り①コントラスト｜Compose ではこう書く
[must] 文字・重要 UI と背景は 4.5:1 以上（大きな文字・太字は 3:1）
[must] 色は ColorScheme に集約
（画面ごとにハードコードしない・アプリルート＝画面間で一貫）
[must] 主役は 4.5:1 を検証して固定
（標準の配色ペア〔primary/onPrimary 等〕はトーン差50+で 4.5:1 を狙う
設計・公式の数値保証は無い／カスタム色・非対ロール・outline は保証外）
[nice] Theme Builder の contrast level（medium / high）を使う
38
Slide 39
Slide 39 text
深掘り②⽂⾔とエラー｜⼿引きの視点B
⼿引きの視点B『サインと⽬印の活⽤』（迷わないための道しるべ）
突き放した⾔葉は、何が起きたか‧次に何をすればいいかが分からず、
操作が進められなくなる
アプリでは
「ボタンは動詞にする」「エラーは原因と解決策をセットで⽰す」
『認知症の⼈にもやさしいデザインの⼿引き』第3章「5つの視点」（P.6〜）
39
Slide 40
Slide 40 text
深掘り②⽂⾔とエラー｜Compose ではこう書く
[must] ボタンは動詞（「送信する」）
[must] エラーは原因＋解決策をセット
[must] 「入力が不正です」
→「メールの形式が違います。@ が入っているか確認してください」
// Compose: TextField の isError と supportingText で解決策を提示
//
エラー文言は semantics にも載せて読み上げにも届ける
40
Slide 41
Slide 41 text
深掘り③ピクトグラムと⾊｜⼿引きの第4章
⼿引きの第4章＝サインとアイコンの伝わりやすさ
同じトイレのマークでも ⼀般92点∕認知症35点
＝⼈によって伝わり⽅が違う
アプリでは
「アイコンに⽂字を併記」「⾊‧⽂字‧アイコンの三重で伝える」
『認知症の⼈にもやさしいデザインの⼿引き』第4章コラム「認知症の⼈にもやさしいピクトグラム理解度調査」（P.36‧認
知症の⼈97名‧2019年）
41
Slide 42
Slide 42 text
深掘り③｜⼿引き由来とUI慣習を分けて書く
[must] アイコンには文字を併記する
← 手引き由来
[must] 色・文字・アイコンの三重で状態を伝える
← 手引き由来
[nice] 赤＝危険 / 緑＝完了 / 青＝情報
← 一般的なUI慣習・補助
// Compose: Icon(contentDescription) ＋ 隣に Text ラベル
//
状態は色以外（テキスト・形）でも必ず示す
42
Slide 43
Slide 43 text
Skill の仕組み
① ルールの中⾝
② Skill の仕組み
③ 検証と運⽤
Slide 44
Slide 44 text
ルールが良くても、description が曖昧だと呼ばれない
ルールに frontmatter（いつ使うか）を付けたもの＝Skill
description の⼀覧だけが常駐‧本⽂は使う時だけ読み込まれる
悪い例「Inclusive UI のルール集」→ 効く例「Compose で UI を書く‧直す時に使
う」
name: inclusive-compose
description: "… Compose の UI を書く・直すときは必ず参照する。"
targets: ["*"]
user-invocable: true
claudecode: { paths: ["**/*.kt", "**/*.kts"] }
44
Slide 45
Slide 45 text
1ソースから、rulesync が3ツールに配る
ルール本体 ＋ いつ使うかの設定
.rulesync/
↓
skill層
← 正はここだけ
npx rulesync@16 generate
SKILL.md（標準）
rules層
各ツール固有
↓
Claude Code
／
Cursor
／
GitHub Copilot
正は .rulesync の1か所‧rulesync が skill層＋rules層を3ツール分⽣成＝1か所直せば全部追従
（⾃分で書かず OSS）
受け取る側は SKILL.md の skill層＋各ツール固有の rules層の2層
3形式は"差別化"でなく「多くの⼈が使えるように」の配布形態
rulesync（dyoshikawa）: https://github.com/dyoshikawa/rulesync
45
Slide 46
Slide 46 text
検証と運⽤
① ルールの中⾝ ② Skill の仕組み
③ 検証と運⽤
Slide 47
Slide 47 text
検証⼿順も Skill に組み込む
ルールだけでなく「書いた後どう確かめるか」も持つ
満たしたかを AI に判定させず、
実⾏できる成果物（テスト＋チェックリスト）を出させる
書く → 確かめる → ルールを強くする を回す前提で設計
47
Slide 48
Slide 48 text
AI は、⽣成物のほうを直す
正である単⼀ソースと、⽣成された配布ファイルは⾒た⽬が同じルール
AI が読み込むのは配布ファイルのほう → 修正を頼むとそちらを直す
⽣成物は再⽣成で毎回作り直される＝直しは必ず消える
48
Slide 49
Slide 49 text
ソースと⽣成物がズレたら、CI が落とす
npx --yes rulesync@16 generate --check
# 再生成して差分が出れば CI が落ちる
1か所直せば全部に伝わるという仕組みを、CI が守る
49
Slide 50
Slide 50 text
では、実際に書かせてみる
Skill を渡した AI は、どんな Compose を書くか
→ 実機の Before / After で⾒てみる
50
Slide 51
Slide 51 text
D. Compose 実装
AI に書かせて、Inclusive UI に寄せる
Slide 52
Slide 52 text
このデモの実⾏条件
コードは AI（claude-opus-4-8）が書いた
（⼿編集は静⽌画撮影⽤の引数のみ‧挙動不変）
⽣成なので出⼒は毎回同⼀でない
＝今⽇は代表の1回分
（⾒えない層の差は何度⽣成しても同傾向）‧事前録画
録画端末＝Android 17（API 37）
会場で⾳が出せない→TalkBack は字幕（⾳声出⼒の表⽰）で⾒せる
今⽇扱わないもの：Autofill‧Gemini Nano の alt-text‧ダークモード
52
Slide 53
Slide 53 text
デモ：同じデザインを渡し、ルールの有無だけ変える
sasaeru の実 Figma 2画⾯（今⽇の記録∕レポート）を AI に渡す
naive＝ルールを渡さない素の⽣成 ∕ Skill＝作ったルールを渡した⽣成
デザイン⼊⼒は同じで、変えるのはルールだけ
⽣成コードは⼿元で gradle コンパイルを通して確認
53
Slide 54
Slide 54 text
⾒た⽬は再現される。
"やさしさの保証"は別物
元のデザインがきちんとしていれば、
naive も Skill も静⽌画はほぼ同じ。
差が出るのは、読み上げ‧選択‧エラーの残り⽅‧⼤きな画⾯。
54
Slide 55
Slide 55 text
画⾯1：今⽇の記録（record）
10問フォームの2問⽬‧選択肢はテキストの
カード
⾒るのは
選択肢の読み上げと戻るのふるまい
55
Slide 56
Slide 56 text
未選択の実物：naive も Skill もほぼ同じに⾒える
naive
skill
並べても違いはほとんど分からない
差は電話アイコンの⾊‧淡い橙の使
い⽅など軽微
使うと出る差は、
その前にコードに現れている
56
Slide 57
Slide 57 text
タッチ & 読み上げ｜原則
アイコンには⽂字を併記（もとは視点B「サインと⽬印の活⽤」∕裏づけは
第4章コラムの ⼀般92点‧認知症35点）
タップ48dp＝Material のタッチターゲット基準（⼿引きには無い）
選択を読み上げ‧装飾は読ませない＝Android のアクセシビリティ由来
57
Slide 58
Slide 58 text
naive のコード：選択が semantics に出ない
Box(Modifier.clip(shape).background(bg).border(...)
.selectableCardClick(onClick)) { Text(text, sc-camel-font-size = 20.sp) }
// sc-camel-selectable-card-click = clickable{...} ＝ 生の clickable
// role も選択状態も semantics に出ない
58
Slide 59
Slide 59 text
skill のコード：selectable＋role＋group＋48dp
Row(Modifier
.selectable(selected, role = Role.RadioButton, sc-camel-on-click = onClick)
.heightIn(min = 48.dp)
// タップ48dp
) { Text(text); if (selected) Icon(CheckCircle, sc-camel-content-description = null) }
// 親 Column に Modifier.selectableGroup()
// 選択チェックは"色以外"の手がかり
59
Slide 60
Slide 60 text
⾒える差：⾊以外の⼿がかり（CheckCircle）
naive（選択時）
skill（選択時）
naive は選択を⾊だけで表す
skill はチェックアイコンを⾜す
＝⾊覚に頼らず選択が分かる
60
Slide 61
Slide 61 text
⾒えない差：実機 TalkBack の読み上げ
naive ラベルだけ
skill 状態‧役割‧位置‧まとまりも
Android 17∕TalkBack 17.0.0 実測。会場で⾳が出せないため「⾳声出⼒の表⽰」の字幕で提⽰
61
Slide 62
Slide 62 text
【知識点】Predictive Back は naive でも効いている
naive も Skill も戻るを独⾃に処理していない＝両⽅とも効いている
効かなくなるのは、戻るをアプリ側で受け取ったとき
（BackHandler で progress を扱わない場合も）
既定有効＝Android 16（targetSdk 36）で何もしなくても効く
62
Slide 63
Slide 63 text
画⾯2：レポート（report）
⻑い説明⽂‧お名前は未設定‧送信ボタン
⾒るのは
⽂字サイズ‧画⾯の広さ‧エラー
63
Slide 64
Slide 64 text
実描画：fontScale 2.0 で残る課題は、⽂字ではなく配置
naive（fontScale 2.0）
skill（fontScale 2.0）
拡⼤追従は原則（最⼩16sp‧折返し‧固定
⾼さ禁⽌）を守れば Compose が担保
＝ Skill の差別化点ではない
両⽅に共通の窮屈さ： 帯が本⽂に重なる
‧ナビラベルが切れる
200% は等倍のデザインにもコードにも写
らない → Skill の検証ルール
＝fontScale 2.0 のスクショテストで描画
して確認
64
Slide 65
Slide 65 text
画⾯の広さ：引き伸ばさず、組み替える
広い画⾯は引き伸ばして埋めない。
広さに合わせて配置を組み替える
＝adaptive（⼤画⾯‧折りたたみ‧外部ディスプレイ）
Android 17 で「前提」に：
⼤きな画⾯では、向き固定‧リサイズ不可の指定を OS が無視する
（16 で導⼊ → 17 で外せなくなる）
65
Slide 66
Slide 66 text
adaptive 実描画：naive は伸びきる、skill は 2 ペイン
naive（幅900dp）
skill（幅900dp）
66
Slide 67
Slide 67 text
skill のコード：WindowSizeClass で組み替える
val expanded = WindowSizeClass.calculateFromSize(DpSize(maxWidth, maxHeight))
.widthSizeClass == WindowWidthSizeClass.Expanded
if (expanded) Row
else
{ … }
// ≥840dp：左右2ペイン・行長を保つ
Column { … } // 1列。順序は同じ
skill は画⾯幅を WindowSizeClass で⾒て、広いとき（Expanded‧≥840dp）だけ
1列→2ペインに組み替える（引き伸ばさず⾏⻑を保つ‧順序は変えない）
naive にこの分岐は無い＝そのまま横に伸びる
67
Slide 68
Slide 68 text
エラー｜原則
⼿引き「安⼼して選べる‧戻れる」
エラーは突き放さない
＝消さずに残す‧原因と次の⼀⼿‧出た瞬間に読み上げる
68
Slide 69
Slide 69 text
naive：Snackbar（親切だが⾃動で消える）
snackbarHostState.showSnackbar(
message = "レポートを送るには当事者様のお名前の登録が必要です",
sc-camel-action-label = "登録する",
duration = SnackbarDuration.Short,
// 自動で消える
)
// 文言は親切。だが semantics error 無し・自動消滅
69
Slide 70
Slide 70 text
skill：寄り添う⽂⾔＋出た瞬間に読み上げ、消さない
if (showNameRequiredError) Text(
text = "お名前が未設定のため、レポートを送れません。" +
"上の「当事者様のお名前」からお名前を登録してください。",
color = MaterialTheme.colorScheme.error,
modifier = Modifier.semantics {
sc-camel-live-region = LiveRegionMode.Polite; error(msg)
// 出た瞬間に読み上げ
},
) // 自動では消さず、名前登録まで残す
⽂⾔を「原因＋次の⼀⼿」に書き換える
表⽰と読み上げを同じ⽂字列にし、error＋liveRegion で TalkBack へ伝える
70
Slide 71
Slide 71 text
⾒える差：エラーが残り、
直し⽅まで⾒える
skill＝エラーがその場に残り、直し⽅まで
⾒える
naive＝Snackbar が⾃動で消え、
静⽌画にすら写らない
71
Slide 72
Slide 72 text
2画⾯ 総まとめ：静⽌画で⼤きく写る差は、この3つ
① 選択の CheckCircle
② エラーの永続
③ ⼤画⾯の2ペイン
72
Slide 73
Slide 73 text
Inclusive UIの半分は、
⽬に⾒えない。
Skill は、その層まで
AI に最初から書かせる
73
Slide 74
Slide 74 text
E. Skill を育てるループ
Skill は「書いて終わり」じゃない
Slide 75
Slide 75 text
⼿動検証は3⼿段
TalkBack
Font Scale 200%
読み上げの内容
⽂字の⾒切れ
Accessibility
Scanner
コントラスト‧タップ領域
‧ラベル
ツールは守備範囲が違う
Scanner は読み上げの中⾝までは⾒ない＝naive でも「提案なし」
そこは TalkBack で聞く
75
Slide 76
Slide 76 text
⾃動検証：semantics をテストでアサート
@Test fun 選択肢は選択状態を読み上げる() {
rule.onNodeWithText("自分で電話をかけた").assertIsSelected()
}
@Test fun タッチターゲットは48dpが確保される() {
rule.onNodeWithText("自分で電話をかけた").assertHeightIsAtLeast(48.dp)
}
@Test fun エラーにerrorセマンティクスが付く() {
rule.onNode(hasText("お名前が未設定", substring = true))
.assert(SemanticsMatcher.keyIsDefined(SemanticsProperties.Error))
}
76
Slide 77
Slide 77 text
⾃動検証②：コントラスト‧タップ‧ラベルをまとめてチェック
// 依存: androidx.compose.ui:ui-test-junit4-accessibility
@Before fun enableA11yChecks() {
composeTestRule.enableAccessibilityChecks()
} // 以降のアクション実行時に ラベル欠落・低コントラスト・48dp未満 を自動 fail
// 任意の時点で:
composeTestRule.onRoot().tryPerformAccessibilityChecks()
77
Slide 78
Slide 78 text
CI に組み込む＋ドリフト検知
# 単一ソース(rules/) → 生成 → 差分が出たら落とす
- run: npx --yes rulesync@16 generate --check
# ドリフト検知＝差分で exit 1
- run: ./gradlew connectedCheck
# accessibility テストを実機/エミュで
ルールとコード、両⽅の退⾏を CI が⾒張る
78
Slide 79
Slide 79 text
育てた実例：原則だけでは過剰装飾する
原則だけ版
skill
原則だけを渡すと、AI は「⽬⽴たせる」
を過剰に適⽤してデザインに無い装飾を
⾜す
skill は同じ「いま何問⽬か」を
読み上げに⾜して⾒た⽬は元のまま
検証で⾒つけ、 「デザインに無い装飾を
⾜さない」 の⼀⾏を後から明⽂化
79
Slide 80
Slide 80 text
育て続けられる
出発点は、 当事者のデータ
確かめているのは、まだ エンジニアと機械
80
Slide 81
Slide 81 text
F. まとめ
今⽇の話を、ふりかえります
Slide 82
Slide 82 text
3つの持ち帰り
① Skill 設計の型
輪読会で「なぜこのルールか」を⼈の側でそろえる → 単⼀ソース → 層設計 → 検証を Skill 本
⽂に
② Compose 固有の Inclusive UI 実装パターン
semantics / 48dp / ⽂字スケール / 戻る安⼼‧具体コードで
③ 書いて終わりにしない、育てるループ
⼿動 → ⾃動 → CI → ルール強化
82
Slide 83
Slide 83 text
GitHub で公開しています
https://github.com/theoria-tech/inclusive-compose-skill
rules層＝単⼀ソース14ファイル（認知症デザインの⼿引きをもとに）
→ ⽣成 → skill層＝Claude / Cursor / Copilot の3形式
⼿動＋⾃動＋CI の verification 同梱
3形式は"差別化"でなく配布形態
83
Slide 84
Slide 84 text
AI に Inclusive UI を書かせよう
84
Slide 85
Slide 85 text
認知症との向き合い⽅を、テクノロジーで変えていく
エンジニア
積極採⽤中
QR
QR
採⽤ページ
note
※QRコードはデンソーウェーブの登録商標です。
85
Slide 86
Slide 86 text
ありがとうございました
資料はこの QR から ∕ 質疑は Ask the Speaker で
※QRコードはデンソーウェーブの登録商標です。