/app/admin — Round 1生成: 2026-05-27T00:00:00+09:00 | Agent: kashi-ui-researcher | Surface: Admin Dashboard | Stage: 1/3 (research only)
kashi/src/app/app/admin/page.tsx (484 行)kashi/src/app/app/layout.tsx (PortalHeader ラップ)kashi/src/components/portal/PortalHeader.tsx (2 段ヘッダー)テナント管理者がテナント全体の状態を一目で把握し、「ユーザー追加」「チーム作成」「ミーティングアップロード」「分析閲覧」へ即座にジャンプできること。 パイロット開始準備チェックリスト (4 ステップ) が未完了の間はそれが最前面に出る。
/longitudinal, /coverage, /readiness, /communication-policy) へのナビゲーションsection として並列に並ぶ。第 2 段が「濃緑カード」、第 3 段が「白カード」とスタイルが混在。合計 11 アクションボタンが上部に集中し、何から始めればいいか分かりにくい。r19 §6.2 「Color semantics inconsistent」と同じ問題がポータル内でも発生。
| フィールドカテゴリ | Admin 可視性 | 制約根拠 |
|---|---|---|
| 自己データ | Y(self) | 全ロール共通 |
| Affected-candidate identity (他者) | N — operational role; no review brief | DATA_VISIBILITY_MATRIX §3 |
| Per-meeting structural metrics (他者) | N | DATA_VISIBILITY_MATRIX §3 |
| Pattern summaries (他者) | N | DATA_VISIBILITY_MATRIX §3 |
| Team aggregates | N | DATA_VISIBILITY_MATRIX §3 |
| System audit log | Y (system audit のみ) | DATA_VISIBILITY_MATRIX §3 / §8 |
| Org-level executive aggregates | N | DATA_VISIBILITY_MATRIX §3 |
| Ref # | プロダクト | 調査 URL / ソース | Archetype | 調査ソース種別 |
|---|---|---|---|---|
| R1 | Stripe Dashboard | docs.stripe.com/dashboard/basics |
金融 SaaS admin — metric overview + progressive drill-down | 公式 docs (WebFetch 2026-05-27) |
| R2 | Vercel Team Dashboard | vercel.com/docs/rbac/managing-team-membersvercel.com/changelog/dashboard-navigation-redesign-rollout |
デプロイ SaaS admin — member lifecycle + project list | 公式 docs + changelog (WebFetch 2026-05-27) |
| R3 | GitHub Org Admin | docs.github.com/en/organizations |
開発 SaaS org admin — member management + team hierarchy | 公式 docs (WebFetch 2026-05-27) |
| R4 | Okta Admin Console | help.okta.com/en-us/content/topics/dashboard/dashboard.htmWebSearch (2026-05-27) |
IdP/SSO admin — org health + task queue + user lifecycle | 公式 help docs + search (WebFetch/WebSearch 2026-05-27) |
| R5 | Google Workspace Admin Console | knowledge.workspace.google.com |
Enterprise admin — users/groups + service management | 公式 knowledge base (WebFetch 2026-05-27) |
| R6 | カオナビ ダッシュボード | support.kaonavi.jp/scene-function/dash-board/001WebSearch (2026-05-27) |
JP 人事 SaaS admin — HR データ集計 + 組織ビュー | 公式 support + search (WebSearch 2026-05-27) |
| R7 | B2B SaaS パターン集積 (multi-source) | GitNexa SaaS UX Patterns guide & GitHub SaaS UI patterns gist & procreator.design onboarding patterns | UX pattern aggregator — admin dashboard best practices | 第三者 UX 文献 (WebFetch/WebSearch 2026-05-27) |
注: SmartHR, BambooHR, Linear, Notion, Jira の help/docs への直接 fetch は 401/404 のため、 WebSearch 経由の 2 次情報として補完。これらは個別 finding の根拠には使わず、 R1〜R6 の主要 fetch 結果のクロスバリデーションに利用。
| Pattern | 適用先 Kashi 課題 | 観察 refs (N≥3) | Kashi 互換性 |
|---|---|---|---|
|
P-1: Setup Checklist as Dismissible Inline Card セットアップ未完了のときのみ表示される埋め込みカード。 完了ステップはチェック済みアイコンで明示。 全完了後に自動非表示 (Dropbox: progress bar 付き)。 カード全体が折りたたみ可能 (Stripe / Okta: tasks widget)。 |
C-A1 / C-A4: 現状のチェックリストは完了後に消えるが、未完了中は黒背景で最前面に出てアクション 11 個と並立する。完了後の「次のステップ」へのパスが弱い。 |
Stripe (R1) — tasks widget Okta (R4) — pending tasks section Google Workspace (R5) — getting started wizard B2B UX patterns (R7) — onboarding checklist card |
✓ 直接適用可 Kashi の既存実装 ( setupComplete フラグで非表示) とほぼ同じ構造。
改善点: 完了後に「パイロット開始へ」の次ステップ CTA カードに切り替えるパターンを追加できる。
canon 制約なし。
|
|
P-2: 3-Stat KPI Strip (count-only) Above Action Grid ページ最上部に 3〜5 枚の数値カード (チーム数 / ユーザー数 / 処理件数)。 数値のみ、グラフなし、深掘りリンクを各カードに付ける。 Stripe: balance + payments + disputes cards。 Vercel: projects / deployments / usage。 GitHub Org: members / teams / repositories。 |
C-A5: 現状の 3 stat cards は数値のみで深掘り動線がない。「利用状況の俯瞰」にはなっているが「だから何をすべきか」が伝わらない。 |
Stripe (R1) Vercel (R2) GitHub (R3) Okta (R4) |
△ 要調整 各 stat card に深掘りリンク ( /app/admin/teams, /app/admin/users) を追加する方向は適合。
ただし Admin は meeting pattern / シグナルを見られないため、
「ミーティング数」カードのリンク先が /app/admin/longitudinal（分析系）に繋がると
canon §4 Admin 可視ルールと衝突する可能性。
リンク先は「アップロード管理」等の operational なページに限定すること。
|
|
P-3: Role-Differentiated Action Architecture (Primary / Secondary / Tertiary) Admin アクションを 3 層に分類: (1) Primary CTA — 最も重要な 1〜2 アクション (大カード / filled button) (2) Secondary actions — 頻度高い管理アクション (outline card, 2〜4 個) (3) Tertiary / advanced — サブページナビゲーション (小さいリンク or 折りたたみメニュー) Stripe: primary CTA → 課金管理、secondary → payments/customers、tertiary → settings。 Vercel: primary → new deployment、secondary → members / billing、tertiary → advanced settings。 Okta: primary → pending tasks、secondary → user lifecycle actions、tertiary → reports。 |
C-A1 / C-A2: 現状は 11 アクションが 3 段にわたって並列。 濃緑 / 白 / 濃緑 / 白 のスタイル混在が優先度を伝えていない。 3 層アーキテクチャを導入することで「今すぐやるべきこと」が即座に分かる。 |
Stripe (R1) Vercel (R2) Okta (R4) Google Workspace (R5) |
✓ 直接適用可 Kashi の kashi-evergreen filled card = Primary 層、
white border card = Secondary 層、
小リンクテキスト = Tertiary 層 — という既存のスタイル分類を
意図的な 3 層 として再整理するだけで実現可能。
canon 制約なし。永続的 UI 原則 §7 (Progressive Disclosure) に合致。
|
|
P-4: Operational Scope Boundary Banner Admin ホームの上部または Stats エリアに「あなたが見られる範囲」を 1 文で明示するバナーまたはサブタイトル。 Stripe: "You have access to payments and team settings. Revenue analysis requires Finance role." GitHub Org: "As owner, you can manage members, teams, and org settings." Okta: role badge + "Super Administrator" vs "Read-Only Administrator" の明示。 Google Workspace: "Super Admin" ラベルが各セクション上部に表示。 |
C-A3: Admin が「ミーティング洞察を見られる」と誤解する動線。 DATA_VISIBILITY_MATRIX §8 「Admin は operational scope のみ」を UI で明示することで、誤解と surveillance 感を同時に回避できる。 |
Stripe (R1) GitHub (R3) Okta (R4) Google Workspace (R5) |
✓ 直接適用 + Kashi 独自強化 Kashi では既に ShieldCheck アイコン + 免責フッターがあるが、
それはページ最下部のみ。
Admin ホームの H1 直下に "管理者ビュー — 操作設定の管理のみ。ミーティング分析への入り口はこの画面にありません。" という 1 行スコープ明示を置くことが、
canon §3 (Role Boundary First) + §4 (System Admin: operational only) の実装になる。
これは surveillance 感回避とも直結し、Kashi の差別化ポイント。
|
|
P-5: Team/Member List with Expandable Row Detail チーム / メンバー一覧を折りたたみ可能な行で表示。 クリックで展開し、メンバー一覧・作成日・アクションが出る (List → Details Drawer pattern)。 Vercel: team settings → members list → role badge + "Manage Role" button per row。 GitHub: org → teams → members tab。 Okta: directory → groups → expandable group detail。 B2B UX patterns (R7): 「Search → Data Table → Bulk Action Toolbar」pattern。 |
C-A5: 「誰がどれくらい使っているか」の俯瞰。 現状の TeamRow は既に展開可能だが、表示される情報 (meetingCount / totalDurationMs / members) の優先度整理が必要。 ミーティング数は「operational な利用量」として Admin が見てよい情報。 |
Vercel (R2) GitHub (R3) Okta (R4) B2B UX patterns (R7) |
△ 要調整 Kashi の TeamRow 展開には「ミーティング一覧 (タイトル・日時)」が含まれる。 これは DATA_VISIBILITY_MATRIX §3 で Admin は N のフィールド (per-meeting structural metrics) に近接する。
ミーティング タイトルと日時 は構造的メタデータであり、
ミーティング内容そのものではないが、要注意。
表示を「ミーティング件数・最終ミーティング日」に絞り、タイトル一覧へのリンクは
"/app/admin/upload" の operational context に限定することを推奨。
|
? キー) — Stripe (R1) のみ。
コマンドパレット的な操作。Kashi admin の現時点のユースケースには過剰。N=1 weak
/app/admin/upload-bulk で既に一部実装中。ここの改善は別 surface スコープ。
Pattern summaries = N / Structural metrics = N。
Admin ホームからの分析 CTA (Longitudinal, Coverage 等) が「ミーティング洞察を見に行く動線」として機能してしまうと canon 違反になるため、
これらのリンクの文言・配置を「operational readiness チェック」として再フレーミングする必要がある。
根拠: permanent-ui-principles.md §4 (System Admin: 見られるのは operational configuration + technical logs のみ)
+ DATA_VISIBILITY_MATRIX §8 (Bypass forbidden)
permanent-ui-principles.md §2 (forbidden wording: "organizational health score", "team health score", "at-risk employee")
および §1 「employee surveillance」に該当。採用不可。
permanent-ui-principles.md §4 (Employee: must NOT expose page views to employer by default)
permanent-ui-principles.md §1 "AI magic" / §13 「AI glow 禁止」に抵触。
Admin 画面では AI 推論の結果を見せてはいけない。
| Pattern ID | Stripe (R1) | Vercel (R2) | GitHub (R3) | Okta (R4) | Google WS (R5) | カオナビ (R6) | B2B UX (R7) | N≥3? |
|---|---|---|---|---|---|---|---|---|
| P-1 Setup checklist card | tasks widget | — (implicit: pending invites) | — | pending tasks section | getting started wizard | — | onboarding checklist card | Yes (4) |
| P-2 KPI strip + drill-down link | balance/payments/disputes | projects/deployments/usage | members/teams/repos | active users/app sign-ins | users/groups summary | dashboard グラフ数値 | 5-7 KPI card limit | Yes (6) |
| P-3 3-layer action architecture | primary/secondary/tertiary nav | owner actions / settings layers | — | tasks / directory / reports | service sections hierarchy | — | layered layout pattern | Yes (5) |
| P-4 Scope boundary banner | role-based access notice | — | owner role badge + capabilities list | Super Admin / Read-Only Admin label | Super Admin badge | アクセス管理 権限付与説明 | — | Yes (4) |
| P-5 Expandable team/member list | — | members list + Manage Role button | teams → members tab | directory → group → detail | — | — | Search → Table → Bulk action | Yes (4) |
/app/admin/upload) に移動。
setupComplete フラグが true になるとチェックリストセクションが丸ごと消える。
Admin は「何もする必要がなくなった」のか「使い方が変わった」のか分からない。
出典: Stripe Dashboard docs (docs.stripe.com) · Vercel RBAC docs + changelog (vercel.com/docs) · GitHub Org docs (docs.github.com) · Okta Admin Console docs (help.okta.com) · Google Workspace Admin knowledge base (knowledge.workspace.google.com) · カオナビ ダッシュボード support (support.kaonavi.jp) · GitNexa SaaS Dashboard UX Patterns (gitnexa.com) · GitHub SaaS UI Patterns gist (gist.github.com/mpaiva-cc) · procreator.design onboarding patterns (procreator.design) · Rosalie / Medium admin dashboard best practices (rosalie24.medium.com)