GitHub、Issueの種類とカスタムフィールドを個人アカウントでも一般提供

何が発表されたか

• GitHubが2026年11月11日、**Issue typesとIssue fieldsを個人アカウント所有のリポジトリで一般提供（GA）**した。これまでOrganization所有のリポジトリだけで使えた計画機能が、個人開発者やOSSメンテナーでも使えるようになった。
• Issue typesはIssueの分類。既定はBug、Task、Feature。
• Issue fieldsはIssueに構造化情報を足すもの。既定はPriority、Effort、Start date、Target date。フィールド型はテキスト、数値、日付、単一選択、複数選択。
• 個人アカウント設定の「Planning」セクション配下のIssue typesページ／Issue fieldsページからカスタマイズする。
• フィールドを特定のIssue typeにピン留めすることも、タイプなしのIssueで使えるようにすることもできる。
• 上限はIssue typesが25個、Issue fieldsが25個。
• Projects側でカスタムビューの作成や一括更新に使える。REST／GraphQL APIとWebhookからタイプとフィールドをプログラム的に管理できる。
• 同じ更新で、Issue画面から直接ラベルとマイルストーンを作れるようになった。検索して一致するものがなければ作成を促される。

実務への影響

• 個人アカウントでクライアント案件のリポジトリを管理しているフリーランスにとっては、Organizationを作らずに案件管理の粒度を上げられるのが実利だ。「Bug／Task／Feature」に加えて「保守依頼」「調査」などの独自タイプを足せば、Issue一覧の時点で性質が分かる。
• Priority／Target dateが構造化フィールドになるため、Projectsのビューで「今週対応」「期限切れ」を機械的に絞れる。ラベル運用でやっていた擬似的な優先度管理を置き換えられる。
• APIとWebhookに対応しているので、Issue作成時にタイプを自動付与したり、期限が近いIssueをSlackへ流すといった自動化が組める。複数クライアントのリポジトリを横断して棚卸しするスクリプトも書きやすくなる。
• 既存のラベル運用から移行する場合、25個の上限を踏まえてタイプとフィールドの設計を先に決めておくのが無難。