開発現場での環境構築やトラブルシューティング中に、「このコマンドのオプションはハイフンが1つだったか、2つだったか」と迷った経験はないでしょうか。複数プロジェクトを掛け持つフリーランスエンジニアにとって、言語やツールごとのコマンド仕様の微妙な差異に毎回時間を取られるのは大きなロスです。

本記事では、Node.js・Java・Gitをはじめとする実務頻出の主要言語・パッケージマネージャー・インフラツールのバージョン確認コマンドを、Mac・Windows両対応のチートシート形式で体系的に整理します。ぜひ、日々の開発業務でいつでも引き返せるリファレンスとして活用してください。

目次

【基本】Node.js・Python・Javaのバージョン確認コマンド

実務の大半を占める3言語のバージョン確認は、言語ごとにオプションの記法が異なるため、まず基本パターンを押さえておくことが重要です。

Node.jsのバージョン確認方法と環境管理ツールのコマンド

Node.jsのバージョン確認には node -v または node --version を使用します。実行すると v22.0.0 のように、先頭に「v」が付いた形式でランタイムのバージョンが表示されます。

実務ではプロジェクトごとにNode.jsのバージョンを切り替えるケースが多いため、バージョン管理ツール自体のコマンドも把握しておく必要があります。

ツール名 確認コマンド 特徴
nvm(Node Version Manager) nvm --version シェルスクリプトベースの定番ツール
fnm(Fast Node Manager) fnm --version Rust製で動作が高速
Volta volta --version プロジェクト単位のツールチェーン管理に強み

Node.js・Python・Javaのバージョン確認コマンドと出力形式の比較図

Pythonのバージョン確認方法と注意すべきコマンドの違い

Pythonのバージョン確認には python --version または python -V(大文字のV)を使用します。ただし、MacやLinux環境では Python 2系と3系が混在しているケースがあり、python コマンドが2系を指している場合があります。意図したバージョン(3.x系)が表示されない場合は、python3 --version を試してください。

確認コマンド 対象 出力例
python --version デフォルトのPython Python 3.12.1 または Python 2.7.x
python3 --version 3系を明示的に指定 Python 3.12.1
python -V 大文字Vでも同じ動作 Python 3.12.1

Java(JDK)のバージョン確認コマンドと出力の読み解き方

Javaのバージョン確認は java -version(ハイフン1つ)を使用します。Java 9以降では java --version もサポートされていますが、古いバージョンを含む環境では -version が安全です。

Javaの出力はほかの言語と比べて情報量が多く、JREのバージョンだけでなく、HotSpot VMのビルド情報やOpenJDK・Amazon Correttoなどのベンダー情報も複数行にわたって表示されます。現場でベンダー指定がある場合は、出力の文字列全体を確認しましょう。

【フロントエンド】主要フレームワーク・関連ツールのバージョン確認コマンド

フロントエンド開発では、コンパイラやフレームワークのCLIツールのバージョンがビルドの成否に直結するため、プロジェクトローカルと グローバルの区別を意識した確認が必要です。

TypeScriptとJavaScript関連ツールのバージョン確認

TypeScriptのコンパイラバージョンを確認するには tsc -v または tsc --version を使用します。ただし、単に tsc -v と実行するとグローバルインストール版が参照される点に注意が必要です。プロジェクトの devDependencies に含まれるローカル版のバージョンを確認したい場合は、npx tsc -v のようにパッケージ実行ツール経由で実行してください。

ツール 確認コマンド 注意点
TypeScript npx tsc -v ローカル版を確認する際は npx を付与
Babel npx babel --version グローバルインストールがない場合は npx 経由
Vite npx vite --version プロジェクトルートで実行
Webpack npx webpack --version プロジェクトルートで実行

Next.js・Vue CLI・Angular CLIのバージョン確認

各Webフレームワークのバージョン確認方法はツールごとに異なります。Vue CLIは vue --version または vue -V で確認できます。一方、Next.jsやNuxtには単体のバージョン確認コマンドが用意されていないため、プロジェクトルートで npx next --version を実行するか、package.json の記述を直接確認するのが確実です。

フレームワーク 確認コマンド 補足
Vue CLI vue --version vue -V でも同様
Next.js npx next --version プロジェクトルートで実行
Nuxt npx nuxi --version Nuxt 3系はnuxi経由
Angular CLI ng version ハイフンなし。依存関係も一覧表示

【バックエンド】Java以外の主要プログラミング言語のバージョン確認コマンド

バックエンド領域で採用される各言語は、コマンドの設計思想がそれぞれ異なるため、特にGoとRustはほかの言語の感覚で入力するとエラーになる点に注意が必要です。

PHPおよびRubyのバージョン確認コマンド

PHPのバージョン確認には php -v または php --version を使用します。実行するとPHP本体のバージョンに加えて、CLIのビルド環境情報やZend Engineのバージョンが複数行で出力されます。Rubyは ruby -v または ruby --version で確認でき、バージョン番号・コンパイル先プラットフォーム・リリース日が1行にまとめて表示されます。

言語 確認コマンド 出力の特徴
PHP php -v Zend Engineの情報が複数行で出力
Ruby ruby -v プラットフォーム情報・日付が1行に集約

GoおよびRustのバージョン確認コマンド

Go言語のバージョン確認は go version と入力します。ハイフンは一切付けませんgo -v と入力するとverboseオプションとして誤認されエラーになるか、意図しない挙動を示すため注意が必要です。

RustはコンパイラへのオプションとしてGNUスタイルを採用しており、rustc --version または rustc -V(大文字)で確認します。Rustはリリースサイクルが非常に早いため、コンパイラだけでなくビルドシステム兼パッケージマネージャーのCargoも cargo --version で同時に確認し、バージョンが一致しているかを確かめるのが一般的です。

Go言語(ハイフンなし)とRust(ハイフンあり)のコマンド文法の違いを示す対比図

言語 確認コマンド 特記事項 出力例
PHP php -v php --version も共通 PHP 8.3.2 (cli) ...
Ruby ruby -v プラットフォーム情報も1行に表示 ruby 3.3.0 (2023-12-25 ...) [x86_64-linux]
Go go version ハイフンは不要。go -v は不可 go version go1.22.0 darwin/arm64
Rust rustc --version rustc -V も可。cargo --version も併用 rustc 1.76.0 (25ef9e3d8 2024-01-28)

【パッケージ管理】npmやpipなど主要マネージャーのバージョン確認コマンド

パッケージマネージャー自体のバージョンが古いと最新ライブラリのインストールに失敗する場合があります。特に複数人開発では、ロックファイルの生成規則に影響するため、チーム間でのバージョン統一が求められます。

npm・yarn・pnpmのバージョン確認コマンド

Node.jsエコシステムの主要パッケージマネージャーはいずれも -v または --version で確認できます。pnpmとは、シンボリックリンクを活用してディスク容量を節約しつつ高速に動作するNode.js用のパッケージマネージャーです。

マネージャー 確認コマンド 出力例
npm npm -v 10.5.0
yarn yarn -v 1.22.21
pnpm pnpm -v 8.15.4

pip・gem・cargoのバージョン確認コマンド

Pythonのライブラリ管理ツールpipは pip --version または pip -V で確認します。Python環境が競合している場合は pip3 --version と明示的に指定が必要なケースがあります。RubyGemsは gem -v、RustのCargoは cargo --version で確認します。

macOS(Homebrew)・Linux(APT)のパッケージ管理コマンド

macOSで必須となるHomebrewは brew --version または brew version で確認できます。DebianやUbuntuなどのLinux環境では apt --version または apt-get --version を使用します。

マネージャー 確認コマンド 対応環境・言語 出力例
pip pip --version Python pip 24.0 from ...
gem gem -v Ruby 3.5.6
cargo cargo --version Rust cargo 1.76.0 (...)
Homebrew brew --version macOS / Linux Homebrew 4.2.9
APT apt --version Debian / Ubuntu apt 2.7.14 ...

【インフラ・DevOps】GitやDockerなど開発ツールのバージョン確認コマンド

CI/CDやInfrastructure as Code(IaC)を支えるツールのバージョン不一致は、デプロイエラーや環境差異の原因になります。作業前の確認を習慣化しておきましょう。

Gitのバージョン確認コマンドと環境ごとの違い

Gitのバージョン確認は必ずハイフンを2つ付けた git --version を使用します。git -v(ハイフン1つ)は環境によっては無効なオプションになるため、混同に注意してください。

特にmacOS環境では、OSアップデート時に自動挿入されるApple固有のGit(出力に Apple Git と表示)と、Homebrewで導入した本家コミュニティ版のGitが共存していることがあります。動作に微妙な差異が生じる場合があるため、出力の文字列末尾まで確認する習慣が有効です。

DockerおよびDocker Composeのバージョン確認コマンド

Dockerのバージョン確認には docker --version を使用します。EngineのAPIバージョンやGoのコンパイルバージョンを含む詳細情報を取得したい場合は、ハイフンを取り除いた docker version を実行します。

Docker Composeは利用している世代によってコマンド構造が完全に異なります。現在の標準であるV2はDockerのサブコマンドとして統合されており、docker compose version(スペース区切り・ハイフンなし)を使用します。過去のV1は独立したバイナリとして docker-compose --version(ハイフン連結)というスタンドアロン形式でした。既存プロジェクトの保守対応時には、この記述方式の差に注意してください。

Docker Compose V1(スタンドアロン)とV2(サブコマンド統合)のコマンド構造と呼び出しプロセスの変化

AWS CLI・Terraformのバージョン確認コマンド

AWS CLIは aws --version を使用します。出力にはAWS CLI本体のバージョンに加えて、内部ランタイムのPythonバージョンやホストOSのカーネル情報も含まれます。

TerraformはIaCツールの中でもメジャー・マイナーバージョン間のコード互換性が特に厳しく、意図しないバージョンで apply を実行するとインフラ構成を壊すリスクがあります。terraform --version または terraform -v で作業前に必ず確認する運用を徹底してください。

ツール 標準確認コマンド 詳細・代替コマンド 注意点
Git git --version git -v は非推奨。macOSはApple Git混在に注意
Docker docker --version docker version サブコマンド形式でサーバー・クライアント詳細が出力
Docker Compose docker compose version docker-compose --version(V1) V2はスペース区切り、V1はハイフン連結
AWS CLI aws --version 内部PythonおよびOS情報が1行で出力
Terraform terraform --version terraform -v バージョン不一致が構文エラーに直結するため作業前に必須

【トラブルシューティング】バージョン確認コマンドが正常に動作しない場合の対処法

コマンドを実行してもエラーが返る、または古いバージョンが表示されるといった問題の原因は、ほぼ確実に環境変数(PATH)の設定か、バイナリの配置パスの不整合にあります。

「command not found」エラーの解決策

command not found(Mac/Linux)や「〜は内部コマンドまたは外部コマンドとして認識されていません」(Windows)というエラーは、シェルが実行ファイルを見つけられていない状態です。ツールが未インストールであるか、インストール後にターミナルを再起動していないことが原因のほとんどです。一度シェルセッションを完全に閉じ、新しいウィンドウで再実行してください。

環境変数PATHの設定確認方法

ツールがインストール済みにもかかわらず認識されない場合は、実行ファイルが存在するディレクトリへのパスがPATHに登録されていない可能性があります。

Windowsでは「システム環境変数の編集」から Path 変数を開き、対象ツールの bin ディレクトリのパスが正しく追加されているかを確認します。Macのzshはホームディレクトリにある .zshrc または .zprofile を開き、以下のように記述されているかを確認してください。

export PATH="/usr/local/opt/YOUR_TOOL/bin:$PATH"

設定ファイルを変更した後は、source ~/.zshrc を実行して変更内容を現在のセッションに即時反映させてください。

OSが環境変数PATHを上から順に走査し、最初に見つかったバイナリを実行またはエラーを返すプロセスフロー

古いバージョンが表示される場合の優先順位の確認

「インストールしたはずなのに古いバージョンが表示される」という現象は、同一ツールのバイナリが複数のディレクトリに存在し、PATH内で先に記述されているディレクトリの古いバイナリが優先的に呼ばれていることが原因です。

現在実行されているバイナリの実体パスを確認するには、以下のコマンドを使用します。

OS コマンド 使用例
Mac / Linux which <コマンド名> which node
Windows(コマンドプロンプト) where <コマンド名> where node

返ってきたパスを確認し、不要な古いバイナリを削除するか、環境変数の記述順序を変更して最新版のパスが先頭に来るよう調整すると、意図したバージョンが正しく呼び出されます。

エラー・現象 根本的な原因 調査・確認方法 解決アクション
command not found 未インストール、またはPATH未設定 echo $PATH で有効パスを確認 再インストール、またはbinパスをPATHに追加
古いバージョンが出る 複数バイナリの優先順位エラー Mac: which / Win: where で実体パスを特定 環境変数の記述順序を変更し、最新版パスを上位に移動
設定が反映されない 設定ファイルの未読み込み 設定ファイルの記述を目視確認 source ~/.zshrc を実行またはターミナルを再起動

まとめ:バージョン確認コマンドを「引ける状態」に保つ

本記事では、Node.js・Python・Javaの基本言語から、フロントエンド・バックエンドの各フレームワーク、パッケージマネージャー、GitやDockerなどのインフラツールまで、実務で頻出するバージョン確認コマンドを体系的に整理しました。ハイフンの個数・サブコマンドの有無・ローカルとグローバルの違いなど、細かな差異こそが現場でのつまずきポイントです。本記事をブックマークしておき、環境切り替えや不具合の切り分けの際に随時参照してみてください。

複数のプロジェクトを横断しながらこうした技術的な正確さを発揮できるスキルは、多様な現場に参画するフリーランスエンジニアにとって直接的な市場価値につながります。自身のスキルをより条件の良い案件で活かしたい方は、ぜひテクフリで案件を探してみてください。

テクフリでフリーランス案件を探してみる

Q. node -v と node –version で出力結果に違いはありますか?

A. 違いはありません。-v と –version はNode.jsのCLI内部で同一の処理へルーティングされるエイリアスとして定義されているため、どちらを実行しても同じバージョン番号が返されます。書きやすい方を使って問題ありません。

Q. Windows環境で python –version を実行してもエラーになるのはなぜですか?

A. インストール時に「Add python.exe to PATH」オプションを有効にしていないことが原因です。PythonのWindowsインストーラーは初期設定でこのオプションが無効になっているため、インストーラーを再実行してチェックを入れるか、手動でシステム環境変数にPythonのパスを追加してください。

Q. java -version と java –version はどう使い分ければよいですか?

A. レガシーなシステムや古いJDKが含まれる環境では、ハイフン1つの java -version が確実です。–version(ハイフン2つ)はJava 9以降でサポートされた形式であり、それ以前のバージョンでは認識されません。バージョン混在環境では前者を使うことで環境を選ばず動作します。

Q. docker compose version でエラーが返される場合、何を確認すべきですか?

A. 導入されているDocker ComposeがV1かV2かを確認してください。現在の標準であるV2はDockerのサブコマンドとしてスペース区切り(docker compose version)で動作しますが、旧来のV1は独立したバイナリとしてハイフン連結(docker-compose –version)の形式でした。既存の古いプロジェクトではV1が残っているケースがあります。

Q. バージョン確認コマンドのオプションを忘れた場合の調べ方はありますか?

A. ほぼすべてのCLIツールで –help または -h を付けて実行するとヘルプ画面が表示されます。ヘルプにはバージョン確認用のフラグ(-V や version など)が明記されているため、そこから正確なオプションを確認できます。


今すぐシェアしよう!
今すぐシェアしよう!