こんにちは、かつコーチです。
「command not foundって出たけど、インストールしたはずなのに」。
「新しいターミナルを開いたら、さっき設定したコマンドが使えなくなった」。
こうしたトラブルの多くは、環境変数とPATHの仕組みを理解していないことが原因です。
この記事では、なぜコマンドが実行できたりできなかったりするのか、その裏側の仕組みを整理します。
検証環境はUbuntu 26.04 LTSです。
環境変数とは？
環境変数の定義
環境変数とは、OSやシェルが持っている「設定値」を、キーと値のペアで保存している仕組みのことです。
たとえばログイン中のユーザー名や、ホームディレクトリの場所、使用する言語設定などが環境変数として保持されています。
$ echo $HOME
/home/user
$ echo $USER
user
$ echo $LANG
ja_JP.UTF-8
$を付けて変数名を指定すると、値を参照できます。
なぜ環境変数の理解が必要なのか
環境変数は、プログラムやコマンドの動作を左右する重要な仕組みです。
たとえばアプリケーションのデータベース接続先やAPIキーを環境変数として渡す設計は、Web開発の現場で非常によく使われます。
環境変数の仕組みを理解していないと、次のような場面で原因が分からず立ち往生します。
- 別のユーザーやシェルに切り替えた途端、コマンドが使えなくなる
- サーバーを再起動したら設定した変数が消えている
- アプリケーションが「設定ファイルが見つからない」というエラーを出す
PATHの仕組み
PATHとは何か
数ある環境変数の中でも、とくに重要なのがPATHです。
PATHとは、コマンドを実行したときに、OSがそのコマンドの実行ファイルをどのディレクトリから探すか、その検索対象を並べたリストです。
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
:（コロン）区切りで複数のディレクトリが並んでいます。
なぜコマンドがどこからでも実行できるのか
L05で紹介したlsやcdのようなコマンドは、実は/bin/lsのように、決まった場所に置かれた実行ファイルです。
$ which ls
/usr/bin/ls
ターミナルでlsとだけ入力してEnterキーを押すと、シェルはPATHに登録されたディレクトリを先頭から順番に探し、最初に見つかったlsという名前のファイルを実行します。
もしPATHに/usr/binが登録されていなければ、lsと入力しても次のようにエラーになります。
$ ls
bash: ls: command not found
これが、独自にインストールしたソフトを実行しようとしたときにcommand not foundが起きる典型的な原因です。
環境変数の設定方法
手順1：一時的に設定する（現在のセッションのみ）
# 現在のターミナルだけで有効な環境変数を設定
$ export MY_APP_ENV=production
$ echo $MY_APP_ENV
production
exportコマンドで設定した環境変数は、そのターミナルを閉じると消えてしまいます。
一時的な検証や、動作確認をしたいときに使う方法です。
手順2：ユーザー単位で永続化する
ログインするたびに自動で設定したい場合は、シェルの設定ファイルに記述します。
# ~/.bashrcの末尾に追記
$ echo 'export MY_APP_ENV=production' >> ~/.bashrc
$ source ~/.bashrc
sourceコマンドは、設定ファイルの内容を今開いているシェルに即座に反映させるためのコマンドです。
新しいターミナルを開けば、sourceしなくても自動的に読み込まれます。
手順3：PATHに新しいディレクトリを追加する
自分でインストールしたソフトを、パスを指定せずどこからでも実行したい場合は、そのディレクトリをPATHに追加します。
# ~/.bashrcの末尾に追記
$ echo 'export PATH="$HOME/myapp/bin:$PATH"' >> ~/.bashrc
$ source ~/.bashrc
$ echo $PATH
/home/user/myapp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$PATHを式の末尾に含めることで、「既存のPATHを保持したまま、新しいディレクトリを先頭に追加する」形になります。
これを忘れてexport PATH="$HOME/myapp/bin"のように上書きしてしまうと、既存のコマンドがすべて使えなくなるため注意してください。
つまずきやすい設定・注意点
bashとzshで読み込む設定ファイルが違う
Ubuntu標準のシェルはbashですが、macOSなどではzshが標準になっています。
| シェル | ログイン時に読み込む設定ファイル |
|---|---|
| bash | ~/.bashrc（対話シェル用）、~/.profile（ログインシェル用） |
| zsh | ~/.zshrc |
使っているシェルに合わせたファイルに設定を書かないと、環境変数が反映されません。
# 現在使っているシェルを確認する
$ echo $SHELL
/bin/bash
よくあるつまずきポイント・エラー対処
インストールしたのにcommand not foundになる
私が実際にNode.jsのバージョン管理ツール（nvm）をインストールした直後、次のエラーに遭遇しました。
❌ Before
$ nvm install 20
bash: nvm: command not found
インストールスクリプトは実行済みで、ファイル自体は~/.nvmディレクトリに存在していました。
原因は、インストール直後のターミナルにはPATHの変更がまだ反映されておらず、シェルがnvmコマンドの場所を認識できていなかったことでした。
✅ After
# 設定ファイルを再読み込みして反映させる
$ source ~/.bashrc
$ nvm install 20
Now using node v20.11.0
インストーラーが自動で~/.bashrcに設定を追記してくれていましたが、それを現在のシェルに反映するsourceを実行していなかったのが原因でした。
インストール直後は「新しいターミナルを開くか、sourceで設定ファイルを再読み込みする」ことを習慣にしています。
sudoを付けるとコマンドが見つからなくなる
一般ユーザーでは動くのに、sudoを付けると急にコマンドが見つからなくなったこともあります。
❌ Before
$ myapp --version
myapp version 1.2.0
$ sudo myapp --version
sudo: myapp: command not found
原因は、sudoが実行するコマンドは、rootユーザー用のsecure_pathという別のPATH設定を参照する仕組みになっているためでした。
~/.bashrcに追加した個人的なPATH設定は、sudo実行時には引き継がれません。
✅ After
# フルパスを指定して実行する
$ sudo /home/user/myapp/bin/myapp --version
myapp version 1.2.0
# もしくはvisudoでsecure_pathに追加する（管理者権限が必要な操作のため慎重に行う）
$ sudo visudo
sudoとPATHの関係は初心者がつまずきやすいポイントなので、フルパスを指定して実行する方法を覚えておくと安全に回避できます。
応用・一歩先の使い方
環境ごとに変数を切り替える
開発環境と本番環境で異なる設定値（データベースの接続先など）を使いたい場合、.envファイルと組み合わせる方法がよく使われます。
# .env（開発環境用）
DATABASE_URL=postgres://localhost:5432/dev_db
# .env.production（本番環境用）
DATABASE_URL=postgres://db.example.com:5432/prod_db
アプリケーション側で読み込む.envファイルを切り替えることで、コードを変更せずに環境ごとの設定を管理できます。
環境変数を安全に扱う
APIキーやパスワードのような機密情報を環境変数として扱う場合、~/.bashrcのような誰でも読めるファイルに直接書き込むのは避けるべきです。
.envファイルをGit管理から除外する、パーミッションを絞る、といった対策を組み合わせて運用してください。
# .envファイルのパーミッションを本人だけに絞る
$ chmod 600 .env
まとめ
この記事のポイント
- 環境変数はOSやシェルが保持する設定値のキーと値のペア
- PATHはコマンドの実行ファイルを探すディレクトリのリスト
- 一時的な設定は
export、永続化は~/.bashrcなどへの追記で行う sourceを実行し忘れると、設定を追記しても現在のシェルには反映されないsudo実行時は個人のPATH設定が引き継がれないことがある
次に読むべき記事
- L05「基本コマンド一覧（ls・cd・pwd・mkdir）」でコマンドの基礎をおさらいする
- L14「sudoの仕組みと安全な使い方」で権限とPATHの関係をさらに理解する
- L25「Linuxサーバー運用者から見たmacOS・Windowsとの違い比較検証」でOSごとの設定の違いを確認する