GitHub Copilot のクラウドサンドボックス使ってみた
製造ビジネステクノロジー部の小林です。
2026 年 6 月 2 日に、GitHub Copilot にローカルサンドボックスとクラウドサンドボックスがパブリックプレビューとして追加されました。ローカルサンドボックスについては下記の記事で試してみました。
今回は、ずっと気になっていたクラウドサンドボックスを触ってみます。GitHub がホストする完全に隔離された Linux 環境の中で Copilot CLI セッションを走らせられる機能です。
クラウドサンドボックスとは
クラウドサンドボックスは、Copilot CLI のセッションを、手元のマシンではなく GitHub がホストする Linux 環境の中で動かすための実行基盤です。
実体は Azure Container Apps Sandboxes 上に構築されており、その上に GitHub が ID・ポリシー・課金の層を載せている構成です。ユーザー側で Azure サブスクリプションを用意したり、API キーを管理したり、インフラを立てたりする必要はありません。Copilot CLI の既存の認証がそのまま使えます。
クラウドサンドボックスのポリシーは Copilot Cloud agent（旧 Copilot coding agent）のポリシーと同じ設定を共有します。すでに Cloud agent 用のセキュリティ制御を組んでいる組織は、追加設定なしでクラウドサンドボックスにも同じルールが効きます。
ローカルとクラウドの使いどころの違い
ローカルサンドボックスに関する記事で触れたとおり、現時点のローカルサンドボックスの守備範囲は「Copilot が起動するシェルコマンド」に限られます。加えてローカルサンドボックスは、ローカル PC 上で動きますが、いくつか制限があります。
- 守れる範囲は「Copilot が実行するシェルコマンド」のみ
- macOS では、通信先ごとの許可・ブロック設定が使えないなど、OS ごとの制約もある
クラウドサンドボックスは、実行環境そのものをローカル PC から切り離します。GitHub 側の隔離された環境で動くため、上記のような手元パソコンの制約を気にする必要がなくなります。
どう使い分ける？
| ローカルサンドボックス | クラウドサンドボックス | |
|---|---|---|
| 向いている場面 | 軽い作業 | 本格的・自律的なタスク |
| 料金 | 追加料金なし | 従量課金あり |
| メリット | 手元のツールがそのまま使える | 手元の秘密情報には触れさせない。別のデバイスからでも同じセッションが引き継げる |
手軽にサッと作業したい → ローカル
安全性・デバイス間の引き継ぎが欲しい → クラウド
前提条件
クラウドサンドボックスを使うには次の 3 つが必要です。
- Copilot CLI をインストールし、サインインしていること
- 組織 / エンタープライズのオーナーが「Cloud Agent」を有効化していること
認証はローカルサンドボックスと同じで Copilot CLI の既存認証がそのまま使えます。組織側のポリシーが無効のままだと copilot --cloud を叩いても弾かれるので、組織管理者に事前確認しておくとよいでしょう。
クラウドサンドボックスを起動する
Copilot CLI に --cloud フラグを付けて起動するだけで、クラウド上の隔離環境で対話型セッションが立ち上がります。
copilot --cloud
Cloud のセッションが立ち上がりました。
表示された URL をクリックすると、クラウドの画面に移動します。
ローカル環境から Copilot に質問してみます。
すると、その内容がクラウド側の画面にもリアルタイムで反映されます。
起動後は、普段のローカルの Copilot CLI とまったく同じ感覚でプロンプトを与えられます。
違うのは、Copilot が実行するシェルコマンドがローカル環境ではなく、クラウド側の環境で走っているという点です。手元のシェルには実行結果や差分だけが返ってくる仕組みです。そのため、依存パッケージのインストールなどで手元の環境に影響を与えずに済むというメリットも得られます。
手元のファイルには触れない
クラウドサンドボックスの隔離性で気になるのは、「Copilot はローカル PC のファイルを覗けるのか」という点だと思います。結論から言うと、プロジェクト配下の .env や ~/.aws/credentials のような、手元の PC にしか無いファイルを Copilot がクラウド側から直接読み取ることはできません。
公式ドキュメントでも、クラウドサンドボックスの各セッションはローカル環境から完全に隔離されており、Copilot が実行するコマンドはクラウド側の環境で走ると明記されています。
セッションの中で Copilot が触れられるのは、クラウド側の隔離環境のファイルシステムだけです。手元にしかない設定ファイルやシークレットは、意図的に貼り付けたり持ち込んだりしない限り、クラウドサンドボックスの中には現れません。「秘密情報に触れさせたくないタスクを自律的に走らせたい」というユースケースに、この隔離モデルが直接効いてきます。
セッションのライフサイクル
クラウドサンドボックスのセッションは次の 3 つの状態を持ちます。
| 状態 | 説明 |
|---|---|
| Active | セッションが起動中で、Copilot CLI から操作できる状態 |
| Stopped | 実行は止まっているが、状態が保存されている状態。再開すると、ファイル・環境変数・作業中の内容がそのまま復元される |
| Deleted | セッションもスナップショットも削除され、復旧できない状態 |
セッションを停止（Stopped）すると、その時点のスナップショットが保存され、後で中断した場所から作業を再開できます。一方、削除（Deleted）すると、ランタイム環境とスナップショットの両方が消えてしまいます。
なお、この状態管理は後述する料金にも直結します。使い終わったセッションはこまめに削除（Deleted）まで持っていく運用にしておくのが基本です。
デバイスをまたいでセッションを引き継ぐ
クラウドサンドボックスのセッションは GitHub のインフラ側に生きているので、開始したデバイスと同じデバイスから再開する必要はありません。会社の PC で走らせ始めたセッションを、帰宅後に別マシンから続ける、といった使い方ができます。
料金
ローカルサンドボックスは Copilot シートに含まれているため追加料金は発生しませんが、クラウドサンドボックスは使用した分だけ課金されます（2026 年 7 月時点）。
課金対象は次の 3 つです。
| 項目 | 内容 | 単位 | 単価 |
|---|---|---|---|
| Compute | セッションが実行されている時間 | コンピュート秒 | 0.000024 USD |
| Memory | 実行中のセッションに割り当てられたメモリ | GiB 秒 | 0.000003 USD |
| Storage | 停止中セッションのスナップショット保存 | GiB 月 | 0.005 USD |
ポイントは、課金されるタイミングが状態によって異なることです。
- Compute と Memory は、セッションが Active な時間だけ発生し、Stopped にすれば止まります。
- Storage は、Stopped の間ずっと課金され続けます。
つまり、放置された Stopped セッションもストレージ料金がかかり続けるという点に注意が必要です。前述のとおり、使い終わったセッションはこまめに削除しておきましょう。
なお、実際に組織で運用する際は、必ず公式ドキュメントで最新の料金を確認してください。
おわりに
ローカルサンドボックスが「手元の作業に薄く一段ガードレールを足す」ものだとすれば、クラウドサンドボックスは「実行環境ごとクラウドに逃がして手元を守る」もの、という位置付けだと理解しました。日々の軽い作業はローカル、長時間の自律実行やシークレットに触らせたくないタスクはクラウド、といった使い分けができそうですね！
パブリックプレビュー中なので今後仕様も料金も動く可能性はありますが、Copilot CLI をエージェントとして本格的に運用へ載せていくうえで、利用を考えてもいいと思いました。
この記事がどなたかの参考になれば幸いです。
