Windows + DevContainerが激遅な問題を解決し、Claude Codeと爆速AI開発環境を構築

私はこれまで、AIアシスタントWindsurfを相棒に、SvelteKitベースのブログサイトを開発してきました。Windowsローカル環境での開発は、ホットリロードも瞬時で、非常に快適そのものでした。

しかし、より高度なコーディングサポートを求め、新たな相棒としてClaude Codeを迎えることを決意。そして、AIの能力を最大限に引き出すために、プロジェクト環境を完全に再現できるDevContainerへと移行することにしたのです。SvelteKitのプロジェクトをそのままDevContainerに載せ、最高のAIペアプログラミング体験を夢見ていました。

しかし、これが悪夢の始まりでした。

快適だった開発体験は見る影もなく、2つの巨大な壁が私の前に立ちはだかったのです。

SvelteKitのビルドが、絶望的に遅延する
起動した開発サーバーに、ブラウザからアクセスできない

この記事は、快適だったWindsurf + SvelteKit環境から、Claude Code + DevContainer環境へ移行する過程で直面した問題を解決し、最終的に以前を上回るほどの「爆速開発環境」をWindows上に再構築するまでの記録です。

##なぜDevContainerがClaude Codeに最適なのか？

本題に入る前に、なぜ私が「Windowsローカル環境で直接開発する」という安易な道を選ばず、ここまでDevContainerにこだわったのかを説明します。それは、Claude Codeのような高度なAIアシスタントの能力を100%引き出すには、DevContainerが提供する以下のメリットが不可欠だと考えたからです。(まぁ、下記の記事に触発されただけなのですが)

WindowsでClaude Codeを使う3つの方法を徹底比較

Zenn

###DevContainerってなに？ Docker Desktopだけじゃダメなの？

ここで、「Docker Desktopさえあればコンテナは動くのに、なぜDevContainerという別のものが必要なの？」という疑問が浮かぶかもしれません。これは非常に重要なポイントです。

一言で例えるなら、Docker Desktopは「コンテナを動かすための強力なエンジン」であり、DevContainerは「開発作業に特化した、そのエンジンを操るためのインテリジェントな運転席」です。

Docker Desktopの役割(エンジン):
コンテナのイメージをビルドし、コンテナを起動・停止・管理する、すべての基礎となるプラットフォームです。これ単体でも、docker runやdocker execといったコマンドを使えばコンテナを操作できます。しかし、これは言わば、車のエンジンを直接手で回しているようなものです。
DevContainerの役割(運転席兼ナビゲーションシステム):
DevContainerは、VS Codeの拡張機能として提供され、Dockerという強力なエンジンを開発ワークフローのために最適化し、自動化してくれる仕組みです。具体的には、以下のことを担当します。
- devcontainer.json(設計図)を読む：プロジェクトに必要な環境を自動で構築します。
- VS Codeとのシームレスな統合：コンテナ内のファイルを、まるでローカルファイルのように編集できます。
- 拡張機能の管理：コンテナ内に、そのプロジェクト専用のVS Code拡張機能を自動でインストールします。
- ポートフォワーディングの自動化：コンテナ内で起動したサーバーに、localhostでアクセスできるように自動で設定します。

つまり、Docker Desktopが「コンテナを動かす力」を提供するのに対し、DevContainerは「その力を開発作業のために、賢く、自動的に引き出してくれる仕組み」なのです。両者は競合するものではなく、最高の開発体験を実現するための強力なタッグです。

このDevContainerという「インテリジェントな運転席」に座ることで、初めてClaude Codeとの快適なドライブ(ペアプログラミング)が可能になります。

###1. AIとの完璧な意思疎通：環境のコード化

DevContainerの核心は、.devcontainer.jsonという設定ファイルにあります。これは、プロジェクトに必要なOS、言語バージョン、ツール、VS Code拡張機能のすべてをコードとして定義する「環境の設計図」です。

Claude Codeは、この「設計図」を読むことで、プロジェクトの技術スタックやセットアップ方法を正確に理解します。これにより、AIは「このプロジェクトはTypeScriptのバージョン5だから、この書き方を提案しよう」といった、極めて文脈に沿った質の高いサポートを提供できるのです。このAIとの完璧な意思疎通こそ、私が目指したものでした。

###2. 「私のPCでは動きます」からの解放

この「環境の設計図」は、チーム開発においても絶大な効果を発揮します。新しいメンバーは、リポジトリをクローンしてボタンをクリックするだけで、誰でも全く同じ開発環境を完璧に再現できます。「私の環境では動くのに…」という不毛な問題が撲滅され、開発の本質に集中できます。(個人開発なのでチームなんて組んでいないのですが)

###3. クリーンでポータブルな開発環境

PCはいつ壊れるか分からないですし、日々何かしらいじっていたら秘伝の環境設定が積み重なっており二度と同じ環境構築は出来ないような魔境に、私の場合はすぐPCがなってしまいます。なのでリポジトリをクローンさえすれば何とかなる、というのは重視したい観点でした。

コンテナ技術により、開発環境はPC本体から完全に隔離されます。プロジェクトごとに異なるツールをインストールしてもPCが汚れることはなく、プロジェクトを削除すれば環境もクリーンに消え去ります。このポータビリティ(持ち運びやすさ)も大きな魅力です。

この素晴らしいシナジーを求め、私はWindowsでの挑戦を始めました。

Windows端末でDevContainerを用いた環境構築は下記ページを参考にしました。

devcontainerでClaude Codeを動かす(Windows)

Zenn

##第1章：ビルドが遅い！SvelteKitのホットリロードが数分待ちに

最初の壁は、パフォーマンスでした。以前は一瞬で起動していたSvelteKitの開発サーバーが、DevContainer環境では何をしても絶望的に遅く、最初の画面が表示されるまでに数分を要しました。これでは、Claude Codeにコード修正を頼んでも、その結果を確認する前に日が暮れてしまいます。

###当初の勘違い：「マウント」していれば大丈夫だと思っていた

当初、私はこの遅延の原因が全く理解できませんでした。

なぜなら、私のプロジェクトフォルダはDevContainerに正しく「マウント」されていたからです。これはDockerの基本的な使い方であり、コンテナがホストのファイルにアクセスするのは当たり前の機能です。ですから、パフォーマンス問題の原因は他にあるはずだ、と。

「Docker DesktopのCPUやメモリ割り当てが少ないのか？」「コンテナイメージに無駄があるのか？」など、私は見当違いの調査に時間を費やしてしまいました。

しかし、調査を進める中で、私は重大な事実に気づきました。それは「マウント」という言葉の裏に隠された性能の罠です。

###真の原因：Windowsとコンテナ(Linux)の「見えない壁」

根本原因は、SvelteKitのソースコードをWindowsのファイルシステム（C:\Users...）に置いたまま、WSL 2上のコンテナからアクセスしていたことでした。

この「Windowsからのマウント」は、例えるなら「低速な翻訳ブリッジ」を介してファイルを読むようなものです。ファイルにアクセスするたびに変換コストが発生するため、Vite(SvelteKitのビルドツール)のように何万ものファイルを読む処理では、その遅延が積み重なり、致命的になります。

私が「大丈夫」だと思っていたマウントは、実はパフォーマンスのボトルネックそのものだったのです。

###解決策：SvelteKitプロジェクトごと「コンテナの国」へ移住させる

この「翻訳ブリッジ」を回避し、「ネイティブの高速道路」を使うための唯一の方法。それがSvelteKitのソースコード全体をWSL 2のネイティブファイルシステム(例：/home/USER_NAME/projects/)に配置することでした。

これにより、コンテナは同じLinux国内のファイルを直接、超高速に読み書きできるようになります。

(この決断に至るまでには、数々のトラブルシューティングがありました。皮肉なことに、この道筋を照らしてくれたのは、WindsurfでもClaudeでもなく、GoogleのGeminiでした)

WSLインスタンスの選択： Docker専用の特殊なWSL環境ではなく、Microsoft StoreからインストールしたUbuntuを使うのが正解でした。
VS Codeの連携設定： Remote Development拡張機能パックのインストールは、VS CodeとWSLを繋ぐために必須でした。
Dockerとの連携設定： Docker Desktopの設定で、UbuntuからのWSL Integrationを有効化する必要がありました。

これらの手順を経てついにソースコードをWSL 2の中に配置し、DevContainerを起動。結果、以前は3分48秒かかっていたビルドが、わずか数十秒に短縮。これで、Claude Codeとの高速なイテレーション(繰り返し作業)が可能になりました。

##第2章：サーバーに繋がらない！Claude Codeと開発したUIがプレビューできない

ビルドは速くなりましたが、次なる壁が立ちはだかりました。pnpm devで起動したSvelteKitの開発サーバーに、Windows上のブラウザからアクセスできないのです。これでは、Claude Codeが提案してくれたUIの変更を、リアルタイムで確認することができません。

###原因：Viteがコンテナの「内側」しか見ていなかった

この問題の犯人は、SvelteKitが内部で利用しているビルドツール、Viteのデフォルト設定でした。

セキュリティのため、Viteサーバーは初期設定ではコンテナの内部からのアクセスしか受け付けません。しかし、私たちのブラウザはコンテナの外部であるWindows上で動作しています。この「内」と「外」の壁が、接続を妨げていたのです。

###解決策：Viteに「外部も歓迎する」よう設定する

// vite.config.js
 
import { defineConfig } from 'vite';
// ... 他のインポート
 
export default defineConfig({
  // ... 他の設定
  server: {
    host: true, // これが外部からのアクセスを許可する設定
  },
});

この一行の変更により、コンテナ内で起動したSvelteKitの開発サーバーに、Windowsのブラウザから瞬時にアクセスできるように。Claude Codeが生成したフロントエンドのコードを、遅延なくプレビューできる環境が、ついに完成しました。

##結論：最高のAIペアプログラミング体験は、最高の環境から

Windows上でClaude Codeの真価を最大限に引き出すための、私の推奨構成はこれです。

WSL2 (Ubuntu) を導入する。
ソースコードは、必ずWSL 2のファイルシステム内に置く。
VS CodeのRemote Development拡張機能を使い、WSL内のプロジェクトを開く。
そこからDevContainerを起動する。

この構成により、ファイルI/Oとネットワークの両方のボトルネックが解消され、AIとのペアプログラミングに集中できる、高速でクリーンな開発環境が手に入ります。

最初は少し遠回りに感じるかもしれませんが、この環境を一度構築すれば今後のすべてのプロジェクトで最高の開発体験が得られます。この記事が、WindowsでClaude Codeと共に未来を創造しようとしている、すべての開発者の助けになることを願っています。