GitHub Copilot をチームで安全に使うために Dev Containers を試してみた
製造ビジネステクノロジー部の小林です。
GitHub Copilot を使っていますが、最近次のような点が気になりました。
- コードが外部に漏洩しないか
- メンバーが未承認の MCP サーバーを使い始めたらどうするか
- 誰がいつどこに通信したか把握できるか
これらを本格的に解決するには GitHub Codespaces の組織ポリシーによる権限制限が有効かと思います。その前段として開発環境と Copilot の設定をコードで統一することが第一歩になると考え、まず Dev Containers を試しました。
前提
本記事での動作確認環境は以下のとおりです。
| 項目 | バージョン |
|---|---|
| マシン | MacBook |
| macOS | Tahoe 26.3.1 |
| Runcher Desktop | 1.19.3 |
| VS Code | 1.120.0 |
| Dev Containers 拡張 | v0.401.0 |
Dev Containers とは
Dev Containers(Development Containers)は、開発環境を Docker コンテナとして定義する仕組みです。
リポジトリに .devcontainer/devcontainer.json を置くだけで、チーム全員が同じ環境で開発できます。
Dev Containers の詳細は下記の記事をご覧ください。
設定ファイルの配置は以下のとおりです。
プロジェクト/
└── .devcontainer/
├── devcontainer.json ← 環境定義ファイル
└── Dockerfile ← (任意)カスタム環境
VS Code の「Dev Containers」拡張と組み合わせて使うと、エディタの見た目・操作感はほぼそのままに、実行環境だけをコンテナに閉じ込められます。
VS Code「Dev Containers」拡張機能
Microsoft 公式の拡張機能で、3900 万以上のインストール実績があります。

インストールすると VS Code にリモートエクスプローラーパネルが追加され、起動中のコンテナの詳細をサイドバーから確認できます。


属性
| 項目 | 内容の例 |
|---|---|
| ワークスペース | ローカルのプロジェクトディレクトリのパス |
| 名前 | コンテナ名(自動生成) |
| イメージ | mcr.microsoft.com/devcontainers/typescript-node:4-24-bookworm |
| 構成 | .devcontainer/devcontainer.json のパス |
マウント
| 種別 | 項目 | 内容 |
|---|---|---|
| マウントをバインドする | ソース | ローカルのプロジェクトディレクトリ |
| 宛先 | /workspaces/devcontainer-codespaces |
|
| I/O パフォーマンス | OS をブリッジすることで削減 | |
| ボリュームマウント | ボリューム | vscode |
| 宛先 | /vscode |
コンテナがどのイメージで動いているか、どのディレクトリをマウントしているかをコマンドなしで把握できるため、環境の確認やトラブルシュートがしやすいですね。
devcontainer.json に定義できること
- 使用する Docker イメージ(Node.js、Python、Java など)
- 自動インストールする VS Code 拡張機能
- VS Code の設定(フォーマッター、Copilot の設定など)
- コンテナ起動時に実行するコマンド(
npm installなど) - ポートフォワード設定
Dev Containers を使うと嬉しいこと
開発環境がコードで管理できる
devcontainer.json をリポジトリに置くだけで、チーム全員が同じ環境で開発を始められます。「自分の PC では動くのに」という問題が起きにくくなります。
新しいメンバーがジョインしたときも、リポジトリを clone してコンテナを起動するだけでセットアップ完了です。README に「まず Node.js をインストールして…」と書く必要がなくなります。
OS・マシンの差異を吸収できる
Mac・Windows が混在するチームでも、コンテナの中は全員同じ Linux 環境です。「Windows だと改行コードが…」「自分だけパスが通らない…」といったトラブルを減らせます。
AI ツールの設定も統一できる
Copilot の設定(機密ファイルの除外・Agent Mode の挙動など)を devcontainer.json に書いておけば、個人の設定に依存せず全員に適用されます。チームで AI ツールを使い始めるときに、最低限の設定を揃えた状態でスタートできます。
やってみた
devcontainer.json を作る
{
"name": "Copilot Dev Environment",
"image": "mcr.microsoft.com/devcontainers/typescript-node:4-24-bookworm",
"customizations": {
"vscode": {
"extensions": [
"GitHub.copilot",
"GitHub.copilot-chat",
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode",
"GitHub.vscode-github-actions",
"shd101wyy.markdown-preview-enhanced"
],
"settings": {
// Agent Mode が VS Code タスクを自動実行する前に確認ダイアログを出す
"github.copilot.chat.agent.runTasks": false,
// 拡張機能の自動更新を無効化
"extensions.autoUpdate": false,
// 機密ファイルを Copilot の補完対象から除外
"github.copilot.enable": {
"*": true,
".env": false,
"*.pem": false,
"*.key": false
}
}
}
},
// npm install で依存関係を、npm install -g @github/copilot で Copilot CLI をインストール
"postCreateCommand": "npm install && npm install -g @github/copilot",
// ポート 3000 をプライベートに(Codespaces での外部公開を防ぐ)
"forwardPorts": [3000],
"portsAttributes": {
"3000": {
"label": "App",
"onAutoForward": "notify",
"visibility": "private"
}
},
// root ではなく一般ユーザーで実行
"remoteUser": "node"
}
各プロパティの意味はこちらです。
| プロパティ | 内容 |
|---|---|
name |
コンテナの表示名。VS Code のリモートエクスプローラーやステータスバーに表示される |
image |
使用する Docker イメージ。Microsoft 公式の Node.js 24 + TypeScript 環境(Debian 12)で、Dockerfile 不要で始められる |
customizations.vscode.extensions |
コンテナ起動時に自動インストールされる拡張機能。Copilot・ESLint・Prettier・GitHub Actions を全員に統一する |
github.copilot.chat.agent.runTasks |
false にすることで、Agent Mode が VS Code タスク(tasks.json)を自動実行する前に確認ダイアログを出す |
extensions.autoUpdate |
false にすることで、拡張機能の自動更新を止め、意図しないバージョン変更を防ぐ |
github.copilot.enable |
.env・*.pem・*.key など機密ファイルを Copilot の補完対象から除外する |
postCreateCommand |
コンテナ起動後に自動実行するコマンド。npm install で依存関係を、npm install -g @github/copilot で Copilot CLI をインストールする |
portsAttributes |
ポート 3000 をデフォルトで private にする。Codespaces で動かす場合に外部公開を防ぐ |
remoteUser |
node(一般ユーザー)で実行する。root で動かす必要がなければ非 root が無難 |
なお、extensions はあくまで「起動時のプリインストールリスト」であり、リスト外の拡張機能の追加インストールを禁止する機能ではありません(後述)。
Dev Containers を起動する
.devcontainer/devcontainer.json を置いたリポジトリを VS Code で開き、左下の <> をクリックして「コンテナーで再度開く」を選択するとコンテナのビルドが始まります。

初回はベースイメージのダウンロードがあるため数分かかります。ビルドが完了すると VS Code がコンテナ内で起動します。ステータスバー左下に 開発コンテナー: Copilot Dev Environment と表示されていれば成功です。ターミナルもコンテナ内のものに切り替わります。

あわせて postCreateCommand が自動実行され、npm install と Copilot CLI のインストールが行われます。

試しに Copilot CLI を起動してみます。

無事 Copilot CLI が起動しました!

実際に試してわかったこと
ブラウザ言語設定に応じた拡張機能も自動インストールされる
devcontainer.json に含めていないにもかかわらず、ブラウザが日本語設定だったため Japanese Language Pack が自動インストールされました。
言語パックを完全に制御したい場合は、devcontainer.json の settings で "locale": "en" を明示的に指定することで統一できます。

Copilot CLI のインストールには注意が必要
Dev Container 内で Copilot CLI を使おうとして、いくつかハマりポイントがありました。
gh copilot が使えない
当初、postCreateCommand に gh extension install github/gh-copilot を書いていましたが、2 つの問題に遭遇しました。
問題 1:exit code 127(コマンドが見つからない)
postCreateCommand from devcontainer.json failed with exit code 127.
Skipping any further user-provided commands.
ベースイメージ mcr.microsoft.com/devcontainers/typescript-node には gh(GitHub CLI)が含まれていないため、gh コマンド自体が見つからずに失敗します。
features で GitHub CLI を追加すれば gh は使えるようになりますが、次の問題が発生します。
問題 2:exit code 1(名前の衝突)
{
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
"postCreateCommand": "npm install && gh extension install github/gh-copilot"
}
"copilot" matches the name of a built-in command or alias
postCreateCommand from devcontainer.json failed with exit code 1.
gh CLI の新しいバージョンでは gh copilot がビルトインコマンドとして組み込まれたため、gh extension install github/gh-copilot を実行すると名前の衝突エラーになります。--force オプションを付けてもブロックされます。
背景:Copilot CLI は独立したツールに移行済み
現在の Copilot CLI は @github/copilot という独立した npm パッケージとして提供されており、gh CLI とは別のツールです。
公式リポジトリに記載されているインストール方法は以下の 4 つです。
| 方法 | コマンド |
|---|---|
| インストールスクリプト | curl -fsSL https://gh.io/copilot-install | bash |
| Homebrew | brew install copilot-cli |
| WinGet | winget install GitHub.Copilot |
| npm | npm install -g @github/copilot |
対処法:npm install -g @github/copilot を使う
Dev Container ではベースイメージに Node.js が入っているため、npm でのインストールがシンプルです。postCreateCommand に追加しておけば、コンテナ再ビルドのたびに自動でインストールされます。
{
"postCreateCommand": "npm install && npm install -g @github/copilot"
}
これにより、旧式で必要だった以下の設定がすべて不要になります。
featuresでの GitHub CLI の追加- ホストの gh 認証情報(
~/.config/gh)のマウント - コンテナ内での
gh auth login
コンテナのターミナルからローカルのターミナルを開きたいとき
Dev Containers で開いた VS Code のターミナルはコンテナ内に接続されます。ローカル(Mac)のターミナルを開きたい場合は、コマンドパレット(Cmd+Shift+P)で Terminal: Create New Terminal (Local) を実行するとローカル側のターミナルが起動します。
コンテナ内とローカルを行き来しながら作業するときに便利です。
おまけ:ローカルと Codespaces の使い分け
| ローカル VS Code | Codespaces | |
|---|---|---|
| 必要なもの | コンテナランタイム(Docker Desktop など) + 拡張機能 | ブラウザだけ |
| 起動速度 | 速い | やや遅い(クラウドビルド) |
| オフライン作業 | ✅ できる | ❌ できない |
devcontainer.json はローカルでも Codespaces でも共通で使えるため、まずローカルで試してから Codespaces に移行するという進め方もスムーズです。
Codespaces の詳細についてはこちらをご覧ください。
あらためてなぜ Dev Containers を使うのか考えた
Codespaces は devcontainer.json がなくても動きますが、その場合は GitHub が管理する汎用イメージがそのまま使われます。汎用イメージの中身を自分たちで変更することはできないため、拡張機能や Copilot の設定は個人任せになります。
devcontainer.json を書けば、ベースイメージ・拡張機能・エディタ設定・起動時のセットアップをリポジトリのコードとして管理でき、clone した瞬間から全員同じ環境で始められます。
まとめ
Dev Containers を試してみて、開発環境と Copilot の設定をリポジトリで管理できるのは素直に便利でした。新しいメンバーが clone してコンテナを起動するだけで同じ状態になり、Copilot の設定も個人任せにならずに済みます。
一方で、最初に挙げた懸念(通信の監視・未承認 MCP のブロック・証跡監査)は Dev Containers だけでは解決できません。これらは Codespaces の組織ポリシーと組み合わせて初めて実現できる部分です。
次回は Codespaces を使って組織レベルの統制まで実践してみます。








