• 今のブランチと別ブランチで、何がどう違うのか？
• どのコミットで、どのファイルが変更されたのか？

こうした確認を視覚的に確認したい方におすすめです。

GitLensでブランチ間の差分（diff）を確認する

まず、VSCode左側のアクティビティバーから「ソース管理（ブランチのアイコン）」をクリックします。

ソース管理ペイン内に表示されている「GITLENS」セクションを展開します。

GITLENS内の「Branches」をクリックすると、リポジトリ内のブランチ一覧が表示されます。

比較したいブランチにマウスホバーして、「比較アイコン」をクリックします。今回は「feature/sampleブランチの比較アイコン」を選択しています。

比較アイコンをクリックすると、「SEARCH ＆ COMPARE」が開き、「自分が現在いるブランチ（HEAD）」と「選択したブランチ」のファイル差分一覧が表示されます。差分一覧を見ると、どのファイルに変更があるかが一目で分かります。この例では、READMEファイルとsample.jsファイルが変更されていることわかります。

各ファイルをクリックすると、VSCodeのdiffビューで実際の変更行を確認できます。

さらに、Aheadのアコーディオンを開くと、各コミットでどのファイルが変更されたかを確認できます。例えば、コミット01ではREADMEファイルとsample.jsファイルが変更されていることわかります。

ここでも、各ファイルをクリックすると、VSCodeのdiffビューで実際の変更行を確認できます。

GitLensでブランチ間の差分（diff）を確認する別の方法

GitLensでは、別の操作でもブランチ差分を確認できます。

「GitLens Inspectサイドパネル」を開きます。

SEARCH ＆ COMPAREペインで「Compare references」をクリックします。

コマンドパレットが開くので「比較先（Compare To）」を選択します。

次に「比較元（Compare From）」を選択します。

すると、選択した2つのブランチ（またはタグ・コミット）間のファイル差分一覧が表示されます。

本記事のまとめ

この記事では「拡張機能GitLens」を使って、ブランチ間の差分（diff）を視覚的に確認する方法について説明しました。

GitLensを使えば、VSCode上で次のような差分確認が簡単に行えます。

• ブランチ間の差分を一覧で確認できる
• コミット単位で変更内容を追える
• ファイル差分をそのままVSCodeで確認できる
• Working Treeとの比較も可能

Gitコマンドを使わなくても、視覚的に安全・確実に差分確認したい場合に、GitLensは非常に強力なツールです。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

イミュータブルとミュータブルは、「オブジェクトの中身を後から変更できるかどうか」に関係しています。

この記事では、

• イミュータブルとミュータブルの違い
• Pythonの具体的なコード例

を、プログラミング初心者の方にも分かるように丁寧に解説していきます。

「イミュータブル」と「ミュータブル」の違い

まずは、イミュータブルとミュータブルの意味を整理しましょう。

イミュータブル（Immutable）は、「不変の」「変更できない」という意味を持つ英単語です。プログラミングにおいては、一度作成したオブジェクトの中身（状態）を、あとから変更できないという性質を指します。

たとえば、Pythonでは、次のような型がイミュータブルです。

• 数値（int, float）
• 文字列（str）

これらは、作られた瞬間に中身（状態）が確定し、後から中身を直接書き換えることができません。

一方、ミュータブル（Mutable）は、「可変の」「変更できる」という意味を持つ英単語です。プログラミングにおいては、一度作成したオブジェクトの中身（状態）を、後から変更できるという性質を指します。

たとえば、Pythonでは、次のような型がミュータブルです。

• リスト（list）
• 辞書（dict）

これらは、オブジェクトそのものを作り直さなくても、後から中身だけを変更できます。

イミュータブルなオブジェクトの例（Python）

Pythonの文字列（str）はイミュータブルな文字列オブジェクトです。つまり、一度作成した文字列の中身を、直接書き換えることはできません。

以下は、Pythonで一度作成した文字列の中身を変更しようとした例です。

text = "Hello"

# 先頭の文字を変更しようとする
text[0] = "h"

print(text)

上記のコードを実行すると、次のエラーが発生します。

TypeError: 'str' object does not support item assignment

"Hello"はイミュータブルな文字列オブジェクトです。そのため、文字列の各文字（text[0]など）は直接変更できません。

正しい変更方法：新しい文字列オブジェクトを作る

文字列を変更したい場合は、既存の文字列オブジェクトを変更するのではなく、新しい文字列オブジェクトを作ります。以下にサンプルコードを示します。

text = "Hello"

new_text = "h" + text[1:]

print(new_text)

上記のコードでは、"Hello"を分解し、必要な部分を組み合わせて、まったく新しい文字列new_textを作成しています。元のtextは一切変更されていません。このコードを実行すると、以下のような結果が表示されます。

hello

元のtextは変更せず、新しい文字列new_textを作っているのでエラーが発生しなくなります。

「再代入」はエラーにならない理由

次のコードはエラーになりません。

text = "Hello"
text = "World"

これを見て、「あれ？文字列って変更できないんじゃないの？」と思うかもしれません。しかし、ここで行っているのは「文字列の変更」ではありません。

"Hello"という文字列オブジェクトはそのまま存在しています。新しく"World"という文字列オブジェクトを作成して、変数textが指している先を切り替えているだけだからです。つまり、"Hello"を書き換えているのではなく、textが参照するオブジェクトを変えているのでエラーにならないのです。

ミュータブルなオブジェクトの実例（Python）

Pythonのリスト（list）はミュータブルなリストオブジェクトです。つまり、一度作成したリストの中身を、後から自由に変更できます。

以下は、Pythonでリストを生成し、そのリストの要素を変更する例です。

numbers = [1, 2, 3]

numbers[0] = 100

print(numbers)

上記のコードを実行すると、以下のような結果が表示されます。

[100, 2, 3]

このコードでは、[1, 2, 3]というリストオブジェクトの中の要素だけを書き換えています。文字列のときと違ってエラーは発生しません。[1, 2, 3]はミュータブルなリストオブジェクトだからです。

本記事のまとめ

この記事では『イミュータブルとミュータブルの違い』について説明しました。

イミュータブルとミュータブルの違いは「オブジェクトの中身を後から変更できるかどうか」です。

• 文字列（str）や数値（int）はイミュータブル
• リスト（list）や辞書（dict）はミュータブル

また、「変数の再代入」と「オブジェクトの変更」は別物である点も重要です。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

• 入力欄に「何も入力されていないか」を判定したい
• 入力欄に「空白だけ入力されていないか」を判定したい
• 「文字列の途中に空白が含まれているか」を判定したい

この記事では、「JavaScriptで空白をチェックする代表的な4つの方法」を用途別にわかりやすく解説します。

空文字・空白のみ・空白を含む文字列の違い

JavaScriptで入力チェックを行う際、「何も入力されていない状態（空文字の状態）」と「空白だけが入力されている状態」さらに「文字列の途中に空白が含まれている状態」はすべて意味が異なります。

まずは、それぞれの違いを以下にまとめます。

• 何も入力されていない状態（空文字の状態）：""
• 空白だけが入力されている状態：" " や "　"
• 文字列の途中に空白が含まれている状態："hello world"

見た目は似ていても、チェック方法を誤ると意図しないバリデーションエラーや不具合につながるため注意が必要です。

空白のみかどうかを判定（trim()を使う）

「空白だけが入力されているか」を判定したい場合、最もよく使われるのがtrim()を使った方法です。

trim()は文字列の前後の空白をすべて削除します。その結果が空文字""であれば、「空白のみ」と判断できます。

const value = "   ";

const isOnlyWhitespace = value.trim() === "";

console.log(isOnlyWhitespace); // true

半角スペース・全角スペース・改行（\n）やタブ（\t）をまとめて判定できるため、フォーム入力チェックで非常によく使われる方法です。実際にさまざまな文字列を判定すると、次のような結果になります。

空白のみを厳密に判定したい場合（空文字は除外）

「空白だけの入力はNGにしたいが、未入力（空文字）は別扱いにしたい」というケースもよくあります。その場合は、空文字でないことを先にチェックすることで対応できます。

const value = "   ";

const isOnlyWhitespaceStrict = value !== "" && value.trim() === "";

console.log(isOnlyWhitespaceStrict); // true

この条件では、

• "" → false
• " " → true

と、未入力と空白入力を正確に区別できます。

実際にさまざまな文字列を判定すると、次のような結果になります。

空白が含まれているかどうかを判定（includes()を使う方法）

文字列の中に「半角スペースが含まれているか」をシンプルに判定したい場合はincludes()が便利です。

const value = "hello world";

const hasSpace = value.includes(" ");

console.log(hasSpace); // true

なお、この方法で検出できるのは半角スペース" " のみです。タブや改行、全角スペースは検出されない点に注意してください。

実際にさまざまな文字列を判定すると、次のような結果になります。

空白（スペース・タブ・改行）が含まれているかどうかを判定（正規表現を使う方法）

「スペース・タブ・改行など、あらゆる空白文字が含まれているか」を調べたい場合は正規表現を使う方法が最適です。

const value = "hello\tworld";

const hasWhitespace = /\s/.test(value);

console.log(hasWhitespace); // true

\sは空白文字全般を表す正規表現です。

つまり、この方法は「空白文字全般が1つでも含まれているか」をチェックしたい場合に最適です。

実際にさまざまな文字列を判定すると、次のような結果になります。

本記事のまとめ

この記事では『JavaScriptで文字列の空白をチェックする方法』について、用途別に代表的な判定方法を解説しました。

「空文字なのか」「空白だけなのか」「空白文字が含まれているのか」は見た目が似ていてもチェック方法が異なるため、目的に応じて使い分けることが重要です。

最後に、用途別のおすすめ方法を整理しておきます。

入力チェックやフォームバリデーションを実装する際は、本記事の内容を参考に、状況に合った方法を選んでみてください。

最後までお読みいただき、ありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

• 拡張機能が正しく動作しなくなった
• 他の拡張機能やプロジェクト設定と競合するようになった
• 設定項目や仕様が変更され、従来の使い方ができなくなった

このような場合、拡張機能をひとつ前、または特定の過去バージョンに戻すことで問題が解決することがあります。

この記事では、VSCodeの拡張機能を古いバージョンに戻す方法を初心者の方にもわかりやすく解説します。

なぜ拡張機能を古いバージョンに戻したくなるのか

VSCodeの拡張機能は、デフォルト設定では自動的にアップデートされます。

そのため、普段は拡張機能のバージョンを意識することはあまりありません。しかし、アップデートによって不具合が発生した場合、VSCodeの拡張機能を古いバージョンに戻したくなることがあると思います。

VSCodeの拡張機能を古いバージョンに戻す手順

ここでは一例として、Docker拡張機能のバージョンを2.0.0 → 1.29.0に戻す手順を紹介します。

まず、VSCodeの左側のメニューから「拡張機能（四角が4つ並んだアイコン）」をクリックし、一覧から「バージョンを戻したい拡張機能（今回はDocker）」を選択して詳細画面を開きます。

拡張機能の詳細画面で「アンインストール（Uninstall）」ボタンの右側にあるドロップダウンをクリックします。そこから、「特定のバージョンのインストール…（Install Specific Version…）」を選択します。

過去のバージョン一覧が表示されるので、「インストールしたいバージョン（今回は1.29.0）」を選択します。選択すると、そのバージョンが自動的にダウンロード・インストールされます。

インストール完了後、「拡張機能の再起動（Restart Extensions）」ボタンが表示されるので、クリックして拡張機能を再起動します。

拡張機能の詳細画面を確認すると、バージョンが1.29.0にバージョンダウンされていることがわかります。

これで、拡張機能のバージョンダウンは完了です。

本記事のまとめ

この記事では『VSCodeの拡張機能を古いバージョンに戻す方法』について説明しました。

VSCodeの拡張機能は便利な反面、アップデートによって思わぬ不具合が起きることもあります。そんなときは、今回紹介したように過去のバージョンへ戻すことで、問題があっさり解決するケースも少なくありません。

拡張機能の動作がおかしいと感じたら、まずはバージョンを確認し、必要に応じてバージョンダウンを試してみてください。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

• コンテナ名がbeautiful_margulisみたいな自動生成名になっている
• 複数コンテナがあってどれがどれかわからなくなった…
• 分かりやすいコンテナ名を付けて管理したい！

このような悩みを解決するのが--nameオプションです。

この記事では、次の内容を順番にわかりやすく解説します。

• Dockerコンテナの名前とは？
• --nameオプションの使い方
• すでに作成済みのコンテナの名前を変更する方法

Dockerコンテナの名前とは？

Dockerコンテナには、必ず1つの名前が付けられます。Dockerコンテナ作成時に名前を指定しなかった場合、Dockerが自動でコンテナ名を付けます。一例として、以下のコマンドを実行して、Ubuntuコンテナを起動してみましょう。

docker run -it ubuntu:latest

上記のコマンドでは、名前を指定していないため、Dockerがランダムなコンテナ名を付けます。作成されたコンテナを確認するために、docker container ls -aコマンドで作成されたDockerコンテナを確認してみると、ubuntu:latestイメージから作成されたDockerコンテナにbeautiful_margulisという名前が自動で付けられたことがわかります。

$ docker container ls -a
CONTAINER ID   IMAGE           COMMAND       CREATED          STATUS          PORTS     NAMES
a3d7a24de312   ubuntu:latest   "/bin/bash"   59 seconds ago   Up 59 seconds             beautiful_margulis

Dockerコンテナの名前を指定する「–nameオプション」とは？

--nameオプションは、Dockerコンテナ作成時に名前を指定するためのオプションです。基本構文を以下に示します。

docker run [オプション] --name コンテナ名 イメージ名

例えば、以下のコマンドでは、Ubuntuコンテナにmy-ubuntuという名前を付けて起動しています。

docker run -it --name my-ubuntu ubuntu:latest

作成されたコンテナを確認するために、docker container ls -aコマンドで作成されたDockerコンテナを確認してみると、ubuntu:latestイメージから作成された名前がmy-ubuntuのコンテナであることが、一目で分かるようになります。

$ docker container ls -a
CONTAINER ID   IMAGE           COMMAND       CREATED         STATUS         PORTS     NAMES
d727bbe25302   ubuntu:latest   "/bin/bash"   5 seconds ago   Up 5 seconds             my-ubuntu
a3d7a24de312   ubuntu:latest   "/bin/bash"   2 minutes ago   Up 2 minutes             beautiful_margulis

すでに作成済みのコンテナの名前を変更する方法

「Dockerコンテナを作った後で、--nameを付け忘れたことに気づいた・・・」。このような場合でも安心です。Dockerでは後からコンテナ名を変更できます。基本構文を以下に示します。

docker container rename 旧コンテナ名 新コンテナ名

例えば、以下のコマンドでは、beautiful_margulisという名前のDockerコンテナをrename-ubuntuに変更しています。

docker container rename beautiful_margulis rename-ubuntu

docker container ls -aコマンドでコンテナを確認してみると、rename-ubuntuに変更されたことがわかります。

$ docker container ls -a
CONTAINER ID   IMAGE           COMMAND       CREATED              STATUS              PORTS     NAMES
d727bbe25302   ubuntu:latest   "/bin/bash"   About a minute ago   Up About a minute             my-ubuntu
a3d7a24de312   ubuntu:latest   "/bin/bash"   3 minutes ago        Up 3 minutes                  rename-ubuntu

本記事のまとめ

この記事では『Dockerコンテナの名前の指定方法・変更方法』について、以下の内容を説明しました。

• Dockerコンテナには必ず名前が付く
• 名前を指定しないと、Dockerがランダムなコンテナ名を自動生成する
• --nameオプションを使うと、コンテナ作成時に分かりやすい名前を付けられる
• docker container renameを使えば、後からコンテナ名の変更も可能

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

• キーと値の型をまとめて指定したい
• 決まったキーを必ず持つオブジェクトを表現したい

と感じることはありませんか？そんなときに役立つのがRecord型です。

この記事では、Record型の基本的な使い方、インデックス型との違い、実際の利用シーンを初心者の方にもわかりやすく解説します。

Record型とは？

Record型はTypeScriptに組み込まれているユーティリティ型のひとつです。「キーの型」と「値の型」を指定することで、その条件に合ったオブジェクト型を自動で作ってくれます。

まずは、シンプルなサンプルコードを見てみましょう。

type ScoreBySubject = Record<string, number>;

const scores: ScoreBySubject = {
  math: 90,
  english: 85,
  science: 92,
};

このScoreBySubject型の意味は次のとおりです。

• キー：string型
• 値：number型

つまり、「キーが文字列で、値が数値のオブジェクト」を表す型になります。

Record型の基本構文

Record型は、次のような形で使います。

Record<Keys, Type>

Record型とインデックス型の違い

ここまでを見ると、「Record型はインデックス型とほとんど同じでは？」と感じるかもしれません。実際、先ほど示したサンプルコードはインデックス型でも以下のように書けます。

type ScoreBySubject = {
  [key: string]: number;
};

const scores: ScoreBySubject = {
  math: 90,
  english: 85,
  science: 92,
};

この段階では、Record型とインデックス型に大きな違いはなさそうに見えます。

しかし、Record型とインデックス型の大きな違いがあります。それは、Record型はキーを「特定の文字列（リテラル）」で厳密に指定できる点です。次の例を見てみましょう。

type Person = Record<"familyName" | "givenName" | "nickname", string>;

const person: Person = {
  familyName: "Tanaka",
  givenName: "Taro",
  nickname: "Taro-san",
};

この場合、Person型は次の条件を持ちます。

• 必ずfamilyName、givenName、nicknameという3つのプロパティを持つ。
• 各キーに対応する値はすべてstringである。

つまり、Record型は「決まったキーを必ず持つオブジェクト」を型として表現できます。

インデックス型でこのような定義をしたい場合、以下のようにエラーとなってしまいます。

そのため、インデックス型で書く場合には、次のようになります。

type Person = {
  [key: string]: string;
};

const person: Person = {
  familyName: "Tanaka",
  givenName: "Taro",
  nickname: "Taro-san",
};

この場合、familyName、givenName、nicknameが必須であるという制約は表現できません。

Record型の内部

実は、Record型は内部的にMapped Typesを使って定義されています。

type Record<K extends keyof any, T> = {
  [P in K]: T;
};

このコードの意味を簡単に説明すると、

• Kで受け取ったキーの集合を
• P in Kで1つずつ取り出し
• それぞれにT型の値を割り当てる

という仕組みです。つまり、「指定されたキーをすべて持つオブジェクト型を作る」ための型というわけです。

Record型の使い道

使い道としては、入れ子になったオブジェクトの型を簡潔に書けるというものが挙げられます。例えば、次のような構造を考えてみます。

type Account = {
  email: string;
  isActive: boolean;
};

type Accounts = {
  admin: Account;
  editor: Account;
  viewer: Account;
};

このように同じ型を何度も書くのは、少し冗長です。Record型を使うと、以下のように書くことができます。

type Account = {
  email: string;
  isActive: boolean;
};

type Role = "admin" | "editor" | "viewer";

type Accounts = Record<Role, Account>;

これで、Accounts型は

• "admin" | "editor" | "viewer"のキーを必ず持つ
• 各値はすべてAccount型

というオブジェクト型をシンプルに定義することができます。

本記事のまとめ

この記事では『Record型』について説明しました。

Record型は「キーの型」と「値の型」を指定するだけで、条件に合ったオブジェクト型を簡潔に定義できる便利なユーティリティ型です。

特に、以下のような場合にRecord型は大きな力を発揮します。

• 決まったキーを必ず持つオブジェクトを表現したいとき
• 同じ型の値を持つオブジェクトをシンプルに書きたいとき

ぜひ実際のコードでRecord型を活用してみてください。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

bash: tsc: command not found

tscはTypeScript Compilerの略で、.tsファイルを.jsファイルに変換（コンパイル）するためのコマンドです。そのため、このエラーが出るとTypeScriptを一切コンパイルできず、先に進めなくなります。

この記事では、以下の内容をわかりやすく解説します。

• なぜ「tsc: command not found」が出るのか
• どうすればこのエラーを解決できるのか

「tsc: command not found」が出る原因

このエラーが出る原因は、ほとんどの場合、次のいずれかです。

• TypeScriptがインストールされていない
• TypeScriptは入っているがPATHが通っていない

まずは「TypeScriptがインストールされているか」を確認しましょう。

原因：TypeScriptがインストールされていない

最初に、TypeScriptがグローバルインストールされているかを確認します。以下のコマンドを実行してください。

npm list -g --depth=0

実行結果の一覧に、以下のような表示があればTypeScriptはインストールされています。

$ npm list -g --depth=0
C:\Users\ユーザー名\AppData\Roaming\npm
└── typescript@5.x.x

typescriptが表示されない場合は、まだインストールされていません。その場合は、次のコマンドでTypeScriptをグローバルインストールします。

npm install -g typescript

インストール後、以下のコマンドを実行してみてください。バージョンが表示されれば、インストール自体は成功しています。

tsc -v

原因：TypeScriptは入っているがPATHが通っていない

TypeScriptがグローバルインストールされているにも関わらず、tscコマンドの実行時にcommand not foundが表示される場合には、PATHが通っていない状態です。まず、npmのグローバルインストール先を以下のコマンドで確認します。

npm config get prefix

実行すると、以下のようにグローバルインストール先がわかり、このディレクトリの中にtscコマンドが実体として存在しています。

$ npm config get prefix
C:\Users\ユーザー名\AppData\Roaming\npm

npm bin -g

$ npm bin -g
Unknown command: "bin"

To see a list of supported npm commands, run:
  npm help

TypeScriptをグローバルにインストールしていても、PATHにnpmのグローバルディレクトリが含まれていないとtscは実行できません。PATHを通すために、~/.bashrc（または環境によっては~/.bash_profileや~/.zshrc）に、次の一行を追加してください。

export PATH="$PATH:/c/Users/ユーザー名/AppData/Roaming/npm"

設定を反映するため、以下のコマンドを実行します（.bash_profileに書いた場合はsource ~/.bash_profile）。

source ~/.bashrc

最後に、tscが使えるか確認するため、以下のコマンドを実行してみてください。バージョンが表示されれば、インストール自体は成功しています。

tsc -v

本記事のまとめ

この記事では「tsc: command not found」について説明しました。

「tsc: command not found」は、TypeScriptのインストールやPATH設定が原因で発生することがほとんどです。

• TypeScriptがインストールされているか
• npmのグローバルディレクトリにPATHが通っているか

この2点を確認すれば、多くの場合は解決できます。同じエラーで困っている方の参考になれば幸いです。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

• docker container runしたら、思っていたコマンドと違うものが実行された
• ENTRYPOINTやCMDを一時的に変えて実行したい
• Dockerfileを書き換えずに、起動時の動作だけ変えたい

そんなときに非常に便利なのが、docker container run(docker run)時にENTRYPOINTやCMDを上書きする方法です。

そもそもENTRYPOINTとCMDとは？

ENTRYPOINTとCMDは、コンテナ起動時に実行されるコマンドを決める設定です。ただし、それぞれの役割は明確に分かれています。

ENTRYPOINTは「必ず実行されるメインのコマンド」です。

一方、CMDは、

• ENTRYPOINTが定義されている場合は、ENTRYPOINTに渡されるデフォルト引数（args）
• ENTRYPOINTが定義されていない場合は、コンテナ起動時にデフォルトで実行されるコマンド

という 2つの役割を持つ設定になります。

例えば、Dockerfileが次のように書かれているとします。

ENTRYPOINT ["echo"]
CMD ["Hello, World!"]

この場合、コンテナ起動時に実行される実際のコマンドは以下のようになります。

echo Hello, World!

重要なのは、ENTRYPOINT + CMDが合体して1つのコマンドになるという点です。この前提を理解していないと、docker run時の上書き挙動が分かりにくくなります。

docker runでENTRYPOINTを上書きする方法

ENTRYPOINTを上書きする場合は、「--entrypointオプション」を使います。基本構文を以下に示します。

docker container run --entrypoint <新しいENTRYPOINT> イメージ名

例えば、DockerfileでENTRYPOINTにechoが設定されているイメージを、lsに変えたい場合には、以下のコマンドを実行します。

docker container run --entrypoint ls sample-image

この場合、Dockerfileに設定されていたENTRYPOINT（echo）は無視され、代わりにlsが新しいENTRYPOINTとして使われます。なお、CMDが定義されている場合、CMDは新しいENTRYPOINTの引数（args）として渡されます。結果として実行されるコマンドは、以下のようになります。

ls "Hello, World!"

docker runでCMDを上書きする方法

CMDを上書きする場合は、イメージ名の後ろに「新しいCMD」を指定します。基本構文を以下に示します。

docker container run イメージ名 <新しいCMD配列の1要素目> <新しいCMD配列の2要素目> ...

例えば、DockerfileでCMDに["Hello, World!"]が設定されているイメージを、["Docker is fun!"]に変えたい場合には、以下のコマンドを実行します。

docker container run sample-image "Docker is fun!"

この場合、ENTRYPOINTはDockerfileに書かれているもの（echo）が使われ、CMD だけが["Docker is fun!"]に置き換わります。結果として実行されるコマンドは、以下のようになります。

echo Docker is fun!

docker runでENTRYPOINTとCMDを上書きする方法

ENTRYPOINTとCMDの両方を上書きしたい場合は、「--entrypointオプション」と「新しいCMD」を組み合わせます。基本構文を以下に示します。

docker container run --entrypoint <新しいENTRYPOINT> イメージ名 <新しいCMD配列の1要素目> <新しいCMD配列の2要素目> ...

例えば、ENTRYPOINTをprintf、CMDを["Hello %s\n", "Docker"]にしたい場合には、以下のコマンドを実行します。

docker container run --entrypoint printf sample-image "Hello %s\n" Docker

結果として実行されるコマンドは、以下のようになります。

printf "Hello %s\n" Docker

本記事のまとめ

この記事では『docker container run時にENTRYPOINTとCMDを上書きする方法』について説明しました。

DockerのENTRYPOINTとCMDは、一見すると似ていますが、役割はまったく異なります。

docker container run時の挙動を正しく理解するためには、「ENTRYPOINT + CMDが合体して1つのコマンドになる」という前提を押さえることが非常に重要です。

今回紹介した方法を使うと、docker container runの指定だけでコンテナの動きを変えられます。

• --entrypointを使えばENTRYPOINTを一時的に差し替えられる
• イメージ名の後ろにCMDを指定すればCMDだけを上書きできる

これらを使い分けることで、Dockerfileを修正しなくても、起動時のコマンドを自由に試せるようになります。「ちょっと別のコマンドで動かしてみたいとき」や「本番用イメージをそのまま使って中身を確認したいとき」に、非常に便利なテクニックです。

Copyright © 2026 IT Information All Rights Reserved.

• このDockerイメージはどんな設定で作られているんだろう？
• ENTRYPOINTやCMDには何が設定されている？
• どのポートがEXPOSEされている？
• 環境変数（ENV）は？

そんなときに活躍するのがdocker image inspectコマンドです。

docker image inspectとは？

docker image inspectはDockerイメージの詳細情報（メタデータ）を確認するためのコマンドです。

イメージの中身（ファイル一覧）を見るコマンドではなく、イメージが「どういう設定で作られているか」を確認するためのコマンドになります。

docker image inspectは、次のような場面でよく使われます。

docker image inspectで分かること

docker image inspectを使うと、次のような情報が確認できます。

• イメージID
• 作成日時
• ベースイメージ情報
• レイヤー構成
• 環境変数（ENV）
• 作業ディレクトリ（WORKDIR）
• EXPOSEされているポート
• ENTRYPOINT / CMD
• OS / アーキテクチャ

つまり、「Dockerfileに書かれている内容 + Dockerが内部で管理している情報」をすべて確認できます。

docker image inspectの基本構文

docker image inspectの構文を以下に示します。

docker image inspect [オプション] <イメージ名またはイメージID>

例えば、nginx:latestのDockerイメージの設定を確認する場合、以下のコマンドを実行します。

docker image inspect nginx:latest

docker image inspectを実際に実行してみる

それでは、実際に動かしながらdocker image inspectについて学んでみましょう。ここでは、nginx:latestのDockerイメージの設定を確認するために以下のコマンドを実行します。

# nginx:latestイメージを pull
docker image pull nginx:latest

# nginx:latestイメージの詳細情報を表示
docker image inspect nginx:latest

このコマンドを実行すると、JSON形式で大量の情報が出力されます。

[
    {
        "Id": "sha256:fb01117203ff38c2f9af91db1a7409459182a37c87cced5cb442d1d8fcc66d19",
        "RepoTags": [
            "nginx:latest"
        ],
        "RepoDigests": [
            "nginx@sha256:fb01117203ff38c2f9af91db1a7409459182a37c87cced5cb442d1d8fcc66d19"
        ],
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2025-12-09T22:51:13.902320549Z",
        "Config": {
            "ExposedPorts": {
                "80/tcp": {}
            },
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "NGINX_VERSION=1.29.4",
                "NJS_VERSION=0.9.4",
                "NJS_RELEASE=1~trixie",
                "PKG_RELEASE=1~trixie",
                "DYNPKG_RELEASE=1~trixie"
            ],
            "Entrypoint": [
                "/docker-entrypoint.sh"
            ],
            "Cmd": [
                "nginx",
                "-g",
                "daemon off;"
            ],
            "Labels": {
                "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
            },
            "StopSignal": "SIGQUIT"
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 59795293,
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:77a2b55fbe8b9984ce0af3ffc0b0ab62507668e63306ec161a585e587a3eb164",
                "sha256:20cf308e6957f546aeb5c3358b908dde65f85d4c3e321a1306bfb2a5002b0147",
                "sha256:69f56ce8c461dc57973b448f1a17aacfa5bc674b8e23f709d58b5fd2a7e6e6f8",
                "sha256:6898c33749d555cdd3df4ba0279a08a58e3b8faaa80bcf76ca71f35ed87e5e0b",
                "sha256:6e32bc56a7253358b6292d5b9e9d473397818ccebaec6edd88d20c7ab508fa4e",
                "sha256:08ba9962589fcdea2592d16bf47a4c299711e9e394b90bf11a830f3b9c9fa580",
                "sha256:8921786c2de3800947893b21f0585eeabc26f7f5a486de5d0ee085596d16d0cc"
            ]
        },
        "Metadata": {
            "LastTagTime": "2025-12-22T05:18:20.801350755Z"
        },
        "Descriptor": {
            "mediaType": "application/vnd.oci.image.index.v1+json",
            "digest": "sha256:fb01117203ff38c2f9af91db1a7409459182a37c87cced5cb442d1d8fcc66d19",
            "size": 10229
        }
    }
]

docker image inspectの出力内容

docker image inspectの出力内容において、実務・学習で特によく見る項目を厳選して解説します。

Id（イメージID）

"Id": "sha256:fb01117203ff38c2f9af91db1a7409459182a37c87cced5cb442d1d8fcc66d19",

Dockerイメージを一意に識別するIDです。同じビルド成果物であればタグ（nginx:latestなど）が変わってもIDは固定ですが、タグが別のイメージを指すようになるとIDは変わります。

Created（作成日時）

"Created": "2025-12-09T22:51:13.902320549Z",

イメージが作成された日時です。「古いイメージを使っていないか？」の確認にも使えます。

Config.Env（環境変数）

"Env": [
    "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
    "NGINX_VERSION=1.29.4",
    "NJS_VERSION=0.9.4",
    "NJS_RELEASE=1~trixie",
    "PKG_RELEASE=1~trixie",
    "DYNPKG_RELEASE=1~trixie"
],

DockerfileのENV命令で設定された環境変数です。この環境変数は、コンテナ起動時にそのまま利用されます。上記の出力結果から、Nginxのバージョンが1.29.4に設定されていることや、実行時のPATHが確認できます。

Config.ExposedPorts（公開ポート）

"ExposedPorts": {
    "80/tcp": {}
},

DockerfileのEXPOSEに対応します。この項目は、「イメージがデフォルトで開放しているポート」を示します。nginxイメージでは、HTTP用の80番ポートが指定されています。なお、EXPOSEは「公開する予定のポート」を示すだけで、実際に公開されるかどうかは-pオプション次第です。

Config.Cmd / Config.Entrypoint

"Entrypoint": [
    "/docker-entrypoint.sh"
],
"Cmd": [
    "nginx",
    "-g",
    "daemon off;"
],

• CMD：デフォルトで実行されるコマンド
• ENTRYPOINT：常に実行されるメインコマンド

ENTRYPOINTとCMDは組み合わさって実行されることが多く、nginxイメージでは/docker-entrypoint.sh nginx -g "daemon off;"のような形で最終的なコマンドが構成されます。

特定の項目だけを確認する（–format）

docker image inspectは、そのまま実行すると大量の情報が表示されます。必要な情報だけを絞り込んで取得・表示するためには、--formatオプションを使います。

CMDだけ確認する

$ docker image inspect --format '{{.Config.Cmd}}' nginx:latest
[nginx -g daemon off;]

ENTRYPOINTだけ確認する

$ docker image inspect --format '{{.Config.Entrypoint}}' nginx:latest
[/docker-entrypoint.sh]

環境変数だけ確認する

$ docker image inspect --format '{{.Config.Env}}' nginx:latest
[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin NGINX_VERSION=1.29.4 NJS_VERSION=0.9.4 NJS_RELEASE=1~trixie PKG_RELEASE=1~trixie DYNPKG_RELEASE=1~trixie]

イメージIDだけ確認する

$ docker image inspect --format='{{.Id}}' nginx:latest
sha256:fb01117203ff38c2f9af91db1a7409459182a37c87cced5cb442d1d8fcc66d19

本記事のまとめ

この記事ではdocker image inspectコマンドについて説明しました。

docker image inspectは、Dockerイメージがどのような設定で作られているかを確認するための基本かつ重要なコマンドです。ENTRYPOINT・CMD・環境変数・EXPOSEポートなどを事前に把握しておくことで、コンテナ起動時の挙動を正しく理解できます。

Dockerイメージの中身を理解する第一歩として、ぜひ活用してみてください。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.

この記事では、docker container execについて、以下の内容をわかりやすく解説します。

• docker container execとは？
• docker container execの構文
• docker container execの動作を確認する

docker container execとは？

docker container execはすでに起動している（UP状態の）コンテナに対して、新しくコマンドを実行するためのコマンドです。

docker container execには、次のような特徴があります。

• 対象は「起動中（UP）」のコンテナのみ
• コンテナを停止・再起動しない
• コマンドを一時的に実行できる
• bashなどのシェルを起動して中に入ることもできる

docker container execの構文

docker container execの構文を以下に示します。

docker container exec [オプション] <コンテナ名またはコンテナID> <実行したいコマンド>

例えば、my-ubuntuという起動中のコンテナに対してlsコマンドを実行する場合は、次のように書きます。

docker container exec my-ubuntu ls

これは、「起動中のmy-ubuntuコンテナに対して、外部（ホスト側）からlsコマンドを実行する」という意味になります。

bashを起動して、コンテナの中に入る場合は、次のように書きます。

docker container exec -it my-ubuntu bash

このコマンドを実行すると、起動中のmy-ubuntuコンテナに後から入ることができます。

docker container execの動作を確認する

次の流れでdocker container execの動きを確認します。

Ubuntuコンテナを起動

まずは、事前準備としてUbuntuコンテナを起動します。

docker container run -it --name my-ubuntu ubuntu:latest

• docker container run
  • 新しいコンテナを作成して起動
• -i
  • 標準入力を有効化（コンテナに入力できるようにする）
• -t
  • 疑似TTYを割り当て（ターミナル操作用）
• --name my-ubuntu
  • コンテナ名をmy-ubuntuに指定
• ubuntu:latest
  • Ubuntuの公式イメージ

実行すると、次のような表示になります。

root@xxxxxxxxxxxx:/#

これはUbuntuコンテナの中に入った状態です。このとき、bashが動いており、コンテナはUP状態になっています（bashプロセスが終了しないため、コンテナも起動し続けます）。

別ターミナルでdocker container lsコマンドを実行すると、以下のようにコンテナがUp状態になっていることが確認できます。

$ docker container ls
CONTAINER ID   IMAGE           COMMAND       CREATED          STATUS          PORTS     NAMES
xxxxxxxxxxxx   ubuntu:latest   "/bin/bash"   23 seconds ago   Up 22 seconds             my-ubuntu

コンテナ内でsample.txtを作成

起動したUbuntuコンテナ内で、echoを使ってsample.txtを作成します。

echo "Hello Docker Exec" > sample.txt

sample.txtが作成できているかlsコマンドで確認してみましょう。

root@xxxxxxxxxxxx:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sample.txt  sbin  srv  sys  tmp  usr  var

sample.txtが作成されていることが確認できます。

別ターミナルからdocker container execを実行

新しく別のターミナルを開き、次のコマンドを実行します。

docker container exec my-ubuntu ls

実行結果は以下のようになります。

$ docker container exec my-ubuntu ls
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sample.txt
sbin
srv
sys
tmp
usr
var

先ほど作成したsample.txtがありますね。これは、「起動中のmy-ubuntuコンテナに対して外部（ホスト側・別ターミナル）からlsコマンドを実行している」という状態です。つまり、コンテナの中に入らずに、外からコンテナの中のコマンドを実行することができました。

本記事のまとめ

この記事ではdocker container execコマンドについて説明しました。

docker container execは、起動中（UP状態）のコンテナに対して、後からコマンドを実行できる便利なコマンドです。

Dockerを使いこなすうえで欠かせない基本コマンドなので、ぜひ実際に手を動かしながら慣れていきましょう。

お読みいただきありがとうございました。

Copyright © 2026 IT Information All Rights Reserved.