Design Decisions — site/top Variant A (rev 2)

「ものすごく B2B」極の top page。大企業の HR / CTO / CEO 層 (40-60 代、保守的、稟議書ベース) を読み手と想定。 corporate evergreen + dense layout + keigo を採用し、個別 KPI は [DEMO] mark で fabrication と明示区別。

このファイル更新 (rev 2): 初稿 (2026-05-27) で月額 ¥240,000 / 90 日 pilot / Google Meet 対応 / SOC 2 取得済 / 専任 CS 等を creative で生成し、共同創業者共有前に Justine が catch。今回 (2026-05-28) は /tmp/site_canon_facts.txt ホワイトリストに厳密照合し、 forbidden patterns 10 種について grep self-audit で 0 件確認済 (§ 9 参照)。

1. 主タスクと上位構造

決定: top page を「稟議書を書く前段の検討者」の 1 回目のスキャンで完結するよう 8 セクションの密度ある縦長構造とした。

大企業の検討者は 6-12 ヶ月の検討期間に入る前に、「これは持って帰ってよい案件か」を 5 分以内で判断する。そのため hero で (1) 何の SaaS か (2) 何をしないか (3) パイロット仕様の核心数字 を即提示。続く §02-§05 で「問題 → 既知コスト → ガバナンス姿勢 → 監視ではない明言」を順に積み、 §06 spec table と §07 FAQ で稟議用の事実確認を済ませる構成。

canon: permanent-ui-principles §7 (progressive disclosure) + variant brief A.tone (dense data, corporate evergreen)

決定: hero は左 (コピー + CTA) + 右 (構造シグナル KPI パネル) の 2 カラム split。

「対話健全性の構造的可視化」と言葉だけで言うより、右側に EMERGING grade pill + delta arrow 付き KPI カードを置いた方が「これは数値 SaaS だ」と 1 秒で伝わる。 KPI カード自体には [DEMO] tag を明示し、 fabrication ではなく仮想顧客 (demo株式会社) のサンプル画面と分かるようにした。

参照: kashi/src/app/page.tsx §1 (split hero pattern) + 2026-05-27 失敗ふりかえり (数値 fabrication 対策で [DEMO] tag 必須化)

2. レイアウト

決定: max-width 1280px / 24px gutter / 8 セクション縦積み + dense grid (3 列 decl / 3 列 nums / 2 列 dontdo / 1 列 spec table / 1 列 FAQ accordion)。

B2B 検討者の典型 device は 13-15 インチ laptop と外部モニタ。 1280 を超えるレイアウトは稟議に貼る spec PDF として見にくい。 dense grid と spec table の組み合わせは Stripe / Atlassian / SmartHR の corp page で確立されたパターン。

参照: globals.css token (色のみ採用、 spacing は variant 仕様に基づき独自) + variant A.layout 「多段グリッド」

決定: 上部 utility bar (法人・自治体向け / パートナー / 採用 / JP/EN / お問い合わせ) + sticky header の 2 段構造。

大企業向け SaaS の corp サイトでほぼ標準。法人・自治体向けである旨を最上段に明示することで「個人 SaaS と間違えた潜在ユーザ」を入口で振り分ける。

参照: SmartHR / カオナビ / Talknote 等の B2B SaaS top の utility bar 慣例

決定: sticky bottom-bar をスクロールで hero 通過後に出現させ、「パイロット相談」 + 「資料請求」に常時 1 click 距離を維持。

B2B 検討者は long scroll を全部読んだ後に CTA を探す。末尾以外でも CTA に到達できるよう sticky 化したが、 hero と被らないよう scroll threshold を仕掛けた (hero 通過後にのみ表示)。 mobile では footer が遠いので削った (sticky 自体を 768px 以下で hide)。

canon: WCAG 2.5.5 (44px touch target) + permanent-ui-principles 触感原則 (画面端 sticky は控えめに展開)

3. 採用したトークン

--color-kashi-evergreen #1F3D33 — primary CTA, brand mark, accent borders
--color-kashi-evergreen-deep #244A3D — utility bar bg, pilot-cta dark band bg, h1/h2 color
--color-emerald-700 #047857 — eyebrow + accent underline + grade-emerging swatch
--color-cream #F5F0E6 — pilot-cta dark band の文字色 (ink-on-dark)
--grade-emerging #2563EB — hero KPI panel の EMERGING pill
--grade-stable / --grade-weak / --grade-blocked — KPI delta arrow + NOT DOING tag の色分離
type scale は v1 と微差: B2B 密度のため --fs-display clamp(2.25, 3.4, 3) (canon の clamp(2.5, 4, 3.5) より 0.25rem 小さく)、 --fs-body 0.9375rem (canon の 1rem より小さく) — dense 表現と稟議貼付向けの読み密度のため独自調整

font 使い分け

IBM Plex Sans + Zen Kaku Gothic New — h1/h2/h3/body デフォルト。 Fraunces を全面採用すると emotional になり、 B2B 検討者の保守感に合わない。 corporate sans を主役にした。
Fraunces — DECL/PROMISE/num-card big number/pilot-cta h2 のみ。「Kashi の人格」として serif を残しつつ、過剰に効かせない。
IBM Plex Mono — eyebrow / label / spec table thead / DEMO tag / canon-line / footer h4。「数値や仕様の言語」を mono で揃え、 enterprise 感を補強。

4. 採用した evidence-grade 表現

決定: hero KPI パネル下段に grade-pill (EMERGING / blue) を 1 つだけ提示。

color alone NG canon を守るため、必ず EMERGING という text label と swatch (square) をセットで表示。 color blind 対応として swatch は色のない box ではなく color box (色 + 形 + text 3 重情報)。 grade は EMERGING を採用 (構造シグナルが立ち上がりつつあるという意味)、 STABLE や HIGH-CONFIDENCE-STABLE は「all clear」寄りで permanent-ui-principles §6 (No-Signal rule) と緊張するので hero では避けた。

canon: design_system_v1 evidence-grade scale + permanent-ui-principles §6 (No-Signal rule, all-clear NG)

決定: NOT DOING cells の tag color は grade-blocked (#6B7280) を採用。

「Kashi がしない 4 項目」は禁止ラベルなので、 negative-but-neutral な grade-blocked を採用。 grade-weak (orange) や red は危険信号で「Kashi 自身が危険」と誤読されるので避けた。

5. 削った要素 (現状の Kashi top page から)

Kimura/Nao 仮想ストーリー (§4) — Variant A は keigo + 検討者向けで人物名のあるエピソード調と相性が悪い。代わりに「7.6 兆円 / 年収 1-2 倍 / 3-6 ヶ月早く」の数値カードを §02 に格上げ。ストーリーは Variant C で活かす。
RotatingHeroViz の動画 — 動的アニメは emotional 寄り。静的な KPI パネル + delta arrow に置換。
hero chip 「人事評価には使われない」等 — 残したが、 pillar row の cell として grid 化 (chip ではなく仕様表に再配置)。
WhyTeaser モジュール — section 数を増やしすぎないため。 footer の「なぜ Kashi か」 link で代替。

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

運用仕様 table (§05) — 稟議担当者が一行ずつ checkbox で潰せる corporate spec sheet。価格・認証・サポート体制を全部「ご相談」 placeholder に揃え、 fabrication を排除しつつ確認事項を網羅。
Kashi が「しない」こと 4 cells (§04) — ガバナンス審査でつまずく論点 (個人スコア / 退職予測 / 内容リスニング / リアルタイム監視) を先回りで明示否定。
pilot-cta セクション (§08) — canon の pilotCtaSubline を mono フォント (canon-line として目立たせ)、「数値の改善を約束できる段階にいません」という disavow を明示。
sticky bottom-bar — hero 通過後の CTA への 1-click 復帰路。
utility bar 「法人・自治体向け」ラベル — variant 仕様 (大企業極) を入口でシグナリング。

7. 既知のトレードオフ / 未解決

トレードオフ: hero KPI パネルの [DEMO] tag は正直さを優先したが、検討者によっては「数字が無いんじゃないか」と読む。

Kashi は実稼働の長期累積 KPI が無いステージ。 fabrication せず DEMO 明示は canon 正解だが、 enterprise SaaS 慣れした検討者は「他社サイトには数字が並んでいる」と感じる可能性。 mitigation 案: pilot 後 N=3 案件で OK 取れた数字が出たら DEMO を実数に置換 (今回は無理しない)。

未解決: 認証連携 (SSO 等) を「導入時に個別協議」とのみ書いたが、検討者は具体的な list が欲しい。

canon に SSO/SAML/OIDC 実装状況の確定 source が無いため確定的記述を避けた。 mitigation 案: 「セキュリティ仕様書」を PDF として別途用意し、「資料請求」 button から取得できるようにする (今回 mockup では link 先 placeholder)。

未解決: 会議基盤について「Zoom」のみ明記、他は「個別協議」とした。

Google Meet / Teams は integration 未実装。これを「対応済」と書いたら 2026-05-27 の事故再発。一方、大企業ユーザは Teams を主力で使うケース多く、 hard-blocker になる可能性。 mitigation 案: pilot 相談時に hearing → roadmap 化、サイト側は不確定情報を出さない (今回 mockup の判断)。

トレードオフ: spec table を hero 上ではなく §05 に置いた。

「価格ご相談」の行が hero に出ると弱く見える。 spec table は decision-ready な検討者向けの section として §05 に配置、 hero は CTA + 三原則 (構造 / 個人 / 評価不使用) で抽象的に強さを出した。 hero に value-prop を寄せた構成。

8. 実装フェーズへの引き継ぎ

このモックアップを実装する際の注意:

該当する Kashi コード: kashi/src/app/page.tsx (現状 7 セクション構造の上書き、 §2-§5 は messages/{en,ja}.json の既存キーを再利用可)
新規 i18n キー: variantA.dontDo.cell[1-4].(tag|ttl|desc), variantA.spec.row[1-10].(key|val|note), variantA.pilotCta.canonLine, variantA.pilotCta.disavow 等。既存 pilotCtaSubline は流用。
影響を受ける共有コンポーネント: PortalHeader は対象外 (本ページは marketing 側、 app/ 側の sticky header とは別)。 Button primitive + Eyebrow primitive は流用可。
必要な新規コンポーネント: HeroKpiPanel (DEMO tag 必須)、 DeclGrid、 DontDoGrid、 SpecTable、 PilotCtaDarkBand、 StickyBottomBar。既存 WhyTeaser は本 variant では使わない (footer link で代替)。
canon-verify CI hook: 実装時に messages/ja.json + messages/en.json 全体を grep し、 SOC 2 / ISO 27001 / 90 ?日 / Google Meet / Microsoft Teams / 専任 CS / 価格 ¥[0-9]+,[0-9]{3} が 0 件であることを CI で常時検査する hook を scripts/checks/ に追加することを推奨。
r19 既存課題のうち本案で同時解決されるもの:
- 「hero が抽象的でプロダクトが何か分からない」 → split hero + KPI panel + 三原則 row で 3 秒理解に短縮
- 「ガバナンス姿勢が見えない」 → §03 / §04 / pilot-cta disavow line で 3 段重ねの明示
- 「pilot 仕様が複数 page にバラけている」 → hero pillar + §05 spec table + §08 pilot-cta で 1 page 完結

9. Canon-verify self-audit (rev 2 で追加、 mandatory)

index.html に対し /tmp/site_canon_facts.txt の forbidden patterns 10 種を grep。すべて 0 件 であることを確認した。

#	Pattern	Hits
01	`¥[0-9]+,[0-9]{3}` (金額 hard-code)	0
02	`90 ?日` (pilot 期間 mis-spec)	0
03	`Google Meet`	0
04	`Microsoft Teams`	0
05	`SSO`	0
06	`SAML`	0
07	`SOC 2`	0
08	`ISO 27001`	0
09	`専任 CS`	0
10	`離職率.{0,3}[0-9]+ ?%`	0

PASS 10/10 forbidden patterns clean. Variant A は canon-bounded のまま B2B dense tone を維持できている。 ROI 「年収の 1-2 倍」は §3 の num-card で残したが、これは canon 確定 source (横浜市立大学 + 経産省) で messages/ja.json section3Card2Number の verbatim 引用なので Kashi 自身の効果値ではない。

audit method: grep -cE '<pattern>' index.html を 10 回実行 (bash one-liner)。

10. Justine confirm 推奨ポイント (rev 2)

hero KPI パネルの [DEMO] tag — fabrication 防止の最低ライン。「DEMO 表記が逆にダサく見える」と感じる場合は、 KPI パネル自体を削って hero を 1 カラム化することも可能 (B2B 密度は落ちるが正直さは増す)。
運用仕様 table の「ご相談」 placeholder の多さ — 価格 / 認証 / サポート体制 / レポートの 4 行が placeholder。検討者によっては「何も決まっていない」と読む。 mitigation で別 PDF (セキュリティ仕様書) を「資料請求」から出す前提で、今は site では出さない判断。
pilot-cta の disavow line 「数値の改善を約束できる段階にいません」 — 通常の B2B コピーでは弱気に映る。でも canon doctrine (forbidden claims registry) を守るには必須。 Variant C で実証された disavow pattern を A でも明示採用したが、残すか弱めるかは Justine 判断。