8月6日、SD Timesが「AI agents are ready for production. The infrastructure around them isn't.」と題した記事を公開した。AIエージェントが本番運用に耐えうる能力を持ち始めた一方で、それを安全に扱うためのインフラや統制の仕組みが追いついていないという現場の実態を詳しく論じている。

エージェントはもう「実験」ではない

AIコーディングエージェントはすでに実際のエンタープライズ開発に投入されている。コードを書き、リポジトリを読み込み、テストを実行し、プルリクエストを開く。一部の組織では、エージェントが書いたコードを人間がレビューしてからプロダクションに出すフローが定着しつつある。

生産性向上の効果は本物だ。しかし問題は、多くの企業がエージェントを「ソフトウェアの機能」として扱い続けている点にある。実態はむしろ「自律的なユーザー」に近い。

コード、API、ドキュメント、内部ツールをまたいで動くエージェントは、現実の運用上のフットプリントを持つ。有用な判断もできるが、クレデンシャルを漏洩させたり、アクセスすべきでないデータに触れたり、シークレットをハードコードしたり、下流のリスクを生み出したりする可能性もある。

こうした露出の多くは、通常の実行の中で起きる。エージェントはタスクを完了させようとする。もし環境にリスクのある選択肢があれば、エージェントはそれを取るかもしれない。

問題の核心：既存のプロセスをエージェントに適用していない

エンジニアリング組織は通常、ID管理、ネットワークポリシー、監査ログ、RBAC（ロールベースアクセス制御）、レビューワークフロー、コスト管理といった成熟したプロセスを持っている。ところがエージェントが登場した途端、チームはそのプロセスの半分を忘れる、と記事は指摘する。

最大の初期ミスは「エージェントに広すぎる行動範囲を与えること」だ。

アクセス範囲を絞る

ネットワークアクセスが最もわかりやすい例だ。エージェントは基本的にインターネット全体にアクセスする必要はない。必要なのは、リポジトリ、パッケージソース、ドキュメントサイト、ビルドシステム程度だ。

記事が推奨するアプローチは明快である。

デフォルトですべて拒否し、エージェントが必要とするパスとツールだけを追加で許可する。（元記事より／編集部意訳）

この1点だけで多くのリスクが排除される。制限のないインターネットアクセスを持つエージェントはデータ漏洩の経路が増え、信頼されていないパッケージをダウンロードし、意図しないツールに接続する可能性がある。

実行環境についても同様だ。エージェントを開発者のラップトップで直接動かすのはまずい選択だと明言されている。そのマシンにはキャッシュされたトークン、ローカルシークレット、SSHキー、ソースコードが散在しており、エージェントはタスクに必要以上の権限を継承してしまう。

推奨されるのは、タスクごとに一時的な制御された環境をエージェントに与え、作業完了またはレビュー後に環境を破棄する方式だ。

IDの問題：APIキーの束ではなく「委任」で管理する

多くのチームが未だにエージェントのアクセス管理をAPIキーのセットで行っており、これがすぐに複雑化する。記事では、同じモデルへのアクセスに数百のキーを配布しているチームの事例が紹介されている。

本来必要なのは「どの人間がタスクを委任し、どのエージェントが作業し、どのシステムに触れたか」を追跡できるID認識型のルーティングだ。これが整っていれば、アクセス付与・取り消し、ポリシー適用、挙動監視、インシデント調査がプラットフォームチームとセキュリティチームにとって明確になる。

記事が提示するモデルはシンプルだ。

すべての個人貢献者は、エージェントというチームメンバーに仕事を委任するチームマネージャーになった。 エージェントの品質は評価できるが、アウトカムのオーナーシップは人間が持つ。（元記事より／編集部意訳）

エージェントを「組織図に載せる独立した従業員」のように扱う考え方を記事は否定する。その枠組みはエージェントに過度の自律性を与え、説明責任を人間から切り離してしまうからだ。

ツールアクセスには最小権限を

エージェントがリポジトリ、チケットシステム、データベース、クラウドサービス、内部APIなどのツールにアクセスできるようになると、真に意味のある仕事ができるようになる。同時にリスクの性質も変わる。

記事の推奨はエージェントをファイアウォールで囲み、トラフィックをプロキシ経由にすることだ。その層がリクエストを認証し、アクセスを制限し、挙動を監視し、危険な呼び出しをブロックする。

監査ログについても具体的な要件が示されている。「開発者がワークスペースを開いた」という記録では不十分だ。どのプロンプトが発行され、どのモデルが応答し、どのツール呼び出しが行われ、どのIDが使われ、何が変更されたか—この一連の記録が必要だ。

また、開発者が数十のリポジトリやシステムへのアクセス権を持っていても、単一タスクを担うエージェントが必要とするのはその一部に過ぎない。タスクに必要なリポジトリ、ブランチ、ファイル、ツール、データだけを与えるのが原則だ。

この「最小権限の原則」はセキュリティの基本概念であり、OWASP Top 10 for LLM ApplicationsでもLLMエージェントに対する重要な対策として位置づけられている。また、NIST AI Risk Management Framework（AI RMF）においても、AIシステムのガバナンスと説明責任の確保は中心的なテーマとして扱われており、本記事の主張と方向性を同じくする。

結論：エージェントを本番インフラとして扱え

記事の主張は一貫している。エージェントは実験ではなく、すでに本番インフラの一部だ。うまく導入できた組織は、セキュリティの例外処理を繰り返すことなく新しいアプリケーションを速く出せる。失敗した組織は「統制なき生産性はより大きな爆発半径に過ぎない」ことを痛い目で学ぶことになる。

詳細はAI agents are ready for production. The infrastructure around them isn't.を参照していただきたい。