AIエージェントがコードを生成し、そのままCI/CDパイプラインを起動したり本番データベースへ接続したりできる状態は、承認なき変更の実行と同義です。実行権限の境界をどこに引くか、どの環境までAIに触れさせるかは、ガバナンス設計の中で最も判断が分かれる項目です。本記事では、AIエージェントの実行権限をどこまで許すべきか、サンドボックス環境をどう分離すべきかを、因果と構成例で示します。
AIエージェント実行権限の設計で決めるべき境界
AIエージェントに実行権限を与える設計では、次の境界を明確に引く必要があります。
- コード生成の範囲: リポジトリのどの階層までAIが読み書きできるか
- CI/CD起動の可否: AIが生成したコードでテスト・ビルド・デプロイを自動実行できるか
- 本番環境への接続: AIが本番データベース・本番APIへ直接アクセスできるか
- 環境分離の粒度: 開発・検証・本番のどこまでを同一の実行基盤に置くか
境界が曖昧なまま運用を始めると、AIが生成したコードが承認なしに本番へ反映される、検証用のデータが本番へ混入する、外部APIを意図しない方法で呼び出す、といった事故が起こります。境界は技術的に引けるだけでなく、その境界を超える操作が発生したときに誰が承認するかまで含めて設計します。
CI/CDパイプラインへの接続を許す場合のリスク
AIエージェントがCI/CDパイプラインを起動できる状態には、次のリスクが伴います。
- 承認なき変更の本番反映: AIが生成したコードが、人の目を通らずに本番環境へデプロイされる
- 無限ループによるリソース消費: AIが誤った条件でパイプラインを繰り返し起動し、ビルド環境のリソースを使い切る
- シークレットの意図しない参照: CI/CD環境に設定された認証情報・APIキーをAIが読み取り、ログへ出力する
- テスト結果の誤読: AIがテスト失敗を成功と誤認し、不具合を含むコードを次の工程へ送る
リスクを抑えるには、AIが起動できるパイプラインの種類を限定する、本番デプロイには必ず人の承認を挟む、シークレットは環境変数ではなく外部シークレット管理サービスから参照する、といった構成が必要です。
サンドボックス環境の分離設計
サンドボックス環境とは、本番データ・本番APIから完全に分離された実行環境を指します。AIエージェントの実行権限を本番から遠ざけるために、次の分離設計を適用します。
ネットワークレベルの分離
サンドボックス環境を本番環境と別のVPC・サブネットに配置し、セキュリティグループで接続元を制限します。本番データベースへの接続は、サンドボックスからは物理的に到達できない構成にします。これにより、AIが誤って本番へ接続するコードを生成しても、実行時にネットワークレベルで遮断されます。
認証情報の分離
サンドボックス環境には、本番の認証情報・APIキーを一切配置しません。代わりに、サンドボックス専用のダミーアカウント・テスト用トークンを用意し、本番とは異なるスコープ・権限を設定します。AIがシークレットを参照するコードを生成した場合でも、取得できるのはサンドボックス内でしか通用しない認証情報に限定されます。
データの分離
サンドボックスで使用するデータは、本番データの匿名化版またはダミーデータに限定します。本番データを直接コピーすると、個人情報や機密情報がサンドボックスに混入し、個人情報保護委員会が示す利用目的の範囲外となるリスクがあります。サンドボックスは「開発・検証のみを目的とする」と明示し、データの種類もその目的に限定します。
実行権限をどこまで許すかの判断基準
AIエージェントに与える実行権限の範囲は、次の基準で判断します。
可逆性
AIが実行した操作を、人が後から取り消せる状態であれば、実行権限を許容できます。例えば、AIがプルリクエストを自動作成する操作は、人がマージ前に内容を確認し、必要に応じて却下できるため、可逆性があります。一方、AIが本番データベースへ直接DELETE文を実行する操作は、データを復元できない限り可逆性がなく、実行権限を与えるべきではありません。
影響範囲
AIが実行した操作が、サンドボックス内で完結するか、本番環境へ影響を及ぼすかを判断します。影響範囲がサンドボックスに閉じている場合、実行権限を広く与えても問題は少なくなります。本番環境へ影響が及ぶ場合、実行前に人の承認を必須とする、または実行権限を与えずコード生成のみに留めます。
再現性
AIが実行した操作を、後から誰が実行したか、どのような入力で実行されたかを記録できる状態であれば、実行権限を許容しやすくなります。ログにAIのセッションID・入力プロンプト・生成されたコードが残る構成にすることで、事故発生時に原因を特定できます。再現性がない操作は、実行権限を与えるべきではありません。
CI/CD環境とAIエージェントの接続構成例
AIエージェントをCI/CD環境へ接続する場合、次の構成例が適用できます。
プルリクエスト作成までをAI、マージ以降を人が担当
AIエージェントは、コード生成・テスト実行・プルリクエスト作成までを自動で行います。プルリクエストのマージ操作は人が承認し、マージ後のデプロイパイプラインも人が起動します。この構成では、AIが生成したコードが本番へ反映される前に、必ず人の目を通る仕組みが成立します。
サンドボックス専用のCI/CDパイプラインを用意
本番用とは別に、サンドボックス専用のCI/CDパイプラインを作成し、AIエージェントにはサンドボックス用のみ起動を許可します。サンドボックス用パイプラインは、本番デプロイの工程を持たず、テスト・ビルド・サンドボックス環境へのデプロイまでで完結させます。本番用パイプラインは、人が手動で起動する、または別のトリガー（タグ付与・特定ブランチへのマージ）で起動する形にします。
外部シークレット管理サービスとの連携
CI/CD環境に設定するシークレットは、環境変数ではなくAWS Secrets Manager・Azure Key Vault等の外部サービスから取得します。AIエージェントには、シークレット管理サービスへのアクセス権限を与えず、CI/CDパイプラインの実行時に必要な認証情報だけを注入します。これにより、AIがシークレットを直接参照するコードを生成しても、実行時には取得できない状態になります。
環境分離の粒度と統制装置の配置
開発・検証・本番という環境分離の粒度は、組織の規模と統制の強度で決まります。AIエージェントを運用する場合、統制装置（承認ゲート・ログ取得・権限制御）をどの環境の境界に置くかが設計の核になります。
例えば、開発環境と検証環境を同一の実行基盤に置き、本番環境のみ分離する構成では、開発から検証への移行は自動化し、検証から本番への移行には人の承認を必須とする統制装置を置きます。統制装置の置き場所は、「どの境界を超えたら人の判断が必要か」という意思決定の線と一致させます。
SHA株式会社が支援したエンタープライズ企業におけるCopilot Studio／Power PlatformのAI基盤ガバナンス構築では、統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を「環境」から「人（セキュリティグループ）とデータ（権限・ラベル）」へ再配置する方針で組み替えた実例がありました。統制設計はライセンスの配布範囲という前提に依存しており、前提が変われば、統制の思想ではなく装置の置き場所を組み替える必要があります。
本番環境への接続を禁止できない場合の代替策
業務の性質上、AIエージェントが本番データへアクセスせざるを得ない場合があります。例えば、顧客からの問い合わせ内容を本番データベースから検索し、回答を生成するエージェントなどです。この場合、本番への接続を完全に禁止するのではなく、次の代替策を適用します。
読み取り専用権限に限定
AIエージェントに与えるデータベースアカウントは、SELECT文のみ実行できる読み取り専用権限に設定します。UPDATE・DELETE・INSERTの権限を持たせないことで、誤操作によるデータ破壊を防ぎます。読み取り対象のテーブル・カラムも、業務に必要な最小限に絞ります。
アクセスログの全件記録
AIエージェントが本番データへアクセスした際のログを、全件記録します。ログには、アクセス日時・実行したSQL・取得した行数・セッションIDを含めます。これにより、後から「誰のAIが、いつ、どのデータを参照したか」を追跡できる状態にします。ログの保管期間は、組織の監査要件に従います。
データマスキング
AIエージェントが本番データを参照する際、個人情報や機密情報を含むカラムは、マスキングした状態で返します。例えば、顧客名を「顧客A」、電話番号を「XXX-XXXX-XXXX」のように置き換えてから、AIへ渡します。これにより、AIが生成する回答に個人情報が含まれるリスクを減らせます。
AIエージェントと人の役割分担を明示する
実行権限の設計では、AIエージェントに任せる範囲と、人が必ず介在する範囲を明示します。曖昧なまま運用すると、「AIが自動でやると思っていた」「人が確認すると思っていた」という認識のずれが起き、承認なき実行や見落としが発生します。
役割分担は、次の形で文書化します。
- AIエージェントの担当: コード生成、テスト実行、プルリクエスト作成、サンドボックスへのデプロイ
- 人の担当: プルリクエストのレビュー、マージ操作、本番デプロイの起動、シークレットの配置
- 共同作業: エラー発生時の原因特定（AIがログを解析し、人が最終判断）
役割分担は、運用開始前にチーム全体へ共有し、運用中に変更が生じた場合は再度文書を更新します。
監査設計と記録の範囲
実行権限を与える以上、「誰が、いつ、何を実行したか」を記録する監査設計が必要です。監査ログには、次の項目を含めます。
- 実行者（AIエージェントのセッションID、またはAIを起動した人のアカウント）
- 実行日時
- 実行内容（生成されたコード、起動したパイプライン名、アクセスしたリソース）
- 実行結果（成功・失敗、エラーメッセージ）
SHA株式会社の支援実例では、監査ログの取得をPurview前提で設計したが、監査ロールの付与が社内承認されなかったケースがありました。メール等まで閲覧範囲が及ぶことが理由です。監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まります。代替手段としてエージェント管理基盤へ監査機能を載せ替える方法もありますが、「誰が誰に共有したか」の操作記録は代替手段がなく、残存リスクとして記録する判断もあります。
実行権限の見直しサイクル
AIエージェントの実行権限は、運用開始後も定期的に見直します。見直しの契機は、次の通りです。
- 新しい業務へAIエージェントを適用する場合
- セキュリティインシデントが発生した場合
- 組織の統制要件が変更された場合
- AIエージェントの利用範囲が拡大し、影響範囲が当初想定を超えた場合
見直しでは、現在の権限範囲が適切か、過剰な権限を与えていないか、逆に権限不足で業務効率が落ちていないかを確認します。見直し結果は文書化し、次の見直しサイクルの基準とします。