💡 この記事の3行まとめ
- オフラインで詰まる原因は翻訳の精度ではなく、「読む直前にネットワークへ取りに行く前提」で動いていることです。
- 解決は出発前に読める状態を確定する → 移動中は生きている機能だけで読む → 復帰後に差分だけ拾い直すの3手順。順番を固定すれば、機内でも客先でも読解は止まりません。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで0.3秒。Apple Visionによる端末内処理で画面画像の外部保存ゼロ、無料でダウンロード（登録不要）、1日15回まで使えます。
📌 この記事の対象読者
- 新幹線・機内・客先の待ち時間に、たまったIssueやPRを片付けたい方
- オフラインになった瞬間、開いていたページが読めなくなって手が止まる方
- 会議室のゲストWi-Fiや検証室など、回線が細い場所でGitHubを開くことのあるエンジニア
オフラインで止まるのは、翻訳の精度ではなく「取りに行く前提」
移動中の空き時間にIssueを読もうとして、開いた瞬間に白い画面が返ってくる。一度読めた本文が、コメントを開いた途端に消える。オフラインで最初に裏切られるのは、たいてい翻訳ツールではなくページそのものです。
ここで多くの人は「オフラインでは読めない」と結論づけます。しかし実際に壊れているのは読む能力ではなく、読む順番です。私たちは無意識に、本文を読み、リンクを開き、差分を見て、ログを確認する順番で動いています。この順番の各段階がネットワークに依存しているため、途中で切れると全体が止まります。
オフラインで起きる詰まりは、大きく3つに分かれます。1つ目は未取得（まだ開いていないIssue、まだ読み込んでいないdiff）。2つ目は未描画（開いたが本文が読み込まれていない状態）。3つ目は未確定（表示はされているが最新かどうか分からない状態）。原因も対処も違うこの3つが、現場では「読めない」という一言にまとめて処理されます。だから毎回同じ場所で止まります。
もうひとつ、GitHub特有の事情があります。IssueやPRの本文は、英語の自由文であると同時に構造を持った文書です。見出し、チェックリスト、コードブロック、差分、ログ。この構造は通信が切れても画面に残ります。つまり、一度描画し終えた画面は、オフラインでも完全な教材になる。ここに気づくと、対策の方向が変わります。
解決策：出発前に確定させ、移動中は生きている機能だけを使う
手順1：出発前に「オフラインで読む一覧」を確定させる
最初の手順は移動前に済ませます。読む予定のIssueとPRを5件まで選び、それぞれを開いて本文とコメントを最後までスクロールし、画像も表示させておきます。ポイントは「開く」ではなく「描画し終える」ことです。タブを開いただけでは本文は読み込まれていません。
同時に読む順番を決めます。判定に使うのは多くの場合、再現手順・期待値・実測値の3ブロックです。この3つが1画面に収まるよう、ブラウザの拡大率を調整しておきます。オフラインでは再読み込みが失敗するので、表示できた状態がそのまま作業台になります。
5件に絞るのは、絞らないと読まないからです。10件開いて3件しか読めないより、5件開いて5件読み切るほうが、復帰後の作業は軽くなります。
手順2：翻訳を端末内で完結させ、囲む単位を固定する
移動中の翻訳は端末の中で終わらせます。⌃S（Control + S） を押し、読みたい範囲をドラッグで囲むと、0.3秒で訳が最前面に表示されます。処理はApple Visionによる端末内処理で画面画像の外部保存ゼロ。回線の有無に関係なく動くので、機内モードのままでも手順は変わりません。
囲む単位はブロック1つに固定します。再現手順のブロックだけ、期待値と実測値のブロックだけ、という具合です。全文をまとめて囲むと、環境情報と推測が混ざって訳文が長くなるだけで、判断は速くなりません。オフラインでは、この囲み直しの回数を減らすことがそのまま時間の節約になります。
手順3：復帰後に「差分だけ」を拾い直す
回線が戻ったら、読んだ内容を最初から確認し直すのではなく、変わった部分だけを見ます。具体的には、開いていたIssueの更新時刻、PRの新しいコミット、CIの結果です。オフライン中に読んだ本文が古くなっていないかは、この3点でほぼ判断できます。
ここで大事なのは、オフライン中に読んだ内容を訳文ではなく自分の言葉で1行残しておくことです。復帰後に見るのは、その1行と現在の画面の差分です。訳文をそのまま保存すると、原文と突き合わせる作業が復活してしまいます。
オフライン対策を比べる
【回線が切れたとき】
従来：訳を取るたびに失敗し、作業ごと止まる
Zipp：端末内処理のため、回線に依存しない
【事前準備】
従来：特に決まっておらず、その場で開く
Zipp：読む5件を描画し終えるだけ
【送信経路】
従来：サービスごとに設定と確認が必要
Zipp：画面画像の外部保存ゼロで、確認する設定がない
【囲む単位】
従来：全文をまとめて貼りがちで訳文が長い
Zipp：ブロック1つに絞って囲める
【復帰後の確認】
従来：訳文を保存し、原文と突き合わせる
Zipp：自分の1行メモと画面の差分だけ見る
【試しやすさ】
従来：利用条件をサービスごとに確認する
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 機内モードのまま本当に使えますか？ A. 翻訳の処理が端末内で完結するため、手順は変わりません。ただしGitHubのページ自体は読み込みが必要なので、出発前に描画し終えた画面であることが前提です。ツールとページで依存先が違う、と分けて考えるのがコツです。
Q. オフライン中に新しいIssueを開きたくなったら？ A. その場では開かず、URLだけをメモに残してください。中途半端に開くと本文が欠けた状態で判断することになり、復帰後に読み直す手間が増えます。移動中に「読む一覧」を増やさないのが原則です。
Q. 5件では足りません。 A. 件数を増やすより、1件あたりの囲み方を絞ってください。判定に必要なのは再現手順と期待値・実測値の3ブロックで、たいてい1件あたり数回の囲みで足ります。1日15回までという範囲も、この絞り方なら現実的に収まります。
Q. 復帰後の差分確認はどこから見ますか？ A. 更新時刻、新しいコミット、CIの結果の3つです。この3つが変わっていなければ、オフライン中に読んだ内容はそのまま使えます。変わっていた場合は、変わったブロックだけを囲み直せば十分です。
オフラインは、読む順番を先に決めた人から強くなる
移動中の読解が止まるのは、回線のせいだけではありません。読む対象を絞らず、描画し終える前に移動を始め、復帰後に全部を確認し直す。この3つが重なると、回線があっても同じように止まります。
出発前に5件を描画し終える。移動中はブロック単位で ⌃S を押す。戻ったら差分だけを見る。この順番を一度決めてしまえば、オフラインは特別な状況ではなく、いつもの作業の延長になります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh