エラーログをそのまま貼るだけ――GitLab Duo で障害切り分けを加速する
シリーズ：GitLab Duo を職種別に使い倒す ⑧
対象：GitLab Premium / Ultimate を使っているテクニカルサポートエンジニア・サポートエンジニア
動作確認バージョン：GitLab 18.8 以降
「コードを全部読まないと答えられない」状況から抜け出したい
テクニカルサポートエンジニアの仕事は、「顧客の報告から原因を絞り込み、開発チームに正確に引き継ぐ」 ことです。しかしその過程には、こんな障壁があります。
- 顧客から届いたエラーログを見ても、コードのどこが原因かすぐにわからない
- 原因を特定するために大量のコードを読む必要があるが、時間がかかる
- 「これは既知の問題か、新しいバグか」を判断するために過去の Issue を調べるのが面倒
- 開発チームへのエスカレーション時に、情報が足りなくて何度もやり取りが発生する
- 顧客への回答を書くのに、技術的な内容を非技術的な言葉に変換する手間がかかる
GitLab Duo の Agentic Chat は、こういった「調べる・絞り込む・伝える」の各ステップを加速します。この記事では、テクニカルサポートエンジニアが今日から使える具体的な使い方をお伝えします。
まず知っておきたい：Included Credits とは
GitLab Credits は、GitLab Duo Agent Platform を使うための消費単位です。Premium / Ultimate ユーザーには毎月 Included Credits が個人ごとに付与されます。
付与量はプランによって異なります。
| プラン | 月間 Included Credits |
|---|---|
| Premium | $12 相当（12 クレジット） |
| Ultimate | $24 相当（24 クレジット） |
注意：この付与量はプロモーション期間中の特典です。将来変更される可能性があります。最新情報は GitLab 料金ページ をご確認ください。
重要なポイントが 3 つあります。
- 個人ごとに付与される（チームの使用量に影響しない）
- 毎月リセットされる（月初に満額に戻る）
- 余っても翌月に繰り越せない（使わなければ消える）
テクニカルサポートエンジニアが主に使う Agentic Chat はモデルによってクレジット消費量が変わります。切り分け作業は会話が長くなりやすいため、1 件の障害調査を 1 回の会話でまとめて聞く習慣をつけると効率的です。
Step 1：エラーログをそのまま貼って原因を絞り込む
Duo Chat を開く
- GitLab の任意のページを開きます
- 画面右下または右サイドバーの 「Duo Chat」アイコンをクリックします
- チャットウィンドウが開きます
エラーログをそのまま貼り付ける
Duo Chat の最もシンプルな使い方は、エラーログをそのまま貼り付けて原因を聞くことです。
顧客環境で以下のエラーが発生しています。
考えられる原因と、確認すべき箇所を教えてください。
[エラーログをここに貼り付ける]
複数のエラーが連続している場合は、**最初に発生したエラー（根本原因）**に絞って聞くのが効果的です。
以下のエラーログのうち、根本原因と考えられるものはどれですか？
連鎖的に発生しているエラーがあれば、最初のエラーを特定してください。
[エラーログをここに貼り付ける]
コードベースと照合して原因を深掘りする
エラーの発生箇所が特定できたら、該当ファイルを開いた状態でさらに質問します。
/explain このファイルの処理フローを説明してください。
特に [エラーが発生している処理] の部分が
どのような条件で失敗するか教えてください。
再現条件を絞り込む
このエラーが発生する条件を絞り込みたいです。
以下の情報をもとに、再現に必要な条件を整理してください。
- エラー発生時刻：[時刻]
- 顧客の操作：[操作内容]
- 環境情報：[OS、バージョンなど]
- エラーログ：[ログ内容]
Step 2：既知の問題かどうかを素早く調べる
顧客から報告を受けたとき、最初に確認すべきは**「これは既知の問題か」**です。Duo Chat でイシューやMRを横断的に調べられます。
類似イシューを検索する
このエラーに関連する過去のイシューや MR はありますか？
エラーメッセージ: [エラーメッセージ]
発生箇所: [ファイル名・関数名]
[機能名] に関連するバグ報告や既知の問題はありますか？
最近クローズされたイシューも含めて教えてください。
変更履歴と照合する
直近のデプロイ後に問題が発生している場合、最近の変更と問題の関係を調べます。
[機能名] に関連する最近のMRや変更はありますか？
直近1ヶ月以内にマージされたものを教えてください。
このファイルに最近変更が加えられましたか？
変更内容と、問題との関連性を確認したいです。
Step 3：開発チームへの引き継ぎ情報を整える
切り分けが終わったら、開発チームへのエスカレーション情報を整理します。情報が不足していると開発チームから「もっと情報をください」と差し戻されます。Duo Chat で引き継ぎ内容の品質を上げましょう。
エスカレーションレポートの下書きを生成する
以下の情報をもとに、開発チームへのエスカレーションレポートを作成してください。
「問題の概要」「再現手順」「環境情報」「調査結果」「想定される原因」
「依頼内容」のセクションで整理してください。
[収集した情報をここに貼り付ける]
情報の抜け漏れを確認する
開発チームへのエスカレーションに必要な情報として、
以下の内容に不足している項目があれば指摘してください。
[作成したエスカレーション内容をここに貼り付ける]
イシューの下書きを生成する
GitLab のイシューとして起票する場合は、下書きを生成できます。
以下の調査結果をもとに、GitLab イシューの本文を作成してください。
再現手順・期待する動作・実際の動作・環境情報を含めてください。
[調査結果をここに貼り付ける]
Step 4：顧客向けの回答を生成する
技術的な調査結果を、顧客に伝わる言葉に変換するのもサポートエンジニアの重要な仕事です。
顧客向け回答の下書きを生成する
以下の技術的な調査結果をもとに、
技術的な知識がない顧客向けの回答メールを作成してください。
専門用語を避け、何が起きていて、何をすればよいかを
わかりやすく説明してください。
[調査結果をここに貼り付ける]
暫定対応手順を整理する
根本対応（修正リリース）までの間に顧客に取ってもらう暫定対応を整理します。
この問題の根本修正がリリースされるまでの間、
顧客に取ってもらえる暫定対応策を提案してください。
実施難易度の低い順に並べてください。
Step 5：ドキュメントのレビューで引き継ぎ品質を上げる
サポート手順書やトラブルシューティングガイドを GitLab で管理している場合、MR レビューに mr-review-instructions.yaml を活用できます。
設定ファイルを追加する
リポジトリのルートに .gitlab/duo/mr-review-instructions.yaml を作成します。
レベル 1：まず日本語で受け取ってみる（最小構成）
instructions:
- name: Review language policy
fileFilters:
- "**/*"
instructions: |
1. すべてのレビューコメントを日本語で書いてください。
2. 重要度を「バグ」「提案」「質問」「要確認」で先頭に示してください。
3. 修正が必要な場合は具体的な修正案を示してください。
レベル 2：サポートドキュメント観点のレビューを追加する
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: サポートドキュメントレビュー
fileFilters:
- "**/*.md"
- "docs/**/*"
- "runbooks/**/*"
instructions: |
1. 手順が抜け漏れなく記載されているか確認してください。
2. 前提条件や必要な権限が明記されているか確認してください。
3. 手順の順序が正しいか、依存関係が考慮されているか確認してください。
4. 技術的な知識がないサポート担当者でも実施できる粒度か確認してください。
5. トラブルシューティングのセクションがある場合、よくある失敗パターンが網羅されているか確認してください。
知っておくと便利
mr-review-instructions.yamlはコードだけでなく、リポジトリに入っているファイルであれば何でもレビュー対象にできます。サポート手順書、Runbook、トラブルシューティングガイドなど、チームで管理しているドキュメント類も同じ仕組みでレビューを受けられます。
レベル 3：Code Owners でファイルを保護する
チームの標準として管理するなら、.gitlab/CODEOWNERS に以下を追加して、変更に承認を必要にしましょう。
[GitLab Duo]
.gitlab/duo @your-support-lead
こうすることで、レビュー指示の変更にはサポートリードの承認が必要になり、チーム標準として安定的に管理できます。
MR を開いて AI レビューを依頼する
設定ファイルをマージしたら、実際にレビューを依頼してみましょう。
- GitLab 上のオープン中の MR を開きます
- コメント欄に
/assign_reviewer @GitLabDuoと入力して送信します
（または MR の「レビュアー」欄から@GitLabDuoをアサインします） - 30 秒〜2 分ほど待つと、サポートドキュメント観点のコメントが日本語で届きます
テクニカルサポートの切り分けフロー
Duo Chat を組み込んだ切り分けフローの全体像です。
顧客報告を受ける
↓
【Duo Chat】エラーログを貼り付けて原因候補を絞り込む
↓
【Duo Chat】既知の問題・類似イシューを検索する
↓
【Duo Chat】再現条件を整理する
↓
自分で再現確認・追加調査を行う
↓
【Duo Chat】エスカレーションレポートの下書きを生成する
↓
【Duo Chat】情報の抜け漏れを確認する
↓
開発チームへエスカレーション or 顧客へ回答
↓
【Duo Chat】顧客向け回答の下書きを生成する
クレジットの消費目安
テクニカルサポートエンジニアが日常的に使う場合の消費目安です。
| 用途 | 1 件あたりの消費目安 |
|---|---|
| エラーログの原因調査（短い会話） | 2〜3 クレジット |
| 切り分け全体（長い会話） | 5〜10 クレジット |
| エスカレーションレポート生成 | 2〜3 クレジット |
| 顧客向け回答生成 | 1〜2 クレジット |
1 件の障害対応で複数の会話をするより、1 回の会話に情報をまとめて聞くほうがクレジットを節約できます。
クレジット残量の確認方法
自分の使用量はいつでも確認できます。
GitLab.com の場合：上部ナビバーでトップレベルグループを開き、Settings > GitLab Credits > Usage by user タブで確認できます。
Self-Managed の場合：右上の Admin > 左サイドバー GitLab Credits から確認できます。
使用データはリアルタイムではなく、数時間後に反映されます。
まとめ：「調べる・絞り込む・伝える」を Duo で加速する
テクニカルサポートエンジニアにとって GitLab Duo が最も価値を発揮するのは、**「大量の情報を素早く整理して正確に伝える」**場面です。
- エラーログをそのまま貼り付ける — 原因候補の絞り込みを AI に任せる
- 既知の問題を素早く調べる — イシュー・MR の横断検索を Duo Chat で行う
- エスカレーションと顧客回答の品質を上げる — 下書き生成と抜け漏れチェックを活用する
-
サポートドキュメントのレビューを自動化する —
mr-review-instructions.yamlでドキュメント品質を底上げする
「コードが全部読めなくても、切り分けの精度を上げられる」——それが GitLab Duo をテクニカルサポートエンジニアが使う最大の理由です。
シリーズ一覧
- ① GitLab Duo、契約してるのに使っていない人へ（エンジニア全般向け）
- ② チームに GitLab Duo を展開する前に読む記事（テックリード向け）
- ③ 「AI ツール、試したけど定着しなかった」人が GitLab Duo を使い始める方法（中堅エンジニア向け）
- ④ コードを書かない PM こそ GitLab Duo を使うべき理由（PM向け）
- ⑤ 巨大コードベースの全体把握に GitLab Duo が効いた（設計・アーキテクト向け）
- ⑥ 手が止まらない開発フローを GitLab Duo で作る（開発・コーディング向け）
- ⑦ QA エンジニアが GitLab Duo でテスト工数を削減した話（テスト・QA 向け）
- ⑧ エラーログをそのまま貼るだけ——Duo 活用の障害切り分け術（テクニカルサポート向け）← この記事
- ⑨ GitLab Duo Foundational Agents を試す（上級編・クレジット追加が必要）
- [シリーズ総合案内] あなたの職種はどれ？GitLab Duo を使い倒す9つの方法
GitLab Credits の詳細な仕様については 公式ドキュメント をご参照ください。