おそらくはそれさえも平凡な日々

fence - AI AgentをOSサンドボックスの中で動かす

AI Agentも賢くなってきたとはいえ、ローカルで何をしでかすかわからない怖さは拭いきれない。かと言って、細かく認可を与えるのもめんどいし、ザルな見過ごしも起こりやすくなって危ないので、できればファイル・ネットワークアクセス、コマンド実行等に適切に制限をかけたサンドボックス環境で放し飼いにしたい。

CLIとして動かすAI Agentの場合、引数に指定したコマンドをサンドボックス内で動かすコマンドラッパーがあると嬉しい。自作しようかと思っていたが fence というツールがまさしくそれだったので、これを使うことにした。Goで書かれていて、macOSとLinuxをサポートしている。早速、GitHub Copilot CLIでも利用しやすいようにpull requestを送って、取り込んでもらった。

使い方

使い方は簡単で fence コマンドの引数にサンドボックス内で動かしたいコマンド、今回のユースケースであればAI AgentのCLIを指定するだけだ。

$ fence copilot
$ fence claude

ただ、最初は外部へのネットワークアクセスが遮断されているので最低限の設定ファイルは必要だ。これも簡単で、fence config init とすれば ~/.config/fence/fence.json に初期設定を書き込んでくれる。初期設定は以下のように簡素だ。

// Starter config generated by `fence config init`; this file extends "code".
// Rules from "code" are inherited and not shown below.
// Add your project-specific overrides in this file.
// Run `fence --list-templates` to see available templates.
// Configuration reference: https://github.com/Use-Tusk/fence/blob/main/docs/configuration.md
{
  "extends": "code"
}

これは、code というCoding Agent用のビルトインテンプレートを継承している。このテンプレートの中身は以下から参照可能だ。特定のAI関係のドメインのみにアクセス許可を与え、ローカルの秘匿ファイルへのアクセスや git push などのコマンドは拒否するようになっている。実際の項目ごとの設定内容は fence config show で確認できる。ここから適宜調整すると良いでしょう。

https://github.com/Use-Tusk/fence/blob/main/internal/templates/code.json

動作確認とデバッグログ

fence の中でAI Agentを動かしていると、ファイルやサイトアクセスのブロック起因で意図しない挙動になることがある。それを確認するために、--monitor--debug オプションをつけて起動すると、モニターログが出力され、実際にブロックされたファイルやサイトを確認できる。ログは標準エラー出力に出るので、ファイルにリダイレクトして、tail で確認するとよいでしょう。ブロック状況を確認して、必要に応じて許可設定を追加すると良いでしょう。

$ fence --debug --monitor -- copilot 2>> .fence-monitor.log
$ tail -f .fence-monitor.log

Appendix

同種のソフトウェア

  • srt (3.7k stars): Anthropic社が開発しているTypeScript製のサンドボックスツール。ライブラリとしてClaude Code内部でも使われている
  • nono (1.8k stars): Rust製のサンドボックスツール
  • cage (100 stars): 日本の方が作られたGo製のツールで日本の技術記事での事例紹介が散見される。ファイルシステムのサンドボックス化のみ提供

fence は600 starsなので、srtやnonoほどではないが、十分に信用がおけると判断し、Go製であることが私にとっては好ましいので採用することにした。

ちなみに、もともとはcageの存在だけ認識していて、そのネットワーク版を作ろうと思ってプロキシ設計までやっていたのだけど、調べたら同種のソフトウェアが流石にあるということが分かったのでそれに乗ることにしたというのがある。ラッパーコマンド自身がプロキシになってそれ経由の通信しか通さなくするというアーキテクチャは面白いので作ってみたかったが、こういうツールは既存の成熟したものを使う方が安心。

いずれのツールでもmacOSではApple SeatbeltというOS組み込みのサンドボックスを使っている。非推奨な機能らしいが、CLIでは代替手段が提供されてておらず、多くのツール内で使われているため、もはや廃止は難しそうになっているようだ。

Linuxではsrtとfenceはbubblewrap, nonoとcageはLandlockを使っている。

この辺りは以下の記事が参考になります。

Claude Code組み込みのサンドボックス機能を使えばよいのでは?

これまでの説明どおり、内部的には同様のことをしているのでそれで良いと思います。まあ、こういうのは別の専用のツールに分かれていた方が責務分離的に安心だし、細かい設定も可能だというのはあるでしょう。

というより、私が主に使っているGitHub Copilot CLIがまだサンドボックス機能が無いので、使っているというのが現実でもあります…。Copilot CLIのissueでも実装も望まれているので、そのうち機能追加されるとは思いますが、早めの対応を期待したいところです。

Add sandbox mode to restrict Copilot CLI file access to a specified working directory · Issue #892 · github/copilot-cli

created at
last modified at

2026-04-11T21:20:47+0900

comments powered by Disqus