5秒で結論
12言語サイトで一番やってはいけないのは、言語ごと・国ごとにアフィリエイト口座を増やし、その管理まで人間が抱えることだ。
最初は「日本はAmazon.co.jp、米国はAmazon.com、ドイツはAmazon.de……」で始まる。気づけば税務情報、支払設定、Tracking ID、審査、APIキー、規約更新、最低支払額が国別に増殖する。
記事を作る工場を作っていたはずなのに、隣にアフィリエイト・サグラダ・ファミリア2号館が建つ。これは避けたい。
現実的な設計は、次の3層に分けることだ。
- 記事工場が「この記事に商品導線を出すべきか」を判断する。
- 収益化の制御盤が、読者の国・言語・記事テーマに応じて販売先を選ぶ。
- Sovrn Commerceなどの集約層に、商品候補・収益化可能性・価格比較・実績集計をできるだけ任せる。
ポイントは、12言語を12個のアフィリエイト運営にしないこと。
「制御盤は1個、販売先だけ市場ごとに差し替える」が正解に近い。
1. なぜAmazonを国ごとに直結すると管理地獄になるのか
AmazonのCreators API自体は複数の国・地域に対応している。米国、日本、英国、ドイツ、フランス、スペイン、ブラジル、メキシコ、豪州など、多くのマーケットプレイスを扱える。[6]
ただし、APIで別のAmazon市場を呼ぶときは、その市場で有効なPartner Tagが必要になる。Amazon公式も、米国用のタグと英国用のタグを別に渡す例を示している。[6]
OneLinkで国際トラフィックをまとめやすくはなるが、対象国によっては各国のAssociatesアカウントや支払設定が必要だ。[7]
つまり技術的には「世界のAmazonを叩ける」。しかし運用側では、
- 国別のアカウント
- 国別のTracking ID / Partner Tag
- 支払設定
- 税務情報
- 最低支払額
- 審査・規約
が残る場合がある。
12言語サイトでこれを正面から全部やると、商品を紹介する前にアカウント管理者へ転職することになる。
Amazon直結は強い。ただし「Amazonを使える国は全部Amazon直結」にすると、集中管理という目的とは逆方向へ進みやすい。
2. Sovrn Commerceは何を集約してくれるのか
Sovrn Commerceは、出版社・ブログ・アプリなどが大量の加盟店をまとめて扱うための中間層だ。
公式オンボーディングでは、審査に通れば数万規模の加盟店に個別申請せずにアフィリエイトできると説明されている。[1]
ここが普通のASPを一つずつ契約する方式と違う。
基本形はこうだ。
記事
↓
Sovrn Commerce
↓
加盟店A / 加盟店B / 加盟店C / …
↓
クリック・購入
↓
Sovrn側で集計
登録は無料アカウントから始められる。サイトへリンクを実装し、数回クリックを発生させると審査キューへ入り、公式案内では審査に最大5営業日ほどかかることがある。[1]
そして重要なのは、「Sovrn経由で使える加盟店」と「自分が別ASPで直接契約したアカウントをSovrnへ接続する」のは別物という点だ。
前者なら、加盟店ごとの個別申請を大幅に減らせる。
後者は、Awin、CJ、Impact、Rakutenなどの自分の既存ネットワークをSovrnへ接続して管理を集約する機能で、その場合は当然それぞれの認証情報が必要になる。[11]
つまり、裏のアカウントを全部作らなければSovrnが使えないわけではない。
最初はSovrn側の提携網だけで始め、収益価値が明確な市場だけ後から直契約を追加する方が、管理コストを抑えやすい。
3. 「言語」と「販売地域」を同じものにしてはいけない
12言語運営では、ここが設計上かなり重要になる。
英語の記事を読む人が米国在住とは限らない。スペイン語ならスペイン、メキシコ、中南米に広がる。中国語繁体字でも台湾、香港、海外在住者など複数の地域がある。
だから、
記事のlocale = 何語で説明するか
market = どの販売地域へ送るか
を分離する。
悪い設計は、en → Amazon.com のように言語だけで販売先を固定すること。
良い設計は、英語記事でも読者地域・通貨・加盟店在庫などを見て市場を選ぶことだ。
SovrnのProduct Recommendation APIとPrice Comparison APIは、現時点で usd_en / gbp_en / aud_en / cad_en / eur_de / eur_it / eur_fr / eur_es / eur_nl / chf_de の10市場を明示対応している。[2][3]
ここは重要な制約だ。
12言語全部が、そのままSovrnの商品推薦APIの12市場になるわけではない。
したがって、12言語サイトでは「Sovrn一本で全部」ではなく、
- Sovrnの商品APIが強い市場 → Sovrnを第一候補
- それ以外 → Link Check、対応加盟店、地域別フォールバックを使う
- 日本で楽天が自然な記事 → 楽天Web Serviceを候補にする
- Amazon直契約に十分な利益が出る市場だけ → 後からAmazon Associatesを足す
というルーティング層が必要になる。
4. 記事工場に必要なのは「広告生成」より先に収益化ゲート
全部の記事に商品を貼ればいいわけではない。
むしろ、多言語メディアで最も重要なのは、広告を出さない判断を自動化することだ。
たとえば、
- 「USB-C充電器の選び方」→ 商品導線が自然
- 「旅行の持ち物」→ 旅行用品や予約導線が自然
- 「引越しで段ボールは何箱必要？」→ 梱包用品が自然
- 「自然の進化はなぜこんなに複雑なのか」→ 無理に商品を出さない
という違いがある。
記事工場には、公開前に次の判定を一度だけ挟む。
記事完成
↓
本文QC
↓
12言語QC
↓
【収益化ゲート】
├─ 商品導線が不自然 → 広告なし
└─ 商品導線が自然
↓
商品カテゴリ / 意図 / 最大表示数を記録
↓
市場ルーター
↓
Sovrn / 楽天 / その他
判定項目は複雑にしすぎなくてよい。
最低限、
- 読者が次に買う・予約する行動が自然か
- 商品が本文の問題解決に役立つか
- 商品を出すことで記事の信頼性が落ちないか
- 比較・価格・在庫を古い固定情報で見せていないか
- 広告であることを適切に開示できるか
を見る。
売るものがない記事に、売るものを無理やり発明しない。
これだけで「1,500記事あるから1,500記事全部広告板にしよう」という事故をかなり防げる。
5. 商品そのものをMDへ焼き込まない
運用を楽にするなら、本文へAmazon URLや商品カードを直接埋め込まない方がいい。
商品は廃番になる。価格は変わる。在庫も変わる。最適な販売店も変わる。
本文へ固定すると、後から全記事を書き換える仕事が生える。
代わりに、記事側には「収益化してよい」という意味だけを持たせる。
monetization:
affiliate: true
intent: high
topic: "usb-c-charger"
placement: "after-buying-guide"
max_products: 3
market_mode: auto
広告なしなら、
monetization:
affiliate: false
reason: "no-natural-commerce-intent"
で終わる。
テンプレート側がこのmanifestを読んで、表示時またはビルド時に商品を取得する。
これなら、記事本文は長寿命、商品データは可変、という役割分担になる。
記事を商品カタログにしない。商品カタログを記事へ一時的に差し込む。
この向きが重要だ。
6. 「売れているもの」は報酬率ではなく実績で選ぶ
高い報酬率だけ見て商品を選ぶと、売れなければゼロである。
SovrnのApproved Merchantsでは、平均EPC、推定報酬、平均コンバージョン率、平均注文額などを確認できる。[4]
Price Comparison APIではEPC順で結果を並べることもできる。[3]
さらに運用後は、Merchant reportingからRevenue、Clicks、Sales、Actions、Conversion Rate、EPCといった自サイトの実績を取得できる。[12]
だから最初はネットワーク平均を使い、データが貯まったら自サイト実績へ重みを移す。
たとえば内部スコアは、
商品スコア
= 記事との関連性
× 実EPC
× 実CVR
× 在庫安定性
× 市場適合度
くらいでよい。
最初から完璧な機械学習モデルを建てる必要はない。
売れ始めてから賢くすればいい。売れる前にNASAを建てない。
7. SovrnのMCPとAPIはどう使い分ける？
SovrnはCommerce MCPをベータ提供しており、AIクライアントから商品検索、価格比較、リンク変換、取引・加盟店レポートなどを呼び出せる。[5]
これは人間が会話しながら、
- 「この記事に合う商品を探して」
- 「先月一番稼いだ加盟店は？」
- 「このリンクは収益化できる？」
- 「同じ商品でもっとEPCが高い店は？」
と調べる用途に向いている。
一方で、記事工場を無人で回すなら、MCPよりAPI直結の方が自然だ。
違いは簡単だ。
MCP = 制御盤
API = 配管
日常運転はAPIで自動処理する。
MCPは調査、監査、例外処理、改善に使う。
ChatGPTもMCP対応アプリを接続できるが、フルの書き込みMCPはプランや利用環境に制約があり、OpenAI公式では現時点でBusiness / Enterprise / Edu向けが中心、Proは読み取り・取得中心、モバイルではMCPアプリを利用できないと案内されている。[10]
だから、記事工場の自動運転をChatGPTの画面操作へ依存させない方がよい。
最初の実装や大型修理にCodex等を使うのは便利だが、設置後はバックエンドが勝手に回る形が完成形になる。
8. 日本語市場は楽天をフォールバックにしやすい
楽天Web Serviceの楽天市場商品検索APIは、affiliateId を渡すと affiliateUrl をレスポンスに含められる。[8]
そのため、日本語記事では、
- Sovrnで自然な加盟店がある → Sovrn
- 楽天市場の商品が自然 → 楽天
- Amazon直結の利益が十分に大きい → Amazonを追加検討
という順番にできる。
重要なのは、最初から全部契約しないことだ。
「この市場だけ直契約すると年間で管理コスト以上の増益が見込める」と分かってから足せばよい。
管理コストも立派なコストである。
報酬率が1%高くても、毎月ログインして税務画面と格闘するなら、その1%はだいたい人間の魂で支払っている。
9. 12言語での現実的なルーティング
現時点の設計なら、次のように考えると分かりやすい。
| locale | 基本方針 |
|---|---|
| ja | Sovrn加盟店を確認しつつ、楽天を有力な日本向けフォールバックにする |
| en | 読者地域に応じてUSD/GBP/AUD/CAD市場へ振り分けやすい |
| de | EUR/CHFのドイツ語市場をSovrn商品APIで扱いやすい |
| fr | EURフランス語市場を扱いやすい |
| es | EURスペイン語市場を扱いやすい。中南米は別market判定が必要 |
| pt-BR | Sovrn商品推薦APIの明示市場外なので、加盟店GEO/別経路を判定 |
| ko | 同上。韓国向け販売先を別ルートで選ぶ |
| zh-Hans | 同上。言語だけで中国市場と決めつけない |
| zh-Hant | 台湾・香港等を地域判定して別ルートへ |
| id | インドネシア向け加盟店・別経路を判定 |
| th | タイ向け加盟店・別経路を判定 |
| vi | ベトナム向け加盟店・別経路を判定 |
これは「対応外言語は稼げない」という意味ではない。
商品推薦APIの市場コードと、アフィリエイト可能な加盟店GEOは別レイヤーだからだ。[4]
まず一つの制御盤で地域と加盟店を判定し、必要な市場だけ後から専用ルートを足せばよい。
10. 開示表示は12言語でローカライズする
アフィリエイトは、リンクが動けば終わりではない。
Sovrn自身も、アフィリエイトリンクを含むページには、読者に分かりやすい開示表示を置くよう案内している。[9]
日本では、2023年10月1日から、広告であることを一般消費者が判別しにくい表示が景品表示法上の規制対象になっている。消費者庁は、アフィリエイトサイトでも表示全体から広告であることが明瞭かを見るとしている。[13]
したがって12言語では、
- 日本語記事には日本語の開示
- 英語記事には英語の開示
- ドイツ語記事にはドイツ語の開示
というように、本文だけでなく広告開示もlocale化する。
さらに、法令・広告ルールは国ごとに違うため、一つの日本語文を翻訳すれば世界中で法的に十分だとは考えない。
「広告を自動挿入する」なら、開示も同じ処理で自動挿入する。
広告だけ自動、法律だけ人間の記憶頼み、という設計は最後に刺さる。
11. 最初からフル実装しない。審査を先に通す
この仕組みは大きく作ろうと思えばいくらでも大きくできる。
しかし最初にやることは単純だ。
- Sovrn Commerceへ無料登録する。
- サイトを登録する。
- 1〜数記事だけ収益化対象にする。
- Sovrnリンクを設置する。
- 数回テストクリックを発生させる。
- 審査結果を待つ。
- 通ったら記事工場へ収益化ゲートを実装する。
- 実績が出てから市場別ルートを増やす。
Sovrn公式も、リンク実装→数回クリック→審査という流れを案内している。[1]
だから、審査前に12言語×全市場×全APIを完成させる必要はない。
空港を建てる前に航空会社が来るか確認する。
これだけで無駄工事をかなり減らせる。
12. 最終形は「記事を書く人」ではなく「収益化ルーターを持つメディア」
最終形では、人間が毎回商品を探す必要はない。
体験・疑問・調査
↓
記事工場
↓
本文QC
↓
12言語化
↓
収益化ゲート
↓
locale + reader market
↓
商品・加盟店ルーター
↓
Sovrn / 楽天 / 必要な市場だけ直契約
↓
表示
↓
クリック・売上・EPC・CVR
↓
次回ランキングへ反映
これなら、記事を増やすほど「広告管理の手間」まで比例して増える構造を避けられる。
目標は、アフィリエイトリンクを大量に貼ることではない。
読者に商品が必要な記事だけ、適切な市場の、実績の良い販売先へ自動でつなぐことだ。
12言語サイトで本当に欲しいのは12個の管理画面ではない。
One control plane. 制御盤は一個でいい。
