AI機能は、今やほとんどのプロダクトに組み込まれています。ヘルプページのチャットアシスタント、ストア内のAI検索、自動生成される商品説明、レコメンドパネルなどです。どれもユーザーの居場所によって回答が変わる可能性があり、チームがオフィスからテストしても、その違いはほとんど表面化しません。複数の市場向けにプロダクトを提供しているなら、国別のAI出力の確認は、ある市場から苦情が来てから行うものではなく、AI・機械学習の取り組みやリリーステストと並んで行うべきものです。
このガイドでは、AIの出力が国によって変わる理由、確認すべき項目、テストリクエストを現地ユーザーのように見せる方法、そして一字一句同じになることのない回答を比較する方法を解説します。
AIの出力が国によって変わる理由
違いの多くは、モデルそのものではなく、モデルを取り巻くプロダクト側から生じます。
- コンテキストとしての位置情報。 多くのアシスタントは、IPから読み取ったユーザーの国や都市をプロンプトに追加します。判定を誤ると、別の市場向けの回答が自信たっぷりに返されます。
- 地域別のルーティング。 データレジデンシーなどの理由で、リクエストが地域ごとに別のモデル、バージョン、エンドポイントに送られることがあります。同じ日に2つの市場で異なるモデルバージョンが動いていることもあります。
- 機能フラグ。 AI機能は国ごとに順次リリースされることが多く、ある市場で動くボタンが別の市場では表示されなかったり、壊れていたりします。
- ポリシーとコンプライアンスのルール。 健康、金融、選挙、年齢に関する現地のルールにより、一部の国だけで回答拒否や免責表示が出ることがあります。
- リトリーバル。 アシスタントがWeb、ヘルプセンター、商品カタログを検索するときは、通常ユーザーの地域で検索するため、引用される事実や商品が変わります。
このうち最初と最後の項目は、リクエストの送信元IPに左右されます。1か所からのテストでは見落とすのはそのためです。
市場ごとに確認すべき項目
提供しているすべての市場で、同じ属性のセットを確認しましょう。
| 確認項目 | 起こりうる問題 |
|---|---|
| 言語 | 日本のユーザーに英語で回答する、1つの回答に複数の言語が混ざる |
| 通貨と単位 | ドイツのユーザーにドル建ての価格を表示する、キロメートルではなくマイルを使う |
| 現地の事実 | その国の配送日数、祝日、税制、店舗所在地が間違っている |
| 機能の提供状況 | AI機能が表示されない、エラーになる、「お住まいの地域ではご利用いただけません」と表示される |
| ポリシー上の挙動 | 1つの国だけに適用すべき回答拒否や免責表示がすべての国で出る、またはその逆 |
| 商品と情報源 | その市場で販売されていない、または関係のない商品のレコメンドや引用 |
| 書式 | 日付、数値、住所が現地の形式になっていない |
これらのいくつかは、従来のページチェックと重なります。文言、hreflang、レイアウトについては大規模なローカライズQAのガイドで解説しています。このチェックリストは、AIレイヤーが追加で持ち込む項目を対象としています。
現地ユーザーとしてテストする
位置情報は通常IPから判定されるため、テストリクエストはその市場から送る必要があります。対象国を指定したレジデンシャルプロキシを経由して送れば、プロダクトは現地の実際のユーザーと同じ地域判定、フラグ、ポリシーを適用します。データセンターのIPレンジは、IPデータベースで誤った国に判定されたり、ボットチェックの対象になったりすることが多く、その市場の誰も目にしないテスト結果になってしまいます。
リクエストのそれ以外の要素も市場に合わせましょう。Accept-Language ヘッダー、タイムゾーン、ブラウザのロケール設定です。日本のIPで英語のブラウザを使うユーザーと、日本のIPで日本語のブラウザを使うユーザーは別のユーザーであり、どちらもテストする価値があります。これらのシグナルを一貫させる方法は、プロキシの地域、タイムゾーン、ロケールを一致させる方法の記事で解説しています。
複数ターンのチャットでは、スティッキーセッションで会話全体を通じて同じIPを維持し、ターンの途中でユーザーが移動したようにプロダクトから見えないようにします。
customer-USERNAME-country-jp-sid-chat-ja-01-ttl-600:PASSWORD小さなテストハーネス
以下のハーネスは、同じプロンプトを複数の市場からAIエンドポイントに送り、正確なテキストではなく属性を確認します。エンドポイントとチェック内容はご自身のものに置き換えてください。
import requests
GATEWAY = "p.shifter.io:443"
USER, PASS = "USERNAME", "PASSWORD"
ENDPOINT = "https://app.example.com/api/assistant"
MARKETS = {
"de": {"lang": "de-DE", "currency": "€"},
"jp": {"lang": "ja-JP", "currency": "¥"},
"br": {"lang": "pt-BR", "currency": "R$"},
"us": {"lang": "en-US", "currency": "$"},
}
PROMPTS = ["How much is shipping for a 2 kg parcel?", "Recommend a laptop under my budget."]
RUNS = 3
def ask(country, lang, prompt, run):
proxy = f"http://customer-{USER}-country-{country}-sid-ai-{country}-{run}-ttl-600:{PASS}@{GATEWAY}"
r = requests.post(ENDPOINT, json={"message": prompt},
headers={"Accept-Language": lang},
proxies={"http": proxy, "https": proxy}, timeout=60)
return r.status_code, r.json().get("answer", "") if r.ok else ""
for country, m in MARKETS.items():
for prompt in PROMPTS:
hits = 0
for run in range(RUNS):
status, answer = ask(country, m["lang"], prompt, run)
if status == 200 and m["currency"] in answer:
hits += 1
print(country, prompt[:30], f"currency ok in {hits}/{RUNS} runs")上の表の各行に対応するチェックを追加しましょう。回答の言語判定、各市場で販売している商品のリスト、地域限定の「ご利用いただけません」メッセージを検出するパターンなどです。モデルの出力は実行ごとに変わるため、各プロンプトは複数回実行します。3回中2回だけ合格するチェックはノイズではなく、検出すべき問題です。
リリーステストに組み込む
- モデル、プロンプト、フラグを変更するたびにハーネスを実行する。 デフォルトの地域だけでなく、すべての市場から実行します。
- 市場ごとに固定のプロンプトセットを用意する。 ネイティブスピーカーが作成し、その市場の顧客が実際にする質問を含めます。
- 回答を国、モデルバージョン、時刻とともに保存する。 モデルの変更とルーティングの変更を区別できるようにするためです。
- 回答拒否を国別に毎週見直す。 ある市場だけ拒否率が急上昇した場合、たいていはポリシールールか地域別のエンドポイントが原因です。
自社のAI機能が検索にも表示されるなら、同じ市場別の手法をAI検索での表示状況のモニタリングにも応用できます。そこでの問いは、各国でほかのアシスタントが自社について何と言っているかです。
まとめ
AIの出力はローカルです。モデルを取り巻くプロダクトがユーザーの位置を読み取り、それに応じて動作するからです。各市場をその市場のレジデンシャルIPからテストし、言語とロケールを合わせ、複数ターンのチャットは1つのスティッキーIPで維持し、言語、通貨、現地の事実、提供状況、回答拒否といった属性を複数回の実行で確認しましょう。これをリリースのたびに行えば、地域特有のAIのバグを顧客より先に見つけられるようになります。