GitHub Issuesで「重複候補が表示されない」「候補がずれている」「MCP経由でIssue fieldsを更新できない」と感じた場合、まず確認すべきなのは不具合そのものではなく、Public Previewの仕様・入力条件・権限・組織設定です。2026年6月19日前後に話題になったGitHub Changelogの更新では、Issue作成時の重複検出と、GitHub MCP serverからのissue fields読み書き対応が発表されました。ただし、どちらもすべての画面・権限・入力状態で同じように動くわけではありません。GitHub Changelog上の公開日は2026年6月18日、分類はReleaseです。日本時間では6月19日の更新として扱われる場合があります。(The GitHub Blog)
この記事では、GitHubの「Detecting Duplicate Issues – Public Preview and issue fields MCP support for GitHub Issues」に関連して起きやすい表示の違い、エラーの切り分け、管理者に確認すべき項目を、実務で使える形に整理します。
Detecting Duplicate Issuesとissue fields MCP supportで何が変わったのか
今回の更新は、大きく分けて2つあります。1つ目は、GitHub Issuesで新しいIssueを作成している途中に、既存Issueと似ている可能性のある候補を表示する重複検出です。2つ目は、GitHub MCP serverに接続したAIツールが、issue fieldsを読み書きできるようになった点です。(The GitHub Blog)
| 機能 | 主な対象者 | できるようになったこと | よくある勘違い |
|---|---|---|---|
| Duplicate issues detection | Issueを作成するユーザー、メンテナー | 新規Issue作成中に、既存Issueの重複候補を最大3件表示 | 候補が出ないと常に不具合だと思ってしまう |
| issue fields MCP support | GitHub MCP serverを使う開発者、管理者、AIエージェント運用者 | AIツールからIssue fieldsの読み取り・書き込み・フィールド値での絞り込みが可能 | MCPを有効にすれば誰でも全フィールドを操作できると思ってしまう |
| issue fields自体 | 組織管理者、トリアージ担当者 | Priority、Effort、日付などの構造化メタデータをIssueに持たせられる | ラベルやProjectsのカスタムフィールドと完全に同じものだと思ってしまう |
Duplicate issues detectionは、Issue作成フォームの入力内容をもとに既存Issueとの類似候補を表示する機能です。公式の説明では、候補はIssue作成フォーム内にインライン表示され、最大3件まで表示されます。候補が出てもIssue作成はブロックされず、そのまま新規Issueを作成できます。(The GitHub Blog)
issue fields MCP supportは、GitHub MCP serverに接続したAIツールが、Issue fieldsを読み書きしたり、フィールド値で既存Issueを絞り込んだりできるようにする更新です。GitHub MCP serverは、AIエージェントやアシスタントがGitHub上のリポジトリ、Issue、Pull Request、ワークフローなどを扱えるようにする公式MCP serverです。(The GitHub Blog)
重複候補が表示されないときの確認ポイント
GitHub Issuesで重複候補が表示されない場合、最初に確認すべきなのは入力条件です。公式のコミュニティ投稿では、Duplicate detectionはIssueタイトルが入力され、本文が100文字に達したタイミングで既存Issueを検索すると説明されています。また、タイトルは20文字以上がトリガー条件として示されています。(GitHub)
| 症状 | 確認すること | 対処 |
|---|---|---|
| 何も候補が出ない | タイトルが短すぎないか | 20文字以上の具体的なタイトルにする |
| 本文を書いても出ない | 本文が100文字未満ではないか | 再現手順、期待結果、実際の結果を入れて100文字以上にする |
| 本文を後から大きく修正しても候補が変わらない | 本文編集後の再検索仕様を誤解していないか | タイトルを編集して再検索を促す |
| 一部のリポジトリだけ出ない | Issueが有効か、Public Previewの提供状態に差がないか | 別リポジトリ・別ブラウザで比較し、必要なら管理者に確認 |
| 自分だけ表示されない | ブラウザ拡張、キャッシュ、ログイン状態の影響 | シークレットウィンドウ、別ブラウザ、再ログインで切り分け |
特に見落としやすいのが、「本文を編集すれば何度でも候補が更新される」と思い込むケースです。公式説明では、初回チェック後にタイトルを編集すると検索が再実行されますが、本文編集は初回チェック後には再トリガーしないとされています。(GitHub)
実務では、候補が出ないときにすぐ「GitHubの不具合」と判断するより、次のようなテストIssue文を使って再現確認すると切り分けが早くなります。
Title:
Windows環境でログイン後にダッシュボードが白画面になる
Body:
Windows 11、Chrome最新版でログインすると、認証完了後にダッシュボードが白画面になります。
コンソールにはTypeErrorが表示され、再読み込みしても改善しません。
期待する動作は、ログイン後にプロジェクト一覧が表示されることです。このように、環境、操作、実際の結果、期待する結果を入れると、重複検出に必要な情報量を満たしやすくなります。
重複候補が的外れに見えるときの考え方
Duplicate issues detectionは、単純なキーワード一致だけでなく意味ベースの類似性を使うと説明されています。そのため、タイトルや本文に同じ単語が含まれていなくても、似た問題として候補に出ることがあります。(GitHub)
たとえば、「ログイン後に白画面になる」と書いたIssueに対して、「ダッシュボード初期化時にReactエラーが出る」という既存Issueが候補に出る可能性があります。表現は違っても、実際には同じ画面・同じ障害を指している場合があるためです。
一方で、意味ベースの候補は、リポジトリ内に似た言葉や似た障害が多いほどノイズも出やすくなります。候補が的外れに見える場合は、次の順で確認すると実務上の判断がしやすくなります。
| 判断ポイント | 見るべき内容 | 判断例 |
|---|---|---|
| 発生箇所 | 同じ画面、API、コンポーネントか | 同じログイン処理なら重複の可能性が高い |
| 再現条件 | OS、ブラウザ、権限、設定が近いか | 条件が大きく違えば別Issueとして残す |
| エラーログ | 同じ例外、同じステータスコードか | 同じスタックトレースなら重複候補を優先 |
| 影響範囲 | 同じユーザー層・同じプランか | 管理者だけ発生するなら別問題の可能性 |
| 解決状況 | 既存IssueがOpenかClosedか | Closedでも再発なら新規Issueにリンクする |
重複候補が表示されたら、すぐに新規Issueをやめるのではなく、既存Issueを開いて「自分のケースと同じ再現条件か」を確認するのが安全です。GitHubの重複候補は非ブロッキングであり、候補が出ても新規Issue作成は可能です。(GitHub)
「Duplicate of」で閉じたのに重複扱いにならないとき
GitHubでは、IssueやPull Requestを重複として扱う方法も用意されています。公式ドキュメントでは、新しいコメント本文に「Duplicate of」に続けてIssue番号またはPull Request番号を書くことで、重複としてマークできると説明されています。(GitHub Docs)
ただし、重複マークのタイムラインイベントが表示されるには、コメントを作成するユーザーが、そのコメントを作成するリポジトリでwriteアクセスを持っている必要があります。権限が足りないユーザーが同じ文言を書いても、期待どおりの重複イベントにならないことがあります。(GitHub Docs)
| 起きていること | 原因として多いもの | 対処 |
|---|---|---|
| 「Duplicate of #123」と書いたのにイベントが出ない | write権限がない | メンテナーに対応を依頼する |
| 別リポジトリのIssue番号を書いたが意図どおりにならない | 参照先や権限の前提が違う | URLで明示し、管理者に確認する |
| 重複として閉じたが後で別問題だと分かった | triage時の判断ミス | タイムラインのUndoで解除できるか確認する |
| 同じ内容のIssueが何度も作成される | Issue templateや検索導線が弱い | テンプレートに「既存Issue確認」を入れる |
Duplicate issues detectionは「作成前に気づかせる」機能であり、作成済みIssueの運用ルールを置き換えるものではありません。メンテナー側では、重複を見つけたら既存Issueへ誘導し、必要に応じて「Duplicate of #番号」で履歴を残す運用が引き続き重要です。
issue fieldsが表示されない・編集できないときの確認ポイント
issue fieldsは、Issueに優先度、工数、開始日、目標日などの構造化メタデータを持たせる機能です。GitHub Docsでは、issue fieldsはPublic Previewであり、変更される可能性がある機能として説明されています。また、組織レベルで定義され、組織内のリポジトリのIssueに適用されます。(GitHub Docs)
表示されない、編集できない、検索できない場合は、次の順で確認します。
| 症状 | 確認する場所 | 管理者に確認すべきこと |
|---|---|---|
| Issueの右サイドバーにfieldが出ない | Issue type、Add field、組織設定 | 対象fieldがIssue typeにpinされているか |
| 自分だけfieldが見えない | 権限、field visibility | Organization onlyになっていないか |
| Public repositoryで外部ユーザーに見えない | Field Visibility | Publicにする必要があるfieldか |
| fieldを編集できない | リポジトリ権限 | triage以上の権限があるか |
| Pull Requestでfieldが見えない | 対象がIssueかPRか | issue fieldsはPull Request非対応でないか |
| 検索クエリでヒットしない | field名、値、スペースの扱い | field."target date":>=2026-03-01 のように書けているか |
GitHub Docsでは、Issue field valuesを設定・編集できるのはリポジトリに対してtriage以上のアクセス権を持つユーザーとされています。また、issue fieldsは現在Issueのみで利用でき、Pull Requestはサポートしていないと説明されています。(GitHub Docs)
管理者側で特に確認したいのは、fieldのpin設定です。GitHub Docsでは、fieldがIssue typeまたは「Issues without a type」にpinされていない場合、Issueサイドバーに表示されないことがあると説明されています。(GitHub Docs)
issue fieldsの検索でエラー・期待外れの結果になるとき
issue fieldsは検索にも利用できます。GitHub Docsでは、field. に続けてfield名と値を指定する形で、Issueをfield値で絞り込めると説明されています。field名にスペースが含まれる場合は引用符で囲む必要があります。(GitHub Docs)
よく使う検索例は次のとおりです。
field.priority:high
field.priority:high,medium
field."target date":>=2026-03-01
field.story-points:>5
is:open field.priority:high検索で失敗しやすいポイントは、field名と値の表記揺れです。たとえば、画面上の表示が「Target date」なのに field.target-date のように書くと、期待どおりに絞り込めないことがあります。field名にスペースがある場合は field."target date":>=2026-03-01 のように引用符を使います。(GitHub Docs)
また、visibilityがOrganization onlyのfieldは、権限のないユーザーにはIssueサイドバー、タイムライン、検索候補に表示されません。Public repositoryで「他の人には検索できない」と言われた場合は、まずfield visibilityを確認してください。(GitHub Docs)
MCP経由でissue fieldsを扱えないときの切り分け
GitHub MCP serverでは、Issues関連のtoolsetや個別toolを通じてIssueを作成・更新・検索できます。公式リポジトリのREADMEでは、issue_writeにissue_fieldsパラメータがあり、field名と値、単一選択のoption名、削除指定などを扱えることが示されています。また、list_issue_fieldsやfield_filtersによる絞り込みも説明されています。(GitHub)
MCPでエラーになる場合は、AIツールのプロンプトを直す前に、接続・権限・toolsetの3点を切り分けるのが近道です。
| 確認項目 | 見るべき内容 | 対処 |
|---|---|---|
| MCP serverの種類 | Remote MCP serverかLocal MCP serverか | 利用環境に合った設定を確認する |
| ホストアプリ | VS Code、Claude Desktop、Cursorなどが対応しているか | 各MCPホスト側の設定方式を確認する |
| 認証方式 | OAuthかPATか | 必要な権限を持つ認証にする |
| toolset | issues toolsetが有効か | GITHUB_TOOLSETSや起動オプションを確認する |
| read-only設定 | 書き込みtoolが無効化されていないか | read-only運用なら更新はできない |
| field名 | 実在するissue field名か | 先にlist_issue_fieldsで取得する |
| fieldの型 | single-select、text、number、dateの型に合っているか | option名、数値、日付形式を合わせる |
| 権限 | repo、read:orgなど必要な権限があるか | 管理者にPAT/OAuth scopeを確認する |
GitHub MCP serverの公式READMEでは、Remote GitHub MCP Serverを使うには対応するMCPホストが必要であり、VS CodeではリモートMCPとOAuth対応のためにVS Code 1.101以降が必要と説明されています。Local MCP Serverを使う場合はDockerの実行状態やPATの準備も確認対象になります。(GitHub)
さらに、GitHub MCP serverではtoolsetを指定して利用可能な機能群を制御できます。issues toolsetが有効でない、または個別toolを限定している場合、Issue関連の読み書きや検索が期待どおりに使えない可能性があります。read-only modeが有効な場合は、明示的に書き込みtoolを指定していてもwrite toolはスキップされると説明されています。(GitHub)
管理者に確認すべき項目
一般ユーザー側で再ログインや入力条件を確認しても改善しない場合は、組織管理者またはリポジトリ管理者に次の点を確認します。
| 確認先 | 確認内容 | なぜ重要か |
|---|---|---|
| リポジトリ管理者 | Issues機能が有効か | Issuesが無効なら作成・候補表示の前提が崩れる |
| 組織管理者 | issue fieldsが作成・pinされているか | fieldが未設定・未pinだと画面に出ない |
| 組織管理者 | field visibilityがPublicかOrganization onlyか | 外部ユーザーとの表示差の原因になる |
| 権限管理者 | 自分にtriage以上の権限があるか | field値の編集には権限が必要 |
| MCP運用担当 | PAT/OAuth scopeが足りているか | MCP経由の読み書きエラーの原因になる |
| MCP運用担当 | issues toolsetが有効か | Issue関連toolが利用できない原因になる |
| セキュリティ担当 | AIツールからIssue更新を許可してよいか | 自動triageやfield更新は監査対象になりやすい |
issue fieldsには上限もあります。GitHub Docsでは、組織あたりのIssue fieldsは25個、single-select fieldのoptionは100個、Issue typeごとにpinできるfieldは10個、Projects内の総field数は50個までと説明されています。上限に達している場合、新しいfieldを追加できない、Projectsにfieldを追加できないといった問題につながります。(GitHub Docs)
障害か仕様かを見分ける手順
GitHubの表示やMCPの挙動がおかしいときは、次の順番で切り分けると、管理者やサポートへ伝える情報が揃いやすくなります。
| 手順 | 確認内容 | 判断 |
|---|---|---|
| 1 | 公式仕様の入力条件を満たしているか | 重複候補はタイトル20文字以上・本文100文字以上を確認 |
| 2 | 別ブラウザ・シークレットウィンドウで再現するか | 拡張機能やキャッシュの影響を切り分け |
| 3 | 別リポジトリでも同じか | リポジトリ設定かアカウント全体かを切り分け |
| 4 | 別ユーザーでも同じか | 権限・visibilityの問題を確認 |
| 5 | GitHub Statusに障害が出ていないか | GitHub側の広域障害を確認 |
| 6 | MCPの場合はtoolset・scope・read-onlyを確認 | AIツール側ではなくMCP設定の問題を確認 |
広範囲でIssue、API、Copilot、Webhooksなどの異常が疑われる場合は、GitHub Statusを確認します。GitHub Statusでは、Issues、API Requests、Copilotなどの稼働状態や過去のインシデントが公開されています。(githubstatus.com)
実務でのおすすめ運用
Duplicate issues detectionとissue fields MCP supportを活かすには、機能を待つだけでなく、Issue運用を少し整えることが重要です。
Issue templateに重複確認の導線を入れる
重複検出は便利ですが、候補表示だけに頼ると、短い本文や抽象的なタイトルでは候補が出にくくなります。Issue templateには、次のような項目を入れると効果的です。
### 事前確認
- [ ] 既存Issueを検索しました
- [ ] 重複候補が表示された場合、内容を確認しました
### 発生環境
- OS:
- ブラウザ:
- バージョン:
### 再現手順
1.
2.
3.
### 期待する結果
### 実際の結果
### 関連するIssueこの形式なら本文が自然に100文字を超えやすく、重複検出にも、メンテナーのtriageにも役立ちます。
ラベルとissue fieldsの役割を分ける
issue fieldsを導入した直後に起きやすい失敗は、既存ラベルと同じ意味のfieldを増やしすぎることです。たとえば、priority/high ラベルと Priority: High fieldを併用すると、どちらが正なのか分からなくなります。
おすすめは、次のように役割を分けることです。
| 用途 | ラベル向き | issue fields向き |
|---|---|---|
| 種類の大まかな分類 | bug、documentation、help wanted | Issue typeと組み合わせる |
| 優先度 | 小規模ならラベルでも可 | 複数リポジトリで統一するならfield |
| 工数 | ラベルでは管理しにくい | EffortやStory points |
| 日付 | ラベルでは不向き | Start date、Target date |
| 自動化 | 単純な振り分け | MCP、API、Actionsと連携するfield |
GitHub Docsでは、issue fieldsはIssue上の値がsource of truthになり、Projectsごとに異なるproject fieldとはスコープが違うと説明されています。既存のProject fieldと同じ概念を二重管理すると混乱しやすいため、移行時は「どちらを正にするか」を先に決めてください。(GitHub Docs)
MCPに書き込みを許可する範囲を決める
MCP経由でIssue fieldsを書き込めるようになると、AIエージェントがPriority、Area、日付などを自動設定できます。便利な一方で、誤ったfield更新が大量に入ると、triage結果やレポートに影響します。
最初は、次のような段階的な運用が安全です。
| フェーズ | 許可する操作 | 目的 |
|---|---|---|
| 試験運用 | Issueの読み取り、field一覧取得 | field名・型・権限の確認 |
| 限定運用 | Draft的なコメント提案、ラベル候補提示 | 人間の確認を残す |
| 部分自動化 | PriorityやAreaの初期値設定 | triageの初動を軽くする |
| 本運用 | field更新、検索、レポート連携 | 運用ルールが固まってから拡大 |
特にPersonal Access Tokenを使う場合は、必要最小限のscope、プロジェクトごとのtoken分離、定期的なローテーション、設定ファイルへの直書き回避を徹底してください。GitHub MCP serverのREADMEでも、PATの安全な扱いとして、必要最小限の権限、tokenの分離、定期ローテーション、バージョン管理へコミットしないことが推奨されています。(GitHub)
よくある質問
重複候補が出ないのはGitHubのバグですか？
必ずしもバグではありません。タイトルが20文字未満、本文が100文字未満、既存Issueに十分似たものがない、本文編集後に再トリガーしていない、ブラウザや権限の影響がある、といった原因が考えられます。まず入力条件と再現環境を確認してください。(GitHub)
候補が出ても新しいIssueを作成できますか？
作成できます。Duplicate issues detectionの候補は非ブロッキングであり、候補が表示されても新規Issue作成を妨げません。候補を確認したうえで、別問題だと判断できるなら新規Issueとして作成して問題ありません。(GitHub)
issue fieldsはPull Requestでも使えますか？
GitHub Docsでは、issue fieldsは現在Issueのみで利用でき、Pull Requestはサポートしていないと説明されています。Pull Requestで同じfieldが見えない場合は、仕様の可能性が高いです。(GitHub Docs)
MCPでissue fieldsを更新できない場合、何を管理者に伝えればよいですか？
対象organization、repository、Issue番号、使ったMCPホスト、RemoteかLocalか、認証方式、PAT/OAuth scope、issues toolsetの有無、read-only設定、実行したtool名、field名と値を伝えると、原因を絞り込みやすくなります。
Public Previewなので本番運用は避けるべきですか？
避けるというより、変更の可能性を前提に段階導入するのが現実的です。GitHub Docsではissue fieldsがPublic Previewであり変更される可能性があると明記されています。重要な業務フローに組み込む場合は、ラベルや既存Projectsとの二重管理期間を設け、APIやMCPの挙動変更に備えてください。(GitHub Docs)
まず取るべき行動
GitHub Issuesの重複検出やissue fields MCP supportで困ったときは、次の順で確認してください。
- 重複候補が出ない場合は、タイトル20文字以上・本文100文字以上・タイトル編集による再検索を確認する。
- 候補が不自然な場合は、発生箇所、再現条件、ログ、影響範囲で既存Issueと比較する。
- issue fieldsが見えない場合は、権限、visibility、Issue typeへのpin設定、Pull Requestではないかを確認する。
- MCPで失敗する場合は、
issuestoolset、PAT/OAuth scope、read-only設定、field名・型を確認する。 - 複数ユーザーで同時に異常が出る場合は、GitHub Statusで広域障害を確認する。
今回の更新は、Issueの重複を減らし、AIツールによるtriageを進めるための実用的な改善です。ただし、Public Previewの機能は「表示されない」「人によって見え方が違う」「MCPでは更新できるが画面では見えない」といった混乱が起きやすい領域でもあります。まず仕様と権限を確認し、そのうえでIssue template、field設計、MCPの権限管理を整えることが、最も確実な対処法です。
コメント