0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

シリーズ：GitLab Duo を職種別に使い倒す ⑥

0
Last updated at Posted at 2026-06-02

手が止まらない開発フローを GitLab Duo で作る――コーディング系エンジニア向け活用ガイド

シリーズ：GitLab Duo を職種別に使い倒す ⑥
対象：GitLab Premium / Ultimate を使っている開発・コーディング系エンジニア
動作確認バージョン：GitLab 18.8 以降

「手が止まる瞬間」を数えたことはありますか

1 日の開発時間のうち、実際にコードを書いている時間はどのくらいでしょうか。

  • 関数名や変数名が思い浮かばず、手が止まる
  • エラーメッセージの原因を調べるためにドキュメントを読み漁る
  • テストコードを書くのが面倒で後回しにしてしまう
  • MR を出した後、レビューが来るまで別の作業に切り替えてコンテキストが飛ぶ
  • 自分でレビューしてから出したいが、時間が取れない

GitLab Duo を使うと、これらの「手が止まる瞬間」をひとつずつ潰していけます。この記事では、開発速度を上げるための具体的な使い方をお伝えします。

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

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

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

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

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

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

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

開発・コーディング系エンジニアにとって最もコスパが高いのが Code Suggestions です。1 クレジットで 50 回実行できるため、Included Credits の大半をここに集中投下しても十分使い続けられます。

Step 1：Code Suggestions で「Tab 駆動開発」を体験する

Web IDE を起動する

  1. GitLab 上の任意のリポジトリを開きます
  2. ファイル一覧から編集したいファイルを選択します
  3. 右上の 「Edit」ボタン → 「Open in Web IDE」 を選択します

VS Code Extension や JetBrains Plugin を使っている場合は、ローカル環境でもそのまま Code Suggestions が使えます。

コメントファースト、コードはあとから

Code Suggestions を最大限に活用するコツは、コードを書く前にコメントで意図を書くことです。

精度が低い書き方

def process(data):

精度が上がる書き方

# 引数: 注文リスト（辞書のリスト、各辞書は user_id, amount, created_at を持つ）
# 戻り値: user_id ごとの合計金額の辞書
# 注意: created_at は ISO 8601 形式の文字列
def aggregate_orders_by_user(orders: list[dict]) -> dict[str, int]:

コメントを書いたら入力を止めて 0.5 秒待つと、グレーのテキストで補完候補が現れます。

  • Tab キー：提案を受け入れる
  • Esc キー：提案を無視してそのまま入力を続ける

Tab 駆動開発のリズムをつかむ

慣れてくると、以下のリズムで開発が進みます。

  1. コメントで関数の仕様を書く
  2. 関数のシグネチャを書き始める
  3. Tab で補完を受け入れる
  4. 意図と違う部分だけ修正する
  5. 次の関数のコメントを書く → 繰り返し

「Tab を押すかどうか 1 秒で判断する」 くらいのスピード感で使うのがコツです。迷ったら Esc で断って自分で書けばいい。補完に頼りすぎず、使えると感じたものだけ使う姿勢が長続きのコツです。

テストコードも補完させる

テストコードは書くのが面倒に感じやすいですが、Code Suggestions と相性が抜群です。

# test_aggregate_orders_by_user のテストケース
# 正常系: 複数ユーザーの注文を正しく集計できること
def test_aggregate_orders_by_user_normal():

ここで Tab を押すと、アサーションまで含めたテストコードが提案されます。提案の精度が低ければ、コメントに「期待する入力と出力の例」を書くとより具体的な提案が返ってきます。

# 入力: [{"user_id": "A", "amount": 100}, {"user_id": "A", "amount": 200}, {"user_id": "B", "amount": 300}]
# 期待する出力: {"A": 300, "B": 300}
def test_aggregate_orders_by_user_normal():

Step 2：Duo Chat でデバッグを加速する

エラーに詰まったとき、Google 検索や Stack Overflow を開く前に Duo Chat に貼り付けるのが最速です。

Duo Chat を開く

  1. GitLab の任意のページを開きます
  2. 画面右下または右サイドバーの 「Duo Chat」アイコンをクリックします

エラーをそのまま貼り付ける

以下のエラーが出ています。原因と修正方法を教えてください。

TypeError: 'NoneType' object is not subscriptable
  File "app/services/order_service.py", line 42, in aggregate_orders
    return orders[0]["user_id"]

スラッシュコマンドでコードに直接質問する

コードファイルを開いた状態でスラッシュコマンドを使うと、そのコードをコンテキストとして質問できます。

コマンド 使い方
/explain 「このコードが何をしているか理解したい」
/refactor 「このコードをきれいにしたい」
/tests 「このコードのテストを生成したい」
/fix 「このコードのバグを直したい」

実際の使い方例

複雑な処理が書かれたファイルを開いて：

/explain このクラスの責務と、各メソッドの役割を日本語で説明してください。

リファクタリング前に：

/refactor このメソッドを読みやすくしてください。
ただし、外部インターフェースは変えないようにしてください。

「なぜこうなっているか」を聞く

既存のコードを読んでいて意図がわからないとき、/explain で聞くより 「なぜ」を直接質問する ほうが有益な回答が得られます。

このコードで、なぜ `sorted()` の前に `list()` を呼んでいるのですか？
単に `sorted(items)` ではいけない理由はありますか？

Step 3：MR を出す前に自分で AI レビューを受ける

「MR を出してからレビューを待つ間にコンテキストが飛ぶ」問題は、MR を出す前に自分で Duo Code Review を走らせることで軽減できます。

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

デフォルトでは Duo のレビューコメントは英語で届きます。日本語にするには .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:
      - "**/*.py"
      - "!test_*.py"
      - "!*_test.py"
    instructions: |
      1. エラーハンドリングが適切か確認してください。
      2. 関数が単一の責務を持っているか確認してください。
      3. マジックナンバーや文字列リテラルが直書きされていないか確認してください。
      4. テストがない関数があれば指摘してください。

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

知っておくと便利
mr-review-instructions.yaml はコードだけでなく、リポジトリに入っているファイルであれば何でもレビュー対象にできます。README や設計ドキュメントなど、MR に含まれるドキュメント類も自動的にレビューされます。

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

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

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

MR を出す前のセルフレビューフロー

  1. MR をドラフト状態で作成します（「Draft:」 をタイトルの先頭に付ける）
  2. コメント欄に /assign_reviewer @GitLabDuo と入力して送信します
  3. 届いたコメントを確認し、対応できるものを修正します
  4. 修正が終わったらドラフトを解除して、人間のレビュアーにアサインします

このフローを習慣にすると、人間のレビュアーに届く MR の品質が上がり、レビューラウンド数が減ります。結果としてレビュー待ち時間も短縮されます。

Duo Chat でレビューコメントを深掘りする

AI のコメントで「なぜこれが問題なのかわからない」と感じたら、MR を開いた状態で Duo Chat に聞けます。

Duo Code Review で「マジックナンバーを避けるべき」と指摘されました。
このコードの場合、具体的にどう修正すればいいですか？

クレジットの消費目安

開発・コーディング系エンジニアが日常的に使う場合の月間消費目安です。

用途 1 回あたりの消費目安 月 20 回の場合
Code Suggestions（50 回補完） 1 クレジット 20 クレジット
Duo Chat（デバッグ・質問） 1〜3 クレジット 20〜60 クレジット
MR Code Review（1 件） 0.25 クレジット 5 クレジット

Included Credits との関係
Included Credits は Premium で月 12 クレジット、Ultimate で月 24 クレジットです。Code Suggestions は圧倒的にコスパが高く、1 日 50 回補完を受け入れても 1 クレジットしか消費しません。ただし Duo Chat を頻繁に使うと Included Credits を超えます。Code Suggestions を軸に使い、Chat は詰まったときだけに絞るのが Included Credits を最大限に活かすコツです。

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

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

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

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

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

まとめ：「手が止まる瞬間」を 3 つの武器で潰す

  1. Code Suggestions：コメントを書いて Tab を押す。1 クレジット 50 回、使い惜しみ不要
  2. Duo Chat：エラーはすぐ貼り付ける。/explain・/refactor・/tests を使いこなす
  3. MR Code Review：ドラフト MR で先に自己レビュー。人間のレビュアーに届く品質を上げる

「手が止まるたびに Tab を押す習慣」と「詰まったらすぐ Duo Chat に聞く習慣」の 2 つが身につくだけで、1 日の開発時間の質は大きく変わります。

次の記事

  • ① GitLab Duo、契約してるのに使っていない人へ（エンジニア全般向け）

  • ⑤ 巨大コードベースの全体把握に GitLab Duo が効いた（設計・アーキテクト向け）

  • ⑦ QA エンジニアが GitLab Duo でテスト工数を削減した話（テスト・QA 向け）

  • ⑨ GitLab Duo Foundational Agents を試す（上級編・クレジット追加が必要）

  • [シリーズ総合案内] あなたの職種はどれ？GitLab Duo を使い倒す9つの方法

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?