💡 この記事の3行まとめ

  1. Dockerの用語が読みづらいのは、語彙が足りないからではなく1つの概念に複数の英語名があるからです。image と container、volume と mount のように。
  2. 用語を単独で訳すと訳語が最短一致で揺れます。定義文ごと囲むと、同じ概念に同じ訳語が返りやすくなります。
  3. Mac専用OCR翻訳『Zipp』は ⌃S で囲んで 0.3秒、Apple Visionによる端末内処理。無料でダウンロード（登録不要）、1日15回まで使えます。

📌 この記事の対象読者

  • Dockerの公式ドキュメントを読んでも、用語の関係が頭に入ってこない方
  • 同じ概念が別の単語で出てきて、別物だと誤解した経験のある方
  • 訳した内容を社内のメモや手順書に残すとき、訳語がばらついて困っている方

Dockerの用語が崩れるのは、概念と名前が1対1でないから

Dockerの英語を読んでいて詰まる原因は、語彙力ではありません。1つの概念に複数の名前があるという、Docker固有の事情です。

代表的なものを並べます。image と container は別物ですが、会話では「イメージを動かす」と「コンテナを動かす」が混ざります。volume と bind mount はどちらもデータの置き場所で、訳すと両方が「ボリューム」「マウント」に行き着きます。tag と digest はどちらもイメージの版を指しますが、可変か不変かが違います。service と task と container は、同じ実行単位を層の違う視点で呼んだものです。compose file と stack も、定義と展開結果の関係にあります。

翻訳ツールは、この名前の違いを概念の違いとして扱えません。volume を「ボリューム」と訳し、bind mount を「バインドマウント」と訳す。日本語としては正しいのに、読み手には「2つの別々の機能」に見えます。実際には同じ「データを永続化する場所」という目的の別手段です。ここで誤解が生まれると、設定ファイルのどこを直すべきかの判断がずれます。

さらに、訳文そのものが言い換える問題があります。同じ container が、ある文では「コンテナ」、別の文では「容器」と訳されることがあります。build は「ビルド」だったり「構築」だったりします。訳としてはどちらも成立しますが、読み手の頭のなかで語が2つに分裂します。分裂した語は、検索でも共有でも機能しません。日本語の「容器」で検索しても、Dockerの文脈では何も出てきません。

ここに、訳文をそのまま手順書へ貼るという落とし穴が重なります。訳文は読みやすく整えられているぶん、原文の識別子（docker run, -v, --mount）が文章に溶けています。これをそのまま共有すると、受け取った人はどのコマンドの話か分からないまま、日本語の説明だけを読むことになります。用語が崩れるというより、用語と操作の対応が失われる。これがDockerのドキュメントで起きている本当の問題です。

解決策：概念単位で訳語を固定し、囲み方を型にする

手順1：用語を「概念」でまとめ、英語名を並べる

まず、読んでいる範囲に出てくる用語を、概念ごとにまとめます。1つの概念に、英語名を複数ぶら下げる形です。

  • 実行単位：container / task / replica
  • 定義：image / Dockerfile / compose file / stack
  • 保存領域：volume / bind mount / tmpfs
  • 版：tag / digest
  • 通信：network / port mapping / expose

このまとめを作ると、訳語を概念に対して1つ決められます。volume と bind mount は「保存領域」という同じ箱に入るので、訳語も「保存領域（永続）」のように統一できます。英語名が違っても、日本語の訳語が同じ箱に収まる。これで、読むたびに語が分裂するのを防げます。

この表は5行で十分です。全部の用語を整理しようとすると、表を作る作業そのものが目的化します。詰まった概念だけを追加していく前提で始めてください。

手順2：用語ではなく「定義文1文」を ⌃S で囲む

次に、囲み方の型を決めます。用語を単独で囲まないことです。volume という単語だけを囲むと、訳は文脈を持たない最短一致になり、訳語が揺れます。代わりに、その用語が説明されている文1つを囲みます。

⌃S（Control + S） を押し、定義文の行を矩形で囲みます。0.3秒で訳が最前面に出て、原文は隠れません。文ごと囲むと、volume が「データを永続化する仕組み」として説明されている文脈ごと訳されるため、訳語が機能の説明を含んだ形で返ります。

同じ概念を別の英語名で見かけたときも、同じ型で囲みます。bind mount の定義文を囲み、volume の定義文を囲む。2つの訳文を並べると、同じ目的の別手段であることが日本語で確認できます。単語を1つずつ引くより、概念の関係が早く見えます。

手順3：訳語は「英語名とセット」で1行だけ残す

囲んだあとに残すのは、訳文そのものではなく1行のメモです。形式は「英語名 / 採用する訳語 / ひとことの注記」に固定します。

たとえば digest / ダイジェスト（不変の識別子） のように書きます。tagが可変でdigestが不変、という違いを注記に残しておけば、次に出会ったときに迷いません。英語名を必ず併記するのは、原文で検索できる形を保つためです。日本語の訳語だけで検索しても、公式ドキュメントには到達できません。

そして、訳文をそのまま社内文書に貼らないこと。貼るなら、英語名とコマンドは原文のまま残し、日本語は説明の部分だけにする。この分担を守ると、受け取った人が「どのコマンドの話か」を失わずに済みます。

用語の扱い方を比べる

【訳す単位】
従来：単語1つ。文脈が落ちる
Zipp：定義文ごと囲めるので文脈が残る

【訳語の安定】
従来：文ごとに「コンテナ」「容器」が混ざる
Zipp：同じ囲み方で同じ訳語を引き当てやすい

【概念の関係】
従来：別名同士が別物に見える
Zipp：2つの定義文を並べて関係を確認できる

【原文の保持】
従来：訳文だけが残り、英語名が消える
Zipp：原文が隠れないので英語名を併記できる

【共有時の齟齬】
従来：訳文を貼るとコマンド名が文章に溶ける
Zipp：英語名とコマンドは原文のまま残せる

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

よくある質問（FAQ）

Q. 用語だけを囲むと、なぜ訳語が揺れるのですか？ A. 文脈がないぶん、訳す側が最も短い言い換えを選ぶためです。mount は「マウント」にも「搭載」にもなり得ます。定義文ごと囲めば、前後の語が手がかりになり、機能を表す訳語が返りやすくなります。

Q. チームで訳語を揃えるにはどうすればいいですか？ A. 英語名と訳語をセットにした5行の表を共有するのが現実的です。訳文そのものを共有すると、人によって書き換えられて崩れます。英語名をキーにすれば、訳語が変わっても対応が保てます。

Q. 訳語が明らかに変なときはどうしていますか？ A. そのまま採用せず、英語名で公式ドキュメントを引きます。Zippは原文を隠さないため、怪しいと感じた語をそのまま原文で確認できます。訳は理解の入口、原文は確認の場、と役割を分けてください。

Q. 1日15回で用語の整理は進みますか？ A. 1回で定義文を1つ囲めば、概念が1つ片付きます。15回あれば15概念で、Dockerの主要な用語はほぼ覆えます。毎日続けるより、詰まった日にまとめて囲むほうが定着します。

用語は「覚える」より「同じ箱に置く」

Dockerの英語が読みにくいのは、単語を知らないからではありません。同じものを指す名前が複数あり、訳すたびに日本語の名前も増えていくからです。だから、用語を1つずつ覚えるのではなく、概念の箱に英語名をまとめ、箱に1つの訳語を割り当てる。この作業だけで、ドキュメントの見え方が変わります。

次の公式ドキュメントで、volume と bind mount の定義文を続けて ⌃S で囲んでみてください。2つの訳文が同じ目的を指していると分かった瞬間、用語は覚える対象から使える道具に変わります。

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

`