企業サイトを大量に翻訳していくと、ある事実に行き当たります。どれだけ高性能なAIモデルでも、すべての言語とあらゆる文章タイプで常に最適とは限らないということです。
この記事では、AIシュリーマンが単一のモデルに固定せず、文章ごとにエンジンを選ぶ設計を採っている理由と、その裏側にある企業ごとの専用ナレッジベースについて解説します。
「良い翻訳」の中身は文章によって変わる
IRニュースや契約書では、多少硬くても数値・固有名詞・制度名・条件表現を正確に保持することが重要です。一方、社長メッセージやブランドストーリーでは、正確性に加えて翻訳先言語として自然に読める語り口が求められます。サービス説明文や採用ページでは、重たい日本語をすっきり整理する力が要ります。
つまり「良い翻訳」と一言で言っても、求められるものは文章ごとに違います。
- 正確性が最重要の翻訳
- 自然さが最重要の翻訳
- ブランドトーンが重要な翻訳
- HTML構造を壊さないことが重要な翻訳
- 固有名詞や専門用語を守ることが重要な翻訳
- 短いUI文言として収まりの良さが重要な翻訳
これらを単一のモデルだけで常に最適化するのは簡単ではありません。
3つのフラッグシップを「翻訳チーム」として扱う
そこで採用したのが、文章ごとに最適なエンジンを選ぶというアプローチです。現在は GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro の3つを組み合わせています。
重要なのは「どのモデルが一番優れているか」ではなく、どの文章に対してどのモデルが向いているかです。3つを代替候補ではなく、役割の異なる翻訳チームとして扱っています。
GPT-5.5：正確性と安定性
強みをひとことで言えば「変に盛らないこと」です。
年号、部署名、制度名、技術名、製品名、住所、金額、条件分岐などが含まれる文章では、自然な意訳よりも堅実な情報保持のほうが価値を持ちます。企業沿革のように古い技術名や制度名、地名、組織名が混在する文章では、読みやすく整えすぎるよりも原文の構造を崩さないことが重要です。
一方で、広告コピーやブランドタグライン、文芸的な文章ではやや硬くなることがあります。意味は正しいものの、読後感が少し説明的になる場合があります。
主な用途は、企業公式サイトの文章、IRニュース、決算説明資料、統合報告書の定量・制度説明部分、契約書、技術仕様書、企業沿革、ヘルプページなどです。
Claude Opus 4.7：読ませる文章
4.0以前は翻訳が固く使いづらいモデルでしたが、現在は文章としての読みやすさ、自然さ、余韻の作り方に強いモデルになりました。
日本語の企業文章には「社会的価値を創造する」「未来を切り拓く」「人と社会に寄り添う」といった抽象度の高い表現がよく登場します。直訳すると英語として重くなったり、翻訳文らしい印象が残ったりします。Claudeはこうした表現を、読み手にとって自然な文章に整えるのが得意です。
主な用途は、社長メッセージ、ブランドストーリー、サステナビリティページ、統合報告書のナラティブ部分、観光・文化紹介、顧客事例、広報文などです。
Gemini 3.1 Pro：短〜中尺の文章を整える
日本語の企業サイトには、主語が省略されていたり、長い修飾語が続いたり、抽象的な表現が重なったりする文章がよくあります。Geminiはこうした文章を、翻訳先言語で読みやすい構造に並べ替えるのが得意です。
その一方で、長文で固有名詞や専門用語が多い文章では注意が必要です。短〜中尺の一般的なWebコンテンツには非常に強い反面、長く専門的な文章では検証を挟みたいモデルという位置づけです。
主な用途は、企業サイトの一般的な説明文、商品・サービス紹介、採用ページ、会社紹介、UI文言などです。
エンジン選択はページ単位ではない
ここが設計上もっとも重要な点です。
エンジンの選択をページ単位で固定していません。同じ統合報告書でも、財務数値や注記が多いパートでは正確性重視のモデルを、トップメッセージや価値創造ストーリーではナラティブに強いモデルを使います。同じ採用サイトでも、社員インタビューのような柔らかい文章と、福利厚生や制度説明のように正確性が要る文章では適性が違います。
つまり「このページはこのモデル」ではなく、文章のブロックごとに適性を見るという設計です。
処理の流れは次のようになっています。
- 翻訳対象テキストを解析する
- 文章タイプ・文体・専門性・固有名詞の密度を判定する
- 翻訳先言語との相性を確認する
- 最適なエンジンを選択する
- 翻訳を実行する
- 構造・用語・数値・HTMLタグなどを検証する
従来の翻訳システムでは、あらかじめ決められた1つのエンジンにすべての文章を渡すのが一般的でした。ここでは翻訳の前に文章の性質を見る、いわばエンジンのルーティング処理を挟んでいます。
翻訳先言語によっても最適解は変わる
判断材料は文章タイプだけではありません。同じ日本語の原文でも、英語・中国語・韓国語・欧州言語では、モデルごとの相性が変わります。
日本語から英語では、IR・法務・技術文書・BtoB企業サイトにおいて正確性重視のモデルが安定します。一方、ブランド文や社長メッセージのように英語としての読み味を重視する場合は、表現力に強いモデルが力を発揮します。
タイ語やベトナム語では、敬称、丁寧さ、外来語処理、UI上の文字長といった別の問題が出やすいため、モデル選択だけでなく最終的なレビューと用語管理が重要になります。
企業ごとの専用ナレッジベース
モデルを使い分けるだけでは、まだ足りません。汎用エンジンは「一般的な正しさ」で翻訳するように作られているため、次のような課題が残ります。
- 専門用語や社内用語が正しく翻訳されない
- 製品名やサービス名まで翻訳されてしまう
- ブランドとして定められたトーンが反映されない
- 同じ単語でも文脈によって訳し分けができない
たとえば「Solution」という単語が、あるページでは「ソリューション」、別のページでは「解決策」と訳されてしまう。これではブランドの一貫性が保てません。従来の辞書登録機能は単純な単語置換に留まることが多く、文脈に応じた柔軟な訳し分けは困難でした。
そこで、企業ごとに専用のナレッジベースを構築しています。
何を記憶させるか
サイトの全コンテンツを読み込んで専門用語、製品・サービス名、独自表現を学習し、ブランドガイドラインなどの関連ドキュメントも取り込みます。これらを単なるテキストとして保存するのではなく、意味や関連性を整理した長期記憶として構築します。
記憶される知識は、たとえば次のような形です。
- 「AIシュリーマン」は自社の製品名なので絶対に翻訳しない
- 「AI翻訳エージェント」の公式な英語名は "AI Translation Agent" である
- 技術ブログでは「〜です、ます」調だが、プレスリリースではよりフォーマルな表現を使う
使うたびに更新される
翻訳結果に対して校正が入ると、その内容が新しい経験としてフィードバックされ、ナレッジベースが更新されます。使うほど、そのサイトの文体や暗黙のルールに最適化されていきます。この更新には人の手を介入させることもできます。
翻訳して終わりではない
エンジンを選んで翻訳したあと、結果に対して次の観点でチェックを行います。
- 原文の意味が保持されているか
- 固有名詞が正しく扱われているか
- 数値・日付・住所が変わっていないか
- 用語に揺れがないか
- 翻訳先言語として自然か
- HTML構造が壊れていないか
- UI上の文字数や表示崩れのリスクがないか
- 文章タイプに合ったトーンになっているか
企業サイトでは「1文だけ自然」でも意味がありません。同じ製品名が同じように扱われていること、IRページではIRらしい文体になっていること、翻訳後もWebページとして崩れないこと。これらを満たして初めて、実務で使えるサイト翻訳になります。
データは学習に使われない
複数のAIエンジンを利用するため、「入力したサイトコンテンツがそれぞれのモデルの学習に使われるのではないか」と不安に感じる方もいらっしゃると思います。
AIシュリーマンで処理されるサイトコンテンツや翻訳対象テキストが、各LLMの学習用途に利用されることはありません。企業の公式サイト、IR情報、採用情報、製品情報、技術文書を扱う以上、翻訳品質と同じくらいデータの安全性は重要だと考えています。
まとめ
従来の翻訳エンジンが「1人の翻訳者にすべて任せる」ものだったとすれば、この仕組みは得意分野の異なる翻訳者を、文章に応じてアサインする翻訳コーディネーターにあたります。
正確さが必要な文章には正確性に強いエンジンを、読ませる文章には表現力に強いエンジンを、短いWeb文には自然に整えるのが得意なエンジンを。この判断を自動化し、さらに企業ごとのナレッジベースで文脈とブランドを担保する。これが現時点で私たちが考えたひとつの最適解です。
モデルの勢力図は今後も変わります。特定のモデルに依存しない構造にしておくこと自体が、長期的には効いてくると考えています。
