GitHub Codespaces の組織設定とポリシーを一から構築してみた

製造ビジネステクノロジー部の小林です。

前回の記事「GitHub Copilot をチームで安全に使うために Dev Containers を試してみた」では、Dev Containers を使って開発環境と Copilot の設定をコードで統一する方法を紹介しました。
その中で、GitHub Copilot や MCP サーバーをチームで使う上での 3 つの懸念を挙げています。

1. コードが外部に漏洩しないか
2. メンバーが未承認の MCP サーバーを使い始めたらどうするか
3. 誰がいつどこに通信したか把握できるか

Dev Containers はローカル環境での統一には有効ですが、あくまでローカルの Docker で動く仕組みです。組織としてセキュリティ統制を強化したい場合、クラウド側で環境を管理できる GitHub Codespaces の導入を検討する価値があります。

今回は Codespaces の組織設定・ポリシー・実際に使ってみるところまで試してみました。

前提

今回は、GitHub Team プラン（$4/月）を利用します。

GitHub Codespaces とは

GitHub Codespaces は、GitHub が提供するクラウドベースの開発環境です。ブラウザ上で VS Code のようなエディタが起動し、リポジトリのクローンや開発環境のセットアップを自動で行ってくれます。

https://docs.github.com/ja/codespaces/overview

ローカルマシンの環境に影響を与えずに開発できるのはもちろん、チームメンバー全員が同じ開発環境を使えるという点が大きなメリットです。devcontainer.jsonを使って環境を定義すれば、「自分の環境では動くのに…」という問題を解消できます。

Codespaces を使うと嬉しいこと

ブラウザだけで開発を始められる

ローカルに Docker、Node.js、Python などをインストールする必要がありません。ブラウザでリポジトリを開いて Codespace を作成するだけで、数分で開発を開始できます。

開発環境がコードで管理される

devcontainer.jsonをリポジトリに含めることで、開発環境自体がバージョン管理の対象になります。「自分の PC では動くのに」が起きにくくなり、Mac・Windows 混在のチームでもコンテナ内では全員同じ Linux 環境です。

組織レベルでのセキュリティ統制ができる

これが Dev Containers と異なるポイントです。Codespaces の組織管理機能（Team プランまたは Enterprise Cloud プランで利用可能）を使えば、利用できるマシンタイプの制限、ベースイメージの制限、アイドルタイムアウトの強制などを組織の管理者が一元管理できます。

マシンスペックに依存しない

重い処理を実行する際も、クラウド上の高スペックなマシンを利用できます。ローカルマシンのスペックが低くても、Codespace のマシンタイプを上げれば快適に開発できます。

なぜ Dev Containers だけでなく Codespaces が必要なのか

前回試した Dev Containers は、ローカルの Docker で動くため環境統一には有効です。しかし、組織としてセキュリティを担保するには以下の限界があります。

• 組織ポリシーを強制できない — マシンタイプの制限や idle timeout の強制はローカル環境では不可能
• イメージの制限ができない — ローカルでは任意の Docker イメージを使えてしまう

これらは Codespaces の組織管理機能（Team プランまたは Enterprise Cloud プランで利用可能）で対応できます。

さらに、GitHub Enterprise Cloud プランを利用すれば、Codespaces とは別のエンタープライズレベルの機能として以下も利用可能です。

• ネットワーク制御 — IP allow list や outbound network policy による外部通信先の制限
• 監査ログ — 誰がいつ何をしたかの証跡を GitHub 側で管理

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/reviewing-your-organizations-audit-logs-for-github-codespaces

料金について

個人アカウントの Free・Pro プランには、毎月一定の無料枠が含まれています。組織アカウントの場合は使用量に応じた従量課金となり、コンピューティング時間とストレージの 2 種類の料金が発生します。

https://docs.github.com/ja/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces/about-billing-for-github-codespaces

利用可能なプラン

Codespaces は GitHub Free、GitHub Team、GitHub Enterprise Cloud のいずれのプランでも利用できます。Team プランと Enterprise Cloud プランでは、Organization owner がプライベート/内部リポジトリでの Codespaces 利用を有効・無効に切り替えたり、利用料金を組織負担にするかユーザー負担にするかを管理できます。

https://docs.github.com/ja/get-started/learning-about-github/githubs-plans
https://docs.github.com/ja/enterprise-cloud@latest/admin/overview/setting-up-a-trial-of-github-enterprise

組織での Codespaces 設定

GitHub Organization の管理者として、Codespaces を利用可能にするための設定を行います。

Organization の Settings → Codespaces から設定画面にアクセスします。

コードスペースへのアクセス

まず、誰が Codespaces を利用できるかを設定します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/enabling-or-disabling-github-codespaces-for-your-organization

以下の 4 つの選択肢があります。

今回の検証では「Enable for specific members or teams」を選択し、検証用に個人アカウントを利用可能にしました。

設定を選択したら「Save」をクリックします。

Codespace の所有権

次に、Codespace の所有権を設定します。これは課金先やポリシーの適用に影響する重要な設定です。セキュリティ統制の観点では、「Organization ownership」を選ぶことで、組織ポリシーの適用・コスト管理を一元化できます。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/choosing-who-owns-and-pays-for-codespaces-in-your-organization

組織として利用料金を管理したい場合は「Organization ownership」を選択します。今回は「Organization ownership」を選択します。

アクセスとセキュリティ（非推奨）

この設定は現在「Deprecated(非推奨)」のラベルが付いています。Codespaces が他のリポジトリにアクセスできる範囲を制御する旧来の仕組みです。

特別な理由がなければ「Disabled」のままで問題ありません。
なお、この設定が「Disabled」であっても、devcontainer.json の customizations.codespaces.repositories で個別に権限を設定すれば、他のリポジトリへのアクセスは可能です。こちらが現在の推奨方法です。

https://docs.github.com/ja/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces

Codespaces policies

ポリシーは、組織内のリポジトリに対して Codespaces の利用ルールを定義する仕組みです。ポリシーの対象は組織に課金される Codespaces に限られ、ユーザー個人に課金される Codespaces（外部ユーザーがパブリックリポジトリから作成した場合など）には適用されません。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/managing-the-cost-of-github-codespaces-in-your-organization

初期状態ではポリシーは設定されていません。「Create Policy」ボタンからポリシーを新規作成できます。

ポリシーの作成画面

「Create Policy」をクリックすると、ポリシー作成画面が表示されます。設定する項目は以下の 3 つです。

• Policy name：ポリシーの名前（例：test-policy）
• Constraints：制約の追加（後述）
• Change policy target：ポリシーの適用範囲。「All repositories」で組織内の全リポジトリに適用するか、特定のリポジトリを選択して適用するかを選べる

Constraints（制約）の種類

「Add constraint」ドロップダウンから、以下の 6 種類の制約を追加できます。各制約は編集アイコンをクリックすると設定値を変更でき、ゴミ箱アイコンで削除できます。

1. Machine types

リポジトリの Codespaces が利用できるマシンタイプを制限します。チェックボックスで許可するマシンタイプを選択します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-access-to-machine-types

選択可能なマシンタイプは以下の 4 種類です。

コア数が増えるほどコンピューティング料金も比例して高くなります。複数のマシンタイプにチェックを入れた場合、ユーザーは Codespace 作成時にチェックされたマシンタイプの中から選択できます。チェックを外したマシンタイプは選択肢に表示されません。今回は「2-core」のみを選択します。

2. Port privacy settings

ポートフォワーディング時の公開範囲を制限します。Codespace 内のアプリケーションを外部からアクセス可能にする際、誰にアクセスを許可するかを制限します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-the-visibility-of-forwarded-ports

セキュリティ要件に応じて、「Org」のみにチェックを入れ、「Public」を外すことで、Codespace 内のアプリケーションの公開範囲を組織内に限定できます。

3. Maximum idle timeout

Codespace がアイドル状態（操作がない状態）で自動停止するまでの最大時間を分単位で設定します。テキストフィールドに数値を入力し、「Apply」をクリックして適用します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-the-idle-timeout-period

例えばデフォルトの 240 分（4 時間）のままだと、昼休みに席を外してそのまま忘れた場合でも 4 時間分のコンピューティング料金が発生します。30〜60 分程度に設定しておくと、うっかり放置による無駄な課金を防げます。

今回は 60 分に設定します。

4. Maximum retention period

普段使っている Codespace は接続するたびにカウントダウンがリセットされるため、自動削除されることはありません。この設定が利くのは、試しに作って使わなくなった、ブランチの作業が終わったのに削除し忘れた、といった放置された Codespace の自動掃除です。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-the-retention-period-for-codespaces

デフォルトの 30 日でも運用上は問題ありませんが、放置 Codespace によるストレージコストを早めに抑えたい場合は短縮を検討しましょう。チームの休暇パターンや開発サイクルに合わせて調整してください。

なお、削除されるとコンテナ内のすべて（未 push の commit や作業中のファイル含む）が失われます。push 済みのコードには影響がありません。

今回は 30 日で設定します。

5. Base images

Codespaces で使用できるベースイメージを制限します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-the-base-image-for-codespaces

テキストフィールドにイメージ URL を入力し、「+」ボタンで追加します。ワイルドカード（*）をサポートしており、例えば以下のように設定できます。

• mcr.microsoft.com/devcontainers/* — Microsoft 公式の Dev Container イメージのみ許可
• ghcr.io/my-org/* — 自組織の GitHub Container Registry にあるイメージのみ許可

組織で検証・承認済みのイメージのみに制限することで、未知のイメージに起因する脆弱性リスクを低減できます。

今回はmcr.microsoft.com/devcontainers/* を利用します。

6. Maximum codespaces per user

ユーザーあたりが同時に保持できる Codespaces の最大数を設定します。テキストフィールドに数値を入力し、「Apply」で適用します。

https://docs.github.com/ja/codespaces/managing-codespaces-for-your-organization/restricting-the-number-of-organization-billed-codespaces-a-user-can-create

この制限はポリシーオーナー（組織）に課金される Codespaces が対象です。適切な数はチームの開発スタイル（1 リポジトリ集中型か、複数リポジトリ並行かなど）によって異なるため、実際の利用状況を見ながら調整するのがよいでしょう。

今回は 1 を設定します。

7. Change policy target

ポリシーの適用範囲を設定します。

例えば、全リポジトリ向けの基本ポリシー（2-core/4-core のみ許可）を「All repositories」で作成し、特定の重いプロジェクト向けに 8-core 以上を許可するポリシーを「Selected repositories」で別途作成する、といった運用ができます。

補足

「Maximum codespaces per user」制約を含むポリシーは「Selected repositories」がグレーアウトされ選択できません。

これは、この制約が「ユーザーが組織全体で持てる Codespaces の合計数」を制限するものだからです。もし特定のリポジトリだけに適用できてしまうと、対象外のリポジトリでは制限なしで Codespaces を作り放題になり、ユーザーあたりの総数制限という目的が達成できなくなります。そのため「All repositories」のみに適用される仕様になっています。

以上でポリシーの設定が完了しました。

ポリシーのまとめ

ポリシーは複数作成できるので、全リポジトリ向けの基本ポリシーと、特定の重いプロジェクト向けに高スペックを許可するポリシーを分けて運用する方法ができます。

Codespace を起動してみる

設定が完了したら、実際に Codespace を起動してみましょう。

起動方法

GitHub でリポジトリのページを開き「Code」ボタンをクリックし「Codespaces」タブを選択 し「Create codespace on main」をクリックします。

数十秒〜数分でブラウザ上に VS Code のようなエディタが起動します。ターミナルも使えるので、すぐに開発を始められます。

devcontainer.jsonをまだ用意していないリポジトリでも、GitHub がデフォルトの Ubuntu イメージで環境を自動構築してくれるため、問題なく起動できます。

ターミナルに npm run build の失敗のエラーが表示されていますが、これはプロジェクト固有のビルド設定がデフォルト環境に合っていないだけで、Codespace 自体の起動には問題ありません。

補足

今回のケースでは、buildスクリプトがtsc（TypeScript コンパイラ）を実行しますが、typescriptはdevDependenciesにあるためnpm installが先に走らないと使えません。

{
  "name": "sample-api",
  "version": "0.1.0",
  "bin": {
    "sample-api": "bin/sample-api.js"
  },
  "scripts": {
    "build": "tsc",   ← コレ
    "watch": "tsc -w",
    "test": "jest",
    "cdk": "cdk"
  },
  "devDependencies": {
    "@types/aws-lambda": "^8.10.161",
    "@types/jest": "^29.5.14",
    "@types/node": "22.7.9",
    "aws-cdk": "2.1031.0",
    "esbuild": "^0.27.4",
    "jest": "^29.7.0",
    "ts-jest": "^29.2.5",
    "ts-node": "^10.9.2",
    "typescript": "~5.6.3"
  },
  "dependencies": {
    "@aws-sdk/client-dynamodb": "^3.1012.0",
    "@aws-sdk/lib-dynamodb": "^3.1012.0",
    "aws-cdk-lib": "2.215.0",
    "constructs": "^10.5.1"
  }
}

デフォルト環境には TypeScript がグローバルインストールされていないので、tscが見つからず失敗しています。npm install後にnpm run buildを実行すれば通ります。こうした環境の差異は、devcontainer.jsonのカスタマイズで解消できます。

まとめ

今回は、GitHub Codespaces の組織設定・ポリシーについて、一から設定し、Codespace の起動までをまとめました。次回はdevcontainer.jsonを使った開発環境のカスタマイズについて試してみます。
この記事がどなたかの参考になれば幸いです。

おまけ Codespace 内で Copilot CLI を実行してみたら

Codespace のターミナルでcopilotコマンドを実行すると、GitHub Copilot CLI の UI が表示されます。デフォルト環境にプリインストールされていました。

しかし、組織で Copilot のポリシーが有効になっていない場合は、以下のエラーが表示されます。

✗ You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled.

Copilot CLI のコマンド自体はインストールされていますが、利用には組織の Copilot ポリシーの有効化が必要という動作です。UI が表示されるので一見使えそうに見えますが、ライセンスがなければ機能しないのでご注意ください。