💡 この記事の3行まとめ

  1. CI のログが読めないのは英語力ではなく、結論が末尾にあり、原因がその手前にあるという構造を知らないまま全文を読んでいるからです。
  2. 読む順序を「失敗したステップ → ログ末尾のエラー行 → その直前のコマンド」に固定すると、翻訳する範囲も自動的に決まります。
  3. Mac専用OCR翻訳『Zipp』は ⌃S で囲んで 0.3秒、Apple Visionの端末内処理。無料でダウンロード（登録不要）、1日15回まで。

📌 この記事の対象読者

  • GitHub Actions の赤いバツを見て、ログを開いたまま固まった経験のある方
  • Process completed with exit code 1 だけを読んで、原因を見失った方
  • CI の失敗対応を、翻訳に頼りながら短時間で終わらせたいエンジニア

CI のログが読めないのは、読む順序が決まっていないから

GitHub Actions の失敗画面には、情報が層になって並んでいます。左にジョブの一覧、中央にステップの一覧、右にログ。上部には annotation と呼ばれる要約。そしてログの末尾には、たいてい次の1文があります。

Error: Process completed with exit code 1

この1文を翻訳すると「プロセスは終了コード1で完了しました」になります。日本語として正しいのですが、これは原因ではありません。終了コードは「失敗した」という結果の言い換えで、どこで失敗したかは書かれていません。ここを結論だと誤解すると、ログ全体を上から読み直すことになり、数百行の英文と向き合うことになります。

もうひとつの罠が折り返しです。GitHub のログは画面幅で折り返され、長いパスやコマンドが途中で切れて表示されます。この状態で範囲をコピーすると、原文には存在しない改行が混ざります。英文としては途中で切れた文になり、翻訳結果も文の途中で崩れます。「訳がおかしい」のではなく、コピーした時点で壊れているケースが、CI のログでは特に多いのです。

つまり必要なのは、英語を学ぶことでも高機能な翻訳を探すことでもなく、読む順序と囲む範囲を先に決めることです。順序が決まれば、翻訳に渡す分量は数十行から数行に減ります。

解決策：読む順序を3手順に固定する

手順1：失敗したステップを特定する（ログはまだ読まない）

最初にやるのは、英文を読まないことです。ジョブの一覧から赤い印のついたジョブを選び、そのなかで赤い印のついたステップ名を探します。ステップ名は Run npm test のように実行されたコマンドがそのまま名前になっていることが多く、ここだけで原因の種類が半分決まります。

ビルドなのか、テストなのか、デプロイなのか。この3つは対処がまったく違います。ステップ名を見ずにログを読み始めると、無関係な警告文を翻訳して時間を使います。英文を読む前に、英語以外の手がかりを全部使うのが、CI 読解の第一手です。

手順2：ログの末尾から、最初のエラー行を探す

次に、そのステップのログを開き、末尾から上へさかのぼります。探すのは error、Error:、failed、##[error] のいずれかを含む行です。最初に見つかったものが、多くの場合いちばん内側の失敗です。

見つけたら、そこで止めて周囲を囲みます。範囲はエラー行1〜2行と、その直前に実行されたコマンド1行です。⌃S（Control + S）を押してドラッグで囲むと、0.3秒で訳が最前面に表示され、原文は隠れません。

この範囲に絞る理由は3つあります。第一に、CI のエラーは「実行したコマンド」と「その結果」が対になっているため、片方だけでは意味が取れません。第二に、折り返しで壊れた長い行を避けられるからです。第三に、expected と received のような対の語が同じ範囲に残るからです。全文を訳すのではなく、対を訳すという発想に切り替えると、読む量が一段落ちます。

手順3：annotation と再実行の判断を、訳のあとで行う

訳を読んだら、画面上部の annotation を確認します。annotation は失敗箇所のファイル名と行番号を含む要約で、ログの本文より短く、構造化されています。ログで原因の種類を掴み、annotation で場所を特定する。この順序なら、訳す分量は数行で済みます。

最後に、再実行するかを決めます。判断材料は「訳文が示した原因が、自分の変更と関係あるか」の1点です。関係がないなら、ネットワークやレジストリ側の一時的な失敗を疑って再実行します。関係があるなら、コードを直します。翻訳は原因の種類を掴むために使い、場所の特定は annotation に任せる。この分担が固定されると、CI の失敗対応は毎回同じ手順で終わります。

ログの読み方を比べる

【読む順序】
従来：上から順に読み、結論まで時間がかかる
Zipp：末尾から辿るため、エラー行に直行できる

【訳す分量】
従来：数百行をまとめて貼ることになる
Zipp：エラー行＋直前のコマンド数行に絞れる

【折り返しの影響】
従来：コピー時に改行が混ざり、文が途中で切れる
Zipp：見た目どおりに囲むため、壊れた改行を拾わない

【対の語の扱い】
従来：expected / received が離れて訳される
Zipp：同じ範囲に残るので、比較の構図が保てる

【原文の確認】
従来：訳文とログを見比べるのに往復が要る
Zipp：原文が隠れず、同じ画面で照合できる

【試しやすさ】
従来：サービスごとに利用条件の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで

よくある質問（FAQ）

Q. exit code 1 の意味を調べれば原因は分かりますか？ A. 分かりません。終了コードは失敗したという結果だけで、原因の種類も場所も示しません。まず失敗したステップ名を見て、次にログ末尾のエラー行を探す順序のほうが早く着きます。

Q. ログが数千行あるときは、どう探しますか？ A. ブラウザのページ内検索で error を後ろから検索するのが現実的です。ただし error を含む警告も混ざるため、見つけた行の前後3行を見て、実行コマンドと対になっているかを確認します。

Q. 訳しても文章が不自然になることがあります。 A. コピーした範囲に、画面の折り返しで入った改行が混ざっている可能性があります。囲む範囲を短くするか、エラー行だけを囲むと改善します。文そのものを訳すのではなく、対になった行を訳す意識も効きます。

Q. 1日15回で CI の失敗対応は足りますか？ A. 1回の失敗で囲むのは通常1〜2回です。回数より、末尾から探す順序を守るほうが成果に効きます。順序を守れば、囲む回数そのものが減ります。

CI の英語は、読む前に範囲を決めると速くなる

Actions のログは長く、英語も固く、折り返しで崩れます。しかし構造は毎回同じです。失敗したステップがあり、末尾にエラー行があり、その直前に実行コマンドがある。この3点を押さえるだけで、翻訳に渡す分量は数十行から数行になります。

次に CI が赤くなったとき、ログの先頭ではなく末尾を開いてください。⌃S でエラー行と直前のコマンドを囲み、原文が残ったまま訳が出ることを確かめる。その1回で、ログを読む時間の見積もりが変わります。

▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh