WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Xcodeのエージェントでアプリを翻訳する

Xcodeのエージェントでアプリを翻訳する

ローカライズString CatalogsXcodeエージェントSwiftUIAI
元の動画を見る

ハイライト

Xcode 27はコーディングエージェントを導入し、String Catalogsが蓄積してきたコード上の位置、用途の説明、他言語の参考翻訳といった文脈を使って、IDE内でアプリの多言語ローカライズを自動実行します。翻訳レビュー、UIの切り詰め検出、反復的な改善にも対応します。

主要内容

機械翻訳によるローカライズに足りなかったのは、モデルではなく文脈

ソフトウェアのローカライズは、ずっと面倒な作業でした。従来の機械学習モデルは、ソフトウェア文字列に含まれる曖昧さをうまく扱えません。現代の大規模言語モデルは汎用的な翻訳能力が大きく向上しましたが、文脈がなければやはり失敗します。

英語の “book” は、名詞の「本」なのか、それとも動詞の「予約する」なのか。同じ単語でも、言語によってまったく違う訳語になります。文脈がなければモデルは推測するしかなく、推測を外すとユーザーが見る画面は不自然になります。

Appleは3年前からString Catalogsでこの問題に取り組み始めました。2年前には、String Catalogsが文字列のコード上の位置を記録するようになりました。昨年は、文字列の用途を記録し、説明的なコメントを自動生成するようになりました。そして今年、Xcode 27はこれらすべての文脈をコーディングエージェントに渡し、IDE内で直接翻訳を完了できるようにしました。

ワンクリック翻訳: 依頼から完了までの流れ

(02:19) 開発者はXcodeのツールバーでNew Conversationをクリックし、エージェントに「アプリをカナダフランス語に翻訳して」と伝えるだけです。その後の手順はすべて自動で実行されます。

エージェントはまずXcodeにプロジェクトの準備を依頼します。対象言語をプロジェクト設定に追加し、すべてのターゲットをビルドしてローカライズ可能な文字列を発見し、新しく見つかった文字列をString Catalogに自動で書き込みます。プロジェクトにまだString Catalogがなければ、Xcodeが自動で作成し、既定のファイル名はLocalizableになります。

(03:11) 開発者はカスタムのtable nameで文字列を整理することもできます。たとえばTextにtableName: "Greetings"を追加すると、その文字列はGreetingsという名前のString Catalogに書き込まれます。

次に、エージェントは文字列をバッチに分け、複数のサブエージェントへ並行して翻訳を割り当てます。Xcodeは各サブエージェントに豊富な文脈を提供します。文字列がコード内のどこにあるか、似た用語を使っている他の文字列の一覧、さらにはその文字列の他言語での既存翻訳まで含まれます。

(04:14) たとえば%lld itemsという文字列について、Xcodeはサブエージェントに「これは複数形変化を持つ文字列で、英語では”one item”と”two items”に分かれる」と伝えます。サブエージェントはそれに基づいて、カナダフランス語でも対応する複数形バリエーションを生成します。複数形の規則は言語ごとに大きく異なるため、Xcodeは対象言語に必要なバリエーションをサブエージェントが常に把握できるようにします。

新機能開発でも翻訳の一貫性を自動で保てる

(07:17) 翻訳は一度きりの作業ではありません。既存のローカライズを持つアプリに新機能を追加する場合も、エージェントは自動で対応できます。

デモでは、開発者がカナダフランス語ローカライズ済みのアプリに新機能を追加し、エージェントに実装とローカライズを依頼しました。エージェントは新しい文字列を翻訳するとき、“landmarks”の訳として既定の訳語ではなく、以前に開発者が手動で指定した”attraits”を自動的に使いました。つまり、エージェントは過去の会話を読むことなく、Xcodeが提供するプロジェクト文脈によって用語の一貫性を維持できます。

翻訳レビュー: リリース前に問題を見つける

(08:46) 翻訳が完了したら、開発者はエージェントにUIプレビューを描画させ、言語ごとの表示問題を確認できます。

カナダフランス語の文は平均して英語より長いため、テキストの切り詰めが起きやすくなります。エージェントは問題箇所をプレビュー上で直接示し、開発者はレイアウトを調整するのか、翻訳を短くするのか、実装のバグを修正するのかを判断できます。

このレビュー方法は他の言語特性にも使えます。タイ語は文字の高さが大きく、縦方向に切り詰められやすい言語です。アラビア語は右から左に書かれるため、ビューの配置を確認する必要があります。開発段階で問題を見つけて修正すれば、ユーザーが壊れた画面を見ることを避けられます。

(10:20) エージェントによるレビューに加えて、AppleはTestFlightを通じてネイティブ話者からフィードバックを集めることも推奨しています。翻訳品質はコードのように一目で判断しにくいため、ネイティブテスターからのスクリーンショットや提案が最後の防衛線になります。

詳細

SwiftUI文字列のローカライズ

SwiftUIのTextやButtonなどのAPIは既定でローカライズ可能で、文字列は自動的にローカライズシステムへ公開されます。

Text("Hello, world!", comment: "A standard greeting")

ポイント:

  • commentパラメータは翻訳に文脈を与え、曖昧さを避けます
  • SwiftUIコンポーネントは文字列をString Catalogへ自動登録します

String Catalogのファイル名をカスタマイズしたい場合は、tableNameを使います。

Text("Hello, world!", tableName: "Greetings", comment: "A standard greeting")

ポイント:

  • tableName: "Greetings"は、既定のLocalizable.xcstringsではなくGreetings.xcstringsへ文字列を書き込みます
  • 大規模プロジェクトで文字列をモジュールや機能ごとに分割管理するのに向いています

SwiftUI以外のコードでのローカライズ

ViewModel、データ層、その他の非UIコードでは、ローカライズAPIを明示的に使う必要があります。

String(localized: "Hello, world!", comment: "A standard greeting")

LocalizedStringResource("Hello World!", bundle: #bundle, comment: "A standard greeting")

ポイント:

  • String(localized:)はローカライズ済み文字列を取得する最も一般的な方法です
  • LocalizedStringResourceは、ローカライズリソースを他のモジュールへ渡す必要がある場面に適しています
  • ハードコードされた文字列はXcodeのビルドシステムに発見されないため、これらのAPIでラップする必要があります

XLIFF内の機械翻訳マーカー

プロの翻訳者に確認してもらうためにXLIFFファイルを書き出すと、機械翻訳された内容には特定のマーカーが付きます。

<trans-unit id="Grand Canyon" xml:space="preserve">
  <source>Grand Canyon</source>
  <target state="translated" state-qualifier="leveraged-mt">Grand Canyon</target>
  <note>Name of the 'Grand Canyon' landmark.</note>
</trans-unit>

ポイント:

  • state-qualifier="leveraged-mt"は、この翻訳がエージェント由来であることを明示します
  • プロの翻訳者はこのマーカーを使い、人手で確認が必要な内容をすばやく絞り込めます
  • <note>内の注釈はString Catalogsが自動収集した文脈に由来します

エージェント向け翻訳ガイドを書く

(12:06) 開発者はプロジェクト内にTRANSLATION.mdファイルを作成し、エージェントに翻訳方針を与えられます。内容には次のようなものを含められます。

  • 特定語彙の必須訳語、たとえば用語集
  • 翻訳すべきではない語彙のリスト、たとえば製品名や商標
  • 期待する口調やスタイルの説明

エージェントは既定でXcode内蔵の言語別スタイルガイドを使い、開発者が提供した追加の指示も読み込みます。翻訳ガイドをTRANSLATION.mdに分けて置けば、翻訳以外のタスクで無関係な文脈を読み込まずに済みます。

モデル選択の考え方

(13:02) 翻訳は複雑で長時間にわたるタスクであり、プロジェクト全体で用語を一貫させる必要があります。大きなコンテキストウィンドウを持ち、長時間のリクエスト処理が得意な大規模モデルを選ぶことが推奨されます。言語によって翻訳品質には差があり、学習データに少ない言語では品質が下がる場合があります。モデル提供元のドキュメントで学習データの言語分布を確認するとよいでしょう。

重要ポイント

多言語対応の旅行ガイドアプリを作る

  • 作るもの: 世界各地の観光地を紹介し、10以上の言語に対応するアプリ
  • 作る価値: Xcodeエージェント翻訳を使えば、これまで外部チームに依頼していた多言語ローカライズを一人でも進められます。String Catalogsが観光地名や説明文などの文字列の文脈を自動収集するため、一般的な機械翻訳よりもはるかに正確になります
  • 始め方: SwiftUIで画面を作り、すべての文字列をTextまたはString(localized:)で宣言します。Xcodeでエージェントを呼び出して対象言語を選び、翻訳が終わったら各言語でUIの切り詰めがないかエージェントに確認させます

用語一貫性チェックツールを作る

  • 作るもの: 大規模プロジェクトでは、同じ英単語を開発者ごとに違う中国語へ訳してしまうことがあります。XLIFFファイルをスキャンし、同じsourceに複数の異なるtargetが対応している箇所を見つけるスクリプトを作ります
  • 作る価値: エージェントは文脈を使って一貫性を保てますが、モジュールをまたいだり時間をまたいだりして開発された文字列では不一致が残ることがあります。このツールをCIに組み込み、マージ前に自動チェックできます
  • 始め方: 書き出したXLIFFを解析し、sourceでグループ化し、各sourceに対応するtargetの数を数えます。1を超えたら警告します

翻訳品質スコアリング用ショートカットを作る

  • 作るもの: TestFlightでネイティブユーザーからスクリーンショット付きフィードバックを集めたあと、エージェントにスクリーンショット上の実際の表示とString Catalog内の翻訳を比較させ、切り詰め、はみ出し、配置ミスなどの可能性を自動でマークさせます
  • 作る価値: 翻訳レビューの手作業を自動化できます。内容を頻繁に更新するプロダクトに特に向いています
  • 始め方: Xcodeのエージェントによる各言語UIプレビュー描画機能を出発点にし、プレビュー画像と翻訳テキストを一緒に視覚モデルへ渡して比較分析します

子ども向けローカライズ語彙学習アプリを作る

  • 作るもの: 子ども向けアプリの口調や語彙は大人向けアプリとまったく異なります。大量のローカライズが必要で、口調に敏感な教育アプリを作ります
  • 作る価値: TRANSLATION.mdに「簡単な語彙を使う」「親しみやすい口調にする」「抽象概念を避ける」と詳しく書けば、エージェントはそれに合わせて翻訳スタイルを調整します。これは従来の機械翻訳では難しいことです
  • 始め方: まず詳細な翻訳スタイルガイドを書き、Xcodeで各言語の出力を確認しながらガイドを反復改善します

関連セッション

  • 101 Keynote — WWDC26のオープニング基調講演。AIとエージェントに関する全体戦略に触れる可能性があります
  • 259 Xcode agents — Xcodeエージェントの汎用機能を紹介するセッションで、この翻訳ワークフローの基盤になります
  • 262 Swift — Swift言語の新機能。ローカライズ関連APIの更新が含まれる可能性があります
  • 344 Code-along: Explore localization with Xcode — Xcodeでローカライズを実践するCode-along。このセッションの理論を補完します
  • 227 UI Prototypes with agents — エージェントでUIプロトタイプを作る内容で、このセッションのUIプレビューを描画して翻訳を確認する考え方とつながります

コメント

GitHub Issues · utterances