セキュリティと柔軟性を両立する！ AIエージェントのためのゼロトラスト・アーキテクチャ

セキュリティと柔軟性を両⽴する！ AIエージェントのためのゼロトラスト‧アーキテクチャ アーキテクチャ Conference2025 GO株式会社 Hikaru Kobori / 小堀 輝

⾃⼰紹介 GO株式会社 Webプロダクト開発部 Hikaru Kobori / ⼩堀 輝 2024年8⽉ ~ 現在 GO株式会社にてグループ会社のGOジョブ株式 会社で展開する⼈材採⽤プラットフォームであ る『GOジョブ』を開発。 傍らで、社内でAIエージェントを⽤いた開発の 推進活動を⾏う。

Introduction

AIエージェントは便利である一方、リスクがある

AIエージェントのリスク ● ファイル操作権限による「ホスト汚染」の恐怖 ● プロンプトインジェクション等による悪意のあるコードの実行や環境変数の流出 ● ホストが持つ権限や環境変数をAIエージェントが利用可能になってしまう ● etc...

組織でAIエージェントを利⽤する際のリスク そして、何も対策を打たないまま使用OKとしてしまうと、 セキュリティ対策は個人の注意と裁量に任せるという状態が発生する → コマンド実行のチェックが属人的であり、人数が増えれば増えるほどリスクが上がる。

セキュリティを「仕組み化」し、強制する

今⽇お話すること GOで内製した AIエージェントのためのサンドボックス環境の話

なぜ従来のセキュリティでは不⼗分なのか？

AIエージェントそれぞれでサンドボックス環境が提供されている 各社が提供するサンドボックス環境でホストコンピュータからの隔離は実現可能 ● Claude Code ○ ● Gemini CLI ○ ● /sandbox で起動可能 gemini -s で起動可能 Codex ○ codex --sandbox で起動可能

• https://docs.claude.com/ja/docs/claude-code/sandboxing
• https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/sandbox.md
• https://developers.openai.com/codex/security/

組織として使うには課題がある ● ツールごとに設定方法が違う ○ ● ● 各社ごとに開発しており、設定方法に一貫性がない 柔軟性に欠ける ○ サンドボックス内に自由に言語やツールをインストールできない ○ 特にネットワーク的な制限がかけにくい ホストOSに依存する（ポータビリティがない） ○ macOSの場合Seatbelt、Linuxの場合bubblewrapが使われる（Windowsでは使えない）

要件（どんなことが実現したいか？）

要件 セキュリティ要件 ● ● ホストコンピューターから隔離 されていること ○ 影響を及ぼさないこと ○ ホストが持つクラウドの権限等を使用できない状態であること ネットワーク的に隔離 されていること ○ 許可されたものとのみ通信ができること 機能要件 ● 全てのAIエージェントに一貫したポリシーを当てることができる ● 環境に依存しない（どの環境でも動作する） ● （Optional）プロジェクトごとに好きなツールを入れることができる ● （Optional）プロジェクトごとに柔軟なネットワークポリシーを当てることができる

これらの要件を満たす仕組みを GOで内製しました

アーキテクチャ

全体構成

解決の鍵1: Sandbox環境

解決の鍵1: Sandbox環境 役割 AIエージェントが動く環境 特徴 ● Dockernizeしており、ホストコンピュータから環境的に隔離 ○ ボリュームによって連携された部分にしか参照できない ○ 環境変数も最低限必要なもののみ連携することで、ホストが持つ権限を行使できないように ● network=noneにすることで、コンテナ外と通信できないように ● ホストで動作するMCPもこの環境内で立てることで、隔離

解決の鍵2: Proxy環境

解決の鍵2: Proxy環境 役割 ネットワークの制御 特徴 ● SquidというProxyサーバーをDockerを用いて起動 ● デフォルトでOutboundな通信を拒否 ● 信頼できるドメインやポートをホワイトリスト形式で指定

解決の鍵3: Sandbox Network

解決の鍵3: Sandbox Network 役割 Sandboxが唯一通信可能な環境 特徴 ● Sandboxからの通信を全てProxy（Squid）コンテナにルーティング ○ http_proxyという環境変数を設定することで実現可能 ○ network=noneになっているため、事実上、 Proxyコンテナが唯一通信可能

アーキテクチャを考えるだけでは、社内に浸透しない

アーキテクチャの実践と社内への浸透

実践のポイント1: インストールの複雑さを排除 課題 アーキテクチャの理解やプロジェクトへのインストールに時間がかかる やったこと ● lboxというコマンドを内製・配布 ○ ● git cloneしてきてmake installとするか、配布したバイナリを直接インストールできる仕組み lbox initとするだけで、インストール可能 ○ .lboxというディレクトリに構成ファイルが配置される ○ git管理に含めてもらうことで、プロジェクト内でレビューもできるように ● lbox up -d でコンテナ起動 ● lbox とするとコンテナ内に入ることが可能

実践のポイント1: インストールの複雑さを排除

実践のポイント2: ドキュメントやサポート体制を整備 その他にも .. ● アーキテクチャの概要をまとめたドキュメント整備 ● Issue・Slackによるサポート体制の整備 ● ユースケースごとのドキュメント整備 ○ サンドボックス環境に新しいツールを入れたい場合 ○ 新しい許可ドメインを追加したい場合 ○ 新しいMCPを追加したい場合 ○ etc..

まとめ

まとめ ● AIエージェントは優秀だが、リスクがある ● AIエージェントが安全に動作できるサンドボックス環境を内製 ○ ○ ● Sandbox ■ AIエージェントが動作するDocker環境 ■ ホストコンピュータから隔離し、権限を必要最低限に Proxy ■ Sandboxからの通信を制御 ■ 許可ドメインとのみ、外部と通信可能な状態に 社内のエンジニアが内製した環境を利用できるようにツールを整備 ○ セットアップの複雑さ解消 ○ プロジェクトごとにサンドボックスに入れるツールやネットワークの設定を可能に