GitHub の Issue fields は、Issue に「優先度」「工数」「開始日」「期限」「独自分類」などの構造化された項目を追加できる機能です。2026年7月2日の公式 Changelog で一般提供が発表され、GitHub Issues をタスク管理や開発計画に使っている組織では、ラベル運用や Projects のカスタムフィールド運用を見直すタイミングになりました。(The GitHub Blog)
今回の更新で重要なのは、Issue fields が単なる入力欄の追加ではなく、組織横断で同じメタデータを扱える仕組みになった点です。複数リポジトリで Issue を管理しているチーム、Priority や Effort をラベルで代用しているチーム、GitHub Projects と Issues の情報がずれがちなチームは、早めに設定方針を決めておくと運用負荷を減らせます。
GitHub の「Issue fields are now generally available」とは
Issue fields は、GitHub Issues に対して組織レベルで定義したフィールドを付与できる機能です。従来は、Issue の状態や重要度を表すために、ラベル、マイルストーン、Projects のカスタムフィールド、本文テンプレートなどを組み合わせるケースが多くありました。
しかし、ラベルで priority-high や effort-large のような値を管理すると、次のような問題が起きやすくなります。
- リポジトリごとにラベル名や色がばらつく
- 「優先度」と「分類」のラベルが混ざり、Issue 一覧が読みづらくなる
- Projects に入っていない Issue では同じ情報を追跡しにくい
- API や自動化で扱う際に値の意味が曖昧になる
Issue fields では、こうした情報を「ラベル名」ではなく、型付きのフィールドとして扱えます。GitHub 公式ドキュメントでは、Issue fields は組織内のすべてのリポジトリにまたがって構造化メタデータを収集するための機能と説明されています。(GitHub Docs)
今回の一般提供で変わった主なポイント
2026年7月2日の更新では、Issue fields が一般提供になったことに加え、Public Preview 以降の改善点もあわせて示されています。実務上の確認ポイントを整理すると、次のとおりです。
| 変更点 | 実務での意味 | 確認すべき人 |
|---|---|---|
| 一般提供開始 | プレビュー前提ではなく、本格運用を検討しやすくなった | 管理者、開発責任者 |
| Issue 一覧でフィールド値を表示 | Issue を開かずに優先度や工数を確認できる | 開発者、PM、サポート担当 |
| Public projects 対応 | 公開プロジェクトでもフィールドを使いやすくなった | OSS 管理者、公開ロードマップ担当 |
| 表示範囲の制御 | 非メンバーに見せる項目を制御できる | Organization 管理者 |
| MCP integration | Copilot などの AI ツールがフィールド値を読み書きしやすくなった | 開発者、AI 活用担当 |
| 非英語文字のサポート | 日本語のフィールド名を使いやすくなった | 日本語圏のチーム |
| 信頼性改善 | 並び順、タイムスタンプ、候補表示などの不具合が改善 | 全ユーザー |
GitHub の発表では、Issue fields は Free、Team、Enterprise、GitHub Enterprise Cloud with data residency の各プランの GitHub organization で利用可能になり、GitHub Enterprise Server 3.23 にも提供予定とされています。(The GitHub Blog)
Issue fields でできること
Issue fields でできることを一言で言えば、Issue に「表計算ソフトの列」のような情報を持たせられることです。ただし、リポジトリ単位ではなく Organization 単位で定義されるため、複数リポジトリをまたいだ管理に向いています。
優先度や工数を標準化できる
GitHub は、Issue fields の既定フィールドとして Priority、Effort、Start date、Target date の4つを自動作成すると説明しています。これらはカスタマイズ可能で、組織の運用に合わなければ名前、説明、選択肢などを変更できます。(GitHub Docs)
たとえば、次のような使い方ができます。
| フィールド | 使い方の例 | 運用上のメリット |
|---|---|---|
| Priority | Urgent、High、Medium、Low | 緊急度の高い Issue をすばやく抽出できる |
| Effort | XS、S、M、L、XL または High、Medium、Low | 見積もりやスプリント計画に使いやすい |
| Start date | 対応開始予定日 | 着手漏れを防ぎやすい |
| Target date | 期限、リリース目標日 | 遅延リスクを把握しやすい |
| Customer impact | High、Medium、Low | 障害・要望の優先順位付けに使える |
| Component | Frontend、Backend、Infra など | 担当領域別の整理に使える |
特に効果が出やすいのは、複数のリポジトリを持つプロダクトチームです。ラベルを各リポジトリに手作業でそろえるより、組織レベルのフィールドとして管理したほうが、後から検索・集計・自動化しやすくなります。
型付きフィールドとして入力できる
Issue fields では、Single-select、Text、Number、Date の4種類のフィールドタイプを作成できます。Organization あたり最大25個の Issue fields を作成でき、Single-select の選択肢は最大100個までです。(GitHub Docs)
| フィールドタイプ | 向いている用途 | 使いどころ |
|---|---|---|
| Single-select | 優先度、影響度、分類、担当領域 | 値を統一したい項目 |
| Text | 顧客名、外部チケット番号、補足情報 | 自由入力が必要な項目 |
| Number | 見積もりポイント、影響ユーザー数、金額 | 数値で比較・集計したい項目 |
| Date | 開始日、期限、リリース予定日 | 日付で並べ替えたい項目 |
注意したいのは、何でもフィールド化すればよいわけではない点です。フィールド数には上限があり、増やしすぎると Issue 作成時の入力負荷が上がります。最初は「検索・並べ替え・レポートで本当に使う項目」に絞るのが現実的です。
管理者が確認すべき設定ポイント
Issue fields は Organization 単位の機能であり、管理者の初期設計がその後の運用品質を左右します。特に、既定フィールドをそのまま使うか、組織の用語に合わせて変更するかは早めに決めておきましょう。
Settings > Planning > Issue fields を確認する
Issue fields の作成や編集は、Organization の設定画面から行います。公式ドキュメントでは、Organization の Settings から Planning セクションの Issue fields を開き、新しいフィールドの作成、編集、削除、表示設定を行う流れが案内されています。(GitHub Docs)
最初に確認すべき項目は次の4つです。
| 確認項目 | 判断基準 |
|---|---|
| 既定フィールドを使うか | Priority、Effort、Start date、Target date が自社の運用に合うか |
| 日本語名にするか | 非英語文字に対応したため、日本語運用のチームでは「優先度」「工数」なども選択肢になる |
| Issue type ごとに表示を分けるか | Bug、Task、Feature で必要な項目が異なるか |
| Public に見せる項目を決めるか | 公開リポジトリや Public projects で外部ユーザーに見せてよい情報か |
日本語圏の組織では、フィールド名を日本語にするか英語にするかで迷いやすいところです。社内利用が中心なら日本語名でも問題ありませんが、OSS や海外チームとの共同開発がある場合は Priority や Target date のような英語名を維持したほうが伝わりやすい場合があります。
Issue type ごとに必要なフィールドを出し分ける
Issue fields は、Issue type に応じて表示するフィールドを固定できます。たとえば、Bug には Severity、Feature には Impact、Task には Effort を表示する、といった設計が可能です。GitHub Docs でも、特定の issue type にフィールドをピン留めすることで、Issue 作成・閲覧時に関連性の高いフィールドを表示できると説明されています。(GitHub Docs)
実務では、次のような設計が使いやすいでしょう。
| Issue type | 推奨フィールド例 | 理由 |
|---|---|---|
| Bug | Priority、Severity、Target date | 影響度と対応期限を明確にするため |
| Feature | Impact、Effort、Target date | 価値と工数を見ながら優先順位を決めるため |
| Task | Effort、Start date、Target date | 作業計画と進捗確認に使うため |
| Support | Customer impact、Priority、External ticket | 顧客影響と外部問い合わせを結び付けるため |
フィールドが表示されない場合は、対象の Issue type にピン留めされているかを確認してください。ドキュメントでは、フィールドがどの type にもピン留めされておらず、値も設定されていない場合、Issue のサイドバーには表示されないとされています。(GitHub Docs)
開発者・一般ユーザーが確認すべき使い方
開発者や一般ユーザーにとっての大きな変化は、Issue の情報をより探しやすくなることです。Priority や Target date がラベルや本文に埋もれず、フィールドとして表示・検索できるため、日々のトリアージや作業選定が楽になります。
Issue の右サイドバーで値を設定する
Issue fields の値は、Issue の右サイドバーから設定できます。GitHub Docs では、triage 権限以上を持つユーザーが Issue field の値を設定・編集できると説明されています。(GitHub Docs)
基本的な使い方は次の流れです。
| 手順 | 操作 |
|---|---|
| 1 | 対象の Issue を開く |
| 2 | 右サイドバーで表示済みのフィールドを確認する |
| 3 | 必要なフィールドがなければ Add field から追加する |
| 4 | Single-select、Text、Number、Date の形式に合わせて値を入力する |
| 5 | 変更は自動保存される |
なお、公式ドキュメントでは、Issue fields は現時点で Issue のみが対象で、Pull request ではサポートされないと説明されています。PR のレビュー優先度やリリース対象を管理したい場合は、Projects のフィールドや既存のラベル運用との使い分けが必要です。(GitHub Docs)
検索クエリでフィールド値を絞り込む
Issue fields は検索にも使えます。たとえば、優先度が高い Issue や期限が近い Issue を探す場合、フィールド値を条件にできます。
| 探したい Issue | 検索例 |
|---|---|
| 優先度が High の Issue | field.priority:high |
| 優先度が High または Medium の Issue | field.priority:high,medium |
| 期限が 2026年3月1日以降の Issue | field."target date":>=2026-03-01 |
GitHub Docs では、field. に続けてフィールド名と値を指定することで、Issues dashboard やリポジトリの Issues ページで絞り込みできると案内されています。(GitHub Docs)
この検索機能は、日次のトリアージで特に役立ちます。たとえば、サポート担当者なら field.priority:urgent、リリース担当者なら field."target date":<=2026-07-31 のようなクエリを保存しておくと、確認漏れを減らせます。
Projects との関係：Project fields との違いを理解する
Issue fields を導入する際に混乱しやすいのが、GitHub Projects のカスタムフィールドとの違いです。
結論から言うと、Issue fields は Issue そのものに紐づく値、Project fields は特定の Project 内だけで使う値です。
| 比較項目 | Issue fields | Project fields |
|---|---|---|
| 定義場所 | Organization | Project |
| 値の所属先 | Issue 本体 | Project 内のアイテム |
| 複数 Project 間の一貫性 | 保ちやすい | Project ごとに値が変わる可能性がある |
| 向いている用途 | 優先度、工数、期限など組織共通の情報 | その Project だけのステータスやビュー管理 |
| 注意点 | 設計を誤ると全リポジトリに影響する | 複数 Project で同じ項目を作ると重複しやすい |
GitHub Docs でも、Issue fields は値が Issue に存在し、Issue が属するすべての Project で一貫する一方、Project fields は単一 Project にスコープされると説明されています。既存の Project field から移行する場合は、同じ概念を二重に持たないよう注意が必要です。(GitHub Docs)
たとえば、すでに Project 側に Priority フィールドがある状態で Issue fields にも Priority を作ると、ユーザーはどちらを更新すべきか迷います。移行期間は併存してもよいですが、最終的には「優先度は Issue fields を正とする」といったルールを明文化したほうが安全です。
Public projects と表示範囲で注意すべきこと
今回の更新では、Issue fields が Public projects でも使えるようになり、表示範囲の制御も重要になりました。GitHub の Changelog では、Public projects で Issue fields が動作し、組織が非メンバーに見えるフィールドを決められること、ログアウトユーザーも Public なフィールドを確認できることが説明されています。(The GitHub Blog)
公開リポジトリや OSS プロジェクトでは、次のような情報の扱いに注意してください。
| フィールド例 | Public に向くか | 理由 |
|---|---|---|
| Priority | 場合による | 公開ロードマップとして有用だが、社内判断を見せたくない場合もある |
| Target date | 慎重に判断 | 期待値管理に役立つ一方、日程変更時の説明責任が生じる |
| Customer name | 基本的に非公開 | 顧客名や契約情報が含まれる可能性がある |
| Security impact | 原則として慎重 | 脆弱性対応や悪用可能性に関わる場合がある |
| Effort | 公開しても問題ない場合が多い | 作業規模の透明性向上に使える |
公式ドキュメントでは、新規・既存のフィールドは既定で Organization only に設定され、Public にしたフィールドだけが誰でも閲覧可能になると説明されています。(GitHub Docs)
公開プロジェクトで使う場合は、最初に「外部ユーザーに見えてよいフィールド」と「内部向けの判断材料」を分けることが重要です。特に、顧客名、売上影響、脆弱性の詳細、社内の優先順位判断などは、安易に Public にしないほうが安全です。
MCP integration と Copilot 活用で変わること
今回の一般提供では、Issue fields が GitHub の MCP server から利用できるようになった点も注目です。GitHub の Changelog では、MCP integration により、Copilot などの AI ツールが Issue 作成・更新時にフィールド値を読み取り、設定できるようになると説明されています。(The GitHub Blog)
これは、Issue 管理の自動化に影響します。たとえば、次のような使い方が考えられます。
- バグ報告の本文から影響度を読み取り、
Severityを提案する - Issue の内容から
Componentを推定し、担当領域を設定する - リリース予定に合わせて
Target dateの候補を入力する - トリアージ時に
Priorityが未設定の Issue を洗い出す
ただし、AI にフィールド値を設定させる場合は、完全自動化よりも「提案後に人が確認する」運用から始めるのが安全です。Priority や Severity は顧客影響、契約、リリース計画に関わるため、誤判定がそのまま開発順序に影響する可能性があります。
既存運用から移行する際のおすすめ手順
Issue fields をいきなり全チームに展開すると、ラベル、Projects、Issue type、Issue templates の役割が混ざることがあります。まずは小さく設計して、値の意味をそろえることが大切です。
| ステップ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 既存のラベルと Project fields を棚卸しする | 似た項目をそのまま重複作成してしまう |
| 2 | 組織共通で使う項目を決める | チーム固有の項目まで入れすぎる |
| 3 | フィールド名と選択肢を決める | High と Urgent の違いが曖昧になる |
| 4 | Issue type ごとの表示項目を決める | すべての Issue に全フィールドを表示して入力負荷が上がる |
| 5 | Public / Organization only を設定する | 公開してはいけない項目を Public にしてしまう |
| 6 | Projects の重複フィールドを整理する | Issue fields と Project fields のどちらが正か分からなくなる |
| 7 | 検索クエリや運用ルールをチームに共有する | 機能は有効でも誰も入力しない状態になる |
最初に作るフィールドは、3〜6個程度に絞るのがおすすめです。たとえば、Priority、Effort、Target date、Component、Customer impact だけでも、多くのチームでは十分に効果を得られます。
ラベル運用は不要になるのか
Issue fields が一般提供されたからといって、ラベルが不要になるわけではありません。むしろ、ラベルと Issue fields の役割を分けることが重要です。
| 用途 | ラベルが向いている例 | Issue fields が向いている例 |
|---|---|---|
| 視覚的な分類 | bug、documentation、good first issue | 重要度、期限、工数 |
| 外部コントリビューター向けの案内 | help wanted、beginner friendly | 内部の優先順位 |
| 状態管理 | needs-info、blocked | 開始日、目標日、影響度 |
| 集計・検索 | 単純な分類 | 型付きで比較したい値 |
判断基準は、「値として比較・検索・集計したいか」です。たとえば、優先度は High、Medium、Low のように一つだけ選びたいため Issue fields 向きです。一方、good first issue のように外部協力者へ意味を伝えるものはラベルのままでも自然です。
導入時に注意したい制限
Issue fields には便利な点が多い一方、制限もあります。導入前に把握しておくべき主な制限は次のとおりです。
| 制限 | 内容 | 対応策 |
|---|---|---|
| Organization あたりの Issue fields | 最大25個 | 本当に共通管理したい項目だけに絞る |
| Single-select の選択肢 | 最大100個 | 細かすぎる分類は Text や別運用を検討する |
| Issue type ごとのピン留め | 最大10個 | 重要な項目だけを表示する |
| Project 内のフィールド総数 | Issue fields や system fields を含めて最大50個 | 既存 Project fields を整理してから追加する |
| 対象 | Issue のみ | Pull request 管理には別の仕組みを併用する |
| Issue template からの事前入力 | 現時点では不可 | サイドバー、Projects、API、GitHub Actions を使う |
GitHub Docs では、Issue fields は Issue のみが対象で、URL クエリパラメータや Issue templates から事前入力することは現在できないと説明されています。値を設定するには、Issue サイドバー、Projects、API、GitHub Actions などを使う必要があります。(GitHub Docs)
この点は、Issue template を使って「優先度」や「期限」を入力させていたチームにとって重要です。テンプレート本文に記入欄を残すのではなく、作成後のトリアージ手順として Issue fields を設定する運用に変える必要があります。
GitHub Actions や API での自動化も検討する
Issue fields は手入力だけでなく、API や GitHub Actions と組み合わせた自動化にも向いています。GitHub Docs では、Issue field の変更により issues イベントの field_added と field_removed をワークフローのトリガーとして利用できると説明されています。(GitHub Docs)
たとえば、次のような運用が考えられます。
PriorityがUrgentに設定されたら Slack や Teams に通知するTarget dateが近い Issue を定期的に一覧化するComponentに応じて担当チームを自動アサインするCustomer impactが High の Issue に専用ラベルを付ける
ただし、自動化を入れる前に、フィールド値の定義を固めることが先です。Priority: High の意味がチームごとに違う状態で通知や自動アサインを組むと、かえってノイズが増えます。
実務でのおすすめ設計例
中規模以上の開発チームなら、次のような最小構成から始めると運用しやすくなります。
| フィールド名 | 型 | 選択肢・入力例 | 目的 |
|---|---|---|---|
| Priority | Single-select | Urgent、High、Medium、Low | 作業順序を決める |
| Effort | Single-select | XS、S、M、L、XL | おおまかな工数を把握する |
| Target date | Date | 2026-07-31 | 期限やリリース目標を管理する |
| Component | Single-select | Frontend、Backend、Infra、Docs | 担当領域を分ける |
| Customer impact | Single-select | High、Medium、Low、None | 顧客影響を判断する |
この構成なら、ラベルを増やしすぎずに、トリアージ、検索、Projects での集計、自動化に必要な情報をそろえられます。
公開リポジトリでは、Customer impact や顧客名に関係する情報は Organization only にし、Priority や Target date を Public にするかどうかをプロジェクトの透明性方針に合わせて判断するとよいでしょう。
まず確認すべきチェックリスト
Issue fields の一般提供を受けて、GitHub 管理者や開発チームは次の順番で確認するとスムーズです。
| 対象者 | まず確認すること |
|---|---|
| Organization 管理者 | Settings > Planning > Issue fields で既定フィールドを確認する |
| 開発リーダー | Priority、Effort、Target date の定義をチームで合意する |
| Project 管理者 | 既存の Project fields と Issue fields が重複しないか確認する |
| OSS 管理者 | Public に見せるフィールドと非公開にするフィールドを分ける |
| 開発者 | Issue サイドバーで値を設定・編集する手順を把握する |
| 自動化担当 | API、GitHub Actions、MCP 連携で使う項目を整理する |
今回の「Issue fields are now generally available」は、GitHub Issues をより構造化された作業管理の中心に近づける更新です。まずは既定フィールドを確認し、ラベルや Projects で重複している情報を洗い出してください。そのうえで、組織共通で使うフィールドだけを少数に絞り、Issue type、公開範囲、Projects との関係を決めることが、失敗しない導入の近道です。
コメント