7月31日、GitLabが「How to govern agentic AI, MCPs, and AI code assistants」と題した記事を公開した。エージェントAIはマージリクエストを開き、ツールを呼び出し、CI/CD設定を変更し、コードをプッシュする——人間の確認を挟まないまま。従来のコード補完が前提としていた「すべての行を人間が承認する」というループを、エージェントはそもそも必要としない。この構造的な変化に対し、GitLabはどのようなガバナンスフレームワークで応えようとしているのかが、本記事の核心だ。
コード補完とエージェントは「別物」のガバナンスが必要
AIコード補完は、人間のレビューを設計上の前提に組み込んでいた。開発者が入力し、候補が表示され、人間が採否を決める。すべての行を人間が確認してからコードがリリースされる。
エージェントAIはそのレビューループを断ち切る。 エージェントはマージリクエストを開き、ツールを呼び出し、CI/CD設定を変更し、変更をプッシュする。それぞれのステップを人間が確認しないまま進むこともある。さらにModel Context Protocol（MCP）（エージェントが自律的に外部ツールやデータソースへ接続できるプロトコル）が加わると、問いかけが変わる。「どのモデルが最良のコードを書くか？」から「このエージェントは何をしてよいのか、そして何をしたかを証明できるか？」へ。
GitLabが1,500人以上の開発者・技術リーダーを対象に行った調査では、73%がAI生成コードの長期保守性を懸念しており、86%が「明確なガバナンスなしにAIは技術的負債を従来開発より速く蓄積する」と同意している。また92%のDevSecOpsプロフェッショナルが何らかのガバナンス上の課題を感じていると回答している。なお元記事では調査対象・実施時期・サンプリング手法の詳細は明示されていないが、同社が公開している調査レポート原文で確認できる。
ガバナンスの核心：Identity・権限・監査可能性
エージェントがツールを呼び出し、外部システムに接続できる環境では、パーミッション管理がコントロールの要になる。GitLabが示すガバナンスモデルは、エージェント実行前に3つの問いに答えることを求める。
- どのエージェント・フローが許可されているか？
- どこで動作することが許可されているか？
- エージェントはどのモデルを使えるか？
以下で紹介するAIカタログ・コンポジットID・各種ガードレールは、いずれもGitLab Duo Agent Platformの構成要素として提供されており、プラットフォーム全体でポリシーを一元管理できる点がアーキテクチャ上の特徴だ。具体的には以下の仕組みが組み合わさる。
- AIカタログ（中央集権型）: 各チームが独自にエージェント統合を構築するのではなく、管理者が公開するものを一元管理する。
- コンポジットID（Composite Identity）: エージェントのすべての操作を、指示を出した人間ユーザーのIDと紐付ける。エージェント単体では認証が成立しない設計で、エージェントと人間の両者が認証・認可されてはじめてリソースへのアクセスが許可される。
- ツール承認ガードレール: 個々のツールを「自律実行」「レビュー待ち」「常時ブロック」の3段階で制御できる。ファイルの書き込みやリソースの削除といったセンシティブな操作は、承認が下りるまで実行されない。
- プロンプトガードレール: Webページ、Issueのコメント、攻撃者が制御するファイルなど、信頼できない入力によってエージェントの挙動を乗っ取ろうとする試み（プロンプトインジェクション）を、事後ログではなくリアルタイムで検出する。
どこに人間レビューを残すか
ガバナンスはエージェントの自律性を全否定するものではない。「どこで自律性を終わらせ、レビューを始めるか」を意図的に決める作業だ。
記事では2つのモードを区別している。
- インタラクティブな作業: 開発者が画面の前にいて、各提案を承認・拒否するモード。既存のAIコード補完がこれにあたる。
- 自動化・ヘッドレス作業: CI/CDパイプライン内でエージェントが動作するなど、開発者がリアルタイムで監視しないモード。ここでは、アクション前（ツール承認ガードレール）またはアクション直後（監査ログ）にレビューを組み込む必要がある。
コードレビュー、テスト・検証、デプロイ承認の各フェーズについて、「エージェントが単独で完了できるか」「名指しの人間サインオフが必要か」をポリシーとして明文化することが推奨されている。承認イベントはチャットスレッドで消えるのではなく、クエリ可能な構造化レコードとして残すことで、監査担当者も次のレビュアー（人間でもエージェントでも）もゼロから出発せずに済む。
AIロールアウトを測定する5つの指標
記事では、エージェントAIの展開を評価するために以下5カテゴリの同時追跡を推奨している。採用率だけ見てリスク指標を無視するのは、それ自体が警告サインだと明記されている。
- 採用（Adoption）: AIフィーチャーの週次アクティブユーザー数、実行フロー数、エージェント機能のオン/オフ状況
- 品質（Acceptance & Quality）: AI支援による変更のリバート率、AI作成マージリクエストが手直しなしにレビューを通過する頻度
- リスク（Risk）: ツール承認ガードレールが発動した回数と、その結果ブロック・変更された件数、ポリシー違反の発生件数
- 修復（Remediation）: 自動修復された脆弱性の割合、フラグ後の解決までの時間
- ROI: エージェントが担うようになったタスクでの開発者の時間節約量と、解決1件あたりのコスト（クレジット・計算コスト）の比較
GitLab Duo Agent Platform 導入前チェックリスト
パイロット展開を超えて本格展開する前に確認すべき項目を、元記事は列挙している。以下では最初に着手すべき3項目（★）を編集部が整理した上で、全項目を掲載する。優先度の根拠は「未設定のまま展開するとガバナンスの根幹が機能しない」かどうかだ。
★ 最初に着手すべき3項目
- コンポジットIDの設定: すべてのエージェント操作を要求した人間と紐付ける。これが未設定だと、誰がエージェントに何をさせたかの追跡が原理的に不可能になる。
- ツール承認ガードレールの設定: ツールの機密度に応じて「常時許可」「常時確認」「常時拒否」を割り当てる。ファイル削除・外部API呼び出しなどのセンシティブな操作を先にブロック状態にしておくことで、展開初期のインシデントリスクを大幅に下げられる。
- 監査イベントストリーミングの有効化: エージェントのすべての操作を既存の監査証跡に記録する。後から「あの操作は誰が許可したか」を問われたとき、ログがなければ答えられない。
※編集部の考察：上記3項目はいずれも設定コストが低く、かつ未設定時の影響が大きい。他の項目はパイロット後でも挽回できるが、この3点は展開初日から必要だ。
全チェックリスト
- AI透明性センターでデータ利用・モデルベンダー・サブプロセッサのコミットメントを確認
- プラットフォームレベルで承認済みエージェント・フローをAIカタログ経由で公開（チームごとの独自設定を防ぐ）
- ツールの機密度に応じてツール承認ガードレールを「常時許可」「常時確認」「常時拒否」に設定
- コンポジットIDを設定し、すべてのエージェント操作を要求した人間と紐付ける
- 規制対象ワークロードについてはセルフホストおよびBring Your Own Model（BYOM）オプションをデータレジデンシー要件と照合
- コードレビュー・テスト・デプロイ承認の各フェーズで人間レビュー必須ポイントを文書化
- 監査イベントストリーミングをオンにして、エージェントのすべての操作を既存の監査証跡に記録
- ロールアウト指標（採用・品質・リスク・修復・ROI）をパイロット拡張前に定義し、定期的に合わせて確認
このチェックリストはリリースサイクルごとに見直すことが推奨されている。新しいエージェント、ツール、モデルが追加されるたびにガバナンスの問いは再浮上する。
詳細はHow to govern agentic AI, MCPs, and AI code assistantsを参照していただきたい。
