QA エンジニアが GitLab Duo でテスト工数を削減した話――抜け漏れ防止からSAST誤検知まで

シリーズ：GitLab Duo を職種別に使い倒す ⑦
対象：GitLab Premium / Ultimate を使っているQAエンジニア・テストエンジニア
動作確認バージョン：GitLab 18.8 以降

「テストケースの抜け漏れ」と「SAST 誤検知の確認」に追われていませんか

QA エンジニアの日常には、こんな場面が繰り返されます。

仕様書を読みながらテストケースを洗い出すが、「これで網羅できているか」という不安が消えない
SAST（静的解析）の検知結果を確認していると、明らかな誤検知が混ざっていて確認コストがかさむ
エンジニアから「このテストで十分ですか？」と聞かれて、コードを読みながら追加ケースを考える
回帰テストの範囲を決めるために、MR の変更内容をひとつひとつ読み込む

GitLab Duo を使うと、これらの作業を効率化できます。特に Duo Chat でのテストケース生成と SAST False Positive Detection は、QA エンジニアの業務に直接刺さる機能です。この記事では、QA の視点から GitLab Duo を使い倒す方法をお伝えします。

まず知っておきたい：Included Credits とは

GitLab Credits は、GitLab Duo Agent Platform を使うための消費単位です。Premium / Ultimate ユーザーには毎月 Included Credits が個人ごとに付与されます。

付与量はプランによって異なります。

プラン	月間 Included Credits
Premium	$12 相当（12 クレジット）
Ultimate	$24 相当（24 クレジット）

注意：この付与量はプロモーション期間中の特典です。将来変更される可能性があります。最新情報は GitLab 料金ページをご確認ください。

重要なポイントが 3 つあります。

個人ごとに付与される（チームの使用量に影響しない）
毎月リセットされる（月初に満額に戻る）
余っても翌月に繰り越せない（使わなければ消える）

QA エンジニアが使う機能のクレジット消費量

機能	1 クレジットで使える回数	注意点
Agentic Chat（テストケース生成など）	モデルによる	会話が長いと消費が増える
Code Review Flow	4 回	MR 1 件あたり 0.25 クレジット
SAST False Positive Detection	1 回	1 クレジット消費。使いどころを絞る
SAST Vulnerability Resolution	0.25 回	1 回に 4 クレジット必要。慎重に使う

SAST 系は他の機能に比べてクレジット消費が大きいため、Included Credits の使いどころを意識する必要があります。まずは Duo Chat でのテストケース生成から始めて、SAST 系は体験用に数回試す、というのが現実的な使い方です。

Step 1：Duo Chat でテストケースを網羅する

Duo Chat を開く

GitLab の任意のページを開きます
画面右下または右サイドバーの 「Duo Chat」アイコンをクリックします
チャットウィンドウが開きます

テスト対象のコードを開いた状態で質問する

Duo Chat はコンテキストを自動で読み取ります。テスト対象のコードファイルを開いた状態で質問すると、そのコードをもとにテストケースを提案してくれます。

テストケースの網羅性チェック

このコードに対するテストケースを洗い出してください。
正常系・異常系・境界値をそれぞれ挙げてください。

抜け漏れの確認

以下のテストケースを作成しました。
抜けている観点があれば指摘してください。

- 正常系：有効なユーザーIDでリクエストした場合
- 異常系：存在しないユーザーIDでリクエストした場合
- 異常系：認証トークンが無効な場合

テストコードの生成

/tests このメソッドに対する pytest のテストコードを生成してください。
正常系・異常系・境界値をカバーしてください。

仕様書からテストケースを生成する

仕様書やイシューの内容をもとにテストケースを生成することもできます。イシューを開いた状態で以下のように質問します。

このイシューに記載された仕様をもとに、
受け入れテストのテストケースを作成してください。
各テストケースは「前提条件・操作・期待結果」の形式で書いてください。

テストケースの優先度付け

以下のテストケースに優先度をつけてください。
リリース前に必ず実施すべきもの（P1）、
時間があれば実施するもの（P2）、
リリース後でもよいもの（P3）に分類してください。

回帰テストの範囲を絞る

MR の変更内容を開いた状態で、回帰テストの範囲を AI に提案してもらえます。

このMRの変更内容を確認して、
回帰テストとして確認すべき機能や画面を
優先度順にリストアップしてください。

Step 2：MR レビューで変更の影響範囲を把握する

QA エンジニアが MR を見るのは、**「この変更でどこをテストすべきか」**を判断するためです。Duo Code Review と組み合わせることで、レビューと影響範囲の把握を同時に行えます。

事前準備：レビューを日本語にする

デフォルトでは Duo のレビューコメントは英語で届きます。日本語にするには .gitlab/duo/mr-review-instructions.yaml を作成します。

レベル 1：まず日本語で受け取ってみる（最小構成）

instructions:
  - name: Review language policy
    fileFilters:
      - "**/*"
    instructions: |
      1. すべてのレビューコメントを日本語で書いてください。
      2. 重要度を「バグ」「提案」「質問」「要確認」で先頭に示してください。
      3. 修正が必要な場合は具体的なコード例を示してください。

レベル 2：QA 観点のレビューを追加する

instructions:
  - name: Review language policy
    fileFilters:
      - "**/*"
    instructions: |
      1. Write all review comments, summaries, and explanations of suggested code changes in Japanese.
      2. Even if code identifiers, existing comments, or documentation are in English, your review text must be in Japanese.
      3. You may include technical terms in English (e.g., function names, class names, framework names), but always explain their meaning or impact in Japanese.
      4. If there are any fixed or automatically generated phrases that must remain in English (for example, system headers), leave them as-is, but keep the main body of your feedback in Japanese.
      5. When you quote code or error messages, keep the code in its original form, but describe problems and recommendations in Japanese.
      6. Start each comment with a one-sentence summary of the issue (what is wrong and why it matters), before providing detailed explanation.
      7. Clearly label the severity of each comment using one of: 「バグ」「提案」「質問」「要確認」.
      8. When suggesting a fix, always provide a concrete code example or a specific action to take, not just a general direction.
      9. Keep comments concise — aim for 5 sentences or fewer per comment unless the issue is complex.

  - name: QA観点のレビュー
    fileFilters:
      - "**/*.py"
      - "**/*.rb"
      - "**/*.go"
      - "**/*.ts"
      - "**/*.java"
    instructions: |
      1. エラーハンドリングが適切か確認してください。
      2. 境界値（空リスト、null、最大値・最小値）の考慮が抜けていないか確認してください。
      3. テストが書かれていない関数や分岐があれば指摘してください。
      4. 副作用（外部 API 呼び出し、DB 書き込みなど）が適切にモックされているか確認してください。
      5. この変更によって既存のテストが壊れる可能性がある箇所を指摘してください。

  - name: テストコードレビュー
    fileFilters:
      - "test_*.py"
      - "*_test.py"
      - "spec/**/*.rb"
      - "**/*.test.ts"
      - "**/*_test.go"
    instructions: |
      1. テストケースが正常系・異常系・境界値をカバーしているか確認してください。
      2. テストの独立性が保たれているか（テスト間に依存関係がないか）確認してください。
      3. アサーションが具体的かどうか確認してください（assertTrue より assertEqual が望ましい）。
      4. テスト名がテストの意図を正確に表しているか確認してください。

  - name: ドキュメントレビュー
    fileFilters:
      - "**/*.md"
      - "docs/**/*"
    instructions: |
      1. 曖昧な表現や主語が不明確な文があれば指摘してください。
      2. 記述内容に矛盾や抜け漏れがあれば指摘してください。
      3. 見出し構造が論理的かどうか確認してください。
      4. 読者が初めてこのドキュメントを読む場合でも理解できるか確認してください。

知っておくと便利
mr-review-instructions.yaml はコードだけでなく、リポジトリに入っているファイルであれば何でもレビュー対象にできます。テスト仕様書やテスト計画書を docs/ で管理している場合も同様にレビューを受けられます。

レベル 3：Code Owners でファイルを保護する

.gitlab/CODEOWNERS に以下を追加して変更を保護します。

[GitLab Duo]
.gitlab/duo @your-qa-lead

MR を開いて AI レビューを依頼する

設定ファイルをマージしたら、実際にレビューを依頼してみましょう。

GitLab 上のオープン中の MR を開きます
コメント欄に /assign_reviewer @GitLabDuo と入力して送信します
（または MR の「レビュアー」欄から @GitLabDuo をアサインします）
30 秒〜2 分ほど待つと、QA 観点のコメントが日本語で届きます

Step 3：SAST False Positive Detection で誤検知を効率的に処理する

GitLab の SAST（静的アプリケーションセキュリティテスト）は、コードのセキュリティ上の問題を自動検出します。しかし、実際には問題ではない「誤検知（False Positive）」が混ざることがあり、その確認作業がQAエンジニアの負担になりがちです。

SAST False Positive Detection Flow を使うと、AI が誤検知かどうかを判定する補助をしてくれます。

使い方

GitLab の 「Security」 タブを開きます
SAST の検知結果一覧から、確認したい項目を選択します
「Explain with AI」 または 「Assess with AI」 ボタンをクリックします
AI が誤検知の可能性とその根拠を日本語で説明してくれます

クレジット消費に注意

SAST False Positive Detection は 1 回に 1 クレジット消費します。Included Credits の範囲で試す場合は、明らかに怪しいと感じる検知結果に絞って使うのが賢明です。

優先度の付け方の目安：

まず AI に確認すべき：脆弱性の深刻度が High 以上のもの
自分で判断できる：過去に同じパターンで誤検知と確認済みのもの
後回しにしてよい：深刻度が Low で、影響範囲が限定的なもの

Duo Chat で詳細を深掘りする

SAST の検知結果について、Duo Chat でさらに詳しく聞くことができます。クレジット消費は Agentic Chat のモデル依存になりますが、1 件あたりの消費は False Positive Detection より小さいため、まずこちらで調べるのも手です。

以下の SAST 検知結果について、誤検知の可能性を評価してください。
また、本当に問題である場合の影響範囲も教えてください。

[検知結果の内容をここに貼り付ける]

QA エンジニアの Duo 活用：週次ルーティン例

以下のようなルーティンで使うと、Included Credits を効率よく使い切れます。

タイミング	使い方	消費目安
MR レビュー時	Duo Chat で影響範囲を確認	1〜2 クレジット/件
テストケース作成時	Duo Chat で網羅性チェック	2〜3 クレジット/回
スプリント開始時	イシューからテスト計画の下書き生成	3〜5 クレジット/回
SAST 確認時	False Positive Detection を High のみに使用	1 クレジット/件

Included Credits との関係
Included Credits は Premium で月 12 クレジット、Ultimate で月 24 クレジットです。上の表をすべて毎週実施すると月間 16〜26 クレジットになり、Premium の Included Credits を超えます。**まずは「MR レビュー時の Chat」と「テストケース作成時の Chat」の 2 つに絞って体験するのがおすすめです。**慣れてきたら SAST 確認を追加し、本格活用は Monthly Commitment Pool 購入後に広げましょう。

クレジット残量の確認方法

自分の使用量はいつでも確認できます。

GitLab.com の場合：上部ナビバーでトップレベルグループを開き、Settings > GitLab Credits > Usage by user タブで確認できます。

Self-Managed の場合：右上の Admin > 左サイドバー GitLab Credits から確認できます。

使用データはリアルタイムではなく、数時間後に反映されます。

まとめ：QA の「抜け漏れ不安」を Duo で解消する

QA エンジニアにとって GitLab Duo が最も価値を発揮するのは、「これで網羅できているか」という不安を解消する場面です。

Duo Chat でテストケースの網羅性をチェックし、抜け漏れを発見する
MR Code Review で変更の影響範囲を把握し、回帰テストの範囲を絞る
SAST False Positive Detection で誤検知の確認コストを削減する（クレジット消費に注意）

「AI が言ったから大丈夫」ではなく、「AI に網羅性を確認してもらった上で、最終判断は自分がする」というスタンスが、QA エンジニアとして AI ツールと正しく付き合う姿勢です。

次の記事

⑥ 手が止まらない開発フローを GitLab Duo で作る（開発・コーディング向け）
⑧ エラーログをそのまま貼るだけ——Duo 活用の障害切り分け術（テクニカルサポート向け）
⑨ GitLab Duo Foundational Agents を試す（上級編・クレジット追加が必要）
[シリーズ総合案内] あなたの職種はどれ？GitLab Duo を使い倒す9つの方法

GitLab Credits の詳細な仕様については公式ドキュメントをご参照ください。