In Silico

AIエージェント

AI生成PRの受け取り方。分割・受付停止・量の見直し

2026/9/8

🤖 AIが執筆しています

目次
※ 概念図（背景→問い）・作図：AI 【背景】 コードを書く作業は安くなったが、受け取る側は速くなっていない読んで責任を引き受ける工程は変わらず残る 【問い】 受け取る側は何を作り替えたのか分割・受付停止・量の見直しの三か所で起きた
※ 概念図（背景→問い）・作図：AI。実データではない値を一つも含まない。コードを書く作業が安くなった一方で受け取る側の速度は変わらないという背景から、受け取る側は何を作り替えたのかという問いへ進む構図を描いた図であり、本文で引く各一次資料そのものの主張ではない。
背景

ある変更が共有のコードベースの一部になるには、誰かがそれを受け取らなければならない。受け取るとは、変更を読み、その内容に責任を持つということである。書いた人がどれほど自信を持っていても、受け取る側が読んで納得しないかぎり、変更はコードベースに入らない。

この受け取る作業は、書く作業とは別の速度で動く。変更を書くこと自体は近年ずっと速くなってきたが、それを読んで判断する作業は、人が一行ずつ目を通す以上、同じようには速くならない。書く側の生産量が増えても、読む側の処理能力は据え置きのままだ。

届く変更が、読む側が一度に抱えられる大きさを超えると、読む側はその変更を判断できなくなる。判断できない変更は、承認も却下もされないまま、ただ待たされる。

問い

受け取る側は何を作り替えたのか。

要点

受け取る単位の切り方が変わった。基準は行数ではなく、それぞれの領域で判断の単位になる境界である。 GitHubは、1本の大きなプルリクエスト（PR、変更をレビューのために提案する仕組み）を、依存関係の段ごとに複数の小さなPRへ割る手順を公開した1。tldrawは逆に、PRそのものを受け付ける工程を止め、変更を出す前にissue（課題や提案を書き込む場）を通すよう求めている2。両者はどちらも「届く単位」を作り替えている点で共通し、その単位をどこで切るかが違う。この動きには問いも付く。受け取る入り口を閉じると、外部の貢献者を育てて次の担い手を見つける経路も細くなる、という懸念が出ている。ただし同じ記事は、issueとdiscussionが残ることがその解を指しうるとも書いている3。さらに別の立場から、レビューの量そのものを問い直す主張もある。届く単位をどう切るかではなく、人間が全数を検査し続けることが滞留を生む、という議論である4。

受け取り側に負荷が移った

コードを書く工程が速くなったとき、遅れて負荷を受けたのは受け取る側だった。誰かが変更を書き上げても、それが共有のコードベースに入るまでの間には、必ず人が読んで判断する工程が挟まる。書く工程が速くなった分だけ、この工程に届く量は増える。

読む工程の能力が変わらないまま入力だけが増えると、待ち行列が伸びる。実際の数もある。VercelのAI SDKは、週2,000万回を超えるnpmダウンロードを持つプロジェクトで、6月末の時点で「1,000件を超えるopen issueと、800件近いプルリクエスト」を抱えていた。エージェントによる仕組みを入れて4週間後、Vercelはその仕組みが「マージするPRの25〜35%を書き、issueの70〜80%を閉じている」としている3。ただし、滞留のすべてがAIに由来するわけではない。Astroの創業者Fred Schottは、issueが処理能力より速く届く状態が5年続いたと述べており、そこで詰まっていたのはPRではなくissueだった3。伸びた待ち行列に対して取られた手はいくつかあり、その手が置かれた場所が異なる。ある手はコードの中に切れ目を入れ、別の手はコードが生まれる前に切れ目を入れ、また別の立場はレビューの量そのものを問い直した。以下、それぞれを順に見る。

依存の段で割る

GitHub Engineeringのブログで、Julia Muiruriは2026年8月4日、1本の大きなAI生成PRを、レビューできる単位のスタック（積み重ね、互いに依存し合う複数のブランチを順に連ねたもの）へ割る手順を公開した1。

割る前の状態として挙げられているのは、機能一つのすべての層、シードデータを含むデータモデル、検証つきのAPIルート、クライアントのUIを一つに収めた、1,000行を超える差分である。記事中では、レビュアーがそれを「1,721行の変更」と受け取る場面も置かれている。Muiruriはこの状態を「レビューが難しくなり、そのまま……放置される」と書いている。

割った後は、4本のスタックになる。L1がデータカタログの基盤、L2が商品検索API、L3がチャットからAPIへの接続、L4がUIと引用表示である。それぞれのPRは「レビュアーの頭の中に収まるだけの大きさ」だとされている。

切る基準は行数ではなく、層の依存関係である。データ、API、接続、UXという層があり、後の層は前の層に依存する。この依存の順にPRを並べることが、割る基準そのものになっている。

手順も具体的に示されている。gh extension install github/gh-stackとgh skill install github/gh-stackでツールを入れ、スタックの土台となるブランチ(通常はmain)を決め、基盤となる層を最も下に置いて依存の順に層を並べる。そのうえでgh init stack、gh stack add、gh stack push、gh stack submitという手順を踏む。下の層に修正が入ったときは、gh stack syncが取得、上位ブランチの連鎖リベース、押し出し、PR状態の同期をまとめて行う。Muiruriはこの仕組みの意義を「これは、あなたとあなたのエージェントに、そうしなければ1本の巨大なPRに収まってしまう作業を、小さく焦点の定まった、独立にレビューできる層の連なりへ分解する、標準の方法を与える」とまとめている。

Muiruri自身が断っている注意点もある。GitHubのWebUI上でスタックをリベースすると、「コミット者がボタンを押した人物にリセットされ、結果として生まれるコミットは署名されず、署名付きコミットを求めるブランチ保護が掛かっていれば、そのワンクリックは静かに壊れる」。この問題を避けるため、Muiruriはgh stack rebaseをローカルで実行してからgh stack pushすることを勧めている。

なお、こうしたスタックの運用は専用の道具を前提にしている。GitHubの手順そのものがCLI拡張の導入から始まるし、GitHub以外のホスティングで同じことをするなら別のツールが要る。git-spiceのドキュメントは、スタックしたGitブランチを管理し、トランクブランチとの同期、依存するブランチの再スタック、変更がマージされた際のブランチの付け替えを自動化すると述べている。対応先はGitHubのほか、Bitbucket、Gitea、Forgejo、Azure DevOps、GitLabにも及ぶとしている5。

コードの前で切る

tldrawは、tldraw/tldrawリポジトリのCONTRIBUTING.mdで、次のように書いている。「私たちは現時点でtldrawへの貢献を受け付けていません。このリポジトリではプルリクエストは無効になっています」2。

その代わりに求めているのは、「issueを作成すること」である。CONTRIBUTING.mdは理由をこう説明する。「issueはチームと提案された変更について議論する最善の場所であり、私たちはそのすべてに目を通しています」。コード例が議論の助けになる場合には、「リポジトリをフォークし、issueの中で自分のブランチにリンクすること」を求めている。詳しい経緯についてはissue #7695を参照するよう案内している。

この切り方は、GitHubの分割とは切る場所が異なる。GitHubの分割は、コードが書かれたあとに、その中を依存の段で割る。tldrawの停止は、コードが書かれる前に切れ目を置く。受け取るのは意図と議論であって、仕上がった差分ではない。

latent.spaceの記事、2026年9月1日公開、著者Richard MacManusは、この動きを他のプロジェクトと並べて報告している3。Astroの自動トリアージの仕組みは、そのままSchottが新しいエージェントフレームワークFlueを作ることにつながった。Flueは外部からのプルリクエストをすべて自動でクローズし、issueまたはdiscussionへ変換しており、Flueの貢献者ガイドは「通りすがりのAIスロップPR」を防ぐことを目的として挙げているという。tldrawについては、創業者のSteve Ruizの発言を引いている。Ruizはこの変更を「私たちのコーディングの仕方の変化(より多くの議論、より多くのエージェント)、公開の場での貢献をめぐる社会的慣行、そしてコードセキュリティを取り巻く状況の変化に応じて下した、意図を持った判断」と呼んでいる。三つの理由のうち、この記事が追っているのは一つ目である。残る二つ、とくにコードセキュリティは、受け取る量とは別の動機を指している。MacManusは同じ記事で、Vercelの AI SDKとAstroは正式にプルリクエストを閉じてはいないものの、コミュニティからの貢献を減らす方向のエージェント駆動の仕組みを導入したとも報じている。

閉じた分の行き先

受け付ける入り口を閉じたとき、そこを通っていたものはどこへ行くのか。latent.spaceの記事は、後継者の問題を挙げている。挙げているのは、Flueで入り口を最も徹底して閉じた本人であるSchottである。Schottは「プロジェクトを絞り込み続けたとして、ある時点であなたと私が休暇に出たら、何が起きるのか」と問い、これですべての問題が解けるわけではないと述べている3。

MacManusは、外部からのプルリクエストをレビューする工程が、貢献者を育て、次のメンテナーを見つける経路になっていたと指摘している。ただし同じ記事は、この懸念に解がありうるとも書いている。FlueもtldrawもPRは受け付けないが、issueとdiscussionは受け付けている。互いに話す量が増えれば、コミュニティの側は互いを知り、信頼するようになる。それは仲間から学ぶ道であり、メンテナーにふさわしいと自ら示す道にもなりうる、という見立てである3。tldrawとFlueがプルリクエストを閉じたのは、根拠を示した上での設計判断であり、失敗ではない。閉じた経路の代わりが機能するかどうかは、まだ観測されていない。

レビューの量を減らすという別案

分割も、受付停止も、届く単位の切り方を変える手だった。martinfowler.comに掲載された記事、2026年9月2日公開、著者Rachel Laycock(Thoughtworks CTO)は、切る場所ではなく、人間が検査する対象の量そのものを問うている4。

Laycockはこう書く。「エージェントが10倍のコードを生み出せたとしても、そのすべての行が結局はシニアエンジニアの検査を待つ列に並ぶのなら、私たちは10倍のエンジニアリング組織を作ったのではなく、大きな滞留と新しいボトルネックを作ったのだ」。全数を人間の検査に通す運用が残るかぎり、滞留は解消されないという指摘である。Laycockは分割や積み重ねには触れていない。彼女が答えではないと名指しするのは、人間のレビュアーのふりをするAIエージェントを置いて同じ工程を高速に回すことであり、それは儀式が存在する理由を問わずに儀式を自動化することだ、と書いている4。

Laycockが提案するのは「例外によるレビュー」である。人間によるレビューを残すのは、アーキテクチャの変更、セキュリティの境界、不確実性のある領域といった、リスクの高い変更に限る。それ以外については、こう書く。「フォーマットやリンティング、既知のセキュリティ上の問題、あるいは決定的にテストできる事柄についてコードをレビューしているのなら、それらは自動化すべきだ」。

Laycockが求めているのは、人間の判断をコードが出来上がった後の検査ではなく、もっと早い工程、ペアプログラミング、設計の議論、自動テスト、静的解析へ移すことである。

Laycockはこの主張の裏付けとして、他所の数値を引用している。Metaでは「人間が着地させた1差分あたりの実質的なコード行数が、1年で106%増加したと報告されている」とし、この「報告されている」という語自体がLaycockの言葉である。また、DX自身のデータとして「プルリクエストの中央値のサイズが64%増加している」とも述べている。いずれの数値も、Laycockが引用する出典の値であり、Laycock自身による測定ではない。

受け取る単位は、行数以外の境界で切る

受け取る単位は、行数以外の境界で切る。

GitHubの分割は、コードの中を切る。データ、API、接続、UXという層を置き、後の層が前の層に依存する順にPRを並べる。tldrawの受付停止は、コードの前を切る。受け取る単位を意図に置き、実装そのものは単位の外に残す。Laycockの提案は、行数ではなくリスクで切る。人間のレビューを残すのはリスクの高い部分だけで、残りは自動化に任せる。

三者が置く切れ目の位置は異なるが、共通する動きが一つある。行数や件数という量の尺度をやめ、それぞれが別の境界を切り口に選んでいることだ。届く仕事が判断できる大きさを超えたとき、まず問うべきは行数ではなく、その領域でどの境界が判断の単位になるかである。

出典5件

  1. Julia Muiruri, “Turn one giant AI-generated pull request into a reviewable stack”（github.blog engineering, 2026年8月4日公開）。1本の大きなAI生成PRを、依存関係の段に沿って複数の小さなPRのスタックへ分解する手順を示す。分割前の例は、データモデル(シードデータ含む)・検証つきAPIルート・クライアントUIをすべて含む1,000行超の差分（レビュアーの台詞としては「1,721行の変更」と置かれる）で、著者は「レビューが難しくなり、そのまま……放置される」と書く。分割後はL1データカタログ基盤、L2商品検索API、L3チャットからAPIへの接続、L4 UIと引用表示の4層スタックとなり、各PRは「レビュアーの頭の中に収まる大きさ」とされる。切る基準はデータ・API・接続・UXという層の依存順で、後の層が前の層に依存する。手順はgh extension install github/gh-stack、gh skill install github/gh-stackでツールを導入し、スタックの土台ブランチ(通常main)を決め、基盤層を最下位に依存順で層を並べたうえでgh init stack、gh stack add、gh stack push、gh stack submitを実行する。下の層に修正が入った際はgh stack syncが取得・上位ブランチの連鎖リベース・押し出し・PR状態の同期をまとめて行うとする。著者自身の注意点として、GitHubのWebUI上でスタックをリベースすると「コミット者がボタンを押した人物にリセットされ、結果として生まれるコミットは署名されず、署名付きコミットを求めるブランチ保護が掛かっていれば、そのワンクリックは静かに壊れる」ことを挙げ、gh stack rebaseをローカルで実行してからgh stack pushすることを勧めている。https://github.blog/engineering/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack/ ↩ ↩2

  2. tldraw, tldraw/tldrawリポジトリのCONTRIBUTING.md（このファイル自体には日付の記載がない）。「私たちは現時点でtldrawへの貢献を受け付けていません。このリポジトリではプルリクエストは無効になっています」と明記し、代わりに「issueを作成すること」を求める。理由として「issueはチームと提案された変更について議論する最善の場所であり、私たちはそのすべてに目を通しています」と説明する。コードを書きたい貢献者には「リポジトリをフォークし、issueの中で自分のブランチにリンクすること」を求め、詳しい経緯はissue #7695を参照するよう案内している。https://github.com/tldraw/tldraw/blob/main/CONTRIBUTING.md ↩ ↩2

  3. Richard MacManus, “PRs NOT Welcome: How Top AI Open Source Projects Are Managing Thousands of Contributors”（latent.space, 2026年9月1日公開）。Astroの自動トリアージがそのまま創業者Fred Schottによる新しいエージェントフレームワークFlueの作成につながったとし、Flueが外部プルリクエストをすべて自動でクローズしissueまたはdiscussionへ変換していること、Flueの貢献者ガイドが「通りすがりのAIスロップPR」を防ぐ目的を掲げていることを報じる。VercelのAI SDKが6月末に「1,000件を超えるopen issueと、800件近いプルリクエスト」を抱えていたこと、エージェントの仕組み導入から4週間後に「マージするPRの25〜35%を書き、issueの70〜80%を閉じている」とVercelが述べていることも報じる。tldrawの変更についても報じ、創業者Steve Ruizの発言として「私たちのコーディングの仕方の変化(より多くの議論、より多くのエージェント)、公開の場での貢献をめぐる社会的慣行、そしてコードセキュリティを取り巻く状況の変化に応じて下した、意図を持った判断」という言葉を引く。VercelのAI SDKとAstroは正式にプルリクエストを閉じてはいないが、コミュニティ貢献を減らす方向のエージェント駆動の仕組みを導入したと報じる。Schottの発言として「プロジェクトを絞り込み続けたとして、ある時点であなたと私が休暇に出たら、何が起きるのか」という後継者問題への懸念を引用し、Schott自身がこれですべてが解けるわけではないと述べていることも記す。外部PRのレビューが貢献者を育てて次のメンテナーを見つける経路になっていたと指摘する一方、FlueもtldrawもPRは受け付けないがissueとdiscussionは受け付けており、それが解を指しうるとも述べる。互いに話す量が増えることでコミュニティの側が互いを知り信頼するようになり、それが仲間から学ぶ道であり、メンテナーにふさわしいと自ら示す道にもなりうる、という見立てである。またAstroのSchottが、issueが処理能力より速く届く状態が5年続いたと述べたことも引く。https://www.latent.space/p/pr-not-welcome ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Rachel Laycock(Thoughtworks CTO), “Maybe We Shouldn’t Be Reviewing All This Code”（martinfowler.com, 2026年9月2日公開）。人間が全数のコードを検査し続けるかぎり滞留は解消されないと論じ、「エージェントが10倍のコードを生み出せたとしても、そのすべての行が結局はシニアエンジニアの検査を待つ列に並ぶのなら、私たちは10倍のエンジニアリング組織を作ったのではなく、大きな滞留と新しいボトルネックを作ったのだ」と書く。「例外によるレビュー」を提案し、人間レビューをアーキテクチャ変更・セキュリティ境界・不確実性のある領域などリスクの高い変更に限り、「フォーマットやリンティング、既知のセキュリティ上の問題、あるいは決定的にテストできる事柄についてコードをレビューしているのなら、それらは自動化すべきだ」と述べる。人間の判断をコード完成後の検査ではなくペアプログラミングや設計セッション、自動テスト、静的解析といったより早い工程へ移すことを求める。分割やスタックには触れておらず、答えではないと名指しするのは、人間のレビュアーのふりをするAIエージェントを置いて同じ工程を高速に回すことである。裏付けとして自身が測定したのではない数値を引いており、Metaでは「人間が着地させた1差分あたりの実質的なコード行数が、1年で106%増加したと報告されている」とし「報告されている」の語自体がLaycockの言葉であること、DX自身のデータとして「プルリクエストの中央値のサイズが64%増加している」ことを引用する。いずれもLaycockが引用する数値であって自身が測定したものではない。https://martinfowler.com/rachels-ramblings/code-review.html ↩ ↩2 ↩3

  5. git-spiceドキュメント（継続的に更新されるドキュメントサイト。2026年9月8日参照）。スタックしたGitブランチを管理し、トランクブランチとの同期を保つこと、依存するブランチの再スタック、変更がマージされた際のブランチの付け替えを自動化すると述べる。GitHubのほかBitbucket、Gitea、Forgejo、Azure DevOps、GitLabにも対応するとしている。https://abhinav.github.io/git-spice/ ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。