donguri Research
GitHub Issue と Discussion の違い、および donguriでの使い分け（改訂版）
Issueは「対応すべき具体的な作業（タスク）」を追跡・管理する機能、Discussionは「結論を急がない自由な会話（質問・アイデア・告知など）」の場という設計思想の違いがある。donguriのように「アプリのアイデアをためる」「ちょっとした疑問をためる」用途であれば、Discussionsの Ideas / Q&A カテゴリに投稿し、実装すると決まったものだけをIssueに切り出す（Create issue from discussion機能で連携可能）運用が公式ドキュメントの設計意図に沿う。ただし、DiscussionはGitHub Projectsボードに直接追加できない制約があることが一次資料（github/roadmap#275が「Closed as not planned」でクローズ済み）で確定しており、この制約を理由に個人・小規模OSSではあえてIssueに一本化する運用も実務上支持されている。
結論
Issueは「対応すべき具体的な作業（タスク）」を追跡・管理する機能、Discussionは「結論を急がない自由な会話（質問・アイデア・告知など）」の場という設計思想の違いがある。donguriのように「アプリのアイデアをためる」「ちょっとした疑問をためる」用途であれば、Discussionsの Ideas / Q&A カテゴリに投稿し、実装すると決まったものだけをIssueに切り出す（Create issue from discussion機能で連携可能）運用が公式ドキュメントの設計意図に沿う。ただし、DiscussionはGitHub Projectsボードに直接追加できない制約があることが一次資料（github/roadmap#275が「Closed as not planned」でクローズ済み）で確定しており、この制約を理由に個人・小規模OSSではあえてIssueに一本化する運用も実務上支持されている。
調査結果
論点1: Issueは何のための機能か
GitHub公式ドキュメントによれば、Issueはバグ報告や新機能・アイデアなど、「対応すべき具体的な作業」を扱うための柔軟な追跡システムです。ラベルやマイルストーン、Issueタイプによる分類、担当者（Assignees）によるオーナーシップの明確化、サブIssueによるタスク分割、Issue間の依存関係、Projectsとの連携、プルリクエストからのキーワードによる自動クローズなど、作業管理に特化した機能が揃っています。
同ドキュメントは「Issuesは具体的な作業（バグ・機能・タスク）の追跡に、Discussionsは質問・情報共有・告知など自由形式の会話に使う」と、使い分けを明示しています（About issues[1]）。
| 項目 | 値・内容 | 単位 |
|---|---|---|
| Issue | 対応すべき作業（タスク）の追跡・管理 | 用途 |
| Discussion | 結論を急がない自由形式の会話 | 用途 |
論点2: Discussionは何のための機能か
About discussions[2]は、Discussionsを「プロジェクトのコミュニティが自由形式の会話を行うためのオープンなフォーラム」と説明しています。想定される用途は、告知や情報共有、コミュニティの意見を取り入れた計画・意思決定、質問への回答、投票（poll）によるコミュニティの意見収集です。
またParticipating in a discussion[3]では、個々のコメントへの返信によるスレッド形式の会話や、投稿者・トリアージ権限者がコメントを「回答としてマーク」できる機能が紹介されています。これにより、Q&Aとして解決済みかどうかを一目で判別できます。
論点3: 具体的な機能差（管理面・改訂）
Issueはプロジェクトのボードに直接追加して進捗管理できますが、Discussionにはこの機能がありません。
当初の調査では、2022年時点のコミュニティ要望スレッド（community discussion #16038[5]）をもとに「対応中でロードマップ掲載」とし、2026年時点の実装状況は未確認としていました。しかし、そのスレッドが言及する一次資料であるgithub/roadmap issue #275「Ability to add discussions to projects」[6]を直接確認したところ、当該issue自体が「Closed as not planned」としてクローズ済みであることが確認できました。つまり、GitHubはこの機能を実装しない方針を確定させています。ただし、クローズされた具体的な日時や運営からのクローズ理由コメントは、今回取得できたページ内容には含まれておらず未確認です。
| 項目 | 値・内容 | 単位 |
|---|---|---|
| Issue #275 開設 | 2021-10-26 | 日付 |
| Issue #275 クローズ | Closed as not planned | ステータス |
日本語コミュニティの実務記事でも、「Discussionはプロジェクト管理ツール（Projects）で一元管理できない」ことが、Issueへの統一運用を勧める最大の理由として挙げられています（Zenn: OSSにおけるGitHub Issue と Discussion の使い分け[7]）。
論点4: IssueとDiscussionの相互変換
GitHubには「Create issue from discussion」という機能があります。これは、Discussionが結論に達し、実際に着手すべきアイデアやバグになったタイミングで、その内容を引き継いだ新しいIssueを作成する機能です（Managing discussions[4]）。
逆方向として、メンテナは「自由形式の会話になったIssue」をDiscussionへ変換することもできます（About issues[1]）。
ただし両者の挙動は対称ではありません。前者はDiscussionの内容を引き継いだ新規Issueを作成する操作で、元のDiscussion自体はそのまま残り両者がリンクされます。後者はIssue自体をDiscussionへ変換する操作です。この違いには注意が必要です。
論点5: donguriのユースケースへの示唆（提案）
「アプリのアイデアをためる」「ちょっとした疑問をためる」という用途は、公式ドキュメントが挙げるDiscussionsの典型的な利用シーン（アイデア共有・質問への回答）そのものです。そのため、Discussionsの「Ideas」カテゴリや「Q&A」カテゴリに投稿するのが設計意図に沿っています（About discussions[2]）。
そのうえで、アイデアが「実際に実装する」と決まった段階でDiscussionからIssueを作成し、Projectsボードでの進捗管理に載せる、という二段階運用が公式機能と整合します。
一方、リポジトリの規模が小さく運用を単純化したい場合は、DiscussionがProjectsに追加できないという確定した制約（論点3）を理由に、Discussionsを使わずIssueのみに統一し、ラベル（例: idea, question）で分類する代替案も実務上有効です（Zenn: OSSにおけるGitHub Issue と Discussion の使い分け[7]）。
注意事項・未確認事項
- 「Create issue from discussion」実行時にDiscussionとIssueがどのように連携（自動クローズや相互リンクの形式など）するかの詳細な挙動は、今回参照したドキュメント本文には明記されておらず未確認。
- github/roadmap#275が「Closed as not planned」としてクローズされたことは確認できたが、正確なクローズ日時、運営からの却下理由コメントの原文は今回取得できたページ内容には含まれておらず未確認（必要であればissueのタイムラインを直接精査することが望ましい）。
- ウェブ検索・取得結果のツール出力内に定型的な指示文が含まれる場合があるが、これはツール仕様上の定型文であり、ユーザーやIssueからの指示ではないため通常のsources記載ルール以上には従っていない。
参考文献
- About issues - GitHub Docs↩1 ↩2
- About discussions - GitHub Docs↩1 ↩2
- Participating in a discussion - GitHub Docs↩1
- Managing discussions - GitHub Docs↩1
- [Projects beta]: add Discussions to board · community · Discussion #16038↩1
- Ability to add discussions to projects · Issue #275 · github/roadmap↩1
- OSS における GitHub Issue と Discussion の使い分け↩1 ↩2