2025年12月年末時点での GitLab Duo 機能サマリ
1. はじめに
GitLab Duoは、単なるコード補完ツールではありません。開発ライフサイクル全体—コーディング、レビュー、セキュリティ、CI/CD—を一貫してサポートするAI支援プラットフォームです。
この記事では、GitLab Duoが提供する機能を体系的に整理し、実際の開発フローでどのように活用できるかを解説します。
1.1. 共通の前提条件
特に記載がない限り、以下の前提条件が適用されます:
基本要件:
- GitLab 17.2以降(最良の体験には18.0以降を推奨)
- 適切なGitLab Duoサブスクリプション
IDE使用時:
- VS Code: GitLab Workflow extension v6.15.1以降
- JetBrains: GitLab plugin v3.11.1以降
- Visual Studio: GitLab extension v0.60.0以降
- Eclipse: GitLab for Eclipse plugin
2. 目次
- はじめに
- 目次
- サブスクリプション構成と機能マトリックス
- コア機能: GitLab Duo Chat
- 開発支援機能
- コードレビューとマージリクエスト
- セキュリティ機能
- Agent Platform: エージェントとフロー
- Model Context Protocol (MCP)
- Knowledge Graph
- 分析とメトリクス
- まとめと導入ガイド
3. サブスクリプション構成と機能マトリックス
3.1. ティア別機能一覧
GitLab Duoは3つのティアで提供されており、それぞれ利用可能な機能が異なります。
| 機能カテゴリ | Core | Pro | Enterprise |
|---|---|---|---|
| コーディング | |||
| Code Suggestions | ✓ | ✓ | ✓ |
| Chat (Classic) | ✓ | ✓ | ✓ |
| コード説明 (IDE) | ✓ | ✓ | ✓ |
| リファクタリング | ✓ | ✓ | ✓ |
| コード修正 | ✓ | ✓ | ✓ |
| テスト生成 | ✓ | ✓ | ✓ |
| 高度な開発 | |||
| Chat (Agentic) | ✓ | ✓ | ✓ |
| Agent Platform | ✓ | ✓ | ✓ |
| MCP連携 | ✓ | ✓ | ✓ |
| コード説明 (UI) | - | ✓ | ✓ |
| CI/CD設定生成 | - | ✓ | ✓ |
| コードレビュー | |||
| MR説明生成 | - | - | ✓ |
| Code Review (Classic) | - | - | ✓ |
| Code Review Flow | - | - | ✓ |
| レビュー要約 | - | - | ✓ |
| コミットメッセージ生成 | - | - | ✓ |
| セキュリティ | |||
| False Positive検出 | ✓ | ✓ | ✓ |
| Vulnerability Explanation | - | - | ✓ |
| Vulnerability Resolution | - | - | ✓ |
| 分析 | |||
| SDLC trends | - | ✓ | ✓ |
| Root Cause Analysis | - | - | ✓ |
3.2. ティアの選択指針
Core: 基本的なコード支援機能を必要とするチーム
- Code SuggestionsとChatで日常的なコーディングを効率化
- 小規模チームや個人開発者に適している
Pro: CI/CD関連の高度な機能が必要なチーム
- CI/CD設定の生成
- 分析ダッシュボードでの効果測定
- 中規模チームに適している
Enterprise: エンタープライズレベルの全機能が必要な組織
- 自動コードレビュー
- セキュリティ脆弱性の自動解決
- 包括的な分析とメトリクス
- 大規模チームや厳格なセキュリティ要件がある組織に適している
4. コア機能: GitLab Duo Chat
4.1. 2種類のChat
GitLab Duoは2種類のChatを提供しています。
| 機能 | Chat (Classic) | Chat (Agentic) |
|---|---|---|
| コンテキスト | 単一ソース | 複数ソース統合 |
| ファイル操作 | 不可 | 作成・編集可能 |
| 検索 | 手動指定 | 自律的に実行 |
| リソース取得 | 制限あり | Issue、MR、パイプライン自動取得 |
| MCP連携 | 非対応 | 対応 |
| コミット作成 | 非対応 | UI上で可能 |
| 対応ティア | すべて | すべて |
推奨事項: 複雑な質問や、複数のソースから情報を統合する必要がある場合はChat (Agentic)を使用してください。
4.2. 利用可能な環境
| 環境 | Chat (Classic) | Chat (Agentic) |
|---|---|---|
| GitLab UI | ✓ | ✓ |
| VS Code | ✓ | ✓ |
| JetBrains IDEs | ✓ | ✓ |
| Visual Studio | ✓ | ✓ |
| Eclipse | ✓ | - |
4.3. スラッシュコマンド一覧
4.3.1. 汎用コマンド(すべての環境)
| コマンド | 機能 | 対応ティア |
|---|---|---|
/new |
新しい会話を開始(履歴は保持) | すべて |
/reset |
会話をリセット | すべて |
/help |
使い方を表示 | すべて |
4.3.2. IDE専用コマンド
| コマンド | 機能 | 対応ティア |
|---|---|---|
/tests |
テストコード生成 | すべて |
/explain |
コード説明 | すべて |
/refactor |
リファクタリング提案 | すべて |
/fix |
コード修正 | すべて |
/include |
ファイルコンテキスト追加 | すべて |
4.3.3. GitLab UI専用コマンド
| コマンド | 機能 | 利用場所 | 対応ティア |
|---|---|---|---|
/summarize_comments |
コメント要約 | Issue | Enterprise |
/troubleshoot |
Root Cause Analysis | CI/CDジョブ | Enterprise |
/vulnerability_explain |
脆弱性説明 | Vulnerability Report | Enterprise |
4.4. 会話の管理
同時会話: GitLab 17.10以降、無制限の同時会話が可能です。
会話の同期: GitLab UIとIDE間で会話が自動的に同期されます。
会話の保持:
- 各会話は最大200,000トークン(約800,000文字)
- 30日間の非アクティブ期間後に自動削除
会話履歴の確認:
- GitLab UI: すべての会話が表示可能
- IDE: 最新20件の会話を表示
4.5. モデルとエージェントの選択
4.5.1. モデル選択(Beta)
対応環境: GitLab.com、GitLab Self-Managed(GitLab UI、VS Code、JetBrains IDE)
会話に使用するAIモデルを選択できます。
注意:
- トップレベルグループのオーナーがモデルを選択している場合、変更できません
- 既存の会話でモデルを変更すると、新しい会話が作成されます
4.5.2. エージェント選択
追加の前提条件:
- プロジェクトでAI Catalogからエージェントが有効化されていること
- プロジェクトのメンバーであること
プロジェクトで有効化されたカスタムエージェントをChatで使用できます。
制限事項:
- 会話ごとに1つのエージェントを選択
- 会話中にエージェントの変更は不可
- エージェントが利用不可になった場合、その会話は継続不可
4.6. Prompt Caching
Prompt Cachingは、モデルベンダー(AnthropicまたはVertexAI)がプロンプトデータを一時的にメモリに保存することで、レイテンシを大幅に改善します。
特徴:
- デフォルトで有効
- キャッシュされたデータは永続ストレージには記録されない
- ChatとCode Suggestionsの両方に適用
無効化: トップレベルグループのGitLab Duo設定で無効化可能(両機能が同時に無効化されます)
4.7. IDEでのカスタマイズ
Chatの動作をカスタマイズするために、2つのアプローチがあります:
1. Custom rules (chat-rules.md):
- GitLab専用
- 個人の好みやチーム標準に最適
2. AGENTS.md instruction files:
- GitLabおよび他のAIツールでも利用可能
- プロジェクトコンテキスト、モノレポ構成、ディレクトリ固有の規約に最適
両方のファイルを同時に使用でき、Chatはすべての利用可能なルールファイルから指示を適用します。
5. 開発支援機能
5.1. Code Suggestions
5.1.1. 2つのモード
コード補完:
- 現在の行を完成させる短い提案
- レイテンシ: 1秒未満
- トリガー: 通常の入力中
コード生成:
- 自然言語コメントから複数行のコードを生成
- レイテンシ: 5秒程度(大きなコードブロックの場合)
- トリガー: コメント入力後にEnter
5.1.2. 効果的なコード生成のベストプラクティス
重要: コード生成の品質を高めるには、以下を心がけてください
- 具体的かつ簡潔に記述
- 達成したい成果(例: 関数)を明記し、詳細を提供
- 使用するフレームワークやライブラリを追加
- 各コメントの後にスペースまたは改行を追加(指示の完了を示す)
例:
# TornadoでWebサービスを作成し、ユーザーがサインイン、セキュリティスキャン実行、
# 結果確認できるようにする。各アクション(サインイン、スキャン実行、結果確認)は
# Webサービスの独立したリソースとして実装する
# ↓ この後Enterを押すと、GitLab Duoが実装を生成
注意: AIは非決定論的なため、同じ入力でも毎回同じ提案が得られるとは限りません。
5.1.3. コンテキストと出力の制限
入力コンテキスト:
| モード | 最大トークン数 | 概算文字数 |
|---|---|---|
| コード補完 | 32,000 | 約128,000 |
| コード生成 | 200,000 | 約800,000 |
出力:
| モード | 最大トークン数 | 概算文字数 |
|---|---|---|
| コード補完 | 64 | 約256 |
| コード生成 | 2,048 | 約7,168 |
カーソル位置より上の内容が優先され、下の内容は右側から切り詰められます。
5.1.4. 複数の提案を確認(VS Code)
VS Codeでは、複数の提案オプションが表示される場合があります。
操作方法:
- Mac:
Option + [/Option + ] - Linux/Windows:
Alt + [/Alt + ] - ダイアログの矢印をクリック
5.1.5. 直接接続と間接接続(Self-Managedのみ)
デフォルトでは、コード補完リクエストはIDEから直接AIゲートウェイに送信されます(レイテンシ最小化)。
直接接続の要件: IDEが https://cloud.gitlab.com:443 に接続できること
ネットワーク制限がある場合、間接接続(GitLab Self-Managedインスタンス経由)を使用できますが、レイテンシが高くなります。
設定方法(管理者のみ):
Admin > Settings > General > GitLab Duo features- Connection methodで選択:
- Direct connections: レイテンシ最小化
- Indirect connections: 直接接続を無効化
5.2. Repository X-Ray
Repository X-Rayは、コードベース全体の構造を理解し、より正確な提案を行うための基盤技術です。
活用される機能:
-
/refactor: リファクタリング提案 -
/fix: コード修正 -
/tests: テスト生成
5.3. ファイルコンテキストの追加
IDEでChatを使用する際、/includeコマンドで特定のファイルをコンテキストに追加できます。
追加の前提条件:
- ファイルがリポジトリの一部であること
- テキストベースのファイル(PDFや画像は非対応)
使用例:
/include cart_service.py
/include checkout_flow.js
checkout_flow.jsはcart_service.pyとどのように連携していますか?
Mermaidでシーケンス図を生成してください。
注意: Quick Chatではファイル追加機能は使用できません。
5.4. コードの説明
5.4.1. IDE内での説明
対応ティア: Core、Pro、Enterprise、Amazon Q
コードを選択して /explain コマンドを実行することで、説明を取得できます。
追加指示の例:
/explain the performance/explain focus on the algorithm/explain why a static variable is used here (C++)/explain how concurrency works in this context (Go)
5.4.2. GitLab UIでの説明
対応ティア: Pro、Enterprise、Amazon Q
使用方法:
- ファイルまたはマージリクエストを開く
- コードを選択
- 疑問符アイコンをクリック
注意: 最初の行までスクロールする必要がある場合があります。
5.5. その他のコード操作
以下のコマンドはすべてRepository X-Rayを使用してコンテキストを理解します。
5.5.1. リファクタリング(/refactor)
対応ティア: Core、Pro、Enterprise、Amazon Q
追加指示の例:
-
/refactor with ActiveRecord(特定のコーディングパターン) -
/refactor using mysql(特定のライブラリ) -
/refactor to TypeScript(別の言語へ) -
/refactor improving performance(パフォーマンス重視)
5.5.2. コード修正(/fix)
対応ティア: Core、Pro、Enterprise、Amazon Q
追加指示の例:
/fix grammar mistakes and typos/fix duplicate database inserts/fix potential bugs-
/fix the build(コンパイルエラー)
5.5.3. テスト生成(/tests)
対応ティア: Core、Pro、Enterprise、Amazon Q
追加指示の例:
/tests using the Boost.test framework (C++)/tests using Jest (JavaScript)/tests focus on extreme cases, force regression testing/tests focus on regressions and potential exploits
5.6. GitLabに関する質問
GitLab Duoは、GitLabの公式ドキュメントを情報源として、GitLabの使い方に関する質問に回答できます。
更新頻度: 毎日更新
使用されるドキュメント:
- GitLab.com: 最新版
- Self-Managed/Dedicated: インスタンスのバージョンに対応
質問例:
Explain the concept of a 'fork' in a concise manner.Provide step-by-step instructions on how to reset a user's password.
5.7. GitLabリソースに関する質問
5.7.1. Issue、Epic、Work Item
対応ティア: Enterprise
質問例:
Generate a summary for the issue identified via this link: <link>How can I improve the description of <link> so that readers understand the value?
制限: テキストが40,000語を超える場合、すべてを考慮できない可能性があります。
5.7.2. Merge Request
対応ティア: Enterprise
MRを表示しながら、タイトル、説明、コメント、Changes、メタデータについて質問できます。
質問例:
Why was the .vue file changed?What do the reviewers say about this merge request?Which files and changes should I review first?
5.7.3. Commit
対応ティア: Enterprise
質問例:
Generate a summary for the commit identified with this link: <link>How can I improve the description of this commit?
5.7.4. Pipeline Job
対応ティア: Enterprise
質問例:
Generate a summary for the pipeline job identified via this link: <link>Can you suggest ways to fix this failed pipeline job?
5.8. コードやエラーに関する一般的な質問
5.8.1. コードに関する質問
対応ティア: Core、Pro、Enterprise
コードをペーストしてChatに質問できます。
質問例:
Provide a clear explanation of this Ruby code: def sum(a, b) a + b end.Write a Ruby function that prints 'Hello, World!' when called.
5.8.2. エラーメッセージの説明
対応ティア: Core、Pro、Enterprise
エラーメッセージをコピーして、Explain this error message: という接頭辞を付けて質問できます。プログラミング言語名も追加してください。
質問例:
Explain this error message in Java: Int and system cannot be resolved to a typeExplain when this C function would cause a segmentation fault: sqlite3_prepare_v2()
5.8.3. フォローアップ質問
対応ティア: Core、Pro、Enterprise
前の質問に対して追加の質問を投げることで、より詳細な情報を得られます。
5.9. CI/CDに関する質問
5.9.1. CI/CD設定の生成
対応ティア: Pro、Enterprise
質問例:
Create a .gitlab-ci.yml configuration file for testing and building a Ruby on Rails application.Create a CI/CD configuration for VueJS. Use npm, and add SAST security scanning.
5.9.2. Root Cause Analysis
対応ティア: Enterprise、Amazon Q
失敗したCI/CDジョブの根本原因を特定します。ジョブログの最後の100,000文字を分析し、失敗原因と修正例を提供します。
制限:
- Triggerジョブは非対応
- Downstreamパイプラインは非対応
アクセス方法:
5.10. Issue discussionの要約
対応ティア: Enterprise、Amazon Q
追加の前提条件: Premium または Ultimate ティア
Issueのディスカッションを最大10項目のリストで要約します。フォローアップ質問も可能です。
使用方法:
- Issueを開く
- Activityセクションまでスクロール
-
View summaryを選択
データ使用: Issueのすべてのコメントがモデルに送信されます。
6. コードレビューとマージリクエスト
6.1. MR説明の自動生成
対応ティア: Enterprise
対応環境: GitLab.com、GitLab Self-Managed
ステータス: Beta
マージリクエスト作成時、コード差分から説明を自動生成できます。
使用方法:
- 新しいマージリクエストを作成
- Descriptionフィールドにカーソルを配置
- ツールバーの「Summarize code changes」ボタンをクリック
データ使用: ソースブランチのheadとターゲットブランチ間の差分がモデルに送信されます。
6.2. GitLab Duo Code Review
GitLab Duoをレビュアーとして追加することで、コードの初期レビューを自動化できます。
6.2.1. 2つのオプション
| 項目 | Code Review (Classic) | Code Review Flow |
|---|---|---|
| プラットフォーム | 従来のアーキテクチャ | Agent Platform |
| コンテキスト理解 | 標準 | 高度 |
| 対応ティア | Enterprise | Enterprise |
| 対応環境 | GitLab.com、Self-Managed、Dedicated | GitLab.com、Self-Managed、Dedicated |
共通機能:
- レビューの依頼方法は同じ
- GitLab Duoとの対話方法は同じ
- 自動レビュー、カスタム指示、カスタムコメントをサポート
6.2.2. Code Review (Classic)の使用方法
使用方法:
- マージリクエストを開く
- コメントボックスに
/assign_reviewer @GitLabDuoと入力、または直接GitLab Duoをレビュアーとして指定
データ使用:
- MRタイトル
- MR説明
- 変更前のファイル内容(コンテキスト用)
- MR差分
- ファイル名
- カスタム指示
6.2.3. Code Review Flowの使用方法
フローを有効化した後、MRで @GitLabDuo をメンションまたはアサインすることでレビューを依頼できます。
6.2.4. レビューでの対話
@GitLabDuo をメンションすることで、レビューコメントに対する追加質問や、ディスカッションスレッドでの質問が可能です。
注意: フィードバックは他のMRのレビューには影響しません。
6.3. 自動レビューの有効化
6.3.1. プロジェクトレベル
追加の前提条件: プロジェクトでMaintainer以上の権限
設定方法:
Settings > Merge requests-
Enable automatic reviews by GitLab Duoをチェック
自動レビューが実行されない条件:
- MRがドラフト状態(Readyにすると実行)
- MRに変更がない(変更を追加すると実行)
6.3.2. グループレベル
追加の前提条件: グループのOwner権限
設定方法: Settings > General > Merge requests で同様の設定
6.3.3. インスタンスレベル
追加の前提条件: 管理者権限
設定方法: Admin > Settings > General で同様の設定
重要: 設定は「インスタンス → グループ → プロジェクト」の順でカスケードされ、より具体的な設定が優先されます。
6.4. カスタムレビュー指示
プロジェクト固有のコーディング規約やレビュー基準を反映させるために、カスタム指示を設定できます。詳細はドキュメントを参照してください。
6.5. コードレビューの要約
対応ティア: Enterprise
ステータス: Experiment
レビュー完了時、コメントの要約を生成できます。
使用方法:
- レビューを完了
-
Finish reviewを選択 -
Add Summaryをクリック
コメントボックスに要約が表示され、編集してから送信できます。
データ使用: ドラフトコメントのテキストがモデルに送信されます。
6.6. コミットメッセージの生成
対応ティア: Enterprise、Amazon Q
マージ時のコミットメッセージを自動生成できます。
使用方法:
- マージリクエストを開く
- マージウィジェットで
Edit commit messageチェックボックスを選択 -
Generate commit messageをクリック - 生成されたメッセージを確認し、
Insertをクリック
データ使用:
- ファイルの内容
- ファイル名
7. セキュリティ機能
7.1. SAST False Positive Detection
対応ティア: Core、Pro、Enterprise
追加の前提条件: Ultimate ティア
ステータス: Beta
GitLab Duoは、CriticalおよびHigh severityのSAST脆弱性を自動分析し、False Positiveの可能性を判定します。
提供情報:
- 信頼度スコア
- True/False Positiveである理由の説明
- Vulnerability Report上での視覚的な表示
7.2. Vulnerability Explanation
対応ティア: Enterprise、Amazon Q
追加の前提条件: Ultimate ティア、SAST脆弱性であること
SAST脆弱性に対して、以下の情報を提供します:
- 脆弱性の要約
- 悪用方法の説明
- 修正方法の提案
使用方法:
Secure > Vulnerability report- フィルターバーで SAST カテゴリを選択
- SAST脆弱性を選択
- 以下のいずれかの方法で説明を取得:
- 説明文下部のリンクをクリック
-
Resolve with merge requestからExplain vulnerabilityを選択 - Chatで
/vulnerability_explainコマンドを使用
データ使用:
- 脆弱性タイトル(ファイル名を含む場合あり)
- 脆弱性識別子
- ファイル名
注意: LLMの出力が正しいとは限りません。慎重に使用してください。
7.3. Vulnerability Resolution
対応ティア: Enterprise、Amazon Q
追加の前提条件:
- Ultimate ティア
- サポートされているSAST脆弱性(特定のCWE識別子)
特定のCWE識別子を持つSAST脆弱性に対して、修正用のマージリクエストを自動生成します。
使用方法:
Secure > Vulnerability report- フィルターで
Vulnerability Resolution availableを選択 - 解決したいSAST脆弱性を選択(青いアイコンが表示)
-
Resolve with AIをクリック - 生成されたMRをレビュー
- 追加コミットをMRに追加
- パイプライン完了後、脆弱性が消えていることを確認
- 手動で脆弱性の状態を更新
重要な注意事項:
- LLMの出力は必ずしも正しいとは限りません
- マージ前に以下を確認してください:
- 既存機能が保たれているか
- 組織の基準に準拠しているか
- パブリックプロジェクトでは、MR作成により脆弱性が公開されます
データ使用:
- 脆弱性名
- 脆弱性説明
- 識別子(CWE、OWASP)
- 脆弱な行を含むファイル全体
- 脆弱な行(行番号)
7.3.1. トラブルシューティング
False positive検出:
- 修正提案前に、AIモデルが脆弱性の妥当性を評価します
- テストコード内の脆弱性はFalse positiveと判断される場合があります
- False positiveと判断した場合は、脆弱性をDismissし、理由を選択してください
一時的または予期しないエラー:
- AIプロバイダーまたはGitLab Duoの一時的な問題の可能性
- 再試行してください
- 継続する場合はGitLabサポートに連絡
7.4. Vulnerability Resolution in Merge Request
対応ティア: Enterprise
MR内で脆弱性修正の提案コメントを自動生成します。
使用方法:
- マージリクエストを開く
- Vulnerability Resolution対応の脆弱性を選択(tanuki AIアイコンが表示)
- セキュリティファインディングダイアログを開く
- 右下の
Resolve with AIをクリック
AI修正提案を含むコメントが作成され、MRサジェスションとして適用できます。
追加のトラブルシューティング:
Resolution target could not be found エラー:
- ターゲットブランチで完全なセキュリティスキャンパイプラインが実行されていない可能性があります
7.5. Vulnerability Code Flow
追加の前提条件: Ultimate ティア
GitLab Advanced SASTは、特定の脆弱性タイプに対してコードフローを提供します。コードフローは、ユーザー入力(source)から脆弱な行(sink)までのデータの経路を示します。
7.6. 脆弱性のステータス
7.6.1. ステータス値
| ステータス | 説明 |
|---|---|
| Needs triage | 新しく発見された脆弱性のデフォルト状態 |
| Confirmed | ユーザーが確認し、正確であると判断 |
| Dismissed | ユーザーが評価し、却下。以降のスキャンで無視 |
| Resolved | 脆弱性が修正または存在しなくなった。再発見された場合、Needs triageに戻る |
7.6.2. 脆弱性が検出されなくなった場合
デフォルトブランチでセキュリティスキャンが実行され、脆弱性が検出されなくなった場合:
- スキャナーはアクティビティログに「No longer detected」を追加
- ステータスは自動変更されません
- 手動で確認し、Resolvedに変更する必要があります
Vulnerability Management Policyを使用して、特定条件に一致する脆弱性を自動的にResolvedに変更することもできます。
7.6.3. 却下理由
| 理由 | 説明 |
|---|---|
| Acceptable risk | 既知だが未修正で、ビジネスリスクとして許容 |
| False positive | 実際には脆弱性が存在しない誤検出 |
| Mitigating control | 管理的、運用的、技術的な対策により、リスクが軽減 |
| Used in tests | テストの一部またはテストデータ |
| Not applicable | 既知だが未修正で、更新されないアプリケーション部分にある |
7.7. 脆弱性ステータスの変更
追加の前提条件: プロジェクトでMaintainer以上の権限、または admin_vulnerability 権限を持つカスタムロール
変更方法:
Secure > Vulnerability report- 脆弱性の説明を選択
-
Change statusをクリック - ステータスまたは却下理由を選択
- Dismissedの場合、理由の詳細を入力(必須)
変更詳細(誰が、いつ変更したか)はアクションログに記録されます。
7.8. セキュリティトレーニング
注意: オフライン環境(インターネットから隔離)では利用できません。GitLabサーバーがトレーニングプロバイダーのAPIエンドポイントにアクセスできる必要があります。
セキュリティトレーニングは、開発者が脆弱性の修正方法を学ぶのに役立ちます。
サポートプロバイダー: Secure Code Warrior、Kontra、SecureFlag
7.8.1. 有効化
追加の前提条件: プロジェクトでMaintainer以上の権限
有効化方法:
Secure > Security configuration-
Vulnerability Managementタブを選択 - セキュリティトレーニングプロバイダーのトグルをオンにする
7.8.2. トレーニングの表示
トレーニングの利用可能性は、有効化されたベンダーが特定の脆弱性に一致するコンテンツを持っているかどうかに依存します。
表示方法:
Secure > Vulnerability report- トレーニングを表示したい脆弱性を選択
-
View trainingをクリック
ヒント: CWEを持つ脆弱性は、トレーニング結果が返される可能性が最も高いです。
8. Agent Platform: エージェントとフロー
Agent Platformは、GitLab Duoの中核となる新しいアーキテクチャです。
8.1. エージェントの種類
| タイプ | 提供元 | 特徴 | 有効化 |
|---|---|---|---|
| Foundational | GitLab | 本番環境対応、特定ドメインの専門知識 | デフォルトで有効 |
| Custom | チーム | システムプロンプトで動作定義 | プロジェクトで有効化が必要 |
| External | 外部プロバイダー | Claude等のモデル連携 | Discussion/Issue/MRから直接トリガー |
8.2. AI Catalog
AI Catalogは、エージェントとフローの中央リポジトリです。
主な機能:
- GitLabチームやコミュニティが作成したエージェント/フローの発見
- カスタムエージェント/フローの作成と共有
- プロジェクトでのエージェント/フロー有効化
追加の前提条件:
- GitLab.com: 実験・ベータ機能が有効なグループに属すること
- エージェント/フローを有効化するには、プロジェクトでMaintainer以上の権限
アクセス方法: Search or go to > Explore > AI Catalog
8.2.1. バージョン管理
各カスタムエージェント/フローは、バージョン履歴を維持します。設定を変更すると、GitLabが自動的に新しいバージョンを作成します(セマンティックバージョニング)。
注意: Foundational AgentsとFlowsはバージョニングを使用しません。
バージョン作成タイミング:
- カスタムエージェントのシステムプロンプト更新
- 外部エージェント/フローの設定変更
バージョンピニング:
- グループ: 最新バージョンにピン
- プロジェクト: プロジェクトのトップレベルグループと同じバージョンにピン
これにより、予期しない変更からワークフローを保護し、安定性と予測可能性が提供されます。
8.2.2. 現在のバージョンを確認
追加の前提条件: Developer以上の権限
確認方法:
-
Automate > AgentsまたはAutomate > Flows - エージェント/フローを選択
詳細ページに、ピンされたバージョン、バージョン識別子、設定詳細が表示されます。
8.2.3. 最新バージョンへの更新
追加の前提条件: Maintainer以上の権限
更新方法:
-
Automate > AgentsまたはAutomate > Flows - 更新したいエージェント/フローを選択
- 最新バージョンを確認
-
View latest version > Update to <x.y.z>を選択
8.3. フロー
フローは、1つ以上のエージェントが協調して複雑な問題を解決する仕組みです。
| タイプ | 説明 | 定義内容 |
|---|---|---|
| Foundational | GitLab提供、一般的な開発タスク向け | 即座に利用可能 |
| Custom | チーム独自のプロセス自動化 | ワークフローステップ、エージェント、トリガー |
8.3.1. 実行環境
| 環境 | 対応フロー | 実行方法 |
|---|---|---|
| IDE | Software Development Flow | VS Code、Visual Studio、JetBrains |
| GitLab UI | すべて | GitLab CI/CDで直接実行 |
8.3.2. 追加の前提条件(GitLab UIでの実行)
- GitLab Duo設定でフローを有効化
- 初回実行前に、プロジェクトが属するグループへのメンバー追加を許可
- コードを作成するフローを使用する場合、サービスアカウントを許可するようプッシュルールを設定
8.3.3. 実行中のフローの監視
GitLab UI: Automate > Sessions
IDE: Flowsタブで「Recent agent sessions」を表示
8.3.4. AGENTS.mdでのカスタマイズ
AGENTS.md ファイルを使用して、foundationalおよびcustomフローの実行中にGitLab Duoが従うコンテキストと指示を提供できます。
9. Model Context Protocol (MCP)
MCPは、GitLab Duo機能が外部データソースやツールに安全に接続するための標準化されたプロトコルです。
9.1. 概要
MCPクライアントとして動作する機能:
- GitLab Duo Chat (Agentic)
- Software Development Flow
対応IDE:
- Visual Studio Code / VSCodium
- JetBrains IDEs
同じMCP設定ファイルがすべての対応IDEで動作します。
9.2. グループでMCPを有効化
設定方法:
Settings > GitLab DuoChange configuration-
Turn on support for Model Context Protocol (MCP)チェックボックスを選択/クリア Save changes
9.3. MCPサーバーの設定
9.3.1. 2つの設定レベル
| 設定レベル | スコープ | 優先度 |
|---|---|---|
| ワークスペース | このプロジェクトのみ | 高(ユーザー設定を上書き) |
| ユーザー | すべてのワークスペース | 低(個人用ツール、一般的なサーバー向け) |
9.3.2. バージョン互換性
| GitLab Workflow extensionバージョン | 利用可能なMCP機能 |
|---|---|
| 6.28.2 - 6.35.5 | 基本MCPサポート |
| 6.35.6以降 | 完全MCPサポート(ワークスペース/ユーザー設定を含む) |
9.3.3. ワークスペース設定の作成
-
<workspace>/.gitlab/duo/mcp.jsonファイルを作成 - 設定を記述
- IDEを再起動
9.3.4. ユーザー設定の作成
VS Code / VSCodium:
- Command Paletteで
GitLab MCP: Open User Settings (JSON)を実行 - 設定を記述
- IDEを再起動
手動作成の場合:
- Windows:
C:\Users\<username>\AppData\Roaming\GitLab\duo\mcp.json - その他:
~/.gitlab/duo/mcp.json
9.4. 設定フォーマット
{
"mcpServers": {
"server-name": {
"type": "stdio",
"command": "path/to/server",
"args": ["--arg1", "value1"],
"env": {
"ENV_VAR": "value"
},
"approvedTools": true
},
"http-server": {
"type": "http",
"url": "http://localhost:3000/mcp",
"approvedTools": ["read_file", "search"]
},
"sse-server": {
"type": "sse",
"url": "http://localhost:3000/mcp/sse"
}
}
}
注意: 他のMCPクライアントでは
mcp.serversを使用する場合がありますが、GitLabではmcpServersを使用してください。
9.5. ツール承認の設定
デフォルトでは、各セッションでサーバーからのすべてのMCPツールを手動承認する必要があります。
approvedToolsフィールド:
| 設定値 | 動作 |
|---|---|
true |
このサーバーの現在および将来のすべてのツールを自動承認 |
["tool1", "tool2"] |
指定したツールのみ承認 |
| 省略 | セッション内のすべてのツールを手動承認(デフォルト) |
警告:
"approvedTools": trueは完全に信頼できるサーバーにのみ使用してください。
9.5.1. ツール承認の仕組み
GitLabは2段階のツール承認システムを使用します:
-
設定ベースの承認(永続的):
mcp.jsonのapprovedToolsで承認。すべてのセッションで持続 - セッションベースの承認(一時的): ランタイム中に承認。IDEを閉じるかワークフローを終了すると消去
いずれかの条件が満たされれば、ツールは承認されます。
9.6. MCPサーバー設定例
9.6.1. ローカルサーバー
{
"mcpServers": {
"enterprise-data-v2": {
"type": "stdio",
"command": "node",
"args": ["src/server.js"],
"cwd": "</path/to/your-mcp-server>",
"approvedTools": ["query_database", "fetch_metrics"]
}
}
}
9.6.2. GitLab Knowledge Graphサーバー
{
"mcpServers": {
"knowledge-graph": {
"type": "sse",
"url": "http://localhost:27495/mcp/sse",
"approvedTools": [
"list_projects",
"search_codebase_definitions",
"get_references",
"get_definition"
]
}
}
}
9.6.3. HTTPサーバー
{
"mcpServers": {
"local-http-server": {
"type": "http",
"url": "http://localhost:3000/mcp",
"approvedTools": ["read_file", "write_file"]
}
}
}
9.7. MCPサーバーのステータス確認
追加の前提条件: GitLab Workflow extension for VS Code v6.55.0以降
確認方法:
- Command Paletteで
GitLab: Show MCP Dashboardを実行 - MCPダッシュボードが新しいタブで開く
ダッシュボードの用途:
- MCPサーバーが正しく設定され、実行されていることを確認
- GitLab Duo機能を使用する前に接続問題を特定
- 各サーバーから利用可能なツールを確認
- サーバー設定の問題をトラブルシューティング
9.8. MCP設定ファイルを開く
ユーザー設定: Command Paletteで GitLab MCP: Open User Settings (JSON)
ワークスペース設定: Command Paletteで GitLab MCP: Open Workspace Settings (JSON)
9.9. MCPサーバーでの再認証
MCP設定ファイルで認証詳細を更新した後、関連するMCPサーバーで再認証する必要があります。
再認証のトリガー方法: そのMCPサーバーからのデータを必要とする質問をGitLab Duoに投げると、認証フローが自動的に開始されます。
9.10. GitLab Duo機能でのMCP使用
GitLab Duo機能が外部ツールを呼び出す際、セッション全体で承認していない限り、そのツールをレビューする必要があります:
注意: MCPサーバー提供のツールのみセッション承認可能。ターミナルやCLIコマンドは不可。
9.11. トラブルシューティング
9.11.1. MCP認証キャッシュの削除
rm -rf ~/.mcp-auth/
9.11.2. Error starting server filesystem: Error: spawn ... ENOENT
このエラーは、相対パス(node 等)を使用してコマンドを指定し、そのコマンドがPATH環境変数で見つからない場合に発生します。
9.12. GitLab MCPサーバー
GitLab自体もMCPサーバーとして機能し、外部AIツール(Claude Desktop、Cursor等)がGitLabデータにアクセスできます。
追加の前提条件: GitLab Duo Coreと実験・ベータ機能が有効化されていること
9.12.1. サポートされる接続方法
| 接続方法 | 説明 | 依存関係 |
|---|---|---|
| HTTP transport(推奨) | 直接接続 | なし |
| stdio transport | プロキシ経由接続 | Node.js v20以降 |
9.12.2. HTTP transport設定
{
"mcpServers": {
"GitLab": {
"type": "http",
"url": "https://<gitlab.example.com>/api/v4/mcp"
}
}
}
9.12.3. stdio transport設定
{
"mcpServers": {
"GitLab": {
"command": "npx",
"args": [
"mcp-remote",
"https://<gitlab.example.com>/api/v4/mcp"
]
}
}
}
9.12.4. 対応クライアント
以下のクライアントがGitLab MCPサーバーに接続できます:
- Cursor(HTTP)
- Claude Code(HTTP)
- Claude Desktop(stdio)
- Gemini Code Assist / CLI(HTTP)
- GitHub Copilot in VS Code(HTTP)
- Continue in VS Code(stdio)
- OpenAI Codex(HTTP)
- Zed(stdio)
各クライアントの詳細な設定方法は、元ドキュメントのセクション9.13を参照してください。
10. Knowledge Graph
Knowledge Graphは、コードベース全体の構造化された表現を作成し、AIエージェントの精度を向上させる基盤技術です。
対応ティア: すべて
対応環境: GitLab.com、GitLab Self-Managed、GitLab Dedicated
ステータス: Beta
10.1. 主な機能
構造要素の識別:
- ファイル、ディレクトリ、クラス、関数、モジュール等を識別
コード関係の把握:
- 関数呼び出し、継承階層、モジュール依存関係などを把握
その他の機能:
- アーキテクチャ図の生成
- MCP経由のクエリ
- RAGアプリケーションでの活用(コードベースをライブグラフデータベースに変換)
10.2. インストールと使用
Knowledge Graphフレームワークは、ワンラインスクリプトでインストールできます。ローカルリポジトリを解析し、Model Context Protocol(MCP)を使用してプロジェクトをクエリするために接続します。
Knowledge GraphはCLI(gkg)も備えています。詳細は、Knowledge Graphプロジェクトドキュメントを参照してください。
11. 分析とメトリクス
11.1. GitLab Duo and SDLC trends
対応ティア: Premium、Ultimate
ステータス: GitLab Self-Managedでは Beta
GitLab DuoがSDLC(Software Development Lifecycle)パフォーマンスに与える影響を測定するダッシュボードです。
活用方法:
- AI投資からどのメトリクスが改善されたかを測定
- プロジェクト/グループのGitLab Duo使用傾向を追跡
- 過去30日間のシート使用と機能採用を監視
11.2. 主要メトリクス
| メトリクス | 説明 | 計算式 |
|---|---|---|
| Assigned Duo seat engagement | 過去30日間にAI機能を使用したDuoシート所有ユーザーの割合 | AI機能使用ユーザー数 / Duoシート総数 |
| Code Suggestions usage | 過去30日間にCode Suggestionsを使用したDuoシート所有ユーザーの割合 | Code Suggestions使用ユーザー数 / コード貢献者数 |
| Code Suggestions acceptance rate | 過去30日間に受け入れられた提案の割合 | 受け入れた提案数 / 生成された提案総数 |
| Duo Chat usage | 毎月Chatと対話するユーザーの割合 | Chatユニークユーザー数 / Duo割り当てユーザー総数 |
注意: Code Suggestionsメトリクスは、コードエディタ拡張機能からのみデータを収集します。
11.3. GitLab Duo使用メトリクス
以下のメトリクスが月別に集計されます:
- Code Suggestions usage(月次ユーザーエンゲージメント)
- Duo RCA usage(Root Cause Analysis使用)
- Duo features usage(全般的な機能使用)
- Duo Code Review requests(レビューリクエスト数)
- Duo Code Review comments(レビューコメント数)
- Duo Agent Platform chats(チャットセッション数)
- Duo Agent Platform flows(フロー実行数)
11.4. 開発メトリクス
- Lead time(リードタイム)
- Median time to merge(マージまでの中央値時間)
- Deployment frequency(デプロイ頻度)
- Merge request throughput(MRスループット)
- Critical vulnerabilities over time(重大脆弱性の時系列推移)
- Contributor count(貢献者数)
11.5. パイプラインメトリクス
| メトリクス | 説明 |
|---|---|
| Total pipeline runs | パイプライン実行回数 |
| Median duration | 実行時間の中央値(分) |
| Success rate | 成功したパイプライン実行の割合 |
| Failure rate | 失敗したパイプライン実行の割合 |
11.6. 視覚化チャート
Code Suggestions acceptance by language: 過去30日間のプログラミング言語別受入数
Code Suggestions acceptance by IDE: 過去30日間のIDE別受入数
Code generation volume trends: 過去180日間の月別コード生成量
Code Review requests by role: 過去180日間の月別レビューリクエスト数(著者/非著者別)
11.7. ユーザー別メトリクス
過去30日間の個別ユーザーによる各GitLab Duo機能の使用状況:
- Code Suggestions usage by user
- Code Review usage by user
- Root Cause Analysis usage by user
- Duo usage by user
11.8. アクセス方法
追加の前提条件:
- Code Suggestionsが有効化されていること
- GitLab Self-Managed: ClickHouse for contribution analyticsが設定されていること
表示方法: Analyze > Analytics Dashboards > GitLab Duo and SDLC trends
APIアクセス: GraphQL API(AiMetrics、AiUserMetrics、AiUsageData)
11.9. メトリクスデータの利用可能性
| GitLab Duoメトリクス | データ計算開始バージョン |
|---|---|
| Code Suggestions usage rate | GitLab 16.11 |
| Root Cause Analysis usage | GitLab 18.0 |
| Code Review requests and comments | GitLab 18.3 |
| Agent Platform chats and flows | GitLab 18.7 |
12. まとめと導入ガイド
12.1. GitLab Duoの特徴
1. 統合性
コーディングからデプロイまで、一貫したAI支援を提供します。単一のプラットフォーム内で、すべての開発活動をサポートします。
2. 拡張性
- MCP: 外部データソースやツールとの標準化された接続
- Knowledge Graph: コードベース全体の構造化された理解
- Agent Platform: カスタムエージェントとフローによる柔軟な自動化
3. 制御性
- カスタムエージェント/フローの作成
- カスタムレビュー指示の設定
- AGENTS.mdによる細かいコンテキスト提供
- バージョンピニングによる安定性確保
4. 可視性
- 詳細なメトリクスダッシュボード
- AI効果の測定
- 投資対効果の可視化
12.2. 段階的導入アプローチ
12.2.1. フェーズ1: 基本機能(1-2週間)
目標: チームがGitLab Duoの基本機能に慣れる
実施内容:
- Code Suggestionsを有効化
- チームメンバーがIDE拡張機能をインストール
- Chat (Classic)の活用開始
- 基本的な使用パターンの確立
12.2.2. フェーズ2: コードレビュー(2-4週間)
目標: レビュープロセスにGitLab Duoを統合
実施内容:
- GitLab Duo Code Reviewの導入
- 自動レビューの有効化(段階的に)
- カスタムレビュー指示の設定
- フィードバック収集と調整
12.2.3. フェーズ3: セキュリティ(4-8週間)
目標: セキュリティワークフローへのAI統合
実施内容:
- Vulnerability Explanation/Resolutionの活用開始
- False Positive Detectionの活用
- セキュリティワークフローへの統合
12.2.4. フェーズ4: カスタマイズ(継続的)
目標: チーム固有のワークフローの最適化
実施内容:
- チーム固有のCustom Agents/Flowsの作成
- MCP連携による外部ツール統合
- Knowledge Graphの活用
- AGENTS.mdによる細かい調整
12.3. 成功のポイント
1. 段階的な導入
すべての機能を一度に導入するのではなく、チームの習熟度に合わせて段階的に展開してください。
2. フィードバックループの確立
- メトリクスダッシュボードで効果を測定
- チームからのフィードバックを定期的に収集
- 設定やワークフローを継続的に改善
3. カスタマイズの活用
- プロジェクト固有のコーディング規約を反映
- チーム固有のワークフローを自動化
- 外部ツールとの統合で効率化
4. トレーニングとサポート
- チームメンバーへの適切なトレーニング
- ベストプラクティスの共有
- 質問や問題への迅速な対応
12.4. 実装例
12.4.1. AGENTS.mdの設定例
# AGENTS.md
## プロジェクトコンテキスト
このプロジェクトはマイクロサービスアーキテクチャを採用しています。
## ディレクトリ構造
- `/services/api`: REST APIサービス
- `/services/worker`: バックグラウンドジョブ処理
- `/shared`: 共通ライブラリ
## コーディング規約
- Pythonコードは PEP 8 に準拠
- すべての関数に型ヒントを追加
- テストカバレッジは80%以上を維持
## テストフレームワーク
- ユニットテスト: pytest
- 統合テスト: pytest + Docker Compose
## CI/CDパイプライン
- すべてのMRでテストとリントを実行
- mainブランチへのマージ時に自動デプロイ
12.4.2. MCPサーバー設定(Knowledge Graph)
{
"mcpServers": {
"knowledge-graph": {
"type": "sse",
"url": "http://localhost:27495/mcp/sse",
"approvedTools": [
"list_projects",
"search_codebase_definitions",
"get_references",
"get_definition"
]
}
}
}
12.4.3. カスタムレビュー指示の例
- セキュリティ: SQLインジェクションやXSS脆弱性を確認
- パフォーマンス: N+1クエリ問題をチェック
- コーディング規約: ESLintルールへの準拠を確認
- テスト: 新機能には必ずユニットテストを含める
- ドキュメント: 公開APIには必ずdocstringを記述
12.5. 最後に
GitLab Duoは、単なるコード補完ツールではなく、開発チーム全体の生産性を向上させる統合プラットフォームです。各機能を段階的に導入し、チームのワークフローに最適化していくことで、最大の効果を得られます。
メトリクスダッシュボードを活用して効果を測定し、継続的な改善を行ってください。