GitHub issueの使い方｜タスク管理に使う3つのコツ
GitHub issueの使い方がわからず、「バグ報告用の機能でしょ？」と思って放置していませんか？
私もClaude Codeで小さなツールを作り始めたころ、やりたいことをメモ帳やチャットにばらばらに書いていました。
気づけば「あれ、何をやる予定だったっけ？」の連続です。
この記事では、GitHub issueをタスク管理に使うための基本と、Claude Codeにissueを作らせるときのプロンプトを紹介します。
※GitHubの機能・画面は2026年10月19日時点の公式ドキュメント・公式ブログで確認した内容です。プランや設定によって表示が異なる場合があります。
結論：GitHub issueは「1タスク＝1issue」で使えばタスク管理ツールになる
一言で言えば、issueは「やることカード」として使えばいいです。
バグ報告だけでなく、次のようなものもissueにできます。
- 追加したい機能のアイデア
- 調べものや確認作業
- 記事やドキュメントの修正予定
ポイントは、1つのissueに1つのタスクだけを書くことです。
こうすると「終わったら閉じる」が明確になり、進み具合が見えやすくなります。
GitHub issueでタスク管理するメリット
ToDoアプリではなくissueを使う理由は、コードと同じ場所にタスクが置けるからです。
たとえば同じリポジトリのコミットメッセージやPull Requestに `#12` のようにissue番号を書くと、そのissueへのリンクになります。
「このタスクのためにどのファイルを変えたか」が後から追えるのは、ToDoアプリにはない強みです。
さらにClaude Codeを使っている場合、issueの内容をそのまま作業指示として渡せます。
タスクの説明を毎回チャットに書き直す手間が減ります。
GitHub issueの使い方：タスク管理に使う3つのコツ
ここからは、公式ドキュメントの機能をもとに「まずこれだけ押さえれば回る」と考えている3つのコツです。
※チーム運用ではなく、個人〜少人数での使い方を想定しています。
コツ1：ラベルで「種類」と「優先度」を分ける
ラベルは、issueに付けられる色付きのタグです。
私は次のように分けるのがわかりやすいと考えています。
- 種類：`feature`（機能追加）、`bug`（不具合）、`research`（調べもの）
- 優先度：`priority-high`、`priority-low`
ラベル名に日本語も使えますが、コマンドで扱うことを考えると英字のほうが無難です。
コツ2：マイルストーンで「いつまでに」をまとめる
マイルストーンは、複数のissueを「ひとまとまりのゴール」として束ねる機能です。
「10月中に公開したいもの」のように期限ごとにまとめると、完了率が自動で表示されます。
締め切りがゆるい個人開発ほど、この「何割終わったか」が見えるだけでやる気が変わります。
コツ3：大きいタスクはサブissueに分ける
GitHubでは2025年4月に、サブissue（sub-issues）とissueタイプが正式提供（GA）されました。
親issueの下に子issueをぶら下げられるので、「ログイン機能を作る」のような大きいタスクを小さく分けられます。
大きすぎるissueは、いつまでも閉じられずに放置されがちです。
「半日で終わるサイズ」を目安に分けるのがおすすめです。
Claude Codeにissueを作らせる方法
Claude Codeには、GitHub公式のコマンドラインツール GitHub CLI（`gh`コマンド） を使ってissueを作らせることができます。
事前に次の準備が必要です（環境によって手順が異なります）。
1. GitHub CLIをインストールする（macOSならHomebrewで `brew install gh` など。公式サイトにOS別の手順があります）
2. ターミナルで `gh auth login` を実行してGitHubにログインする
3. ターミナルで対象リポジトリのフォルダに移動してから（例：`cd path/to/your-repo`）、`claude` でClaude Codeを起動する
インストールでエラーが出ても、`sudo` を付けて無理に実行するのは避けてください。
権限まわりのトラブルの原因になりやすいので、エラー文をそのままClaude Codeに見せて相談するほうが安全です。
準備ができたら、issueはこんなコマンドで作れます。
gh issue create --title "Add export button" --body "Export the list as CSV" --label "feature" --assignee "@me"
ただし、存在しないラベル名を指定するとエラーになる点に注意してください。
先に `gh label list` で既存のラベルを確認しておくと安心です。
そのまま貼れるプロンプト
おすすめは、いきなり作らせるのではなく「下書き→確認→作成」の流れにすることです。
issueはリポジトリの閲覧権限がある人なら見られるので、公開リポジトリでは特に中身の確認が大切です。
このリポジトリのGitHub issueをタスク管理用に作成したいです。
目的：やりたいことのメモをissueに整理する
対象：以下のメモ（1行＝1タスク候補）
- CSV出力ボタンを付けたい
- READMEにインストール手順を追記
- ログイン機能（大きいので分けたい）
お願いしたいこと：
1. まず `gh label list` で既存ラベルを確認してください
2. 各タスクについて、タイトル・本文・付けるラベル案を一覧で表示してください
3. 大きいタスクはサブissueに分ける案を出してください
4. 新しいラベルが必要な場合は、作成案として提示するだけにしてください
issueの作成・ラベルの作成など、GitHub上に反映する操作を実行する前に、作成内容の一覧と影響範囲を表示してください。私が確認してから実行してください。
不明点は推測せず、確認事項として列挙してください。
正直、まだ試行中のこと
一方で、まだ答えが出ていないこともあります。
GitHub Projects（カンバン形式のボード）と組み合わせるかどうかは、まだ迷っています。
個人だとissue一覧とラベルだけで十分な気もしますし、ボードで見たほうが楽な気もします。
サブissueやissueタイプも、使いこなしているとはまだ言えません。
issueタイプは組織（Organization）単位で設定する機能なので、個人リポジトリでは使えない場面もありそうです。
ここは調査ベースの整理なので、使ってみたらまた追記します。
なお、Claude Code向けのissueの「書き方」については、Claude Code向けGitHub Issueの書き方で詳しくまとめています。
この記事は「issueでタスクを回す仕組み」、前回の記事は「1つのissueをどう書くか」と思って読んでもらえるとつながります。
まとめ：GitHub issueの使い方はタスク管理から始めるとわかりやすい
- GitHub issueはバグ報告専用ではなく、「やることカード」として使える
- 1タスク＝1issueにすると、終わったかどうかが明確になる
- ラベルで種類と優先度、マイルストーンで期限をまとめる
- 大きいタスクはサブissueに分けて「半日サイズ」にする
- Claude Codeに作らせるときは「下書き→確認→作成」の順にする
まずは、今頭の中にあるタスクを3つだけissueにしてみてください。
一覧で並んだ瞬間、「意外と管理できそう」と感じられるかもしれません。
Git・GitHubの基本操作を手を動かして覚えたい方向けに、Git学習アプリも公開準備中です（app.maahsachi.com で公開予定）。準備ができたらこのブログでお知らせします。
