💡 この記事の3行まとめ
- Xcode のエラーとログは量が多く、社内の識別子を含むため、翻訳の手段は「速さ」より先に「どこで処理するか」で選ぶべきです。
- 比較の軸は処理場所・送信の有無・原文の可視性の3つ。オンデバイス処理なら送信経路がなく、原文も残ります。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Vision による端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回まで。
📌 この記事の対象読者
- Xcode のビルドエラーや実行ログを、英語のまま読み飛ばしている方
- ログに社内のモジュール名や顧客名が出てくるため、外部サービスへの貼り付けを避けたい方
- 翻訳の手段を「処理場所」という観点で比較したことがない方
Xcode の英語は「読めない」より先に「貼れない」
Xcode のビルドエラーは、Swift コンパイラが返す英文です。実行ログは、アプリと OS が出力する英文です。どちらも技術英語として素直な部類で、翻訳サービスに通せば日本語になります。それなのに、多くの人がそこで止まります。
理由は3つあります。1つ目は量です。ビルドログは数千行になることがあり、全文を訳すという発想そのものが非現実的です。2つ目は連鎖です。1つの型エラーが10件の派生エラーを生むので、上から読むと最初の原因にたどり着く前に疲れます。3つ目は中身です。ログには社内のモジュール名、ターゲット名、場合によっては顧客名を含むテストデータの識別子がそのまま出ます。
この3つ目が、手段の選択を難しくします。クラウド型の翻訳は、入力した文字列をサーバーへ送り、訳文を受け取ります。ブラウザ拡張も内部で外部へ問い合わせます。つまり、貼る行為がそのまま送信になります。ビルドが通らない焦りの中で、毎回「この文字列は送ってよいか」を判断するのは現実的ではありません。
だから比較の順番を変える必要があります。速いかどうか、訳が自然かどうかより先に、どこで処理されるか。処理場所が端末内なら、送信経路が存在しません。この一点を最初に決めておくと、以降の判断が全部軽くなります。
もう一つの見落としは、表示位置です。Xcode の Issue Navigator や Report Navigator は、翻訳結果を別ウィンドウで開くと隠れます。隠れると、訳文と該当行を交互に見比べることになり、行番号を目で追う作業が発生します。原文の上に訳が出るかどうかは、ログ読解では速度に直結します。
解決策：オンデバイス処理を前提に、読む範囲を3段階で絞る
手順1：エラーは「最初の1件＋note 行」だけを囲む
ビルドが失敗したら、まず Issue Navigator の一番上だけを見ます。Xcode はエラーを並べますが、根本原因はたいてい最初の1件です。そこに付いている note: 行も一緒に確認します。note には「型はこう推論した」「ここで定義されている」といった補足が入っており、原因の特定に効きます。
⌃S（Control + S） を押し、エラー1件と note 行を含む矩形を囲みます。訳は 0.3秒 で最前面に出て、原文は隠れません。エラー本文の英文と、自分のコードの該当行が同じ画面に残るので、訳文を読んだあとに目線を戻す距離が短くて済みます。
2件目以降は、最初の1件を直してから再ビルドして確認します。連鎖エラーを全部訳すのは、ほとんどが無駄になります。
手順2：ビルドログは「検索してから」囲む
Report Navigator のビルドログは、全文を読む対象ではありません。まず検索します。error:、warning:、Undefined symbol、failed、自分のターゲット名。検索で絞ってから、ヒットした前後数行だけを矩形で囲みます。
この順番が重要なのは、ログが時系列で流れるからです。リンカエラーは、実際の原因より後に大量のシンボル一覧を出します。上から読むと、無関係なシンボル名を延々と読むことになります。検索で当たりを付けてから囲めば、1回の囲みで原因に届きます。
Zipp は Apple Vision で画面の文字を認識し、端末内で翻訳します。画面画像の外部保存ゼロなので、社内モジュール名を含むログでも、送信可否を悩まずに読めます。訳文が原文に重なるため、ログの行の位置も動きません。
手順3：実行ログは「自分のファイル名を含む行」から読む
実行時のクラッシュログやコンソール出力は、スタックトレースを含みます。ここで読むべきは、自分のプロジェクトのファイル名が出てくる行です。フレームワークの内部フレームは、読んでも対処できないことがほとんどです。
自分のファイル名を含む行と、その直後の fatal error: や例外メッセージを囲みます。訳文でメッセージの種類を掴み、原文で変数名と行番号を確認する。この分担なら、ログの英語を全部理解する必要はありません。
1日に何度もビルドを回す日は、囲む回数も増えます。1日15回までという範囲で足りるように、まず「最初の1件」と「自分のファイルの行」に絞る。この習慣が、結果的に読解の速度を上げます。
手段を処理場所で比べる
【処理する場所】
従来：外部サービスのサーバー上
Zipp：Apple Vision による端末内処理
【送信される情報】
従来：ログ全文（社内名・識別子を含みうる）
Zipp：画面画像の外部保存ゼロ（画面の矩形のみを端末内で処理）
【大量ログの扱い】
従来：全文を貼ると読み切れない量になる
Zipp：検索してから必要な数行だけ囲める
【表示位置】
従来：別タブ・別ウィンドウになり、Xcode が隠れる
Zipp：最前面に重なり、原文と同時に見える
【原文の可視性】
従来：訳文だけを見ることになりやすい
Zipp：原文が隠れず、行番号もそのまま
【試しやすさ】
従来：アカウントや契約の確認が必要な場合がある
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 端末内処理だと、コンパイラ用語の訳が不安です。 A. 訳語が合わないことはあります。そのときに原文が隣に残っているかどうかが決定的で、expected inferred mutable といった語は原文のほうが確実です。訳文は意味の当たりを付けるために使い、確定は原文で行うのが現実的です。
Q. ビルドログが長すぎて、どこを囲めばいいか分かりません。 A. まず error: で検索してください。ヒットが多すぎる場合は、自分のターゲット名を追加して絞ります。絞ってから前後数行を囲むのが基本で、ログ全体を囲む場面はほとんどありません。
Q. 1日15回でビルドを何度も回す日は足りますか？ A. 最初の1件と自分のファイルの行に絞れば、1回のビルドで囲むのは2〜3回です。連鎖エラーを全部訳さないことが、回数を守る最大のコツになります。
Q. ログをそのまま翻訳サービスに貼る運用を続けてもいいですか？ A. 規程が許すなら選択肢の一つです。ただしログには社内の識別子が含まれやすく、貼るたびに判断が必要になります。判断を毎回しないで済む経路を既定にしておくほうが、長い目では楽になります。
処理場所を先に決めれば、ログは読む対象に変わる
Xcode の英語がつらいのは、語彙の難しさより量と連鎖です。だから翻訳の精度を上げるより先に、処理場所と読む範囲を決めます。端末内で処理し、最初の1件と自分のファイルの行だけを囲む。それだけで、ビルドログは「流れて消える文字」から「判断できる材料」に変わります。
次のビルドで、Issue Navigator の一番上のエラーを ⌃S で囲んでみてください。訳が出て、原文と行番号がそのまま残っている。その確認が、以後のログ読解の基準になります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh
`