WindowsでWSL2をセットアップしてUbuntuを使えるようにする

TerraformやAWS CLI、Dockerを快適に使うために、WindowsにWSL2を導入しました。

この記事では、実際に行ったセットアップ手順と、途中で遭遇したエラーへの対処方法をまとめます。

なぜWSLを使うのか？

WSL（Windows Subsystem for Linux）は、Windows上でLinux環境を動かすための仕組みです。

AWSやTerraform、Dockerなど、多くの開発ツールはLinux環境との相性が良いため、Windowsで開発する場合でもWSL2を利用するのが一般的です。

今回の開発環境では以下のような構成を想定しています。

Terraform
AWS CLI
Docker
Git
Node.js
Electron
PostgreSQL

1. WSLをインストール

PowerShell（管理者）を開き、以下を実行します。

wsl --install

2. Ubuntuの初回セットアップ

Ubuntuを起動すると、Linuxユーザー名とパスワードの設定を求められます。

例

Enter new UNIX username:

好きなユーザー名を入力します。

続いてパスワードを設定します。

※入力中は文字が表示されませんが正常な動作です。

3. パッケージを更新

Ubuntuを起動したら、まず最新状態へ更新します。

sudo apt update
sudo apt upgrade -y

4. エラーが表示された

アップグレード中に次のようなメッセージが表示されました。

Failed to connect to system scope bus via local transport: Connection refused

一見エラーに見えますが、今回は最後まで

Processing triggers...
done.

と表示され、更新自体は正常に完了していました。

WSLではsystemd関連の処理で、このような警告が表示されることがあります。

5. WSLの状態を確認

PowerShellで以下を実行します。

wsl --status

今回は

既定のディストリビューション: docker-desktop
既定のバージョン: 2

となっていました。

6. Docker DesktopとUbuntuの違い

ここで少し混乱しやすいポイントがあります。

Docker Desktopをインストールすると、docker-desktopというWSLディストリビューションが作成されます。

しかし、これはDockerが内部で利用するためのもので、普段の開発を行う場所ではありません。

おすすめの構成は次の通りです。

Windows
│
├── VS Code
├── Docker Desktop
│
├── Ubuntu (WSL2)
│   ├── Git
│   ├── Terraform
│   ├── AWS CLI
│   ├── Node.js
│   └── Docker CLI
│
└── docker-desktop
    └── Docker Engine

開発はUbuntuで行い、Docker Desktopはコンテナ実行基盤として利用します。

7. Ubuntuを既定のディストリビューションに変更

現在登録されているWSLを確認します。

wsl -l -v

Ubuntuがインストールされていることを確認したら、

wsl --set-default Ubuntu

を実行します。

これで

wsl

だけでUbuntuが起動するようになります。

今後インストール予定

WSL環境では今後以下を導入していきます。

Git
Node.js
pnpm
Docker CLI
AWS CLI
Terraform

この環境をベースに、AWS Organizations、IAM Identity Center、Terraformを利用したインフラ構築を進めていく予定です。

まとめ

WSL2を導入することで、Windows上でもLinuxとほぼ同じ開発環境を構築できます。

特にAWSやTerraform、Dockerを利用する場合は、Windowsネイティブ環境よりもトラブルが少なく、本番環境との差異も減らせます。

Windowsでクラウドインフラ開発を始める場合は、まずWSL2 + Ubuntuをセットアップしておくことをおすすめします。

この記事をシェア

投稿日: 2026年7月28日

カテゴリ: 未分類

タグ:

coiai

この記事もおすすめ

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）確認日：2026年7月28日バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。はじめに：WSL開発の大原則コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。出典：WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。ディストリビューションの優先パッケージマネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

AWS CLIでIAM Identity Center（AWS SSO）を設定する

これまでの記事で、まで構築しました。今回は、ローカルPCからAWSを操作するために、AWS CLIをIAM Identity Center（AWS SSO）へ接続します。これにより、長期アクセスキーを発行せず、安全にAWS CLIやTerraformを利用できるようになります。なぜアクセスキーを使わないのか以前はAWS CLIを利用する際、IAM Userを作成し、を発行していました。しかし、この方法にはいくつかの課題があります。現在AWSでは、人によるAWSへのアクセスには**IAM Identity Center（旧AWS SSO）**を利用することが推奨されています。 IAM Identity CenterとAWS CLIの仕組み AWS CLIは、IAM Identity Centerへログインし、一時的な認証情報（Temporary Credentials）を取得します。つまり、という、安全性の高い認証方式になります。 aws configure sso を実行まずAWS CLI v2をインストールします。インストール後、次のコマンドを実行します。すると、対話形式で設定が始まります。 SSO Session Name ここはローカルPC上だけで利用する設定名です。今回はとしました。好きな名前で問題ありません。 SSO Start URL IAM Identity CenterのアクセスポータルURLを入力します。例このURLは IAM […]

AWS IAM Identity Centerとは？IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。 IAM Identity Centerとは IAM Identity Center（旧 AWS Single Sign-On）は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。従来のように各AWSアカウントへIAM Userを作成する必要はなく、というメリットがあります。 AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。なぜIAM UserではなくIdentity Centerなのか以前は、このような構成が一般的でした。しかし、この方法ではといった課題があります。 Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。 AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報（IAM Userのアクセスキーなど）をできる限り利用しないことが推奨されています。今回の構成今回は次のようなシンプルな構成にしました。グループ Administrators AWS環境全体を管理するメンバーです。現在はを所属させる予定です。 Developers アプリケーションやインフラ開発を行うメンバー向けです。今回はまだ利用していませんが、開発メンバーが増えた際に使用します。将来的にはなどを割り当てる予定です。 ReadOnly 閲覧専用グループです。監査やレビュー、外部アドバイザー向けとして利用します。今回は技術メンターにReadOnly権限を付与することを想定しています。 Permission […]

AWS Organizationsで始めるマルチアカウント設計 ― 小規模開発チーム向けのベストプラクティス

サービスの開発を進めるにあたり、AWSの初期構築を行いました。今回は、AWS Organizationsを利用してマルチアカウント環境を構築し、今後TerraformによるIaC（Infrastructure as Code）やGitHub Actionsを利用したCI/CDを前提とした設計を採用しています。この記事では、実際に構築した構成と、その設計意図をまとめます。なぜ最初にAWS Organizationsを導入するのか AWSでは1つのアカウントにすべてのリソースを作成することもできます。しかし、開発が進むにつれて次のような問題が発生します。 AWSではこのような課題に対応するため、マルチアカウント構成を推奨しています。AWS Organizations ユーザーガイド Organizationsとは AWS Organizationsは、複数のAWSアカウントをまとめて管理するためのサービスです。 OrganizationsにはOU（Organizational Unit）という概念があります。 OUはEC2やS3を配置する場所ではなく、AWSアカウントを整理するためのフォルダのような存在です。例えば、というようにOUを作成し、その中へAWSアカウントを配置していきます。 OUを利用することで、将来的にSCP（Service Control Policies）などのポリシーをまとめて適用できるようになります。AWS Organizations のベストプラクティス今回採用した構成今回はAWS Security Reference Architecture（AWS SRA）の考え方を参考にしつつ、小〜中規模の開発チーム向けにシンプルな構成を採用しました。AWS Security Reference Architecture (AWS SRA) Infrastructure OU インフラ運用に必要なAWSアカウントを配置します。 Log CloudTrailをはじめとする監査ログを集約するためのアカウントです。 AWSではCloudTrailのイベント履歴は標準で90日間参照できますが、長期間保持する場合はS3へ保存する構成が推奨されています。さらに、一定期間経過後はS3 Glacierへ移行することで保管コストを抑えることができます。今後はCloudTrailだけでなく、各種監査ログもこのアカウントへ集約する予定です。 Security Security HubやGuardDuty、AWS Configなどのセキュリティサービスを配置するためのアカウントです。今回はまだ構築していませんが、を集約する予定です。 AWS SRAでも、ログ管理アカウントとセキュリティアカウントを分離する構成が推奨されています。 […]