LASSIC Media らしくメディア
開発環境のコンテナ化・標準化を外注で進める
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 開発環境のコンテナ化は、開発者ごとに異なるローカル環境が原因で起きる不具合を、devcontainer.jsonによる宣言的な定義で抑える取り組みです
- Development Containers仕様に対応したVS Code Dev ContainersやGitHub Codespacesを使うと、同じ設定ファイルをローカルとクラウドの両方で使い回せます
- 導入にはベースイメージ選定・拡張機能設定・パフォーマンス対策・CIとの設定共通化といった検討項目があり、外注する場合は委託範囲とドキュメント化の範囲を事前に定めることが重要です
目次
“works on my machine”問題と開発環境標準化の必要性
「自分の環境では動くのに、他の人の環境では動かない」という、いわゆる”works on my machine”問題は、開発チームで日常的に発生します。開発環境をコンテナで統一するDev Containersは、devcontainer.jsonという設定ファイルでOSやツールのバージョンを宣言的に固定し、この問題を環境面から抑える仕組みです。
開発チームでは、メンバーごとにOSやエディタ、言語ランタイムのバージョンが異なる状態が生まれやすい状況です。新しいメンバーが加わるたびに「READMEの手順通りに進めたのに動かない」というやり取りが発生したり、既存メンバーの環境でも時間の経過とともに手元のツールのバージョンが少しずつずれていく場面があります。
この状態を放置すると、コードは動くはずなのに個々の環境差が原因で不具合の再現・切り分けに時間がかかったり、新規メンバーのオンボーディングに要する時間が延びたりする可能性があります。環境構築の手順書をいくら詳しく書いても、手順自体が形骸化し、更新が追いつかなくなるケースも珍しくありません。
こうした背景から、開発環境そのものをコード化し、チーム全員が同じ定義から同じ環境を再現できる仕組みへの関心が高まっています。次章で解説するDev Containers仕様は、この「開発環境のコード化」を業界横断で扱えるように標準化した仕組みです。
Dev Containers仕様とdevcontainer.jsonの仕組み
Dev Containers（Development Containers）仕様は、コンテナを開発環境として活用するための標準規格です*1。既存のコンテナフォーマットに、開発に特有の設定やツール、構成を追加し、簡潔かつ単一のコンテナ定義で開発環境を運用できるようにすることを目的としています*1。
Dev Containers仕様が定義する主な構成要素は4つです*1。1つ目はdevcontainer.jsonで、開発環境の設定全体を記述する中心的なファイルです。2つ目はImage・Dockerfileで、コンテナの基盤となるイメージやコンテナ定義を指します。3つ目はFeaturesで、開発環境のセットアップ手順を部品として共有・再利用できる機能です。4つ目はTemplatesで、複数の技術スタックに対応した定義のひな形です*1。
devcontainer.jsonには、ベースイメージやDockerfile、あるいは既存のdocker-compose.ymlの参照先を指定できます。加えて、コンテナ内で使うエディタの拡張機能、外部に転送するポート、コンテナ作成後に自動実行するコマンド（postCreateCommandなど）を宣言できます。これらをリポジトリに含めておくことで、開発環境の構築手順そのものをコードとしてバージョン管理できます。
この仕様は「devcontainers」プロジェクトが策定・公開しており、GitHub上のリポジトリで仕様の管理が行われています*1。ローカル環境だけでなくリモート環境でも実行でき、継続的インテグレーション（CI）やテストの支援にも活用できる設計です*1。特定のエディタに縛られない仕様として設計されているため、複数のツールが対応を進めています。
VS Code Dev ContainersとGitHub Codespacesの関係
Dev Containers仕様に対応した具体的な実装として代表的なのが、Visual Studio Code（VS Code）の「Dev Containers」拡張機能と、GitHub Codespacesです。両者は同じdevcontainer.jsonを読み込む仕組みのため、設定ファイルを一つ用意しておけば、ローカルとクラウドの両方で使い回せます。
VS Code Dev Containers拡張機能を使うと、任意のフォルダをコンテナ内で開き、コンテナの中でIntelliSense（コード補完）やコード解析、デバッグなど、VS Codeの機能をそのまま利用できます*2。この拡張機能の目的は、コンテナを「本格的な開発環境」として機能させることで、チーム全体が同じコンテナ設定を使えるようにし、ローカル環境の違いによる不具合を解消することにあります*2。devcontainer.jsonは、この拡張機能が読み込む設定の中核で、コンテナの構築方法・拡張機能・ポート設定・環境変数を定義します*2。
GitHub Codespacesは、Dev Containerを仮想マシン上でホストし、ブラウザやローカルのVS Codeからクラウド上のコンテナに接続して開発する仕組みです*3。ここで使われるdevcontainer.jsonも、リポジトリごとにカスタマイズされた開発環境を定義するファイルで、プロジェクトに必要なツールとランタイムを含めることで、チームメンバーが一貫した環境で作業できるようにします*3。GitHub公式のドキュメントでは、devcontainer.jsonによる標準化を「個人的な好みではなく、カスタマイズと標準化の分離」と位置づけており、複数の設定を用意して異なるチームが適切な環境を選べるようにする考え方が示されています*3。
つまり、ローカルの端末にDockerを入れて手元で開く場合はVS Code Dev Containers、ブラウザや非力な端末からクラウド上のコンテナで作業する場合はGitHub Codespacesという使い分けが可能です。どちらを選んでも、devcontainer.jsonという同じ設定の入り口を使えるため、チームの一部がローカル、一部がCodespacesという併用もできます。
標準化で得られる効果：オンボーディング短縮と依存の一元管理
開発環境をコンテナで標準化する効果として、まず挙げられるのがオンボーディングにかかる時間の短縮です。新規メンバーの環境構築が「Dockerとエディタの拡張機能を入れて、リポジトリを開く」という操作に近づくため、言語ランタイムやライブラリのバージョンを個別にインストールする手順を減らせます。
2つ目の効果は、依存関係の一元管理です。プロジェクトで使う言語のバージョンやツールチェーンをdevcontainer.jsonとDockerfileに集約することで、「このメンバーだけ古いバージョンのツールを使っている」といった状態を防ぎやすくなります。依存関係の更新もリポジトリ内の設定ファイルを更新するだけで、チーム全員に反映できます。
3つ目の効果は、ドキュメントと実態のズレの解消です。従来はREADMEやWikiに環境構築手順を書いていても、手順の更新が追いつかず実態とズレることがありました。devcontainer.jsonは実行可能な設定ファイルであるため、手順書とは異なり「動かなければ気づく」性質を持ちます。設定ファイル自体が最新の構築手順として機能する点は、テキストの手順書との大きな違いです。
ただし、これらの効果は導入の設計次第で変わります。ベースイメージの選定や拡張機能の取り扱いを誤ると、逆にコンテナ特有のトラブルシューティングコストが発生する場面もあります。次章では、導入時に検討すべき具体的な項目を整理します。
導入の進め方：ベースイメージ・拡張機能・パフォーマンス・CI連携
ベースイメージの選定：公式イメージか自社標準イメージか
devcontainer.jsonのベースには、言語ごとに用意された公式のベースイメージを使う方法と、自社の標準ツールを組み込んだ独自イメージを使う方法があります。プロジェクトの立ち上げ初期は公式イメージから始め、チーム共通のツールが増えてきた段階で自社標準イメージに切り替える進め方が現実的です。イメージの更新頻度と、脆弱性対応の運用方針もあわせて決めておくと、長期運用で管理しやすくなります。
拡張機能・Featuresの設定：チーム全体で統一すべき範囲を決める
devcontainer.jsonにはエディタの拡張機能を指定できるため、コードフォーマッターやリンターなど、チームで統一したい拡張機能をあらかじめ組み込んでおけます。一方で、テーマやキーバインドのような個人の好みに関わる設定まで強制すると、開発者ごとのカスタマイズ性を損ないます。「標準化すべき範囲」と「個人の裁量に委ねる範囲」を分けて設計することが大切です。Featuresを使うと、言語ランタイムやCLIツールの追加を再利用可能な部品として組み込めます。
パフォーマンスとボリューム設計：ファイルI/Oの遅さへの対策
コンテナ内開発では、ホストとコンテナ間でファイルをバインドマウントする構成の場合、ファイル数が多いプロジェクトでファイルI/O性能が低下する場面があります。この対策として、依存パッケージのインストール先やビルド出力先を名前付きボリュームに切り出す方法があります。ソースコード自体はバインドマウントしつつ、頻繁に読み書きが発生するディレクトリだけボリューム化することで、影響を抑えられます。プロジェクトの規模やファイル数に応じて、どこまで対策が必要かを見極めることが重要です。
CI環境との設定共通化：同じdevcontainer.jsonをCIでも使う
devcontainer.jsonで定義したコンテナは、ローカル開発だけでなくCI（継続的インテグレーション）のビルド・テスト環境でも利用できます*1。ローカルとCIで異なるDockerfileや環境構築スクリプトを個別に保守していると、両者の環境差からCIだけで発生する不具合の調査に時間がかかることがあります。同じdevcontainer.jsonをCIのジョブでも参照する構成にすることで、環境差そのものを設計上減らせます。
外注する場合の委託範囲と発注準備
委託範囲の考え方：設計・作成・ドキュメント化までを含める
開発環境のコンテナ化を外注する場合、devcontainer.jsonとDockerfile（またはdocker-compose.yml）の設計・作成に加えて、必要な拡張機能・Featuresの選定、CI環境との設定共通化、導入手順のドキュメント化までを委託範囲に含めるプロジェクトが一般的です。設定ファイルを作るだけでなく、チームが自走して更新していけるようにするための知見移転も範囲に含めておくと、導入後の運用がスムーズになります。
発注前に整理しておくとよい情報
発注の準備として、現状の開発環境構築手順、使用している言語・フレームワークのバージョン、既存のDockerfileやdocker-compose.ymlの有無、CI環境で使っている設定を整理しておくと、委託先との要件のすり合わせがしやすくなります。特に、ローカル環境に依存したスクリプトやパス指定が残っている場合は、その一覧を共有することで、コンテナ化にあたって調整が必要な箇所を早期に洗い出せます。
また、対象範囲を最初から全リポジトリに広げるのではなく、まずは1つのプロジェクトで導入し、パフォーマンスや運用上の課題を検証したうえで対象を広げる進め方も検討に値します。段階的な展開は、コンテナ化に伴う想定外の課題を早期に発見し、対策を講じるうえで有効です。
委託先選定で確認しておきたいポイント
委託先を選ぶ際は、Dockerやコンテナ技術の構築実績に加えて、CI/CD環境の設計経験があるかどうかを確認することをお勧めします。開発環境のコンテナ化はCI環境との連携を視野に入れて設計する場面が多いため、両方の知見を持つ委託先であれば、設計の一貫性を保ちやすくなります。あわせて、導入後にチーム内で設定を保守していけるよう、ドキュメントや説明を含めた知見移転に対応できる体制かどうかも確認するとよいでしょう。
LASSICのIT事業部では、をもとに、要件整理から設計・構築・ドキュメント化まで一貫して対応しています。開発環境の標準化に関するご相談はIT開発支援サービスページからどうぞ。
まとめ：開発環境のコンテナ化で得られるものと進め方
本稿では、”works on my machine”問題の背景と、それを解消するDev Containers仕様・devcontainer.jsonの仕組み、VS Code Dev ContainersとGitHub Codespacesの関係、標準化で得られる効果、導入時の検討項目、外注時の委託範囲を整理しました。要点を3つにまとめます。
第一に、開発環境のコンテナ化は、開発者ごとに異なるローカル環境が原因で起きる不具合を、devcontainer.jsonという宣言的な設定ファイルで抑える取り組みです。手順書に依存せず、実行可能な設定として環境を再現できる点が特徴です。
第二に、Dev Containers仕様はエディタやツールに縛られない標準規格であり、VS Code Dev ContainersとGitHub Codespacesはいずれも同じdevcontainer.jsonを読み込みます。ローカルとクラウドを併用するチームでも、設定ファイルを一つに集約できます。
第三に、導入にはベースイメージの選定・拡張機能の統一範囲・パフォーマンス対策・CI環境との設定共通化といった検討項目があり、外注する場合はこれらの設計に加えてドキュメント化・知見移転までを委託範囲に含めることが、導入後の自走につながります。
よくある質問
Dev Containersとdocker-composeを使った従来の開発環境の違いは何ですか？
docker-composeはコンテナ群の起動・ネットワーク構成を定義する仕組みで、Dev Containersはその上に「エディタからどう開発するか」という開発体験の定義を加える仕様です。Dev Containers仕様ではdevcontainer.jsonにベースイメージやDockerfile、docker-compose.ymlを指定できるため、既存のcompose構成をそのまま活かしながら、エディタの拡張機能やポート、ユーザー設定を追加で宣言できます。
GitHub CodespacesとVS Code Dev Containersはどちらを使えばよいですか？
どちらも同じdevcontainer.jsonを読み込む仕組みのため、リポジトリの設定は共通化できます。ローカルにDockerを用意して手元のマシンで開く場合はVS Code Dev Containers拡張機能、ブラウザや非力な端末からクラウド上のコンテナで開発する場合はGitHub Codespacesが向いています。同一のdevcontainer.jsonを使うため、チームの一部がローカル、一部がCodespacesという併用も可能です。
既存プロジェクトにDev Containersを後から導入する場合、大きな改修が必要ですか？
既存のDockerfileやdocker-compose.ymlがあれば、devcontainer.jsonから参照する形で導入できるため、大規模な改修は必須ではありません。ただし、ローカル環境依存のスクリプトやパス指定が残っている場合は、コンテナ内で完結するように調整が必要になる場面があります。段階的に対象リポジトリを広げていく進め方が現実的です。
コンテナ内開発でパフォーマンスが低下することはありますか？
特にファイル数の多いプロジェクトをホストとコンテナ間でバインドマウントする場合、ファイルI/Oの性能がホスト直下での開発より低下する場面があります。Dev Containers仕様ではボリュームやnamed volumeを使ったマウント方式を選べるため、依存パッケージやビルド出力先を名前付きボリュームに切り出すなどの対策で影響を抑えられます。
開発環境のコンテナ化を外注する場合、どこまでを委託範囲にすればよいですか？
devcontainer.jsonとDockerfile（またはdocker-compose.yml）の設計・作成、必要な拡張機能・Featuresの選定、CI環境との設定共通化、導入手順のドキュメント化までを委託範囲に含めるプロジェクトが一般的です。既存の開発フローやツールチェーンの調査を委託先と共有できるよう、事前に現状の環境構築手順や使用ツールを整理しておくと、要件のすり合わせがしやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Development Containers Community「Development Containers Specification」— devcontainer.json・Image/Dockerfile・Features・Templatesの4要素からなる、コンテナを開発環境として活用するための標準仕様。URL: https://containers.dev/
- *2 出典：Microsoft「Developing inside a Container」Visual Studio Code公式ドキュメント — VS Code Dev Containers拡張機能の概要とdevcontainer.jsonの役割を説明する公式資料。URL: https://code.visualstudio.com/docs/devcontainers/containers
- *3 出典：GitHub「Introduction to dev containers」GitHub Docs — GitHub CodespacesにおけるDev Containerの役割とdevcontainer.jsonによる環境標準化を説明する公式資料。URL: https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers
