9月22日、Craig Risiが「GitLab Duo Expands Self-Hosted AI Options Through Microsoft Foundry」と題した記事を公開した。GitLab DuoがMicrosoft Foundry経由でセルフホストAIモデルの選択肢を拡大し、企業がAIインフラの管理権をより細かく掌握できるようになった。「どのモデルを使うか」の選択より、「そのモデルをどこで動かし、データをどこに通すか」の設計判断が問われる局面が現実のものになりつつある。
GitLab DuoのAIインフラが「組織の手元」に
GitLabはGitLab Duo Self-Hostedを拡張し、Microsoft Foundry（Azure AI Foundryとも呼ばれる、Azure上のAIモデルデプロイ・管理サービス）上にデプロイされたモデルへの対応を追加した。これにより、企業はGitLab Duoの各種AI機能を、GitLab管理のインフラではなく、自社が選択したAzure環境内のモデルに対して実行できるようになった。
対応するモデルファミリーはOpenAI GPT、Anthropic Claude、Meta Llama、Mistralの4系統。モデルプロバイダー、デプロイ先、データの経路をすべて自組織でコントロールできる点が、今回の核心だ。
特に適合するのは、データレジデンシー（データの保管場所規制）、データ主権、規制コンプライアンス、ネットワーク隔離などの要件を抱える企業だ。金融・医療・公共セクターなど、AIリクエストが外部インフラを経由することを許容できない環境で、実運用の選択肢が広がる。
アーキテクチャ：3層構造でモデルを切り替える
今回の統合は以下の3コンポーネントで構成される。
- セルフマネージドGitLabインスタンス
- **セルフホスト型 GitLab AI Gateway**（GitLab DuoとモデルエンドポイントのHub）
- Microsoft Foundry経由でホストされる1つ以上のモデルエンドポイント
AI GatewayがGitLab Duoと各モデルの間に入ることで、個々のDuo機能が特定プロバイダーに直結しない設計になっている。
さらに重要なのが機能単位でのモデル選択だ。元記事によれば、Duo機能ごとに異なるモデルを割り当てることが可能であり、モデルの入れ替えもGitLabの開発ワークフロー自体を変えることなく実施できる。
※編集部の考察：この設計は、コード補完・エージェント的ワークロード・高頻度の軽量タスクといった用途別にモデルを使い分けるユースケースを想定したものと考えられる。
セルフホストの代償：運用責任は組織に移る
柔軟性の裏には明確なトレードオフがある。GitLab管理インフラを使わない分、モデルのデプロイ、キャパシティ管理、ネットワーク設定、クレデンシャル管理、可用性確保、モデルのライフサイクル管理がすべて自組織のエンジニアリングチームの責任になる。
また、Microsoft FoundryのカタログがGitLab対応モデルのマトリクスより先に更新される可能性がある点にも注意が必要だ。Foundryで提供されているモデルがそのままGitLab Duoで使えるわけではなく、両プラットフォームで個別に互換性を確認する必要がある。
「モデル非依存のコントロール層」へ
この動きはAI開発ツールとモデルを一体のサービスとして扱う従来の方式からの脱却を示している。
類似した動向として、GitHub Copilotも複数モデルへの対応を進めているが、その標準体験はGitHubのマネージドサービスと密接に統合されたままだ。一方、Amazon BedrockやMicrosoft Foundryはマルチモデルインフラを提供するが、GitLabのような統合DevSecOpsプラットフォームの代替にはならない。
GitLabのアプローチは、開発者ワークフローとAI機能はGitLabが管理し、その下に置くモデルは組織が決める——という「モデル非依存のコントロール層」として機能することを目指している。
AIがソフトウェアエンジニアリングに深く組み込まれていくなか、企業が問われる問いは「どのAI機能を使うか」だけではなくなっている。モデルをどこで動かすか、コードとプロンプトがどこを通るか、クレデンシャルは誰が管理するか、どの法域でデータが処理されるか——今回の統合はこれらの問いに対する実装上の回答の一つだ。
詳細はGitLab Duo Expands Self-Hosted AI Options Through Microsoft Foundryを参照していただきたい。
