UI Proposal — app-admin

制約	出典	UI への含意
Admin は Pattern summaries / Per-meeting metrics / Team aggregates すべて N	DATA_VISIBILITY_MATRIX §3	Longitudinal / Coverage / Readiness 等の分析系サブページへの直リンクは admin home から構造的に除去または再フレーミング
System admin = operational configuration + technical logs のみ	permanent-ui-principles.md §4	「分析」「洞察」「メンバー発言」系 CTA は禁止。「稼働準備」「データ品質」「アクセス管理」系 CTA で再構成
Bypass forbidden — 「admin will eventually look」を構造的に防ぐ	DATA_VISIBILITY_MATRIX §8 / WORKER_FACING_TRUST_CANON §2.6	UI 上で「あなた (admin) はミーティングの中身を見ることができません」を 1 文で明示 (Scope Boundary Banner)

Variant A — 保守的 (Visual / Token Cleanup)

SCOPE: visual only 実装工数: S (2-3 日)

一文要約

現状の 11 アクション flat grid と IA は完全に維持しつつ、 design_system_v1 トークン適用と r19 §6.2 「Color semantics inconsistent」解消で「素人感」を排除する保守案。

主タスク (page の primary job)

現状と同じ: 「テナント管理者がテナント全体の状態を一目で把握し、ユーザー追加 / チーム作成 / アップロード / 稼働準備チェックへジャンプ」。主タスクの定義は変えない。

レイアウト構造 (above-fold composition)

┌─────────────────────────────────────────────────────────────────┐
│ PortalHeader (現状維持)                                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  管理ダッシュボード                              [role: admin]   │  ← H1 (Fraunces, --text-h1)
│  ──────────────────────────────                                  │
│  あなたは操作設定のみを管理します                                  │  ← 推奨追加 (P-4 light)
│                                                                 │
│  ┌─チーム数─┐ ┌─メンバー数─┐ ┌─ミーティング数─┐               │  ← KPI strip (P-2)
│  │   12   │ │    47    │ │     156      │   ← --text-h2     │
│  │ →一覧   │ │ →一覧     │ │ →処理状況     │   ← drill link    │
│  └────────┘ └──────────┘ └──────────────┘                       │
│                                                                 │
│  [現状チェックリスト 4 ステップ — 未完了時のみ表示、 完了で消える]│
│                                                                 │
│  ─── 管理アクション ──────────────────────────                   │  ← H2
│  ┌──────────┬──────────┬──────────┬──────────┐                 │
│  │チーム作成 │ユーザー  │単発      │一括      │  ← 4 col, 統一 │
│  │          │管理      │Upload    │Upload    │     style       │
│  └──────────┴──────────┴──────────┴──────────┘                 │
│  ┌──────────┬──────────┬──────────┬──────────┐                 │
│  │稼働状況   │コミュ    │データ    │話者管理  │  ← 4 col 統一  │
│  │確認       │ポリシー  │品質      │          │     文言改訂   │
│  └──────────┴──────────┴──────────┴──────────┘                 │
│  ┌──────────┬──────────┬──────────┐                            │
│  │ジョブ     │通知      │準備度    │  ← 第 3 段、 統一 style   │
│  │監視       │管理      │チェック  │                            │
│  └──────────┴──────────┴──────────┘                            │
│                                                                 │
│  ─── チーム ──────────────────────────────────                  │
│  [TeamRow x 5 — 既存仕様維持、 展開 detail のミーティング       │
│   タイトル列は件数表示に絞る (リスク 2 回避)]                    │
│                                                                 │
│  ─── 直近ミーティング ───────────────────────                    │
│  [RecentMeetingsList — 既存仕様維持]                            │
│                                                                 │
│  [フッター: 免責 + governance リンク]                            │
└─────────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	適用方法	研究参照
P-2 KPI strip with drill-down link	3 stat cards に drill-down リンクを追加。ただし「ミーティング数」のリンク先は `/app/admin/upload` (operational) — 分析系は NG	app-admin__references.html §3 / Stripe R1 + Vercel R2 + GitHub R3 + Okta R4 (N=4)
P-1 Setup checklist as dismissible card	既存実装をそのまま維持 (Kashi は既に `setupComplete` フラグで OK)	§3 / Stripe + Okta + Google WS + B2B UX (N=4)
(Light) P-4 Scope Boundary mention	H1 直下に 1 行サブタイトルとして「あなたは操作設定のみを管理します」を追加 (banner レベルではない、軽量版)	§3 / Stripe + GitHub + Okta + Google WS (N=4)

design_system_v1 トークン適用箇所

全アクションカードを --kashi-paper-tint 背景 + --kashi-border 1px outline で統一 (現状の濃緑/白混在を解消、 r19 §6.2)
H1: --text-h1 + Fraunces + --kashi-evergreen-deep
H2 (セクション見出し): --text-h2 + Fraunces + --kashi-evergreen
カード内ラベル: --text-body, 数値: --text-h2
spacing: --space-5 (card padding) + --space-6 (section gap) + --space-8 (block separation)
icon: Lucide outline 1.5px stroke、 20px size grid (現状 mixed の解消)
focus ring: --shadow-focus 適用 (a11y baseline)

permanent-ui-principles 適合チェック

§	判定	根拠
§3 Role Boundary First	PASS	H1 直下に admin role 表示 + サブタイトルで「操作設定のみ管理」を 1 行明示
§4 Visibility per Role (System Admin)	PARTIAL	第 2 段「稼働状況確認」「データ品質」等は operational 文言に改訂 (現状の Longitudinal / Coverage / Readiness ラベルは NG)。ただし B/C と比べると境界明示が弱い
§7 Progressive Disclosure	PARTIAL	11 アクション flat grid は依然として「default visible layer 3-5 cards」ルール (§7) を逸脱。 A の限界点
§8 Cognitive Load	PARTIAL	token 統一で「all equally important」感は改善するが、 11 アクションの並列は残る
§9 Dashboard Rules	PASS	個人スコア / 健康スコア類は登場せず、 KPI は組織レベル aggregate (チーム数 / メンバー数) のみ
§11 Internal Screen Rules	PASS	role label + visibility 明示 + 安全 actions + audit semantics 既存維持
§13 Visual System	PASS	off-white base + 濃緑 accent + outline icon、 surveillance 系アイコン無し

DATA_VISIBILITY_MATRIX 適合チェック

Admin に表示: 自テナントの組織構造数値 (チーム数 / メンバー数 / ミーティング件数) — これは structural metric ではなく count なので OK
Admin に表示しない (除去): ミーティングタイトル一覧 (TeamRow 展開で件数 only に変更)、個別 pattern summary、個別 member 名指しシグナル — 全て現状から除去
第 2 段アクションの文言改訂 (canon §4 適合):
- 「Longitudinal」 → 「稼働状況確認」 (アップロード頻度 / 連続性のチェック)
- 「Coverage」 → 「データ品質」 (transcript 品質 / 抜けチェック)
- 「Readiness」 → 「準備度チェック」 (パイロット要件達成状況)
- 「Communication Policy」 → そのまま (operational config)
- 「Speakers」 → 「話者管理」 (speaker aliases の operational config)

解決される Justine の不満 (researcher 推察)

C-A2 解決: token 統一でスタイル混在 (濃緑/白) が完全解消
C-A3 部分解決: 第 2 段の文言改訂で「分析を見に行く」誤読を回避
C-A5 部分解決: KPI strip に drill-down リンク追加で「だから何をすべきか」を補強
C-A1 未解決: 11 アクション並列の認知負荷はそのまま (A の限界)
C-A4 未解決: セットアップ完了後の「次のステップ」案内は現状維持

残るリスク / 未解決事項

11 アクションの並列は依然として「何から始めればいいか分からない」課題を残す (B で解決)
Scope Boundary は H1 直下サブタイトル止まり — banner レベルの明示は B/C で実現
r19 §6.2 (Color semantics) は解消されるが、 §7 progressive disclosure と §8 cognitive load の本質的解決にはならない

Canon Violation 検出

CLEAN 「分析」「ミーティング詳細」「メンバー発言」系の CTA は 0 件。第 2 段の現状ラベル (Longitudinal / Coverage / Readiness) は operational 文言に改訂済み。

Variant B — 中庸 (3-Layer Action Architecture + Scope Banner)

SCOPE: IA reorganization 実装工数: M (5-7 日)

一文要約

11 アクションを Primary 1 / Secondary 4 / Tertiary 6 の 3 層に再構造化し、 H1 直下に Scope Boundary Banner を恒久配置。「Admin はミーティングの中身を見られない」を視覚化することで Kashi 差別化を実装レベルで担保する推奨案。

主タスク (page の primary job)

"テナント運用の next step を 1 つだけ提示し、 admin がそれ以外で迷わない" — pilot phase に応じて Primary CTA が動的に切り替わる。例: setup 未完了時 → 「セットアップを完了する」、 setup 完了時 → 「Manager に Mirror URL を共有する」、定常運用時 → 「今週の稼働サマリ確認」 (operational 集計のみ)。

レイアウト構造 (above-fold composition)

┌─────────────────────────────────────────────────────────────────┐
│ PortalHeader (現状維持)                                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  管理ダッシュボード                              [role: admin]   │  ← H1
│                                                                 │
│  ╔═════════════════════════════════════════════════════════════╗│
│  ║  Scope Boundary Banner (恒久表示、 dismissible でない)        ║│  ← P-4
│  ║                                                             ║│
│  ║  あなたは [組織と利用状況] の管理者です。                       ║│
│  ║  ミーティングの中身、 メンバー個別のパターン、 シグナルは       ║│
│  ║  この画面からは閲覧できません — これは canon です。            ║│
│  ║                                                             ║│
│  ║  → 詳細は データ可視性マトリクス §3 / §8                      ║│
│  ╚═════════════════════════════════════════════════════════════╝│
│                                                                 │
│  ┌─チーム─┐ ┌─メンバー─┐ ┌─処理件数─┐                          │  ← KPI strip
│  │  12  │ │   47   │ │   156   │   (drill = operational のみ) │
│  └──────┘ └────────┘ └─────────┘                              │
│                                                                 │
│  ───────── 今すぐやるべきこと ────────────                       │  ← H2 (Primary)
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  ✓ パイロット稼働中 (setup 完了)                          │   │  ← P-1 evolved
│  │                                                          │   │
│  │  → 次のアクション: Manager に Mirror URL を共有する        │   │  ← Primary CTA
│  │    [evergreen filled button, 大]                          │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ───────── 日常の管理 ────────────────                          │  ← H2 (Secondary)
│  ┌──────────┬──────────┬──────────┬──────────┐                │
│  │ユーザー  │チーム    │単発      │一括      │  ← 4 cards     │
│  │管理      │作成      │Upload    │Upload    │   outline only │
│  └──────────┴──────────┴──────────┴──────────┘                │
│                                                                 │
│  ───────── その他の管理機能 (▼ 展開) ────────                    │  ← H2 (Tertiary)
│  [折りたたみ — 展開すると以下 6 項目が出る]                       │
│    · 稼働状況確認  · データ品質  · 準備度チェック                  │
│    · コミュニケーションポリシー · 話者管理                         │
│    · ジョブ監視  · 通知管理                                       │
│                                                                 │
│  ───────── チーム ────────────────                              │
│  [TeamRow x 5 — 展開 detail はミーティング件数・日付範囲のみ]    │
│                                                                 │
│  [フッター: 免責 + governance リンク]                            │
└─────────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	適用方法	研究参照
P-3 3-Layer Action Architecture	11 アクションを Primary (1) / Secondary (4) / Tertiary (6) に分離。 Primary は pilot phase で動的、 Tertiary は折りたたみ	app-admin__references.html §3 / Stripe R1 + Vercel R2 + Okta R4 + Google WS R5 (N=4)
P-4 Scope Boundary Banner (full)	H1 直下にフル banner として恒久配置。 dismissible でない (canon 強制)	§3 / Stripe + GitHub + Okta + Google WS (N=4)
P-1 Setup checklist → Post-Setup Transition	完了後に「稼働中」バナー + 次アクション CTA (Manager に Mirror URL 共有) に切り替える evolved 版	§3 (researcher §7 リスク 3 の回避策) / Stripe + Okta + Google WS + B2B UX (N=4)
P-2 KPI strip + drill-down (Variant A 同様)	drill-down 先は operational ページのみ	§3 / N=4
P-5 Expandable TeamRow (調整版)	展開 detail はミーティング件数・日付範囲・平均時間に絞る (タイトル列除去 — researcher §7 リスク 2 回避)	§3 / Vercel + GitHub + Okta + B2B UX (N=4)

design_system_v1 トークン適用箇所

Scope Boundary Banner: --kashi-paper-tint 背景 + --kashi-evergreen 3px left border + --space-5 padding + --radius-md + outline ShieldCheck icon (Lucide 24px)
Primary CTA カード: --kashi-evergreen filled + white text + --text-h3 ボタンラベル
Secondary カード: --kashi-paper 背景 + --kashi-border outline + --text-body
Tertiary 折りたたみ: accordion (アクセシブル) + --text-body-sm リンクテキスト
KPI 数値: --text-h2 + Fraunces (現状 Inter から変更で「数字が読みやすく serious」になる)
spacing: section block separator --space-8 (現状 inconsistent から統一)
focus ring: --shadow-focus 全 interactive 要素に適用

permanent-ui-principles 適合チェック

§	判定	根拠
§3 Role Boundary First	PASS+	Scope Boundary Banner で role + 可視範囲 + 不可視範囲を H1 直下で明示。 §3 の 6 質問のうち 1-3 + 5 (forbidden action) が banner だけで answer される
§4 Visibility per Role (System Admin)	PASS+	「operational configuration + technical logs のみ」を banner で明示。 Tertiary 折りたたみ内のラベルも operational 文言に統一
§7 Progressive Disclosure	PASS	「default visible layer: 1 headline + 1 short explanation + 3-5 cards + 1 primary CTA」完全準拠。 Tertiary 6 項目は fold 化
§8 Cognitive Load	PASS	「one primary CTA」「clear H1 + logical H2 sections」「grouped controls」完全準拠。「equal-weight CTA spam」が解消される
§9 Dashboard Rules	PASS	KPI は組織構造の count のみ、個人 rank / health score 無し
§11 Internal Screen Rules	PASS+	role label / visibility boundary / safe actions / forbidden actions を Scope Boundary Banner で 1 箇所集約表示
§13 Visual System	PASS	off-white base + 濃緑 accent + outline icon、 surveillance 系アイコン無し。 ShieldCheck は「security camera」と異なり「policy boundary」メタファーで OK

DATA_VISIBILITY_MATRIX 適合チェック

Admin に表示:
- 自テナントの組織構造数値 (KPI strip): チーム数 / メンバー数 / 処理件数
- operational config 管理 (Secondary 4 アクション): ユーザー管理 / チーム作成 / Upload (2 種)
- 技術ログ・運用設定 (Tertiary 6 項目): 稼働状況 / データ品質 / 準備度 / コミュニケーションポリシー / 話者管理 / ジョブ / 通知
- TeamRow 集計値 (件数・日付範囲・平均時間): operational な利用量で structural metric でない ことを確認済み
Admin から構造的に除去:
- ミーティングタイトル列 (TeamRow 展開から削除)
- 個別 pattern summary への CTA (Longitudinal という名称自体が誤解を生むので除去)
- 個別 member 名指しシグナル (もともと無いが UI 上で「ない」ことを明示)
Scope Boundary Banner 本文 (canon §4 + §8 適合確認済み): 「あなたは [組織と利用状況] の管理者です。ミーティングの中身、メンバー個別のパターン、シグナルはこの画面からは閲覧できません — これは canon です。 → 詳細はデータ可視性マトリクス §3 / §8」

解決される Justine の不満 (researcher 推察)

C-A1 解決: 11 アクション並列 → 1 primary + 4 secondary + 6 tertiary fold で「何から始めればいいか」が即座に分かる
C-A2 解決: Variant A 同様に token 統一でスタイル混在解消、さらに 3 層構造で「視覚的優先度」が伝わる
C-A3 完全解決: Scope Boundary Banner で「ミーティング洞察を見られる」という誤読が canon 強制レベルで排除される
C-A4 解決: P-1 evolved で完了後の「次のステップ」 (Manager に Mirror URL 共有) が Primary CTA として常駐
C-A5 解決: KPI strip drill-down + 3 層構造で「だから何をすべきか」が動線として明示される

残るリスク / 未解決事項

Tertiary 折りたたみは初見の admin が「機能が無いと思い込む」可能性。 mockup で展開ヒント (「+ 6 項目」等) を明示する
Primary CTA の動的切り替え (pilot phase ベース) はバックエンド state の信頼性に依存。 mockup では 3 phase それぞれを示す
Scope Boundary Banner の文言は haseruida@ / Justine の最終 review が必要 (canon 系 copy は wording sensitive)

Canon Violation 検出

CLEAN+ 「分析」「ミーティング詳細」「メンバー発言」系の CTA は 0 件。 Tertiary 折りたたみ内含めて全て operational 文言。 Scope Boundary Banner で「不可視」が積極的に表明される (canon §1 「The UI wins by showing less」の実装)。

Variant C — 大胆 (Operational Task Inbox Unification)

SCOPE: cross-surface IA rethink 実装工数: L (15-20 日、 routing 変更含む)

⚠ Variant C のみ: cross-surface 影響あり (PortalHeader nav / routing 構造変更)。実装工数は A/B の 約 3 倍 必要。 Justine は「根本解決の必要性」と「現行 muscle memory 破壊コスト」を比較して判断。

一文要約

Admin の今やるべき operational task を単一 priority queue (inbox) に統合し、 user provisioning / billing alert / org settings 変更レビュー等を同じスタックで処理。「meeting analysis」系の入り口は構造的に消去 (探しても無い設計) — admin home が canon を物理的に体現する大胆案。

主タスク (page の primary job)

"admin の inbox にある operational task を順番に消化する" — Stripe / Okta / Linear inbox pattern を operational task に転用。各 task は明示的に「何が今 attention required か」を queue として提示。 admin は「何をすべきか」を考える必要がない (inbox が示す)。

レイアウト構造 (above-fold composition)

┌─────────────────────────────────────────────────────────────────┐
│ PortalHeader (簡素化: 3 items のみ — Inbox / Settings / Help)   │  ← nav 縮小
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  管理 Inbox                                      [role: admin]   │  ← H1
│                                                                 │
│  ╔═════════════════════════════════════════════════════════════╗│
│  ║  Scope Boundary Banner (恒久、 B より強い文言)                ║│  ← P-4 max
│  ║                                                             ║│
│  ║  この inbox は operational task のみを扱います。              ║│
│  ║  ミーティング洞察 / メンバー個別パターン /                     ║│
│  ║  シグナルへの入り口は意図的に存在しません。                    ║│
│  ║                                                             ║│
│  ║  これは Kashi の根本設計 — Bypass forbidden (canon §8)        ║│
│  ╚═════════════════════════════════════════════════════════════╝│
│                                                                 │
│  ┌─処理待ち─┐ ┌─完了 (今週)─┐ ┌─保留─┐                          │
│  │   3    │ │     12      │ │  0  │   (count only)            │
│  └────────┘ └─────────────┘ └─────┘                            │
│                                                                 │
│  ───── 処理待ちタスク (priority queue) ─────                    │  ← H2 単一
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ [高]  ユーザー招待 3 件の承認待ち                          │   │  ← inbox row
│  │       期限: 2026-05-30 · → 処理する                       │   │
│  ├─────────────────────────────────────────────────────────┤   │
│  │ [中]  Speaker alias 未割り当て: 田中, 佐藤                 │   │
│  │       → 割り当てる                                         │   │
│  ├─────────────────────────────────────────────────────────┤   │
│  │ [中]  パイロット準備度: 3/4 ステップ完了                    │   │
│  │       残り: 通知ポリシー設定 · → 完了する                   │   │
│  ├─────────────────────────────────────────────────────────┤   │
│  │ [低]  処理ジョブ: 過去 7 日で再試行 2 件                    │   │
│  │       → ジョブ詳細                                         │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ───── 組織概要 (operational read-only) ─────                   │  ← 折りたたみ可
│  チーム: 12 · メンバー: 47 · 処理件数: 156 (今月)                │
│  ▼ チーム一覧を見る (件数のみ)                                  │
│                                                                 │
│  ───── 設定 (Settings) ─────                                    │  ← 折りたたみ可
│  ▼ 設定項目を見る (8 項目 fold)                                  │
│    · 組織設定  · Upload 設定  · 通知ポリシー  · データ品質基準     │
│    · 話者管理  · API トークン  · 監査ログ  · プライバシー設定      │
│                                                                 │
│  [フッター: 免責 + canon リンク]                                 │
└─────────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	適用方法	研究参照
Operational Task Inbox (新 archetype)	11 アクションを「処理待ちタスク」として priority queue に統合。 Okta R4 の pending tasks section が最も近い参照	app-admin__references.html §3 / Okta R4 「pending tasks section」直接適用 + Stripe R1 「tasks widget」拡張 (N=2 だが Okta pattern は同 archetype での再現性高)
P-4 Scope Boundary Banner (max strength)	B より強い文言 — 「意図的に存在しません」「これは Kashi の根本設計」を明示	§3 / N=4
P-2 KPI strip (簡素化版)	処理待ち / 完了 / 保留の 3 カウントのみ — task inbox の状態指標	§3 / N=6
P-3 (吸収) — 階層化は inbox priority に集約	3 層 action architecture は inbox 内の priority (高/中/低) に内包される	§3 / Okta R4 inspired
(意図的に除去) P-5 Expandable TeamRow	チーム一覧は「組織概要」折りたたみに格下げ — Admin home の primary 要素から外す	— canon §4 「operational のみ」を最大限実装

design_system_v1 トークン適用箇所

Inbox row: --kashi-paper 背景 + --kashi-border hairline + --space-4 padding + hover で --shadow-sm
Priority badge ([高]/[中]/[低]): --kashi-state-warning / --kashi-grade-emerging / --kashi-ink-muted + 色のみでなくテキストラベル必須 (a11y)
Scope Boundary Banner (max): --kashi-evergreen filled 背景 + white text + --space-6 padding + --radius-lg + ShieldCheck Lucide icon 24px
KPI count: --text-h3 (大きすぎない、 task inbox の従属指標として)
「組織概要」「設定」折りたたみ: accordion (a11y) + chevron icon
typography: 全てのインライン CTA は --text-body-sm リンクスタイル (button カード乱立を避ける)

permanent-ui-principles 適合チェック

§	判定	根拠
§3 Role Boundary First	PASS++	Scope Boundary Banner (max) + inbox 構造そのものが「admin の役割は task 処理」を明示。 §3 の 6 質問すべてが banner + inbox で 1 画面 answer
§4 Visibility per Role	PASS++	「operational task のみ」を inbox 構造で物理的に実装。 Longitudinal / Coverage / Readiness 系へのリンクは存在しない (探しても無い)
§7 Progressive Disclosure	PASS++	default visible = banner + KPI 3 + inbox 上位 4 行 + 折りたたみ 2 セクション。「default visible layer 3-5 cards」完全準拠。全 6 設定項目は fold
§8 Cognitive Load	PASS++	「one primary CTA」 = inbox の最上位 row。全てが「処理順序」として既に整理されている。「equal-weight」問題が構造的に不可能
§9 Dashboard Rules	PASS	KPI = task inbox state のみ、個人 rank / health score 無し
§11 Internal Screen Rules	PASS++	各 inbox row が role label + safe action + audit semantics を自然に含む (task = action なので必須)
§13 Visual System	PASS	off-white base + 濃緑 accent banner + outline icon。 inbox UI は monitoring/surveillance 系と意味論的に異なる (task queue は能動的、 dashboard は受動的監視)

DATA_VISIBILITY_MATRIX 適合チェック

Admin に表示 (inbox 内):
- ユーザー招待・承認待ち (operational config event)
- Speaker alias 未割り当て警告 (operational config の不足通知)
- パイロット準備度進捗 (operational checklist state)
- ジョブ失敗・再試行 (technical log の attention required event)
Admin に表示 (背景情報):
- 組織構造 count (チーム/メンバー/処理件数) — 「組織概要」折りたたみ内
- operational 設定 8 項目 — 「設定」折りたたみ内
Admin から構造的に消去 (canon §8 max enforcement):
- Longitudinal / Coverage / Readiness 系ページへの全リンク (PortalHeader nav からも除去)
- Communication Policy admin 側操作 (operational config なので残すが Settings fold 内に格下げ)
- 個別チームのミーティング一覧へのドリル動線 (TeamRow 展開は件数 only)
- 「分析」「洞察」「メンバー個別」系の語彙すべて

解決される Justine の不満 (researcher 推察)

C-A1 完全解決: 11 アクション並列 → priority queue で「次に何をすべきか」が常に最上位 1 行に出る
C-A2 完全解決: inbox row は全て同一スタイル。 priority badge のみで差別化 — visual hierarchy 統一
C-A3 究極解決: 「ミーティング洞察」への入り口が UI から物理的に消滅。 admin が誤解する余地が無い
C-A4 解決: setup task も inbox 内の 1 row として扱われ、完了後は自動的に inbox から消える (次の task が自然に top に来る)
C-A5 部分解決: 「誰がどれくらい使っているか」は「組織概要」折りたたみ内 — 主要画面要素ではなくなる (これは canon §4 的には正しい設計だが、利用状況把握ニーズがある admin には UX 後退の可能性)

残るリスク / 未解決事項

Cross-surface 影響: PortalHeader nav が 3 items (Inbox / Settings / Help) に縮小されると、他 4 surface (me/ceo/reviewer/mirror) のナビ連動も再設計が必要。これは別 surface の variant pick と整合性を取る必要あり
Routing 変更: 既存 /app/admin/longitudinal 等のページは残るが、ナビからは到達不能になる。既存のブックマーク / 直リンクは backward compat で残す要
Backend 依存: 「処理待ちタスク」の動的生成には backend に task aggregator service が必要 (現状は無い)
Muscle memory 破壊: 既存 admin user (Justine 含む) が「いつものアクション grid」を探して見つからない混乱期間が発生
「利用状況概観」の弱体化: C-A5 不満には部分的にしか応えられない。ただし canon §4 的にはこれが正しい設計
Settings 8 項目 fold は探しにくい: 普段使う operational config (Upload 等) が fold 内になると admin が困る可能性 — mockup で頻度別 sub-grouping を検討

Canon Violation 検出

CLEAN++ 「分析」「ミーティング詳細」「メンバー発言」系の CTA は 0 件 — UI 上から物理的に消滅。 Scope Boundary Banner で「意図的に存在しない」を積極的に表明。 SmartHR / カオナビ-style HR surveillance dashboard との差別化が最も明確に出る variant。

3 Variant 比較表

出典: app-admin__references.html (Stage 1 research) · permanent-ui-principles.md §1-§15 · design_system_v1.md §1-§10 · DATA_VISIBILITY_MATRIX.md §1-§10 · orchestrator_kickoff.html §3

軸	A 保守	B 中庸 (推奨)	C 大胆
IA 変更	なし	3 層構造化 + Scope Banner	Inbox 一本化 + nav 縮小
実装工数	S (2-3 日)	M (5-7 日)	L (15-20 日、 routing 含む)
リスク	低	中	高 (muscle memory 破壊、 backend 依存)
C-A1 (11 並列認知負荷)	未解決	解決	完全解決
C-A3 (洞察誤読リスク)	部分解決	完全解決 (banner 強制)	究極解決 (物理消滅)
Kashi 差別化 (SmartHR/カオナビとの対比)	弱 (見た目だけ改善)	強 (banner で明示)	最強 (構造で明示)
canon §4 適合度	PARTIAL	PASS+	PASS++
permanent-ui §7 progressive disclosure	PARTIAL	PASS	PASS++
cross-surface 影響	なし	なし	あり (PortalHeader nav 連動再設計要)
Round 1 mockup 適性	地味で feedback 取りにくい	差分が明確で feedback 取りやすい	方向性議論を引き起こすので Round 1 で見せる価値高

UI Proposal — `/app/admin` — Round 1

0. 共通前提 — Admin canon の 3 つの絶対制約

Variant A — 保守的 (Visual / Token Cleanup)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

Variant B — 中庸 (3-Layer Action Architecture + Scope Banner)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

Variant C — 大胆 (Operational Task Inbox Unification)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

3 Variant 比較表

Justine への推奨

UI Proposal — /app/admin — Round 1

0. 共通前提 — Admin canon の 3 つの絶対制約

Variant A — 保守的 (Visual / Token Cleanup)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

Variant B — 中庸 (3-Layer Action Architecture + Scope Banner)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

Variant C — 大胆 (Operational Task Inbox Unification)

一文要約

主タスク (page の primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher 推察)

残るリスク / 未解決事項

Canon Violation 検出

3 Variant 比較表

Justine への推奨

UI Proposal — `/app/admin` — Round 1