はじめに

はじめまして! 23卒入社で現在FANTECH本部CL事業部でiOSアプリ開発をしている田野辺開(@iOSRakko)と申します。

「CL」とは、LDHのオリジナル番組やアーティストによるライブ配信などをいつでもどこでも気軽に楽しむことができる、LDHのコンテンツが満載な究極のエンターテインメントサービスです。
現在の主要戦略の1つとして、CLはグローバル展開を掲げており、「LDH動画配信サービス「CL」、生成AIを使用した字幕・翻訳機能を提供開始 」 など多言語対応にも力を入れています。
今回は、CLのコミュニティ機能において、iOS 18から利用可能となったApple Translation APIを採用し、オンデバイスで翻訳機能を搭載した事例について、技術選択と工夫の観点からお話しします。

コミュニティ機能におけるオンデバイス翻訳のイメージ

実例を見ていただいた方が、イメージが付きやすいと思いますので、以下に動画を掲載しています。動画では、日本語から英語へのオンデバイス翻訳を行っています。ただし、日本語から英語の翻訳以外にも、テキストの主要言語を識別(後述)し、ユーザーの端末設定言語で翻訳する機能を展開しており、多数の言語ペアをサポートしています。

オンデバイス翻訳の大まかな流れ

CLのオンデバイス翻訳機能は、以下のような流れで実装しています。
オンデバイス翻訳の全体フロー図

  1. 言語推定: APIで投稿情報を取得する際に、Natural Language Frameworkを使用して投稿本文の主言語を推定し、翻訳可能な言語かどうかを判定。
  2. 翻訳ボタン表示: 推定された言語が翻訳可能な場合、翻訳ボタンを表示。
  3. モデル確認とダウンロード: 翻訳ボタンが押されると、必要な翻訳モデルがダウンロードされているか確認し、未ダウンロードの場合はシステムにモデルをダウンロード。(以下添付画像は実際の確認画面)
  4. 翻訳実行: モデルの準備が整ったら、推定された言語から端末の設定言語へ翻訳を実行。
翻訳モデル確認画面のスクリーンショット

言語識別のNatural Language Frameworkの利用法

テキストの言語識別には、Natural Language FrameworkのNLLanguageRecognizer を使用しています。このフレームワークは、テキストの言語を自動的に検出し、後述のTranslation API利用時に翻訳可能な言語かどうかを判定することができます。
NLLanguageRecognizer は、テキストの言語を自動的に検出するための強力なツールです。processString メソッドでテキストを処理し、dominantLanguage プロパティを通じてテキスト内で複数の言語が発見された際、最も使用頻度が高い言語を識別し取得できます。
CLでは、この機能を活用して以下のような実装を行っています。

  1. 投稿本文の言語自動検出: ユーザーが投稿したテキストの言語を自動的に検出。
  2. 翻訳可能な言語の判定: 検出された言語が翻訳可能かどうかを判定し、翻訳機能の提供可否を決定。
  3. 翻訳ボタンの表示制御: 翻訳可能な言語の場合のみ翻訳ボタンを表示し、ユーザー体験を担保。

この機構により、ユーザーは翻訳可能な言語でのみ、翻訳ボタンの押下を通じて、オンデバイス翻訳の体験を得ることができます。

// 簡単なコードサンプル
let recognizer = NLLanguageRecognizer()
recognizer.processString(text)
if let dominantLanguage = recognizer.dominantLanguage {
    // 言語が識別された場合の処理
}

Apple Translation APIの選択

iOS 18では、翻訳機能を実装するための2つの主要なAPIが提供されています。それぞれの特徴と、CLでの採用理由について説明します。

  • translationPresentation
    translationPresentation は、システムが提供する翻訳ポップオーバーを使用したシンプルな実装方法です。最小限のコードで実装でき、システム標準のUIによる一貫したユーザー体験を提供できます。また、replacementAction を設定することで、「翻訳で置き換え」ボタンがポップオーバー内に自動的に表示され、翻訳後のテキストを任意のビューに表示することが可能です。当初、CLでもこの方法の採用を検討し、PoCを作成していましたが、以下の理由から使用を断念しました。
    まず、UIのカスタマイズに制限があり、CLのデザインシステムに適合しないという課題がありました。また、長文の翻訳には不向きであり、CLでは最大500文字の翻訳が必要なため、ポップオーバーではUXを損なう点から適切に対応できません。さらに、インターネット接続に依存する場合があり、オフライン環境での利用を一部想定するCLの要件と一致しませんでした。
  • translationTask
    一方、translationTask は、より柔軟な翻訳機能の実装を可能にするAPIです。プログラム的な制御が可能で、カスタムUIの実装が自由な点が特徴です。また、オフライン動作が可能で、高度なエラーハンドリングも実装できます。
    この機構により、ユーザーは翻訳可能な言語でのみ、翻訳ボタンの押下を通じて、オンデバイス翻訳の体験を得ることができます。以下の点がtranslationTask が優れていると判断し、採用に至った理由です。

    1. CLのデザインシステムに合わせたUIの実装が必要だった
    2. 最大500文字の翻訳が必要なため、ポップオーバーUIは不適切
    3. インターネット接続に依存しない翻訳機能の実現
    4. ユーザーへの適切なフィードバックの提供

翻訳時におけるURL処理

言語識別や翻訳処理において、テキスト内のURLが対象となってしまう問題がありました。テキスト内のURLが対象となってしまうことで、2025年1月時点では翻訳の精度を著しく低下させてしまう問題がありました。
この問題を解決するため、Swiftの正規表現で、翻訳処理前にテキスト本文に含まれるURLのみを一時的に除外し、処理後に元の位置に戻す処理を実装しました。特にクエリパラメータの処理(?の後のスペース問題など)に対応することで、URLの機能を維持しながら、より精度の高い翻訳機能を実現しています。

SwiftUIとUIKitの連携

Apple Translation APIはSwiftUIでのみ提供されていますが、CLのコミュニティ機能はUIKitベースで作成されています。この課題を解決するため、翻訳ボタン部分のみをUIHostingController を使用し、SwiftUIで切り出してて実装しつつ、UIKitのビュー階層に統合しました。この対応により、SwiftUIのみで提供されている、Apple Translation APIを利用することが出来るようになりました。

まとめ

iOS 18のApple Translation APIを採用することで、システムレベルの翻訳機能を活用しつつ、CLの要件に合わせたカスタマイズを実現しました。この実装により、以下のような利点を得ることができました。

  • 追加コストを抑えながら、ユーザーに対して多言語対応を提供
  • 高精度な翻訳機能の実現
  • Apple純正APIによる安定した動作と低いメンテナンスコスト
  • オフライン環境での翻訳機能の提供
  • 効率的な言語識別によるユーザー体験の向上

生成AIの進化が著しい中、私たちのチームでは、エンジニアリング主導でサービスや開発体験に生成AIを積極的に取り入れ、常に最新技術をキャッチアップしていくことを意識しています。

最後までお読みいただき、ありがとうございました。