![技術語り-Tech Blog[JP]](https://blogger.googleusercontent.com/img/a/AVvXsEiYsL2e14T1O3H3pP9BUj4BxNQQDgWUK-pNhtt6X8syLNp1zvyRWOG_UEv_Gcanv4Nix1_-8MCZL02odSwi69Cbmp6WJeoNDX8f7GQSPH25NUW3dtNTkcGdKhA0sRemc7CD46aj4pMhd8WzzKViOuxBpGmZ5DaFru2sTTv9Jie9aXa98EppzJj1P3lUvyY=s175)
ナレッジ対応
ServiceNowのナレッジポータルにおける多言語（i18n）対応について、実装アプローチごとの特徴、OOTB（Out-of-the-Box）度、工数、運用観点を整理しました。
1. 多言語対応アプローチの比較表
| 案 | 概要 | OOTB度 | 工数 | 運用観点 | おすすめ度 |
|---|---|---|---|---|---|
| 案1 言語別インスタンス管理 |
kb_knowledge の言語フィールドで記事を分離し、標準のLocalization Frameworkでマスタ・翻訳版の親子関係を管理する。 |
高 （標準機能） |
高 ワークフロー設計等 |
ユーザー言語に応じた正確な出し分けが可能。原版改定時の多言語同期や翻訳ステータス管理に継続的な運用負荷がかかる。 | 高 ベストプラクティス |
| 案2 AI自動翻訳の活用 |
単一のマスタ記事に対し、プラグインやGenAI（Now Assist for Knowledge）の自動翻訳を組み合わせ、動的または一括で他言語対応を行う。 | 高 （標準プラグイン/AI） |
中 初期設定・用語集 |
記事の実体が1つであるためメンテナンス負荷が非常に低い。ただし機械翻訳特有の不自然さや専門用語の揺れに対し品質担保が必要。 | 中 効率重視の場合 |
| 案3 インライン併記 |
1つの記事本文内に、原語と英語などの対訳（タブ切り替えや上下配置）を直接HTML等で記述する。 | 最高 （追加構築不要） |
低 設定不要 |
管理・紐付けの仕組みが不要で最もシンプル。しかし検索インデックス（AI Search）の精度低下、記事肥大化、UX悪化を招くため非推奨。 | 低 暫定対応向け |
2. 各案の詳細と選定のポイント
案1：Localization Framework ＋ 言語別インスタンス管理（おすすめ）
- 特徴：ServiceNowが公式に推奨する王道のアプローチ。検索エンジン（AI Search）も言語ごとにインデックスを正しく保持できるため、ユーザーは自身の言語設定に合った最も精度の高い記事にアクセスできます。
- 向いているケース：翻訳ベンダーや社内翻訳者との連携フローが確立しているエンタープライズ企業。
案2：動的翻訳・AI自動翻訳の活用（Now Assist / Dynamic Translation）
- 特徴：昨今のNow AssistやDynamic Translationの進化により現実的になったアプローチ。工数を大幅に削減でき、記事のメンテナンス負荷も最小限に抑えられます。
- 向いているケース：翻訳チームを抱える余裕がない、または急速なグローバル展開で「まずは読める状態にしたい」場合。※社内用語集（Glossary）の登録による誤訳対策が必要です。
案3：単一記事内でのバイリンガル併記（インライン形式）
- 特徴：システム的な改修を一切行わずスモールスタートできる反面、記事のメンテナンスが煩雑になり、検索やレポート集計（どの言語で何回読まれたか等）の正確性が失われます。
- 向いているケース：全社展開前の極小規模なテスト運用や、ごく一部の特例記事の暫定対応。
まとめ：多言語化する対象記事のボリュームと、求める翻訳品質（公式な法務・IT手順書なのか、ラフな社内FAQなのか）のバランスによって、基本的には案1を軸にしつつ、コストパフォーマンスを最優先する場合は案2を検討するのが現実的な選定基準となります。
