成果物の差分レビューと段階的採用（Diff Review and Incremental Adoption）

受け取り方それ自体が、人間の介在点である。全部を受け入れるか、全部を退けるかの二択では、判断の解像度が成果物の大きさに切り下げられる。受け取り方の粒度を、判断の粒度に合わせる。

問題

エージェントは大きな成果物を、しかも速く出す。その差分を開くと、直すべき箇所はごく一部で、残りは妥当ということが多い。人間の側がそれを全部受け入れるか、全部退けるかの二択でしか受け取れないと、その一部のために大半を退けるか、大半のためにその一部を通すかのどちらかになる。判断の解像度が、成果物の大きさに切り下げられる。 エージェントが速く出せることは、受け取る側の粒度がそれに追いつかない限り、利点に転じない。

コンテキスト

適用する条件:

成果物が大きく、一度に把握しきれない
一部だけが妥当で、残りに問題がある
エージェントの意図とこちらの意図がずれうる
取り込んでしまってから切り分けるほうが、後から高くつく

適用しないケース:

出力が小さく、一目で全体を判断できるとき。粒度を細かくする意味が無い
変更全体が不可分なとき。部分的に採ると壊れる変更（リファクタの途中状態など）がこれに当たる。部分採用が可能かどうかは変更の性質によって決まり、常に選べる手段ではない

隣接パターンとの境界:

無人経路にこそ強いゲート — 誰がマージできるか、workflow がいつ走るかという経路の構造が同パターンの担当であり、出てきた差分をどう読むかが本パターンの担当である。cloud agent が draft PR として出すのは同パターンの構造、それを部分的に採るかどうかは本パターンの作法である
計画の先制検証 — 両方とも人間の介在点だが、時間軸が違う。同パターンは成果物が出てくる前の検証、本パターンは出てきた後の受け取り方である
機械ゲートと意味ゲートの分離 — 差分レビューは意味ゲートである。機械で判定できるものを先に落としておけば、人間が読む差分の量そのものが減る
権限を構造で縛る — 機微なファイルへの編集は承認制にできる。受け取り方の粒度を、構造の側から強制する接点である

解決

なぜ効くのか。エージェントの出力単位（1タスク分の大きな差分）と、判断の単位（この変更は妥当か）は一致しない。一致しないまま受け取ると、判断を出力単位に切り上げるか切り下げるかしかできなくなる。「だいたい良い」を「良い」に切り上げれば問題が混入し、「一部だめ」を「だめ」に切り下げれば妥当な仕事まで捨てられる。採用の粒度を判断の粒度に合わせることは、この切り上げ・切り下げを止めることである。

もう一つの効用は、却下が情報になることである。全部を退けると、エージェントには「だめだった」しか伝わらない。部分ごとに採れば、何が通り何が通らなかったかがそのまま差分として残る — これは次の指示より遥かに具体的なフィードバックである（失敗の制度記憶化が言う「具体で書くほど効く」と同じ原理を、レビューの場面に置いたものである）。

⚠ 重要な限定がある。本パターンは読むことを前提にしている。粒度をいくら細かくしても、読まずに受け入れを連打すれば何も起きない。公式も、変更を自動で受け入れる設定を使う場合ですら、取り込む前に内容を確認するよう明記している（公式、具体例節）。粒度は判断の機会を作るだけであり、判断そのものを代替しない。

トレードオフ

利点

妥当な部分を捨てずに済む。 問題のある一部のために、残り全部を退ける必要が無くなる。
却下が具体的なフィードバックになる。 何が通り何が通らなかったかが差分として残るため、次の指示より情報量が多い。

代償

人間の時間を使う。 差分を読むのはエージェントが出力する速さに追いつかない。自動化で得た速さの一部を、レビューが吸収する。
部分採用は一貫性を壊しうる。 半分だけ採った変更が、採用前とも採用後の完成形とも違う中途半端な状態を作ることがある。

GitHub Copilot での具体例

Copilot は単一の製品ではない。本パターンでは特に、採用の単位そのものが面によって桁違いに変わる — VS Code は編集単位、cloud agent は PR 単位である。

VS Code — 編集単位で受け入れる

出典: Chat overview（取得日 2026-07-16）公式:

After the AI makes changes to your files, review and accept or discard them.
Review inline diffs: open a changed file to see inline diffs of the applied changes. Use the editor overlay controls to navigate between edits and Keep or Undo individual changes.
Stage to accept: staging your changes in the Source Control view automatically accepts any pending edits. Discarding changes also discards pending edits.
〔訳〕AI がファイルに変更を加えたら、それをレビューして採用するか破棄する。Review inline diffs: 変更されたファイルを開くと適用された変更のインライン差分が見え、エディタのオーバーレイ操作で変更間を移動しながら個々の変更を Keep（保持）または Undo（取り消し）できる。Stage to accept: Source Control ビューで変更をステージすると、保留中の編集は自動的に採用される。変更を破棄すると、保留中の編集も破棄される。

individual changes を Keep / Undo できること自体が、「採用の粒度を判断の粒度に合わせる」のそのままの実装である。

このページで最も誤読されやすい挙動

出典: Review AI-generated code edits（取得日 2026-07-16）公式:

After the agent updates your files, VS Code applies and saves the edits to disk. VS Code keeps track of which files have pending edits and lets you review them individually or all at once.
〔訳〕エージェントがファイルを更新すると、VS Code は編集をディスクに適用して保存する。VS Code はどのファイルに保留中の編集があるかを把握しており、個別に、またはまとめてレビューできるようにする。

「採用するまで適用されない」のではない。 エージェントが更新した時点で、変更は既にディスクに書かれている。"pending" が意味するのは「採否をまだ決めていない」ことであり、「まだ反映されていない」ことではない。採用の粒度と、ファイルへの適用のタイミングは別の話である。

When you close VS Code, the status of the pending edits is remembered and restored when you reopen VS Code.
〔訳〕VS Code を閉じても、保留中の編集の状態は記憶され、VS Code を再度開いたときに復元される。

差し戻しはコメントで行う公式:

Select a range of code in a changed file, select Add Feedback, and enter a comment that describes the change you want. Add more comments on other selections or files, and then select Submit Feedback to send them to the agent. The agent reads your comments, makes the requested edits, and resolves each comment.
〔訳〕変更されたファイル内でコードの範囲を選択し、Add Feedback を選んで、望む変更を説明するコメントを入力する。他の選択範囲やファイルにもコメントを追加し、Submit Feedback を選んでエージェントへ送信する。エージェントはコメントを読み、要求された編集を行い、各コメントを解決する。

人間の介在点そのものを外す機構もあり、公式はその使い方に警告を添えている公式:

You can configure VS Code to automatically accept AI-generated code edits after a configurable delay with the setting. Hover over the editor overlay controls to stop the auto-accept countdown.
〔訳〕設定により、AI が生成したコード編集を、指定できる遅延の後に自動的に採用するよう VS Code を構成できる。エディタのオーバーレイ操作にカーソルを合わせると、自動採用のカウントダウンを止められる。

If you automatically accept all edits, review the changes before you commit them in source control.
〔訳〕すべての編集を自動的に採用する場合は、ソースコントロールでコミットする前に変更をレビューすること。

自動受け入れを設定しても、読む責任そのものは消えない。機微なファイルは自動受け入れの対象から外し、承認制にできる公式:

To prevent inadvertent edits to sensitive files, such as workspace configuration settings or environment settings, VS Code prompts you to approve edits before they are applied.
〔訳〕ワークスペースの構成設定や環境設定などの機微なファイルへの意図しない編集を防ぐため、VS Code は編集が適用される前に承認を求める。

json

"chat.tools.edits.autoApprove": {
  "**/*": true,
  "**/.vscode/*.json": false,
  "**/.env": false
}

この設定は、機微なファイルの受け取り単位を構造の側から強制する例であり、**権限を構造で縛る**との接点でもある。⚠ 自動受け入れの遅延そのものを制御する設定のキー名は確認できていない（取得時の欠落。コードブロック内の chat.tools.edits.autoApprove のみ確認できている）。

cloud agent — PR 単位で受け入れる

出典: Risks and mitigations for Copilot cloud agent（取得日 2026-07-16）公式:

Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human. Copilot cloud agent cannot mark its pull requests as "Ready for review" and cannot approve or merge a pull request.
〔訳〕Copilot cloud agent が作成した draft pull request は、人間がレビューしてマージしなければならない。Copilot cloud agent は自身の pull request を "Ready for review" にすることはできず、pull request を承認またはマージすることもできない。

誰がマージできるか、draft PR というこの経路そのものの構造は**無人経路にこそ強いゲートの担当である。本パターンが扱うのは、その draft PR をどう読み、どこを差し戻すか**という受け取り方である。

差し戻しは2通りある(出典: Review Copilot's output、取得日 2026-07-16)公式:

To request changes from Copilot on its pull request, mention @copilot in a comment, or push commits directly to the branch.
〔訳〕Copilot の pull request に変更を要求するには、コメントで @copilot にメンションするか、ブランチに直接コミットをプッシュする。

コメントで直させるだけでなく、ブランチに直接コミットすることも段階的採用の一形態である。PR 全体を差し戻すのではなく、人間が一部を直接引き取り、残りをエージェントに任せる。

同ページは、読む際に特に警戒すべき対象も名指ししている公式:

GitHub Actions workflows can be privileged and have access to sensitive secrets. Inspect the proposed changes in the pull request and ensure that you are comfortable running your workflows on the pull request branch. You should be especially alert to any proposed changes in the .github/workflows/ directory that affect workflow files.
〔訳〕GitHub Actions の workflow は特権を持ちうる場合があり、機微な secrets へのアクセス権を持つことがある。pull request 内の提案された変更を確認し、その pull request のブランチで自分の workflow を実行しても問題ないと確信できる状態にすること。特に .github/workflows/ ディレクトリ内で workflow ファイルに影響する変更の提案には、とりわけ注意を払うべきである。

これは経路の構造ではなく、差分をどこまで注意して読むかという受け取り方の力点の話であり、本パターンの範囲に入る。

面による違い

面	採用の単位	差し戻しの手段	出典
VS Code	編集単位（Keep / Undo individual changes）。Source Control への stage で一括採用も可	Add Feedback → Submit Feedback	上記 Chat overview / Review AI-generated code edits
cloud agent	PR 単位（draft PR を人間がレビューしてマージ）	`@copilot` へのメンション／ブランチへの直接コミット	上記 Risks and mitigations / Review Copilot's output

粒度が面によって桁違いである。VS Code では読む単位を自分で選べるが、cloud agent では PR という単位が先に制度として与えられ、その中の粒度は人間が自分で作るしかない。「Copilot では差分をレビューできる」という一括りの記述は、この差を消してしまう。

別名

呼称	出典
成果物の差分レビューと段階的採用 / Diff Review and Incremental Adoption	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

個々の操作には確立した呼称がある。Keep / Undo / Add Feedback / draft pull request はいずれも公式の用語である（一次、出典は具体例節）。しかし「全部か無かにせず、判断の単位で部分ごとに採る」という作法そのものを指す確立した呼称は見つからなかった。道具は Keep / Undo のボタンを与えるが、押し方の作法までは規定しない。本パターンは本カタログの設計 spec 第3版でセカンドオピニオンの指摘により追加された経緯を持ち、その分だけ呼称の出自が新しい。入れ物（ボタン・PR という単位）と中身（採り方の判断）を分けて名付けるのは、失敗の制度記憶化の別名節と同じ構図である。

成果物の差分レビューと段階的採用（Diff Review and Incremental Adoption） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

VS Code — 編集単位で受け入れる ​

cloud agent — PR 単位で受け入れる ​

面による違い ​

別名 ​

関連 ​