GitHub・プルリク・会話の解決・2026年10月26日に確認

GitHub：マージが会話の解決を待っている

ブランチの保護やルールセットは、マージの前に会話の解決を求めることができます。そうすると、プルリクのコメントを全部解決するまで、そのブランチにはマージできません。マージの前に、すべてのコメントに対応したか目を通したことを確かめるための設定です（GitHub の説明「保護されたブランチについて」と「ルールセットで使える規則」）。REST の説明では、ルールセットのこの設定を「All conversations on code must be resolved before a pull request can be merged」（コードへの会話を全部解決してからでないとマージできない）と書いています。それまでの間、REST のプルリクの mergeable_state は blocked、GraphQL の mergeStateStatus は BLOCKED です（2026年10月26日に確認）。

GET  /repos/OWNER/REPO/rules/branches/BRANCH        → 規則 "pull_request" の parameters.required_review_thread_resolution
GET  /repos/OWNER/REPO/branches/BRANCH/protection   → required_conversation_resolution.enabled
POST /graphql   pullRequest(number: N) { reviewThreads(first: 100) { nodes { isResolved isOutdated viewerCanResolve path line } } }

数に入る会話

コードへの会話：解決できるのは、Files changed のタブにある、変更したコードへのコメントから始まった会話です。「Resolve conversation」を押すと会話全体がたたまれ、解決済みになります（GitHub の説明「プルリクにコメントする」）。API ではレビューのスレッドと呼び、それぞれに isResolved があります。
古くなった会話も：新しい変更で古くなった（outdated）会話でも、解決されていないことがあります。API は isOutdated と isResolved を別々に返します。Files changed のタブの Conversations メニューは、未解決・解決済み・古くなった会話を分けて一覧にするので、開いたままの会話を探せます（コメントが outdated になる理由）。
ルールの場所：ブランチの保護なら「Require conversation resolution before merging」、ルールセットならプルリクの規則の required_review_thread_resolution です。「Get rules for a branch」が、そのブランチに効いている規則の中に返します。1つのブランチに複数のルールセットが同時に効くこともあります。

会話を解決できる人

開いた人か書き込みのできる人：会話を解決できるのは、プルリクを開いた人か、リポジトリの書き込み権限を持つ人です。それ以外の人は、会話を始めたレビュアーでも、書き込み権限が無ければ解決できません。GraphQL の viewerCanResolve で、自分が解決できるかが分かります。
API で：GraphQL の resolveReviewThread と unresolveReviewThread は、スレッドの node id を受け取ります。ワークフローやアプリのトークンでは、プルリクの権限だけでは足りません（会話が解決できない理由）。
管理者：既定では、ブランチの保護の制限は、管理者の権限を持つ人や「bypass branch protections」の権限を持つロールには効きません（「Do not allow bypassing the above settings」をオンにすると効きます）。そのため、ほかの人が待っている間に管理者はマージできます。

直す所

開いたままの会話を探す：Files changed のタブで Conversations メニューを開くか、GraphQL でレビューのスレッドを一覧にして isResolved が false の物を拾います。
答えてから解決する：コメントに対応するか返信してから、プルリクを開いた人か書き込み権限のある人が解決します。プルリクの範囲の外の指摘は、元のコメントへのリンクつきの新しい issue にしてから解決できます。
解決できる人に頼む：自分では解決もルールの迂回もできないなら、プルリクを開いた人か、書き込み権限のあるメンテナーに頼みます。
ほかのルールも見る：会話の解決は要件の1つにすぎません。承認のレビュー（コードオーナーのレビュー・承認が数に入らない理由）、必須のチェック（必須チェックが Expected のまま）、ブランチを最新にしておくことも止める理由になります。

IntelliJ IDEA はスレッドは読むが、ルールは読まない

IntelliJ IDEA に入っている GitHub の機能が、会話の解決をどう扱うか。ソース（2026年10月31日に確認・IntelliJ IDEA：refUpdateRule.graphql・pullRequestReviewThreads.graphql・pullRequestReviewThread.graphql・GHPRTimelineThreadViewModel.kt・GHPRReviewServiceImpl.kt・GraphQL のファイル）では：

ルールは読まない：78本の GraphQL のファイルのどれも、会話の解決が必要か（ブランチ保護の requiresConversationResolution・プルリクのルールの requiredReviewThreadResolution）を頼まず、マージ先のブランチについて読むルールにもどちらもありません。
スレッドは読む：プルリクのレビューのスレッドを100件ずつ頼みます。それぞれについて、解決済みか・古くなったか、ファイルと行、100件までのコメント、自分のアカウントが返信・解決・解決の取り消しをできるかを頼みます。
解決する：タイムラインのスレッドのコードでは、状態を変えられるかを GitHub の答え（自分のアカウントでそのスレッドを解決・取り消しできるか）から決め、変えた分は GitHub の resolveReviewThread か unresolveReviewThread で送ります。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。差分の上の会話を出し、解決済みの会話にはだれが解決したかを出し、「解決」と「未解決に戻す」を出します。スレッドはトークンで GraphQL から読みます。GitHub がプルリクを blocked と言うときは、マージの確認に「対象のブランチのルールをまだ満たしていない（必須のレビューか、必須のチェック）」と出します。blocked のプルリクに未解決のコードへの会話があると、そこに件数を出し、対象のブランチのルールセットか保護が解決を求めているなら、それがマージを止めていると出します（ルールを読めない時は、止めているかもしれないと出します）。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。