ラベル、コメント、スレッド

Posted at 2025-11-20

ラベル、コメント、スレッド

プロジェクトが成長し、チームが拡大するにつれて、作業の追跡と管理は複雑になります。GitLabは、この課題に対して「ラベル」と「ディスカッション」という2つの強力な機能を提供しています。これらの機能を組み合わせることで、チームのコミュニケーションを円滑にし、作業の優先順位付けを明確にできます。

1. ラベル機能:作業を整理し、可視化する

ラベルは、GitLabの各種機能にわたって作業を整理・追跡するための仕組みです。イシュー、マージリクエスト、エピックにカスタム属性を付与し、リストやボードでフィルタリングできます。

1.1 ラベルの3つのスコープ

GitLabでは、スコープに応じて3種類のラベルを使い分けられます。

タイプ	スコープ	用途
プロジェクトラベル	特定のプロジェクト内	プロジェクト固有の分類
グループラベル	グループおよびサブグループ内	複数プロジェクト横断の分類
インスタンスラベル	インスタンス全体	組織全体の標準分類

1.2 スコープドラベル:排他的な状態管理

Premium以上のティアでは、スコープドラベルが利用できます。二重コロン(::)を使った命名規則により、相互排他的なラベルを実現します。

基本構文

<スコープ>::<値>

例: workflow::development、priority::high、platform::iOS

動作原理

同じスコープを持つラベルは、1つのイシュー/マージリクエスト/エピックに1つしか割り当てられません。新しいラベルを追加すると、既存の同スコープラベルは自動的に削除されます。

実用例

ユースケース	ラベル例	効果
ワークフロー管理	`workflow::planning` `workflow::development` `workflow::review` `workflow::deployed`	開発フローの各段階を明確化
優先度管理	`priority::low` `priority::medium` `priority::high` `priority::critical`	優先度の重複を防止
プラットフォーム指定	`platform::iOS` `platform::Android` `platform::Linux`	対象プラットフォームを一意に特定
環境指定	`env::development` `env::staging` `env::production`	デプロイ環境を明確化

1.3 ネストされたスコープ

複数の二重コロンを使用することで、階層的な管理が可能です。最後の::より前の部分がスコープとして扱われます。

例

workflow::backend::review
workflow::backend::development
workflow::frontend::review
workflow::frontend::development

この場合の排他関係:

workflow::backend::review ⇔ workflow::backend::development (排他)
workflow::frontend::review ⇔ workflow::frontend::development (排他)
workflow::backend::review + workflow::frontend::review (共存可能)

1.4 スコープドラベルのフィルタリング

スコープ全体でフィルタリングする場合、ワイルドカード構文を使用します。

構文

<スコープ>::*

例

platform::* → platform::iOS、platform::Android、platform::Linuxのいずれかを持つイシューを抽出
workflow::backend::* → workflow::backend::review、workflow::backend::developmentのいずれかを持つイシューを抽出

注意: イシューまたはマージリクエストのダッシュボードページでは、スコープドラベルによるフィルタリングは利用できません。

1.5 ラベルの優先順位設定

ラベルに相対的な優先順位を設定することで、イシューやマージリクエストのリストをラベル優先度でソートできます。

設定方法

プロジェクトの「管理」→「ラベル」を開きます
優先順位を付けたいラベルの星アイコンを選択します
「優先ラベル」セクションでドラッグ&ドロップして順序を調整します

注意: 優先度ソートは、最も高い優先度のラベルのみに基づいて行われます。複数の優先ラベルが割り当てられている場合、最も高い優先度のものが使用されます。

1.6 リアルタイム更新

GitLab 15.6以降、ラベルの変更はページをリフレッシュすることなく、他のユーザーに即座に表示されます。この機能は以下のオブジェクトで利用可能です。

エピック
インシデント
イシュー
マージリクエスト

1.7 ラベルのライフサイクル管理

アーカイブ機能(GitLab 18.3以降、ベータ版)

使用頻度が低くなったラベルを履歴として保持できます。

選択ドロップダウンリストから非表示
既存のアイテムでは引き続き表示
検索と履歴参照は可能
優先順位は自動的に解除

マージ時のラベルロック(GitLab 16.3以降、ベータ版)

監査要件に対応するため、マージリクエストがマージされた際にラベルをロックできます。

マージ後は誰もラベルを削除できません
設定は不可逆的です
イシューとエピックでは通常のラベルとして動作します

プロジェクトラベルのグループラベルへの昇格

プロジェクトラベルをグループラベルに昇格することで、同じグループ内の他のプロジェクトでも利用可能になります。

同じタイトルのラベルは自動的にマージされます
昇格は永続的で元に戻せません
イシュー、マージリクエスト、イシューボード、ラベル購読はすべて新しいグループラベルに引き継がれます

1.8 デフォルトラベルセット

プロジェクトまたは親グループにラベルがない場合、以下のデフォルトラベルセットを生成できます。

bug, confirmed, critical, discussion, documentation, 
enhancement, suggestion, support

1.9 ラベルの購読

ラベルを購読することで、そのラベルが割り当てられたときに通知を受け取れます。グループラベルの場合、プロジェクトレベルまたはグループレベルでの購読を選択できます。

2. ディスカッション機能:コミュニケーションを構造化する

GitLabのディスカッション機能は、コメントとスレッドを通じてチーム内のコミュニケーションを促進します。Markdownとクイックアクションをサポートし、コードの変更提案も可能です。

2.1 コメントの基本

対応オブジェクト

コミットdiff、コミット、デザイン、エピック、イシュー、マージリクエスト、スニペット、タスク、OKR、Wikiページ

制限: 各オブジェクトには最大5,000件のコメントを追加できます。

2つのコメントタイプ

標準コメント: 単独のコメント
スレッドコメント: 解決可能なコメントスレッド

2.2 メンション機能

基本構文

@ユーザー名
@グループ名
@グループ名/サブグループ名

動作

メンションされたユーザーにToDoアイテムとメール通知が送信されます
自分自身へのメンションは異なる色でハイライト表示されます
既存のコメントを編集してメンションを追加した場合、ToDoアイテムは作成されますが、メール通知は送信されません

注意: @allのメンションは避けてください。GitLab 16.1以降、@allを無効化するフィーチャーフラグが導入されています。

2.3 マージリクエストdiffへのコメント

マージリクエストのdiffにコメントを追加すると、リベース後の強制プッシュやコミットの修正を行っても、コメントは保持されます。

コメント方法

ファイル全体: ファイルヘッダーの「このファイルにコメント」アイコンを選択
特定の行: 行番号にカーソルを合わせて「コメント」アイコンを選択(複数行の場合はドラッグ)

送信オプション

オプション	動作	ショートカット
今すぐコメントを追加	即座に公開	macOS: `Shift+Command+Enter` その他: `Shift+Control+Enter`
レビューを開始	レビュー完了まで非公開	macOS: `Command+Enter` その他: `Control+Enter`

技術的な特徴

コメント内のコミット参照は、マージリクエストのコンテキストでリンクに変換されます。

例: 28719b171a056960dfdc0012b625d0b47b123196 → 28719b17(リンク)

2.4 スレッドの作成と解決

スレッド作成方法

既存コメントへの返信: コメントの「コメントに返信」アイコンを選択
新規スレッド: コメント入力後、「コメント」ボタンの下矢印から「スレッドを開始」を選択

スレッド解決

解決されたスレッドは折りたたまれますが、引き続きコメントを追加できます。

解決方法:

元のコメントの「スレッドを解決」アイコンを選択
返信フィールドで「スレッドを解決」を選択
返信入力時に「スレッドを解決」チェックボックスを選択

対応オブジェクト

オブジェクト	対応バージョン	備考
マージリクエスト	初期から対応	-
イシュー	GitLab 16.7以降	-
タスク、目標、主要結果	GitLab 17.3以降	-
エピック	GitLab 18.1以降	新しいエピックUIが必要

マージリクエスト固有の機能

オープンなスレッドを新しいイシューに移動
すべてのスレッドが解決されるまでマージを防止

2.5 内部ノート

公開イシュー、エピック、Wikiページ、マージリクエストに機密情報を追加する場合に使用します。

特徴

Reporter以上のロールを持つプロジェクトメンバーのみが閲覧可能
通常のコメントに変換不可
内部ノートへの返信もすべて内部ノート
「内部ノート」バッジと異なる色で表示

使用方法

コメント入力後、「これを内部ノートにする」を選択して「内部ノートを追加」を選択します。

代替手段

イシュー全体を機密にする
機密マージリクエストを作成する

2.6 ディスカッションのロック

公開コメントを防止し、プロジェクトメンバーのみがコメントを追加・編集できるようにします。

前提条件

マージリクエスト: Developer以上
イシュー: Planner以上

注意: クローズされたイシューやマージリクエストを再オープンする前に、すべてのロックを解除する必要があります。

2.7 アクティビティのフィルタリングとソート

フィルタオプション

オプション	表示内容
すべてのアクティビティを表示	ユーザーコメント + システムノート
コメントのみを表示	ユーザーコメントのみ
履歴のみを表示	システムノートのみ

ソート順

イシュー/エピック: 「最新順」または「最古順」
マージリクエスト: 「昇順」または「降順」

設定はローカルストレージに保存され、すべてのオブジェクトに適用されます。

2.8 その他の機能

メール返信

「メール返信」機能が設定されている場合、メールでコメントに返信できます。Markdownとクイックアクションも使用可能です。

コメント作成者への割り当て

コメントの「その他のアクション」メニューから「コメント作成者に割り当て」を選択できます。

説明の変更履歴(Premium以上)

説明の変更を履歴で確認し、「前のバージョンと比較」で差分を表示できます。

GitLab Duo Chatによる要約(Premium以上、GitLab Duo Enterpriseアドオン必要)

イシューのディスカッションを最大10個のリストアイテムに要約できます。すべてのコメントのテキストが大規模言語モデルに送信されます。

3. 実践的な活用パターン

3.1 ワークフロー管理の実装例

シナリオ: バックエンドとフロントエンドの並行開発

使用ラベル

type::feature, type::bug, type::refactoring
priority::low, priority::medium, priority::high, priority::critical
platform::web, platform::mobile, platform::api
workflow::backend::development, workflow::backend::review, workflow::backend::deployed
workflow::frontend::development, workflow::frontend::review, workflow::frontend::deployed
env::development, env::staging, env::production

3.2 コードレビュープロセスの最適化

ステップ1: レビュー開始

マージリクエストを作成し、workflow::reviewラベルを追加
レビュアーをメンションして通知
重要な変更箇所にdiffコメントを追加

ステップ2: レビュー実施

diffの各行にコメントを追加(「レビューを開始」を使用)
議論が必要な箇所はスレッドを作成
すべてのコメントを追加後、レビューを送信

ステップ3: 修正と解決

作成者が修正を実施
修正完了後、スレッドに返信
レビュアーが確認してスレッドを解決

ステップ4: マージ

すべてのスレッドが解決されたことを確認
workflow::deployedラベルに変更
マージを実行

3.3 イシュートリアージの自動化

ラベル構成

triage::new (新規イシュー)
triage::investigating (調査中)
triage::confirmed (確認済み)
triage::wontfix (対応しない)

フロー

3.4 リリース管理

ラベル構成

release::v1.0, release::v1.1, release::v2.0
status::planned, status::in-progress, status::completed

運用

リリース計画時にrelease::v1.0とstatus::plannedを追加
開発開始時にstatus::in-progressに変更
リリース完了後にstatus::completedに変更
古いリリースラベルはアーカイブ

3.5 セキュリティイシューの管理

機密情報の保護

イシューを機密に設定
内部ノートで脆弱性の詳細を記録
security::criticalラベルを追加
修正完了後、内部ノートで検証結果を記録

通知範囲

イシューに割り当てられたユーザー
Planner以上のロールを持つユーザー
イシュー作成者(Guest以上のロール)

4. 推奨される運用パターン

4.1 初期設定

デフォルトラベルセットの生成: プロジェクト開始時に基本ラベルを作成
スコープドラベルの設計: チームのワークフローに合わせて設計
グループラベルの活用: 複数プロジェクトで共通のラベルを使用
優先順位の設定: 重要なラベルに優先順位を付与

4.2 日常運用

ラベルの一貫性: 命名規則を統一し、チーム全体で共有
リアルタイム更新の活用: ページリフレッシュなしで最新状態を確認
フィルタリングの活用: platform::*などのワイルドカード構文を使用
スレッド解決の徹底: 議論が完了したら必ず解決

4.3 レビュープロセス

diffコメントの活用: 具体的な行にコメントを追加
スレッドの構造化: 関連するコメントをスレッドにまとめる
内部ノートの使用: 機密情報は内部ノートで共有
解決条件の明確化: マージ前にすべてのスレッドを解決

4.4 情報管理

アクティビティフィルタ: コメントのみ表示で議論に集中
ソート順の調整: 最新順で最近の活動を追跡
ラベル購読: 重要なカテゴリの通知を受け取る
アーカイブの活用: 古いラベルを整理

4.5 スケーラビリティ

グループラベルへの昇格: プロジェクトラベルを必要に応じて昇格
ネストされたスコープ: 大規模プロジェクトでは階層的に管理
ラベルのライフサイクル: 使用頻度に応じてアーカイブ
権限管理: Planner以上のロールでラベル管理を制限

5. まとめ

GitLabのラベルとディスカッション機能は、以下の点で技術的に優れています。

ラベル機能の強み

スコープドラベルによる排他的な状態管理
ネストされたスコープによる階層的な分類
リアルタイム更新による即座の可視化
ワイルドカード構文による柔軟なフィルタリング
ライフサイクル管理(アーカイブ、ロック、昇格)

ディスカッション機能の強み

スレッドによる構造化されたコミュニケーション
diffコメントの永続性(リベース後も保持)
内部ノートによる機密情報の保護
解決機能による進捗の可視化
メール返信やクイックアクションによる効率化

組み合わせの効果

スコープドラベルとディスカッションスレッドを組み合わせることで、分散したチームでも一貫したワークフローを維持できます。特に、マージリクエストのレビュープロセスでは、diffコメント、スレッド解決、ラベルの自動更新を連携させることで、レビューの完了状態を明確にできます。

次のステップ

チームのワークフローに合わせたスコープドラベルを設計
デフォルトラベルセットを生成し、必要に応じてカスタマイズ
レビュープロセスでスレッド解決を導入
機密情報の扱いに内部ノートを活用
プロジェクトの成長に合わせてラベルをグループレベルに昇格

これらの機能を段階的に導入し、チームに最適な運用パターンを確立していくことをお勧めします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up