String Catalog多言語テスト：2026年リモートMacをどう自動化する？

String Catalogは、言語、翻訳、複数形、デバイス変体を管理できます。ただし、エディタ上で未翻訳項目がないことは、実行時の表示やArchiveへの収録を保証しません。AppleのString Catalog公式ドキュメントでも、文字列の管理と表示確認は別の作業として扱われています。

自動化では、次の四つを別々の証拠として保存します。

• 抽出の証拠：ソースコードやInterface Builderから必要な文字列がCatalogへ入っているか。
• 翻訳状態の証拠：対象言語の翻訳、複数形、変体が未完了になっていないか。
• 実行画面の証拠：実際の言語設定で、切り詰め、重なり、フォールバックが発生していないか。
• 配布物の証拠：Archive後のBundleに、想定した言語リソースが含まれているか。

SwiftUIのTextや文字列補間は、書き方によって抽出結果が変わります。Appleのローカライズ用文字列抽出の説明を基準に、通常文、数値を含む文、複数形、画面幅の狭い文を小さな検証セットとして用意します。翻訳率だけで合格にせず、各セットが画面に正しく現れることまで確認してください。

SwiftUIの独立開発者

最初に、画面の主要導線から文字列を抽出します。ログイン、購入、主要機能の作成画面など、ユーザーが離脱すると影響の大きい経路を優先し、アプリ全体を一度に対象にしない方が保守しやすくなります。

最低限、次の組み合わせを含めます。

• 通常の短いラベルと長い説明文
• 数値やユーザー名を含む補間文字列
• 単数・複数で表現が変わるメッセージ
• iPhoneの狭い画面とmacOSの広い画面で配置が変わる項目
• 翻訳が存在しない場合のフォールバック表示

String Catalogで取りこぼしを確認するには、何を見ればよいのでしょうか。
Catalogの状態だけでなく、抽出元のコードと実行画面を突き合わせます。新しい文字列を追加した変更でCatalogの差分が発生し、指定言語のUIテストがその文字列を表示し、ビルド後のBundleにも対応リソースが存在する、という三段階を合格条件にします。

UIKit・混在プロジェクトの保守担当者

既存アプリでは、.xcstringsだけを調べると漏れが生じます。Localizable.strings、stringsdict、Storyboard、XIB、Info.plist、アプリ拡張、フレームワークのリソースを分けて確認してください。

移行時は、モジュール単位で旧リソースを残しながら検証する方法が安全です。すべてを一度に置き換えると、重複キー、異なるBundleへの収録、Storyboardだけに残った文字列を切り分けにくくなります。テスト対象のSchemeとTargetを固定し、生成されたBundleの中身と実際の画面を両方確認します。

注意：Catalogの緑色の状態は、画面幅、文字方向、日付形式、通貨形式まで正しいという意味ではありません。編集画面の状態、実行結果、配布物の状態を同じ判定にまとめないでください。

全言語と全シミュレーターを機械的に掛け合わせると、失敗の原因が増え、独立開発者では結果を確認しきれなくなります。実際に提供する言語、販売地域、書字方向、主要デバイスを基準に代表ケースを選びます。

Test Planでは、Application LanguageとApplication Regionを分けて設定します。言語は翻訳文やフォールバックを確認する軸、地域は日付、通貨、数値、カレンダーなどの表示を確認する軸です。Appleのローカライズ実行テストの公式説明に沿って、両方を混同しない構成にします。

iOSアプリの言語と地域をまとめて検証するには、どう設計すればよいでしょうか。
まず主要市場ごとに代表ケースを選び、次に右から左へ読む言語、長い翻訳、複数形、通貨表示が変わる地域を追加します。各ケースには、アプリ言語、地域、端末サイズ、テストアカウントの条件を記録し、どの条件で失敗したかを結果ファイルから追えるようにします。

AppleのTest Planの整理方法を使い、通常の機能テストとローカライズUIテストを分離します。コミットごとは代表ケース、発行前は対象市場を広げたケース、というように実行範囲を変えると、速度と網羅性を両立しやすくなります。

判断用チェックリスト：実行範囲を条件で決める

次のチェックを上から確認し、該当する分岐に従ってください。これは、毎回のCIで動かす検査と、発行前だけ動かす検査を分けるための判断工具です。

• [ ] 新しい文字列の取りこぼしが最優先ですか。 はいの場合は、Catalogの差分確認と文字列抽出検査をコミット時に実行します。画面を開くUIテストは主要導線に限定します。
• [ ] 購入、ログイン、作成などで文字切れが起きると公開を止めますか。 はいの場合は、対象言語・地域をTest Planに登録し、UIテストとローカライズ用スクリーンショットを発行前の必須条件にします。
• [ ] UIKitや旧形式のリソースが残っていますか。 はいの場合は、String Catalogだけで合格にせず、Storyboard、XIB、stringsdict、拡張TargetのBundleを個別に確認します。
• [ ] 右から左への表示、複数形、通貨、長い商品名が重要ですか。 はいの場合は、該当する言語・地域を発行前の必須ケースにします。
• [ ] ローカルMacを常時起動できませんか。 はいの場合は、リモートMacでシミュレーターを起動し、SSH切断後もxcresultとスクリーンショットを保存できることを確認してからCIへ組み込みます。
• [ ] 物理iPhoneや専用周辺機器が必須ですか。 はいの場合は、リモートMacだけを前提にせず、必要な機器へ接続できる常設環境を選びます。
• [ ] 単一言語で画面変更が少ないですか。 はいの場合は、毎回の全言語UIテストを避け、Catalog差分と発行前の代表画面確認に縮小します。

「はい」の項目が複数ある場合は、もっとも公開リスクの高い項目を発行ゲートにし、それ以外を定期回帰へ分けます。UIテストを安定して起動できない場合は、翻訳の不備とテスト基盤の不備を同じ失敗として扱わないことが重要です。

多言語UIテストでは、画面を開くだけでなく、購入ボタン、入力欄、エラー表示、ナビゲーション、戻る操作など、文字列が長くなったときに崩れやすい要素を操作します。スクリーンショットには言語、地域、ビルド識別子を分かる形で残し、翻訳確認用の証拠とApp Store向けの宣材画像を混同しないようにします。

Appleはローカライズ用スクリーンショットの作成方法を案内しています。スクリーンショット生成をUIテストの最後に組み込み、画面遷移の途中で保存されないよう、表示待ちやログイン状態を明示してください。

リモートMacで多言語UIテストとスクリーンショットを実行するには、何が必要でしょうか。
SSHでコマンドを送るだけでなく、シミュレーターを起動できるグラフィカルセッション、固定したXcodeプロジェクト、Test Plan、テストデータ、保存先を準備します。VNCやWebコンソールで同じ画面を確認できるようにし、SSH接続が切れても処理と結果保存が止まらない構成にします。

なお、シミュレーターを使うUIテストは、文字列抽出だけのジョブとは異なります。画面セッションの有無、シミュレーターの状態、テストアカウントの有効性を別の前提条件として記録してください。

CIでは、すべてを一つの長いジョブに詰め込まない方が原因を追いやすくなります。次のように段階を分けます。

1. ソース変更を取得し、対象Schemeと構成を固定します。
2. String Catalogの差分と、抽出された文字列の未処理項目を確認します。
3. xcodebuildで指定したTest Planを実行し、代表的な言語・地域のUIテストを動かします。
4. テスト結果ファイルとローカライズ用スクリーンショットを保存します。
5. Archiveを作成し、生成されたBundleに想定言語のリソースが含まれるか確認します。
6. 失敗を翻訳不足、画面レイアウト、地域形式、署名・実行基盤の問題に分類します。

Appleのxcodebuildによるローカライズ内容の書き出しと、ローカライズ内容の取り込みを使う場合も、ファイルの受け渡しだけで翻訳完了とは判定しません。取り込み後にCatalogの差分、実行画面、最終Archiveを再確認します。

リモートMacでは、SSH切断、ホスト再起動、同じジョブの再実行を想定します。結果ファイルの保存先をジョブ固有のディレクトリにし、途中生成物を次の実行が誤って再利用しないようにします。処理を再実行したとき、同じ入力から同じテスト条件と判定結果が得られることを確認してから、プルリクエストの必須検査や発行前ゲートに移します。

多言語アプリを公開する前に、何を確認すべきでしょうか。
未翻訳項目の有無だけでなく、代表的な言語で主要導線を実行し、文字切れ、重なり、誤った地域形式、右から左の配置、フォールバック、Archive内のリソースを確認します。編集画面の状態が良好でも、最終成果物に必要な言語が含まれなければ公開判定は保留です。

判定は次の三つに分けると運用しやすくなります。

• 継続：抽出、翻訳、UI、地域形式、Archiveのすべてが合格している。
• 修正後に再実行：翻訳不足や画面の文字切れなど、アプリ側で直せる問題がある。
• 発行を保留：テストセッション、シミュレーター、署名、結果保存など、検証基盤そのものが不安定である。

翻訳内容の受け渡しが必要な場合は、Appleのローカライズテストに関する公式資料と入出力の手順を基準に、対象ファイルを保存します。次回のリリースで同じ言語・地域ケースを再利用できるよう、失敗した画面、条件、修正内容、再実行結果を一緒に残してください。

ローカルMacだけで実行する構成には、スリープや再起動でジョブが止まる、Xcodeとシミュレーターがローカル容量を占有する、開発作業と発行検査が同じ環境を奪い合う、という問題があります。特にUIテストでは、作業者のログイン状態や手動操作に依存すると、同じ条件を再現できません。

そのため、長期的に必要な条件を先に整理します。Macを常時稼働させる必要がなく、発行前や定期回帰だけを実行するなら、必要な期間だけMac環境を用意する方法が適しています。反対に、毎日大量のビルドを行う、物理iPhoneや専用周辺機器を接続する、ネットワークから切り離された署名環境が必要、といった場合は、専用の自社設備や常設環境の方が向いています。

NUKCLOUDのリモートMac利用環境を検討する場合は、まずXcode、シミュレーター、Test Plan、テスト結果の保存先を同じ環境で維持できるかを確認します。日本向けの運用条件を確認したい場合は、日本向けMac利用案内で、必要な利用期間と接続方法がプロジェクトの実行形態に合うかを照合してください。

String Catalog多言語テストは、翻訳率を眺める作業ではありません。文字列抽出、言語・地域の行列、画面の実行結果、スクリーンショット、Archiveという異なる証拠を順番に結び付け、失敗した段階を特定できるようにする作業です。ローカルMacを常時確保できないチームなら、この検証手順をリモートMacへ移し、再実行できるTest Planと成果物保存を先に整えると、発行判断を人の記憶に依存しにくくなります。