---
title: "需要エンジン v2 — 海外バイヤーとつながるための実装計画（プル型統合版）"
type: operation
status: draft
version: v2（2026-08-10。**8/9 初回定例の議事録を反映**。v1 は議事録の取込前に書いたもので、v1 は `_archive/25-demand-engine-v2-plan-v1-20260809.md` に保存）
gardener_generated: false
maintained_by: "手動（澤田）"
last_synced: "2026-08-10"
updated: "2026-08-10"
sources:
  - "**議事録: 第1回_澤田さんAI定例 2026-08-09**（`Hamakaze_admin` → `wiki_system/raw/meet/...__1oaSkJAn6v3A.md`・Gemini 自動要約）"
  - "[[operations/deliberations/モート③_世界の需要データ]]（濱風 Wiki・last_synced 2026-08-10・**自動集約**）"
  - "[[operations/ideas/AI-BtoB需要データエンジン]]（濱風 Wiki・2026-07-31 更新）"
  - "[[operations/ideas/濱風オンラインカタログの整備と多面掲出]]（同・2026-07-27 更新）"
  - "[[insights/platform_intelligence]] / [[insights/ai_search_optimization]] / [[insights/category_intelligence]]"
  - "[[08-需要エンジン-実装計画たたき台]] v7"
  - "[[24-benchmark-research-metoree]]（8/9 実測） / [[26-tech-decision]]（8/9 技術構成の裁定）"
confidence: medium
tags: [cross_border, 需要データ, カタログ, SEO, 実装計画, 海外向け]
related: ["[[24-benchmark-research-metoree]]", "[[16-イベント定義]]", "[[14-営業接続の設計]]"]
---

> ## この資料の状態
>
> - **これは済んだものです。** 読み返す必要はありません（記録として残しています）
> - **8月22日の定例で2点とも決まりました**。①購買代行の形＝当面は問い合わせベースを維持（サンプル購入など限定的な機能から検討）②検索で戦う対象＝商品ページではなくメーカー情報とカテゴリ紹介に絞る。
>
> いま全体で何が動いているかは、共有ページの「いま動いていること」をご覧ください。
> （この欄は共有ページと同じ内容が自動で入ります。2026/10/2時点）

---


# 需要エンジン v2 — 海外バイヤーとつながるための実装計画

> **目的は1つです。海外のバイヤーとつながること。**
> 需要データも、カタログも、検索順位も、すべてその手段です。目的と手段が入れ替わらないように書きます。
> **すべて海外向け前提**で書いています。日本国内向けの検討は含みません。

---

## この版（v2）で変わったこと — 8/9 定例の議事録を反映

**v1 は 8/9 の夜に書きましたが、その時点で定例の議事録はまだ Wiki に取り込まれていませんでした。** 8/10 に取り込まれたので突き合わせました。突合の全文は `planning/reports/inbox/NOTE-20260810-demand-engine-meeting-reconciliation.md`。

| # | 変わった点 | どこ |
|---|---|---|
| 1 | **商品を「持つ／持たない」を面ごとに分けた**。定例で合意された購買代行モデルと、同じ定例で合意された「検索流入の最大化」は、そのままでは両立しないため | §2-4・§5 |
| 2 | **カテゴリの絞り込みを入口別にした**。入口A は絞らない（7/23 の決定どおり）／入口B は絞って深く作る | §2-5 |
| 3 | **決済の要否が閉じた**。v1 は「注文申込で足りるか要確認」だったが、定例で「決済は難易度が高く優先度は検討事項」と確認された | §9-1 |
| 4 | **Phase 1 の第1カテゴリを化粧品に変更**（定例で優先方針が出たため。日本酒は第2候補） | §7 |
| 5 | **解説文を画面に出さない件**は「折りたたみなら可・HTML埋込は不可」を明記 | §4-2 |
| 6 | **レビュー・ランキング**を「やらない」から「v1では出さない・置き場所は作る」へ | §10 |
| 7 | **技術基盤の記述を Astro + Cloudflare に修正**（v1 の §8 は Next.js + Vercel のままで、執筆時点で既に古かった） | §8 |
| 8 | サプライヤーフォームに **AI 自動補完**の要望が加藤さんから出た | §7 Phase 2 |

**変わっていないもの**: 目的（海外バイヤーとつながる）、3つの入口、5層の骨格、権利処理ゼロで着手する方針。

---

## 0. 先に結論

**作るのは「1つの商品データベース」と「3つの入口」です。**

| 入口 | 誰が来るか | 既存の呼び方 | 状態 |
|---|---|---|---|
| **A. 送る**（メール＋固有リンク） | こちらが選んだバイヤー | 需要データエンジン（Wiki 既定） | 要件 v7 で設計済 |
| **B. 見つけてもらう**（検索・AI検索） | 見知らぬバイヤー | — | **8/9 に追加。本計画の主題** |
| **C. 他所に置く**（YUGUO・CCEE・alibaba 等） | 各プラットフォームの客 | 多面掲出（Wiki 既定） | 方針のみ・未着手 |

**3つとも同じ商品データベースの上に乗ります。** 別々に作ると3回作ることになります。

そして**入口Bには、権利処理をまったく必要としない着手方法があります**（§3）。ここから始めれば、商品掲載の許諾交渉を待たずに、**今月中に海外バイヤーの需要データが取れ始めます**。

---

## 1. 濱風が既に決めていること（Wiki から確認）

**この計画は、ゼロから提案するものではありません。** Wiki に書かれている決定を、実装できる形に落とすものです。

### 1-1. 需要データエンジン（`operations/ideas/AI-BtoB需要データエンジン`・2026-07-31 更新）

- 主目的 = **需要データ収集エンジン**。購買を必須にしない
- 計測は**受信者ごとの固有リンク**
- **広告もメールも両方使う。粒度が違うだけ**（広告は地域単位の粗い粒度）
- 掲載商品 = **契約済みクライアント＋見込商品の混合**
- **見込商品は「無償掲載＋反応データ共有」と引き換えに掲載許諾を先行取得。それ自体が GLOBAL DESK 営業のフック**
- **カテゴリも地域も広く。こちらの業種・地域判断で絞り込まない（バイアス排除）。全員同じ単一カタログを自由に回遊させる**
- 表示順はランダム／お気に入りはログイン不要／**購買導線は作る**（2026-07-29 加藤さん確定）
- **言語は英語正＋AI多言語版を最初から**
- パイロットは1ヶ月。成功基準 = **需要マトリクスを根拠に配分判断を実際に1件以上行うこと**

### 1-2. オンラインカタログ（`operations/ideas/濱風オンラインカタログの整備と多面掲出`）

- 自前カタログを整備し、**掲出先を複数持つ**（自前／YUGUO ソーシングDB／CCEE distribution）
- 掲出は**1年更新**。古い情報が載り続ける状態を防ぐ
- **契約が終わった顧客の掲出も残す**（「売れなかったが、これは残った」と言える状態）

### 1-3. 全社方針（`insights/platform_intelligence` 冒頭）

> 濱風は全世界対応型として、**共通在庫から複数プラットフォームへ世界同時多発出店**する。（…）**特定PFを前提・筆頭としない**

### 1-4. AI検索の方針（`insights/ai_search_optimization`・2026-06-05 deep-research 済）

- 従来SEO + E-E-A-T の土台維持が最優先。Google は GEO を "still SEO" と位置づけ
- **オウンドコンテンツは AI が参照するソースのわずか5-10%**（McKinsey）。**マルチプラットフォーム露出が事実上の必須条件**
- 記事は**自己完結型の段落**で書く（結論先出し・Q&A型見出し）
- llms.txt・AI専用schema に工数を割かない
- **最終資産は「所有するオーディエンス」**（メール・指名検索・直接来訪）

---

## 2. 🔴 既存決定と、8/9 の方針が食い違う点（先に潰します）

**放置すると実装の途中で矛盾が表面化します。** 5件あります（**2-4・2-5 は 8/9 の議事録を読んで追加**）。

### 2-1. 「自前サイトで検索から集める」は、既存方針と正面から衝突しないか

**衝突しません。ただし条件が付きます。**

Wiki の AI検索方針は「**オウンドの天井は5-10%。マルチプラットフォーム露出が必須**」と明記しています。つまり**自前サイト一本足の集客は、濱風が自分で否定している戦略**です。

一方で「多面掲出」「世界同時多発出店」も既に決まっています。したがって正しい読み方はこうです。

> **自前サイトは「集客の主役」ではなく「需要データを取れる唯一の面」として作る。**
> 集客そのものは、自前サイト＋複数PF＋広告＋メールの**合計**で取る。

**自前サイトにしかできないことは1つです——「誰が・何を・どこまで見たか」を濱風が所有すること。** YUGUO や CCEE に出しても、その行動データは濱風のものになりません。ここが自前を作る唯一かつ十分な理由です。

### 2-2. 「カテゴリも地域も広く・全員同じ単一カタログ」 vs 要件 v7 の「10〜20商品・1社1リンク」

**Wiki の決定（広く・単一カタログ）が上位です。** v7 の「10〜20商品」は**パイロットの初期規模**であって、思想ではありません。

ただし1点、**技術的に両立させる必要があります**。「全員同じ単一カタログ」と「受信者ごとに表示順をランダム固定」は、**同じ商品集合を、受信者ごとに違う順で見せる**という意味で両立します（商品を絞るのではなく、順番だけを変える）。ここは v7 の設計のままで問題ありません。

### 2-3. 「購買導線は作る」（7/29 加藤さん確定）が、v7 では「未確定」のまま

**v7 の分岐①「即時オンライン決済は必要か」は、実は 7/29 に方向が出ています。**

> 購買導線は作る（2026-07-29 更新）。三段のどこに転んでも価値が出る設計にするため。①その場で購買されてもよい ②買われなくても興味のある商材が分かるので後から営業できる ③それでも買われなくても需要地図は残る

**ただし「購買導線を作る」と「カードで即時決済する」は別物です。** 三段の①は「注文の意思をその場で受け取れる」で足ります。

> ✅ **8/9 の定例で閉じました。** 「まずは SEO や AI からのトラフィックを最大化し、**見積依頼の獲得を優先**する。**決済機能の実装は難易度が高いため、優先度は検討事項**」と確認されています。
> **v1 は「見積依頼・サンプル・注文申込」まで。カード決済は作りません。** 7/29 の「購買導線は作る」とも矛盾しません（三段の①を満たすため）。

---

### 2-4. 🔴【最重要】「商品情報を保持しない購買代行モデル」と「検索流入の最大化」は、そのままでは両立しない

**8/9 の定例では、次の2つが同じ場で合意されています。**

| # | 合意内容 |
|---|---|
| ② | 商品情報を自社サーバーに**保存せず**、リンク表示で**購買代行**として機能させる（ZenMarket 型）。著作権とデータ保持の法的リスクを避けるため |
| ③ | **検索と AI 検索からの流入を最大化**し、見積依頼を優先する |

**問題**: 検索エンジンが順位を付ける対象は「自分のサイトにある実体のあるページ」です。商品情報を一切持たない＝インデックスされる面が無い、という意味になると、③が達成できません。

**さらに、②の前提そのものが正確ではありません。**

- **保存しなければ安全、ではありません。** 画像を自分のサイトに表示すれば、ファイルを持たずリンクで読み込む形でも公衆送信に当たりうる、というのが実務上の理解です。**「保存の有無」は分岐点になりません**
- 逆に、**保存しても問題にならない情報が大量にあります**。§3-1 のとおり、権利は**要素ごとに違います**（事実情報に著作権はありません）

**したがって推奨は「どちらか」ではなく「面ごとに分ける」です。**

| 面 | 持ち方 | 理由 |
|---|---|---|
| メーカー一覧・カテゴリ解説・規制記事（＝**検索で戦う面**） | **自前で持つ** | 濱風が書いたオリジナル。著作権の問題が構造的に発生しない。**③はここで達成する** |
| 商品の実体（**画像**・メーカーが書いた説明文） | **持たない／リンクで飛ばす**（購買代行型） | **②の狙いはここで満たされる** |
| 商品の事実情報（型番・仕様・容量・MOQ・納期・価格） | **自前で持つ** | 事実情報に著作権はない。**ここが無いとサイト内検索（層3）が成立しない** |

**この分け方なら②と③の両方を満たします。** 5層の骨格（§5）はそのまま使え、**層4（商品ページ）の扱いだけが変わります**。

**ただし、失うものを正直に書きます。** 商品の実体を外部リンクに出すと、**遷移先での行動は見えません**。「一覧のどこでスクロールが止まったか、どの商品を開き、詳細のどこで止まったか」は先方 Wiki が定義した需要データの中核なので、**購買代行型に倒すほど需要データの粒度は下がります**。

> **これは技術の選択ではなく事業の選択です。**「法的な安全」と「需要データの粒度」のどちらをどれだけ取るか。
> **次回定例の主題**にすべき論点であり、こちらが勝手に決めてよいものではありません（§9-1 #13）。

---

### 2-5. 🔴「抹茶のようなニッチに絞って始める」の不採用は、入口の違いを見ていない

**経緯**

| いつ | 何が起きたか |
|---|---|
| 7/23 | `/grill-me` で「カテゴリも地域も絞らない」と決定。理由＝**何が求められているかを確認する取組みで、濱風側が絞ると目的が消える** |
| 8/9 | 佐瀬さんが「最初は抹茶のようなニッチに絞って開始」を提案。理由＝**スパム判定のリスクを避け、段階的に拡大する** |
| 8/10 | 先方 Wiki に「**8/09 の案は不採用**（7/23 の判断を維持）」と記載。ただし**このページは `gardener_generated: true` ＝ AI の自動集約**で、人が判断したとは限らない |

**7/23 の「絞らない」は、入口A（こちらが選んだバイヤーへ送る）については完全に正しいです。** 送る相手が決まっている以上、見せる範囲を濱風側が絞れば、それは濱風の仮説を確かめているだけになります。

**しかし入口B（検索で見つけてもらう）には当てはまりません。** 薄いページを全カテゴリに大量展開すると、Google のスパムポリシー "Scaled content abuse" の**例示と逐語で一致します**（§4-1）。**佐瀬さんの懸念は、こちらの調査結果と同じ方向を向いています。**

**推奨（入口別に分ける）**

| 入口 | カテゴリ | 理由 |
|---|---|---|
| **A. 送る**（固有リンク） | **絞らない** | 7/23 の判断のとおり。バイアスを入れると需要地図の意味が消える |
| **B. 見つけてもらう**（検索） | **絞って深く作る**（1〜2カテゴリから） | 薄いページの大量展開は、順位が付く前に飛ぶ。深さで戦う面 |

**この分け方は 7/23 の決定を否定しません。** 7/23 の時点では入口B が存在しなかった（8/9 に追加された）ので、そもそも判断の対象外でした。

---

## 3. 🟢 権利処理ゼロで、今月から需要データが取れる方法

**ここが本計画で一番使える部分です。**

商品を載せるには許諾が要ります。しかし**許諾がまったく要らない層だけで、検索流入と需要データの両方が取れます**。

### 3-1. 権利は「要素ごと」に違う

| 要素 | 権利 | 載せられるか |
|---|---|---|
| 会社名・所在地・創業年・資本金・従業員数 | 事実情報 | **載せられる** |
| 商品名・型番・メーカー名 | 事実情報 | **載せられる** |
| 仕様・寸法・成分・容量・原材料 | 事実情報 | **載せられる** |
| 価格・MOQ・納期 | 事実情報 | **載せられる**（正確なら） |
| 商品説明文 | 創作性があれば著作権 | コピーはNG／**書き直せばOK** |
| **商品画像** | 写真の著作権・ロゴの商標 | **NG。ここだけが本当の壁** |

> **無断転載は日本で実際に負けています。** 東京地裁 令和4年11月4日・12月22日判決で、商品写真と説明文の無断掲載が著作権侵害と認定され、**2週間程度の利用でも5万円**（1商品あたり）の賠償。数千点で桁が変わります。

### 3-2. 画像がなくても商品ページは成立します

電子部品大手 **Digi-Key** は、画像がない商品ページに「**Image is not available**」と表示したまま、**仕様表・データシート・CADモデルだけで**商品ページを成立させています。

**B2Bバイヤーが本当に見るのは、写真ではなく「仕様・MOQ・認証・納期・供給可能地域」です。**

### 3-3. だから、こう始めます

**第1弾＝「日本メーカー一覧（英語）」。権利処理ゼロ、今週から着手できます。**

海外バイヤーが `Japanese sake manufacturers` `Japanese cosmetics OEM suppliers` `Japanese functional textile makers` で検索したときに着地する面を作ります。

各メーカーページに載せるもの:

| 項目 | 出どころ |
|---|---|
| 会社名（英語表記）・所在地・創業年・規模 | 公開情報（事実） |
| 取扱カテゴリ | 公開情報 |
| 公式サイトへのリンク | 公開情報 |
| **輸出実績の有無・対応可能地域** | **濱風が知っている情報** |
| **英語対応の可否・MOQ の目安・リードタイム** | **濱風が知っている情報** |
| **濱風が仲介できるか（Contact via Hamakaze）** | **濱風にしか書けない** |

> **最後の3行が決定的です。** 単なる名簿は Google に「読者に価値がないページ」と判定されます（§4）。**濱風にしか書けない情報を足すことで、コピーではなくオリジナルになります。** そしてバイヤーにとっても、名簿より「連絡が取れるかどうか」の方が価値があります。

---

## 4. 🔴 Google のルールが2024年に変わっています（回避策つき）

### 4-1. 何が問題か

Google 公式のスパムポリシーに「**Scaled content abuse**（大量生成コンテンツの不正使用）」という項目があります。禁止例の逐語:

> "Scraping feeds, search results, or other content to generate many pages (including through **automated transformations like synonymizing, translating**, or other obfuscation techniques), where little value is provided to users"

> "Creating many pages where **the content makes little or no sense to a reader but contains search keywords**"

**8/9 に出た「解説文を表示しなくても検索でワードが引っかかればいい」「翻訳メインで大量に」という進め方は、この2つに逐語で当たります。**

**Metoree が成功したのは 2017〜2020年代前半で、Google がこの方針を大規模に執行し始めたのは 2024年3月以降です。** 同じ手を今から始めると、順位が付く前に飛ぶ可能性があります。

> ⚠ 濱風の既存 SEO 知見（`insights/ai_search_optimization`・2026-06-05）は AI検索の観点で非常に精緻ですが、**このスパムポリシーの観点は入っていません**。追記を推奨します。

### 4-2. 回避策 — 面ごとに「誰が書くか」を分ける

**Google が禁じているのは「価値を足さずに量を増やすこと」であって、翻訳そのものではありません。質の高い内容を翻訳するのは許容範囲です。**

| 面 | 誰が書くか | 理由 |
|---|---|---|
| **カテゴリ解説**（"Japanese Sake for Export: What Buyers Should Check"） | **人が書く**（AI下書き＋人の加筆） | 検索の主戦場。ここが薄いと全体が沈む |
| **メーカーページ** | 事実情報＋**濱風の一次情報3行**（§3-3） | 一次情報がオリジナル性を担保 |
| **商品ページ** | **機械翻訳で可** | 検索の主戦場にしない。ログイン後・リンク経由で見る面 |
| **規制・実務の記事** | **人が書く** | 後述（4-3）。ここが最大の武器 |

### 4-2b. 「解説文を画面に全部出さなくてよい」は、やり方次第で違反になります

8/9 の定例で「SEO のために解説文は必要だが、**UI 上の可読性を考慮して、必ずしもすべてをフロントに表示しなくてよい**のでは」という提案が出ました（加藤さん）。**意図は理解できます**（読みにくい長文で画面を埋めたくない）。**ただし実装方法によっては、Google の禁止事項に直接当たります。**

| やり方 | 可否 |
|---|---|
| **折りたたみ（アコーディオン）で畳んでおく。ユーザーが開けば読める** | **可**。Google は折りたたみコンテンツを通常どおり評価すると明言している |
| **別ページに分けて内部リンクで繋ぐ** | **可** |
| 画面に出さず HTML にだけ置く／背景色と同色にする | **不可**（隠しテキスト。§4-1 の「読者には意味をなさないが検索キーワードを含む」にも当たる） |

> 次回定例では「やめましょう」ではなく「**畳むのは大丈夫です**」と返すのが正しい形です。

### 4-3. 🟢 濱風には「カテゴリ解説を書く材料」が既にあります

**これは今回いちばん大きな発見です。**

Wiki の `insights/category_intelligence` に、**カテゴリ別の市場知見が既に蓄積されています**。

日本酒・アルコール（HKTVmall 実績、競合構造、北米展開）／メンズアパレル／食品・地域産品／ウェアラブル・IoT（hamon band）／化粧品／メンズスキンケア（規制含む）／オリーブオイル・輸入D2C／小型家電・雑貨／伝統工芸・地域産品／**ホームテキスタイル（難燃規制が仕向地ごとに分岐する、という実務知見つき）**

**Metoree の起点資産は「9,634カテゴリの解説文」でした。濱風は同じものを、実務経験に基づいて既に書き始めています。**

さらに、この知見には**規制情報**が含まれています。これは決定的です——

- 競合 umamill も、記事で戦っています（"Importing Japanese Food to the U.S.: FDA, FSVP & Labeling" 等）
- **規制・実務の記事は、AI が要約しても価値が減りません**（読者が実際に手続きする必要があるため）
- Wiki の AI検索方針が言う「自己完結型の段落・結論先出し」と相性が良い

> **推奨**: カテゴリ解説の第1弾は「**その国に輸入するとき何が要るか**」から書く。SEO のためでなく、バイヤーが本当に困っているからです。結果として §4-1 のリスクも回避されます。

---

## 5. アーキテクチャ — 1つの商品DB × 5層

| 層 | 中身 | 元ネタ | 権利処理 | 検索流入 |
|---|---|---|---|---|
| **1. メーカー一覧** | 日本メーカーを英語で掲載。事実情報＋濱風の一次情報3行 | Metoree の企業層 | **不要** | ◎ ロングテール |
| **2. カテゴリページ** | 大中小の階層 ＋ 解説（**人が書く**）＋ 規制記事 | Metoree ＋ umamill | 自作 | ◎ 主戦場 |
| **3. サイト内検索** | **外国語→日本語に変換して検索。全クエリを記録（0件も記録）** | ZenMarket | **不要** | — |
| **4. 商品ページ** | ①自社取扱＝自前撮影 ②許諾済＝一括取込 ③未許諾＝**事実情報のみ・画像なし**（Digi-Key型）＋**メーカー公式へのリンク**（購買代行型） | Metoree（登録制）＋ Digi-Key ＋ ZenMarket | 段階取得 | ○ |
| **5. 引合の受け口** | 見積・サンプル・注文申込（＝要件 v7 の CTA 3種がそのまま乗る）。**カード決済は作らない**（8/9 定例） | 濱風独自 | — | — |

> **層4 は「持つ／持たない」を要素で分けます**（§2-4）。**画像とメーカーの説明文は持たず**リンクで飛ばす（＝定例で合意された購買代行モデル）。**型番・仕様・容量・MOQ・納期・価格の事実情報は持つ**（著作権がなく、ここが無いと層3の検索が成立しない）。

### 5-1. 層3が本命です（商品ゼロでも需要が測れる）

ZenMarket の実装（2024年9月アップデート）:

> 日本語以外の言語で商品検索を行った際、**検索キーワードが自動的に正確な検索結果を得られる日本語に翻訳・最適化**され（…）検索結果画面には、**元の外国語キーワードと変換後の日本語キーワードが両方表示**されます

海外バイヤーが `yuzu kosho wholesale` と打つ → 内部で「柚子胡椒 卸」に変換して検索 → **元の外国語も保持**。

**なぜこれが本命か:**

- **商品が1点も載っていなくても需要が取れます**（0件ヒットでも「探された」ことは記録される）
- **0件だった検索こそが宝**です。「探されたのに濱風に無かったもの」＝ 次に仕入れる／次に許諾を取るべき対象
- Metoree の「検索上位から新カテゴリを増やす」戦略も、**推測ではなく実データで**決められます
- 実装が軽い（翻訳API＋検索＋ログ）

### 5-2. 需要データは3種類になります

| 種類 | 取れる場所 | 粒度 | Wiki の既存定義 |
|---|---|---|---|
| **検索クエリ** | 層3 | 言語・地域・時刻（企業は不明） | **新規** |
| **閲覧行動** | 層1・2・4（入口A の固有リンク経由なら企業単位） | **企業単位** | 需要データエンジンの本体 |
| **引合** | 層5 | 企業＋商品＋数量 | 同上 |

---

## 6. 「どの会社が見ているか」— 買えます

8/9 に共有された「アクセス元の IP アドレスを特定してインテントセールスに活用」という手法について。

**自作する前に、濱風が既に知っている既製品を評価してください。**

Wiki の `insights/platform_intelligence` に記載があります:

> **OKKI（海外営業SaaS）**
> - 企業DB 2億社超（貿易取引データ・担当者情報含む）
> - **バイヤーの90日行動履歴を可視化**
> - 料金：年間66万円 or **alibaba.com連携で月3万円**

**月3万円です。** 自作すると、企業判定のデータベース（IPアドレスと企業の対応表）を自前で持つ必要があり、これは買うしかありません。

> ⚠ ただし **EU 圏では、IPアドレスから企業を特定する手法は GDPR 上の扱いに注意が要ります**。米国・アジアが主戦場なら相対的に問題は小さくなります。**対象地域が決まるまで、この機能は後回しで構いません**（§9-2）。

---

## 7. 実装フェーズと優先順位

**「権利処理が要らないもの」「既にあるもの」から順に並べています。**

### Phase 1 — 今月（権利処理ゼロ・許諾交渉を待たない）

| # | やること | 完了の目安 | 依存 |
|---|---|---|---|
| 1-1 | **メーカー一覧（英語）の型を1カテゴリ分作る**（**第1候補＝化粧品**。第2候補＝日本酒。10〜20社） | 1カテゴリが公開され、Google にインデックスされる | なし |
| 1-2 | **カテゴリ解説を1本、人が書く**（「米国へ化粧品を輸出するとき何が要るか」＝ FDA MoCRA・成分規制 等）。材料は `category_intelligence` にある | 1本公開 | なし |

> **第1候補を化粧品にした理由**（8/9 定例で「海外と国内の双方で需要が高くプレイヤーが多い」ため化粧品を優先する方向と確認された）
> - 化粧品は各国の規制が重い（薬機法・EU CPNP・FDA MoCRA）＝ **§4-3 の「規制記事が最大の武器」がそのまま効く**
> - 先方 Wiki の `insights/category_intelligence` に**化粧品・メンズスキンケア（規制含む）の知見が既にある**
> - ⚠ ただし英語圏の "Japanese cosmetics supplier" 系は**競合の強さが未確認**（§9-3 #12）。1本書いて順位の付き方を見てから2本目を決める
| 1-3 | **サイト内検索＋クエリ記録**（外国語→日本語変換つき） | 0件検索も含めて記録され、週次で一覧が出る | なし |
| 1-4 | **引合の受け口**（見積・サンプル・「この商品を探しています」の3種） | 送信でき、Google Chat に通知が飛ぶ | 既存 pm/notify.py を流用 |

**Phase 1 の成果物**: 「海外バイヤーが何を探しているか」の週次リスト。**商品を1点も載せずに得られます。**

### Phase 2 — 来月（許諾を取りながら厚くする）

| # | やること | 依存 |
|---|---|---|
| 2-1 | **h3yun サプライヤー登録フォームに英語列を追加**（現在は日本語・中国語のみ。英語がない） | h3yun 側の改修 |
| 2-1b | 🆕 **入力フォームの負担を下げる**＝**AI がカタログPDF等から自動で埋め、不足分だけ人に聞く**形へ。**8/9 に加藤さんから出た要望**。`26-tech-decision §8` の確認4（既存フォームを作り直してよいか）と一体で判断する | 2-1 と同時 |
| 2-2 | **umamill との商品情報の提携**（6,800商品・1,900メーカー）。**8/9 に「競合ではなく物流パートナー」と確認された**ので交渉の前提が固まった。※検索面の衝突回避は別途決める（§9-3） | 交渉 |
| 2-3 | 商品ページ（Digi-Key 型＝仕様のみ・画像なしでも公開可） | 2-1 or 2-2 |
| 2-4 | Phase 1 のクエリデータを持って**メーカーへ営業**（「あなたの商品が月◯件検索されています。無償掲載＋反応データ共有でいかがですか」＝ Wiki の既定路線） | Phase 1 のデータ |

### Phase 3 — 秋（既存の需要エンジン v7 と接続）

| # | やること |
|---|---|
| 3-1 | 入口A（メール＋固有リンク）を同じ商品DBの上に載せる。要件 v7 の設計をそのまま使う |
| 3-2 | 多面掲出（YUGUO ソーシングDB・CCEE distribution）へ同じデータを流す |
| 3-3 | 需要マトリクスで配分判断を1件行う（＝ Wiki の成功基準） |

---

## 8. 既存資産の再利用マップ（新規に作らないもの）

| 必要なもの | 既にあるもの | 状態 |
|---|---|---|
| 商品データの入り口 | **h3yun サプライヤー登録フォーム**（1商品=1行、Sheets、画像はDrive、承認はstatus列） | **稼働中**。英語列の追加のみ |
| 商品マスタ | 同上の Google スプレッドシート | 稼働中。**シートが正本のまま。作り置きの時だけ読む**（`26-tech-decision §5-3`） |
| 通知 | `pm/notify.py`（Google Chat） | 稼働中 |
| カテゴリ解説の材料 | `insights/category_intelligence`（10カテゴリ以上） | **蓄積済み**。英語化と加筆 |
| バイヤー行動の可視化 | **OKKI**（月3万円〜） | 未契約・評価対象 |
| SEO の方針 | `insights/ai_search_optimization` | **策定済み**。スパムポリシーの追記を推奨 |
| 掲出先 | YUGUO ソーシングDB / CCEE distribution / alibaba+OKKI / HKTVmall | 方針決定済・登録要件は未確認 |
| 技術基盤 | **Astro（静的生成）+ Cloudflare（Workers / D1 / R2）** | **8/9 に裁定済**＝`[[26-tech-decision]]`。**Cloudflare への移行は 8/9 の定例で先方と合意済み**。~~Next.js + Vercel / Supabase~~ は不採用（Vercel は無料プランの商用利用が規約上不可・Supabase 無料枠は1週間無操作で停止） |

**新規に作るのは、層1〜3の画面と、クエリ記録の仕組みだけです。**

---

## 9. 濱風に確認すること

### 9-1. 加藤さんへ（構成が変わる）

| # | 確認 | なぜ効くか |
|---|---|---|
| 1 | ~~「購買導線は作る」（7/29）は、カード即時決済まで含みますか~~ | ✅ **8/9 の定例で解決**。「決済は難易度が高く優先度は検討事項」＝ **v1 は注文申込まで** |
| 2 | **最初の対象地域はどこですか**（米国／アジア／EU） | EU は個体レベルの追跡に同意UIが必須。IP企業特定（§6）の可否も変わる。**8/9 も未確定のまま** |
| 3 | **反応が来たときに動くのは誰ですか。何営業日以内ですか** | v7 の実装停止条件。ここが空欄だと装置は動くのに商談が生まれない。**8/9 も未確定のまま** |
| 4 | **「勝手に大量に載せる」はメーカー許諾なしという意味ですか** | §3 のとおり、画像と説明文だけが壁。事実情報は載せられる。**全部か無かの二択ではありません** |
| **13** | 🆕 **購買代行モデル（商品情報を保持しない）は、どこまでを指しますか。** 画像とメーカーの説明文だけを外に出す形（推奨・§2-4）で意図に合っていますか。**事実情報まで持たないと、サイト内検索も需要データも成立しません** | **本計画で最大の分岐**。ここが決まらないと層3・層4 の実装に入れない |
| **14** | 🆕 **需要データの粒度をどこまで諦めますか。** 商品の実体を外部リンクに出すほど「詳細のどこで止まったか」は取れなくなります | 先方 Wiki が定義した需要データの中核部分。**法的な安全との取引になります** |
| **15** | 🆕 **8/10 に Wiki へ載った「抹茶案は不採用」は、どなたの判断ですか** | あのページは AI の自動集約です。**入口B（検索）については絞る方が安全**なので、人の判断なら理由を伺いたい（§2-5） |

### 9-2. 佐瀬さんへ（Metoree の内部知識でしか答えられない）

| # | 確認 | なぜ効くか |
|---|---|---|
| 5 | 🔴 **カテゴリ解説文は誰が何人で、どれくらいの期間で積みましたか** | 濱風が同じ道を行けるかが即断できる。**最重要・8/9 も未回答** |
| 6 | 🔴 **2024年以降に新設したカテゴリでも、同じように検索順位が取れていますか** | §4 のリスクが現実のものかを判定できる唯一のデータ。**8/9 も未回答** |
| 7 | ~~掲載無料で集めていた助走期間と、広告が売れ始めたトラフィック規模~~ | 🟡 **8/9 に部分回答**＝収益源は **PR枠の販売（特定カテゴリの最上位表示・月額約10万円）**。無料枠で情報を集約して検索上位を取る「正の循環」。ただし**助走の長さと規模は未回答** |
| 8 | 🔴 **海外版（英・独・仏・西・韓）は日本版が軌道に乗ってからですか。解説文は翻訳流用ですか。海外版で収益は出ていますか** | 濱風は最初から海外向け。**ここが最も知りたい・8/9 も未回答** |
| 9 | ~~IP から企業を特定する手法の**実務精度**~~ | 🟡 **8/9 に部分回答**＝IPを公開DBと**ドメイン照合**。**中小企業や自社サイトの無い企業は特定できない**。精度の数値は未回答だが、**§6 の「自作せず OKKI 月3万で買う」の判断には十分** |

### 9-3. 両者へ

| # | 確認 |
|---|---|
| 10 | **umamill とは検索面でどう役割を分けますか**。同じ商品説明が両サイトに出ると、Google はどちらか一方しか表示しません。分け方の候補＝言語／地域／カテゴリ／**濱風側は説明文を書き直す** |
| 11 | 島崎酒造の日本酒は umamill の領域と重なりませんか（先方は既に米国向けの日本酒記事を出しています） |
| 12 | 最初に検索1位を取りにいく**言語**はどこですか（英語圏は競合の強さが桁違いです） |

---

## 10. この計画で「やらないこと」

- **自前サイト単独での集客**（Wiki の「オウンドは5-10%が天井」に反する）
- **解説文の機械翻訳による大量生成**（§4-1）
- **商品画像の無断転載**（§3-1・判例あり）
- **「N人が見ています」の買い手向け表示**（母数が小さいと需要の弱さを露出し、他社の関心も見えてしまう。データは取るが表示しない）
- **月次ランキング・企業レビュー・エリア検索を「画面に出す」こと**（大量の選択肢を絞る道具。母数が足りないと機能せず、レビュー3件のランキングは需要の弱さを自分で露出する）
  - 🆕 **ただし 8/9 の定例で「AI 検索・Google 検索の流入にはレビューとランキングが重要」「自社でレビューを蓄積する設計が要る」と議論されました。両方正しく、時期が違うだけです。**
  - **v1 でやること＝データの置き場所だけ用意する**（レビューを後から入れられる形にしておく。後から足すと全ページの作り直しになる）。**出す条件＝カテゴリあたりのレビューが二桁に乗ったら**
- **IP企業特定の自作**（OKKI 月3万円がある。対象地域が決まるまで着手しない）
- **決済・在庫・税・配送の自動化**（§9-1 が「注文申込で足りる」に倒れた場合）

---

## 11. 未確認事項

0. 🔴 **購買代行モデルの法的評価**（§2-4）。「保存しない＝安全」は成立しないので、**画像を外部リンクで表示する形の是非**を含めて、**顧問弁護士への相談論点にする**。加藤さんは**8月下旬に顧問弁護士と面談予定**（8/9 議事録）。**論点整理は面談の前に渡す必要がある**
1. ~~Vercel の現行プラン~~ → ✅ **決着**。無料プランは商用利用が規約上できないため**不採用**。Cloudflare へ移行（8/9 定例で合意・`26-tech-decision`）
2. ~~既存 Supabase プロジェクトに同居してよいか~~ → ✅ **不要になった**（Supabase を使わない構成に変更）
3. YUGUO ソーシングDB の登録要件、CCEE distribution の掲載枠上限（Wiki でも未確認のまま）
4. h3yun の商品データの**欠損率と更新頻度**（Sheets の閲覧権が必要）
5. OKKI の実際の企業判定精度と、EU 圏での利用可否
6. FINET（酒類・加工食品の業界データ網・会員2,500社）と GS1 Japan 産業横断レジストリー（2026年4月開始・Web API）を、**非会員の商社が使えるか**
7. 送信ドメインを分けてよいか（本業のメール到達率を守るため）
8. 見込商品の掲載について、サプライヤーの同意は取れているか

---

## 付録：判断の根拠

- 8/9 の実測調査 = `[[24-benchmark-research-metoree]]`（Metoree / umamill / ZenMarket の実測、Google スパムポリシー、判例、商品データ経路の調査）
- 濱風 Wiki の既存決定 = `shotakato-Hm/Hamakaze_admin` の `wiki_system/wiki/` 配下を 2026-08-09 に読み取り
- ✅ **8/9 定例の議事録は 2026-08-10 に取り込み済み**（コミット `ad5beae`）。突合の全文 = `planning/reports/inbox/NOTE-20260810-demand-engine-meeting-reconciliation.md`
  - ⚠ 議事録は **Gemini の自動要約**であり逐語ではない（固有名詞の誤変換あり）。**方針レベルの記述だけを根拠にしている**
  - ⚠ 先方 Wiki のモート③ページは `gardener_generated: true` ＝ **AI の自動集約**。そこに書かれた裁定を「人が決めたこと」と同一視していない（§2-5）