GitHub、Copilotコードレビュー改善の舞台裏を公開。高性能なツールがレビューを悪化させた理由

道具を良くしたら、AIのレビューが下手になった

GitHubが公式ブログで、めずらしい失敗談を語りました。公開日は2026年7月11日。主役はAIレビュー機能のCopilot code reviewです。

Copilot code reviewは、プルリクエスト(コードの変更をチームに提案する仕組み)をAIが点検する機能です。変更点を読んで気になる箇所を指摘し、人間のレビュー担当の負担を軽くします。

記事の題名は強烈です。「より良いツールが、Copilotのコードレビューを悪化させた」。道具を良くしたら、結果はむしろ悪くなったとGitHub自身が認めています。

普通の道具なら、性能が上がれば仕事の質も上がります。ところがAIエージェント(自分で手順を選んで動くAI)では、逆のことが起きました。

自社製品の失敗をここまで率直に語る例は、多くありません。だからこそ、この記事はAIを使う人みんなの教科書になっています。

立て直しの柱は、Unix流の小さな道具

GitHubが選んだ立て直し策は、意外なほど地味でした。Unix流(1つのことをうまくやる小さな道具を組み合わせる設計思想)の共有コード探索ツールへの移行です。

「共有」も見逃せない言葉です。レビュー専用に作り込んだ道具ではなく、共通の探索ツールを使う形にしました。

もう1つの柱が、プルリクエストにある証拠を軸にした手順の組み替えです。そこには、誰が何をどう変えたかという記録が残っています。

AIを遠くまで探索させず、目の前の証拠に集中させる。この組み替えで、レビューにかかるコストは下がったとGitHubは説明しています。

現場を離れる探偵は、事件を解けない

例えるなら、事件現場の探偵に街全体の地図と万能鍵を渡したような話です。どこへでも行けるせいで、足元の手がかりを調べる前に街を歩き回ってしまう。高性能なツールは、AIをそんな探偵にしてしまいました。

便利な道具を増やしたのに、かえって仕事が遅くなった経験はありませんか。机の上のアプリが増えるほど、目の前の1枚に集中できなくなる。あの感覚に近い現象です。

だからGitHubは、探偵を現場に縛り直しました。使う道具は小さく、見る場所はプルリクエストの中。賢くするのではなく、迷わせないという発想の転換です。

料金や使い方は変わるのか

結論から言うと、今回の記事は開発の裏側の解説です。新機能の発表ではありません。提供時期や料金、対象条件の変更は発表に書かれていません。

Copilot code review自体の使い方は、公式ドキュメントで公開されています。プルリクエストの画面から、AIにレビューを依頼できる仕組みです。

そしてこの話は、エンジニアだけのものではありません。資料の下書きや調べものなど、AIに任せる仕事は職場に広がっています。任せ方の原則は、今回とまったく同じです。

・資料の要約を頼むなら、読ませる文書を絞る ・調べものを頼むなら、参照する範囲を先に決める ・チェックを頼むなら、見てほしい部分だけを渡す

遠くまで自由に探させるより、証拠のそばに置く方がAIは力を発揮します。

賢いAIより、迷わない段取り

AI活用の成果を分けるのは、モデルの賢さだけではありません。どんな道具を渡し、どこを見せるかという段取りが結果を左右します。GitHubの失敗談は、その生きた証拠です。

この原則は、開発の現場に限りません。人に仕事を頼むときと同じで、AIにも良い頼み方があります。

AIがうまく働かないとき、疑うべきは能力より渡し方かもしれません。材料を絞り、見る範囲を決めてから任せる。足し算ではなく引き算が、AIを賢くするのです。