AIエージェントガバナンス：エンジニアリーダーのためのフレームワーク

AIエージェントガバナンスは、エージェントの責任者、許可する行動、アクセスできる情報、人間が作業を確認・停止する方法を定めるものです。本ガイドでは、リポジトリへのアクセス、コード変更、マージ承認、デプロイの境界を扱い、コーディングチームにこの枠組みを適用します。

リスクに応じて責任者と制御を決めるために活用してください。より広い概念はAIコードガバナンスとは（英語）、リポジトリ設定とポリシーの具体例はコーディングエージェントのAIガバナンスで説明しています。

コーディングエージェントの権限を決めるリスクマトリクス

以下はポリシー設計の出発点としての提案であり、法令上のリスク分類ではありません。扱うデータ、システム、インシデント対応手順に合わせて調整してください。

読み取り対象から秘密情報や無関係な顧客データを除きます。承認済みツールを使い、保護ブランチへの直接プッシュを防いでください。タスク範囲、エージェントID、差分、チェック結果を保存します。認証、インフラ、マイグレーションの変更では、指定オーナーがテスト結果とロールバック計画を確認してからリリースを承認します。

たとえば、ログイン処理のリファクタリングを依頼されたエージェントが、本番のアクセス制御ポリシーの変更も提案したとします。開発用の認証情報では、そのポリシーを本番へ適用できないようにします。PRで変更を提案することはできますが、インフラのオーナーが計画をレビューし、リリース手順を通じてデプロイを承認します。レビューコメントだけで、この実行時の境界を作ることはできません。

AIエージェントガバナンスとは結局のところ何か

AIエージェントガバナンスとは、自律的なAIエージェントが何をしてよいか、何にアクセスできるか、その行動をどう検証するかについて、ルールを設定する取り組みのことです。SDLCの中では、PRを書き、設定を変更し、コードを本番環境へ反映するコーディングエージェントを統制することを意味します。

AIエージェントガバナンスは、従来のモデルガバナンスとは別物です。モデルがリリースされる前の学習データやモデルの振る舞い、バイアス、評価といった部分に焦点を当てるのではなく、AIエージェントガバナンスはその合間の運用層をカバーします。具体的には、どのエージェントが行動したのか、いずれのアクセスを許可されていたのか、実際には何を行ったのか、そして本番環境に到達する前に人間が出力を検証したかどうか、といった内容です。

アプリケーションセキュリティ（AppSec）とも別物です。AppSecは、すでに存在するコードの中の脆弱性パターンを捕まえる領域です。

モデルガバナンスは「そのモデルはデプロイしても安全か」を問います。AppSecは「そのコードは動かしても安全か」を問います。エージェントガバナンスは「いまエージェントが取った行動は、認可され、レビューされ、記録されていたか」を問うものです。

現場のエンジニアリングワークフローでエージェントがコードを書く状況では、ガバナンスの核となる問いは、エージェントのID、説明責任、トレーサビリティ、アクセス権、取った行動、そして何か問題が起きたときにどう止められるか、といった点に及びます。たとえば次のような問いです。

• どのエージェントがプルリクエストを開けるのか、そしてどのリポジトリに触れてよいのか？
• エージェントはインフラの設定を変更したり、mainブランチに直接プッシュしてよいのか？
• 出力を誰がレビューするのか、そのレビューには意味があるのか？

こうした問いに現場で答えるということは、エージェントが動いている間にできることを明確に制限することを意味します。実行時に制限を強制しなければ、ポリシーと現場との間のギャップこそが、これから挙げるリスクの温床になります。

統制のないAIコーディングエージェントが抱える、4つの大きなリスク

コーディングエージェントが何にアクセスでき、何を行い、何をリリースしてよいかについて誰もルールを定めないと、4つのリスクが立ち上がります。それぞれのリスクは特定のガバナンス制御に対応していて、その制御が欠けると、エージェントがコードを生成する速度で問題が積み上がっていきます。

1. スコープのない権限と、不明確な認可

広い権限を与えられたエージェントは、タスクと無関係なリポジトリを読み、APIを呼び、コマンドを実行できる場合があります。認証情報、ファイルシステム、ネットワークへのアクセスを、認可された作業範囲に絞ります。デフォルト権限はツールと設定によって異なります。

インフラの変更には別の認可境界が必要です。Terraformを編集する権限と、それを適用する権限は異なります。誰が計画を承認し、どのIDがデプロイでき、そのIDをどう制限するかを記録します。

2. エージェントが書いた変更に対する監査証跡の欠落

ガバナンスがないとき、エージェントが書いた変更の執筆者の連鎖は消えてしまいます。エージェントがコードを生成し、人間がマージをクリックする、その間にどのエージェントが動いたのか、どのプロンプトを受け取ったのか、他にどのツールを呼び出したのか、途中でどのリビジョンを捨てたのか、何も記録されません。

2025年のサンフランシスコ大学の研究（IEEE-ISTAS）では、400件のコードサンプルを、各イテレーションの間に人間のレビューを挟まずに自動化されたAIによる5回の改善ラウンドにかけたところ、クリティカルな脆弱性が37.6%増加することが分かりました。著者らの結論は、イテレーション間に人間のレビューを挟むことが緩和策である、というものでした。

タスク、エージェント、リビジョン、レビュアーを結び付けた記録がなければ、欠陥が入り込んだ経緯の調査は難しくなります。秘密情報や不要な機密データを除き、調査に必要なコンテキストを保存します。

3. エージェントの出力全体に対する、強制力のない基準

コーディングエージェントは、コードベースで目にしたパターンを再現します。一貫していないものや、最適でないものも含めて、です。チームの基準をコード化したガバナンス層（コードガイドライン、AGENTS.mdファイル、パスベースの指示、マージ時のポリシーチェック）がなければ、過去の平均ではなく、いまのチームの規約のほうへエージェントの出力を引き寄せる仕組みがありません。

CodeRabbitによる470件のPRのレビューでは、AIのPRで可読性の問題が3倍以上見つかりました。文書化した指示は基準の共有に役立ちますが、出力はレビュアーと実行可能なチェックで検証する必要があります。

4. リポジトリやチームをまたいだ、エージェントポリシーの不揃い

中央集約されたガバナンスがなければ、チームごとのエージェント構成は、それぞれが独立したポリシーの島になります。あるチームはmainへのプッシュを許可し、別のチームは禁止しています。あるチームはスコープを絞ったトークンを使い、別のチームはすべてを管理者として動かしています。あるチームはAIのPRにセキュリティレビューを強制し、別のチームはしていません。

Apiiroの分析を取り上げたCSO Onlineの記事では、AIが生成したコードが毎月10,000件を超える新たなセキュリティ検出を持ち込んでおり、6か月で10倍の急増を意味すると伝えています。その量こそが、組織全体で異なるエージェントが「良いコード」の異なる解釈を当てはめたときに生まれる、スプロールの結果です。

CIに置かれた共有ルールと、すべてのPRに適用される一貫したレビュー層を通じて中央集約されたガバナンスを適用することが、こうしたポリシーの島々を、単一の強制可能な基準へとまとめあげるものです。

エンジニアリングチームで機能する、ガバナンス層

ここまで挙げた4つのリスクは、結局のところ同じギャップに行き着きます。エージェントがコードをリリースする速度に追従して動く強制層が、存在していないのです。このギャップを埋めているエンジニアリングチームは、SDLCの4つのポイントにガバナンスを差し込んでいます。それぞれが上記のリスクのどれかに対応していて、エンジニアリングリーダーがすでに持っていて、そのまま拡張できるものばかりです。

1. コーディングエージェントに対するIDとアクセス制御

スコープのない権限への対策は、エージェントのすべての行動を「実行前にポリシーチェックを通る必要があるもの」として扱うことです。現場で機能するフレームワークは、エージェントの行動を次の3段階に分類します。

1. エージェントが自分の判断で取ってよい行動
2. 人間の確認を必要とする行動
3. コンテキストにかかわらず、決して許されない行動

実行環境での強制は、エージェントと、エージェントが触れられるシステムとの間に挟まり、ファイル操作・API呼び出し・シェルコマンドのいずれも、実行前にこの階層化されたポリシーに照らして評価します。

ここで使う運用上のコントロールは、人間のエンジニアにアクセス権を設定したことがある人なら見慣れたものです。RBAC、監査ログ、スコープを絞ったトークンは、そのままコーディングエージェントにも当てはまります。200のリポジトリにPRを開けるが、インフラ設定には触れず、保護されたブランチにもプッシュできないエージェントは、統制されているエージェントです。一括での書き込み権限は、障害発生後の振り返りで必ず取り上げられることになります。

2. CIにコード化されたチーム基準

基準ごとに強制の仕組みを割り当てます。Conftestは構造化された設定をポリシールールで評価します。コードの検証には専用の秘密情報スキャナー、リンター、テストを用い、製品やアーキテクチャの文脈が必要な判断は人間がレビューします。

保護ブランチに必須チェックと承認を設定し、バイパスできる主体を制限します。GitHubでは成功、スキップ、中立の結果が必須チェックを満たし得ます。チェックの完了をポリシー準拠の証明とせず、それぞれの結果をテストしてください。

AGENTS.md、CLAUDE.md、SKILL.mdはエージェントに指示を伝えるファイルであり、セキュリティ境界ではありません。アクセス制限は実行環境と認証情報で強制し、コードの要件はCIとレビューで検証します。

CodeRabbitでは、明確な判定基準を持つカスタムPre-Merge Checksを追加し、結果の根拠を確認できます。変更要求ワークフローとリポジトリ保護でブロック動作を設定し、決定的なテストと人間の承認も維持します。

3. 基準を強制する層としてのAIコードレビュー

CIは実行可能なチェックで表現できる要件を検証します。AIコードレビューは利用可能なコンテキストからアーキテクチャや要件との整合性を調査し、検証すべき指摘を提示できます。リスクの受容と承認は人間の責任者が担います。

この層を「オプションではなく必須」にしているのは、量が多いためです。たとえばFaireは週におよそ3,000件のPRを自動化されたレビューで処理しており、人間だけのレビューでは追いつけない水準をはるかに超えています。

ただし、プレッシャーは量だけではありません。CodeRabbitのState of AI vs Humanレポートでは、AIが生成したPRには、人間が書いたPRよりも多くの問題が表面化することが分かりました。つまり、量に応じてレビュー能力も成長させなければ、品質が下がります。本番環境で機能しているパターンは、スタイル、バグ、リンターの検出、セキュリティの検出を含めた1回目のパスをAIが担当し、人間のレビュアーはアーキテクチャと設計上の判断に注意を集中させる、というものです。

このレビュー能力の問題は、ガバナンスフレームワークが文書化される前から、本番運用のチームに現れます。たとえばfreeeでは、AIが生成したPRの量にCodeRabbitを重ねたエンジニアたちが、6か月間でレビュアーの時間を32.8週間分節約しました。

同じようにTaskrabbitでは、CodeRabbitによるAI支援のコードレビューを採用した後、チームは平均のマージ時間を25%以上短縮し、10日から7日にしました。

CodeRabbitはPR、IDE、CLIでレビューを提供します。ツール連携とリポジトリの指示は、AI生成コードと人間が書いたコードのレビューを支援します。対象範囲は設定、言語、利用できるコンテキストによって異なり、レビュー層はアクセス制御とCIを補完します。

4. 人間のレビューを意味のあるものにする監査証跡

監査証跡が欠けている問題への対策は、「何かが承認された」という事実だけでなく、本当に何が起きたかを捉えるロギングです。NIST AI RMFのMEASURE機能は、AIシステムの再較正、緩和、撤去に関する意思決定について、「追跡可能な根拠」を求めています。

実装上は、エージェントID、タスクの範囲、コミット、チェック、承認記録を保存します。証跡の保存先には、アクセス制御、保持期間、改ざん対策を定めてください。PR履歴だけを不変のログと説明するべきではありません。

監査証跡が価値を持つのは、ループに人間がいて、意味のある意思決定が行われている場合だけです。シンガポールのAgentic AI Governance Frameworkは、さらに踏み込みます。承認チェックポイントが存在するかどうかだけでなく、レビュアーが反射的に承認するのではなく、本当に意思決定できるように設計されているかを問うのです。

差分が大きすぎる、あるいは締め切りが厳しすぎる、といった理由で形式的に判子を押されているチェックポイントは、名ばかりのチェックポイントです。

標準のすり合わせ：NIST、ISO 42001、EU AI ActがSDLCにどう対応するか

開発時の記録は、組織のガバナンスプログラムを支える証跡になります。それだけで準拠や認証を証明するものではありません。

NIST AI RMFは任意のリスク管理フレームワークです。責任者、意思決定の文書、レビューの証跡は、その実装に役立ちます。

ISO/IEC 42001は組織のAIマネジメントシステムに対する要件を定めています。CIチェックと監査記録はその証跡の一部であり、規格全体をカバーするものではありません。

EU AI Actの義務は、システム、意図された用途、組織の役割によって異なります。コーディングエージェントを使うだけで、すべての開発ワークフローが高リスクAIシステムになるわけではありません。適用範囲、必要な証跡、現在の適用日程は、担当の法務・コンプライアンス責任者が確認します。

ガバナンスは、コードがある場所に置かなければならない

リスクデータと本番環境での障害は、1つの結論を指し示しています。AIエージェントガバナンスは、誰も読まないポリシードキュメントの中には置けません。PRの中、CIパイプラインの中、ブランチ保護ルールの中、そしてレビューコメントの中に置かなければならないのです。強制層は、人間が差分を読む速度ではなく、エージェントがコードを生成する速度で動かなければなりません。

CodeRabbitを使っているエンジニアリングチームは、コードが本番へ流れていく場所、つまりPRレビュー、マージ時のチェック、人間が依然としてループに残った状態での監査可能性、これらの場所でガバナンスを運用に落とし込んでいます。ルーチンとなるレビューの層をCodeRabbitが受け持つことで、シニアエンジニアは、本当に人間の判断を必要とする意思決定に注意を集中できます。

2026年のGoogle DORA AI ROIサマリーはこう述べています。「モデルへの問い合わせコストはゼロに近づきつつあり、導入に伴う本当の金銭的負担はガバナンスコストへとシフトした」。AIコーディングエージェントによる生産性向上は本物です。そしてそれを統制するコストもまた、本物です。

まず1つのリポジトリで、各制御の責任者を決めます。許可する行動、禁止する行動、例外をテストしてから展開してください。コーディングエージェントのポリシー実装ガイドでは、この枠組みを設定へ落とし込む方法を説明しています。