前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。
ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。
この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。
各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。
検証環境
Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）
確認日：2026年7月28日バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。
コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。
使う予定のツールと同じ OS 側にファイルを置く。
Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。
具体的には、プロジェクトは次の場所に置きます。
\\wsl$\Ubuntu\home\<ユーザー名>\Project（Linux 側 = ~/Project）C:\Users\<ユーザー名>\Project（= WSL から見た /mnt/c/Users/...）/mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。
Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。
ディストリビューションの優先パッケージ マネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。
Windows では、Linux ディストリビューションの更新やアップグレードは自動的に行われません。
sudo apt update && sudo apt upgradeapt update はパッケージ一覧の更新、apt upgrade は実際のアップグレードです。WSL は勝手にアップデートしてくれないので、これは月イチくらいで習慣にしておくのがおすすめです。
続いて、この記事の後半で必要になるツールをまとめて入れておきます。
sudo apt install -y \
build-essential \
curl \
wget \
unzip \
ca-certificates \
gnupg \
software-properties-commonそれぞれの役割は以下の通りです。
add-apt-repository コマンドを提供。Git の PPA 追加で使用HashiCorp の公式チュートリアルも、Terraform を入れる前段としてこう書いています。
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common出典：
まず理解しておきたい前提。Microsoft の公式ドキュメントはこう書いています。
Git を使用する予定の各ファイル システムに Git をインストールする必要があります。
WSL は Windows とは別のファイルシステムを持っています。つまり Windows 側の Git と WSL 側の Git は完全に別物で、バージョンも設定ファイルも別々です。この記事では WSL 側を入れますが、Windows 側にも Git for Windows を入れておくことが推奨されています（理由は後述の Credential Manager のところで説明します）。
Ubuntu にはたいてい Git が最初から入っていますが、バージョンが古いことが多いです。Git 公式サイトは、Ubuntu/Debian で最新の安定版を入れる方法として PPA を案内しています。
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install gitppa:git-core/ppa は Git のメンテナが管理している公式の PPA で、Ubuntu 標準リポジトリより新しいバージョンが提供されます。
バージョンにこだわらないなら、標準リポジトリからでも構いません。
sudo apt install git確認：
git --versionコミットに刻まれる名前とメールアドレスを設定します。
git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"設定ファイルを直接編集したいときは nano ~/.gitconfig で開けます。
ここが WSL ならではの便利ポイントです。
Git Credential Manager（GCM） は .NET 製の資格情報ヘルパーで、GitHub・Azure DevOps・Bitbucket の多要素認証に対応しています。認証トークンを Windows 資格情報マネージャーに安全に保存してくれるので、一度認証すれば以降は再認証なしで push / pull できます。
WSL で使うには Windows 10 バージョン 1903 以降が必要です（GCM が WSL 側の Git と連携するために wsl.exe を使うため）。
推奨されるのは、Windows 側に Git for Windows を入れる方法です。GCM は Git for Windows に同梱されているため、インストール時に「GCM を既定の資格情報ヘルパーにする」を選ぶだけで済みます。
Git for Windows を入れたら、WSL 側で GCM が見えているか確認します。
git-credential-manager.exe --version2.7.3+5fa7116896c82164996a609accd1c5ad90fe730aこのようにバージョンが返ってくればOKです。
⚠️ ここは Microsoft 公式ドキュメントの記述にひとつ罠があります。
公式には確認コマンドとしてgit --version; git credential-manager --versionと書かれていますが、WSL 側でこれを実行すると失敗します。$ git --version; git credential-manager --version git version 2.54.0 git: 'credential-manager' is not a git command. See 'git --help'.
git credential-managerという書き方は、Git が「git-credential-managerという名前の実行ファイル」を PATH から探す仕組みです。しかし WSL から見える実体はgit-credential-manager.exeで、Linux 版の Git は拡張子.exeを補完しません。そのため見つけられずにエラーになります。GCM が入っていないわけではないので、慌てなくて大丈夫です。上記のように
.exeを明示して実行すれば確認できます。ファイルの存在を直接見てもOKです。ls -l "/mnt/c/Program Files/Git/mingw64/bin/git-credential-manager.exe"
続いて、WSL 側の Git に「認証は GCM に任せる」と設定します（GCM 公式リポジトリの手順）。
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"パス中の空白を \ でエスケープしている点に注意してください。設定されたか確認するには次のコマンドを実行します。
git config --global credential.helperこれで、WSL 内で実行する git 操作はすべて GCM 経由になります。Windows 側でキャッシュ済みの資格情報があればそれが使われ、まだなければ、Linux コンソールで作業していても Windows のダイアログが出てきて認証を求められます。
Azure DevOps / Azure Repos を使う場合は、追加でこの設定が必要です。
git config --global credential.https://dev.azure.com.useHttpPath true注意点が2つあります。
%UserProfile%\.gitconfig です。プロキシ設定などは Windows 側と WSL 側（\\wsl$\distro\home\$USER\.gitconfig）の両方に書く必要があります。なお、Git for Windows を入れずに WSL 側だけで完結させることも可能ですが、その場合 GCM は Linux アプリとして動くため、Windows の認証・資格情報ストレージ機能は使えません。手順はGCM 公式ドキュメントの該当セクションにあります。
Windows と Linux で同じリポジトリを触ると、Git が「大量のファイルが変更された」と報告してくることがあります。中身は同じで、改行コードだけが違うという状態です。
対策は次のどちらかです。
.gitattributes を置いて改行コードを明示する（推奨）詳しい対処は VS Code のトラブルシューティングドキュメントにまとまっています。
プロジェクトには .gitignore を置きましょう。GitHub が用途別のテンプレート集を公開しているので、そこからコピーするのが早いです。
出典：
Node.js は apt install nodejs でも入りますが、Ubuntu の標準リポジトリのバージョンはかなり古く、しかもプロジェクトごとにバージョンを切り替えられません。nvm（Node Version Manager） を使えば、複数バージョンの Node.js を共存させてコマンド一発で切り替えられます。
nvm 公式リポジトリが案内しているインストールコマンドです（執筆時点の最新は v0.40.6）。
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bashwget 派の人はこちら。
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash⚠️ URL にバージョン番号（
v0.40.6）が直接埋め込まれている点に注意してください。この記事を読んでいる時点でより新しいバージョンが出ている可能性があります。実行前に nvm-sh/nvm の Releases で最新タグを確認して、URL のバージョン部分を置き換えるのが確実です。
スクリプトは ~/.bashrc に以下を自動で追記します（うまく入らなかった場合は手動で追記してください）。
export NVM_DIR="$( [ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"追記後、ターミナルを一度閉じて開き直します（または source ~/.bashrc）。
command -v nvmnvm と表示されれば成功です。
⚠️
which nvmでは確認できません。 nvm は実行ファイルではなくシェル関数として読み込まれるためです。ここは公式 README がわざわざ注意書きしているポイントで、「インストールしたのにwhichで出てこない」と焦る人が多い箇所です。
nvm install --lts # 最新のLTSを入れる（本番用途はこれ）
nvm install 24 # メジャーバージョンを指定して入れる
nvm use 24 # 使うバージョンを切り替える
node -v # 確認2026年7月現在の Node.js のリリース状況はこうなっています。
迷ったら nvm install --lts で Active LTS を入れておけば間違いありません。
💡 プロジェクトのルートに
.nvmrcというファイルを作ってバージョン（例：24）を書いておくと、そのディレクトリでnvm useするだけで切り替わります。チーム開発では地味に効きます。出典：
pnpm は npm 互換のパッケージマネージャで、ディスク上で依存パッケージを共有する仕組みにより、インストールが速くディスク消費も小さいのが特徴です。
pnpm 公式ドキュメントは3つの方法を案内しています。順に見ていきます。
corepack enable pnpm
corepack use pnpm@latest-11Corepack を使う利点は、package.json にパッケージマネージャのバージョンが記録され、チーム全員が同じバージョンを使えることです。再現性を重視するプロジェクトに向いています。
⚠️ Node.js 25 以降は Corepack が同梱されません。
2025年3月19日、Node.js の TSC は v25 以降で Corepack を配布しないことを正式に決定しました。Node.js 24 以前では experimental 機能として引き続き利用できます。Node 25 以降で Corepack を使いたい場合は、別途インストールが必要です。
npm install -g corepackActive LTS の v24 を使っている限りは同梱されているので、当面はそのまま
corepack enable pnpmで動きます。
Node.js が入っていれば一番シンプルです。
npm install -g pnpm@latest-11Corepack の同梱状況に左右されないので、この記事の構成（nvm で Node を入れる）なら方法Bが一番素直だと思います。
Node.js なしでも入れられる方法です。
curl -fsSL https://get.pnpm.io/install.sh | sh -wget 派：
wget -qO- https://get.pnpm.io/install.sh | sh -バージョンを指定したい場合：
curl -fsSL https://get.pnpm.io/install.sh | env PNPM_VERSION=<version> sh -公式ドキュメントに記載されている注意点です。
libatomic.so.1 が別途必要になる場合があります確認：
pnpm --version執筆時点の最新は 11.17.0 です。
出典：
AWS 公式ドキュメントが「コピペ用」として提示している3行です。x86_64（Intel/AMD の 64bit）向け。
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/installARM 環境（Snapdragon 搭載 PC など）の場合は URL を差し替えます。
curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/installデフォルトでは /usr/local/aws-cli にファイルが置かれ、/usr/local/bin にシンボリックリンクが張られます。sudo はこれらのディレクトリへの書き込み権限のために必要です。
確認：
aws --versionaws-cli/2.36.9 Python/3.13.4 Linux/5.15.167.4-microsoft-standard-WSL2 exe/x86_64.ubuntu.24こんな出力が返ればOKです（バージョンや環境の部分は各自で異なります）。
awsコマンドが見つからない場合は、ターミナルを再起動してみてください。
AWS 公式は「上記のクイック手順はダウンロードの整合性を検証していません」と明記しています。zip は PGP 署名されているので、検証したほうが安全です。
手順1：GPG をインストール（基本ツールのセクションで入れていれば不要）
sudo apt install gnupg手順2：AWS CLI の公開鍵をファイルに保存
aws-cli-key.asc などのファイル名で、以下を保存します。
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF2Cr7UBEADJZHcgusOJl7ENSyumXh85z0TRV0xJorM2B/JL0kHOyigQluUG
ZMLhENaG0bYatdrKP+3H91lvK050pXwnO/R7fB/FSTouki4ciIx5OuLlnJZIxSzx
（中略：全文は下記の公式ドキュメントからコピーしてください）
-----END PGP PUBLIC KEY BLOCK-----鍵の詳細は以下の通りです。ここが一致していることを確認してください。
Key ID: A6310ACC4672475C
Type: RSA
Size: 4096/4096
Created: 2019-09-18
Expires: 2027-07-01
User ID: AWS CLI Team <aws-cli@amazon.com>
Key fingerprint: FB5D B77F D5C1 18B8 0511 ADA8 A631 0ACC 4672 475C手順3：鍵をインポート
gpg --import aws-cli-key.asc手順4：署名ファイルをダウンロード
curl -o awscliv2.sig https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip.sig手順5：検証
gpg --verify awscliv2.sig awscliv2.zipGood signature from "AWS CLI Team <aws-cli@amazon.com>" が出れば成功です。
このとき
WARNING: This key is not certified with a trusted signature!という警告が出ますが、これは想定内で問題ありません。自分の PGP 鍵と AWS の鍵の間に信頼の連鎖がないだけです。AWS 公式ドキュメントにもそう明記されています。
検証が通ったら、展開してインストールします。
unzip awscliv2.zip
sudo ./aws/installAWS CLI v2 は自動更新されません。更新するときは新しいインストーラをダウンロードし直して --update を付けて実行します。
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip -u awscliv2.zip
sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --updateunzip -u（update フラグ）を使うと、上書き確認のプロンプトをスキップできます。
既存のインストール先がわからなくなったら、次のコマンドで調べられます。
which aws # --bin-dir に渡すパス
ls -l /usr/local/bin/aws # リンク先 = --install-dir に渡すパス常に最新版でよく、バージョン固定が不要なら snap も公式サポートされています。
sudo snap install aws-cli --classicsnap は自動更新されるのがメリットですが、マイナーバージョンを選ぶ組み込みサポートがないため、チームでバージョンを固定したい場合はコマンドラインインストーラのほうが適している、と公式は説明しています。
なお、AWS 公式ドキュメントは「AWS は snap 以外のサードパーティリポジトリを管理していないため、最新版が含まれる保証がない」と注意しています。
apt install awscliは避けたほうが無難です。出典：Installing or updating to the latest version of the AWS CLI — AWS ドキュメント
Terraform は HashiCorp が公式の apt リポジトリを提供しているので、一度登録してしまえば以降は apt upgrade で更新できます。
wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null公式チュートリアルはこのステップを挟んでいます。
gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint出力された fingerprint が、HashiCorp が公式に公開している署名鍵のものと一致するか確認してください。
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list長いですが、やっていることは単純です。
$(dpkg --print-architecture) — CPU アーキテクチャを自動判定signed-by=... — さっき登録したキーでのみ署名検証する指定$(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) — Ubuntu のコードネーム（noble など）を自動取得。取れなければ lsb_release -cs にフォールバックsudo apt update
sudo apt-get install terraform確認：
terraform -version執筆時点の最新安定版は v1.15.8（2026年7月8日リリース）です。
これは入れておくと体験がかなり変わります。
terraform -install-autocomplete実行後、シェルを再起動すると terraform pl → Tab で terraform plan が補完されるようになります。
出典：
最後にまとめて確認しましょう。
git --version
node -v
npm -v
pnpm --version
aws --version
terraform -version執筆時点（2026年7月28日）の各バージョンは以下の通りです。参考までに。
| ツール | 執筆時点のバージョン | インストール方法 |
|---|---|---|
| Git | 2.5x 系（PPA の最新安定版） | ppa:git-core/ppa |
| nvm | v0.40.6 | install.sh |
| Node.js | v24（Active LTS） | nvm install --lts |
| pnpm | 11.17.0 | npm または Corepack |
| AWS CLI | 2.36.9 | 公式インストーラ（zip） |
| Terraform | 1.15.8 | HashiCorp apt リポジトリ |
第2弾を通して出てきた注意点を、最後にもう一度並べておきます。
1. /mnt/c/ にプロジェクトを置かない
ファイルシステムをまたぐと明確に遅くなります。プロジェクトは ~/ 配下へ。
2. Windows 側と WSL 側は別環境
Git は両方に必要。git config も別々に保存されます。「Windows で設定したのに WSL で効かない」は仕様です。
3. which nvm は使えない
nvm はシェル関数なので command -v nvm で確認します。
4. Node.js 25 以降は Corepack が同梱されない
pnpm を Corepack で管理している場合、Node をアップグレードしたタイミングで壊れます。CI や Dockerfile も要チェックです。
5. AWS CLI は自動更新されない--update を付けて再インストールする必要があります。忘れがちなのでカレンダーに入れておくのがおすすめです。
6. Git の改行コード
Windows と Linux をまたぐと大量の差分が出ます。.gitattributes で明示するのが確実です。
7. git credential-manager --version は WSL では動かない
Microsoft 公式ドキュメントに載っている確認コマンドですが、Linux 版 Git は .exe を補完しないため is not a git command になります。git-credential-manager.exe --version と書けば動きます。GCM が入っていないわけではありません。
これで、WSL2 上の Ubuntu に開発の基礎セットがそろいました。Git でコードを管理し、Node.js/pnpm でフロントエンドを動かし、AWS CLI と Terraform でクラウドを操作する — ひととおりの土台ができた状態です。
次回はこの環境の上で、VS Code の WSL 拡張を使ったリモート開発や、Docker との連携あたりを扱えたらと思います。
すべて 2026年7月28日 に確認しています。
WSL / 環境全般
Git
Node.js / nvm
pnpm
AWS CLI
Terraform
この記事をシェア
coiai
この記事もおすすめ
株式会社coiaiは、「想像できることを美しく実現」を掲げ、XR・Web・アプリ・システム開発およびDX支援を行う会社です。 創業2022年、東京都練馬区に本社を置き、要件のヒアリングからPoC（概念実証）、本番運用まで一貫して伴走します。 まずはお気軽にご相談ください。
主なご相談内容
詳しい会社情報は会社概要ページでご覧いただけます。
