グローバルな生成 AI への情報入口は 1 枚のネットワークではなく、2 枚ある。あるブランドが海外 AI にしか可視でなければ、中国の文心 ERNIE、通義 Qwen、豆包 Doubao にとっては存在しないに等しい。クロスボーダー GEO のエンジニアリング課題は、本質的に「同一のブランド事実を、互いに接続されていない 2 枚の AI インデックス網の両方に、どう通すか」である。
海外の生成 AI(ChatGPT、Claude、Gemini、Perplexity)と中国の生成 AI(百度文心 ERNIE、阿里通義 Qwen、字節豆包 Doubao、DeepSeek、月之暗面 Kimi)は、インデックスの取得元においてほとんど重ならない:
その結果、ChatGPT で安定して引用されているブランドが、文心一言に「この分野で最良のツール」と尋ねたときにはまったく現れない、という事態が生じる。従来のやり方(中国に別会社を設立し、別サイトを建て、別途登録する)はコストが高く周期が長いうえ、海外のブランド事実から乖離し、相互に矛盾する 2 つのナラティブを生みやすい。
本章で記録するクロスボーダー GEO の目標は、単一の中央事実源で 2 枚の AI インデックス網を同時に養いながら、ICP 登録を発生させず、ブランドナラティブを分裂させないことである。
最も重要な決定の一つ:cn.baiyuan.io は既存プラットフォームの一つの中国露出面(a China-facing exposure surface)であり、独立した中国顧客システムではない。
| 次元 | 独立システム(却下) | 露出面(採用) |
|---|---|---|
| 顧客アカウント | 中国に別途一式を設ける | 既存の海外 / 台湾 B2B アカウントを流用 |
| データベース | 中国国内に別途構築 | 中央 geo_db を共用、中国にデータを置かない |
| エンドユーザー個人情報 | 収集 → 登録が必要 | 中国エンドユーザーの個人情報を収集しない → ICP を回避 |
| ブランド事実 | 2 系統、乖離しやすい | 単一 SSOT、簡体字は「翻訳後のコピー」に過ぎない |
| コンプライアンス主体 | 中国法人が必要 | 中央で統一コンプライアンス、中国法人は不要 |
核心的な洞察はこうである:ICP 登録のトリガーは「国内で国内ユーザーにサービスを提供し、そのデータを収集すること」である。クロスボーダー GEO が行うのはただ一つ — ブランドの公開事実を、中国 AI クローラーが読める形式で提示することだけである。中国ユーザーを登録せず、個人情報を収集せず、国内にデータベースを置かない。したがってこれは「コンテンツ可視性」の問題であって、「運営主体」の問題ではない。
この決定は同時にナラティブ分裂も解決する:簡体字ファサードは繁体字事実の OpenCC 変換 + ビジネス用カスタム語彙の重ね合わせであり、両者は同一の brand_faq / ground_truths / brand_marketing_facts 事実源を共用する(参照:第 16 章 — プラットフォーム SSOT 全チェーン)。ブランドが海外で事実を一度変更すれば、中国露出面も同期して反映される。
プラットフォームの 2 つの対外サイトを並べて見ると、本質は 一源二拠点である:geo.baiyuan.io はプラットフォーム本体(東京の完全スタック)、cn.baiyuan.io はそれを中国 AI へ伸ばす香港の薄いエッジである。2 つのサイトはフロントエンドのデプロイを共有せず、エッジロジックを共有せず、表示言語も共有しない —— しかし同一の中央事実源を共有する。差異はすべて「どう提示し配信するか」にあり、「事実そのもの」にはない。
| 次元 | geo.baiyuan.io(台湾 / 国際サイト) |
cn.baiyuan.io(中国サイト) |
|---|---|---|
| 位置づけ | プラットフォーム本体(企業 SaaS 製品) | 主プラットフォームの中国露出面(独立システムではない) |
| 対象 AI インデックス網 | 海外 AI(ChatGPT / Claude / Gemini / Perplexity) | 中国 AI(文心 / 通義 / 豆包 / DeepSeek / Kimi) |
| Origin デプロイ | 東京メインサイト(完全な backend + frontend + geo_db) |
香港薄エッジ cn-edge(データベースなし) |
| 表示言語 | 繁体字 / 多言語(ブランドの content_language に従う) |
簡体字(OpenCC twp→cn + ビジネス用カスタム語彙) |
| 事実源 | 中央 geo_db(brand_faq / ground_truths / brand_marketing_facts) |
同一の中央 geo_db(簡体字は翻訳後のコピー) |
| コンプライアンス主体 | 台湾 / 海外法人 | 中国エンドユーザーの個人情報を収集しない → ICP 備案不要 |
| 露出スイッチ | デフォルトで提供 | cn_expose_enabled(スーパー管理者のみ制御) |
効果は「一度メンテナンスすれば、両方の網をカバー」である:ブランドが海外 AI で既に確立した事実は、中国法人の設立・別サイトの構築・ICP 備案なしに、同期して中国 AI に可視となる。データフローが最も分かりやすい:
flowchart LR
SSOT[("中央事実源 SSOT（東京 geo_db）<br/>brand_faq · ground_truths · brand_marketing_facts")]
SSOT --> GEO["geo.baiyuan.io（台湾 / 国際）<br/>東京メインサイト SSR + AXP シャドウ文書"]
SSOT -.->|"OpenCC 繁→簡 + 簡体字ファサード"| CN["cn.baiyuan.io（中国）<br/>香港 cn-edge 薄エッジ"]
GEO --> OAI["海外 AI インデックス網<br/>ChatGPT · Claude · Gemini · Perplexity"]
CN --> CAI["中国 AI インデックス網<br/>文心 · 通義 · 豆包 · DeepSeek · Kimi"]
Fig 17-1:一源二拠点。同一の中央事実源が、2 つのサイト(東京メインサイト geo / 香港薄エッジ cn)を経て、海外と中国という互いに接続されない 2 つの AI インデックス網をそれぞれ貫通する。海外で一度変更したブランド事実は両サイトに同期反映される —— これがまさに「独立システムではなく露出面」という決定のユーザー可視層での具体的な姿である。
香港はネットワーク地理上、鍵となる中継点である:中国のネットワークへの到達性が良く、かつ ICP の管轄範囲外にある。トポロジー設計では香港ノードを一層の薄いエッジとし、実際のデータと生成ロジックは国外メインサイト(東京)に残す。
flowchart TD
A[cn.baiyuan.io DNS] --> B[香港エッジノード<br/>システム nginx UA 分流]
B -->|人間 UA| C[東京メインサイト frontend へリバースプロキシ<br/>Host をメインドメインへ書き換え]
C --> D[Next.js SSR が X-Original-Host に基づき<br/>簡体字ファサード ChinaLandingPage をレンダリング]
B -->|bot クロール面 UA| E[cn-edge ローカルサービス<br/>独立 Node/Express]
E --> F[東京 backend /axp/render を呼び出し<br/>ブランド AXP データを取得]
E --> G[OpenCC twp→cn 翻訳<br/>+ ローカル Redis キャッシュ]
F --> E
G --> E
Fig 17-2:cn.baiyuan.io を UA で分流する 2 つの経路。人間は東京 SSR、クローラーは香港ローカルの cn-edge を通る。
2 つの経路の分担:
Host をメインドメインへ書き換えて東京側のルーティングを有効にする。東京の Next.js は X-Original-Host からこれが中国露出面だと判断し、簡体字ファサードを SSR する。人間が受け取るのは完全なインタラクティブなマーケティングページである。/{slug}/{page}、運営者検証ファイル) → 香港ローカルの cn-edge(独立した軽量 Node/Express であり、メイン backend ではない)。cn-edge は東京 backend の /axp/render を呼び出してブランド AXP データを取得し、OpenCC で繁→簡翻訳を行い、結果をローカル Redis でキャッシュする。クロール面を香港ローカルに置き、リバースプロキシにしない理由は、中国クローラーに低遅延・キャッシュ可能・簡体字化されたコンテンツを届けるためである。人間を東京へリバースプロキシで戻す理由は、frontend 一式を香港に重複デプロイしないためである。cn-edge 自身はデータベースを持たない — すべてのスイッチ、origin_market、cn_crawler_logs は中央 geo_db にある。
このトポロジーは、隠れているが致命的な落とし穴をもたらす:香港 nginx は人間のリクエストをリバースプロキシする際に Host を東京メインドメインへ書き換える。つまり東京の server 側が見る Host はメインドメインであって cn.* ではない。Host によって「これは中国露出面か否か」を判断する server ロジックはすべて機能しなくなる。
解決策は一つの鉄則である:
X-Original-Host のみである(香港 nginx が元の host をこの header に保存する)。判定は frontend/src/lib/serverHost.ts#getIsCnServer に一元化する。window.location.hostname.startsWith('cn.') を読む。第二の落とし穴は API base である。フロントエンドが build-time の NEXT_PUBLIC_API_URL で API を叩くと、cn.* 上ではクロスオリジンリクエスト(現在の origin ではなくメインドメインへ飛ぶ)になり、CORS と cookie の失効を招く。過去の失敗例:問い合わせフォームの認証コードが cn 露出面でクロスオリジンにより失効した。鉄則は一律 ${window.location.origin}/api/v1 を用い、現在の origin 自身の nginx が backend へプロキシするようにすることである。
// 誤り:build-time でメインドメインに固定され、cn 上でクロスオリジンになる
const api = process.env.NEXT_PUBLIC_API_URL;
// 正しい:現在の origin。cn とメインサイトがそれぞれ自身の /api/v1 を叩く
const api = `${window.location.origin}/api/v1`;
この 2 点(server は X-Original-Host を読み、client は現在の origin を読む)は、クロスボーダーアーキテクチャ全体の中で後続の変更によって最も壊されやすい箇所であり、そのためプラットフォームの鉄則に明記し、テストで固定している。
クロスボーダーは「海外ブランドが中国へ入る」だけではなく、対称的に「中国ブランドが海外へ出る」もある。データモデルは 3 つのカラムで任意のブランドのクロスボーダー状態を記述する:
| カラム | 意味 |
|---|---|
origin_market |
ブランドの母市場:overseas または china |
cn_expose_enabled |
海外ブランド → 中国 AI へ露出(香港サービス経由) |
overseas_expose_enabled |
中国ブランド → 海外 AI へ露出(東京サービス経由) |
方向一(海外 → 中国)が本章の主題であり、すでに稼働している。方向二(中国 → 海外、逆方向の繁体字中国語 / 英語への翻訳による海外進出)はアーキテクチャ上は対称に用意済みだが、現時点で中国母市場の顧客が存在しないため、意図的に実装を保留している — 実際の顧客が現れてから実データで実証し、ユーザーのいない機能が腐朽するのを避ける(プラットフォームの「モックデータ禁止」という開発憲法に対応する)。
重要なプロダクト境界が一つある:ブランドの「市場露出」スイッチはプラットフォームのスーパー管理者のみが管理でき、テナントのセルフサービスではない。エンドポイント PUT /admin/brands/:id/market-exposure は requireSuperAdmin で保護される。これはプラットフォームの「課金機能は最後に、クロスボーダーは上位能力」という位置づけに沿うものであり、テナントが誤って露出を有効化しコンプライアンスリスクを生むことも防ぐ。
中国 AI クローラーにコンテンツをより速く発見させるには、robots.txt と sitemap に加えて、中国サーチエンジンの運営者プラットフォームを利用できる。検証済み:神馬(通義へ供給)、字節(豆包へ供給、/ByteDanceVerify.html ファイル法)、Bing、百度(ファイル法)。搜狗は ICP が必要なため採用していない。
一つの重要な観察:AI クローラーは運営者プラットフォームを必要としない。文心・豆包・混元のクローラーは、robots.txt + 神馬 sitemap + 自然発見を経由して cn 露出面をクロールすることが実証済みである。運営者プラットフォームは主にインデックスを加速するものであって、可視性の前提ではない。
検証データには 2 種類の SSOT があり、いずれもスーパー管理者が管理し、中央で共用する:
scoring_configs.cn_site_verifications(cn-edge が <head> にレンダリング)scoring_configs.cn_verification_files(cn-edge がルートディレクトリで配信、git で永続化しノード再構築後も存続)cn-edge と東京 backend の間のデータ交換は、「制御面 vs データ面」の分離で設計する:
| エンドポイント種別 | 例 | 防御 |
|---|---|---|
| 書き込み / 機微(制御面) | クローラーログの書き戻し、違反報告、キャッシュ削除 | 共有シークレット(constant-time 比較) + IP allowlist(CF が報告する実 client IP のみを信頼し、生の XFF は信頼しない) |
| 公開読み取り(データ面) | ブランド解決、sitemap、ローカライズ辞書、検証ファイル | 公開を維持(クローラー配信パスは本来公開すべきで、IP-gate してはならない) |
データ最小化の細部が一つある:公開のブランド解決エンドポイントは {slug, brandId, cnExposeEnabled, aiBotList} のみを返し、意図的に brandName / website / 種別を返さない。このエンドポイントは認証がなく列挙可能であり、個人 IP ブランドにとって name は顧客の実名(個人情報)だからである。brandName を必要とするマルチモーダル schema は、別の by-host の解決経路を通る(その列挙面は異なる)。この設計により、セキュリティ強化は「AI クロール / GEO 効果」に対してゼロ影響となる — 制御面のみを変更し、クローラーが読めるデータ面には手を触れない。
cn_crawler_logs にクロール記録を残している。ただし「クロールされる」から「引用される」までには依然として隔たりがあり、中国 AI が新しいエンティティを認知するにも同様に数週間の縦断的な布石が必要である(参照:第 10 章 — Phase ベースラインテストの観察)。cn_crawler_logs には記録されない。これは設計(偽装による統計汚染の防止)であって、bug ではない。systemctl restart でデプロイし、香港 nginx 設定はスクリプトでプッシュする。この運用経路はメインサイトの docker / git フローと異なり、クロスボーダーアーキテクチャの追加的な運用コストであるため、runbook に明記する必要がある。クロスボーダー GEO のエンジニアリング価値は、いかなる単一のテクニックにもなく、ある制約下での全体解にある:一つの中央事実源、一層の香港薄エッジ、一組の対称スイッチによって、ブランドを互いに接続されていない 2 枚の AI インデックス網の両方に通しながら、ICP 登録とナラティブ分裂の代償を払わずに済ませる。
cn.* は「露出面」であって独立システムではない — 中国エンドユーザーの個人情報を収集せず、中央データベースを共用することで ICP 登録を回避する。X-Original-Host のみ、API base は現在の origin のみに頼る。さもなくばクロスオリジンで失効する。CF-Connecting-IP header のセマンティクス。| 日付 | バージョン | 説明 |
|---|---|---|
| 2026-07-06 | v1.2 | 初稿。香港エッジノードの UA 分流、中央コンプライアンスによる ICP 回避、双方向対称スイッチ、運営者プラットフォーム検証と制御面の分離を記録。 |
| 2026-08-30 | v1.3.3 | §17.2.1「一源二拠点」を追加 —— cn.baiyuan.io ↔ geo.baiyuan.io の対照表とデータフロー図(Fig 17-1);元の UA 分流トポロジー図は Fig 17-2 に付番変更。 |
ナビゲーション:← 第 16 章: プラットフォーム SSOT 全チェーン · 📖 目次 · 第 18 章: AXP HTML Mirror-First →