GitHub、ラベルは知っていたけど……Milestones・Projects・Viewsって何？ いつの間に増えたの？
GitHubのIssueにラベルを付けることは知っていました。bugとかenhancementとか、あの色付きの目印です。
ところが、メニューを見ると「Views」「Projects」「Milestones」「Labels」が並んでいる。
えっ、こんなにあったっけ？ そもそも、どう使い分けるの？
調べてみると、以前からあった機能と、最近増えた機能や入り口が一緒に並んでいました。この記事では「ラベルは使うけれど、その先はよくわからない」という目線で整理します。
2026年9月6日時点のGitHub.comの公式資料に基づく解説です。ボタンの位置は画面の更新で変わるため、操作は機能名を目印にしてください。以下の開発例は説明用です。
まず、4つの役割をひと言で
土台になるのはIssue＝やることや相談を記録する1件のチケット。PR（Pull Request）は、コードなどの変更を提案・レビューする単位です。
その周りにある機能を、こんな質問に対応させると理解しやすくなります。
| 機能 | 答えてくれる質問 | 使い方の例 |
|---|---|---|
| Labels | これは何の種類の作業？ | 不具合、改善、ドキュメント |
| Milestones | どの節目までに終える作業？ | v1.1公開、ベータ版完成 |
| Projects | 全体をどう進める？ | 未着手・作業中・完了を並べる |
| Views | 今、どの切り口で見たい？ | 自分の担当だけ、未解決の不具合だけ |
これは使い分けのための整理です。Viewsには、Issuesの検索条件を保存するものと、Projects内の表示を切り替えるものがあります。後ほど分けて説明します。
「いつの間に？」を公式の発表でたどる
実は、Milestonesはかなり前からあります。一方、今回のようなサイドバーには最近の変更が関係しています。
| 時期 | 何が登場・変更された？ |
|---|---|
| 2011年4月9日 | Issues 2.0で、IssueをMilestoneに割り当てる機能を紹介。Labelsはすでに存在していました。当時の発表 |
| 2016年9月14日 | カードを列に並べるProjectsが登場。GitHub Universeの発表 |
| 2022年7月27日 | 新しいProjectsが一般提供へ。今のProjectsを理解するときは、この世代の機能が基準です。一般提供の発表 |
| 2025年5月15日 | リポジトリを横断するIssuesダッシュボードに、検索条件を保存するViewsが登場。保存ビューの発表 |
| 2026年6月25日 | リポジトリのIssuesにも保存ビューがパブリックプレビューで登場。新しいサイドバーにProjects、Milestones、Labelsへの入り口も集約。サイドバーの発表 |
| 2026年8月20日 | 保存ビューをリポジトリのIssuesサイドバーにピン留めする機能が一般提供に。ピン留めの発表 |
「前は見なかった気がする」という感覚にも、ちゃんと理由がありそうです。 画像の並びは、2026年6月の公式発表で説明されているサイドバーと整合します。ただし、この切り抜きだけで撮影時期や、そのアカウントへの提供開始日は特定できません。
古い解説記事を見るときも、2016年当時のProjectsと現在のProjectsでは、操作画面が違うことに気を付けたいところです。
Labels：作業に付ける「分類の目印」
Labelsは、IssueやPRに付ける分類です。1件に複数付けられるので、「不具合」であり「画面に関する作業」でもある、と表せます。
例えば、架空のIssue「スマホでメニューが画面からはみ出す」なら、bugとui。説明書の修正ならdocumentation。名前や色はリポジトリで管理できます。ラベルの公式ガイド
使うときは、Issueを開き、詳細欄の「Labels」から選択します。新しい分類が必要なら、リポジトリの「Labels」画面で作成します。編集には必要な権限があるアカウントを使います。
私なら、最初はbug・enhancement・documentation程度に絞ります。分類を増やしすぎると、作業するより「どれを付けるか」に悩むようになるからです。
Milestones：「次の公開に、何を入れる？」を決める
Milestoneは、同じリポジトリのIssueやPRを、ひとつの節目にまとめる機能です。期限や説明を持たせ、未完了・完了の件数と進捗を確認できます。Milestonesの公式解説
例えば、個人サイトの「v1.1公開」というMilestoneを作り、次の3件を入れます。
- スマホのメニュー表示を直す
- プロフィールを更新する
- お問い合わせへの導線を追加する
bugというラベルは「作業の種類」ですが、v1.1公開というMilestoneは「今回、完成させる範囲」です。不具合修正と文章更新のように、種類が違う作業も同じ節目にまとめられます。
最初のMilestoneを作る手順
- リポジトリのIssuesから「Milestones」を開く。
- 「New milestone」で「v1.1公開」などの名前を付ける。
- 説明に完成条件を書き、必要なら期限を設定する。
- 対象のIssueを開き、「Milestone」欄で割り当てる。
- 一覧で残っている作業を確認する。
作成画面については公式の操作手順を参照できます。
ここで気を付けたいのは、進捗表示を「工数の消化率」と読み替えないこと。小さな文言修正も、大きな機能追加も1件です。残り1件だから、残り時間も少ないとは限りません。
Projects：やることを並べて、進め方を見渡す
Projectsは、IssueやPRを使って計画・進行を管理する場所です。ユーザーやOrganization単位で作り、複数リポジトリにまたがる仕事も整理できます。表示にはTable（表）、Board（カンバン）、Roadmap（時間軸）があります。Projectsの公式解説
例えば、サイトとアプリを並行して作っているなら、「個人開発」というProjectを作って、両方のIssueを集める使い方が考えられます。
| Todo（未着手） | In Progress（作業中） | Done（完了） |
|---|---|---|
| お問い合わせ導線 | スマホ表示の修正 | プロフィール更新 |
上の表はBoardの考え方を表した例です。「今回の公開に何を含めるか」はMilestoneで、「今、何を進めているか」はProjectで把握する、と考えると役割が分かれます。
最初のProjectを作る手順
- 自分のプロフィール、またはOrganizationの「Projects」を開く。
- 「New project」を選ぶ。
- 最初は「Board」を選び、「個人開発」などの名前で作成する。
- 既存のIssueを追加し、Statusで未着手・作業中・完了に整理する。
作成場所とレイアウト選択は公式の作成ガイド、Issueの追加は項目追加のガイドで確認できます。
なお、Projectを作っただけで、すべてのIssueが自動で入るとは限りません。手動で追加するか、自動追加の設定を使います。また、ProjectのStatusとIssueのOpen／Closedは別の項目です。連動させたい場合は、ProjectのWorkflowsを確認します。組み込み自動化のガイド
Views：毎回同じ検索をしなくてよくなる
Viewsは「見たい切り口を保存する」と考えるとわかりやすい機能です。ただし、どこにあるViewなのかで扱うものが違います。
IssuesのViewsは、検索条件の保存
例えば、Issuesで「未解決」「自分が担当」「不具合」と毎回絞り込んでいるなら、その条件を保存しておくと便利です。保存されるのは固定されたIssueのコピーではなく、検索条件。条件に合うIssueが変われば、表示内容も変わります。
Issuesダッシュボードでは「Views」の横の追加ボタンから、名前とQuery（検索条件）を設定し、「Save view」で保存します。保存ビューの公式手順
例えば、次のような条件です。
is:issue is:open assignee:@me
これは「自分が担当する未解決のIssue」。不具合ラベルだけに絞るなら、次のようにします。
is:issue is:open label:bug
リポジトリを横断するダッシュボードで対象を限定したければ、repo:OWNER/REPOを追加します。OWNER/REPOは実際の所有者名とリポジトリ名に置き換え、ラベル名も手元にあるものを指定してください。検索構文の公式ガイド
リポジトリ側のIssuesにある保存ビューは、そのリポジトリの人たちで共有するためのものです。2026年6月の発表では、作成にTriage以上の権限が必要とされています。自分用の横断ダッシュボードと、チームで共有するリポジトリ側の一覧を使い分けます。リポジトリ保存ビューの案内
Projects内のViewは、同じ仕事の見せ方を切り替えるタブ
Projectの中では、同じ項目を使って「全体を表で見る」「作業状況をBoardで見る」など、複数のViewを作れます。絞り込みや並べ替えも保存できます。
Project上部の「New view」で追加し、表示を調整します。後から条件などを変更したときは、未保存の印に注意し、「View」メニューの「Save changes」で保存します。Projectのビュー管理
「別のViewにすると、別の仕事一覧を一から作る」という意味ではありません。同じProjectの項目を、別の角度から見ています。
1件のIssueに重ねてみると、違いがわかる
「スマホでメニューがはみ出す」というIssueなら、こんな組み合わせになります。
| 設定するもの | 値の例 | 意味 |
|---|---|---|
| Labels | bug、ui | 画面に関する不具合 |
| Milestone | v1.1公開 | 次の公開までに直したい |
| Project | 個人開発 | ほかの開発作業と一緒に管理 |
| ProjectのStatus | In Progress | 今、修正している |
| Issuesの保存View | 未解決の不具合 | 検索条件に合うので、この一覧にも出る |
最後のViewはIssueに付ける分類ではなく、Issueが条件に一致して表示される一覧です。4つを無理にどれかひとつに決める必要はなく、それぞれ違う役割を持っています。
個人開発なら、困ったところからひとつ足す
私なら、最初から全部を設定するより、今感じている不便に合わせて足していきます。
- Issueの種類が混ざって探しにくい → Labelsで分類する。
- 次の公開に何を入れるか曖昧 → Milestoneをひとつ作る。
- 毎回同じ検索をしている → IssuesのViewに保存する。
- 同時進行の作業や複数リポジトリを見渡したい → Projectを作る。
例えば、次の更新でやりたいことが3件あるなら、まずはその3件をMilestoneにまとめるだけでも、次の公開までの道筋が見えてきます。
ラベルの先にあったのは、難しい管理機能の山というより、「何の作業か」「どの節目に入れるか」「どう進んでいるか」「今どれを見たいか」を、それぞれ扱う道具でした。
次にGitHubのサイドバーを開いたら、まずは自分が繰り返している検索か、次の公開予定をひとつ、形にしてみようと思います。