GitLab Duo Agent Platform + MCP：GitLabはAIコーディングエージェントのOSになろうとしている
GitLab Duo Agent Platform + MCP：GitLabはAIコーディングエージェントのOSになろうとしている
AIコーディングに関するほとんどの見出しは、今もある一つの狭い問いを中心に回っている。どのモデルがより良いコードを書くか、というものだ。GitLabは別の賭けをしている。次のAI開発フェーズを、コード生成の問題としてではなく、ワークフロー制御の問題として捉えているのだ。
だからこそ、GitLab Duo Agent Platformが重要なのだ。
2026年1月15日、GitLabはDuo Agent Platformを一般提供（GA）とした。現在のGitLabドキュメントにはClaude Code、OpenAI Codex、Amazon Q、Gemini向けの管理された外部エージェントが記載されており、新しいMCPチュートリアルではGitLabがJira、Slack、Confluenceといったシステムにそれらのワークフローを接続するクライアントとして機能する様子が示されている。これらを合わせると、「GitLabがAIを追加した」という話よりずっと大きな話になる。
GitLabは、人間の開発者、社内ワークフロー、サードパーティのコーディングエージェントが全て集まる、ガバナンスされたコントロールプレーンになろうとしている。
本当の変化はコパイロットからオーケストレーションへ
AIコーディング製品の第一波は、主に個人支援に関するものだった。モデルは開発者の傍らに座り、コードを生成し、質問に答え、IDE内で編集を提案した。
それでも有用だが、AIをソフトウェアライフサイクル全体に組み込みたいチームには不十分だ。AIがイシュー、マージリクエスト、承認ゲート、ブランチ、デプロイワークフローと相互作用しはじめると、重心が移動する。問題はもはや「モデルはコードを書くのに役立つか？」ではなくなる。問題はこうなる：
- 誰がエージェントをトリガーできるか
- どんな権限で動作するか
- その行動はどこに記録されるか
- 外部システムとどのように相互作用するか
- 変更が本番環境に届く前にどんなガバナンスが存在するか
GitLabのポジショニングが強力なのは、まさにそのライフサイクルの多くをすでに自社が所有しているからだ。より綺麗なプロンプトボックスを作る代わりに、エージェントをDevSecOpsのシステムオブレコードに組み込んでいる。
GitLabは自社AIだけでなく、外部エージェントも受け入れている
ドキュメントの中で最も重要な戦略的詳細の一つは、GitLabがDuo Agent PlatformをGitLab独自のインテリジェンスに限定していないことだ。ドキュメントにはGitLabが管理する外部エージェントとして以下が記載されている：
- Claude Code
- OpenAI Codex
- Amazon Q
- Gemini
これは意味のある動きだ。
GitLabがワークフロー競争に勝つためにモデル競争に勝つ必要はない、ということを示唆している。最高のコーディングエージェントが異なるベンダーからますます登場するようになっても、GitLabはそれらのエージェントが企業のソフトウェアデリバリー内でどのようにデプロイ・承認・監視されるかを管理するレイヤーとして自らを位置づけることができる。
これにより競争の構図が変わる。GitLabがAnthropicやOpenAIのモデル品質に勝てるかを問うのではなく、より関連性の高い問いは、GitLabがそれらすべてのエージェントが働かざるを得ない運用環境を支配できるかどうかだ。
MCPが戦略の効果を倍増させる
MCPの視点から見ると、この戦略は一見するよりずっと強力になる。
GitLab Duo Agent PlatformがMCPクライアントとして機能できるなら、GitLab内のコーディングエージェントはもはやリポジトリコンテキストに縛られない。ソフトウェア作業が実際に調整されているシステム——チケット、計画ドキュメント、チャットスレッド、ダッシュボード、承認システム——から情報を引き出したり、それらに対してアクションを取ったりできる。
これが重要なのは、現代のソフトウェア作業が複数のツールにまたがって分散しているからだ。計画はJiraにあるかもしれない。仕様はConfluenceにあるかもしれない。アラートはSlackに表示されるかもしれない。品質とリリースのコンテキストはGitLabにあるかもしれない。リポジトリしか見えないコーディングエージェントは、実際のワークフローの多くに対して盲目だ。
MCPはその盲目性を軽減する。すべてのコンテキストがすでにGitLab内に存在するふりをしなくても、エージェントをより有用にするための道をGitLabに与えてくれる。
戦略的な含意は明確だ。AIコーディングの勝者は、最も印象的なデモを持つモデルではなく、制御を維持しながら最も多くのコンテキストを接続できるプラットフォームかもしれない。
ガバナンスが本当の堀だ
GitLabのストーリーで最も強力な部分は、より多くのエージェントをサポートしていることではない。それらのエージェントを企業ワークフロー内のガバナンスされたアクターとして提示していることだ。
ドキュメントとローンチ資料は、AIプロダクトのデモよりも実際の組織においてはるかに重要な詳細を強調している：
- エージェント活動の監査証跡
- サービスアカウントまたは複合IDによる実行
- サポートされている外部エージェントへの管理された認証情報
- ツールアクセスへの承認コントロール
- エージェントが作成した作業に対するブランチルールとセキュリティ上の考慮事項
ここでDevSecOpsのフレーミングが重要になる。企業はコードを書けるAIを求めているだけではない。ポリシー、追跡可能性、アカウンタビリティを備えたシステム内で動作できるAIを求めている。
だからこそ、GitLabの動きは単なるアシスタントローンチよりも真剣に受け止めるべきものだ。エージェントによる開発をインフラとしてパッケージ化しているのだ。
Claude Code、Codex、その他すべてのエージェントベンダーにとっての意味
ここには、より広い市場シグナルがある。Claude Code、Codex、Gemini、Amazon Qは能力、UX、モデル品質で競争するかもしれない。しかし企業がそれらのエージェントを呼び出し、監査し、承認する場所がGitLabになるなら、力のバランスが変わる。
その世界では、エージェントベンダーはインテリジェンスを所有するが、GitLabはワークフローレバレッジを所有する。
これは企業ソフトウェアでおなじみのパターンだ。最も耐久性のある企業は、多くの場合、最も派手な基盤エンジンを持つ企業ではない。システム、権限、チームが収束する地点に座っているため、取り除くことが難しくなった企業だ。
GitLabはまさにその位置をエージェント的ソフトウェア開発において主張しようとしている。
開発者とプラットフォームチームが得るべき教訓
実践的な教訓は、すべてのチームが今すぐGitLab Duo Agent Platformを必要としているということではない。本当の教訓は、AIコーディングがスタックの上へと移動しているということだ。
次の競争レイヤーはますますオーケストレーションをめぐるものになっている：
- エージェントはどのようにトリガーされるか
- エージェントはどのようにIDと権限を継承するか
- エージェントはどのように外部コンテキストを取得するか
- エージェントはどのようにレビューされ、制限されるか
- エージェントのアクションはどのように既存のデリバリーコントロールに組み込まれるか
プラットフォームチームにとって、それはあるモデルが別のモデルよりもオートコンプリートがわずかに優れているかどうかよりも、ずっと興味深い問いだ。AIが本番ワークフローに近づけば近づくほど、ガバナンスはより重要になる。
GitLabはそれを理解している。Duo Agent PlatformとMCPは、AIコーディングを孤立した生産性機能から、DevSecOpsのオペレーティングシステムの一部へと転換しようとする賭けだ。
この賭けが成功すれば、AIコーディングの長期的な勝者はモデルプロバイダーではないかもしれない。オーケストレーション、権限、クロスツールワークフロー制御を所有するプラットフォームかもしれない。