更新日:2026年8月3日

11分で読めます

エージェント型AI、MCP、AIコードアシスタントを統制する方法

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

AIによるコード補完は、設計の段階から人によるレビューをプロセスに組み込んできました。開発者がコードを入力すると提案が表示され、それを採用するかどうかは人が判断します。リリース前には、すべての行を必ず人の目で確認していました。

エージェント型AIは、このレビューのループを崩します。エージェントはマージリクエストを作成し、ツールを呼び出し、CI/CD設定を変更し、変更をプッシュすることができますが、その一つひとつの操作を人がレビューするとは限りません。さらに、エージェントが外部のツールやデータソースに自ら接続できるようにするModel Context Protocol(MCP)が加わることで、エンジニアリングリーダーが向き合う問いも変化します。もはや「どのモデルが最も優れたコードを書くか」ではなく、「このエージェントに何が許可されているのか、そしてその行動を事後に証明できるのか」が問われているのです。

1,500人を超える開発者およびテクノロジーリーダーを対象としたGitLab独自の調査では、回答者の73%がコードの長期的な保守性に懸念を抱いており、86%が「明確なガバナンスがなければ、AI生成コードは従来の開発手法よりも速く技術的負債を積み上げてしまう」という点に同意していることが明らかになりました。

この記事では、エージェント型AIのガバナンスにおいて各組織が直面し始めている課題に、どう先手を打って対応すればよいかを解説します。ソフトウェア開発におけるエージェント型AIのガバナンスフレームワークを紹介し、何を制御すべきか、人によるレビューがどこに残るべきか、導入状況をどう測定するか、そしてGitLab Duo Agent Platformへの標準化を進めるチームのための実践的なチェックリストを取り上げます。

エージェント型AIのガバナンスに異なるアプローチが必要な理由

対話型のコーディングアシスタントにおけるセキュリティモデルは、あらゆる段階に人が関与しているため、シンプルです。開発者が質問を投げかけ、提案をレビューし、採用するか却下するかを判断します。

自動化されたワークフローにおけるエージェント型AIには、異なるガバナンスアプローチが求められます。エージェントがテストを実行し、設定を変更し、ソフトウェア提供ライフサイクル全体にわたる複数ステップの操作を、人がその都度レビューすることなく行えるようになると、問うべき論点は次のように変わります。

  • このエージェントは何にアクセスできるか
  • 何を行う権限を持っているか
  • どのような操作を行い、それを事後に証明できるか

すでに多くのチームがこの課題を実感しています。DevSecOps専門家の92%が、AI生成コードに関して何らかのガバナンス上の課題を抱えていると回答しており、具体的な懸念は上記の論点に直結しています。

主な懸念事項は次のとおりです。

  • コードの帰属: そもそも、どのコードがAI生成で、どのコードが人間による記述かを判別できるかどうか。
  • 意図へのトレーサビリティ: AI生成コードを、それが満たすべきだったビジネス要件に遡って紐づけられるかどうか。
  • スケールするドキュメント化: エージェントがコードベースの生成に占める割合を増やしていくにつれ、手作業によるドキュメント化では対応しきれなくなる点。

いったんプロジェクトでエージェントの利用が承認されると、多くの場合、そのエージェントは誰かが事前にレビューすることなく、コードの記述、削除、変更のプッシュを行えるようになります。しかし、コードベースに反映される内容については、それを行ったのが人間かエージェントかにかかわらず、組織が責任を負うことに変わりはありません。

エージェント型AIのガバナンスは、コード補完のガバナンスに単に追加されるものではありません。ID、権限、監査可能性を軸に据えた、まったく異なるアプローチです。

MCP、エージェント、モデルアクセス、ツール権限の制御方法

エージェントがMCPのようなプロトコルを通じてツールを呼び出し、外部システムに接続できるようになると、権限管理こそが制御の要となります。実効性のあるガバナンスモデルは、エージェントを実行する前に、次の3つの問いに答えられるものです。

  1. どのエージェントとフローの利用が許可されているか
  2. どこでの稼働が許可されているか
  3. エージェントはどのモデルを使用できるか

実際には、これはいくつかのレイヤーが連携して機能する形になります。

  • エージェントとフローの一元管理カタログ:各チームが個別にエージェント連携を構築するのではなく、共有のAIカタログを通じて、組織の既存のロールやグループ構造に沿った形で、何を公開するかを管理者が判断できるようにします。
  • コンポジットアイデンティティ すべてのAIエージェントのIDは、その操作を要求した人間ユーザーに紐づけられるべきであり、活動がエージェント単体に帰属することがないようにします。エージェントがリソースへのアクセスを試みる際は、エージェントとそれを指示した人間の両方の主体が、アクセスを許可される前に認証・認可される必要があります。
  • ツール承認ガードレール 個々のエージェントツールは、自律的に実行する、人によるレビューのために一時停止する、あるいは完全にブロックするといった設定が可能です。これにより、ファイルの書き込みやリソースの削除といった機微な操作は、実行前に承認を待つようになります。
  • プロンプトガードレール エージェントはWebページ、Issueのコメント、攻撃者が操作するファイルなど、信頼できない入力を処理することがあるため、プラットフォーム側では、事後にログを残すだけでなく、ワークフローの途中でエージェントの挙動を乗っ取ろうとする試みを検知する必要があります。

目指すべきは、エージェントの権限を、組織がすでに人間の権限に対して行っているのと同じように扱う制御基盤です。つまり、ロールベースで、監査可能であり、すべてのプロジェクトで一貫している状態です。

データプライバシーとセルフホストAI:問うべきこと

ソースコードは企業が持つ最も機微な資産の一つであり、それを読み取るAI機能はすべて、データの取り扱いに関する問いを生じさせます。エージェント型AIを本格的に展開する前に、エンジニアリングおよびセキュリティのリーダーは、通常、いくつかの重要な問いに対して明確な答えを求めます。

  • ベンダーは自社のコードでモデルを学習させているか
  • 入出力データの所有権はどこにあるか
  • サブプロセッサはどこに所在し、そのリストが変更された際には通知を受けられるか

規制の厳しい業界の組織にとって、「サブプロセッサはどこに所在するか」という問いへの答えは、多くの場合「自社のインフラの外には一切存在しない」でなければなりません。だからこそ、セルフホストは単なる導入方式の好みではなく、ガバナンス上の重要なレバーとなります。セルフホストの選択肢を利用すれば、チームは自らが制御するインフラ上でAIエージェントを完全に運用しながら、利用状況を正確に追跡し、規制当局の要件も満たすことができます。

自社モデル持ち込み(BYOM)への対応は、これをさらに一歩進めるものです。管理者は、社内ですでに検証済みのモデルを接続し、特定のモデルを特定のエージェントフローに割り当てることができます。この方法により、機微なワークフローは組織が信頼するモデルに固定しつつ、機微性の低いワークフローではマネージド型のオプションを利用するといった使い分けが可能になります。

Human-in-the-Loop:人によるレビューをどこに残すか

ガバナンスとは、エージェントの自律的な行動を一律に禁じることではありません。自律性がどこで終わり、レビューがどこから始まるのかを、意図的に決めることを意味します。実効性のあるポリシーは、通常、次の2つのモードを区別します。

  • 対話型の作業: 開発者がその場にいて、それぞれの提案を確認し、直接承認または却下します。これは、AIコード補完を通じて多くのチームがすでに理解しているモードです。
  • 自動化・ヘッドレス型の作業: CI/CDパイプライン内でエージェントが稼働するなど、開発者がリアルタイムで見ていない状況です。この場合、レビューは操作の実行前(ツール承認ガードレールによる)、または実行直後(人が確認できる監査証跡による)のいずれかで行う必要があります。

定義しておくべき重要な意思決定ポイント

コードレビュー、テストと検証、デプロイ承認は、いずれも次のような問いへの答えを通じて定義しておくべきです。

  • これらのうち、エージェントが単独で完了できるものはどれか
  • 変更を進める前に、特定の担当者による承認が必要なものはどれか

実際には、各チェックポイントにはそれぞれ固有の実施メカニズムが必要です。例えば次のような形が考えられます。

  • マージリクエスト承認ポリシーは、マージリクエストを開いたのがエージェントか開発者かにかかわらず、着地前に誰の承認が必要かを定めます。
  • エージェント向けのツール承認ガードレールは、ツールごとに、エージェントの操作を自律的に実行するか、レビューのために一時停止するか、あるいはブロックしたままにするかを決定します。
  • スキャナーの強制適用は、組織が求めるセキュリティおよび品質チェックをクリアするまで、パイプラインの段階で変更を保持します。

各チームの慣習に委ねるのではなく、組織全体で統一したAIガバナンスポリシーを策定することをおすすめします。これにより、利用方法とポリシーの一貫性が保たれるとともに、監査担当者がAIの利用状況を検証しやすくなります。

ディシジョンレイヤーが加える文脈

こうした承認を、チャットのスレッドやレビュー担当者の記憶の中に消えていくままにするのではなく、構造化された記録として残しておくことには、長期的なメリットがあります。前四半期に認められた例外や、それがどのポリシーバージョンのもとで承認されたか、誰が承認したかといった情報は、監査担当者と将来のエージェントの双方が参照すべき、組織としての判断そのものです。

意思決定を、永続的でクエリ可能なイベントとして扱う企業には、次にレビューを行う人間またはエージェントが、ゼロからではなく、追加の文脈を踏まえた状態で始められるという利点もあります。

ディシジョンレイヤーについて詳しく知り、意思決定イベントの記録がソフトウェア開発にどのような影響を与えうるかをご覧ください。

AI導入の成果を測る5つの指標

最初から追跡しておくべき指標は5つのカテゴリーに分かれており、これらは個別にではなく、併せてレビューすべきものです。リスク指標を伴わない導入率の急上昇自体が、一つの警告サインとなるためです。

  1. 導入状況: AI機能の週次アクティブユーザー数、実行されたフローやエージェントの数、そしてどのチームがエージェント機能を有効化していて、どのチームがまだ有効化していないか。
  2. 採用状況と品質: AI支援による変更のリバート率や、AIが作成したマージリクエストが手戻りなしでレビューを通過する頻度といった、後続工程の指標です。採用率単体の数値は、採用後にそのコードがどうなったかを示さないため、効果を測る指標としては単体では不十分です。
  3. リスク: ツール承認ガードレールが操作をレビューのために一時停止させた頻度、その一時停止がブロックまたは操作の修正につながった頻度、そしてエージェントの活動がポリシー違反を引き起こしたかどうかを追跡します。
  4. 修正対応: プロジェクト全体のスキャナーカバレッジ、自動修正された脆弱性と手動でトリアージされた脆弱性の割合、そして検出後に問題を解消するまでの時間に注目します。
  5. ROI: 四半期分のデータが揃ったら、AI投資のROIを検証しましょう。エージェントが担うようになったタスクで開発者がどれだけの時間を削減できているかを追跡し、それを解決済みIssueやマージ済み変更あたりのコスト(クレジットや計算リソースの消費量)と比較します。AIのROIを詳しく知るためのチュートリアルでは、生の利用データをビジネス上のインサイトやROI計算に変換する方法を学べます。

これら5つの指標をすべて併せて追跡することで、AI導入の問題を早期に発見できます。導入率や採用状況の面では順調に見えても、水面下でリスクが蓄積し、半年後の監査で初めて表面化するというケースもあります。上記の指標を用いることで、組織にとってのAIの価値を総合的に把握できます。

GitLab Duo Agent Platformのガバナンスチェックリスト

GitLab Duo Agent Platformへの標準化を進めるチームに向けて、パイロットの範囲を超えてエージェント型AIを拡大する前に確認しておきたい、実践的なチェックリストを紹介します。

  • AI Transparency Centerを確認し、データの利用方法、モデルベンダー、サブプロセッサに関するコミットメントを理解しておく。
  • どのエージェントとフローの利用を承認するかをプラットフォームレベルで決定し、各チームに個別設定させるのではなく、GitLabのAIカタログを通じて公開する。
  • ツールの機微性に応じて、ツール承認ガードレールを「常に許可」「常に確認」「常に拒否」のいずれかに設定する。
  • コンポジットアイデンティティを設定し、すべてのエージェントの操作を要求元の人間に紐づけ、アクセスには両者の認可を必須とする。
  • 規制対象のワークロードについては、データレジデンシー要件に照らしてセルフホスト展開と自社モデル持ち込みの選択肢を評価する。
  • コードレビュー、テストと検証、デプロイ承認について、明確なHuman-in-the-Loopのチェックポイントを文書化する。
  • エージェントの活動について監査イベントストリーミングを有効化し、すべての操作を組織がすでにレビューしている監査証跡に集約する。
  • パイロットの範囲を超えて拡大する前に、導入指標(導入状況、採用状況、リスク、修正対応、ROI)を定義し、継続的なサイクルで併せてレビューする。

このチェックリストは、リリースサイクルごとに見直しましょう。エージェント型AIのガバナンスは、一度設定すれば終わりというものではありません。新しいエージェント、新しいツール、新しいモデルが登場するたびに、ガバナンス上の論点が再び浮上することが少なくないためです。

エージェント型AIのスピードとエンタープライズの統制が交わる場所

エージェント型AIは、ガバナンスの対象そのものを変えます。コード補完が問うていたのは、その提案が良いものかどうかを開発者に確認することでした。エージェント型AIが問うのは、エージェントが何に触れることを許されているのか、誰がそれを承認したのか、そして後からそれを証明できるのか、という点です。

これらの問いに十分に答えるには、後から積み上げるのではなく、プラットフォーム自体に組み込まれたガバナンスが必要です。GitLab Duo Agent Platformは、実際に作業が行われるプラットフォームに、AIカタログ、承認ガードレール、監査イベントストリーミングを直接組み込んでいるため、ガバナンスが後付けになることはありません。ガードレールはワークフローと並行して動く別プロセスではなく、ワークフローそのものの一部であるため、チームはAIによるスピードとエンタープライズレベルの統制を同時に得られます。

GitLab Duo Agent Platformの無料トライアルを今すぐ始めましょう。Freeプランでは、簡単な手順でサインアップできます。すでにGitLab PremiumまたはUltimateをご利用の場合は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご利用いただけます。

ご意見をお寄せください

このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。

フィードバックを共有する

よくある質問

今すぐ開発をスピードアップ

DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。