エージェント

プルリクエストを開くのはエージェント

GitHubによると、プルリクエストの40パーセント超はエージェントが始めています。希少な仕事はもはやコードを書くことではなく、仕様を定め、レビューし、テストし、責任を持つことです。

  • 分析
  • 2026年11月8日
  • 5分で読めます

10月28日、GitHubはプラットフォーム全体の活動をまとめた年次レポートOctoverseを公開しました。その中で目を引く一文があります。2026年9月までに、GitHub上のプルリクエストの40パーセント超がエージェントによる最初の下書きから始まるようになり、3月の17パーセントから増えたというのです。9月だけで1億1000万件のプルリクエストにあたります。同じ日、GitHubはカンファレンスUniverseで、Copilot Projectsをパブリックプレビューとして公開し、Agentic Workflowsを一般提供しました。

その1週間後、Metaは、複数のコーディングエージェントを同時に動かすために作られたスタートアップConductorを買収しました。これらのニュースは同じ方向を指しています。ソフトウェアづくりにおいて、コードを書くことはもはや希少な部分ではありません。希少なのは、仕様を定め、レビューし、テストし、責任を負うことです。

GitHubが数えたもの

これはGitHub自身が自社のプラットフォームで測った数字であり、そのつもりで読むべきです。Octoverseは、最初の下書きがGitHubの検出できるコーディングエージェントから来たプルリクエストを、エージェントが始めたものとして数えています。レポートはこの指標を「すべてのエージェントの利用が検出されるとは限らないため、下限」と呼んでいます。対象は公開と非公開の両方のリポジトリで、過去の年の数字も同じ基準で計算し直されています。

レポートによると、エージェントのプルリクエストは、いまやほかのものと少なくとも同じくらいの頻度でマージされています。2月には、エージェントが関わったプルリクエストの83パーセントが2週間以内にマージされ、エージェントが検出されなかったものでは約86パーセントでした。9月までに、エージェントの側は90パーセントに達しています。範囲も広く、約87パーセントが複数のファイルを変更しており、ほかのものでは79パーセントです。私たちの読み方では、マージが示すのはレビュアーが変更を受け入れたことであり、その変更が正しかったことではありません。

1人あたりのエージェントが増える

GitHubが同じ日に投入した製品は、この割合が今後も伸び続けることを前提にしています。Copilot Projectsは、複数のリポジトリにまたがる仕事に、その文脈、エージェント、成果をまとめる1つの場所を与えます。目標を記述すると、Copilotがエージェントを並行して動かし、「必要なときには確認を求め」、レビュー用のプルリクエストなどの成果を持ち帰ります。Agentic Workflowsでは、チームがIssueのトリアージや失敗したビルドの分析といったタスクをMarkdownで記述し、コーディングエージェントにGitHub Actionsの中で実行させることができます。初期設定の権限は読み取り専用で、提案された変更を適用する前にスキャンする別のジョブも用意されています。

Universeに関するGitHubの投稿は、この分業を一文で表しています。「開発者が方向を定め、判断を下し、リリースされるものに責任を持ち続ける」。InfoWorldが引用したアナリストは、それが実際に何を意味するのかを具体的に説明しました。「たとえば、10のエージェントのセッションを並行して動かせば、レビューが必要なプルリクエストが10件生まれる可能性がある」と、コンサルティング会社KanerikaでAI開発を率いるAmit Kumar Jena氏は語っています。

70パーセントは完了ではない

GitHubの外で行われた新しいテストが、そのレビューを省けない理由を示しています。10月26日、Alibabaと複数の大学の研究者がCo-Design Benchを公開しました。26'314件の実際のユーザーのコーディングセッションから抽出した273のタスクで、それぞれが専門家の書いた非公開の受け入れ基準、合計2'331項目に照らしてチェックされます。同じエージェントの構成で動かした10のモデルのうち最も強いモデルは、タスクあたり平均で基準の69.9パーセントを満たしましたが、完全に満たしたタスクは26.4パーセントにとどまりました。11月8日にこの研究を報じたThe Decoderは、コーディングエージェントはいまも「4つのタスクのうち3つ近くで、人による後片付けが必要」だと書いています。

この研究には限界があります。各タスクは1つの固定された依頼なので、エージェントは途中で質問したり修正を受けたりできませんでした。採点は誤りうるAIの審査員が行い、著者の何人かはAlibabaの所属で、同社のQwenモデルもテスト対象に含まれていました。それでも、この研究が測っている隔たり、つまり要件の大半と要件のすべてとのあいだの隔たりは、まさにレビュアーが埋めるために存在する隔たりです。

優れたチームがいま行っていること

そのどれにも、新しいツールよりも、昔ながらの規律をより厳格に適用することが必要です。まずは仕様から。エージェントが変更の下書きを作る場合、書かれたタスクこそが本当のソースであり、Jena氏は「定義が不十分なタスクは、実行の繰り返し、手戻り、AIクレジットの消費増につながりかねない」と警告しています。Co-Design Benchが受け入れ基準を最初に定めるように、エージェントが始める前に、何をもって完了とするかを書き留めておきましょう。

変更は、読める程度に小さく保ちましょう。GitHubによると、関連する仕事をより小さな変更に分け、順番にレビューするスタックド・プルリクエストは、プレビューの開始から2か月後の9月までに、264'000人を超える開発者に使われました。テストを関門にしましょう。変更はテストに通るまで人のもとに届くべきではなく、テストそのものこそ最も入念なレビューに値します。自分のテストを編集できるエージェントは、何でも通せてしまうからです。

最後に、人を指名すること。リリースされるすべての変更には、それを承認し、説明できる誰かが必要であり、その誰かがエージェントであってはなりません。CIOへのJena氏の助言も同じです。「エージェントが生成したプルリクエストは、マージする前に人の承認を必須とすること」。

ツールは止められることがある

Conductorの買収は、もう少し目立たない教訓を加えます。TechCrunchは11月4日、Metaが2024年創業のこのスタートアップを買収したと報じました。Conductorのエージェントチームは、AnthropicやOpenAIといったラボのエージェントを使い、「ソフトウェアエンジニアが、プロジェクトの切り分けられた別々の部分に、協調して取り組めるよう設計されて」います。Metaは買収を認めましたが、条件は明らかにしていません。

スケジュールはConductor自身の告知に示されています。新規登録は11月4日に停止され、クラウドのワークスペースは11月13日に読み取り専用になり、11月20日にはクラウド上のユーザーデータの削除が始まります。顧客がそこに保存しているものを書き出すための期間は16日間です。デスクトップアプリは当面動き続け、2027年初めに段階的な終了が始まります。Conductorは、ユーザーデータを販売したことも学習に使ったこともないとしており、書き出しとローカルアプリへの移行の手段を提供しています。

ここに悪意をうかがわせるものは何もありません。示されているのは、エージェントを動かす層がまだどれほど新しく、不安定かということです。エージェントのワークスペースやチャットを預かるサービスが、数週間のうちに買収され、閉鎖されることもありえます。大切なものは、自社が管理する場所に置きましょう。コードとその履歴は自社のリポジトリに、仕様と判断はその隣に書き留めて。そして、どのベンダーが提供するエージェントであれ、必ず通らなければならないテストを用意しておくことです。

私たちの立ち位置

私たちのアプリプラットフォームWerkは提供中で、この分業の上に築かれています。私たちが構築し、信頼するフレームワークの上でAIがコードの大半を書き、何を作るかを決め、使い心地をデザインし、すべてのリリースをレビューするのは人です。そして、すべてのリリースはテストされます。コードはお客様のものであり、その下でプラットフォームは成長し続けます。私たちが目指す次のステップは、定型的な変更や修正を、リリース前にテストとレビューを経たうえで、エージェントが自らリリースすることです。それが機能するのは、仕様の策定、テスト、レビューがすでに整っている場合だけです。