GitHub Issueとは？使い方・書き方と運用のベストプラクティス【2026年版】

GitHub Issueは、GitHubのリポジトリに付属する課題管理機能です。バグ報告・機能要望・作業タスクを「#123」のような番号付きのチケットとして起票し、議論から修正のPull Requestまでを1か所でつなぎます。なお、Git本体にIssueの機能はありません。「git issue」で調べている場合も、GitHubやGitLabといったホスティングサービス側の機能を指しています。

この記事では、Issueの作り方と伝わる書き方、テンプレートの置き方に加え、2025〜2026年に増えたIssue types・sub-issues・Issue fieldsの使い分け、Issueからブランチを作ってPull Requestで閉じるまでの流れ、GitHub Actionsでの自動処理までを扱います。仕様は2026年10月時点のGitHub Docsと、GitHub CLI 2.103.0（2026年10月21日リリース）を基準にしています。

まとめ：GitHub Issueの要点

• Issueはリポジトリ単位の番号付きチケット。作業やバグはIssue、コード変更はPull Request、結論を決めない相談はDiscussionsに置く。
• タイトルは「事象＋場所＋条件」、本文は「再現手順・期待する結果・実際の結果・環境」。公開リポジトリで必須入力を設定するならYAMLのIssueフォームを使う。
• 横断タグはラベル（新規リポジトリに既定10個）、種類はIssue types（既定はTask・Bug・Feature）、優先度や期限はIssue fields（2026年7月2日GA）。Issue typesとIssue fieldsはOrganizationのリポジトリだけで使える。
• 大きな作業はsub-issues（親1件に最大100件・8階層）と、blocked by／blockingの依存関係で分解する。順序の無い関連は「Relates to」でつなぐ。
• 作業はIssueのDevelopment欄か gh issue develop でブランチを作って始め、コミットメッセージに #123 を書いて経緯を残す。
• PR本文の Closes #10 でIssueが閉じるのは、デフォルトブランチへのマージ時だけ。develop がデフォルトブランチでなければ、そこを対象にしたPR本文のキーワードは無視される。
• 運用で効くのは「1 Issue＝独立して完了できる作業単位」と、クローズ理由（completed・not planned・duplicate）の使い分け。仕分けと放置Issueの整理はGitHub Actionsに任せられる。

GitHub Issueの役割とPull Request・Discussionsとの違い

Issue（イシュー）は英語で「課題・問題」という意味です。1件のIssueには、タイトル、本文、コメントのスレッド、担当者、ラベル、マイルストーン、紐づくProjectsやPull Requestがまとまります。「誰が・何を・どこまで終えたか」の記録がリポジトリのそばに残るため、コミットやPRから経緯をたどれる点がスプレッドシートや外部のタスク管理ツールとの違いです。

迷いやすいのが、Pull RequestとDiscussionsとの使い分けです。GitHub Docsの計画と追跡のガイドは、Issueをバグや性能の報告・四半期計画・新しい施策の設計といった具体的な議論に使い、Discussionsを「コードベースの外やリポジトリをまたいだ、結論を決めないブレインストーミングやフィードバック」に使うよう案内しています。

判断の目安は「完了条件を書けるか」です。書けるならIssue、書けないうちはDiscussionsで話し、結論が出たところでIssueに起こします。Discussionのサイドバーにある「Create issue from discussion」を使うと、本文とラベルを引き継いだIssueを作れます（triage以上の権限が必要）。

Issueの作り方：Web画面とGitHub CLI

Web画面からは次の順で作成します。

1. リポジトリの Issues タブを開き、New issue をクリックする。
2. テンプレートが用意されていれば種類を選ぶ。無ければそのまま入力画面に進む。
3. タイトルと本文を書く。入力中に似た既存Issueが候補として表示されることがあるので、重複していないか確認する。
4. 権限に応じて設定できる担当者（Assignees）、ラベル、Type、Projects、マイルストーンを指定し、Submit new issue で登録する。

Issuesタブが見当たらない場合は、リポジトリの Settings にある「Features」でIssuesが無効になっています。同じ場所で、起票できる人を「Collaborators only」に絞る設定もできます。

コードの特定行について起票したいときは、ファイル表示で行番号を選び「Reference in new issue」を使うと、該当コードの抜粋付きでIssueが作られます。

ターミナルからは GitHub CLI の gh issue create を使います。2026年6月10日リリースの v2.94.0 で --type（Issue type）、--parent（sub-issueとして追加）、--blocked-by／--blocking（依存関係）が加わりました。以下は gh auth login で認証を済ませ、対象リポジトリのローカルディレクトリで実行する例です。最初の例では、本文を事前に bug.md へ保存しておきます。

# バグ報告を起票し、自分を担当者にする
gh issue create --title "Safari 18でログインフォームの送信ボタンが反応しない" \
  --body-file bug.md --label bug --type Bug --assignee "@me"

# 再現時のスクリーンショットを添付して起票する（v2.99.0以降）
gh issue create --title "決済完了画面で金額が0円と表示される" \
  --body-file bug.md --attach ./repro.png

# 親Issue #120 のsub-issueとして作る
gh issue create --title "パスワード再設定メールの文面を差し替える" --parent 120

# #200 と #201 が片付くまで着手できないタスクとして作る
gh issue create --title "決済APIをv2へ切り替える" --blocked-by 200,201

--attach は2026年9月1日の v2.99.0 で加わったオプションで、手元の画像や動画をアップロードして本文に差し込みます。--project でProjectsに追加するには、CLIの認証に project スコープが必要です（gh auth refresh -s project）。--type は後述のIssue typesを使っているOrganizationのリポジトリでだけ意味を持ちます。

伝わるIssueの書き方：タイトルと本文の型

Issueタイトル：事象・場所・条件の明示

「バグ」「ログインできない」のようなタイトルは、一覧で他のIssueと区別しにくく、検索結果から目的のIssueを絞り込みにくくなります。何が起きたか、どの画面や機能で、どんな条件のときかを1行に収めます。

• 悪い例：「ログインできない」
• 良い例：「Safari 18でログインフォームの送信ボタンが反応しない」
• タスクの例：「CSVエクスポートに注文日の列を追加する」

タスクのタイトルは「〜を検討」「〜の改善」ではなく、終わった状態が分かる動詞で書きます。「改善」だけでは閉じる基準が分からないためです。

本文：再現手順・期待する結果・実際の結果・環境

バグ報告は、読んだ人がそのまま再現できるかで価値が決まります。本文はMarkdownで書けるので、見出しとチェックリストで型を固定すると抜けが減ります。

## 再現手順
1. https://example.com/login を Safari 18.6 で開く
2. メールアドレスとパスワードを入力する
3. 「ログイン」ボタンを押す

## 期待する結果
ダッシュボードに遷移する

## 実際の結果
ボタンが無反応。コンソールに次のエラーが出る
```
TypeError: undefined is not an object (evaluating 'form.requestSubmit')
```

## 環境
- macOS 15.6 / Safari 18.6
- 本番環境、2026-09-25 のデプロイ以降

## 関連
- #98（フォームのバリデーション変更）
- [ ] 再現を確認した

GitHubのMarkdownでは、#98 と書くと同じリポジトリのIssueやPRへ自動でリンクされます。@ユーザー名 で相手に通知が飛び、- [ ] はクリックで切り替えられるチェックボックスになります。スクリーンショットは本文へのドラッグ＆ドロップで添付できます。

機能要望とタスク：背景と完了条件の記載

要望やタスクでは、実装方法より先に「なぜ必要か」と「何ができたら閉じるか」を書きます。たとえばGitHub Issueで「CSVエクスポートに注文日の列を追加する」と依頼するなら、背景は「経理担当者が注文日別に集計するため」、完了条件は「出力したCSVに注文日がYYYY-MM-DD形式で含まれる」と具体化します。完了条件が箇条書きで並んでいれば、レビューする人もPRと突き合わせて確認できます。実装方法まで起票時に決め打ちすると、議論の余地を狭めます。

Issueテンプレート：Markdown形式とIssueフォーム（YAML）の書き方

毎回同じ項目を書いてもらうなら、テンプレートを置きます。テンプレートにはMarkdown形式（拡張子 .md）とIssueフォーム（拡張子 .yml）の2種類があり、どちらもリポジトリの .github/ISSUE_TEMPLATE に置きます。GitHub Docsのテンプレートの説明のとおり、読み込まれるのはデフォルトブランチにあるファイルだけで、作業ブランチに置いたままでは作成画面に出ません。

Markdown形式：前付けのname・aboutと本文の下書き

Markdown形式は、先頭の前付け（YAML frontmatter）に name と about を書き、その下に本文の下書きを置きます。title・labels・assignees・type を足すと、起票時にタイトルの接頭辞やラベルが入ります。機能要望のように、書き手が見出しを自由に足し引きしてよい種類に向いています。

---
name: 機能要望
about: 新しい機能や改善の提案
title: "[要望] "
labels: ["enhancement"]
---

## 背景（誰が何に困っているか）

## 完了条件
- [ ]

## 対象外にすること

ただし、下書きは記入者が消せば項目ごと無くなります。公開リポジトリでバグ報告の必須入力を設定するには、次のIssueフォームを使います。

Issueフォーム：必須入力と入力欄の種類

Issueフォームは入力欄として描画されます。公開リポジトリでは、required: true の項目を空のまま送信できません。フォームスキーマの仕様が「Only for public repositories」としているため、非公開リポジトリではこの必須指定は効きません。2026年10月時点のGitHub Docsでは、Issueフォームは「public preview」と表記されています。

Issueフォームの必須キーは name・description・body の3つです。任意で labels・assignees・type・projects を指定すると、起票時に自動で付きます。入力欄の種類は markdown（説明文）、textarea、input、dropdown、checkboxes、upload です。

# .github/ISSUE_TEMPLATE/bug_report.yml
name: バグ報告
description: 期待どおりに動かない箇所を報告する
type: Bug
labels: ["triage"]
body:
  - type: textarea
    id: steps
    attributes:
      label: 再現手順
      placeholder: "1. ... 2. ... 3. ..."
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 期待する結果と実際の結果
    validations:
      required: true
  - type: dropdown
    id: env
    attributes:
      label: 発生環境
      options:
        - 本番
        - ステージング
        - ローカル
    validations:
      required: true

注意点が2つあります。labels に書いたラベルがリポジトリに存在しないと、そのラベルは付きません。projects は起票者がそのProjectへの書き込み権限を持っている必要があり、外部からの起票を集めるならProjects側の自動追加ワークフローを使います。

config.yml：白紙Issueの抑止と質問窓口の分離

同じフォルダに config.yml を置くと、テンプレートを使わない白紙のIssueを抑止し、質問や脆弱性報告を別の窓口へ誘導できます。以下のOWNERとREPOは実際の所有者名とリポジトリ名に置き換え、Discussionsを有効にしてください。脆弱性報告のリンクは、公開リポジトリでPrivate vulnerability reportingを有効にした場合に使用し、それ以外では実際に受け付けている非公開窓口のURLに置き換えます。

# .github/ISSUE_TEMPLATE/config.yml
blank_issues_enabled: false
contact_links:
  - name: 使い方の質問
    url: https://github.com/OWNER/REPO/discussions
    about: 質問はDiscussionsへお願いします
  - name: 脆弱性の報告
    url: https://github.com/OWNER/REPO/security/advisories/new
    about: 公開のIssueには書かないでください

blank_issues_enabled: false でも、Write・Maintain・Admin権限を持つ人には「Maintainers only」付きの白紙Issueの選択肢が残ります。白紙を選べなくなるのはRead・Triage権限の人です。

ラベル・Issue types・Issue fieldsの使い分け

Issueを分類する仕組みは4つあります。2025年以降にIssue typesとIssue fieldsが加わり、ラベル1つで種類も優先度も状態も表す運用は不要になりました。

ラベル：既定の10個と設計の失敗パターン

新しいリポジトリには accessibility・bug・documentation・duplicate・enhancement・good first issue・help wanted・invalid・question・wontfix の10個が最初から入っています。good first issue を付けたIssueは、リポジトリの contribute ページに一覧表示されます。Organizationのオーナーは、配下の新規リポジトリに入る既定ラベルを差し替えられます。

よくある失敗は、bug と type: bug、priority: high と P1 のように同じ意味のラベルが増えることです。Organizationで運用しているなら、種類はIssue types、優先度はIssue fieldsへ移し、ラベルは「frontend」「api」のような担当領域と、「needs-triage」のような状態に絞ると重複しません。

整理で使わなくなったラベルは、削除せずにアーカイブします。2026年8月27日に一般提供になった機能で、既存のIssueに付いた履歴を残したまま、ラベルの選択肢から外せます。Labelsページからいつでも戻せます。

Issue types：Organization共通の種類と追加設定

Issue typesは、1件のIssueに1つだけ付ける「種類」です。すべてのOrganizationにTask・Bug・Featureが既定で入っており、名前・説明・色を変えたり、無効化・削除したりできます。1つのOrganizationで最大25個まで作れます。

追加するには、OrganizationのオーナーがOrganizationの Settings を開き、サイドバーの「Code, planning, and automation」にある Planning から Issue types を選び、Create new type をクリックします。リポジトリ単位の設定ではないため、個人アカウントのリポジトリの設定画面には出てきません。種類で絞り込むときは type:"Bug" と検索します。

Issue fields：優先度・期限の型と既定項目

Issue fieldsは2026年7月2日に、Free・Team・Enterpriseの全Organization向けに一般提供（GA）になりました。有効にすると、次の4項目が自動で作られます。

• Priority（単一選択）：Urgent・High・Medium・Low
• Effort（単一選択）：High・Medium・Low
• Start date（日付）
• Target date（日付）

項目の種類は単一選択・複数選択・テキスト・数値・日付の5つで、Organizationあたり最大25個まで作成できます。値は field.priority:high や field."target date":>=2026-03-01 で検索でき、GitHub MCPサーバー経由でAIツールから読み書きすることもできます。

Issue typesもIssue fieldsもOrganizationの機能です。個人リポジトリで優先度や期限を持たせるなら、priority: high のようなラベルに加え、期限をマイルストーンの期日で表すか、ProjectsのDateフィールドを使います。

sub-issuesと依存関係：作業の分解と着手順序

1件で終わらない作業は、親Issueの下にsub-issueをぶら下げます。親Issueの本文の下にある Create sub-issue から新規に作るか、既存のIssueを「Add existing issue」で子にします。上限は親1件あたり100件、入れ子は8階層までです。sub-issueの進み具合はProjectsのビューにも表示されます。

順序の制約は、依存関係（Issue dependencies）で表します。「blocked by（〜が終わるまで着手できない）」と「blocking（〜の着手を止めている）」の2種類があり、それぞれ1件のIssueに最大50件までリンクできます。順序はないが関連は残したい2件には「Relates to」を使います。2026年9月25日に一般提供になった関係で、ブロック・重複・親子・クローズのいずれも意味しません。

分解の目安は「sub-issue 1件をPull Request 1本で閉じられるか」です。親Issueは目的と完了条件だけを持ち、実作業は子に書きます。親に作業内容を書き込むと、子との二重管理になります。

Issueから作業を始める：ブランチ作成とコミットでの参照

Development欄：Issueに紐づくブランチの作成

Issueを開き、右サイドバーの Development にある Create a branch を押すと、そのIssueにつながったブランチを作れます。ダイアログではブランチ名と作成先のリポジトリを指定できます。GitHub Docsの手順によると、作成できるのはリポジトリへの書き込み権限を持つ人で、既定では今のリポジトリのデフォルトブランチから分岐します。1件のIssueに複数のブランチをつなげることもできます。2026年10月時点でこの機能は「public preview」の表記です。

このブランチからPull Requestを作ると、PRは自動でIssueにリンクされ、Development欄の表示はブランチからPRに置き換わります。

ターミナルで同じことをするのが gh issue develop です。--base で develop などの分岐元を明示でき、v2.99.0（2026年9月1日）からは、今の作業ツリーを変えずに別のworktreeへ取り出せるようになりました。ブランチの切り方そのものはブランチの仕組みと使い方を参照してください。

# Issue #123 用のブランチを作ってチェックアウトする
gh issue develop 123 --checkout

# develop から分岐させる
gh issue develop 123 --base develop --checkout

# 現在の作業ツリーはそのままに、別ディレクトリのworktreeで作業する
gh issue develop 123 --checkout --worktree ../wt-issue-123

コミットメッセージ：Issue番号による経緯の記録

コミットメッセージに #123 と書いてpushすると、Issue #123のタイムラインにそのコミットが表示されます。REST APIのイベント種別では referenced（コミットメッセージから参照された）として記録されます。閉じるキーワードを付けなければIssueは開いたままなので、1件のIssueに何回も途中経過のコミットをつなげられます。

git commit -m "ログインフォームの送信処理を requestSubmit から submit に戻す #123"

別リポジトリのIssueは octo-org/octo-repo#100、URLや GH-123 の形でも参照できます。コミットの粒度とメッセージの決め方はコミットの仕組みと粒度・メッセージ設計で解説しています。

Pull RequestでIssueを閉じる：closing keywordsと閉じない原因

PRの説明文かコミットメッセージにキーワードとIssue番号を書くと、マージ時にIssueが自動でクローズされます（GitHub Docs：プルリクエストを問題にリンクする）。使えるキーワードは close・closes・closed・fix・fixes・fixed・resolve・resolves・resolved の9語で、Closes: #10 のようなコロン付きや、CLOSES #10 のような大文字でも解釈されます。

マージしたのにIssueが閉じないときは、次の順に確認します。

• PRの向き先がデフォルトブランチ以外：キーワードが解釈されるのは、デフォルトブランチ（多くは main）を対象にしたPRだけです。develop がデフォルトブランチでない場合、そのブランチを対象にしたPR本文のキーワードではリンクが作られず、マージによる自動クローズも起こりません。git-flowのように統合ブランチを挟む運用では、main へのリリースPRにキーワードを書き直すか、手動で閉じます。
• 2件目以降にキーワードを付けていない：Closes #10, #11 では #11 は閉じません。1件ごとにキーワードが要ります。
• キーワードをPRのコメントに書いた：解釈されるのはPRの説明文とコミットメッセージです。

コミットメッセージにキーワードを書いた場合もデフォルトブランチへのマージでIssueは閉じますが、そのPRは「リンクされたPR」としてIssueに表示されません。キーワードを使わずにつなぐなら、PRかIssueのサイドバーの Development から手動でリンクします（PR 1本につき最大10件）。PRの作り方とマージ方式の選び方はGitHubのPull Requestの作り方にまとめています。

Issueの検索とフィルタ：よく使う修飾子

Issue一覧の検索欄には修飾子を組み合わせて入力します。

2025年4月からは AND・OR と括弧を使った検索ができ、括弧は5階層まで入れ子にできます。たとえば (type:"Bug" AND assignee:octocat) OR (type:"Feature" AND assignee:hubot) は、octocat担当のバグとhubot担当の機能要望をまとめて表示します。

同じ条件はCLIでも使えます。gh issue list は、指定しなければ未完了のIssueを30件まで表示します。

# 担当者未定の bug または help wanted を古い順に並べる
gh issue list --search 'no:assignee label:"help wanted",bug sort:created-asc'

# Issue typeで絞ってJSONで取り出す
gh issue list --type Bug --json number,title,labels --limit 100

GitHub Projectsとマイルストーン：進捗の見える化

複数のIssueをまとめて進めるなら、Projectsに載せます。1つのProjectに複数のビューを作り、それぞれTable（表）、Board（カンバン）、Roadmap（タイムライン）のいずれかで表示できます。Projectに追加できるフィールドはText・Number・Date・Single select・Multi select・Iterationの6種類で、Single selectの「Status」列をBoardの列にするのが基本の形です。ボードの列の切り方やWIP制限の考え方はカンバン方式のタスク管理で詳しく扱っています。

Issue fieldsの値はProjectsのビューでも絞り込みや並べ替えに使えます。ただし、公開・内部公開のProjectで表示できるのは、可視性をPublicに設定したIssue fieldsだけです。Organizationで運用するなら、優先度をProject独自のフィールドで作り直すより、Issue fieldsのPriorityを使うほうがリポジトリをまたいで値が揃います。

リポジトリ1つで「v2.3までに終わらせるもの」を束ねるだけなら、Projectsより軽いマイルストーンで足ります。Issues一覧の検索欄の横にある Milestones から New Milestone を押し、タイトル・期日・説明を入れて作ります。マイルストーンのページには完了率と、紐づくIssue・PRのopen／closedの件数が出ます。ドラッグで並べ替えて優先順位を付けられますが、openのIssueが500件を超えるとこの並べ替えはできません。マイルストーンを削除しても、紐づいていたIssueとPRはそのまま残ります。

GitHub ActionsでIssueを自動処理する：起票時のラベル付けと放置Issueのクローズ

GitHub Actionsのワークフローは issues イベントで起動でき、ワークフローを起動するイベントの一覧では、opened・edited・closed・labeled などに加え、Issue typeの付け外し（typed・untyped）とIssue fieldの値の追加・削除（field_added・field_removed）も起動条件に挙がっています。実行されるのはデフォルトブランチにあるワークフローファイルです。トリガーの書き方全般はGitHub Actionsのトリガー（on）の設計で扱っています。

起票されたIssueに仕分け待ちのラベルを付ける例です。GitHub公式チュートリアルと同じく、ランナーに入っているGitHub CLIで操作します。付けるラベルはリポジトリに先に作っておきます。

# .github/workflows/issue-triage.yml
name: Issue triage
on:
  issues:
    types: [opened, reopened]
jobs:
  label:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - run: gh issue edit "$NUMBER" --add-label "needs-triage"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GH_REPO: ${{ github.repository }}
          NUMBER: ${{ github.event.issue.number }}

しばらく動きの無いIssueには actions/stale を使います。2026年7月28日の v11.0.0 では、既定で60日更新が無いと Stale ラベルを付け、さらに7日動きが無ければ理由 not_planned で閉じます。1回の実行で行うAPI操作は既定30件までなので、溜まったIssueは数回の実行に分けて処理されます。

# .github/workflows/stale.yml（毎日 1:30 UTC＝日本時間 10:30 に実行）
name: Close inactive issues
on:
  schedule:
    - cron: "30 1 * * *"
jobs:
  stale:
    runs-on: ubuntu-latest
    permissions:
      actions: write
      issues: write
      pull-requests: write
    steps:
      - uses: actions/stale@v11
        with:
          days-before-issue-stale: 60
          days-before-issue-close: 14
          stale-issue-message: "60日間更新がないため stale を付けました。14日以内に動きがなければクローズします。"
          exempt-issue-labels: "pinned,security"
          days-before-pr-stale: -1
          days-before-pr-close: -1

days-before-pr-stale: -1 と days-before-pr-close: -1 で、Pull Requestを対象から外しています。権限はactions/staleのREADMEの推奨に合わせました。READMEはブランチ削除を使う場合だけ contents: write も挙げています。

自動クローズが向くのは、再現情報や回答を待っているIssueです。再現を確認済みのバグや、優先度を決めて寝かせている要望にまで当てると、直っていないのに閉じた扱いになります。そうしたIssueには除外ラベルを付けるか、only-issue-types で対象のIssue typeを絞ります。

CIの設計とあわせて、Issueの仕分けからリリースまでの流れを整える場合は、DevOps・CI/CD導入支援でもご相談を受け付けています。

Issue運用のベストプラクティスと失敗パターン

Issueの粒度：独立して完了できる作業単位

「管理画面を改善する」のように閉じる基準が無いIssueは、誰も完了を判断できず、開いたまま残りがちです。目的や担当が異なり、独立して完了を判定できる作業はsub-issueに分けます。同じ変更に対する複数の受け入れ条件は、1件のIssue内にまとめます。起票したらすぐ担当者と種類を決め、担当者が決まらないものは no:assignee で週1回まとめて振り分ける、といった仕分けの時間を決めておくと未整理のIssueが溜まりません。

Issueの終了処理：クローズ理由（completed・not planned・duplicate）と削除

Issueは「Close issue」の横の▼から理由を選んで閉じます。理由は次の3つで、GraphQL APIの定義でも同じ3値です。

「Close as not planned」は、修正や実装をしないまま閉じたことを示す理由です。理由を選んでおけば、後から reason:"not planned" で見送った要望だけを振り返れます。「Close as duplicate」を選ぶと重複先のIssueを検索して指定でき、どちらに議論を集めたかが残ります。

閉じたIssueは再オープンできます。Organizationのリポジトリの標準ロールでは、Read権限の人は自分で閉じたIssueだけ、Triage以上の人はすべてのIssueを再オープンできます。

完全な削除はリポジトリのadmin権限を持つ人しかできず、Organizationのリポジトリではオーナーが削除を許可している必要があります。削除してもコラボレーターには通知されず、URLを開くとページが見つからない表示になります。経緯が消えるので、スパムや誤って書いた機密情報でない限り、削除ではなくクローズを選びます。

Issueの整理：移管とピン留め

• 別のリポジトリで扱うべき未完了のIssueは移管できます。ただし、非公開リポジトリから公開リポジトリへの移管はできません。移管元と移管先の両方に書き込み権限が必要で、同じユーザーか同じOrganizationが所有するリポジトリ間に限られます。
• 既知の障害や貢献ガイドのように全員に見てほしいIssueは、一覧の上部に最大3件までピン留めできます。

AIエージェント向けIssue：作業指示と変更範囲の明示

GitHub CLIでは gh issue create --assignee "@copilot" のように、有料のCopilotプランでIssueをCopilotに割り当てる指定ができます（GitHub Enterprise Serverは非対応）。この使い方では、Issueの本文がそのまま作業指示になります。再現手順・完了条件・触ってはいけない範囲が書かれていないIssueでは、AIエージェントが不足情報を補って実装し、意図と違うPRを作るおそれがあります。人に渡すときと同じ型で書くことが、AIに任せる場合でも品質を左右します。

逆に、エージェントにIssueの仕分けを任せる場合は、2026年7月23日にpublic previewで始まった承認の仕組みが使えます。対象はGitHub Agentic WorkflowsとCopilot cloud agentの自動化（REST・GraphQL APIからも利用可）で、ラベル・Issue field・Issue type・担当者・クローズの変更に理由と確信度（high・medium・low）が付きます。公式発表ではhighを自動適用、mediumとlowを提案として保留する動作が説明されています。自動適用する確信度のしきい値は、リポジトリ管理者が変更できます。保留中のIssueは has:suggestions で探せます。ただしGitHubは、この承認はセキュリティ上の制御ではないと明記しています。変更権限を持つエージェントは承認を通さず直接書き換えられるので、権限そのものを絞ります。

Issueを起点に開発を回す考え方はチケット駆動開発（TiDD）、GitHubのIssueやPRをAIから操作する仕組みはGitHub MCPサーバーで解説しています。

JiraなどほかのツールでIssue管理をしている場合は、JiraとGitHubの連携でコミットやPRをJira側の課題に結び付けられます。ブランチ戦略やコミット規約までチームで揃えるなら、Git運用のベストプラクティスもあわせて確認してください。

よくある質問

GitHubのIssueの読み方と意味は？

「イシュー」と読みます。英語で「課題・問題」という意味で、GitHubではリポジトリごとにバグ報告・機能要望・作業タスクを番号付きで管理するチケットを指します。

GitにIssueの機能はありますか？

ありません。Git本体はバージョン管理のツールで、IssueはGitHubやGitLabなどのホスティングサービスが提供する機能です。GitHubとGitLabでのIssueやCI/CDの違いはGitHubとGitLabの違いで比較しています。

「Close as not planned」とはどういう意味ですか？

「対応予定なし」として閉じたことを示すクローズ理由です。修正や実装をしないまま閉じる場合、たとえば要望を見送るとき、再現しないとき、仕様どおりの動作だったときに選びます。完了したIssueは「Close as completed」、同じ内容の別Issueがあるなら「Close as duplicate」を選びます。

Issue typeを追加するにはどうすればよいですか？

Organizationの Settings から「Planning」の「Issue types」を開き、Create new typeで追加します。Organizationあたり最大25個まで作れます。Issue typesはOrganizationの機能なので、個人アカウントのリポジトリでは種類をラベルで表します。

GitHub Issueで優先度や期限を管理するには？

Organizationなら、Issue fieldsの既定項目PriorityとTarget dateを使います。個人リポジトリでは、優先度をラベル、期限をマイルストーンの期日かProjectsのDateフィールドで表します。

関連記事

• チケット駆動開発（TiDD）とは？No Ticket, No Commitのルールとツール設定
• Git運用のベストプラクティス｜ブランチ戦略・コミット規約・レビュー基準の決め方
• JiraとGitHubを連携する方法｜GitHub for Jiraで課題キー・スマートコミット設定
• カンバン方式のタスク管理とは？ボードの作り方とWIP制限・リードタイムの測り方
• コミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説