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

決定: 「B2B 大手企業のセキュリティ・法務担当者が、 Kashi のデータ取扱を 1 ページで査読できる」 を主タスクに据える

「ものすごく B2B」 を 「enterprise SaaS 典型仕様の dense 仕様表」 ではなく、 data architecture を中心とした査読可能ページ として翻訳した。 これは canon source (NO_PAYLOAD_ARCHITECTURE.md) が最も豊富かつ詳細に書かれている領域であり、 fabricate せずに B2B 信頼性の高い density を出せる唯一の領域だから。

結果として: hero spec table / 4 layer architecture / persisted data allow-list (table) / 6 enforcement cards / lanes (default vs opt-in) / scope (does/doesn't) / pilot spec / FAQ という構造で、 全節が canon source 1:1 trace 可能になった。

canon: NO_PAYLOAD_ARCHITECTURE.md §1-7 / permanent-ui-principles.md §2 (no surveillance framing)

決定: dense 多段グリッド + 2 行 sticky header + side spec table 維持 (前回踏襲)

Variant A の brief に 「dense data / 多段グリッド (3-4 列) / sticky CTA バー」 とあり、 これは canon 違反では無いため維持。 ただし密度の中身を 「fabricate 仕様表」 から 「canon-verified architecture 表」 に総入れ替え。

• Header: 2 行構造 (top: 言語・取扱資料 / bottom: brand + nav + 2 CTA) — 大手企業の corporate site の通例パターン
• Hero: 1.2fr : 1fr の 2 column grid。 左は本文、 右は mono タイポの spec table (「カテゴリ / 主たる出力 / persist する / 運用可能な会議系 / パイロット枠 / 公開価格」 8 行) — 全 8 行は canon source あり
• 4 Layer Architecture: 4 column grid (貴社環境 / Ingest / Kashi cloud / 永続化)。 LAYER 3 のみ evergreen 背景で視覚的に Kashi 領域を明示
• Allow-list Table: 6 row 表 (4 row が persist する / 2 row が persist しない)。 各 row は NO_PAYLOAD_ARCHITECTURE.md §3 §4 §4.1 から直接引用
• Enforcement: 3 col × 2 row の 6 card (§6.1 〜 §6.6 と一致)。 全 6 card は NO_PAYLOAD_ARCHITECTURE.md §6 から直接 trace
• Lanes: 2 col (default ON は cream + evergreen border で hierarchy、 opt-in OFF は white)
• Scope: does ○ / doesn't × の 2 col。 doesn't 側を grey にして 「Kashi が disclaim する境界」 を明示

canon: site_mockup_brief.txt § A 「dense data (KPI 表 / グラフ)、 多段グリッド (3-4 列)」

決定: design_system_v1 token のみ。 Variant A 内では emerald-700 を semantic accent (○ / does column) に、 evergreen を Kashi 領域 + structural authority に使用

token	用途
--color-kashi-evergreen #1F3D33	brand wordmark / heading / 主 CTA / LAYER 3 (Kashi cloud) 背景 / pilot block / lane default border
--color-emerald-700 #047857	does ○ / persist-yes 行のみ。 brand 直接ではなく 「肯定 semantic」 にだけ使用
--color-cream #F5F0E6	hero 背景 / default lane card 背景 / 「担当者と話す」 CTA block
--stone-900	footer 背景 (enterprise corporate らしい暗色 footer)
Fraunces 500	全 h1-h4、 wordmark、 layer-name、 lane h3、 pilot-block h2
IBM Plex Sans 400/500/600	body / button / nav
IBM Plex Mono 400/500	eyebrow、 SOURCE: 注、 hero-spec dl、 layer-item tag、 audit_log / meeting_metrics 等 table key、 PILOT SPEC dl、 footer-bot
Zen Kaku Gothic New	fallback (Plex Sans が JA glyph 不在の場合)

color discipline: 既存 /product page.tsx の Day 8c 規律 「emerald-700 → Kashi 価値、 stone-* → warm neutral」 を踏襲。 violet / amber / 複数 green は使わない。

canon: kashi/src/app/globals.css / kashi/docs/design/design_system_v1.md / 既存 product/page.tsx Day 8c color rule

決定: 製品ページなので evidence-grade badge は出さない

evidence-grade (blocked / insufficient / weak / emerging / stable / high-confidence-stable) は アプリ画面 (in-product 観察結果) で使う構造。 マーケティングサイトの製品紹介ページで使うと 「Kashi が会議に grade を付ける」 という誤解を生む。

かわりに persist allow-list で 「○ persist」 (emerald) / 「× 列が存在しない」 (grey + 取消線) という binary な状態タグを使った。 これは grade では無く、 単純な存在 / 不在の表示。

canon: permanent-ui-principles.md §2 (no scoring of people) / DATA_VISIBILITY_MATRIX.md (grade はアプリ層)

削除: SOC 2 Type II 取得済 / ISO 27001 取得済 / ISO 27018 / ISO 30414 認証

canon に第三者認証の取得状況の記述無し → fabricate 禁止。 FAQ では 「第三者認証の取得状況は本公開ページではなく Kashi 担当者よりロードマップ含めて個別にご説明」 と placeholder 化。

site_canon_facts.txt § 認証取得

削除: SSO / SAML / OIDC / SCIM 対応の確定的記述

canon に明示無し → 「認証要件は導入時に個別協議」 placeholder。 FAQ 設問でも 「シングルサインオン等」 と一般化し、 SSO / SAML / OIDC / SCIM の語自体を本文から完全除去。

site_canon_facts.txt § 認証 / SSO / grep 結果 0 件

削除: 月額 ¥240,000 / 年額試算 / ROI 削減金額

canon に公開価格無し → 全箇所 「個別見積もり」 「pilot 期間中は無料」 のみ。 hero-spec dl にも 「公開価格: 個別見積もり (担当者)」 と明示。 ROI 試算ブロックは全削除。

site_canon_facts.txt § 価格 / FAQ Q「数値保証」 で 「Kashi では離職率改善 % / ROI 削減額 / 生産性 % 向上 等の確定的成果数値は保証しておりません」 と明示

削除: 専任 CS 1 名 / ソリューションエンジニア 1 名 / カスタマーサクセスマネージャー

Kashi は早期スタートアップ、 dedicated role canon 無し → 「Kashi チームが直接併走」 のみで言及。 役職名・人数は出さない。

site_canon_facts.txt § Team composition / pilot-block 本文 「Kashi チームが直接併走」

削除: Google Meet / Microsoft Teams / Webex / Slack huddle 対応

canon は Zoom のみ運用可 → hero-spec dl 「運用可能な会議系: Zoom (現時点)」 / FAQ Q「対応する会議ツール」 で 「現時点で Zoom」 と明示。 他ツール名は本文中に一切出さず。

site_canon_facts.txt § 会議 integration / memory project_zoom_integration_pending.md

削除: 「実績ロゴ wall」 / 「お客様事例 PDF DL」 / 「ベンダーチェック回答書 128 項目 DL」

Kashi はまだ顧客実績の公開段階に無く、 124 項目等の数字も canon 無し → 全削除。 かわりに 「ドキュメント請求 (NDA 下)」 という controlled な hand-off フレーズに。

site_canon_facts.txt § 納品物 / grep 「128 項目」 0 件

追加: 4 Layer Architecture 図

NO_PAYLOAD_ARCHITECTURE.md §1-3 の data flow を視覚化した。 LAYER 1-4 の名称・各レイヤーで扱う対象は全て canon 由来 (LAYER 1 = §1 「貴社環境の会議ツール」 / LAYER 2 = §2 「volatile memory」 / LAYER 3 = §3 「構造抽出」 / LAYER 4 = §3 allow-list)。

視覚的に LAYER 3 のみ evergreen 反転にしたのは、 「Kashi が触る領域はどこか」 をセキュリティ担当者が一目で identify できるようにするため。

NO_PAYLOAD_ARCHITECTURE.md §1-§3 / 本ファイル § 6 (architecture, not promises)

追加: Persisted Data Allow-list (6 row table)

NO_PAYLOAD_ARCHITECTURE.md §3 (3 row) と §4 (deny list の 12 key) を 1 table に統合。 4 row の persist-yes (meetings / meeting_metrics / meeting_trace / audit_log) は §3 から直接引用、 2 row の persist-no (body_text / raw_vtt 等) は §4 §4.1 から引用。

枠外注 「詳細なテーブル定義 / RLS ポリシー / サニタイザ実装の参照は、 NDA 締結後に担当者経由でお渡し」 は意図的なノイズ低減 (公開できない技術詳細を 「NDA 下」 として正当に隠蔽)。

NO_PAYLOAD_ARCHITECTURE.md §3 §4 §4.1

追加: 6 Enforcement Cards (§6.1-§6.6 と一致)

NO_PAYLOAD_ARCHITECTURE.md §6 が 6 サブセクションあるので、 1 サブセクション 1 card で素直に visualize。 各 card 下部の SOURCE: は canon doc / file path を明示 (mockup の trust transparency)。

NO_PAYLOAD_ARCHITECTURE.md §6.1-§6.6

追加: Default Lane / Opt-in Lane 2 card

NO_PAYLOAD_ARCHITECTURE.md §5 の 表 (Structural lane / Semantic lane) を card 化。 default ON は cream + evergreen border で 「これが既定」 を視覚 hierarchy。 LLM 送信について 「既定では送信されません」 を hero 直下にも書きつつ、 詳細はここで開示する 2 段構成。

NO_PAYLOAD_ARCHITECTURE.md §5

追加: Scope (does / does not) 2 column

permanent-ui-principles.md の disavow doctrine (「監視ではない」 「予測ではない」 「人事判断の置き換えではない」) を 1 ブロックで明示。 Variant C の disavow pattern が前回 successful だったので、 B2B 文脈でも採用 (「セキュリティ担当者ほど 「やらないこと」 の明示を信用する」 という性質に合致)。

does column は emerald-700 ○ / doesn't column は ink-faint × という color coding で、 「肯定は brand color、 disavow は neutral」 という階層を作った。

permanent-ui-principles.md §2 / CANONICAL_PRODUCT_TRUTH.md §1-§2 / Variant C disavow precedent

追加: Pilot Block (canon-strict spec 8 項目)

site_canon_facts.txt § Pilot 仕様 (canon 確定) からそのまま 8 行 (対象 / 期間 / 形式 / 枠数 / 料金 / 本契約 / 導入会議系 / 連絡先) を mono spec dl に転写。 月 3 枠限定は canon の核心 fact なので strong 強調。

site_canon_facts.txt § Pilot 仕様 / kashi/messages/ja.json pilotCtaSubline

追加: 8 FAQ (Security Reviewer 想定)

大手企業の情報セキュリティ担当者が最初に投げる 8 質問を、 全て canon-verified な回答に統一:

1. 文字起こしは保存されるか → NO_PAYLOAD_ARCHITECTURE.md §2 と一致
2. 外部 AI に内容が送られるか → §5 と一致
3. 認証連携 (SSO/SAML 等の語は出さず一般化) → 「導入時に個別協議」 placeholder
4. 第三者認証の取得状況 → 「個別ご説明」 placeholder
5. 対応会議ツール → Zoom のみ明示
6. パイロット仕様 → 8 項目 canon と一致
7. 監査ログ / DPA の請求 → 「NDA 締結後」 placeholder
8. 離職率 / 生産性 数値保証 → 「保証しておりません」 明示の disavow

FAQ 8 番の disavow は意図的 — B2B ページに 「数値保証しない」 を堂々と書くことで、 信頼を逆に獲得する pattern。

site_canon_facts.txt 全項 / NO_PAYLOAD_ARCHITECTURE.md §1-§7

トレードオフ 1: 「ものすごく B2B」 の brief 期待値との張り合い

brief には 「ROI 比較表」 「セキュリティホワイトペーパー」 「導入事例 PDF」 が想定 CTA として並んでいた。 これらは canon に裏付けが無いため、 「ドキュメント請求 (NDA 下)」 という controlled hand-off に置換。 大手企業担当者が期待する 「download 即ダウンロード可」 の即時性は犠牲になった。

判断: canon 無しで偽 PDF DL リンクを置くと、 リンク先が空 or 404 で 「この会社、 ちゃんと整備していない」 という逆効果になる。 「NDA 下で担当者から正式に」 と明示する方が、 セキュリティ担当者には誠実に映る。

トレードオフ 2: enterprise look の density vs canon 実 fact 量

canon にある fact だけで dense 4-column grid と 6-card grid と 6-row table を埋めた結果、 「実体ベースの dense」 にはなったが、 「数字が踊る dense」 にはなっていない。 大手担当者によっては 「KPI 表が無い」 「グラフが無い」 と素っ気なく見える可能性。

判断: 数字でない architecture density (LAYER 1-4 / 12 key sanitizer / §6.1-6.6 など) で B2B 重みを出すことに振った。 これは canon 完整性を最優先する Kashi の position と整合する判断。

未解決: 「Kashi 担当者にご連絡ください」 の繰り返し

ページ内 6 箇所で 「個別協議」 「Kashi 担当者」 「NDA 下」 のいずれかが出てくる。 canon-strict にした reasonable な結果だが、 大手担当者が 「全部 hand-off で fact が無いな」 と読む可能性は残る。

本実装時に検討: 担当者連絡フォームを 1 ヶ所に集約 (footer 直前の 「担当者と話す」 callout) しているが、 副次 CTA として hero/pilot/FAQ にも分散して配置。 ここを 1 ヶ所に統合するか分散するかは Justine の判断点。

未解決: 「実績無し」 を公開ページで隠す問題

B2B 大手向けページなら通常 「導入事例 / 顧客ロゴ」 が必須。 Kashi はまだ pilot 段階で公開できる顧客実績無し → 全削除。 結果としてページから 「他社も使っている」 という社会的証明 (social proof) が完全に欠落。

本実装時に検討: pilot 終了後の顧客から OK が出た時点で 「使用例」 セクションを追加する余地を、 layout 上で footer 直前に空けてある (現在の最後の callout 「担当者と話す」 の上)。