新しいスマホに買い替えたのに、前より写真を撮らなくなった。多機能な家電を買ったのに、結局使うボタンは2つだけ。便利になるはずの道具が、かえって私たちを迷わせる——そんな経験は、誰にでもあるのではないでしょうか。

実はこれと同じことが、いま最先端のAIの世界でも起きています。GitHub（世界中のプログラマーが書いたプログラムを保管・共有する、いわば「ソフトウェア開発の巨大な共同作業場」を運営する会社です）が2026年に公開した記事のタイトルは、そのものずばりでした。

「Better tools made Copilot code review worse.（より良いツールが、Copilotのコードレビューを悪化させた）」

AIに高性能な専用道具を持たせたら、仕事の質がむしろ下がってしまった。そしてそれをどう立て直したのか——。この記事では、GitHubが公開したこの興味深い「失敗と改善」の話を入り口に、AIとの付き合い方、さらには私たち自身の仕事の道具選びにも通じる教訓を考えていきます。

なお、本稿は執筆時点で元記事の本文全体を直接確認できていません。GitHubが公開しているタイトルと公式の紹介文（記事の要約）にもとづいて書いており、そこから読み取れない詳細は「未確認」と明記します。

何が起きたのか：GitHubが公開した"逆説"

まず前提となる言葉を、専門知識がない方向けに整理します。

• コードレビュー：プログラマーが書いたプログラムの変更を、別の人が公開前にチェックする作業です。文章でいえば「原稿の校閲」にあたります。間違い（バグ）や読みにくさを、世に出る前に見つけるための工程です。
• GitHub Copilot（コパイロット）：GitHubが提供するAIアシスタントです。プログラムを書く手伝いだけでなく、このコードレビュー（校閲）自体をAIが代行する機能も持っています。
• プルリクエスト：「この変更を取り込んでください」というプログラマーからの提案書のようなものです。コードレビューは、この提案書に対して行われます。

GitHubの公式紹介文によれば、この記事の主題は次のとおりです。

Copilotのコードレビューを、共通のUnixスタイルのコード探索ツールへ移行したことで、エージェントの作業の流れをプルリクエストの証拠（evidence）を中心に組み立て直し、レビューのコストを削減した。

タイトルと合わせて読むと、こういう経緯だったと理解できます。GitHubはAIレビュアーの性能を上げようとして「より良いツール」を与えたところ、結果はむしろ悪化した。そこで方針を転換し、昔ながらのシンプルな探索ツールに共通化し、AIが「証拠」にもとづいてレビューする流れに作り直したことで、ようやく改善した——という話です。

「Unixスタイルのツール」というのは、プログラマーの世界で50年近く使われてきた道具の設計思想を指します。代表例は「grep（グレップ）」という、ファイルの中から特定の文字列を探し出すだけの小さな道具です。Unixの道具は「1つの道具は1つの仕事だけを、確実にこなす」という考え方で作られており、多機能な統合ツールとは対照的です。料理でいえば、何でもできる高級調理家電ではなく、よく研がれた包丁とまな板のような存在だと思ってください。

つまりGitHubの結論は、AIレビュアーには専用の高機能ツールより、単純で予測しやすい定番の道具を持たせたほうがうまくいった、ということになります。

ただし注意点があります。「悪化」が具体的にどんな症状だったのか（見当違いの指摘が増えたのか、重要な見落としが増えたのか、時間がかかったのか）、コスト削減が何％だったのかといった詳細な数値は、公開されている紹介文からは読み取れません。この点は未確認です。詳細を知りたい方は、末尾の参考資料から元記事をご覧ください。

なぜ道具を増やすと、AIはかえって迷うのか

「高性能な道具で悪化する」というのは直感に反しますが、AIエージェント（自分で道具を選び、複数の手順を踏んで作業を進めるタイプのAI）の仕組みを知ると、腑に落ちるものがあります。ここからは元記事の主張ではなく、AIエージェント開発で広く知られている一般的な背景として、筆者の解説を書きます。

第一に、道具が増えるほど「選ぶ」という仕事が増えます。 AIは作業のたびに「いま、どの道具を使うべきか」を判断しています。似たような道具が10個あれば、その判断を毎回10択で行うことになり、選び間違いも起きます。人間でも、リモコンのボタンが40個あると、よく使う3個しか押さなくなるのと同じです。

第二に、専用ツールは「便利すぎる要約」を返しがちです。 高機能なツールは、AIのために情報を整理・加工して渡そうとします。しかし加工された情報は、元の情報から何かが抜け落ちています。レビューという仕事は「実際に書かれているものを自分の目で確かめる」ことが命ですから、加工済みの要約に頼ったAIは、実物を見ずに校閲をする校閲者のようになってしまいます。GitHubの紹介文にあった「プルリクエストの証拠を中心に組み立て直す」という表現は、まさにここへの対処だと読めます。つまり、AIの指摘の一つひとつを、変更内容という動かぬ証拠に紐づけさせる方向への転換です。

第三に、シンプルな道具は結果を検証しやすいという利点があります。 grepのような単純な道具は、同じ入力には必ず同じ結果を返します。AIがどんな手順で結論に至ったのかを、後から人間が追いかけて確かめられるのです。多機能なブラックボックスの道具では、この「追試」が難しくなります。

まとめると、AIに仕事を任せるときの道具選びは「高機能かどうか」ではなく、**「AIが迷わず選べて、生の情報に触れられて、後から人間が検証できるか」**が大事だ、ということです。

私たちの仕事にも当てはまる教訓

この話は、プログラマーでない方の仕事にもそのまま当てはまると思います。

たとえば、チームに新しく入った人（あるいはAIアシスタント）に仕事を任せる場面を想像してください。よかれと思って10種類の社内ツールと分厚いマニュアルを渡すより、「この共有フォルダと、この検索方法だけ覚えてください。判断に迷ったら、必ず元の資料を直接見てください」と伝えたほうが、立ち上がりが速く、間違いも減る——多くの方が経験的に知っていることではないでしょうか。

ポイントは3つに整理できます。

1. 道具は「足す」より「絞る」。 選択肢を減らすことは、手抜きではなく設計です。
2. 要約より原本。 大事な判断は、加工された情報ではなく、元の資料（証拠）にあたる習慣をつける。AIに仕事を頼むときも「根拠になった箇所を示して」と求めると、精度の感覚がつかめます。
3. 後から検証できる手順を選ぶ。 結果だけでなく「どうやってその結論に至ったか」を追える仕事の進め方は、AI時代にますます価値が上がります。

GitHubのような、AI開発の最前線にいる企業ですら「一度ツールを盛りすぎて失敗し、シンプルに戻して改善した」と公表しているのです。私たちが自分の仕事でAIを試すときに、最初から完璧な道具立てを目指す必要はない、と心強く受け取ることもできます。

注意点：この記事で「未確認」のこと

本稿の性質上、以下の点を明示しておきます。

• 元記事の本文全体は未確認です。本稿の事実関係は、記事タイトルおよびGitHubが配信している公式の紹介文にもとづいています。
• レビューが「悪化した」ことの具体的な症状や度合いは未確認です。
• 「レビューコストの削減」の具体的な数値（削減率や金額）は未確認です。
• 移行先のツール群の正確な構成（grepそのものを使ったのか、類似の自社ツールなのか）は未確認です。「Unixスタイルの共通コード探索ツール」という紹介文の表現の範囲で記述しています。
• 「なぜ道具を増やすとAIが迷うのか」の節は、元記事の主張の引き写しではなく、AIエージェント開発一般の知見にもとづく筆者の解説です。

正確な詳細は、必ず下記の一次情報をご確認ください。

まとめ

GitHubが公開した「より良いツールがCopilotのコードレビューを悪化させた」という話は、AIの性能向上が「道具を増やすこと」では達成できない場合がある、という示唆に富んだ事例です。公式の紹介文によれば、GitHubはUnixスタイルのシンプルな共通ツールへ移行し、プルリクエストという「証拠」を中心にAIの作業の流れを組み立て直すことで、レビューコストの削減にたどり着きました。

高機能を足すのではなく、迷いなく使える定番の道具に絞り、根拠にあたる手順を整える。AIに限らず、人に仕事を任せるときの普遍的な知恵が、最先端のAI開発の現場で再発見された——そんなふうに読める話です。ご自身の仕事でAIを使うときも、「道具を盛る」前に「流れを整える」ことから始めてみてはいかがでしょうか。

参考資料

• Better tools made Copilot code review worse. Here’s how we actually improved it.（The GitHub Blog）: https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/ （本稿執筆時点で本文全体は未確認。公開されている紹介文にもとづき言及しています）