💡 この記事の3行まとめ

  1. オフラインや閉域網でDockerが止まると、Dockerのエラーと翻訳経路の断絶が同時に起きます。クラウド翻訳は、いちばん必要な場面で使えません。
  2. 読むべきは「名前解決」「TLS・プロキシ」「ローカルにイメージが無い」の3種類で、どの層で止まったかで復旧手順が変わります。
  3. Mac専用OCR翻訳『Zipp』は ⌃S で囲んで 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。ネットワークが無くても読めます。無料でダウンロード（登録不要）、1日15回まで。

📌 この記事の対象読者

  • 客先の閉域網や社内ネットワークで、Dockerのイメージ取得に失敗した方
  • 移動中・機内・現場など、ネットワークが細い場所でコンテナを触る方
  • エラーをクラウド翻訳に送ること自体が許可されていない環境で作業している方

オフラインで詰まると、詰まりが二重になる

ネットワークが使えない場所でDockerを動かすと、たいてい同じ画面で2つの問題が同時に起きます。

1つ目は、イメージが取れないことです。docker pull も docker compose up も、既定ではレジストリに取りに行きます。返ってくるのは英語のエラーです。代表的なものを挙げます。

  • dial tcp: lookup registry-1.docker.io on ...: no such host — DNSが引けていない
  • i/o timeout / TLS handshake timeout — 経路が通っていない、または途中で切られている
  • proxyconnect tcp: ... — プロキシ設定がDocker側に渡っていない
  • manifest unknown / pull access denied — 名前か認証の問題（通信自体は届いている）
  • Error response from daemon: No such image — ローカルに存在しない（通信不要の失敗）

2つ目は、そのエラーを読む手段が絶たれることです。ここが本当の詰まりです。ブラウザで翻訳サイトを開こうとしても開かない。スマートフォンのテザリングも使えない。結果として、英語の1行だけが画面に残ります。しかも閉域網では、そもそも外部への送信が規約で禁止されていることが多く、ネットワークが復旧しても「貼って訳す」という手段が使えません。

つまりオフライン環境では、翻訳の可否がネットワークの可否に従属してしまう設計が破綻します。ここを分離しておくことが、現場での復旧速度を決めます。読みたいのは「どの層で止まったか」という1点だけなのに、その1点に到達するために通信が必要、という状態を避けるわけです。

もう一つ、オフライン特有の事情があります。復旧の手順は、エラーの種類によってまったく別です。DNSなら resolv.conf や resolver の設定、プロキシならデーモン側の環境変数、イメージ欠如なら別マシンでの save と load。ところが英語のエラーを漠然と読むと、どれも「通信できない」という同じ顔に見えます。層の判別ができないまま、思いつく設定を順に試す。これがオフライン作業を長時間化させる典型的なパターンです。

解決策：通信に依存しない読み方を先に作る

Zippは画面に描画された文字をOCRで読み、Apple Visionで端末内処理します。翻訳の経路にネットワークが介在しません。オフライン環境での「読めない」を、通信の復旧と切り離せます。

手順1：エラーを3つの層に分類する

まず、目の前の1行がどの層の失敗かを決めます。

  • 第1層：名前解決（no such host / lookup ...）… 通信以前の問題。DNSの設定を見る。
  • 第2層：経路と認証（i/o timeout / TLS handshake timeout / proxyconnect）… プロキシ、証明書、ファイアウォール。
  • 第3層：ローカルの状態（No such image / manifest unknown）… 通信が届いていても起きる。イメージの持ち込みで解決する。

分類するだけで、次に開くべき設定画面が決まります。ここで重要なのは、分類に必要な情報はたいてい1行に収まっていることです。ログ全体を訳す必要はありません。

手順2：⌃S でエラー行を囲み、通信なしで読む

⌃S（Control + S） を押し、エラー行と、その直前のコマンド行を矩形で囲みます。0.3秒で訳が最前面に表示され、原文は隠れません。ネットワークの状態に関係なく動くため、機内モードのままでも、閉域網のままでも同じ結果になります。

ここで一度、ネットワークを切った状態で試しておくことを勧めます。いざというときに動くかどうかは、実際に切って確かめる以外に方法がありません。事前に確認しておけば、現場で「翻訳が開かない」という2つ目の詰まりに直面しません。

手順3：読んだ結果で復旧の順序を決め、記録に残す

層が分かったら、復旧の順序を固定します。

  • 第1層なら、まず名前が引けるかを切り分け、次にDockerデーモン側のDNS設定を確認する。
  • 第2層なら、シェルのプロキシ設定がデーモンに渡っているかを確認する。シェルで通るのにDockerで通らないなら、渡っていない可能性が高い。
  • 第3層なら、ネットワークのある別のマシンでイメージを保存し、ファイルとして持ち込んで読み込む。

そして、どのエラーがどの層だったかを1行でメモします。次に同じ現場に入ったとき、同じ分類がそのまま使えます。オフライン作業は再現性がすべてです。

オフライン環境での読み方を比べる

【ネットワーク前提】
従来：翻訳のたびに外部通信が必要
Zipp：通信不要。端末内で完結

【閉域網での可否】
従来：そもそも開けないことが多い
Zipp：そのまま使える

【エラー層の判別】
従来：全文訳で層が混ざり、判断が遅れる
Zipp：1行を狙って囲めるので層が残る

【復旧の順序】
従来：英語を読み切ってから考える
Zipp：分類してから設定を開ける

【ログの扱い】
従来：社内のエラーが外部へ送られる
Zipp：Apple Visionで端末内処理・画面画像の外部保存ゼロ

【試しやすさ】
従来：通信できる場所でしか確認できない
Zipp：無料でダウンロード（登録不要）／1日15回まで

よくある質問（FAQ）

Q. 完全にネットワークを切った状態でも使えますか？ A. 使えます。OCRと翻訳の処理は端末内で完結し、外部送信はありません。インストールと初回起動だけはダウンロードが必要なので、ネットワークのある場所で準備しておいてください。

Q. プロキシ認証が必要な環境でも読めますか？ A. 読み取り自体は認証と無関係に動きます。認証が絡むのはDockerがレジストリへ接続する段階です。エラー文を読んで「認証で止まっているのか、経路で止まっているのか」を切り分けてから設定を触るほうが早く解決します。

Q. エラーが出ずに固まる場合はどうすればいいですか？ A. 固まる場合は、docker info や docker version のように短い出力で状態を確認し、その数行を囲んでください。タイムアウト待ちなのか、デーモンに届いていないのかで、見るべき場所が変わります。

Q. 1日15回で、復旧作業は足りますか？ A. 層の判別は1行で足りるため、1回の囲みで次の手が決まることが多いです。何度も囲む必要が出るのは、設定を変えて再実行するたびに新しいエラーが出る場合です。その場合も、直前のエラーと新しいエラーを1回でまとめて囲めば回数を抑えられます。

「読む」を通信から切り離しておく

オフライン環境でのトラブル対応は、英語力より順序で決まります。どの層で止まったのかを1行から判別し、その層に合った設定を開く。この順序さえ持っていれば、通信が細くても復旧は進みます。

問題は、その1行を読むために通信が必要な設計になっていることです。読む手段を端末内に置いておけば、ネットワークの状態と読解の可否を切り離せます。次の現場に入る前に、ネットワークを切った状態で一度 ⌃S を試しておいてください。その確認が、いちばん忙しい瞬間の余裕になります。

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

`