CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 04, 2026
1 min read
AI agent governance: A framework for engineering leadersの意訳です。
コーディングエージェントは今や、人間のレビュアーが読めるよりも速くプルリクエスト（PR）を開きます。誰も内容を十分に理解しないままPRがマージされると、チームは自分たちでは説明できない本番コードを抱え込むことになります。
AIコーディングがもたらす生産性向上は、本物です。一方で、エージェントが生成するコードの量がチームの意味あるレビュー能力を超え始めると、検証の負債もまた本物として積み上がっていきます。
AIエージェントガバナンスは、エージェントが生成するものと、人間が検証するものとの間のギャップを、チームがどう埋めるかという考え方です。ソフトウェア開発ライフサイクル（SDLC）の中で自律的に動くコーディングエージェントに対してルールを設定し、どのエージェントが行動できるか、何にアクセスしてよいか、そして成果物がリリースされる前にどう検証されるかを決めていきます。
本記事ではこの後、AIエージェントガバナンスが現場で何を意味するのか、リスクがどこに集中するのか、本番運用のチームで機能している強制層はどのようなものか、そして主要な標準（NIST AI RMF、ISO/IEC 42001、EU AI Act）がエンジニアリーダーがすでに持っているSDLCのコントロールにどう対応するかを解説していきます。
AIエージェントガバナンスとは、自律的なAIエージェントが何をしてよいか、何にアクセスできるか、その行動をどう検証するかについて、ルールを設定する取り組みのことです。SDLCの中では、PRを書き、設定を変更し、コードを本番環境へ反映するコーディングエージェントを統制することを意味します。
AIエージェントガバナンスは、従来のモデルガバナンスとは別物です。モデルがリリースされる前の学習データやモデルの振る舞い、バイアス、評価といった部分に焦点を当てるのではなく、AIエージェントガバナンスはその合間の運用層をカバーします。具体的には、どのエージェントが行動したのか、いずれのアクセスを許可されていたのか、実際には何を行ったのか、そして本番環境に到達する前に人間が出力を検証したかどうか、といった内容です。
アプリケーションセキュリティ（AppSec）とも別物です。AppSecは、すでに存在するコードの中の脆弱性パターンを捕まえる領域です。
モデルガバナンスは「そのモデルはデプロイしても安全か」を問います。AppSecは「そのコードは動かしても安全か」を問います。エージェントガバナンスは「いまエージェントが取った行動は、認可され、レビューされ、記録されていたか」を問うものです。
現場のエンジニアリングワークフローでエージェントがコードを書く状況では、ガバナンスの核となる問いは、エージェントのID、説明責任、トレーサビリティ、アクセス権、取った行動、そして何か問題が起きたときにどう止められるか、といった点に及びます。たとえば次のような問いです。
こうした問いに現場で答えるということは、エージェントが動いている間にできることを明確に制限することを意味します。実行時に制限を強制しなければ、ポリシーと現場との間のギャップこそが、これから挙げるリスクの温床になります。
コーディングエージェントが何にアクセスでき、何を行い、何をリリースしてよいかについて誰もルールを定めないと、4つのリスクが立ち上がります。それぞれのリスクは特定のガバナンス制御に対応していて、その制御が欠けると、エージェントがコードを生成する速度で問題が積み上がっていきます。
ガバナンスがないと、コーディングエージェントは広いデフォルト権限を引き継ぎます。コードベース全体を読み、内部・外部のAPIを呼び、シェルコマンドを実行し、接続されたどのリポジトリにもPRを開けるということです。それらの権限を特定のタスクやスコープに結びつけるものは何もなく、つまり1つの汚染されたプロンプトや乗っ取られた指示ファイルだけで、チームが触れさせるつもりのなかったシステムにまで、エージェントのアクセスが行動として広がってしまいます。
エージェントがインフラに触れると、リスクはさらに悪化します。たとえば、Terraformファイルへの書き込み権限と、保護されたブランチへのプッシュ権限を持つエージェントは、本番環境で動いていることになります。これらの変更にゲートをかけるロールベースのアクセス制御（RBAC）、スコープの絞られたトークン、承認ポリシーがなければ、午前2時に何かが壊れたとき、誰がその行動を認可したのか、答えを返せません。
ガバナンスがないとき、エージェントが書いた変更の執筆者の連鎖は消えてしまいます。エージェントがコードを生成し、人間がマージをクリックする、その間にどのエージェントが動いたのか、どのプロンプトを受け取ったのか、他にどのツールを呼び出したのか、途中でどのリビジョンを捨てたのか、何も記録されません。
2025年のサンフランシスコ大学の研究（IEEE-ISTAS）では、400件のコードサンプルを、各イテレーションの間に人間のレビューを挟まずに自動化されたAIによる5回の改善ラウンドにかけたところ、クリティカルな脆弱性が37.6%増加することが分かりました。著者らの結論は、イテレーション間に人間のレビューを挟むことが緩和策である、というものでした。
各リビジョンを特定のエージェント、プロンプト、レビュアーへ紐づける不変ログがなければ、その脆弱性がどう紛れ込んだのかをチームは復元できず、次の脆弱性も同じパターンを繰り返します。
コーディングエージェントは、コードベースで目にしたパターンを再現します。一貫していないものや、最適でないものも含めて、です。チームの基準をコード化したガバナンス層（コードガイドライン、AGENTS.mdファイル、パスベースの指示、マージ時のポリシーチェック）がなければ、過去の平均ではなく、いまのチームの規約のほうへエージェントの出力を引き寄せる仕組みがありません。
CodeRabbitによる470件のPRのレビューでは、コードの可読性に関する問題が、AIのPRでは3倍以上の頻度で見つかりました。ガバナンスは、エージェントが読み、レビュアーが強制するアーティファクトに基準をコード化することで、このギャップを埋めます。基準が、レビュー済みのポリシーアーティファクトに収まっていて、エージェントがそれを取り込み、レビュアーがすべてのPRで強制している状態になれば、ドリフトは四半期をまたいで積み上がる代わりに、生成の瞬間で止まります。
中央集約されたガバナンスがなければ、チームごとのエージェント構成は、それぞれが独立したポリシーの島になります。あるチームはmainへのプッシュを許可し、別のチームは禁止しています。あるチームはスコープを絞ったトークンを使い、別のチームはすべてを管理者として動かしています。あるチームはAIのPRにセキュリティレビューを強制し、別のチームはしていません。
Apiiroの分析を取り上げたCSO Onlineの記事では、AIが生成したコードが毎月10,000件を超える新たなセキュリティ検出を持ち込んでおり、6か月で10倍の急増を意味すると伝えています。その量こそが、組織全体で異なるエージェントが「良いコード」の異なる解釈を当てはめたときに生まれる、スプロールの結果です。
CIに置かれた共有ルールと、すべてのPRに適用される一貫したレビュー層を通じて中央集約されたガバナンスを適用することが、こうしたポリシーの島々を、単一の強制可能な基準へとまとめあげるものです。
ここまで挙げた4つのリスクは、結局のところ同じギャップに行き着きます。エージェントがコードをリリースする速度に追従して動く強制層が、存在していないのです。このギャップを埋めているエンジニアリングチームは、SDLCの4つのポイントにガバナンスを差し込んでいます。それぞれが上記のリスクのどれかに対応していて、エンジニアリングリーダーがすでに持っていて、そのまま拡張できるものばかりです。
スコープのない権限への対策は、エージェントのすべての行動を「実行前にポリシーチェックを通る必要があるもの」として扱うことです。現場で機能するフレームワークは、エージェントの行動を次の3段階に分類します。
実行環境での強制は、エージェントと、エージェントが触れられるシステムとの間に挟まり、ファイル操作・API呼び出し・シェルコマンドのいずれも、実行前にこの階層化されたポリシーに照らして評価します。
ここで使う運用上のコントロールは、人間のエンジニアにアクセス権を設定したことがある人なら見慣れたものです。RBAC、監査ログ、スコープを絞ったトークンは、そのままコーディングエージェントにも当てはまります。200のリポジトリにPRを開けるが、インフラ設定には触れず、保護されたブランチにもプッシュできないエージェントは、統制されているエージェントです。一括での書き込み権限は、障害発生後の振り返りで必ず取り上げられることになります。
強制力のない基準への対策は、エージェントと継続的インテグレーション（CI）の両方が読めるアーティファクトに、基準を書き込むことです。Open Policy Agent（OPA）やConftestのようなポリシー・アズ・コードのツールは、マージ時にコードとインフラの変更を、宣言的なルールに照らして評価します。ハードコードされた認証情報を禁じる、公開関数にはドキュメントを必須にする、承認済みレジストリからの依存関係しか許さない、といったルールです。
これらのチェックが必須のステータスチェックとして動いていれば、すべてのチェックを通過しない限り、PRはマージできません。AIが生成したコードも、人間が書いたコードと同じゲートを通ることになります。
また、エージェントがセッション開始時に取り込むAGENTS.md、CLAUDE.md、SKILL.mdファイルに基準をコード化しているチームも増えています。これらのファイルは、機械が読めるポリシーアーティファクトとして機能します。エンジニアリング基準のドキュメントそのものを、レビューで捕まえる（あるいは見逃す）のではなく、生成の瞬間に強制する形に書き換えたものです。
CodeRabbitを使っているチームは、同じアプローチをPre-Merge Checksで広げられます。マージ前に動き、実装がチームの定めた要件とポリシーに本当に沿っているかを強制してくれます。
CIにコード化された基準は、決定的なチェックとして表現できるルールはカバーします。しかし、良いコードベースを形作るものの大半（アーキテクチャ的な収まり、命名規約、その変更が本当に正しい問題を解いているかどうか）は、判断を必要とします。AIコードレビューは、エージェントがコードを生成する速度で、すべてのPRにその判断を適用し、ステータスチェックだけでは表現できない基準の部分を強制してくれる層です。
この層を「オプションではなく必須」にしているのは、量が多いためです。たとえば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に行き着くことがよくあります。CodeRabbitは、PR、統合開発環境（IDE）、コマンドラインインターフェイス（CLI）にまたがるレビュー層に位置します。すべてのPRに対して、組み込みの静的解析ツール、リンター、SAST（静的アプリケーションセキュリティテスト）ツールを実行し、コードガイドラインやパスベースの指示にコード化されたチーム基準を適用します。これによってチームは、AIが生成したコードにも人間が書いたコードにも、単一の強制ポイントを持てるようになります。
監査証跡が欠けている問題への対策は、「何かが承認された」という事実だけでなく、本当に何が起きたかを捉えるロギングです。NIST AI RMFのMEASURE機能は、AIシステムの再較正、緩和、撤去に関する意思決定について、「追跡可能な根拠」を求めています。
現場の言い方をすれば、これは、各エージェントが何を生成したか、どのレビュアーがいつ承認したかを記録した不変ログを必要とする、ということです。ツールを評価するエンジニアリングリーダーは、監査ログを取得できることを調達要件として扱うべきです。
監査証跡が価値を持つのは、ループに人間がいて、意味のある意思決定が行われている場合だけです。シンガポールのAgentic AI Governance Frameworkは、さらに踏み込みます。承認チェックポイントが存在するかどうかだけでなく、レビュアーが反射的に承認するのではなく、本当に意思決定できるように設計されているかを問うのです。
差分が大きすぎる、あるいは締め切りが厳しすぎる、といった理由で形式的に判子を押されているチェックポイントは、名ばかりのチェックポイントです。
AIエージェントガバナンスのための3つのガバナンス標準は、SDLC内にすでに存在するコントロールに対応します。どれも、エンジニアリング組織の外側に別個のAIガバナンスプログラムを立ち上げることを求めてはいません。求められているのは、文書化され、監査可能な状態になった、これまでに述べた強制層と同じものです。
NIST AI RMFは、組織全体のAIリスクに対する役割と責任の文書化（GOVERN 2.1）と、AIリスク管理および意思決定のための説明責任の仕組み（GOVERN 2.3）を求めています。SDLCの文脈に置き換えれば、監査ログの層に加えて、各ポリシーアーティファクトに明確なオーナーを置くことに対応します。
ISO/IEC 42001は、AIマネジメントシステムに対する要件を定めています。リスクアセスメント、定期的な内部監査、AIシステムの意図された用途の文書化などが含まれます。CIに置かれた基準と監査証跡の層が、ISO/IEC 42001がエンジニアリング組織に求める内容のほとんどをカバーします。
EU AI Actは、第26条で展開者（デプロイヤー）の義務を課しています。つまり、高リスクのAIシステムを展開する組織は、ツールベンダーと並んでコンプライアンス責任を負うことになります。AI Actの規則の大半は2026年8月から、特定の高リスクAIシステムの義務は2027年8月から適用されます。展開者の義務は、監査ログと人間のチェックポイントの層に、そのまま降りてきます。だからこそ、これらの層は期限を迎えてから整えるのではなく、その前に揃えておく必要があります。
3つのフレームワークに共通する筋道はこうです。あなたのSDLCにすでに存在するガバナンス制御（ID、監査証跡、人間のチェックポイント、ポリシー・アズ・コード）こそが、規制当局が期待しているものなのです。エンジニアリングチームに、別個のAIガバナンスプログラムは必要ありません。必要なのは、すでに持っているコントロールを、正式なものにすることです。
リスクデータと本番環境での障害は、1つの結論を指し示しています。AIエージェントガバナンスは、誰も読まないポリシードキュメントの中には置けません。PRの中、CIパイプラインの中、ブランチ保護ルールの中、そしてレビューコメントの中に置かなければならないのです。強制層は、人間が差分を読む速度ではなく、エージェントがコードを生成する速度で動かなければなりません。
CodeRabbitを使っているエンジニアリングチームは、コードが本番へ流れていく場所、つまりPRレビュー、マージ時のチェック、人間が依然としてループに残った状態での監査可能性、これらの場所でガバナンスを運用に落とし込んでいます。ルーチンとなるレビューの層をCodeRabbitが受け持つことで、シニアエンジニアは、本当に人間の判断を必要とする意思決定に注意を集中できます。
2026年のGoogle DORA AI ROIサマリーはこう述べています。「モデルへの問い合わせコストはゼロに近づきつつあり、導入に伴う本当の金銭的負担はガバナンスコストへとシフトした」。AIコーディングエージェントによる生産性向上は本物です。そしてそれを統制するコストもまた、本物です。
すべてのエンジニアリング組織は、ガバナンス層を必要としています。唯一の問いは、あなたの組織のそれが、エージェントがコードをリリースする速度に追いついているか、という点です。あなたの組織にもガバナンス層を置く準備はできていますか。今すぐ、CodeRabbitの14日間無料トライアルを始めてみてください。
