AI 時代の多言語化は、翻訳することではない

自社サイトを英語にしたい。海外の顧客や取引先に、自社のことを正しく伝えたい。そう考えて日本語ページを機械翻訳にかけると、たしかに意味は通る英文が出てきます。ところが、それを英語ネイティブが読むと、どこか不自然に感じる。文法は正しいのに、外国人が書いた英語だと一目で分かってしまう。B2B では、この違和感が静かに信頼を削ります。

なぜ精度の高い翻訳でも不自然なのか

日本語と英語は、語順も、修辞も、文章の前提も違います。日本語は主語を省き、結論を後ろに置き、行間に文脈を託します。英語は主語を立て、結論を先に出し、言葉で説明しきります。この差を無視して一文ずつ置き換えると、文法的には正しくても、英語として読むと座りの悪い文章になります。

たとえば主語のない受動態をそのまま訳すと、誰が何をするのか曖昧な英文になる。抽象名詞をつないだ日本語をそのまま移すと、動詞のない硬い表現になる。日本語では自然な比喩が、英語では意味不明の直訳になる。いわゆる Japanglish は、翻訳精度の問題ではなく、発想の問題です。

翻訳ではなく、書き下ろす

この問題への業界の答えが transcreation（トランスクリエーション）です。原文を訳すのではなく、伝えたい意図・読者・トーンを記した指示書をもとに、目標言語で文章を新しく書き起こす。担い手は翻訳者ではなくコピーライターだ、というのが標準的な考え方です。日本語ページは翻訳の原文ではなく、英語を書くための参照資料として扱う、と言い換えてもいいでしょう。

検索エンジンの観点でも、この方が有利です。Google は、機械的に未翻訳のまま複製したページだけを重複コンテンツとして扱う、としています。意図から書き下ろした英語ページは重複とはみなされず、独立したページとして評価されます。

AI だからこそ、現実的になった

書き下ろしは、従来は高コストでした。バイリンガルのコピーライターを起用する必要があり、少人数の会社には手が届きにくい方法だったからです。

AI 駆動なら、この工程を人手のコピペ往復なしで回せます。日本語から意図を抽出して指示書にする。その指示書から英語で書き下ろす。複数の異なるネイティブ視点の AI に並列でレビューさせ、直訳臭やコロケーションの違和感を洗い出す。さらに別系統の AI で事実整合を検証する。品質のゲートを AI 同士で回し切れるようになったことが、書き下ろしを中小企業の現実的な選択肢に変えました。

自社サイトで実践して分かったこと

Nihonbashi AI Lab は、自社サイトを英語化する際にこの方法を採りました。米国の経営者、英文の編集者、日英のローカライゼーション専門家という三つのネイティブ視点で英文を並列レビューし、複数の視点が独立に同じ箇所を指摘した部分を、本当に直すべき所として確定しました。一人のレビューでは見落とす違和感が、複数の合議で浮かび上がります。

そして実際に難しいのは、初回の英語化よりも運用でした。一度英語にしても、日本語を更新して英語版が古いまま取り残されると、言語間の対応付け（hreflang）が壊れ、検索評価も崩れます。だから私たちは、日本語のコアページを直したら英語版も同じ流れで直す、という規律を仕組みにしました。英語版が欠けているとビルド自体が止まるようにして、直し忘れを構造的に防いでいます。

多言語化は、ツールで英訳して終わる話ではありません。何を伝えるかを設計し（業務設計）、日本語と英語をどう対応させるかを決め（データ構造）、書き下ろしと品質検証を AI で回し（AI 活用）、更新時に英語を追従させる仕組みを持つ（運用導線）。この四つが揃って初めて、ネイティブに違和感のない多言語サイトが、片手間ではなく資産として回り始めます。

自分で回すなら（手順の骨子）

この方法は特別なツールを必要としません。次の型でAIエージェントに回させます。

• 意図を指示書にする — 目的・読者・残す主張・トーンを書き出す（原文を訳すのではなく、これをもとに書き下ろす）
• 目標言語で書き下ろす — 指示書からネイティブ品質で新規に執筆する
• 複数の視点で審査する — 立場の違う複数のネイティブ視点で並列レビューし、複数が同じ箇所を指摘した所を直す
• 別系統で整合を見る — 文章の質とは別に、リンクや表示の実装が壊れていないかを別の目で確認する
• 更新の追従を仕組みにする — 原文を直したら訳も直す、を人の意志でなくビルドで強制する

これをコピーしてそのまま使えるスキル（Claude Code 用）として、実装手順・擬似コードとあわせて Zenn の記事 にまとめました。