---
title: "どこまで見せて、何と引き換えにするか — 選択肢と、それぞれで取れる情報"
type: operation
status: draft（濱風さまに選んでいただく前提。**決め打ちしていません**）
version: v1（2026-08-09）
gardener_generated: false
maintained_by: "手動（澤田）"
last_synced: "2026-08-09"
updated: "2026-08-09"
confidence: medium
tags: [cross_border, 需要データ, 認証, リード獲得, UIUX]
related: ["[[26-tech-decision]]", "[[25-demand-engine-v2-plan]]", "[[24-benchmark-research-metoree]]"]
---

> ## この資料の状態
>
> - **これは済んだものです。** 読み返す必要はありません（記録として残しています）
> - 8月14日の定例で、末尾の5問すべてに決着がつきました（必須＝メールアドレス・会社名／任意＝担当者名・電話番号。Google ログインは使わない）。方式ごとの比較は、なぜその形にしたかの背景として残します
>
> いま全体で何が動いているかは、共有ページの「いま動いていること」をご覧ください。
> （この欄は共有ページと同じ内容が自動で入ります。2026/10/2時点）

---


# どこまで見せて、何と引き換えにするか

> **これは「選んでいただく」ための資料です。** こちらの推奨は書きますが、決めるのは濱風さまです。
> **判断の軸は1つ**——「**濱風さまが本当に取りたい情報は何か**」。技術はその後についてきます。
> あわせて、**後から選び直せる作り**にしておく方法も書きます（§5）。認識がずれても作り直しになりません。

---

## 0. 決めることは2つだけです

| # | 決めること | 例 |
|---|---|---|
| **① 何を隠すか** | 商品名・仕様は全員に見せて、**価格とMOQだけ**隠す／カタログPDFだけ隠す／何も隠さない |
| **② 何と引き換えに見せるか** | メールアドレス／会社名も／何も要らない／その場では見せずに問い合わせだけ受ける |

**この2つの組み合わせが、そのまま「取れる情報」と「離脱の多さ」を決めます。**

---

## 1. 大前提 — 検索から集めたいなら、隠しすぎてはいけません

**Google は、ログインしないと見えない情報を評価しません。**

つまり**隠した部分は検索の武器になりません**。入口B（検索から見つけてもらう）を成立させるには、**商品名・仕様・メーカー・カテゴリ解説は全員に見せる必要があります**。

一方、**価格を出さないのは B2B では普通の作法**です（"Request a quote" が標準）。むしろ越境取引では、**条件（数量・仕向地・Incoterms）で価格が変わるのが当たり前**なので、固定価格を出さないほうが実務に合っています。

→ **「仕様は公開・価格は引き換え」が、SEO と B2B 実務の両方に適合します。** これを既定案とします。

---

## 2. 「何と引き換えに見せるか」の選択肢

**上から順に、摩擦が小さく・取れる情報が少ない**並びです。

| # | 方式 | バイヤーがすること | **取れる情報** | 離脱 | 偽情報 | 実装 | 預かる責任 |
|---|---|---|---|---|---|---|---|
| **0** | 何も求めない | なし | **匿名の行動だけ**（国・閲覧・検索語） | なし | — | 済 | なし |
| **1** | **メール入力で即開示** | メールを1つ入れる | **メール（未確認）**＋以後の行動が個人単位で繋がる | **極小** | 多い | 小 | メールのみ |
| **2** | **メールリンク方式**（推奨） | メールを入れ、**届いたリンクを押す** | **メール（確認済）**＋会社ドメイン＋以後の行動 | 中 | ほぼ無い | 中 | メールのみ |
| **3** | 登録フォーム | 氏名・会社名・電話・メールを入力 | **全部（未確認）** | **大** | 中 | 中 | **個人情報一式** |
| **4** | ソーシャルログイン | Google や LinkedIn で認証 | メール・氏名（確認済） | 中 | 無し | 中 | 少 |
| **5** | ID/パスワード登録 | アカウントを作る | 同上＋再訪しやすい | **最大** | — | 大 | **パスワード** |

### それぞれの「負ける条件」

- **0**：誰が見たか分からないので、**営業に繋げられません**。需要の傾向は分かりますが、電話をかける相手が特定できない
- **1**：`test@test.com` のような偽アドレスが混ざります。**営業リストとしての精度が落ちる**
- **2**：メールを開く手間があるぶん、**その場で価格を見たい人を取り逃がします**
- **3**：**海外バイヤーは電話番号を入れたがりません**。しかも初期のアクセスが少ない段階で摩擦を最大化すると、データが溜まる前に枯れます。**キーエンス・Metoree がこれをやれるのは、既に大量の訪問者がいるからです**
- **4**：**中国では Google が使えません**。LinkedIn も地域で普及率が大きく違います。**万国対応が要件の濱風さまには不向き**
- **5**：B2B の初回接触でアカウントを作らせるのは過剰。しかも**パスワードを預かると管理責任が発生します**（漏洩対策・リセット導線・保管方式）。**再訪問はメールリンクで足ります**

---

## 3. ご質問への直接の回答：パスワードの代わりは何か

**「メールリンク方式」です。Google ログインではありません。**

**動きはこうです。**

```
バイヤーが価格のところをクリック
   ↓
「メールアドレスを入れてください」だけ表示
   ↓
入力 → その場ですぐ価格が見える（← ここが肝心）
   ↓
同時に、そのメール宛に「あなた専用のリンク」を送る
   ↓
リンクを押した人＝メールが実在すると確認できた人
```

**パスワードを作らせません。覚えることもありません。** 次に来たときは、メールのリンクを押すだけで同じ状態に戻ります。

**なぜ Google ログインではないのか：**

1. **中国では Google が使えません**。濱風さまの取引先には中国・香港が含まれます
2. LinkedIn は B2B で有効ですが、**地域によって普及率が大きく違います**（アジア・中東では低い）
3. **メールアドレスは万国共通**で、B2B なら必ず持っています
4. そして——**濱風さまは既に「メールで固有リンクを送る」仕組みを作る予定です**（入口A）。**メールリンク方式は、その仕組みの使い回しです。新しい系を増やしません**

### 推奨：**1 と 2 を組み合わせる**

**メールを入れたら即座に価格を見せ、同時にリンクも送る。** リンクを押した人だけ「確認済み」に格上げする。

| 状態 | 意味 | 営業の扱い |
|---|---|---|
| 匿名 | 何も入力していない | 傾向の集計にだけ使う |
| **メール入力済（未確認）** | 価格を見た。アドレスは本物か不明 | 様子を見る |
| **確認済** | メールが実在し、本人が受け取った | **営業対象** |

**摩擦をゼロにしたまま、営業できる相手だけを選り分けられます。**

---

## 4. 「何を隠すか」の選択肢

| 案 | 全員に見せるもの | 引き換えで見せるもの | 向いている状況 |
|---|---|---|---|
| **A（推奨）** | 商品名・仕様・MOQ・メーカー・カテゴリ解説 | **価格・段階価格・カタログPDF・在庫** | 検索から集めたい。**SEOと両立** |
| B | 商品名・メーカーだけ | 仕様以下すべて | 情報を守りたい。**ただし検索で戦えない** |
| C | 全部見せる | なし（問い合わせだけ受ける） | **摩擦最小・誰が見たかは分からない** |
| D | 商品ページ自体を隠す | 全部 | **入口Bが成立しない**（Metoree の逆） |

> **補足**：Metoree は「メーカー一覧・製品情報は全公開／**カタログの一括ダウンロードで会員登録**」という形でした（robots.txt に `/login/*catalog_ids=` があることから実測）。**A に近い設計**です。

---

## 5. 🔴 認識がずれても作り直しにならない作り方

**ここが今回いちばん大事な部分です。** 上のどれを選んでも、**後から変えられる**ようにしておきます。

### 5-1. 「誰か」の記録は、方式に依存しない形で持つ

どの方式を選んでも、記録する中身は同じ形にします。

| 列 | 中身 | どの方式でも同じ |
|---|---|---|
| `identity_id` | 内部の識別子 | ○ |
| `email` | メールアドレス | 0以外なら埋まる |
| `verified` | 実在を確認できたか | 2・4なら真、1・3なら偽 |
| `company_domain` | メールのドメインから推定した会社 | 自動 |
| `display_name` / `phone` | 氏名・電話 | 3を選んだ場合だけ埋まる |
| `source` | どの入口から来たか（A/B/紹介） | ○ |
| `first_seen` / `last_seen` | 初回・最終 | ○ |

**方式を変えても、この表の形は変わりません。** 埋まる列が増えたり減ったりするだけです。

### 5-2. 「何を隠すか」は設定ファイルの1行で変える

```
gate:
  price:        "identified"     # 匿名 / メール入力済 / 確認済 のどれから見せるか
  price_tiers:  "verified"
  catalog_pdf:  "verified"
  stock:        "verified"
  spec:         "public"         # 仕様は全員（SEOのため）
  moq:          "public"
```

**「やっぱり仕様も隠したい」「価格は全員に見せたい」となっても、この行を書き換えるだけです。** 画面もデータ構造も作り直しません。

### 5-3. 認証の方式も差し替え可能にする

メールリンクの発行処理を**1つのファイルに閉じ込めます**。将来「やはり Google ログインも欲しい」「登録フォームにしたい」となっても、**そのファイルの差し替えで済みます**。呼び出し側（画面）は触りません。

### 5-4. なぜここまでするのか

**濱風さまがまだ実物を触っていないからです。** 画面を見て初めて「ここは隠したい」「ここは見せたい」が分かります。**その時に「作り直しです」と言わなくて済むように、変えられる形で作ります。**

---

## 6. こちらの推奨（現時点の想定に基づく）

**この想定で先に作ります。違っていたら §5 のとおり設定で直します。**

| 項目 | 推奨 | 理由（要件との紐付け） |
|---|---|---|
| 何を隠すか | **A**（仕様は公開・価格とカタログは引き換え） | 入口B（検索流入）を成立させるには仕様の公開が必須。価格を出さないのは B2B の標準作法 |
| 引き換え方式 | **1+2**（メール入力で即開示＋リンクで確認） | 摩擦を最小にしつつ、営業できる相手を選り分けられる。**入口Aの仕組みを使い回すので系が増えない** |
| パスワード | **作らせない** | 預かる秘密を増やさない。再訪はリンクで足りる |
| ソーシャルログイン | **入れない** | 中国で Google が使えない。万国対応の要件に反する |
| 電話番号 | **初回では聞かない** | 海外バイヤーは入力を嫌う。引合フォームで必要になった時に聞く |
| 会社名 | **メールのドメインから推定**し、引合時に本人に確認 | 入力項目を増やさずに精度を上げる |

---

## 7. 濱風さまに決めていただきたいこと

| # | 質問 | 選択肢 |
|---|---|---|
| 1 | **価格を、誰まで見せますか** | 全員 / メールを入れた人 / メールを確認できた人 / 見せない（問い合わせのみ） |
| 2 | **カタログPDF は** | 同上 |
| 3 | **初回に電話番号・氏名まで聞きますか** | 聞く（＝方式3・キーエンス型） / 聞かない（推奨） |
| 4 | **取りたい情報の優先順位は** | ①連絡先の数を最大化 ②連絡先の質（本物であること）を優先 ③行動データだけあればよい |
| 5 | 匿名のままでも「探しているものを教えてください」は受けますか | 受ける（推奨・**権利処理ゼロで需要が取れる口**） / 受けない |

> **4 が最も重要です。** ①なら方式1寄り（摩擦ゼロ・偽物混じり）、②なら方式2寄り（確認必須）、③なら方式0（何も求めない）になります。
> **「濱風さまが本当に取りたい情報は何か」で、他は自動的に決まります。**

---

## 8. 技術要件との紐付け（なぜ Astro のままでよいのか）

**ログインを入れても、前回の技術決定は変わりません。**

Astro は**ページ単位で静的と動的を切り替えられ**、さらに **Server Islands** という機能で「**静的なページの中に、その人だけの部分を後から差し込む**」ことができます（[Astro 公式](https://docs.astro.build/en/guides/server-islands/)）。

| 部分 | 作り方 | 効果 |
|---|---|---|
| 商品名・仕様・メーカー・解説 | **静的HTML（作り置き）** | 検索に載る。閲覧時にプログラムが動かない。壊れても前回版が出続ける |
| **価格・カタログのボタン** | **Server Island**（その場でサーバーが判定） | ログイン状態で表示が変わる |

**ページの器は静的のまま、価格の部分だけが人によって変わります。** 静的の利点（費用が寝ている・壊れ方が穏やか・計算時間の制限に当たらない）を、**公開部分については保ったまま**です。

> **前回の文書（26番）§6 の記述を訂正します。**
> 誤：「バイヤーのログイン制が v1 に入る → Next.js が妥当になる」
> 正：「**主戦場がログイン後にあるか**で分かれる。**検索から集めるのが主戦場で、ログインが価格を見るための導線なら、Astro のままが最適**」

---

## 9. この設計から生まれる、もう一つの効果

**入口B（検索から来た見知らぬ人）を、入口A（誰か分かっている相手）に変換できます。**

```
検索から来る（匿名）
   ↓ 価格のところで メールを入力
   ↓ 専用リンクをメール送信
誰か分かっている状態（＝入口Aと同じ）
   ↓ 以後の閲覧は企業単位で記録される
   ↓ 見積・サンプル依頼へ
```

**入口Aと入口Bが、別々の仕組みではなく1本の導線になります。**

そして——**キーエンスが会員登録という摩擦を払って得ているものを、濱風さまはメール1つで得られます**。もともと「メールで固有リンクを送る」設計を持っているからです。