Brand Communication Design

ブランド階層 × 問い合わせ導線 × 法的構造の統合設計。 法人名とブランド名を一致させ、全接点で一貫性を実現する。

DESIGN PRINCIPLE

SEEHUB合同会社(法人)= SEEHUB(ブランド)→ 個別サービス。 法人名とブランド名が一致するため、全ての顧客接点で矛盾が生じない。 サポートはログイン後のみ。この2つの原則で全体が機能する。

Part 1: ブランド階層設計

SEEHUB合同会社(法人 = ブランド)
 │ 法人格・登記・決済・契約・コピーライト
 │ 顧客接点の中心・「見えれば、壁は溶ける」
 │ ドメイン: seehub.org
 │
 ├── IPPUKU by SEEHUB(旗艦・週次自己認識)
 ├── IBUKI by SEEHUB(親密さの設え)
 ├── LEGACY by SEEHUB(寄付受入基盤)
 ├── RENJI by SEEHUB(タイポグラフィ描画)
 ├── CHIGAI by SEEHUB(審美眼の可視化)
 ├── GUN by SEEHUB(データ構造可視化)
 ├── LIFE by SEEHUB(人生健康度診断)
 ├── PAIR by SEEHUB(結婚準備度診断)
 └── 将来のサービス群

法人名の決定(2026-03-14): 法人名をSEEHUB合同会社とする。法人名=ブランド名にすることで、 フッター・決済画面・銀行明細・利用規約の全接点でユーザーが見る名前が統一される。

検討経緯: 当初はJILL合同会社(思想に依存しない器)を検討したが、 (1) フッター © JILL LLC がブランドと矛盾する (2) Stripe決済でJILL表示→チャージバックリスク(決済紛争の45%は明細の名前不一致が原因) (3) ユーザーの「JILLって誰?」という認知コストが全接点で発生する ことから、ブランド整合性を優先した。 SEEHUB外の事業が必要になった場合は別法人を設立する(合同会社設立費用は約6万円)。

各層の役割

表記役割登場する場面
SEEHUB全大文字法人・ブランド・コミュニケーションの全てを担うフッター、特商法、利用規約、Stripe、Webサイト、SNS、メール、ドメイン
サービスNAME by SEEHUBユーザーが触れるプロダクト各サービスUI、オンボーディング、FAQ

法的権利の帰属

権利帰属先備考
著作権(コード・コンテンツ)SEEHUB合同会社© SEEHUB LLC
商標権(SEEHUB / IPPUKU)SEEHUB合同会社SEEHUB名義で出願
利用規約の契約主体SEEHUB合同会社「当社」= SEEHUB
Stripe決済の事業者SEEHUB合同会社descriptor: SEEHUB* IPPUKU
個人情報の管理者SEEHUB合同会社プライバシーポリシーの主体

ブランド階層が「効く」場面

場面表示理由
WebサイトヘッダーSEEHUB(+ サービス名)顧客接点はSEEHUB
フッター(全サービス共通)© SEEHUB LLC All rights reserved.法人名=ブランド名で一致
特商法ページSEEHUB合同会社法的義務
利用規約SEEHUB合同会社(以下「当社」)契約主体=ブランド
Stripe決済画面SEEHUB / IPPUKUdescriptor: SEEHUB* IPPUKU
銀行明細SEEHUB* IPPUKUユーザーがサービス名を認識可能
メール配信(問い)IPPUKU by SEEHUBユーザー体験はサービス名
メール配信(noreply)[email protected]ドメインはSEEHUB
SNS・コンテンツSEEHUB発信の顔はSEEHUB

表記テンプレート

フッター(全ページ共通)

© SEEHUB LLC All rights reserved.

利用規約冒頭

SEEHUB合同会社(以下「当社」)が運営する
IPPUKU(以下「本サービス」)の利用規約...

会社概要

運営会社: SEEHUB合同会社
SEEHUBは、意識進化プラットフォームです。

Part 2: コミュニケーション設計

ドメイン体系

用途ドメイン管理
メインサイトseehub.orgCloudflare
各サービス*.seehub.orgCloudflare

メールアドレス体系

全アドレスはGoogle Workspace(1ライセンス)のエイリアスとして [email protected] の受信トレイに集約。追加コスト0円。

アドレス公開用途
[email protected]公開法人代表窓口、Webサイト記載
[email protected]非公開外部SaaS登録(GitHub, Vercel, Stripe, Cloudflare等)
(お問い合わせフォーム)公開特商法・プライバシーポリシー・利用規約
(サポートフォーム)公開ユーザーサポート(Clerk認証内フォーム)
[email protected]送信元トランザクションメール(Resend経由)
(非公開)限定代表社員の個人通信・名刺
(非公開)限定関係者の個人通信

admin@ を分離する理由: info@は公開アドレス(Webサイト・特商法に記載)→ 攻撃対象になりやすい。 SaaS登録メールにはパスワードリセット等のセキュリティ関連メールが届くため、 admin@(非公開)に分離して認証メールと公開メールを構造的に分ける。

将来の拡張: Year 1-2でsupport@独立化、Year 2-3で個人アドレス独立化、Year 3+でadmin@のMFA専用化。エイリアスで論理分離しておけば、アドレス自体は変わらず外部サービスの書き換えが不要。

SNS・コンテンツ発信

全チャネルを SEEHUB で統一。 個別サービスのアカウントは作らない。一点集中でブランドを育てる。

note

深い記事・思想

YouTube

解説・対話

X

短い洞察・告知

Instagram

ビジュアル・引用

Facebook

コミュニティ

コミュニケーションのトーン

SEEHUB(法的文脈)堅実・簡潔・法的

「SEEHUB合同会社は、意識進化プラットフォームを運営しています」

SEEHUB(ブランド)静謐・知的・問いかけ

「見えれば、壁は溶ける。」

IPPUKU温かい・内省的・余白のある

「週にひとつの問い。10年かけて、自分に出会う。」

Part 3: 法的構造と問い合わせ導線

seehub.org / ippuku.seehub.org
 │
 ├── 公開ページ
 │ ├── FAQ(セルフサービス)
 │ ├── 利用規約(契約主体: SEEHUB合同会社)
 │ ├── プライバシーポリシー(管理主体: SEEHUB合同会社)
 │ └── 特定商取引法に基づく表記
 │ └── お問い合わせフォーム / 住所・電話: 請求時開示
 │
 └── 認証済みユーザーのみ(Clerk)
 └── サポートフォーム → カテゴリ選択 → 送信

「接触面を作らない設計」: Clerk認証がサポートフォームのフィルタとして機能し、 bot・営業・スパムが構造的に到達不可能。 住所・電話番号は消費者庁Q&A(A17)に基づき「請求時開示」で対応。

公開情報の設計

項目公開方法
事業者名SEEHUB合同会社(特商法ページに記載)
代表者名特商法ページに記載
住所「請求時、遅滞なく開示」
電話番号「請求時、遅滞なく開示」
法律用窓口各サービスのお問い合わせフォーム
サポート窓口ログイン後のサポートフォーム

Part 4: 全サービス共通インフラ

要素設計配置
特商法ページseehub.org/legal に一本化SEEHUB
プライバシーポリシーseehub.org/privacy に一本化SEEHUB
利用規約サービスごとに個別サービス
FAQseehub.org/faq にセクション別統合SEEHUB
法律用窓口各サービスのお問い合わせフォームSEEHUB
サポートフォーム各サービスのClerk認証内サービス
ドメイン*.seehub.org(サブドメイン方式)SEEHUB
Stripe descriptorSEEHUB* [サービス名]SEEHUB(静的prefix)

新サービス追加チェックリスト

  1. サブドメイン設定([service].seehub.org)
  2. 利用規約の作成(テンプレートから派生)
  3. FAQ セクションの追加
  4. Clerk認証内サポートフォームの設置
  5. 特商法ページの販売価格欄にサービスを追加(有料の場合)
  6. Stripe dynamic descriptor suffix の設定

特商法ページ・プライバシーポリシー・legal@は既存のものをそのまま使える。

Next Actions

法人登記 → 法的基盤整備 → サービス実装の順序で進行。

#タスク優先度状態
1SEEHUB合同会社の登記を実施P0法人名確定済み
2定款に英文表記「SEEHUB LLC」を併記P0#1と同時
3Stripe本番環境: statement descriptor を SEEHUB* IPPUKU に設定P0Stripeダッシュボードで設定(個人事業主でも可)
4メールアドレス体系構築(Google Workspace エイリアス7アドレス)P0完了 2026-03-14
5seehub.org/legal(特商法ページ)作成P0完了 — seehub /support/policy + ippuku /legal に配置
6seehub.org/privacy(プライバシーポリシー)作成P0完了 — seehub /support/policy に配置
7seehub.org/about(会社概要)作成P1完了 — seehub /company/about に既存
8全ページフッターに © SEEHUB を設置P0完了 2026-03-14(登記後にLLC追記)
9seehub.org/faq 作成(IPPUKU分から開始)P1完了 — ippuku /faq に既存(20問)
10SNSアカウント開設(SEEHUB名義、主要チャネル)P1未着手
11既存サイトのメールアドレスを体系に準拠して修正P0完了 2026-03-14
12Clerk認証内サポートフォーム実装P2未着手
完了
着手可能
未着手
依存待ち

TRUST検証

ORIGIN

法人名=ブランド名は最も一般的なパターン(CookPad、mixi等も最終的にこの形に移行)。インフラ設計であり独自性を求める場所ではない。

RESISTANCE

  • 「SEEHUB外の事業をやる余地がなくなるのでは?」→ 必要時に別法人を設立すればよい(合同会社設立費用は約6万円)。今存在しない事業のために全ユーザーに認知コストを負わせるのは本末転倒
  • 「SNSを一つに集約して大丈夫か?」→ 一点集中がYear 0の戦略と整合する
  • 「法人サイトがないのは問題では?」→ seehub.org/about で十分。法人名=サイト名なので自然

EXECUTION

法人名: SEEHUB合同会社(英文: SEEHUB LLC)。コピーライト: © SEEHUB LLC All rights reserved. Stripe descriptor: SEEHUB* IPPUKU。全接点で名前が一致。

TIP検証

C1 制約による解放

禁止: メールアドレスの公開表示、未認証ユーザーからの問い合わせ受付、個別サービスのSNSアカウント開設

接触面を作らないことでスパムゼロ。SNSを一本化することで発信力が集中する。法人名=ブランド名で全接点の認知が統一される。

C2 結合規約の単純さ

禁止: 最小の約束事: 2つだけ

(1) 全ての法的・顧客接点はSEEHUB (2) サポートはログイン後のみ。法人名とブランド名が同一なので「法的はX、顧客接点はY」の使い分けが不要になった。

C3 構造に検証を埋め込む

禁止: ドメインが*.seehub.orgで統一、法人名もSEEHUB

法人名・ブランド名・ドメイン名が全て一致。フッター、決済、明細、規約のどこを見てもSEEHUB。Clerk認証がフィルタそのもの。

C4 判断の記録

禁止: SEEHUB外の事業には別法人が必要(拡張性のトレードオフ)

受け入れた理由: (1) 合同会社設立は約6万円で低コスト (2) CookPad/mixiも法人名をブランド名に合わせた (3) チャージバックリスク(決済紛争45%が名前不一致起因)の排除が優先。

Source: docs/brand/BRAND_COMMUNICATION_DESIGN.md | 原本: Notion管理