AI コーダーは『前の人の仕事』を引き継げるか

『ベンチマーク』って、要するに AI の成績表みたいなもの？現実とは別の理想的な条件で測ってるってこと？

ベンチマークはそういう側面もあるんですが、正確には『採点の場』というより『競走のトラック』に近いと言えそうです。 選手が実力を競う時、みんなが同じ平坦なトラックで走ると、速さの差が明確に出ます。でも坂道だらけのコースで測ったら、実力とは別の要因（得意な地形か、運か）が影響してきてしまう。だからベンチマークはわざと単純にしておく。AI の実力を純粋に比較するために、背景の余計な変数を全部排除するんです。 ここが核心なんですが、この戦略には弱点がある。現実の開発現場は『汚い』のが当たり前。前の人の失敗が積み重なった状態で、その中から答えを探す必要がある。それって、きれいなトラックでの速さとは全く別のスキルなんですよね。まるで『本番の試合には坂道やコーナーがあるのに、練習は直線走だけ』みたいな。 記事の指摘は、ベンチマークが完全に悪いという話ではなく、『この測り方だけでは不十分だ』という警告に見えます。現実での使えなさが、テストの綺麗さに隠れていたわけです。

プログラマーの仕事をする AI が『前の人の不完全な仕事』に弱いなら、自分たちの職場で AI に仕事を任せるときも、引き継ぎの質が結果に大きく影響するってことか。

その通りに見えます。つまり AI コーダーの実力は、渡されるコードの状態に左右される。きれいな状態なら 80 点でも、バグが混じってると 30～40 点に落ちてしまう。 だから、職場で AI に仕事を任せるなら、前置きが重要になってくる。「ここまで完成してます」「この部分にはこういうバグがありそうです」という情報を、できるだけ正確に伝えられるかどうかが、AI の成果を大きく左右する。 ここで厄介なのは、人間の開発者なら「なんか変だな」と違和感で気づけることも、AI は『これが完成状態』と思い込んでしまう点です。引き継いだ不完全さを『仕様の一部』だと解釈してしまう。だから引き継ぎ側の人間が、単に「ここ直して」と言うだけじゃなく、「ここはこういう理由でまだ完成してない」と前置きしないと、AI は空回りしてしまう可能性がある。 結果として、AI を効率的に使うには、引き継ぎを整理する作業そのものが新しい負担になるのかもしれません。

今まで AI コーダーのテストが『白紙からのスタート』ばっかりだったのって、単に測りやすかったからなの？それとも『理想的な環境での力を知りたかった』から？

測りやすさと理想主義、多分どっちも混じってるんだと思います。ただ、より根本的には「AIの能力を見たい」という欲求が、知らず知らずのうちに『好都合な環境設定』を選ばせたのかもしれません。 ベンチマークテストって、本来は「この製品・技術はどこまで使えるのか」を客観的に調べるものです。でも AI コーダーが登場した時点では、みんなが「AI は本当にコード書けるのか」という基礎的な問いを持ってた。だから白紙から始めることで「純粋な生成能力を測ろう」という意図があったはず。不完全なコードが入ってくると、どこまでが AI の失敗で、どこまでが前の開発者の責任かが曖昧になってしまう。その『ノイズ』を避けたかったんでしょう。 でも同時に、測りやすさという現実的な都合もあります。白紙なら評価基準がシンプルです。一方、壊れたコードを引き継ぐテストは設計が難しい。どんな不具合を混ぜるのか、どのレベルの混乱を想定するのか。その決定が恣意的に見える可能性もある。 結果として、テストが「理想的な環境での力」を測るものになってしまったわけですが、それは意識的な選択というより、問題の立て方そのものが『きれいな環境を前提にしていた』のかもしれません。

これって『AI が前提条件に引きずられて、そこから抜け出す判断ができない』って話だよね。人間のバグ修正でも似たことって起きる？

人間も確実にやります。むしろ『前提条件に引きずられる』のは人間の方が深刻かもしれません。 開発現場では「このコードはこういう設計で書かれてるんだ」と思い込むと、その枠組みの中でしか考えなくなる。バグの原因が実は設計そのものにあるのに、「この設計の中での最適解を探す」という袋小路に入ってしまう。経験の長い開発者ほど、一度納得した前提を疑いにくくなる傾向さえある。 ただ、人間とAIで決定的に違う点がありそうです。人間は「違和感」に気づくことができる。コードを見てて「あ、ここ変だな」という曖昧な感覚が、時に設計の根本的な誤りを指摘させる。でもAIは記事で言われてるように、不完全な状態を『完成状態の一部』として受け入れてしまう。違和感ではなく整合性で判断しているから、一度納得させられたら、そこから逃げにくい。 むしろ問題は、AIがこの『人間的な思い込み』を、人間より徹底的にやってしまうことなのかもしれません。

性能が 20～50% 落ちるってことは、逆に言うと『不完全な状態から始まる仕事の方が、意外と人間の方が得意な領域』ってことなのかな。

その通りかもしれません。人間の開発者は、不完全な状態を「読む」のに長けているんですよね。 バグや未完成のコードを前にしたとき、人間は「なぜ前の人はここで止めたのか」「何が足りないのか」という意図を推測しながら進めます。コードの行間を読む能力です。一方、AI は記事の分析にあるように、残されたコードを「完成状態」として受け入れてしまう。既に存在するパターンに合わせようとする習性が、ここでは仇になっている。 興味深いのは、これが単なる「AI の弱さ」ではなく、AI と人間の学習方式の違いを浮き彫りにしているということです。AI は大量のきれいなコード例から最適解を学ぶ。だから不完全さが混在すると、その「ノイズ」をどう扱ったらいいのか判断できなくなる。人間は逆に、不完全さの中に「ストーリー」を見出す。「なぜこうなった」という文脈理解が武器になる。 開発の現場では、むしろ「汚さの中での意思決定」こそが価値なのかもしれません。