GitHub Copilot Coding Agentをself-hosted runnerで動かす
GitHub UniverseでGitHub Coding Agentをself-hosted runnerで動かせるようになったという発表がありました。
coding agentはその性質上、ちょっと複雑なタスクをお願いすると10分以上は動き続けることが多いので、GitHub Actionsの料金がちょっと心配という方も多かったのではないのでしょうか。というわけでself-hosted runnerの上で動かせるようになるのは嬉しいニュースではあったのですが、このchangelogを見てみるとActions Runner Controllerを使っている例しか書かれていませんでした。
更新されたドキュメントも見てみますが、やはりActions Runner Controllerを使う方法しか書かれていません。
しかもセクションのタイトルにバッチリ with ARC と書かれていたりして、もしかしてARC上のself-hosted runnerでしか動かせないのか・・・？という不安がよぎりました。
ドキュメントの魚拓代わりのスクショ
これはもう試してみる方が手っ取り早いので試してみました。結論から言うと、普通にself-hosted runnerで動かすことができました。
ただしCoding AgentのFirewallの設定はオフにする必要があるので、通常のCoding Agentの使い方よりはセキュリティが緩くなることには注意が必要です。
self-hosted runnerの準備
自分は最も手軽にself-hosted runnerを動かせる https://github.com/organizations/YOUR-ORG/settings/actions/runners/new からコマンドをぽちぽちコピペしてLinuxのself-hosted runnerをセットアップしました。
環境は自分のWindowsのWSL2で直接動かしてしまいましたが、coding agentのセットアップコマンドやcoding agentが実行するコマンドによってマシンの環境が破壊される可能性もあるので、できればdockerなどの隔離された環境で動かすことをオススメします。
（自分はどうせ動くか動かないかは50/50ぐらいだと思っていて慢心していたので雑に試しすぎました）
Coding Agentのセットアップ
このドキュメントに書かれているように、coding agentの環境をセットアップするためのジョブを定義している .github/workflows/copilot-setup-steps.yml の copilot-setup-steps ジョブの runs-on を変更します。
self-hosted runnerのラベルを指定すればよいので、最も雑に設定する場合は runs-on: self-hosted とするだけです。自分はこれで動きました。
jobs:
copilot-setup-steps:
runs-on: self-hosted
Coding AgentのFirewallをオフにする
The Copilot coding agent native firewall is not compatible with self-hosted runners. To use Copilot coding agent with self-hosted runners, you will need to disable the firewall in the repository's coding agent settings.
と書かれている通り、Firewallをオフにしてください。オフにし忘れた場合、このようにエラーになります。
Firewallをオフしないとエラーになる
（自分は最初見落としていて、この地雷を踏み抜きました・・・）
Coding Agentの起動
あとは通常通りCoding Agentを起動すると、自分のself-hosted runner上でCoding Agentが動き始めます。self-hosted runnerのログを見てみると、 copilot というジョブがcoding agentのジョブとして実行されているようでした。
$ ./run.sh
√ Connected to GitHub
Current runner version: '2.329.0'
2025-10-29 13:00:19Z: Listening for Jobs
# copilot-setup-steps は先ほどの copilot-setup-steps.yml をコミットしたときに実行されたジョブ
2025-10-29 13:03:54Z: Running job: copilot-setup-steps
2025-10-29 13:06:06Z: Job copilot-setup-steps completed with result: Succeeded
2025-10-29 13:06:09Z: Running job: copilot-setup-steps
2025-10-29 13:07:28Z: Job copilot-setup-steps completed with result: Succeeded
2025-10-29 13:07:42Z: Running job: copilot-setup-steps
2025-10-29 13:09:20Z: Job copilot-setup-steps completed with result: Succeeded
# copilot ジョブがcoding agentとして動いている
# 初回はFirewallをオンのままにしていたため失敗している
2025-10-29 13:09:24Z: Running job: copilot
2025-10-29 13:09:34Z: Job copilot completed with result: Failed
# Firewallをオフにして再度実行してcoding agentが無事に完走した
2025-10-29 13:12:16Z: Running job: copilot
2025-10-29 13:45:53Z: Job copilot completed with result: Succeeded
こちらがCoding Agentのセッションログ。今までのGitHub Hosted runner上で動かしていたときと特に違いはありませんでした。
self-hosted runner上で動いたCoding Agent。動作に遜色はなさそう
ということで、ARCを使わない通常のself-hosted runnerでも問題なくGitHub Coding Agentを動かせることが確認できました。
Coding Agentをself-hosted runnerで動かす必要があるのか？
できることは分かりましたが、self-hosted runnerで動かす必要があるのか？という点は人によって意見が分かれそうです。とはいえ、会社の事情などでどうしてもself-hosted runnerで動かす必要がある場合などは嬉しいアップデートなのは間違いないでしょう。
メリット
- GitHub Actionsの利用料金を節約できる可能性がある
- 一般的にself-hosted runnerの方が時間当たりのコストは安価にできることが多い
- 特殊なネットワーク要件に対応できる
- 例えば社内ネットワークからしかアクセスできないリポジトリやサービスにCoding Agentがアクセスする必要など
デメリット
- スケール性が確保しにくいのでCoding Agentの並列性のメリットがスポイルされる
- 今回の記事のように最もシンプルな方法でself-hosted runnerを動かす場合、1台のマシンで1つのCoding Agentしか同時に動かせないため
- ARCなどを使ってself-hosted runnerをスケールアウト可能な基盤を運用している場合はもちろん問題ない
- Coding Agentの安全装置であるFirewallをオフにする必要がある
- Coding Agentはパッケージレジストリなど一部許可されたサービス以外はデフォルトでアクセス禁止であり、ローカルで動かす各種エージェントツールよりも安全に倒されている
- それをオフにするのでセキュリティ的にはやや不安が残ります[1]
- self-hosted runnerの環境が独立していない場合、前のCoding Agentのセッションの影響を受ける可能性がある
- これはGitHub Actionsでのself-hosted runnerの問題と同じ
- ephemeral runnerとして動かし、セッションごとにself-hosted runnerを動かしているVMやコンテナを破棄してまっさらに作り直す運用が望ましい
self-hosted runnerなので当たり前ですが、GitHub Actionsにおけるself-hosted runnerと同じ運用の難しさが見えてきます。既にGitHub Actionsように運用基盤を整えているところでは利用検討の価値があると思いますが、そうでない場合はあえてself-hosted runnerで動かすメリットはあまり大きくないかもしれません。
-
AIを騙すための悪意あるプロンプトをwebサイトに仕込むプロンプトインジェクションという攻撃が知られています。人間の許可なしに任意の外部webサイトにAIがアクセスすることは今後高リスクになる可能性があります ↩︎
Discussion