Design Decisions — /product Variant A (ものすごく B2B)

決定: ページ全体を「製品仕様書 (Product Specification Document)」として扱う

稟議書添付・社内回覧 PDF と同じ参照体験になるよう、 番号付き章立て (01-08)、 doc-nav (sticky)、 セクション末尾のダウンロードリンクで構造化した。 マーケサイトというより「営業担当者が貴社に送付する技術資料の Web 版」 という体裁。

背景: 大手企業の人事部長 / CTO / CEO (40-60代、 検討期間 6-12ヶ月) は、 emotive な hero copy より「項目が網羅されているか」 を最初に確認する。 章番号があるだけで「読むべき文書」として認識される。

brief Variant A 仕様 / target reader = 大手企業の人事部長・CTO・CEO / buying mode = 稟議書ベース

決定: ヘッダーを 2 行構造にし、上段に ISO/SOC 2/APPI 準拠バッジを常時表示

大手企業の購買担当はページ最上部の「監査適合性」を最初に確認する。 上段は B2B sub-header (規模目安・準拠表示)、 下段は標準 nav。 これは複数のエンタープライズ SaaS (Workday / SAP SuccessFactors / Lattice の Enterprise tier) の構成と一致。

さらに sticky-cta band (evergreen 帯) を ヘッダー直下に固定 — 「貴社の人事・情報システム部門ご担当者様へ」 という購買セグメント呼びかけ + 「資料一式 PDF」 「商談予約」 の常設 CTA。 スクロール中に常に触れる位置に置くことで「次の行動」 を購買モードと一致させる。

brief tone: sticky CTA バー + 多段グリッド / CTA: 資料請求・商談予約・セキュリティホワイトペーパー

決定: 番号付き 8 セクション (01-08) のタブ式 nav を sticky 化

Stripe Atlas / AWS Marketplace のエンタープライズ製品ページに頻出するパターン。 章番号 (01-08) が並ぶことで、「読み飛ばし可」 + 「全体ボリュームの把握」 が即座にできる。

スクロール時に現在セクションが自動 highlight される vanilla JS を 30行で実装 (highlight 以外の挙動は CSS scroll-behavior に任せた)。

brief visual: information density 高 / 多段グリッド (3-4 列)

決定: 右側にダッシュボード風 KPI チャート (sparkline + evidence-grade ラベル)

brief で明示された「ヒーローもデータ駆動 (グラフ + 数値)」 を直接実装。 demo株式会社のサンプル数値 (対話往復率 +18%・発言占有偏り -24%・4 部門の安定/観察中/要確認ラベル) を表示し、 大企業購買担当が「これは実数値の見える化ツールである」 と一読で理解できるようにした。

右上に SAMPLE ラベル + チャート下にフットノートを置き、 「これは見本値である」 ことを明示。 過大評価リスクを抑制。

brief hero: data 駆動 / 数値 + グラフ / canon: evidence-grade ラベル必須 (色だけでなくテキスト)

決定: 対応規模 / 提供形態 / データ所在 / 監査ログ / SSO / SLA を 2×3 grid で即提示

大企業 IT 部門の購買要件の核 6 項目を、 リード文の下に枠付きで即配置。 「対象規模 300〜10,000名」「データ所在 国内 (東京)」「SLA 99.5%」 など、 稟議書に転記可能な形で構造化。 これにより hero スクロール前に既に「最低限の検討材料が揃っているか」 が判別可能。

brief dense data (KPI 表) / corporate evergreen 多用

決定: 6 カテゴリ × 17 項目の機能比較表、 Kashi 列を RECOMMENDED マークで強調

brief で明示された「feature 比較表」 の核実装。 競合は実名を伏せて「サーベイ型 EX ツール」「1on1 管理ツール」 とジェネリック化した — これは法的リスク回避 + 「具体名出したくない」 大企業文化への配慮。

カテゴリは A. 入力データ / B. 認証 / C. データ保護 / D. ガバナンス / E. インフラ / F. 運用 SLA の 6 つ。 これらは情報システム部門の SaaS 採用ベンダーチェックシートの標準項目セットと一致 (CASB / 三井住友海上雛形 / 東京海上日動雛形等)。

「✓ 対応 / — 非対応 / △ 条件付き」 はテキスト + 色 + アイコンの 3 重表記 (canon: color alone NG)。

brief ROI 比較表 / dense table / B2B 比較表は emotion を持ち込まない

決定: 4 レイヤー (音声ソース → 構造抽出 → Lattice 蓄積 → 役割別ビュー) を縦積み diagram

brief で明示された「architecture 図 (RLS / k-anon / forward-only lattice 等 enterprise-grade governance を visualize)」 を直接実装。 各レイヤー左に LAYER ラベル、 右に 4 ノードを並べる枠組み。

3色ボーダー区別: 緑 (貴社環境内) / 濃緑 (エッジ処理) / 青 (Kashi クラウド)。 凡例で「データが境界を越える / 越えない」 を明示。 これにより「音声は貴社環境を出ない」「集計シグナルだけ送る」 という Kashi 独自のデータガバナンスが図 1 枚で説明される。

ノード名 (DIARIZATION / STRUCT_EXTRACT / K_ANON_FILTER / FORWARD_LATTICE / RLS_POLICY / AUDIT_LOG / TOKYO_REGION 等) は IBM Plex Mono の SCREAMING_SNAKE_CASE。 大企業のシステム設計書 / ER 図と同じ視覚言語。

各レイヤー間の「▼ 音声 (貴社環境内処理)」「▼ 集計済シグナルのみ送信 (構造数値、内容除去済)」 という flow caption が、 図を読み解く順序とデータの境界遷移を明示。

brief architecture 図 (RLS / k-anon / forward-only lattice) / canon: structure-not-content (内容ではなく構造)

決定: 12 カードを LIVE / BETA / ROADMAP の 3 ステータスで分類

brief で明示された「SSO / SAML / SCIM / Audit log / on-prem option (将来)」 を 12 カードに展開。 ステータスバッジで「現在提供中 / 招待制 / 計画中」 を明確化することで、「将来計画を現行機能と誇張表記する」 リスクを排除。

カードは SAML SSO / SCIM / RLS / k-匿名化 / Forward Lattice / 監査ログ / 専用 VPC / データ所在 / SIEM連携 / BYOK / オンプレ / ISO 27001。 これらは大企業情報システム部門ベンダーチェックシートの「セキュリティ 30項目」 から抜粋した実用最小セット。

各カードのフッタに CATEGORY / IDENTITY 等のメタ表記。 検索 / フィルタ可能な構造化文書として読める。

brief enterprise feature 表示 / SSO / SAML / SCIM / Audit log / on-prem

決定: 4 つの ROI 試算カード + 「想定」「試算」 表記 + 計算前提の foldout 公開

brief は「離職率○%改善」 などの ROI 数値を促していたが、 同時に canon (CANONICAL_PRODUCT_TRUTH) は「予測 / 健康スコア / at-risk」 を禁止語に指定している。

両立のため、 全数値に「想定 / 試算」 を冠し、 「Kashi が ○ を解決する」 ではなく「貴社規模 (300名・退職率13%) を仮定すると、 ○ の規模感で試算可能」 という構造に書き換えた。 これは「貴社の稟議書添付材料の例」 という枠組みで提示し、 「Kashi の効果保証」 という枠組みは取らない。

カード下に「前提・引用元・計算式を開く」 details 要素を配置し、 厚生労働省・リクルートワークス研究所等の引用元を foldout 内に明示。 監査担当者の「数字の根拠は?」 質問に対応可能。 最後に「本試算は導入効果を保証するものではない」 免責を明記。

brief ROI 数値 + 比較表 / canon 予測・健康スコア・at-risk 禁止 (permanent-ui-principles §2)

決定: 8 項目の正式契約条件テーブル (期間 / 初期費用 / 範囲 / 撤退 / 移行 / NDA / 審査 / サポート)

brief で明示された「pilot 期間 90 日、 初期費用ゼロ」 を、 稟議書の「契約概要」 シートにそのまま貼り付けられる構造化テーブルにした。 「90日 / ¥0 / 1-3部門 / 30-80名 / 撤退条項あり」 という条件が一覧化されていることで、 購買担当者の稟議作成負担を最小化。

撤退条項 (第30日以降 随時終了可、 削除証明書発行) を明示し、 大企業の「失敗時のリスク管理」 の懸念を先回りで打ち消す。

NDA / DPA / セキュリティチェックシート対応・SIEM連携・国内日本語サポート等、 大手企業導入時の「定番質問」 をすべて回答済の形で配置。

brief pilot 期間 90 日 / 初期費用ゼロ / 撤退条項

決定: 「Kashi が行わないこと」 セクションをアテンション色 (cream) で目立たせる

permanent-ui-principles §1 (監視感 NG)、 §13 (surveillance metaphor NG)、 CANONICAL_PRODUCT_TRUTH §2 (structure-not-content)、 DATA_VISIBILITY_MATRIX §4 (no HR use) を、 大企業導入時の「ガバナンス上の懸念点」 への先回り回答として配置。

3 つの境界宣言 (個別発言の内容評価しない / 人事評価利用しない / リアルタイム監視しない) は、 各カードに CANON / ... 形式で社内 canon 参照を明記。 これは「営業担当者が口頭で説明する内容を、 文書として残す」 ガバナンス要件にも応える。

cream 背景 + 各カードに canon-ref フッタ。 「禁止事項を堂々と公開している」 ことが大企業の信頼確保の重要要素。

canon permanent-ui-principles §1, §13 / CANONICAL_PRODUCT_TRUTH §2 / DATA_VISIBILITY_MATRIX §4

決定: 8 文書 (PDF/XLS/DOC) を 2 カラム grid で常設ダウンロード

brief で明示された「セキュリティ仕様書 / DPA download CTA」 を 8 文書に拡張: セキュリティ仕様書 / DPA / 機能比較詳細 / 参考事例 / 契約書ひな形 / ROI 試算シート / ベンダーチェック回答書 (128項目記入済) / 運用境界ガイドライン。

各文書にページ数 + 更新月 (バージョン管理) を表記し、「適当な PDF ではなく管理された文書である」 ことを示す。 evergreen のフルブリード band で配置し、 ページ最下部で「結局これを持ち帰りたい」 検討者の動線を確保。

「ベンダーチェック回答書 128項目記入済テンプレ」 は特に大企業の情報システム部門担当者に刺さる項目 — 「自分が記入する手間が省ける」 という pre-emptive 提供。

brief 「セキュリティ仕様書」 「DPA」 download CTA

TO1: 情報密度が高く、 モバイル (480px) では機能比較表のスクロール体験が落ちる

機能比較表は 4 列構成のため、 モバイルでは横スクロールに依存 (overflow-x: auto)。 大企業購買担当の 90% はデスクトップで見るという前提を置いたが、 通勤中の役員レビューなどモバイル参照のユースケースは対応弱。 もし「モバイルでも完全に読めること」 を要件にする場合、 表を「行転置 (Kashi 列 + 他社2列を行に展開)」 する別 view が必要。

TO2: BETA / ROADMAP 機能の比率が高い (SIEM 連携 / BYOK / オンプレ / ISO 27001)

大企業導入時、「ISO 27001 取得済」 を要件にする企業は実装上の障害になる。 現状「準拠 (申請中)」 「Roadmap 2027」 と正直表記しているが、 競合がすでに取得済の場合、 この表記で稟議落ちするリスクあり。 営業担当者の口頭補完が必須となる。

選択肢: (a) 取得まで本ページを公開しない、 (b) ロードマップ計画を強く打ち出して「将来確実取得」 を強調する、 (c) パイロット時の同等性確認チェックシートで代替する。 Justine 判断要。

TO3: ROI 試算は「demo株式会社 (300名)」 1 例のみ

brief で指定された仮想顧客 1 例のみ表示。 「うち 1,000名」「うち 5,000名」 の試算は省略 (mockup スコープ外)。 実装時はインタラクティブな「貴社規模を入力 → 試算」 ウィジェットが望ましい。

TO4: 「導入実績」 セクションが無い (canon 上の制約)

大企業購買担当は「既存導入企業ロゴ」 を強く求めるが、 Kashi 現時点で公開可能なロゴは無い (Phase 0 ヒアリング中)。 §08 で「参考導入事例 (匿名版)」 を提示して代替したが、 ロゴ wall がないことは Variant A の主弱点。 競合 (パーソル EX / SmartHR / Lattice) との直接比較場面で見劣りする可能性が高い。

選択肢: (a) パイロット協力企業のロゴ掲載交渉、 (b) ロゴ無しでも刺さる「業界アナリスト引用」 を追加する、 (c) ヒアリング段階の「参加企業数 (匿名)」 を提示する。 Justine 判断要。

TO5: Variant A は warmth ゼロ。 B / C との切替判断ポイント

本案は「人事部長 60 代・購買期間 12 ヶ月」 という極端な保守セグメントに最適化したため、 「個人として使ってみたい Manager / 若手」 には冷たく感じる可能性が高い。

Variant A を選ぶ判断条件: (a) GTM が大企業 ENT 営業中心、 (b) パイロット狙いが 1,000 名以上の上場企業、 (c) 共同創業者の合意で「最初の 10 社は大手」 と決まっている場合。

逆に「ベスチャー / 個人サインアップ経由のリード」 を狙うなら Variant B、 「思考リーダー / メディア露出経由」 なら Variant C。 6 ページ全体で variant 統一が必要 (page ごとに variant 混在は brand 破壊)。