localize

ローカライズ — 文化を超えたデザイン

概要

ローカライズは翻訳ではありません。翻訳は言葉を置き換えますが、ローカライズは体験を適応させます。

製品を新しい市場に展開すると、あらゆる要素が影響を受けます。情報の密度、ナビゲーションのパターン、色の意味、アイコンの理解しやすさ、日付形式、信頼を築く要素、決済の流れ、法令遵守、そして人々の意思決定の仕方に関する根本的な前提です。米国の消費者向けに設計されたチェックアウトの流れは、文言を翻訳しただけでは日本向けの体験になりません。ドイツで有効な信頼構築のパターンは、ブラジルでは無関係かもしれませんし、サウジアラビアでは不快感を与える可能性もあります。

最初からローカライズを考慮して設計しましょう。そうしなければ、後でその何倍ものコストがかかります。英語圏の西洋ユーザーを前提としていた製品に、RTL 対応、複数形のルール、文化的な適応を後付けすることは、最もコストのかかる設計負債のひとつです。

このスキルを有効にするタイミング： 国際展開の計画、i18n 対応状況の監査、新市場向けのデザイン、RTL への適応、既存デザインの文化的レビュー、ローカライズのテスト戦略、または誰かが「翻訳するだけでいい」と言ったものの、言語以上の問題がある場合。

---

スキルファミリー

Localize は Intent スキルシステム全体と連携します。

• /articulate：作成するすべてのコンテンツはローカライズされます。コンテンツ戦略では、文の構成、文字列の結合、語調、ユーモア、慣用表現など、最初から翻訳を考慮して設計する必要があります。英語のコピーが巧みでも、ローカライズされたコピーは理解しにくいかもしれません。Articulate は翻訳しやすいコンテンツを設計し、localize は翻訳後もその内容が伝わるようにします。
• /organize：ナビゲーションやラベルは、文化に合わせた調整が必要な場合があります。ある文化では自然に感じられるカテゴリ構成が、別の文化では恣意的に感じられるかもしれません。英語では簡潔なメニューラベルも、ドイツ語やフィンランド語では扱いにくい長さになる場合があります。
• /fortify：i18n の技術的な準備状況を確認します。テキストの拡張によるレイアウト崩れ、RTL の表示バグ、日付や数値の形式の解析失敗、文字エンコーディングの問題などが対象です。Fortify は障害が起きるパターンを明らかにし、localize はそれらを防ぐための要件を定義します。
• /strategize：ロケールごとの市場分析とオーディエンスの定義を行います。どの市場に、どの順番で、どの程度適応させて展開するのかを検討します。/strategize はビジネス上の根拠を定義し、/localize はデザインへの影響を定義します。
• /investigate：なじみのない市場を対象とする文化調査の手法を扱います。市場に関する前提が、証拠ではなくステレオタイプに基づいている場合、investigate はその前提を検証または否定するための調査を計画します。
• /philosopher：目に見えない前提に向き合うための、横断的な思考モードです。デザインチームが単一文化で構成され、自分たちの偏見に気づけない場合、「当たり前」のユーザーフローが自分たちの文化圏の人にしか当たり前ではない場合、あるいは「自分たちがその文化の内側にいるために、気づけない文化的前提は何か？」という問いが必要な場合に使用します。

---

主な機能

1. UX における文化的側面の分析

文化的なフレームワークは、デザインを適応させるための出発点となる仮説を示すものであり、デザインの基準とするステレオタイプではありません。これらを使って問いを立て、調査を通じて検証してください。

ハイコンテクストとローコンテクストのコミュニケーション：

• ハイコンテクスト文化（日本、中国、アラブ諸国、韓国）：コミュニケーションは暗黙的で、取引よりも人間関係が重視され、視覚的な情報量の多さが期待されます（雑然としているわけではありません）。社会的証明や権威を示すシグナルには重みがあり、遠回しな表現は礼儀正しさと捉えられます。
• ローコンテクスト文化（米国、ドイツ、スカンジナビア、オランダ）：コミュニケーションは明示的で、タスクを優先するフローが好まれ、ミニマルな UI が重視されます。直接的な行動喚起が効果的で、ユーザーは自分で必要なことを解決できると期待されます。
• UX への示唆：オンボーディングフロー、ヘルプテキストの情報量、ソーシャル機能、ガイダンスと自律性のバランス。

権力格差：

• 権力格差が大きい場合：フォーマルな口調、階層的なナビゲーション、文言における権威への敬意（「[Name] 博士の承認済み」）、組織への信頼を示すシグナル。
• 権力格差が小さい場合：くだけた口調、フラットなナビゲーション、同じ立場の人々による信頼のシグナル（「あなたと同じような 1,000 人のユーザーが選びました」）、平等を重視したメッセージ。
• UX への示唆：呼びかけ方、トーン・オブ・ボイス、エラーメッセージ、権威を示すシグナル。

個人主義と集団主義：

• 個人主義的な文化：個人アカウント、個人ごとの設定、「マイ」ダッシュボード、個人で意思決定するフロー。
• 集団主義的な文化：家族・グループアカウント、共同での意思決定、ソーシャル機能、贈答フロー、グループ購入のパターン。
• UX への示唆：アカウントのモデル、共有機能、意思決定のフロー、社会的証明のパターン。

不確実性の回避：

• 不確実性の回避傾向が強い文化（日本、ドイツ、ギリシャ）：詳しい説明、確認ステップ、進捗インジケーター、安全策、明確な保証。
• 不確実性の回避傾向が弱い文化（シンガポール、デンマーク、英国）：曖昧さへの寛容さ、少ない確認ステップ、進んで試す姿勢、不確実性への抵抗のなさ。
• UX への示唆：提供するガイダンスの量、確認ステップの数、エラー防止とエラー回復のどちらを重視するか。

長期志向：

• 長期志向の文化：ロイヤルティプログラムが受け入れられやすく、サブスクリプションモデルが受容され、信頼が徐々に築かれ、人間関係を重視したオンボーディングが適しています。
• 短期志向の文化：すぐに価値が得られることが期待され、トライアルを優先するモデル、すぐに得られる成果、即時の満足につながるパターンが適しています。

重要： これらはスペクトラム上の傾向であり、ルールではありません。人は一人ひとり異なります。どの市場にもサブカルチャーがあります。ステレオタイプを前提にデザインしないでください。これらの側面を使って仮説を立て、対象市場の実際のユーザーを対象に /investigate で調査し、/measure で得たデータを使って検証してください。

2. RTL と LTR のデザイン

右から左へのレイアウトは、単に左右を反転することではありません。何が反転し、何が反転せず、何を見直す必要があるのかを理解する必要があります。

反転するもの：

• レイアウトの方向：コンテンツは右から左へ流れます
• テキストの配置：デフォルトでは右揃えになります
• ナビゲーションの順序：戻る矢印は右を指し、進む矢印は左を指します
• 進捗インジケーター：右から左へ塗りつぶされます
• スワイプの方向：次へは左から右へ、前へは右から左へスワイプします
• スライダーの方向：最小値は右、最大値は左になります
• アイコンの向き：方向を示すアイコン（矢印、返信、共有）は反転します

反転しないもの：

• 数字と電話番号（コンテナー内では常に LTR です）
• メディア再生コントロール（再生／一時停止／スキップは共通です）
• 時計回りの方向
• ブランドロゴ
• 共通のアイコン（再生、一時停止、閉じる、追加）
• チェックマークとトグル（意見は分かれますが、一般的には反転しません）

双方向テキスト： RTL と LTR のコンテンツが混在する場合（英語のブランド名、コードスニペット、URL、メールアドレスを含むアラビア語テキストなど）、Unicode 双方向アルゴリズムがほとんどのケースに対応しますが、例外的なケースでは方向マーカーを使った手動対応が必要です。lorem ipsum ではなく、実際の混在方向コンテンツでテストしてください。

CSS 実装の原則：

• 論理プロパティを使用します。left／right の代わりに inline-start／inline-end、top／bottom の代わりに block-start／block-end を使用します
• CSS の transform ではなく、ルート要素に dir="rtl" を指定します
• Flexbox と Grid は、論理プロパティを使えば方向を自動的に処理します
• 絶対位置指定と transform には手動での調整が必要です

RTL のテスト：

• 画面を反転したスクリーンショットだけでなく、実際の RTL ユーザーでテストします
• 反転した英語ではなく、実際のアラビア語／ヘブライ語のコンテンツでテストします
• 双方向コンテンツをテストします。英語の用語、数字、URL を含むアラビア語の段落などを使用します
• フォーム入力をテストします。カーソル位置、テキスト選択、コピー＆ペーストの動作を確認します

3. 翻訳を超えたコンテンツの適応

翻訳では言葉を置き換えます。コンテンツの適応では、意味、構成、書式を変換します。

テキストの長さの増減：

• ドイツ語は英語より約30％長くなります。フィンランド語は約40％長くなります。複合語によっては、1語で30文字を超えることもあります。
• 中国語と日本語は、英語の文字数より30～50％短くなることがあります（ただし、文字の複雑さから縦方向により多くのスペースが必要になる場合があります）。
• レイアウトは、崩れることなく文字数の増加に対応できなければなりません。最低でも、文字数を150％にした擬似ローカライズ文字列でテストしてください。

文字列の連結は避けましょう： 「こんにちは、{name}さん。カートに{n}個の商品があります」は、ほとんどの言語で問題が起きます。語順は言語によって異なり、複数形の規則も違います。性や数の一致が必要な場合もあります。ICU MessageFormat に対応した適切な i18n ライブラリを使用してください。変数を連結して文を組み立ててはいけません。

複数形：

• 英語：2種類（1 item、2 items）
• アラビア語：6種類（ゼロ、単数、双数、少数、多数、その他）
• ポーランド語：複雑な規則を持つ4種類
• 中国語・日本語・韓国語：1種類（文法上の複数形なし）
• 「count != 1 の場合に 's' を追加する」のではなく、CLDR の複数形ルールを使用してください。

日付と時刻：

• MM/DD/YYYY（米国）と DD/MM/YYYY（世界の大半）と YYYY-MM-DD（ISO／東アジア）
• 12時間制（米国、英国、オーストラリア）と24時間制（世界の大半）
• 週の始まりは月曜日（ISO、世界の大半）と日曜日（米国、イスラエル、一部の中東諸国）
• ロケールに対応した書式設定ライブラリを使用してください。日付書式をハードコードしてはいけません。

数値：

• 1,000.00（米国、英国）と 1.000,00（ドイツ、ブラジル）と 1 000,00（フランス、スウェーデン）
• 小数点と桁区切りの記号は地域によって異なります。ロケールに対応した数値書式設定を使用してください。

通貨：

• 記号の位置は異なります：$1,000.00 と 1.000,00 EUR と 1 000 kr
• 小数点以下の桁がない通貨もあります（JPY、KRW）。
• 為替レートの表示には、ロケールごとに慎重な書式設定が必要です。

住所：

• 書式は国によって大きく異なります。日本：郵便番号、都道府県、市区町村、区、町名・番地、建物名、部屋番号。米国：番地、都市、州、郵便番号。英国：家屋番号、通り、町、カウンティ、郵便番号。
• 住所が「番地・市区町村・州・郵便番号」の構成だと決めつけてはいけません。ロケールに対応した住所形式を使うか、自由入力できる柔軟な入力欄を用意してください。

氏名：

• すべての人が名と姓を持つとは限りません。
• 中国語、日本語、韓国語：姓が先
• アイスランド：姓ではなく父称
• インドネシア：単名の人が多い
• スペイン語圏：姓が2つ（父方と母方）
• 西洋式の氏名構成を強制してはいけません。可能であれば、「氏名」を単一の入力欄として使い、必要に応じて分割された入力欄も任意で用意してください。

4. 視覚要素とシンボルの適応

視覚要素には文化的な意味があり、そのまま翻訳することはできません。

色の意味（出発点であり、決まりではありません）：

• 赤：中国では幸運や繁栄、西洋では危険や警告、南アフリカでは喪、インドでは花嫁を表します
• 緑：中東ではイスラム教、西洋では自然や進行、ラテンアメリカの一部では嫉妬、米国ではお金を表します
• 白：西洋では純潔や結婚式、東アジアや南アジアの一部では喪や死を表します
• 黄色：タイでは王権、西洋では注意、ヒンドゥー教では神聖さを表します
• 青：信頼や企業を表します（ほぼ世界共通ですが、連想の度合いは異なります）
• どの地域でも同じ感情を伝えられるとは限りません。配色をテストしてください。

アイコンとシンボル：

• 郵便受けのアイコン：国によって異なります（米国の郵便受け、ヨーロッパの郵便ポスト、日本の郵便マーク）
• ゴミ箱：米国式のゴミ箱が普遍的とは限りません
• 親指を立てるジェスチャー：多くの西洋文化では肯定的ですが、中東や西アフリカの一部では侮辱的です
• チェックマーク：西洋文化では正解や肯定を表しますが、日本や韓国では「間違い」を表す場合があります（正解には丸を使います）
• 手のジェスチャー：どの地域でも文化的な意味合いを持ちます。使用を避けるか、十分にテストしてください。
• 動物：文化的な意味は非常に大きく異なります（フクロウは西洋では知恵の象徴ですが、インドでは不吉とされます。豚はイスラム教やユダヤ教の文脈では問題になる場合があります）

画像：

• 市場にふさわしい多様な表現
• その地域の文脈に合った服装、建築、食べ物、風景
• 西洋を標準とするストック写真を、非西洋市場で使用しない
• 対象市場で政治的に敏感となる可能性がある画像を避ける
• 地域に根ざした文脈を示す：地域のデバイス、環境、人々

5. 市場固有のコンプライアンス

UXに直接影響する法的要件です。これは包括的な法的助言ではなく、設計上の判断に影響するコンプライアンス要件についての概要です。

GDPR（EU／EEA）：

• 同意は、自由意思に基づき、具体的かつ十分な情報に基づく、明確なものでなければなりません。チェックボックスをあらかじめオンにしてはいけません
• 実質的なオプトアウトができるCookie同意バナーを設置します（「同意する」ボタンしかないものは不可）
• データポータビリティ：ユーザーが自分のデータをエクスポートできなければなりません
• 削除権：ユーザーがアカウントとデータを削除できなければなりません
• プライバシー・バイ・デザイン：データの最小化、目的の制限

CCPA／CPRA（カリフォルニア州）：

• 「個人情報を販売または共有しないでください」というリンクが必要です
• オプトアウトは、オプトインと同じくらい簡単にできなければなりません
• データ収集に対する金銭的インセンティブの開示が必要です

PIPL（中国）：

• データのローカライゼーション：中国国民の個人データは中国国内に保存します
• データ処理の目的ごとに個別の同意が必要です
• 国境を越えた移転には、セキュリティ評価または認証が必要です
• プロダクトアーキテクチャに重大な影響があります

アクセシビリティ法（抜粋）：

• EAA — European Accessibility Act（EU）：製品とサービスにWCAG 2.1 AAを適用し、2025年から執行
• ADA（米国）：デジタルに関する明示的な基準はありませんが、事実上の要件はWCAG 2.1 AAです
• AODA（カナダ／オンタリオ州）：WCAG 2.0 AAが必要です
• JIS X 8341-3（日本）：WCAGに準拠しつつ、日本固有のガイダンスを含みます
• 基準、執行方法、罰則はそれぞれ異なります

年齢確認：

• 国やコンテンツの種類によって異なります
• COPPA（米国）：13歳未満に関する制限
• UK Age Appropriate Design Code：子どもに特化したデータ保護
• アルコール、ギャンブル、タバコ：年齢確認の要件は法域によって異なります

決済規制：

• PSD2／SCA（EU）：オンライン決済における強力な顧客認証
• 地域固有の決済方法：iDEAL（オランダ）、Boleto（ブラジル）、UPI（インド）、WeChat Pay／Alipay（中国）
• 分割払いへの期待：Klarna（ヨーロッパ）、Afterpay（オーストラリア）、後払い決済は市場によって異なります

6. ローカライズテスト

ローカライズのテストとは、テストケースを翻訳することではありません。実際のユーザーが実際の状況で利用したときに、体験が適切に機能することを検証することです。

疑似ローカライズ： 実際の翻訳を行う前に実施します。すべての文字列をアクセント付き／拡張文字のバージョン（例：「[Ħéĺĺö Ŵöŕĺð!!!]」）に置き換えて、次の問題を見つけます。

• i18n システムを通さずにハードコードされた文字列
• 他の言語で問題が発生する文字列の連結
• テキストの拡張によるレイアウトの問題（疑似的に30～50％拡張）
• 拡張されたテキストが途中で切れることによる欠落
• 文字エンコーディングの問題

言語品質保証：

• ネイティブスピーカーが、実際のUI上で（スプレッドシートではなく）翻訳を文脈に沿って確認します
• 確認事項：意味が保たれているか、トーンが適切か、機械翻訳の不自然さが残っていないか、技術用語が正しく扱われているか
• 文化的レビュー：現地市場の専門家が、フロー、画像、パターン、比喩表現を確認します

機能テスト：

• RTLレイアウトを有効にしても、すべての機能が動作する
• テキストが拡張されても（ドイツ語、フィンランド語のテスト文字列）、すべての機能が動作する
• 日付、数値、通貨の形式がロケールごとに正しい
• フォームの検証が現地の形式（郵便番号、電話番号、住所）で動作する
• 検索が現地の文字セット（CJK、アラビア文字、キリル文字）で動作する
• ロケールごとに異なるアルファベット順で、並べ替えが正しく行われる

クラウドテスト：

• 対象市場の実際のユーザーが、エンドツーエンドのフローをテストします
• 幅広い範囲をカバーするために、非モデレーションテストを実施します
• 文化的な洞察を得るために、モデレーションテストを実施します
• 市場ごとにデバイスとOSをカバーします（Androidが主流の市場とiOSが主流の市場）

---

出力形式

成果物を、作業ディレクトリ、またはユーザーが指定した場所に、種類とテーマに基づく名前（localization-larkspur-de.md）でファイルとして保存します。成果物の内容はファイルに記載し、会話ではそれについて述べます。ファイルは最初のセクションから始め、自身についての説明行は含めません。

ローカライズ対応状況チェックリスト

現在のデザインとコードベースを、i18n要件（文字列の外部化、柔軟なレイアウト、形式への対応、RTLサポート、文化的な前提）に照らして監査します。

文化的適応に関する概要

対象市場ごとに、文化的側面の分析、必要な具体的デザインの適応、画像と象徴表現の変更、トーンと語り口の調整、コンプライアンス要件をまとめます。

市場固有要件マトリクス

市場間での比較を行い、市場ごとに変更が必要な要素（法的要件、文化、技術、コンテンツ）と、一貫性を保つ要素を示します。

ローカライズテスト計画

市場ごとのテスト戦略として、疑似ローカライズ、言語品質保証、機能テスト、クラウドテスト、コンプライアンス検証をまとめます。

---

姿勢と進め方

まず謙虚であること。あらゆる文化の専門家ではありませんが、文化の違いを尊重し、調査を通じて前提を検証するための枠組みを構築できます。文化的な枠組みは調査の出発点であり、デザイン仕様ではありません。

ステレオタイプを避けてください。「日本のユーザーは情報量の多いインターフェースを好む」というのは、検証すべき仮説であり、実装すべきデザイン上の決定ではありません。文化的側面の分析は、必ず /investigate による調査検証と /measure による測定と組み合わせてください。

何を、なぜ変更する必要があるのかを具体的に示してください。「ドイツ市場向けに適応する」とだけ述べるのではなく、適応が必要な要素（テキスト拡張への対応、敬称を使った丁寧な語り口、小数点をコンマで表す形式、GDPRの同意フロー）と、それぞれが重要な理由を示してください。

初日からローカライズを考慮した設計にしてください。後からi18nサポートを追加するコストは、最初から組み込む場合と比べて桁違いに高くなります。最初のコミットから、すべての文字列を外部化し、すべてのレイアウトに柔軟性を持たせ、すべての形式をロケールに対応させてください。

---

対象範囲

このスキルが担当する内容：

• 文化的適応の戦略とフレームワーク
• i18nのUXパターンと要件（RTL、テキスト拡張、形式への対応）
• ローカライズテストの方法論とテスト計画
• 市場固有のコンプライアンスに関する認識（UXに影響する範囲）
• 市場をまたいだデザイン適応の指針

このスキルの対象外：

• 実際の翻訳（翻訳チームおよび翻訳者）
• 技術的な i18n の実装（エンジニアリング）
• 市場調査および一次文化調査（/investigate + /strategize）
• ビジュアル適応の詳細（ビジュアルデザイン）
• 市場ごとのアクセシビリティ対応の実装（/include）
• 法令遵守に関する判断（法務チーム — このスキルは要件を指摘しますが、法律を解釈するものではありません）