こんにちは。テックリードの私だ。
日々の開発において、このような不毛な議論やトラブルにリソースを割いていないだろうか？
- 「私のローカル環境では動くのに、stagingコンテナだと落ちる」
- 「Node.jsのバージョン差異でネイティブモジュールのビルドが爆発した」
- 「プロジェクトを切り替えるたびにグローバルの環境変数が汚染されていく」
モダンなWeb開発において、Dockerを用いたコンテナ化はもはやデファクトスタンダードだ。しかし、「コードを書くのはホストOSのIDE、実行とテストはDocker CLIや別ウィンドウのターミナル」という半端な分離ワークフローを続けているとしたら、それはエンジニアの認知負荷を無駄に高め、開発速度を大きく殺している。
今回は、IntelliJプラットフォームの最高峰であるWebStormとDockerを完全に融合させ、ローカル環境を一切汚すことなく、IDEのGUIと強力なインテリジェンスの恩恵を100%受けながらコンテナ開発を完結させる「シームレス連携術」を伝授する。
単なる「コンテナの起動方法」ではない。プロジェクトに新人が参画したその日から、IDEを開くだけで同一のコンテナ環境が立ち上がり、ブレークポイントがヒットする――そんな「プロフェッショナルな開発基盤」の構築法を解説しよう。
—
1. なぜ「WebStorm × Docker」なのか？（内部アーキテクチャの理解）
多くの開発者は、Dockerを「CLIで操作するもの」、あるいは「VS CodeのRemote Containersで開くもの」と捉えている。しかし、WebStormのDockerインテグレーションは、単なるDocker APIのラッパーではない。
WebStormは、Dockerデーモン（UnixドメインソケットまたはNamed Pipe）と直接通信し、コンテナ内で稼働するNode.jsプロセスやV8エンジンと直接デバッグセッション（Inspector Protocol）を確立する。
つまり、ホスト側（手元のMacやWindows）にNode.jsのランタイムすらインストールされていなくても、WebStormの強烈なコード補完、静的解析、そしてTypeScriptの言語サービスを維持したまま、「頭脳はホスト、身体はコンテナ」という理想的な分離と結合を同時に実現できるのだ。
—
2. 実践：マルチステージビルドを意識したベストプラクティス設定
まずは、WebStormから完全にコントロールするためのDocker基盤を整える。ここでは、開発（Development）と本番（Production）を美しく分離しつつ、WebStormのホットリロード（ライブリロード）に最適化した `docker-compose.yml` の構成を示す。
`docker-compose.yml`（実務標準のベストプラクティス構成）
version: ‘3.8’
services:
web:
build:
context: .
dockerfile: Dockerfile.dev
target: development # マルチステージビルドのターゲットを指定
container_name: enterprise_web_app
ports:
- “3000:3000” # アプリケーションのエンドポイント
- “9229:9229” # Node.jsリモートデバッグ（Inspector）用のポート
volumes:
# ソースコードをマウントしつつ、node_modulesはコンテナ内の名前付きボリュームで保護
# ホストの汚染を防ぎつつ、ファイルの変更をリアルタイムで検知させる
- .:/app
- /app/node_modules
environment:
- NODE_ENV=development
- WATCHPACK_POLLING=true # ファイル変更検知の確実性を上げる（Docker環境特有の対策）
command: npm run start:dev
networks:
- app-network
networks:
app-network:
driver: bridge
volumes:
node_modules:
> アーキテククトの解説：
> `- /app/node_modules` という無名/名前付きボリュームのオーバーレイ設定に注目してほしい。これがないと、ホストOS（Mac/Windows）のファイルシステムとコンテナ内のLinux間におけるI/Oの非効率や、OS間のバイナリ差異でnpmパッケージがクラッシュする。ホスト側の `node_modules` をコンテナ内に混入させない、極めて重要なテクニックだ。
—
3. WebStormをDockerに接続し、IDE内で完結させる
設定ファイルができたら、いよいよWebStormとDockerを結合する。
1. Dockerデーモンの接続設定
- WebStormの Settings / Preferences ＞ Build, Execution, Deployment ＞ Docker を開く。
- `+` ボタンを押し、利用している環境（Docker Desktop, OrbStack, Podman等）のソケットパスを指定して接続する。
- 画面下部に Servicesツールウィンドウ が出現し、コンテナの一覧が表示されれば接続完了だ。
2. コンテナのライフサイクルをIDEから完全制御
- Servicesツールウィンドウ内で `docker-compose.yml` を右クリックし、「Compose Up」を実行する。
- これだけで、ターミナルを開くことなくコンテナのビルド、起動、ログのストリーミングがWebStorm内で完結する。コンテナが暴走した際も、GUIから即座に「Stop」や「Kill」を叩けるため、精神的なストレスが激減する。
—
4. 開発スピードを極限まで高める：神プラグインと隠れショートカット
日々のコーディング速度を「次元の違うレベル」に引き上げるための、私秘蔵の設定を公開しよう。
絶対に入れるべき神プラグイン
- Docker (JetBrains標準同梱)
- 標準機能だが使いこなせていない人が多い。Dockerfileやcomposeファイルの補完（環境変数やサービス名のオートコンプリート）が強力。
- EnvFile
- `.env` ファイルをDocker RunやCompose設定にシームレスに注入するためのプラグイン。セキュアな環境変数管理をIDE側で担保できる。
現場で即座に使える！生産性爆上げキーボードショートカット（macOS / Windows）
| アクション | macOS ショートカット | Windows / Linux | 狙い・効果 |
| :— | :— | :— | :— |
| Servicesウィンドウの開閉 | `⌥ 8` (`Option` + `8`) | `Alt` + `8` | 迷ったら秒速でDockerの状態を確認・制御する |
| コンテナログのフォーカス | `F4` (コンテナ選択時) | `F4` | ログ出力のエラーへ瞬時にジャンプしてスタックトレースを追う |
| どこでも検索 (Shift 2回) | `⇧ ⇧` (`Shift` + `Shift`) | `Shift` + `Shift` | Docker関連の設定、ファイル、コマンドを全横断検索 |
| ターミナル呼び出し | `⌥ F12` | `Alt` + `F12` | IDE内部のターミナルで即座にコンテナ内へ `exec` 入力 |
—
5. チーム開発で役立つ「設定の共有化（Share Settings）」ルール
「私の環境では動くが、チームメンバーの環境ではDocker連携のエラーが出る」――これを防ぐためには、WebStormのプロジェクト設定をGit管理下に置き、チーム全体でイミュータブル（不変）な開発環境を強制する必要がある。
WebStormは、プロジェクト内の `.idea/` ディレクトリに設定を保存する。これをGitで管理する際、不要な個人用キャッシュを含めず、Dockerおよびランタイムの設定のみをチームで共有するベストプラクティスな `.gitignore` 構成は以下の通りだ。
`.gitignore` の追加推奨設定（`.idea/` 内の制御）
WebStormの個人用設定やワークスペース状態は除外
.idea/workspace.xml
.idea/tasks.xml
.idea/usage.statistics.xml
.idea/dictionaries/
.idea/shelf/
★重要：Dockerの実行構成やサーバー接続設定はチーム共有のためにバージョン管理に含める
.idea/runConfigurations/
.idea/deployment.xml
.idea/modules.xml
これにより、チームメンバーの誰かがプロジェクトをクローンしてWebStormで開いた瞬間から、あらかじめ定義されたDocker Composeの実行構成（Run Configuration）が即座に共有され、全員が全く同じワンクリックでデバッグを開始できるエコシステムが完成する。
—
6. 究極の奥義：コンテナ内リモートデバッグの接続
最後に、この環境構築の最大の果実である「コンテナ内Node.jsのデバッグ」を設定する。これによって、`console.log()` を無限に仕込んでビルドを待つという、前近代的で非効率な開発手法とは永遠に決別できる。
1. WebStormのメニューから Run ＞ Edit Configurations… を開く。
2. `+` ボタンを押し、Node.js または Attach to Node.js/Chrome を選択。
3. 以下のように設定する：
- Host: `localhost`
- Port: `9229` （docker-compose.ymlでマウントしたポート）
- Remote files path: `/app` （コンテナ内のソースコード絶対パス）
4. これを保存し、デバッグアイコン（虫のマーク）を押す。
これで、コンテナ内で動いているTypeScriptのコードに対して、WebStorm側でブレークポイントを直撃させることができる。変数のインスペクト、コールスタックの追跡、条件付きブレークポイントの活用――すべてがローカルアプリをデバッグしているかのような滑らかさで手に入るのだ。
—
総括
WebStormとDockerの連携は、単に「ツールを便利に使う」というレベルの話ではない。「インフラストラクチャの差異」という開発者最大の敵をIDEの内部にカプセル化し、ピュアな創造的コーディングにのみ集中するためのパラダイムシフトである。
ローカル環境の汚染に怯える日々は今日で終わりにしよう。このシームレスなワークフローをチームに導入し、圧倒的な開発スピードとコード品質を手に入れてほしい。あなたのプロジェクトの成功を、アーキテクトとして心より応援している。