Design Decisions — pilot / Variant C

Round 001 · Generated by kashi-ui-mockupper · Variant: C (記事主体 / note 型) · 2026-05-27

本書は、 pilot/C/index.html の設計判断を、 future-Justine と将来の React 実装担当者のために残すトレース文書。 三 variants (A / B / C) の中で C を選んだ理由ではなく、 「C を作るとしたら、 こう作るしかない」 という設計の必然性 を記録する。

1. 主タスクと上位構造

決定: pilot page を 「pilot 募集」 ではなく 「第 4 章: 共同探究者の募集」 として書き、 conversion 機能を CTA 1 つ (→ /contact) に圧縮した。

brief Variant C 仕様 §「pilot: 第 4 章 — 我々が探しているのは、 共に答えを探す人」 そのまま。 物語の中で 「あなたを共同探究者として迎えたい」 と告げる章が pilot page。 form を埋めるのではなく、 章を読み終えた人が末尾の 「もし、 話したい人がいたら」 をクリックして /contact 章へ進むのが唯一の遷移。

canon: brief §C「CTA: 控えめ、 末尾に 1 つ」 / permanent-ui-principles §1 監視感 NG (商売っ気の希薄化も同じ系列)

決定: 現行 kashi/src/app/pilot/page.tsx の 4 セクション (Hero / Form / Expect / Alt-CTA) を解体し、 6 つの 「§」 (essay sections) に再構成した。

現行構造は B2B 検討ファネル: 関心 → 申込 → 期待値合わせ → 代替 CTA。 Variant C は逆。 関心の解像度を上げ、 「自分はそもそも合うのか」 を読者自身が判断するための material を提供する。 申込 form は無い。 申込のような切迫感を持たせること自体が、 共同探究の関係性と矛盾するため。

canon: brief Variant C 仕様 「conversion ではなく共感と理解が目的」

章内の 6 節 (§) の対応関係

役割現行 page.tsx 対応
§ 1 正解を持っている SaaS ではなく、 問いを持っている SaaSpositioning の宣言― (新規)
§ 2 共同創業者からの率直な告白founders vulnerability― (新規)
§ 3 我々があなたにお願いしたい四つのことcommitment の明示現 form/lead を物語化したもの
§ 4 共同探究の、 おおよその時間軸practical な期待値合わせ現 expect の 5 cards を 4 tick の時間軸 illustration へ
§ 5 こういう方とは話さない方がいいnegative qualification― (新規 / 反 conversion 装置)
§ 6 では、 どんな方ならself-identification の招待現 altCta を内省への招きに変換

2. レイアウト

決定: 読みやすさ最優先の 1 column、 max-width 680px。 wide breakout は §4 時間軸 illustration のみ (880px)。

brief §C 「max-width 680px (読みやすさ優先)」 そのまま。 日本語本文は 1 行 28-35 字程度が最適。 680px / IBM Plex Sans 17px だと 1 行 約 35 字に収まる。 多段グリッドや side rail を入れないことで、 読者の視線が一本のラインから外れず、 long-form の没入を保つ。

canon: 日本語タイポグラフィ通例 (1 行 28-35 字) / brief §C max-width 680px

決定: hero (chapter opening) と本文の間に short lede + byline を挟む note 型構造。 byline には日付・著者・読了時間。

note / Medium の読者は、 読み始める前に 「これは何分で読み終わる読み物か」 を知りたい。 「読了 約 8 分」 を最初に置くことで、 読者の中の認知コスト計算を肩代わりする。 これは B2B SaaS の page ではあまり見ない signal だが、 essay site ではほぼ必須。

ref: note.com / Medium.com 慣例

3. 採用したトークン

token使用箇所判断
--color-cream #F5F0E6body 背景全体Variant C は cream dominant。 商業性ではなく書物性を出すための基底色
--color-cream-deep #EDE6D6colophon (footer) 背景商用 site では footer に暗色を置くが、 essay site では同系色で 「本のおわり」 感を出す
--color-cream-soft #FAF6EEinline aside 背景本文と微差で、 本文流れを切らない
--color-kashi-evergreen #1F3D33wordmark / em 強調 / drop cap / pullquote 縁 / closing CTA「主役の差し色」 として控えめに。 段落地の色には使わない
--ink #2A3A1E本文段落純黒ではなく深緑寄りの ink。 cream 地で目が疲れにくい
--ink-soft #4B5746lede / aside / 章末 lede地の文より一段やわらかく
--ink-faint #7A8273byline / meta / 番号 / ornament機能情報 (構造情報) は限りなく後景へ
Fraunces (serif)h1 / h2 / em / pullquote / CTA / founders note文学的・思考的・「人が書いた」 感の signature
IBM Plex Monochapter mark / byline / 番号 / label / ornament / colophon h4「装幀」 のための活字。 本文には絶対使わない
Zen Kaku Gothic New本文 (font-family の fallback として常駐)日本語本文。 Fraunces とは混ぜず、 sans に統一
決定: Emerald (#047857) は採用しなかった。

brief base palette には Emerald も含まれているが、 Variant C は色数を絞ることで essay 感を強める。 Evergreen + cream + ink scale のみで構成。 Emerald を使うとデータ可視化や CTA の 「商品色」 寄りになり、 章末 1 CTA の控えめさと矛盾する。

canon: brief §C 「文字主体、 mid-page illustrative imagery (data viz が art piece として)」

4. 採用した evidence-grade 表現

決定: evidence-grade badge は本 mockup には登場しない。

pilot page は 共同創業者が読者に直接書く章 であり、 製品 UI のスクリーンショットや 「証拠強度」 を表示する画面ではない。 evidence-grade は /app/me/app/team の dashboard tokens であり、 marketing 章の中で前借りすると 「product として完成している」 という嘘の signal になる。 Variant C はその嘘を真っ先に避ける文書。

canon: design_system_v1 §「evidence-grade は dashboard UI のみで使用」 / brief §C 「正解を持っている SaaS ではなく問いを持っている SaaS」

5. 削った要素 (現状 kashi/src/app/pilot/page.tsx から)

削った要素削った理由
PilotRequestForm (組織名 / 役職 / メール / 規模 / 任意メモ) 申込 form は商品取引の signal。 共同探究は契約締結前に必ず 1 時間の対話があるため、 form ではなく /contact 章で対話する。 form の friction が、 「真摯に向き合う関係を選ぶ人」 を逆に弾いてしまうリスクがある。
PilotTimelineStrip (5 stops の横方向 strip) 削ったのではなく、 §4 の 4-tick illustration に翻訳。 「30 日」 を 「Week 0 / 1-2 / 3-10 / 11-12」 と章として読ませることで、 進行ではなく節として感じさせる。
EXPECT_KEYS 5 cards (scope / duration / pricing / review / slots) card grid は parallel 比較の signal。 共同探究は parallel に並ぶ要素ではなく、 順序のある関わり合い。 §3 の 01-04 番号付き list と §4 の時間軸 illustration に分解。
Alt-CTA band (demo / why の 2 button、 ink tone 暗色背景) 暗色 band は 「ここで決めて」 という visual pressure。 §6 + closing で 「合わなければ来なくていい」 と語っているため、 trap door 的に押す button は矛盾する。 章末ナビ (← 第 3 章 / 第 5 章 →) で代替。
「ISO 27001 / SOC 2 Type II 準拠」 「初期費用ゼロ」 などの B2B 訴求 本文中に inline で 「契約と SOC 2 相当の運用で固めますが、 何より大事なのは...」 と一行で触れるに留めた。 訴求材料ではなく、 共同探究の前提として最小限で。

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

追加要素根拠 / pattern
Chapter mark (「第 4 章 / Chapter IV」 + 横棒) note / Medium の章扉慣例。 6 ページ全体を 1 つの物語として読ませるための index signal。
Drop cap (1 段落目の頭文字を Fraunces 大判で) 文学的長文の signature。 「読み物として読んでほしい」 を視覚で先に告げる。
Pullquote (引用ブロック、 Fraunces italic、 evergreen 左罫) 長文中の呼吸点。 Variant C 仕様 「chapter breaks (---、 大きな margin)」 の中位段階。
Founders' note (2 人の創業者の対話風 italic note) brief §C 「founders の率直な vulnerability」 そのまま。 2 列で対話的に並べることで 「一枚岩の声明」 ではなく 「対話の中の声」 として読ませる。
§5 「こういう方とは話さない方がいい」 (反 conversion 段落) brief §C 「conversion ではなく共感と理解」 を作るための negative qualification。 これがあると、 §6 「では、 どんな方なら」 の招きが強くなる。 心理学的には commitment-consistency 効果。
4-tick 時間軸 illustration (Week 0 / 1-2 / 3-10 / 11-12) brief §C 「data viz が art piece として」 のミニ実装。 horizontal axis + filled / outlined dots で、 「今ここ」 ではなく 「節の連なり」 として時間を見せる。
Inline aside 「補足 / 守らないこと、 という設計」 permanent-ui-principles §2 forbidden wording を、 marketing 文の中に再書き込みする装置。 「製品としての制約」 ではなく 「読者と一緒に守る約束」 として語る形に。
Closing single CTA (「話したい人へ、 連絡先のページへ」 を italic + 下線) button 色ではなく typography だけで CTA を作る。 brief §C 「末尾に控えめに 1 つ」 そのもの。
Colophon (footer に 「about this chapter」 + chapter list + index) SaaS site の footer ではなく、 出版物の奥付。 「これは商品ページではなく文書である」 という最後の signal。

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

トレードオフ 1: conversion rate は確実に下がる。

form を消したことで、 「pilot を申し込みたいけど /contact ページに行くのが面倒」 という層は離脱する。 これは Variant C の前提 (variant 比較で 「最も少ない申込数、 最も濃い対話」 を志向) であり、 設計バグではない。 ただし数値で示すと A 比 10-20% の form 通過率、 / cm 数値 (M/L) の質は不明、 ヒアリング比較が必要

トレードオフ 2: 「読まないと意思決定できない」 が読者の認知負荷になりうる。

読了 8 分は long-form として標準域だが、 B2B 意思決定者の 「scan して比較表で決めたい」 行動パターンとは衝突する。 Variant C は scan 不可能 (見出しだけ拾うと文意が崩れる) に意図的にしている。 これは 意思決定のスピードを犠牲にして、 意思決定の質を上げる 賭け。

未解決 1: 「読み終えた人が /contact に進むコンバージョン経路」 を form 抜きでどう quantify するか。

現実装の form 送信ログ (/api/pilot-requests) が捉えていた conversion event がなくなる。 /contact 章での event tracking を、 (a) UTM 付与 / (b) /contact 章自体の form / (c) email mailto: + Plausible event tracking、 のいずれで設計するかは Variant C を採用する段階で決める必要がある。 本 mockup ではスコープ外。

未解決 2: 日本語 site と英語 site の文体ギャップ。

Fraunces italic の英文 (「Founders' Note」 等) と Zen Kaku Gothic 日本語本文は、 同じ tone でも視覚的な重さが異なる。 EN/JA 両言語で long-form を保つ場合、 EN 版は文章量が 1.3-1.5 倍に膨らむ。 ja-only で出すか、 EN は要旨版にするかは、 共同創業者の言語分担次第。

未解決 3: founder note を本物の創業者 2 人の文で差し替える必要がある。

現 mockup の founder A / B の note は dummy。 公開前に共同創業者本人の言葉に差し替える必要があり、 そこで vulnerability の塩梅 (どこまで本音を書くか) を Justine 自身が決めることになる。 ここが Variant C を 「実際に公開できるか」 の最後の関門。

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

このモックアップを React/Next.js で実装する際の注意:

9. Justine confirm 判断点 (共同創業者ヒアリング前に決めること)

  1. 「共同探究」 という言葉を、 公式 vocabulary として採用するか ―― 採用するなら CANONICAL_PRODUCT_TRUTH.md に追加。 採用しないなら本 mockup の言葉を 「pilot」 「研究的 pilot」 等に置換することになり、 章のトーン自体が変わる。
  2. founder vulnerability をどこまで開示するか ―― 現 mockup は 「組織開発の専門家ではない」 「監視窓に変わることが一番こわい」 まで開示。 これは投資家 due diligence で読まれた時に追加質問になる文章でもある。
  3. 料金を 「いただきません」 と明示するか ―― 現 mockup は明示。 ただし pilot 後の有償化への transition は別途 /pricing 章が必要 (本 mockup スコープ外)。
  4. 「こういう方とは話さない方がいい」 段落 (§5) を残すか ―― これがあると 「断り」 をプロダクトが先に出すことになり、 大手企業の意思決定者には不快に映る可能性。 一方でこれが Variant C の核でもある。
  5. form を完全に消すか、 「気が向いたら一行だけ」 のような mini-form を残すか ―― 現 mockup は完全消去。 中間案として 「§ 末尾に email 1 field だけ」 という選択肢もある。