Content last updated 2026-07-01

GitLab における AI モデル検証

評価対象のモデルを見つけるために市場を監視し、新しいモデル評価のオンデマンドリクエストに対応する方法。

はじめに

GitLab の AI モデル検証アプローチでは、AI 搭載機能を支援するために、厳格な評価と実用的な効率性を組み合わせています。私たちのフレームワークは、GitLab の品質およびコンプライアンス基準を維持しながら、チームが最先端の AI 技術を活用できるよう支援します。一貫した検証方法を確立することで、モデルがパフォーマンス、品質、コンプライアンスの要件を満たすよう支援します。

運用上のノーススターメトリクス

私たちの検証システムの有効性は、主にモデルの提出から検証レポートの提供までの 所要時間 で測定します。モデルプロバイダーの応答時間は私たちが制御できないため、所要時間を測定するのはオープンソース（OSS）モデルの評価のみであることに注意してください。

既存ベンダー（標準的な評価の緊急度）: 5 営業日
新規ベンダー: 15 営業日（達成に向けて最大限努力しますが、ベンダーの応答時間に左右されます）
- 新規ベンダーを GitLab dot-com の顧客向け本番プロダクトおよび機能で使用するには、新しい「サブプロセッサー」として GitLab Legal に 登録する必要があります。新しいサブプロセッサー（すなわち新しいモデルホスト）の登録には 30 日前の通知が必要です。サブプロセッサーの利用を終了する場合や関係を解消する場合は顧客への通知は不要ですが、顧客向け機能を新しいモデルホストに移行する場合は通知が必要です。
- 新しいサブプロセッサーを申請するには、モデルプロバイダーの詳細を記載し、Legal プロジェクトで general-legal-template の Issue テンプレートを使用して新しい Legal Issue を作成します。

この所要時間には、運用メトリクス（法務およびコンプライアンス要件）、技術メトリクス（リソース使用率およびパフォーマンスベンチマーク）、統合メトリクス（デプロイの複雑さおよび使いやすさ）にわたる評価が含まれます。

モデルの発見と選定戦略

GitLab は、相互に補完する 2 つのアプローチを通じて、評価対象となる AI モデルのアクティブなパイプラインを維持します。

市場監視

AI Framework チームは、GitLab の機能を強化できる有望なモデルを特定するため、AI 分野を継続的に調査します。学術論文、商用リリース、オープンソースプロジェクトをレビューし、GitLab の機能に適用できる可能性があるモデルを特定します。また、注目すべきモデルを現在の本番実装に対してベンチマークし、市場での採用状況とコミュニティのサポートを評価して、長期的な実用性を見極めます。

機能チームからのリクエスト

機能チームは、プロダクト要件に基づいて、評価する特定のモデルを直接推薦できます。リクエストを提出する際、チームは以下を提供してください。

想定されるユースケースを含む、モデル評価の詳細な根拠
ニーズに最も関連する、機能固有の評価基準
評価の優先順位付けに役立つ、統合タイムラインの要件

緊急モデル評価のための Bridge Process

私たちの標準的な検証プロセスでは多くの状況に対して包括的な評価を提供しますが、Bridge Process はオープンソース（OSS）モデルにのみ適用されます。緊急性の高い状況に向けて迅速な評価経路を提供し、GitLab が市場の重要な動向にすばやく対応できるようにします。

Bridge Process を使用する状況

Bridge Process は、以下の場合に適しています。

新しくリリースされたモデルが大きな競争優位性をもたらす
市場での迅速なポジショニングに即時評価が必要である
機能チームが緊急評価を必要とする重要な期限に直面している

Bridge Process のタイムラインとアクティビティ

Bridge Process は、私たちの標準的な検証アプローチを簡素化された 5 日間のタイムラインに圧縮します。

1～2 日目: 初期評価
- 基本的な品質チェックに、事前定義されたプロンプトのサブセットを使用する
- 法務および運用上のリスクについて、ベンダーの利用規約をレビューする
  - 注記: モデルが技術評価に合格しても Legal が却下する可能性があるというリスクを、機能チームが受け入れる
3～4 日目: 詳細評価
- 既存のベンチマークを使用して包括的なテストを実施する
- スケーラビリティと統合要件を評価する
5 日目: 最終レビュー
- 結果をまとめ、調査結果を文書化し、ステークホルダーレビューを実施する
- 機能チームに明確な次のステップを提供する

Bridge Process の成果物

Bridge Process が成功すると、以下が提供されます。

本番利用に向けたモデルの法務承認ステータス
私たちの検証観点に基づく評価レポート
ステークホルダーレビューと go/no-go の決定
承認された場合は、モデルデプロイの目標日を含むイテレーション計画

Bridge Process 評価のリクエスト

機能チームは、以下の手順で Bridge Process を開始できます。

Model Validation Rapid Eval Requestテンプレートを使用して専用の Issue を作成する
付随する Legal 受付 Issue に記入し、法務レビューを開始する

AI Framework チームは、すべての Bridge Process リクエストを 1 営業日以内にレビューします。

検証レポートの構成

評価したモデルごとに、以下を含む包括的な検証レポートを生成します。

パフォーマンス評価

現在の本番モデルに対するレイテンシー比較分析:
- 標準入力サイズでの応答時間ベンチマーク
- テールレイテンシーの比較（p95、p99）
- 最初のトークンまでの時間のパフォーマンス
現在のパフォーマンスベースラインと同等にするためのリソース要件:
- 必要な GPU/CPU 構成
- メモリ使用量の比較
- インフラストラクチャのスケーリング要件
コスト評価:
- 簡略化された 3 段階のフレームワークを使用した相対的なコスト位置付け:
  - 現在のベースラインと同等
  - 中程度に高いコスト影響（ベースラインの 2～5 倍）
  - 大幅なコスト差（ベースラインの 5 倍超）
パートナーシップのステータス:
- モデルプロバイダーとの現在の関係ステータス
- 関連する場合の意思決定への影響

法務ステータス

Legal チームの正式な承認ステータス（承認済み／未承認）
承認された場合の条件付き要件または制限

品質評価結果

私たちの品質評価では、モデルそのもののパフォーマンスと機能レベルの実装の両方を調査します。

短期評価メトリクス

初期品質評価では GitLab の主要評価スイートに重点を置き、以下を測定します。
- Duo Chat のパフォーマンスメトリクス（読みやすさ、簡潔さ、正確性）
- Code Suggestions の精度
- RCA の平均正解スコア
- Vulnerability Resolution の正解スコア

長期監視フレームワーク

私たちは、以下について継続的な監視を確立します。

インフラストラクチャの安定性（Apdex スコア）
ワークフローとツールの応答信頼性
アップストリームサービスの可用性
機能固有の品質メトリクス

オーナーシップと責任

Model Validation チームの責任

技術的検証（リソース使用量、スケーラビリティ）
市場監視とモデルパイプライン管理
プロセスの調整

機能チームの責任

機能固有の評価用データセットの作成
機能の品質に関するオーナーシップと実装判断

共同責任

モデルの選定と優先順位付け
評価基準の策定
結果のレビューと意思決定