こんにちは！ GO株式会社のWebプロダクト開発部に所属しております、小堀と申します。
アーキテクチャConference2025にセキュリティと柔軟性を両立する！AIエージェントのためのゼロトラスト・アーキテクチャというタイトルで発表してきたので、振り返りも兼ねて登壇内容を記事にしたいと思います。
背景
Claude CodeやGemini CLI、Codex等、AIエージェントを用いた開発は便利である一方、セキュリティ的なリスクを抱えていると考えています。
- ホスト汚染のリスク
ホストコンピュータ上で動作させることにより、プロジェクト以外のルートディレクトリやホームディレクトリに対してファイルを消されたり、書き換えられるようなリスクがある。 - 情報漏洩のリスク
プロンプトインジェクションなどの攻撃により、環境変数やプロダクションコードを外部のサーバーに対してPOSTしてしまうといったリスクがある。 - 悪意のあるスクリプト実行のリスク
プロンプトインジェクションなどの攻撃により、悪意のあるスクリプトをインターネット上からGETしてきて、ホストコンピュータ上で実行してしまうといったリスクがある。 - ホストが持つクラウド権限を行使してしまうリスク
ホストが持つ環境変数を用いて、クラウドや踏み台サーバーにアクセスし、攻撃を行えてしまう可能性がある。
皆さんの会社でも、dangerously-skip-permissionsは使わないであったり、AIエージェントが用意してくれているsandbox環境を使ったり、permission設定をされているとは思いますが、本当にそれだけで十分と言えるでしょうか？
個人の注意と裁量に任せる。という状況が作られてしまうと、何かあったときに個人の責任になってしまうので、組織としてこれらのツールを使う場合、そもそも、何も起き得ない状況を作るというのが重要かと思います。
そこで、GOではAIエージェントが安全に動けるサンドボックス環境というのを内製化したのでそのご紹介ができればと思います。
要件定義
セキュリティ要件
ゼロトラストに設計されていること（AIエージェントが開発をするうえで、必要最低限のみの情報を共有すること）をコンセプトに考えました。
- AIエージェントが動く環境がホストコンピュータから隔離されていること
AIエージェントを用いた開発を行いたいプロジェクトに限り、ファイルに参照可能となり、それ以外のファイルへの参照やホストが持つ環境変数に対してアクセスしたり、行使できないこと。 - ネットワーク的に隔離されていること
全くネットワークが使えないと困るので、基本はブロックしつつ、プロジェクトごとに許可されたドメインやポートとのみ通信が可能であること
機能要件
セキュリティ要件を担保しつつ、きちんと使われるツールとなるように、以下のような機能要件を整理しました。
- 全てのAIエージェントに一貫したポリシーを当てられること
AIエージェントを用いた開発が活発になっている現代なので、色々なAIエージェントを試したいというニーズに対応するべく、全てのAIエージェントに一貫したポリシーを当てられるように - どの環境でも動作すること
OSに依存せず、どの環境でも同様に動作すること - プロジェクトごとに柔軟にツールを導入可能であること
GOではバックエンドはGolangで開発することが多いですが、他にもフロントエンド関連の開発にはNode.js、AI関連にはPython、ネイティブアプリの開発もあるので、技術や使っているツールがバラバラです。なので、プロジェクトにインストールした後に自由にツールや言語を入れることができること - プロジェクトごとにネットワークの境界を設定可能であること
開発をするために、全てがサンドボックス環境内で立ち上げ可能であればいいんですが、マイクロサービスと通信を行ったり、外部のSaaSと通信を必要とするケースもあります。なので、全てのプロジェクトで一貫したポリシーを当てるということはできず、こちらもプロジェクトにインストールした後に自由にネットワークの境界線を変更できること
外部のツール（特に各AIエージェントが提供してくれるサンドボックス環境）を検討しましたが、全てを満たしてくれるツールがなく、これらの要件を満たすように設計、実装を行いました。
アーキテクチャ
では、実際に作ったアーキテクチャをご紹介します。
一つずつ、解説をしていきます。
ポイント1: サンドボックス環境
AIエージェントが動作する環境になります
- Dockernizeによる環境隔離
- Volumeで必要なコードのみDocker環境内に連携
- 環境変数に関しても必要なもののみ連携することで、ホストコンピュータが持つ権限を行使できないように
- network=noneオプションによるネットワーク的な隔離
- Dockerにあるnetwork=noneオプションを設定することで、コンテナ外とは基本、通信ができないように設定（後述するProxyコンテナとのみ通信可能な状態）
ポイント2: Proxy環境
ネットワークを制御する環境になります
ポイント3: サンドボックスネットワーク
上記2つのコンテナを繋ぐDockerネットワーク
サンドボックス環境はnetwork=noneのため、事実上、唯一通信可能な環境で、http_proxy=http://proxy という環境変数をセットすることで、proxyコンテナを向くように設定をしています。
これにより、サンドボックス環境とホストコンピュータを隔離しつつ、Proxyコンテナと通して、信頼されたドメインとのみ通信可能な状態にしています。
アーキテクチャの実践
ただ、このままでは、机上の空論になってしまうので、ここからは、アーキテクチャの実践ということで、どのようにエンジニアやプロジェクトに対してこれらのアーキテクチャを根付かせていったのかについてご紹介します。
課題
何と言っても、アーキテクチャの理解が難しかったり、プロジェクトへのインストールが難しかったり、カスタマイズの方法がわからず、安定した運用が難しいということです
解決方法
lboxというコマンドを内製し、社内のエンジニアに配布しました。
lboxコマンド自体はGolangで実装されており、リポジトリをクローンし、make installとするか、バイナリを直接ホストコンピュータにインストールすることで、lboxというコマンドが使えるようになっています。
後は、AIエージェントを使いたいプロジェクトの中で3ステップ実行するだけで、安全にAIエージェントを使うことができます。
以下で詳しく解説していきます。
lbox init: プロジェクトへの初期化
上記のようなアーキテクチャを構成するファイルをプロジェクトの .lboxというディレクトリにコピーします。
重要な構成ファイルは以下の通りです。
.lbox
├── Dockerfile
├── compose.sandbox.yml
├── .env
└── proxy
└── squid.conf
.lbox/Dockerfile- サンドボックス用のDockerfile
- このファイルを編集することで、各プロジェクトに好きな言語やツールをインストール可能
.lbox/compose.sandbox.yml- ネットワークの設定
- volumeの管理
- 各コンテナの設定
.lbox/.env.lbox/proxy- プロキシ設定
- squid.confを提供することで、各プロジェクトごとに柔軟にネットワークの制御をすることが可能
lbox up -d: サンドボックス環境の立ち上げ
- Dockerで構成されたサンドボックス環境やProxy環境を立ち上げ
- 内部的にはdocker composeを用いているので、実際には
docker compose -f .lbox/compose.sandbox.ymlへのエイリアスになっています
lbox: サンドボックス環境に入る
- サンドボックスコンテナにbashでexecすることができます
- DockerfileにすでにAIエージェントがインストールされているため、Claude CodeやGemini CLIを実行することができるようになっています
このようにすることで、プロジェクトにサクッとインストールを行い、プロジェクトごとにカスタマイズが可能な状態にしたうえで、以下のようなドキュメント整備やサポート体制の強化等を行いました。
まとめ
AIエージェントを用いた開発が盛んになっていっているが、セキュリティ的なリスクがある。 そこで、GOでは、AIエージェントが安全に動作できるサンドボックス環境を内製し、社内のエンジニアが使えるようにツールを整備したので、その事例を発表させていただきました。
最後にはなりますが、イベント開催いただきました、ファインディ株式会社の皆様、セッションをお聞きいただきました皆様、懇親会でお声がけいただきました皆様ありがとうございました。
