2026 7 月、 GitHub Agentic Workflows は、サポートされているエージェント ランタイムとして Docker Sandboxes を追加しました。つまり、CI環境において、AIコーディングエージェントはDockerコンテナの実行など、環境を幅広く制御できる一方で、環境自体はマイクロVM内に隔離され、ネットワークポリシーとシークレットの注入によって、AIの隔離に関する現在のベストプラクティスに準拠した保護が提供されるということです。
有用なコーディングエージェントは、リポジトリを読み込んでパッチを提案する以上のことを行うため、エージェントの分離は重要です。彼らはツールをインストールし、任意のシェルコマンドを実行し、プロジェクトコードを実行し、データベースを起動し、そして時折、「クリーンアップ」という言葉の驚くべき新しい意味を発見する。これらの機能によってエージェントは有用となり、CIランナーへの直接アクセスが可能になることで、あらゆるミスの影響範囲が拡大する。
sbxが統合されたことで、エージェントの境界は使い捨ての環境となり、内部ではかなりの自由度を持ち、外部のすべてへのアクセスは制限されるようになった。
実際にどうなるかを確認するために、簡単な例を作ってみました。エージェントはGitHubでホストされているUbuntuランナー上で動作し、Dockerサンドボックス（sbx）に入り、Testcontainersを使用してPostgreSQLとのJava統合テストスイートを実行し、意図的に仕込まれたバグを見つけて修正し、ドラフトプルリクエストを作成します。GitHub Agentic Workflowsは、すぐに使える統合機能を提供しているため、アクションの設定にカスタム構成は一切必要ありません。
GitHub Agentic Workflowsとは何ですか？
GitHub Actionsは引き続きCIシステムとして使用されます。ジョブのスケジュール設定、Ubuntuランナーの提供、権限とシークレットの管理、および結果の記録を行います。
GitHub Agentic Workflows（通常はgh-awと略される）は、オープンソースのGitHub CLI拡張機能およびコンパイラです。あなたは、YAMLフロントマターで実行設定を記述し、本文でエージェントのタスクを記述する、エージェントのワークフローをMarkdownファイルで説明しています。gh aw compile実行すると、そのソースコードが.lock.ymlという拡張子が付いた従来のGitHub Actionsワークフローに変換されます。
その関係性は次のようになります。
Markdown workflow
|
| gh aw compile
v
Generated GitHub Actions .lock.yml
|
| runs on ubuntu-24.04
v
Docker Sandbox microVM
|
v
Copilot agent and its tools
docker-sbx gh-awのエージェントランタイム構成に属します。runs-onフィールドは依然としてubuntu- 24 . 04を選択し、コンパイルされたファイルは標準的な GitHub Actions ワークフローです。サンドボックスツールをインストールし、認証を行い、ランナーをチェックし、サンドボックス内でエージェントを起動し、その後すべてをクリーンアップします。
その統合はgh-awに取り込まれ、バージョン0 . 82 . 9でリリースされました。
GitHub Actionsでsbxを設定する
以下はサンプルに含まれるsandbox-explorer.mdからの設定です。
---
name: "Docker Sandboxes sample: exploratory test"
on:
workflow_dispatch:
runs-on: ubuntu-24.04
permissions:
contents: read
copilot-requests: write
engine: copilot
network:
allowed:
- defaults
- github
- containers
- java
sandbox:
agent:
id: awf
runtime: docker-sbx
sudo: true
tools:
edit:
bash: [":*"]
safe-outputs:
create-pull-request:
title-prefix: "[docker-sbx sample] "
draft: true
protected-files: blocked
allowed-files:
- "src/**"
---
sandbox.agentの下にある3行は、Docker Sandboxランタイムを選択します。内部では、エージェントはアプリケーションを構築し、テストインフラストラクチャを起動するために必要なsudo権限と無制限のシェルアクセス権を持っている。
サンドボックスの外では、ワークフローの対象範囲ははるかに小さくなります。そのnetworkブロックの許可リストには、このジョブに必要な宛先が指定されており、エージェントのGitHubトークンはリポジトリの内容を読み取り、Copilotにリクエストを送信できます。プルリクエストの作成は、パッチにsrc/**以下のファイルのみが含まれる別の安全な出力ジョブで行われます。
CIエージェントにどの程度の裁量権を与えるべきかは、その職務内容によって異なる。この場合、分割は有効です。サンドボックス内では広範なシェルアクセスが可能で、サンドボックス外では小規模なネットワークとリポジトリへのアクセスが可能、そして人間のレビューを待つドラフトのプルリクエストとなります。
分離境界はマイクロVMです
「Docker」というと単一のアプリケーションコンテナを連想しがちですが、この構成では実際にはマイクロVMを主要な分離境界として使用しています。
sbxでは、すべてのサンドボックスは専用の環境であり、独自のカーネル、ファイルシステム、ネットワークスタックを備えています。最も重要な点は、独自のプライベートなDockerデーモンを実行していることです。これは、エージェントがホストのDockerデーモンを制御することなく、VM内で完全なルート権限を取得することを意味します。両者をつなぐ唯一の架け橋は、リポジトリの明示的な共有ワークスペースである。
プライベートデーモンを持つことは、統合テストにおいて画期的な変化をもたらします。このデモでは、開発者がローカルマシンで実行する場合とまったく同じように、アプリがTestcontainersを実行します。結果として得られる構造は次のようになります。
GitHub Actions runner
└── Docker Sandbox microVM
├── GitHub Agentic Workflows agent
└── Private Docker daemon
├── Maven / Java 21 container
└── PostgreSQL Testcontainers container
環境をクリーンに保つため、テストランチャーは固定コンテナ内でMavenを実行し、サンドボックスのDockerソケットをそのまま渡してプライベートデーモンと通信できるようにします。
docker run --rm \
--add-host=host.testcontainers.internal:host-gateway \
-e TESTCONTAINERS_HOST_OVERRIDE=host.testcontainers.internal \
-v "$PWD:/workspace" \
-w /workspace \
-v /var/run/docker.sock:/var/run/docker.sock \
maven:3.9.9-eclipse-temurin-21@sha256:3a4ab3276a087bf276f79cae96b1af04f53731bec53fb2e651aca79e4b10211e \
mvn --batch-mode "$@" test
Testcontainersは、そのソケットを使用してPostgreSQLデータベースを起動します。まるで多くのレイヤーがあるように聞こえます。ビルドを実行するコンテナが別のコンテナを起動し、それらすべてがCIランナー上のマイクロVM内で実行されますが、各レイヤーはエージェントが隔離された状態を維持しつつ、完全な機能を発揮できるようにするための特定の目的を果たします。
エージェントに発見する価値のある欠陥を与える
このサンプルは、小規模なJava 21登録サービスです。その要件によると、メールアドレスは大文字と小文字を区別しないとのことです。標準実装では、提供されたとおりにデータを保存し、PostgreSQLの大文字小文字を区別する一意制約に依存しています。既存のTestcontainers統合テストは、完全な重複を検出するが、後者のケースについては何も言及しない。
ワークフローのMarkdown部分では、エージェントに対し、要件とコードを検査し、ベースラインスイートを実行し、大文字小文字のみが異なる2つのアドレスに対するテストを追加するよう指示します。不変条件が満たされない場合、エージェントは最小限のソース補正を行うべきである。アプリケーションに手を加える前に、 uname 、Dockerバージョン、Docker情報、および小さなAlpineコンテナの実行を記録し、ワークフローログに作業が実行された場所に関する具体的な証拠を残します。
タスク自体は、yamlファイルのフロントマターの下に記述された、ごく普通のMarkdownです。（デバッグのために環境を記録するコマンドをいくつか実行した後）私たちにとって重要な部分は次のとおりです。
Act as a bounded exploratory tester for this repository.
...
Then:
1. Read `REQUIREMENTS.md` and the relevant source and test files.
2. Run `./scripts/test-in-docker.sh` without changing anything.
3. Add a PostgreSQL Testcontainers test that checks registration of two
addresses that differ only in letter case.
4. Run the focused test and explain the observed behavior.
5. If the implementation violates the documented invariant, make the
smallest fix under `src/`.
6. Run the complete test suite again.
7. Create one draft pull request containing the regression test and fix.
そして、正しい行動を促すためのプロンプトレベルのガードレール：
Do not modify dependency manifests, workflow files, scripts, documentation,
or generated files. Do not weaken or delete existing tests. Include the
commands run and their results in the pull request description.
実際の実行も当然その通りの経過をたどりました。ベースラインテストは合格しましたが、新しいケースバリエーションテストは失敗しました。
expected: <false> but was: <true>
エージェントはメールを挿入する前に正規化し、テストスイート全体を再実行した結果、2つの統合テストに合格した。
ログには、 defaultコンテキストでDockerクライアントとサーバーのバージョン29 . 7 . 1が報告されました。これは、現在sbxのデフォルトサンドボックステンプレートで使用されている正しいDockerバージョンです。これはサンドボックスのプライベートデーモンであり、Testcontainersライブラリが統合テストのためにPostgreSQLを起動する際に使用した唯一のデーモンです。
完全なワークフローは、GitHub がホストするubuntu- 24 . 04上で実行されました。ランナー。の 走る 所要時間は11分16秒でした。
すると、safe-output ジョブによって、 src/**の下に正確に 2 つのファイルを含むドラフト PR が開かれました。それは、回帰テストと 1 行の正規化修正です。ワークフロー構成、スクリプト、依存関係、およびドキュメントは、パッチ適用範囲外でした。
生成された ドラフトプルリクエスト 宣言されたソース専用境界内に留まった。
ワークフローを自分で実行する
まず、 gh-awをインストールしてください。
gh extension install github/gh-aw
コンパイル済みのDocker Sandboxランタイムは、認証を行い、サンドボックステンプレートを取得するためにDockerの認証情報を必要とします。サンプルリポジトリの 「設定」>「シークレットと変数」>「アクション」 に DOCKER_USERNAME と DOCKER_PAT を追加するか、GitHub CLIに両方の値の入力を求めるようにします。
gh secret set DOCKER_USERNAME
gh secret set DOCKER_PAT
リポジトリのCopilot権限とcopilot-requests: write権限は、サンプルが正常に動作するのに十分でした。その権限を持たないリポジトリはgh-awによって文書化されているように、サポートされているCOPILOT_GITHUB_TOKENシークレットを使用できます。
また、リポジトリのアクション設定で、 「GitHub Actionsがプルリクエストを作成および承認することを許可する」を有効にしてください。次に、Markdownソースをコンパイルし、ソースと生成されたワークフローの両方をコミットします。
gh aw compile sandbox-explorer
git add .github/workflows/sandbox-explorer.md \
.github/workflows/sandbox-explorer.lock.yml
git commit -m "Compile Docker Sandboxes sample workflow"
git push
.lock.ymlは生成されたコードです。変更はMarkdownソースコードに直接行い、その後再度コンパイルする必要があります。
最後に、ワークフローを開始してその様子を確認してください。
gh aw run sandbox-explorer
gh run watch
このサンプルは、GitHubでホストされているubuntu- 24 . 04上で動作します。ランナーは約束通り。自己ホスト型のLinuxランナーには、適切なKVM対応環境に加え、Dockerサンドボックスに必要なDockerおよびシステムアクセスが必要です。
ノートパソコンでsbxを試してみてください
CI環境でエージェントを分離する機能は素晴らしいですが、Docker Sandboxを理解する最も簡単な方法は、ローカルプロジェクト上のエージェントを囲むようにDocker Sandboxを配置することです。お使いのプラットフォームのDockerサンドボックス設定手順に従い、サインインしてリポジトリに移動し、インストール済みのエージェントを実行します。
sbx login
cd ~/my-project
sbx run <claude|codex|opencode>
テストの実行、イメージのビルド、Testcontainersの依存関係の開始など、実際のツールを必要とするタスクを与えてください。sbx 、ワークロードが実際の開発ループである場合に、評価や理解がはるかに容易になります。
そして、もし実験が組織全体へのエージェント展開へと発展するならば、次に検討すべきはDocker AIガバナンスです。サンドボックスネットワーク、ファイルシステム、およびMCPへのアクセスに関して、組織およびチームのポリシーを適用し、ポリシーの決定事項を監査ログに記録します。これらの記録は、 sbxを含む送信元クライアントとマシンホスト名を特定するのに役立つため、同じポリシーと監査モデルでチームのラップトップと CI ランナーを簡単にカバーできます。
