最近、AIエージェント（OpenAI Codex CLIなど）を使ってコーディング作業を効率化しています。
これまでは専用のSSH接続端末で使っていたのですが、メインPCでも使えたら便利だなと思うようになりました。
ただ、AIエージェントによる予期しない破壊的変更が心配です。
プロジェクトのコードはGitで管理しているので、最悪そこは復元できます。
しかし、開発環境そのもの――つまり、メインPCのファイルシステムやシステム設定――が不用意に書き換えられてしまうリスクは無視できません。
そこで、Dockerを使ってアクセス範囲を制限する方法を検討したのですが、最終的にはVM（仮想マシン）を使う方が安全だという結論に至りました。
1. AIエージェントの何が心配なのか
AIエージェントは便利です。
コードを書いてくれるし、デバッグもしてくれます。
でも、AIは予測困難な動作をすることがあります。
たとえば、「このプロジェクトを整理して」と指示したとき、意図せず重要なファイルを削除してしまうかもしれません。
あるいは、システム設定ファイルを書き換えてしまうかもしれません。
人間なら「これは触っちゃダメだ」と判断できることでも、AIには難しい場合があります。
プロジェクトファイルはGitで保護されているので、コミット履歴から復元できます。
しかし、開発環境全体――たとえば、ホームディレクトリの設定ファイルや、システムにインストールされているツール――が壊れてしまったら、復旧は大変です。
1.1. Dockerで制限する
そこで思いついたのは、Dockerを使ってAIエージェントのアクセス範囲を制限する方法でした。
Dockerコンテナは、ファイルシステムを隔離できます。
たとえば、プロジェクトディレクトリだけをコンテナにマウントして、それ以外のファイルにはアクセスできないようにする、という設定が可能です。
具体的には、こんなイメージです。
docker run -v /path/to/project:/workspace ai-agent
これで、AIエージェントは/workspace以下しか見えなくなります。
ホームディレクトリやシステムファイルは保護されるはず……と思いました。
1.2. Dockerでは制限しきれない？
しかし、調べていくうちに、Dockerによる制限には問題があることがわかりました。
Dockerは軽量です。
その理由は、ホストOSのカーネルを共有しているからです。
VMのように、OS全体を仮想化しているわけではありません。
つまり、Dockerコンテナとホストマシンは、根本的な部分で繋がっています。
もしDockerやカーネルに脆弱性があれば、コンテナから脱出してホストOSに侵入される可能性があります。
実際に、そういった事例は報告されています。
1.3. 設定ミスのリスク
もう一つの問題は、設定の複雑さです。
コーディング作業では、多くのファイルやツールにアクセスする必要があります。
たとえば、言語のランタイム、ライブラリ、パッケージマネージャー、エディタの設定ファイル、SSH鍵、環境変数……挙げればキリがありません。
これらすべてをDockerでホワイトリスト化するのは現実的ではありません。
必要なファイルを一つずつ指定していくのは手間ですし、何より、見落としがあればセキュリティホールになります。
逆に、広範囲にマウントしてしまうと、結局ホストOSへのアクセスを許してしまうことになります。
1.4. Dockerは何のためのツールか
ここで立ち止まって考えました。
Dockerは本来、何のために使うツールなのか？
Dockerは、プロジェクトごとにライブラリやツールのバージョンを切り分けるのに優れています。
たとえば、プロジェクトAではPython 3.9を使い、プロジェクトBではPython 3.11を使う、といった依存関係の管理には最適です。
しかし、信頼できないプログラムを隔離するためのツールではありません。
そもそも、そういう用途を想定して設計されていないのです。
2. VMという選択肢
では、どうすればいいのか？
答えはシンプルで、VM（仮想マシン）を使うことでした。
VMは、ホストOS上に完全に独立した仮想的なコンピュータを作ります。
VMの中では、別のOSが動いています。
カーネルもファイルシステムも、すべてホストOSから分離されています。
たとえるなら、Dockerは「今のOSに壁を作る」のに対し、VMは「もう一台別のコンピュータを作る」イメージです。
2.1. 使えるVMソフトウェア
VMソフトウェアはいくつかあります。
- VirtualBox：
無料で使いやすい。
初めてVMを使う人にもおすすめです。 - VMware Workstation Player：
無料版があり、高性能。VirtualBoxより動作が軽快だと感じる人も多いです。 - Hyper-V：
Windows Pro以上なら標準搭載されています。
設定は少し難しいですが、パフォーマンスは良好です。
私はVirtualBoxを使うことにしました。
慣れているのと、設定がわかりやすいからです。
2.2. なぜVMの方が安全なのか
VMはDockerより重いです。
メモリも多く消費しますし、起動にも時間がかかります。
でも、VM内で何が起きても、ホストOSには影響しません。
AIエージェントがVM内でファイルを削除しようが、設定を書き換えようが、ホストOSは無傷です。
もちろん、VM自体が壊れる可能性はあります。
しかし、VMはスナップショット機能があります。
作業前にスナップショットを取っておけば、何か問題が起きてもクリーンな状態に瞬時に戻せます。
これは強力です。
2.3. 実際の運用イメージ
最終的に、こんな構成で運用することにしました。
ホストOS（メインPC）
└─ VM（開発環境）
├─ プロジェクトファイル
├─ 開発ツール
└─ AIエージェント
プロジェクトファイルはGitで管理しているので、VM内でコミット・プッシュすれば、ホストOSからも同じリポジトリにアクセスできます。
作業を始める前に、必ずスナップショットを取ります。
新しいAIエージェントの機能を試すときや、大規模なリファクタリングを任せるときは特に重要です。
何か問題が起きたら、スナップショットから復元すればいいだけです。
3. DockerとVMの使い分け
誤解のないように補足すると、Dockerが悪いわけではありません。用途が違うだけです。
Dockerは、自分で管理するプロジェクトの環境を切り分けるのに最適です。
依存関係の衝突を避けたり、クリーンな環境でテストしたりするには、Dockerの軽量さが活きます。
一方、VMは、信頼できないプログラム動作を隔離するのに向いています。
AIエージェントのように、予測困難な動作をするツールを動かすなら、VMの方が安全です。
両方を組み合わせることもできます。
たとえば、VM内でDockerを使えば、依存関係の管理と安全性の両立が可能です。
3.1. おわりに
AIエージェントは便利ですが、信頼しきるのは危険です。
特に、メインPCで動かすなら、環境を守る仕組みが必要です。
Dockerは軽量で便利ですが、AIエージェントのアクセス範囲を制限する目的には不向きでした。
設定の複雑さと、カーネル共有によるリスクが大きすぎます。
VMは重いですが、完全な隔離が得られます。
スナップショット機能もあり、何かあっても安心です。
結局のところ、道具は目的に合わせて選ぶべきだと改めて感じました。
AIエージェントという新しいツールを使うなら、それに見合った環境を用意する。
それが、安心して開発を続けるための第一歩だと思います。