トップヒント
DevEx チームが実際に役立つと感じたワークフローです。共有する価値があるものを発見したら、追加してください。
Glean を使用してコードを検索し、1 日の優先事項を決める
Glean は GitLab のエンタープライズ検索ツールで、GitLab、Slack、Google Drive、ハンドブックを含む内部システムに接続されています。AI アシスタントは、これらすべてのソースにわたる質問に 1 つの場所で回答できます。
コードとコンテキストを検索する:
GitLab、Slack スレッド、ハンドブックを行き来する代わりに、Glean に直接質問します:
「Gitaly コールをモックする RSpec ヘルパーはどこにありますか?」 「メインリポジトリの CI ジョブ定義の構造についての決定の背景は何ですか?」 「メインブランチが壊れたインシデントのランブックを見つけてください」
Glean は接続されたソース全体を検索し、リンク付きで最も関連性の高い結果を表示します。
1 日のトップ優先事項を尋ねる:
1 日の始まりに、Glean の AI アシスタントに注意が必要なことのサマリーを依頼します:
「オープンな Issue と最近の Slack のメンションに基づいて、今日のトップ優先事項は何ですか?」 「昨日のフォローアップが必要な未読のメンションやスレッドをサマリーしてください」 「最近のアクティビティがある私にアサインされた Issue は何ですか?」
ヒント:
- Glean は存在は知っているが素早く見つけられないものを探すのに最適 — GitLab と Slack を別々に検索する代わりに使用します
- 同じ会話でフォローアップの質問をして結果を絞り込みます
- ハンドブックのコンテンツについては、Glean は組み込みのハンドブック検索より速い場合が多いです
会話から GitLab の Issue を作成する
GitLab MCP サーバー が接続されていると、エディタやブラウザを離れることなく、Claude に GitLab で Issue を直接作成させることができます。
プロンプトの例:
「
gitlab-org/gitlabに ‘Investigate flaky spec in pipeline_spec.rb’ というタイトルの GitLab Issue を作成してください。type::bugとteam::devexのラベルを付けてください。説明には再現手順とこのパイプラインの実行へのリンクを含めてください: [URL]。」
Claude は MCP ツールを呼び出し、Issue を作成し、リンクを返します。コンテキストを GitLab UI に切り替えずに、バグ、タスク、フォローアップを途中でキャプチャするのに役立ちます。
ヒント:
- プロジェクトパス(
namespace/project)を明示的に指定します — Claude は推測しません - プロンプトで説明すると、Claude に構造化されたコンテンツ(再現手順、受け入れ基準、リンク)を説明に含めさせることができます
- デバッグセッションの終わりに効果的です: 「見つけたことをサマリーして、修正を追跡する Issue を作成してください」
MR のコメントを取得して VS Code で対処する
マージリクエストにレビューフィードバックがある場合、Claude Code(GitLab MCP サーバー使用)を使用して VS Code を離れずにコメントを取得して作業できます。
ワークフロー:
- VS Code で Claude Code を開く(
Ctrl+Shift+P→Claude Code) - MR のコメントを取得するよう Claude に依頼する:
「
gitlab-org/gitlabの MR !12345 の未解決のレビューコメントを取得してください」 - Claude がコメントを取得し、コンテキスト内にリストアップする
- 一緒に対処する:
「
app/models/pipeline.rbの 42 行目のコメントに対処してください — レビュアーはこれを別のメソッドに抽出するよう求めています」 - Claude が編集を行い、あなたが差分を確認し、次のコメントに進む
ヒント:
- 作業に入る前にコメントのサマリーを依頼します: 「テーマ別にグループ化したフィードバックのサマリーをください」
- 単純な指摘(スタイル、命名、タイポ)については一括対処が可能です: 「すべての指摘コメントを一度に対処してください」
- より複雑なフィードバックには、一度に 1 つのコメントに取り組み、先に進む前に各変更を確認します
- 完了したら、Claude に MR でコメントが対処されたことを確認する返信を投稿させることができます
MR レビュー指示でチーム標準を自動的に適用する
繰り返しレビューコメントを手作業で残す代わりに、.gitlab/duo/mr-review-instructions.yaml に標準をコード化して、GitLab Duo がすべての MR で自動的に適用するようにします。
クイックセットアップ:
リポジトリにファイルを作成します:
instructions:
- name: Test descriptions
fileFilters:
- "spec/**/*.rb"
instructions: |
1. Every `it` block description must read as a complete sentence
describing behaviour, not implementation
2. Flag tests that assert on too many things — suggest splitting them
Duo は一致するファイルに触れる MR をレビューするたびにこれらのチェックを含み、違反を見つけるとルール名への参照とともにコメントします。
始める際の良いルール:
- 評価するために判断が必要なもの — 読みやすさ、明確さ、意図
- リントルールとして表現するには文脈が必要すぎる規約
- チームが人間のレビューで繰り返し指摘するパターン
避けること:
可能な場合はデフォルトで静的解析を使用してください。AI を使用して静的チェッカーを生成することも含めて — 安価で、決定論的で、MR が開かれる前に IDE で表示されます。
より詳細な例と完全な YAML リファレンスについては、メイン AI ページ の MR レビュー指示セクションをご覧ください。
人間のレビュー前に AI による初期 MR レビューを実施する
レビュアーをアサインする前に、MR を AI レビューパスにかけて問題を早期にキャッチします — ロジックのギャップ、不足しているテスト、不明確な命名、スタイルの不一致。これにより人間のレビューが速くなり、より高レベルな懸念事項に集中できます。
Claude Code のワークフロー:
- ブランチをチェックアウトした状態で、Claude に差分のレビューを依頼します:
「このブランチの main への変更をレビューしてください。正確性、テストカバレッジ、レビュアーがフラグを立てそうなことに注目してください。」
- Claude が差分を読み込み、構造化されたフィードバックを提供します
- 人間のレビュアーをアサインする前に問題を対処します
さらに、MR 上で直接 GitLab Duo コードレビュー を使用して、自動化された最初のパスのレビューコメントを取得します。
ヒント:
- 関連する場合は Claude にフォーカスエリアを与えます: 「データベースのクエリに特に注意してください — N+1 を避けたい」
- 不足しているエッジケースを確認させます: 「この変更で対処されておらず、テストでカバーされていないシナリオはありますか?」
- AI レビューをチェックリストとして扱い、ゲートとして扱わないでください — 何に対処するかは判断を使います
- MR が大きい場合、Claude に優先順位をつけさせます: 「レビュアーが指摘するであろう最も重要な 3 つのことをリストしてください」
AI 支援でパイプラインの失敗を修正する
パイプラインが失敗した場合、AI を活用してログを分析し、根本原因を特定し、修正を提案または直接適用することで、「何かが壊れている」から「これが修正方法」まで速く移行できます。
Claude Code のワークフロー:
- 失敗したジョブのログを取得します — 直接貼り付けるか、GitLab MCP サーバーが接続されていれば Claude に取得させます:
「
gitlab-org/gitlabのパイプライン #12345 の失敗したジョブのログを取得してください」 - Claude に失敗を診断させます:
「この CI ログを分析して失敗の根本原因を特定してください」
- コードの問題であれば、Claude に修正させます:
「関連するファイルに修正を適用してください」
- フレーキーなテストや環境の問題であれば、Claude に説明と次のステップの提案をさせます
GitLab Duo 根本原因分析:
GitLab.com のパイプライン失敗については、パイプライン UI で直接 GitLab Duo 根本原因分析 を使用します。失敗したジョブをクリックし、「根本原因分析」 を選択すると、ブラウザを離れずに AI が生成した説明が得られます。
ヒント:
- 長いログでは、Claude に集中させます: 「このログの最初のエラーを探し、後続の失敗は無視してください」
- 修正が明らかでない場合は、仮説を求めます: 「この失敗の最も可能性が高い 3 つの原因は何ですか?」
- 繰り返し発生する失敗については、Claude に git 履歴のコンテキストを確認させます: 「このテストファイルは最近この失敗を説明できる方法で変更されましたか?」
- 修正後、Claude に同様のパターンを別の場所で確認させます: 「このファイルの他のテストで同じ理由で失敗する可能性があるものはありますか?」
整形式のコミットメッセージを生成する
不適切に書かれたコミットメッセージは git log と git blame の有用性を大幅に低下させます。AI を使用して、正確で一貫したフォーマットで conventional commit スタイルに従ったコミットメッセージを生成します。
Claude Code では、直接依頼できます:
「ステージングされた変更のコミットメッセージを書いてください。短いサブジェクト行と理由を説明する簡単な本文を含む conventional commit フォーマットを使用してください。」
Claude はステージングされた差分を読み込み、実際に変更されたことに基づくメッセージを生成します — 「fix stuff」のようなコミットはもうありません。
コミットフォーマットを AGENTS.md に組み込む:
毎回のプロンプトでフォーマットを指定する代わりに、リポジトリの AGENTS.md または CLAUDE.md に追加して、すべてのエージェントが自動的に採用するようにします:
# Commit Messages
- Use conventional commit format: `type(scope): short description`
- Keep the subject line under 72 characters
- Use imperative mood ("add feature", not "added feature")
- Include a body when the change needs context beyond the subject line
- Valid types: feat, fix, chore, docs, refactor, test, ci
- Always link to the relevant issue number in the body if one exists
リポジトリにこれが含まれていると、Claude Code は求めることなくこれらのルールに従います — 会話の途中でコミットメッセージを生成する場合も含めて。
ヒント:
- 差分が複数の懸念事項に触れている場合、Claude にフラグを立てさせます: 「この差分は単一の論理的な変更を表していますか、それとも別々のコミットに分割すべきですか?」
- マージ前のスカッシュコミットでは、サマリーのコミットメッセージを求めます: 「このブランチのすべてのコミットを単一の conventional commit メッセージにサマリーしてください」
- 生成されたメッセージを確認してください — Claude は差分に基づきますが、あなたの方が意図をよく知っています
