AIにコードを書かせる前に、権限を設計する：セキュアなAI駆動開発の5つの境界

「生成されたコードを人がレビューすれば、コーディングエージェントも安全に使える」と考えたくなる。

エージェントは差分を作る前に、リポジトリやIssueを読み、コマンドを実行し、依存パッケージを取得し、接続したツールへ引数を渡しているかもしれない。

完成したコードに既知の脆弱性が見つからなくても、その過程で機密情報を読んだり、意図しない接続先へ送ったり、開発者の権限で別の対象を変更したりすれば、コードレビューだけでは防げない。

セキュアなAI駆動開発では、生成コードへの指示と検査に加え、ファイル、実行環境、通信、資格情報、承認の強制的な境界を設計する。

コードレビューより前に増えた攻撃面

OWASPの「Secure Coding with AI Cheat Sheet」は、Issue、PRの説明、README、ログ、取得したWebページなどを間接プロンプトインジェクションの経路として挙げ、ツール、サンドボックス、ルールファイル、変更範囲、テスト、CI/CDを信頼境界として扱っている。

既存のレビュー、CI、アクセス制御を、エージェントが差分を作るまでの経路へ延長する。

AIコーディングエージェントを、内側のコンテキストから外側のIDと監査まで五つの境界で囲む。

Project CodeGuardでセキュリティルールを作業文脈へ入れる

Project CodeGuardは、AIコーディングで参照させるセキュアコーディングルールを、ツールごとの形式で配布するオープンソースプロジェクトである。

統一したMarkdown形式のルールを、Cursorの.cursor/rules/、GitHub Copilotの.github/instructions/、Codexの.agents/skills/codeguard/などへ変換して配置できる。

Project CodeGuardでは、管理したセキュリティ指示を、エージェントが参照する作業文脈へ届ける。

公式の導入ガイドによると、常時適用するルールと対象ファイルに応じて適用するルールがある。 読み込み方と適用範囲はAIツールによって異なるため、実際のセッションで適用を確認する。

境界1：コンテキストとルールファイル

ソースコード、環境変数、顧客データ、Issue、ログ、ルールファイルを列挙し、機密性と指示としての信頼性を別々に分類する。

読み取り対象をタスクに必要なディレクトリへ絞り、秘密情報をコンテキストから除外し、外部由来の文書は「命令」ではなく「未信頼のデータ」として扱う。

導入経路の公式説明では、リポジトリに置いたルールはクローンしたメンバーへ共有でき、変更履歴をPRで確認できる一方、個人スコープの設定は共有もコードレビューもされないと整理されている。

ルールファイル自体がエージェントの行動を変えるため、CODEOWNERSやブランチ保護の対象に含め、通常のコードやCI設定と同じ変更管理へ載せる。

境界2：コマンドを動かす実行環境

実行境界では、ファイルの読み書き、許可するコマンド、プロセス数、CPUとメモリ、実行時間、外向き通信、資格情報への到達可能性を決める。

基本単位は、使い捨てにできるサンドボックスと、タスクに限定した短命な資格情報である。

たとえばGitHubの公式文書は、Copilot coding agentのインターネット接続を既定で制限している。 同資料は、その制御がMCP（Model Context Protocol）サーバーやセットアップ工程には適用されないことや、回避される可能性も制約として明記している。

ルールに「秘密情報を送信しない」と書くことと、秘密情報へ到達できないよう実行環境で強制することは同じではない。

境界3：ツール、依存関係、ルールの版

CLI、MCPサーバー、パッケージレジストリ、外部APIは実行能力を拡張するため、提供元、版、引数、接続先まで管理対象になる。

承認済みのツールと依存パッケージを許可リストで管理し、追加された依存関係を脆弱性検査、ライセンス確認、由来の確認へ通す。

CodeGuardのGetting Startedは、OpenCodeのリモート指示を固定して使う場合、mainではなくリリースタグを参照する方法を示している。

リポジトリへ同梱する場合も、取得したリリースまたはコミット、生成元、更新日を記録し、更新は差分を確認できるPRとして扱う。

境界4：変更と検証の担当を分ける

変更可能なパスをタスクごとに定め、認証、CI、デプロイ、ルールファイルには別の承認者を置き、テスト削除やロックファイル変更を明示する。

CodeGuardのリリースには、一部の対応ツールで使える任意のcodeguard-reviewerエージェントも含まれる。

公式の導入手順では、たとえばCodex向けのルールスキルは.agents/、任意のReviewerは.codex/として配布され、スキルインストーラーだけではReviewerが入らないと説明されている。

Reviewerは実装時とは別の確認経路になるが、それ自体もAIであるため、検出、見逃し、誤検出を人によるレビュー、CI、SASTと照合する。

境界5：誰の操作として記録するか

エージェントには個人の常設権限を引き継がせず、リポジトリ、ブランチ、期間、操作を絞った識別子と短命な資格情報を割り当てる。

監査記録には、依頼者、タスク、使用したモデルとツール、適用したCodeGuardの版、要求した操作、承認または拒否、実行結果、変更された成果物を対応づける。

OWASPの「AI Agent Security Cheat Sheet」も、最小権限、高影響操作への人の承認、構造化された監査記録、変更後の敵対的テストを一続きの統制として示している。

説明責任を果たすには、ある変更に至った権限、適用ルール、承認の根拠と結果をあとから再構成できる記録が要る。

自社ルールは狭い適用範囲から始める

CodeGuardのCustom Rules公式手順では、sources/rules/配下へ独自のルール群を作り、テンプレートを基にcodeguard-*.mdを追加し、変換と検証を実行する流れが示されている。

自社ルールは「安全に書く」のような抽象文ではなく、「このAPIでは認可済みのテナントIDをサーバー側で再検証する」のように、対象、禁止事項、期待する実装、確認方法を結びつける。

常時適用しないルールはfrontmatterで対象言語を指定し、生成物の検証と代表タスクでの適用試験を残す。

CodeGuardは防御層の一つであり、代替ではない

CodeGuardのFAQは、既存のセキュリティスキャナーを置き換えるものではなく、併用するものだと説明している。

防御層	主に扱う対象	CodeGuardでは代替できない点
CodeGuard	生成時とレビュー時に参照するセキュアコーディング指示	指示が常に守られることの強制
サンドボックス	ファイル、プロセス、ネットワーク、資格情報への到達	実行時の隔離と外部送信の遮断
CIとSAST	リポジトリ全体に対するテストと静的解析	実際に生成された差分の機械的な検査
依存関係の検査	脆弱性、ライセンス、由来、ロックファイル	パッケージと供給元の健全性確認
人によるレビュー	仕様、設計意図、例外、残余リスク、マージ承認	組織としてのリスク受容と説明責任

CodeGuardは、サンドボックス、CI/SAST、依存関係の検査、人によるレビューの代替ではない。

CodeGuardは指示層を担い、実行隔離、機械検査、依存関係検査、人のレビューを置き換えない。

一つのリポジトリで導入経路を検証する

全社配布の前に対象リポジトリとIssueを一つ選び、CodeGuardをリリースタグまたはコミットへ固定してPRで導入する。

自社固有の確認事項を一つだけCustom Ruleへ落とし、ルールありとルールなしの作業を比較して、Reviewer、CI/SAST、依存関係の検査、人によるレビューが挙げた項目を対応づける。

株式会社麻布技術研究所は、日本企業のAI導入をサイバーセキュリティと統合し、経営上の判断軸から設計、検証、実装、運用まで支援する技術研究所である。

コーディングエージェントの導入範囲、CodeGuardの配布方法、権限、ログ、承認ゲートを実環境に合わせて整理する場合は、Technology Strategistに相談するから対象業務と現在の構成を共有してほしい。

この記事を書いた人

中村泰行（Yasu Nakamura）

株式会社麻布技術研究所 代表取締役社長。 サイバーセキュリティ、人工知能、セキュアシステム、事業成長を主な専門領域としています。

著者プロフィール