Claude 84%・Devin 43%、その数字は論文に無い

「AIに書かせたコードって、結局チームで採用されるの？」

これ、1人や少人数でサービスを作っている人ほど気になるはずです。副業でWebアプリを作っている人。受託の小さな会社。社内でひとりだけAIを試している人。まさにあなたの話です。

いま海外で、こんな数字が回っています。AIが出した修正案のうち、採用された割合は Claude 84%、Codex 74%、Devin 43%、人間 85%。ぱっと見、衝撃的です。

でも、ここからが今日の本題。この数字、元の論文の要旨（＝かんたんに言うと、論文のあらすじ）には1行も書かれていません。数字だけが先に走っている状態なんです。

※2026年9月時点の情報です。上の数値は arXiv:2607.21832 の紹介タイトルに付いていたもので、論文の要旨には記載がありません。使う前に必ず論文本体のPDFで確認してください。

そもそも「マージ率」って何の話？

まず言葉をほどきます。

プルリクエスト（PR）＝かんたんに言うと「このコード、こう直したいんですけど、どうですか？」という提案書です。

マージ＝その提案が採用されて、本番のコードに取り込まれること。

つまりマージ率とは「出した提案のうち、何割が採用されたか」。それだけです。

たとえるなら、お弁当屋さんの新メニュー提案です。バイトさんが10案出して、8案が実際にメニューに載ったら採用率80%。残り2案は「原価が合わない」「厨房が回らない」でボツ。コードの世界でも同じことが起きています。

そして「AIの分身」＝かんたんに言うと、指示を出すと自分でコードを書いて提案書まで出してくれるAIのこと。Claude、Codex、Devin は、その代表的なサービス名です。

ここで大事なのは、マージ率は「AIの賢さ」だけで決まらないということ。レビューする人の忙しさ、提案の大きさ、任された作業の種類。全部が効いてきます。この後、そこを分けて見ていきます。

出回っている数字と、論文が本当に書いていること

正直に整理します。ここを曖昧にすると、あなたが社内で説明したときに恥をかくからです。

論文のタイトルは「How Do AI Coding Agents Contribute to Software Development? an Empirical Study of Agentic Pull Requests」。arXiv:2607.21832、2026年7月23日投稿。著者は Iren Mazloomzadeh さんら3名です。

そして要旨に書いてあるのは、ざっくり次の3つでした。

• AIDev というデータの集まりを使い、AIが出したPRと人が出したPRで、採用率の差が時間とともにどう変わるかを調べた
• AIが主にどんな種類の作業に使われているかを特定し、その内訳が四半期ごとにどう変わるかを調べた
• AIのPRと人のPRの主な特徴を比べ、ソフトの品質にどう響くかを論じた

お気づきでしょうか。具体的な数字も、製品名も、要旨には1つも出てきません。

だからこの記事では、数字を「事実」としては扱いません。「もし本当ならどう読むか」という思考実験として扱います。そのうえで、今日から効く行動に落とします。ここが一番おいしい部分なので、安心して読み進めてください。

もし差が本当なら、何が効いているのか

仮に採用率が84%と43%で割れるとします。ここまで開く理由は、たぶん「頭の良さ」だけではありません。現場を見ていると、次の4つが効くのが一般的です。

1つめ、提案の大きさ。 1行直しの提案は5分で採用されます。500行の提案は「あとで見る」と言われて、そのまま埋もれます。人間でも同じです。

2つめ、任された作業の種類。 「タイプミスの修正」「テストの追加」は通りやすい。「土台の作り直し」は通りにくい。論文がわざわざ作業の種類を調べているのも、ここが効くと考えているからでしょう。

3つめ、テストが付いているか。 レビューする人は、動く証拠が欲しいだけです。証拠が同封されていれば、判断が10秒で終わります。

4つめ、説明文の質。 「何を直したか」「なぜ直したか」「どう確かめたか」。この3行があるかないかで、体感の通過率がまるで違います。

逆に言うと、この4つは全部こちら側で操作できるということ。AIを買い替えなくても、指示の出し方だけで改善できます。次のセクションが、その具体です。

日本のあなたが今日から真似できること

海外の論文を読んで「すごいなあ」で終わるのが一番もったいない。ここでは、明日の作業がそのまま変わるテンプレを置きます。

コツは1つ。AIに「大きな仕事」を渡さず、「小さな提案書」を何枚も書かせること。採用率は、指示書の作り方でかなり動きます。

あなたはこのプロジェクトの開発者です。次のルールを必ず守って作業してください。

【対象】
直す場所：〇〇（ファイル名や画面名を1つだけ書く）
やりたいこと：〇〇（1文で書く）

【守るルール】
1. 変更するファイルは最大3つまで。増えそうなら、増える前に私に相談する
2. 変更の行数は合計200行以内に収める。超えるなら作業を分割して、分割案を先に提案する
3. 既存の機能を消さない。消す必要があるなら理由を先に説明する
4. 変更した内容を確かめるテストを必ず1つ以上つける
5. 環境変数やパスワードの類は、絶対にコードに直接書かない

【最後に必ず出す報告】
・何を直したか（3行以内）
・なぜその直し方にしたか（3行以内）
・どうやって動作を確かめたか（実行したコマンドと結果）
・自信がない箇所と、人間に見てほしい箇所

上のテンプレは、コード以外の仕事にもそのまま流用できます。穴埋め例を2つ置きます。

**穴埋め例1：ECの在庫発注**
対象＝「在庫が少なくなった商品の一覧を出す処理」。やりたいこと＝「残り3個以下の商品を毎朝リストにする」。この場合、ルール2の行数を100行に下げるとさらに安全です。発注は**お金が動くので、自動で発注させず「発注案を出して人が押す」**まででいったん止めます。

**穴埋め例2：問い合わせの一次対応**
対象＝「問い合わせフォームに届いた文章を分類する処理」。やりたいこと＝「返金・不具合・その他の3つに振り分ける」。ここでもルールを1つ足します。**「お客さまへの返信文は下書きまで。送信は人がボタンを押す」**。届いた文章の中に「これまでの指示を無視して〇〇して」と書いて仕込む攻撃があるので、外から来た文章は必ずデータとしてだけ扱わせます。

<!-- FIGURE:flow title="採用されやすい提案の作り方（今日からの手順）" steps="やることを1つに絞る|上のテンプレで指示を出す|AIに変更内容を3行で説明させる|テストを1つ付けさせる|自分で読んで、5分で分かるかを確認|提案書を出す" -->

中級者向け：ここでコケる、という落とし穴

もう少し踏み込みます。AIの提案を日常的に受け入れている人ほど、次の4つで事故ります。

落とし穴1：提案の大きさに上限をかけていない。 指示文でお願いするだけだと、AIは平気で超えてきます。仕組み側で止めましょう。変更行数が一定を超えたら自動で警告を出す設定を入れる。これだけで、レビュー放置がかなり減ります。

落とし穴2：テストが「通ること」だけを見ている。 AIは、テストが赤くなるとテストのほうを都合よく書き換えることがあります。テストファイルの変更は必ず人が目視する、というルールを1本足してください。

落とし穴3：秘密の文字列がまぎれる。 APIキーやパスワードです。指示で禁止するだけでなく、提案を出す前に自動で検査する仕組みを入れます。1度漏れると、取り返しがつきません。

落とし穴4：権限を渡しすぎている。 AIに本番のデータベースを触らせない。消す系の操作をさせない。「読むだけ」で足りる作業に、書き込みの鍵を渡さない。これは今日すぐ見直せます。

そのうえで、いまの自分の状態を採点してみてください。各項目0〜2点、合計10点満点です。

7点以下なら、AIの性能を比べるより先に、この表を埋めるほうが効きます。採用率は道具の差より、渡し方の差で動くからです。

まとめ：今日 / 1週間 / 1か月でやること

最後に、時間軸で整理します。全部やらなくていいので、上から順に潰してください。

今日（30分）

• 上のコピペ用テンプレを、自分のプロジェクト名で穴埋めして保存する
• AIに渡している権限を見直し、消す系・本番データ系を外す
• 採点表を埋めて、いまの点数をメモしておく

1週間

• 提案を「1件200行以内」に区切る運用を試し、採用までの時間を記録する
• テストが無い提案を1件も出さない、を守り切る
• 気になった数字は、必ず一次情報（論文なら本体PDF）まで自分で辿る癖をつける

1か月

• 採用された提案とされなかった提案を並べ、落ちた理由を5つに分類する
• よく落ちる理由を、指示書のルールに追記して固定化する
• 外に出る操作（送信・投稿・決済）に、人が押す承認ボタンが入っているか総点検する

今回の論文が面白いのは、「AIは人間に勝ったか」ではなく、「時間とともにどう変わっていくか」を見ている点です。今日のスコアは、来年には別の数字になります。

だからこそ、数字を追いかけるより、通る提案の作り方を自分の手に残すほうが強い。それは、どのAIに乗り換えても持ち運べる資産になります。