Design Decisions — app-admin — Round 1 (Variant A 保守)

生成: 2026-05-27 · Agent: kashi-ui-mockupper · Surface: /app/admin · Stage 3/3 · Variant pick: A 保守

このドキュメントの読み方: Variant A (保守) の mockup (index.html) が下した非自明な設計判断を 1 つずつトレースします。将来 Justine か実装担当エンジニアが「なぜ mockup は X をしたのか?」と問うときに、答えがここにあることを保証します。 A は visual / token cleanup のみの保守案で、 IA (情報構造) は現状維持 — B/C との位置づけ比較は §5 に。

1. A 概要 — Variant A の本質

決定: A は「11 アクション flat grid を維持しつつ、 token 統一 + 文言改訂で素人感を排除」する保守案である。

A の scope は意図的に狭い:

IA (Information Architecture) は変えない — Primary/Secondary/Tertiary の階層化 (B) や Inbox 一本化 (C) は しない。現状 11 アクションを並列のまま残す。
design_system_v1 トークンを 100% 適用 — 現状の濃緑カードと白カードの混在 (r19 §6.2 「Color semantics inconsistent」) を統一カードスタイルで解消。
第 2 段ラベルを operational 文言に改訂 — Longitudinal / Coverage / Readiness / Speakers は admin canon (§4 system admin = operational only) と矛盾するので、稼働状況確認 / データ品質 / 準備度チェック / 話者管理に書き換える。
H1 直下に light サブタイトル を追加 — B の full Scope Boundary Banner と違って、 1 行で「組織+利用状況管理」を控えめに示すのみ。

canon: permanent-ui-principles §1 「The UI wins by showing less」 (A レベルでの実装) / §13 visual system / design_system_v1 §1-§4 token spec

2. 11 アクション flat grid を維持した理由

決定: 11 アクションは 4 + 4 + 3 の flat grid のまま残す。 Primary/Secondary/Tertiary に再構造化しない。

理由:

A の存在意義は「IA 不変」にある。 Justine が 3 案を比較して「IA を変えるリスク」を取りたくない/取れない場合の最低限の改善が A。ここで 3 層化したら A の独自性が消える。
11 アクションは現状の admin の muscle memory 起点 — 既存パイロット顧客や Justine 自身が慣れ親しんだレイアウト。変更ゼロで token と文言だけ整える価値がある。
r19 §6.2 (Color semantics inconsistent) は IA を変えなくても解消できる — 全カードを --kashi-paper-tint 背景 + 1px border outline で統一すれば、視覚的優先度の混乱は十分解消される。

並べ方:

1 行目 (4 枚 / 組織構築系): チーム作成 · ユーザー管理 · 単発アップロード · 一括アップロード
2 行目 (4 枚 / operational 確認系): 稼働状況確認 · コミュニケーションポリシー · データ品質 · 話者管理
3 行目 (3 枚 / 運用ログ系): ジョブ監視 · 通知管理 · 準備度チェック

3 行目が 3 枚なのは 11 = 4 + 4 + 3 という現状の自然な分割を尊重した結果。 grid は 4 列のまま、 3 行目は左寄せで自然に並ぶ。

canon: permanent-ui-principles §7 progressive disclosure は A では PARTIAL — 11 並列は「3-5 cards」ルールを逸脱するが、 A は意図的にそれを残す (B の存在意義のため)

トレードオフ自覚: 11 並列は依然として「何から始めればいいか分からない」認知負荷を残す。 これは A の限界点であり、 B/C はこれを解決する。 Justine が「最初の改善は A で十分」と判断するか、「やはり認知負荷を解消したい」と感じるかは Round 1 共有後の質的 feedback で決める。

complaints.md C-A1 「11 並列認知負荷」未解決 / A の意図的限界

3. design_system_v1 token 適用箇所

A の主目的の 1 つは token 統一なので、ここを詳細に列挙します。全て design_system_v1.md の verbatim 値:

箇所	適用 token	解消する r19 課題
11 アクションカード背景	`--kashi-paper-tint` (#F7F8FA) を全カード統一	r19 §6.2 (濃緑/白混在 → 統一)
11 アクションカード枠線	`--kashi-border` (#E5E7EB) 1px outline	r19 §6.2 (枠あり/なし混在 → 統一)
カード内アイコン	`--kashi-evergreen` (#2F6B4A) + Lucide outline 1.5px stroke + 20px size grid (§7 iconography)	r19 §6.2 (アイコンの色・サイズ混在)
H1 (demo株式会社)	Fraunces 500 + 36px + `--kashi-evergreen-deep`	r19 (現状 Inter のみ → serif 統一)
H2 セクション見出し (管理アクション/チーム一覧)	Fraunces 500 + `--text-h3` (24px) + `--kashi-evergreen-deep`	r19 (H レベルの size 不揃い)
KPI 数値 (12 / 47 / 156)	Fraunces 500 + 32px + `--kashi-ink`	「数字が serious に読める」 (B との共通項)
カード hover	border-color → `--kashi-evergreen` · background → `--kashi-paper` · `--shadow-sm`	r19 (hover state 不揃い)
spacing 全体	card padding `--space-5` (24px) · card 間 gap `--space-4` (16px) · section 間 `--space-8` (48px)	r19 (8-point grid 違反箇所多数)
focus ring (全 interactive 要素)	`--shadow-focus` (0 0 0 3px rgba(47,107,74,0.4))	a11y baseline (§12)
radius	カード `--radius-md` (8px) · 内部要素 `--radius-sm` (4px) で統一	r19 (radius 値混在)
font stack	本文 IBM Plex Sans + Zen Kaku Gothic New · 見出し Fraunces · 数値・ラベル IBM Plex Mono	design_system_v1 §2 typography (現状未適用箇所)

canon: design_system_v1.md §1 color tokens / §2 type scale / §3 spacing / §4 radius+shadow+focus / §7 iconography / r19 §6.2 「Color semantics inconsistent」解消

4. 第 2 段ラベル改訂 (operational 文言への書き換え)

決定: 現状の admin home にある Longitudinal / Coverage / Readiness / Speakers の 4 ラベルを operational 文言に改訂する。 A 版でも厳守する。

改訂対応表:

旧ラベル	新ラベル (A 版)	改訂理由
`Longitudinal`	稼働状況確認	「縦断的分析」を連想させる → admin canon §4 「operational のみ」に違反。アップロード頻度・連続性の operational 監視であることを明示
`Coverage`	データ品質	「coverage 分析」と読まれる → transcript 品質・抜けチェック (data quality) という operational concern であることを明示
`Readiness`	準備度チェック	「Pilot readiness」という operational checklist を明示 (分析系の readiness ではない)
`Speakers`	話者管理	「Speakers analysis」と読まれる → speaker_aliases の operational config (alias 追加・未割り当て解消) であることを明示
`Communication Policy`	コミュニケーションポリシー (改訂不要)	すでに operational config を示しており、ラベル単独で誤解されない

各カードの __sub テキストにも「(集計のみ)」を 3 箇所明記し、個別 meeting 内容には飛ばないことを reinforce している。

canon: permanent-ui-principles §4 「System admin: operational configuration + technical logs」 / DATA_VISIBILITY_MATRIX §3 (admin = Pattern summaries N) / §8 (Bypass forbidden)

5. H1 直下 light サブタイトル (P-4 light 版)

決定: H1 (demo株式会社) の直下に 1 行のみの light サブタイトルを置く。 B 版のような full Scope Boundary Banner にはしない。

文言:

🛡 あなたは 組織と利用状況 の管理者です — ミーティング内容や個別パターンは表示されません (役割境界の詳細)

理由:

A の scope は「visual cleanup のみ」。 B の Scope Boundary Banner (恒久カード) は IA 寄りの変更なので A の範囲外。
とはいえ admin canon §4 に対する最低限の signal はないと「素人感」の Justine 不満 (C-A3 洞察誤読リスク) に部分対応できない。
そこで「banner」ではなく「subtitle」として実装 — visual hierarchy 上、 H1 の説明文として読まれる軽量さを保つ。
ShieldCheck icon (16px) + 主文 + 「役割境界の詳細」 link の 3 要素のみ。 B の Banner と違って padding なし・背景なし・border なし。

research: app-admin__references.html §3 P-4 Scope Boundary mention (light) / canon: permanent-ui-principles §3 Role Boundary First (light 適合) / Justine complaint C-A3 部分解決

6. A vs B 比較 (Justine 判断材料)

軸	A 保守 (本 mockup)	B 中庸
11 アクションの扱い	flat grid 維持 (4+4+3)	Primary 1 + Secondary 4 + Tertiary 6 に再構造化
Scope 表示	H1 直下 1 行サブタイトル (light)	H1 直下 full Banner (paper-tint 背景 + 3px border + icon + 本文 + footnote)
Setup checklist	常駐 (mockup では 3/4 完了表示)	Phase A 用に折りたたみ可、 Phase B/C では Primary CTA に切り替わる
Primary CTA	なし — 11 アクションすべて同 weight	あり (filled evergreen button、 phase 連動で動的)
第 2 段ラベル改訂	適用	適用
token 統一	100% 適用	100% 適用
3 段階構造 (P-3 3-Layer Action Architecture)	採用しない	採用
Tertiary 折りたたみ accordion	なし	あり (6 項目を default fold)
JS の量	1 関数 (TeamRow toggle のみ)	3 ブロック (phase switcher + accordion + TeamRow)
実装工数 (estimate)	S (2-3 日)	M (5-7 日)
r19 §6.2 解消	解消	解消
permanent-ui §7 (progressive disclosure)	PARTIAL — 11 並列は逸脱	PASS — 3-5 cards layer 準拠
permanent-ui §8 (cognitive load)	PARTIAL — equal-weight 残る	PASS — one primary CTA + grouped
Kashi 差別化 (SmartHR/カオナビとの対比)	弱 (見た目だけ改善、 banner なし)	強 (banner で構造的明示)

7. 採用した evidence-grade 表現

決定: admin home では evidence-grade badge を 使わない。

理由:

evidence-grade は pattern summary や signal に付くもので、 admin canon §3 (admin = Pattern summaries N) により admin home には pattern summary 自体が存在しない。
無理に grade を出すと「admin はやはり pattern を見られる」と誤読される逆効果。
代わりに operational state は文言で示す — 「集計のみ表示」「(集計のみ)」「サンプル」等。

tokens.css には --kashi-grade-* 6 色を verbatim で含めているが、 A 版 mockup では 使用しない。これは正しい canon 適合。

canon: DATA_VISIBILITY_MATRIX §3 (admin = Pattern summaries N) / design_system_v1.md §1 evidence-grade tokens (定義されているが admin 画面では未使用が正解)

8. 削った要素 (現状の Kashi から)

TeamRow 展開内の「最近のミーティングタイトル一覧」 — researcher §7 リスク 2 「admin がミーティング詳細に飛んでしまう動線」を回避。件数・日付範囲・平均時間・処理ソースの aggregate のみ表示。
第 2 段の英語ラベル (Longitudinal / Coverage / Readiness / Speakers) — §4 で詳述した通り、 admin canon §4 に違反するため operational 文言に置換。
個別 member 名指し signal カード (もし現状 mockup data であれば) — admin canon §3 違反。 mockup data 内には member 名なし、 manager_A〜D の placeholder のみ。
分析・洞察・メンバー発言系の CTA — 11 アクション中 0 件。検出済み。

9. 追加した要素 (現状にない)

H1 直下 light サブタイトル — §5 で詳述。 light P-4 patten。
KPI strip の drill-down リンク — 3 カードに「チーム一覧 → / ユーザー管理 → / アップロード履歴 →」を追加。 drill 先は全て operational page のみ (分析系には飛ばさない)。 P-2 pattern (Stripe R1 + Vercel R2 + GitHub R3 + Okta R4, N=4)。
TeamRow 展開内の Scope Note — 「集計のみ表示」を 2 行で明示 (上位 2 チームで表示、下位 3 チームは省略)。 admin canon の reinforcement。
Mockup meta banner (ページ最上部) — 「Round 1 / Variant A 保守 / 共有用」のレビュー context。実装時には消える。

10. 既知のトレードオフ / 未解決事項

1. 11 並列認知負荷は未解決 (C-A1)

A の意図的限界。 Justine が「実際に画面を見て、やはり認知負荷を解消したい」と感じたら B/C に切り替えるべき判断点。

2. permanent-ui-principles §7 (progressive disclosure) は PARTIAL のまま

11 並列は「default visible layer: 3-5 cards」ルールを満たさない。これは A の構造的限界で、 token 統一だけでは解決不能。

3. SmartHR/カオナビ-style HR surveillance dashboard との差別化が弱い

A の light サブタイトルだけでは「banner で境界を構造的に示す」 B の強さに及ばない。 Justine が co-founder/メンターに見せた時、「他社と何が違うのか」が一目で伝わりにくい可能性。

4. Setup checklist は常駐するが、完了後の next action が無い (C-A4)

A は「setupComplete=true で消える」既存実装のままを想定。 setup 完了後の admin の next move (Manager に Mirror URL 共有等) は B の Phase B/C で実装される。 A は意図的にここを残さない。

5. Round 1 mockup として「feedback 取りやすさ」はやや低い

A は変化が visual のみなので、 co-founder/メンターから「これって今と何が違うんですか?」という反応が出やすい。一方で「ちゃんと整っている」という第一印象は得られる。 Round 1 で「Kashi UI は仕様化されている」を demo 用に示したい場合は A が最適。

11. Justine の判断ポイント (A を pick する/しないの最終チェック)

A を採用するべきケース:

Round 1 で「visual だけ整える低リスク改善」を出して、既存パイロット顧客の muscle memory を壊さずに「素人感を排除した」と示したい
VC demo 用に「Kashi UI は token 統一されている」ことを示したいが、大きな構造変更は工数的に避けたい
B/C のメリットは認めるが、まず A で reaction を見たい (段階的改善)

A を採用しないべきケース:

11 アクション並列の認知負荷を Justine 自身が日常的に感じている → B
SmartHR/カオナビとの差別化を UI でも明示的に示したい → B (banner) または C (構造)
「admin 画面は根本的に何のためにあるのか」の方向性を co-founder/メンターと議論したい → C

12. 実装フェーズへの引き継ぎ (将来の React 実装エンジニア向け)

この mockup を Kashi (Next.js / React / Tailwind) に組み込む際の注意:

該当する Kashi コード

主ファイル: kashi/src/app/app/admin/page.tsx
テスト: kashi/test/app/admin/* + RLS テスト kashi/test/rls/admin-*
i18n: kashi/messages/ja.json + en.json の admin.* ネームスペース

影響を受ける共有コンポーネント

PortalHeader.tsx (replica は mockup 内、実装時は既存コンポーネント使用)
SetupChecklist.tsx または admin 専用 setup widget (現状実装の有無を確認)
KPI card component (既存 StatCard 等があれば再利用、なければ新規)
Action card component (11 個共通、既存 AdminActionCard がなければ新規)

必要な新規コンポーネント (A 版限定)

PageSubtitle.tsx (light Scope サブタイトル、 H1 直下の 1 行) — 他 surface でも再利用可能
共通 ActionCard の variant prop (現状の濃緑/白混在を排除した統一 outline style)

i18n 改訂が必要なキー

i18n key (推測)	旧 EN	新 JA (本 mockup)
`admin.actions.longitudinal`	Longitudinal	稼働状況確認
`admin.actions.coverage`	Coverage	データ品質
`admin.actions.readiness`	Readiness	準備度チェック
`admin.actions.speakers`	Speakers	話者管理
`admin.subtitle` (新規)	—	あなたは「組織と利用状況」の管理者です — ミーティング内容や個別パターンは表示されません

i18n verbatim test 影響 (LESSONS.md feedback_i18n_verbatim_test_pinning_governance 参照)

i18n の改訂は 39 test files での verbatim pinning に影響する可能性あり。 PR 前に npm run i18n:verify (pre-commit hook) を走らせること。 admin.actions.* を読んでいる test 全部を grep で洗い出す。

r19 既存課題のうち本案で同時解決されるもの

r19 §6.2 (Color semantics inconsistent) — token 統一で完全解消
r19 typography 系の指摘 — Fraunces + Plex Sans/Mono の正しい組み合わせ適用で解消
r19 spacing 違反 — 8-point grid (--space-*) で全 spacing 統一
r19 focus ring 未対応 — --shadow-focus 適用

r19 既存課題のうち本案では解決されないもの (B/C 待ち)

permanent-ui §7 progressive disclosure 不適合 — 11 並列は B の Primary/Secondary/Tertiary 化を待つ
permanent-ui §8 cognitive load 不適合 — equal-weight CTA spam は B/C で解決

responsive breakpoints (本 mockup の検証済範囲)

1280px+ (desktop): 4 列 grid、 KPI 3 列、 team detail 3 列 — primary 検証範囲
1100px 以下: 3 列 grid に縮約 (アクション数 11 を 3 列で 4+4+3 → 4+4+3 そのまま左寄せ)
920px 以下 (tablet): 2 列 grid、 KPI 3 列維持、 team detail 2 列
600px 以下 (mobile): 1 列 grid、 KPI 1 列、 PortalHeader 縦積み

a11y baseline (本 mockup 内で適用済)

1 H1 per page (demo株式会社)
logical heading order: H1 → H2 (管理アクション / チーム一覧) → H3 (パイロットを開始する / 運用中のチーム)
semantic HTML: <header>, <main>, <nav>, <section>
aria-label on icon-only buttons (サインアウト, role chip)
aria-expanded on TeamRow toggle button
focus-visible outline: 2px evergreen ring via --shadow-focus
color contrast: 全 text 4.5:1 以上 (--kashi-ink on stone-50, --kashi-evergreen-deep on cream)

13. canon 適合最終チェック

項目	判定	根拠
permanent-ui §1 「UI wins by showing less」	PARTIAL	token 統一で素人感は消えるが、 11 並列は残るので「showing less」は不完全
permanent-ui §3 Role Boundary First	PASS	H1 + role-chip + light サブタイトルで role + 不可視範囲を明示
permanent-ui §4 Visibility per Role (System Admin)	PARTIAL	operational 文言改訂は適用、ただし B/C と比べると境界明示が弱い
permanent-ui §7 Progressive Disclosure	PARTIAL	11 並列が default visible で 3-5 cards ルール逸脱
permanent-ui §8 Cognitive Load	PARTIAL	token 統一で hierarchy は改善するが、 equal-weight CTA spam は残る
permanent-ui §9 Dashboard Rules	PASS	個人スコア / 健康スコア無し、 KPI は組織レベル aggregate のみ
permanent-ui §11 Internal Screen Rules	PASS	role label + visibility (サブタイトル) + safe actions + audit リンク (footer)
permanent-ui §13 Visual System	PASS	off-white base + 濃緑 accent + Lucide outline icon、 surveillance imagery 無し
DATA_VISIBILITY_MATRIX §3 (Admin Pattern summaries N)	PASS	個別 pattern summary への CTA は 0 件 (検出済み)
DATA_VISIBILITY_MATRIX §8 (Bypass forbidden)	PARTIAL	light サブタイトルで「中身は見えない」を明示 (banner レベルではない)
design_system_v1 §1-§4 token 適用	PASS	100% verbatim 適用
design_system_v1 §7 iconography	PASS	Lucide outline 1.5px stroke + 16/20/24px size grid、 eye/surveillance/police icon 無し
「分析」「ミーティング詳細」「メンバー発言」系 CTA	CLEAN	11 アクション中 0 件、 KPI drill 先も operational のみ

判定総括: A は permanent-ui-principles の 8 項目中 4 PASS + 4 PARTIAL。 PARTIAL の 4 つは A が意図的に残した「11 並列 + light Scope」の構造的限界によるもので、これらを完全 PASS にしたい場合は B/C を採用する判断になる。 canon violation (forbidden CTA) は 0 件 — 安全に共有可能。

出典: app-admin__variants.html (Stage 2) · app-admin__references.html (Stage 1) · permanent-ui-principles.md §1-§15 · design_system_v1.md §1-§10 · DATA_VISIBILITY_MATRIX.md §1-§10 · kashi/src/components/portal/PortalHeader.tsx · LESSONS.md feedback_i18n_verbatim_test_pinning_governance