更新日:2026年8月3日
11分で読めます
AIエージェントは、各ステップで人によるレビューを介さずに、コードの記述、プッシュ、デプロイを行うことができます。アクセス、権限、監査証跡を統制する実践的なフレームワークを解説します。

AIによるコード補完は、設計の段階から人によるレビューをプロセスに組み込んできました。開発者がコードを入力すると提案が表示され、それを採用するかどうかは人が判断します。リリース前には、すべての行を必ず人の目で確認していました。
エージェント型AIは、このレビューのループを崩します。エージェントはマージリクエストを作成し、ツールを呼び出し、CI/CD設定を変更し、変更をプッシュすることができますが、その一つひとつの操作を人がレビューするとは限りません。さらに、エージェントが外部のツールやデータソースに自ら接続できるようにするModel Context Protocol(MCP)が加わることで、エンジニアリングリーダーが向き合う問いも変化します。もはや「どのモデルが最も優れたコードを書くか」ではなく、「このエージェントに何が許可されているのか、そしてその行動を事後に証明できるのか」が問われているのです。
1,500人を超える開発者およびテクノロジーリーダーを対象としたGitLab独自の調査では、回答者の73%がコードの長期的な保守性に懸念を抱いており、86%が「明確なガバナンスがなければ、AI生成コードは従来の開発手法よりも速く技術的負債を積み上げてしまう」という点に同意していることが明らかになりました。
この記事では、エージェント型AIのガバナンスにおいて各組織が直面し始めている課題に、どう先手を打って対応すればよいかを解説します。ソフトウェア開発におけるエージェント型AIのガバナンスフレームワークを紹介し、何を制御すべきか、人によるレビューがどこに残るべきか、導入状況をどう測定するか、そしてGitLab Duo Agent Platformへの標準化を進めるチームのための実践的なチェックリストを取り上げます。
対話型のコーディングアシスタントにおけるセキュリティモデルは、あらゆる段階に人が関与しているため、シンプルです。開発者が質問を投げかけ、提案をレビューし、採用するか却下するかを判断します。
自動化されたワークフローにおけるエージェント型AIには、異なるガバナンスアプローチが求められます。エージェントがテストを実行し、設定を変更し、ソフトウェア提供ライフサイクル全体にわたる複数ステップの操作を、人がその都度レビューすることなく行えるようになると、問うべき論点は次のように変わります。
すでに多くのチームがこの課題を実感しています。DevSecOps専門家の92%が、AI生成コードに関して何らかのガバナンス上の課題を抱えていると回答しており、具体的な懸念は上記の論点に直結しています。
主な懸念事項は次のとおりです。
いったんプロジェクトでエージェントの利用が承認されると、多くの場合、そのエージェントは誰かが事前にレビューすることなく、コードの記述、削除、変更のプッシュを行えるようになります。しかし、コードベースに反映される内容については、それを行ったのが人間かエージェントかにかかわらず、組織が責任を負うことに変わりはありません。
エージェント型AIのガバナンスは、コード補完のガバナンスに単に追加されるものではありません。ID、権限、監査可能性を軸に据えた、まったく異なるアプローチです。
エージェントがMCPのようなプロトコルを通じてツールを呼び出し、外部システムに接続できるようになると、権限管理こそが制御の要となります。実効性のあるガバナンスモデルは、エージェントを実行する前に、次の3つの問いに答えられるものです。
実際には、これはいくつかのレイヤーが連携して機能する形になります。
目指すべきは、エージェントの権限を、組織がすでに人間の権限に対して行っているのと同じように扱う制御基盤です。つまり、ロールベースで、監査可能であり、すべてのプロジェクトで一貫している状態です。
ソースコードは企業が持つ最も機微な資産の一つであり、それを読み取るAI機能はすべて、データの取り扱いに関する問いを生じさせます。エージェント型AIを本格的に展開する前に、エンジニアリングおよびセキュリティのリーダーは、通常、いくつかの重要な問いに対して明確な答えを求めます。
規制の厳しい業界の組織にとって、「サブプロセッサはどこに所在するか」という問いへの答えは、多くの場合「自社のインフラの外には一切存在しない」でなければなりません。だからこそ、セルフホストは単なる導入方式の好みではなく、ガバナンス上の重要なレバーとなります。セルフホストの選択肢を利用すれば、チームは自らが制御するインフラ上でAIエージェントを完全に運用しながら、利用状況を正確に追跡し、規制当局の要件も満たすことができます。
自社モデル持ち込み(BYOM)への対応は、これをさらに一歩進めるものです。管理者は、社内ですでに検証済みのモデルを接続し、特定のモデルを特定のエージェントフローに割り当てることができます。この方法により、機微なワークフローは組織が信頼するモデルに固定しつつ、機微性の低いワークフローではマネージド型のオプションを利用するといった使い分けが可能になります。
ガバナンスとは、エージェントの自律的な行動を一律に禁じることではありません。自律性がどこで終わり、レビューがどこから始まるのかを、意図的に決めることを意味します。実効性のあるポリシーは、通常、次の2つのモードを区別します。
コードレビュー、テストと検証、デプロイ承認は、いずれも次のような問いへの答えを通じて定義しておくべきです。
実際には、各チェックポイントにはそれぞれ固有の実施メカニズムが必要です。例えば次のような形が考えられます。
各チームの慣習に委ねるのではなく、組織全体で統一したAIガバナンスポリシーを策定することをおすすめします。これにより、利用方法とポリシーの一貫性が保たれるとともに、監査担当者がAIの利用状況を検証しやすくなります。
こうした承認を、チャットのスレッドやレビュー担当者の記憶の中に消えていくままにするのではなく、構造化された記録として残しておくことには、長期的なメリットがあります。前四半期に認められた例外や、それがどのポリシーバージョンのもとで承認されたか、誰が承認したかといった情報は、監査担当者と将来のエージェントの双方が参照すべき、組織としての判断そのものです。
意思決定を、永続的でクエリ可能なイベントとして扱う企業には、次にレビューを行う人間またはエージェントが、ゼロからではなく、追加の文脈を踏まえた状態で始められるという利点もあります。
ディシジョンレイヤーについて詳しく知り、意思決定イベントの記録がソフトウェア開発にどのような影響を与えうるかをご覧ください。
最初から追跡しておくべき指標は5つのカテゴリーに分かれており、これらは個別にではなく、併せてレビューすべきものです。リスク指標を伴わない導入率の急上昇自体が、一つの警告サインとなるためです。
これら5つの指標をすべて併せて追跡することで、AI導入の問題を早期に発見できます。導入率や採用状況の面では順調に見えても、水面下でリスクが蓄積し、半年後の監査で初めて表面化するというケースもあります。上記の指標を用いることで、組織にとってのAIの価値を総合的に把握できます。
GitLab Duo Agent Platformへの標準化を進めるチームに向けて、パイロットの範囲を超えてエージェント型AIを拡大する前に確認しておきたい、実践的なチェックリストを紹介します。
このチェックリストは、リリースサイクルごとに見直しましょう。エージェント型AIのガバナンスは、一度設定すれば終わりというものではありません。新しいエージェント、新しいツール、新しいモデルが登場するたびに、ガバナンス上の論点が再び浮上することが少なくないためです。
エージェント型AIは、ガバナンスの対象そのものを変えます。コード補完が問うていたのは、その提案が良いものかどうかを開発者に確認することでした。エージェント型AIが問うのは、エージェントが何に触れることを許されているのか、誰がそれを承認したのか、そして後からそれを証明できるのか、という点です。
これらの問いに十分に答えるには、後から積み上げるのではなく、プラットフォーム自体に組み込まれたガバナンスが必要です。GitLab Duo Agent Platformは、実際に作業が行われるプラットフォームに、AIカタログ、承認ガードレール、監査イベントストリーミングを直接組み込んでいるため、ガバナンスが後付けになることはありません。ガードレールはワークフローと並行して動く別プロセスではなく、ワークフローそのものの一部であるため、チームはAIによるスピードとエンタープライズレベルの統制を同時に得られます。
GitLab Duo Agent Platformの無料トライアルを今すぐ始めましょう。Freeプランでは、簡単な手順でサインアップできます。すでにGitLab PremiumまたはUltimateをご利用の場合は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご利用いただけます。
このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。
フィードバックを共有するよくある質問
人間の開発者があらゆる提案をレビューする対話型のコード補完とは異なり、エージェント型AIはテストの実行や設定の変更など、複数のステップにわたる操作を、各段階で人手を介さずに実行できます。そのため、問われるべき論点は「どのモデルが最も優れたコードを書くか」から、「このエージェントに何を許可するか、そしてその行動を証明できるか」へと変化しています。
強固なガバナンスモデルの中心となるのは、ID、権限、そして監査可能性です。主な構成要素として、エージェントとフローを一元管理するカタログ、エージェントの操作を要求元の人間ユーザーに紐づけるコンポジットアイデンティティ、自律性を制御するツール承認ガードレール、そして挙動の乗っ取りを防ぐプロンプトガードレールが挙げられます。
エンジニアリングおよびセキュリティ部門のリーダーは、通常、データの取り扱いに関する3つの中核的な問いに注目します。ベンダーが自社のコードでモデルを学習させているか、入出力データの所有権はどこにあるか、そしてサブプロセッサの所在地はどこか、という点です。規制の厳しい業界では、インフラの制御とデータレジデンシーを維持するために、セルフホストや「自社モデル持ち込み(BYOM)」といった選択肢がよく利用されます。
組織は、開発者が関与する「対話型」の作業と、CI/CDパイプラインのような「自動化・ヘッドレス型」の作業とを区別して考える必要があります。コードレビュー、テストと検証、デプロイ承認のチェックポイントは、各チームの慣習に委ねるのではなく、マージリクエスト承認ポリシー、ツール承認ガードレール、スキャナーの強制適用といった仕組みを通じて徹底すべきです。
チームは、導入状況(利用レベル)、採用状況と品質(リバート率や手戻りの発生状況)、リスク(ポリシー違反やガードレールによる介入の発生状況)、修正対応(脆弱性の解消にかかる時間)、そしてROI(コストに対する削減時間)という5つの指標を統合的に追跡すべきです。これらを併せてモニタリングすることで、導入率や効率化の効果だけに注目して、潜在的なリスクが蓄積してしまう事態を防げます。