見出し画像

AIに頼むより自分でやったほうが速いという罠

「AIって遅いですよね。結局、自分でやったほうが速いです」。

AIへの批判として、これはよく聞きます。そして、たいていの場合は本当だろうと思っています。強がりでも思い込みでもなく、その人の手元では実際にそうなっている。

実測もあります。METR が経験豊富なOSS開発者16人に246件の課題を割り当てたランダム化比較試験では、AIの使用を許した条件のほうが完了までに19%長くかかりました。面白いのは、同じ開発者たちが事後に「20%速くなった」と申告している点です。体感と実測が、逆を向いています。

ただ、一つだけ気になることがあります。その人たちはAIに、何を渡したのでしょうか。

説明の手間は、仕事の大きさに比例しない

設定ファイルの一行を直したいとします。

自分でやるなら、ファイルを開いて、その行を書き換えて、保存する。十秒ほどでしょうか。これをAIに頼むとなると、どのファイルの、どの行の、何を、何に変えるのかを言葉にしなければなりません。書いているうちに、自分で直したほうが速かった、と気づきます。

そのとおりだと思います。

ただ、ここで比べられているのはAIの速度ではありません。伝えるコストと、作業そのもののコストです。そして伝えるコストは、仕事の大きさにあまり比例しません。一行を直す指示も、機能を一つ作る指示も、書く文章の長さはさほど変わらないからです。

だとすると、作業を小さく切って渡すほど、伝えるコストの比率は上がっていきます。極限まで小さく切れば、必ず割に合わなくなる。これは算数の話であって、AIの性能とは関係がありません。

分母を自分で小さくしておいて、比が悪いと言っている。 そういう構図に見えます。

METRの研究も、遅くなった原因を分析しています。挙がった要因のうち二つは、AIに暗黙のリポジトリ文脈がないことと、開発者自身がそのリポジトリに習熟していることでした。対象は平均100万行を超える成熟したコードで、開発者は平均5年そこに関わっています。頭の中にあって言葉になっていない知識が、いちばん多い場所です。

見覚えのある光景

手順を細かく指定して、判断の余地を残さず、成果物の形を先に決めておく。

これは、人間の組織でも見る光景です。仕事を手放せない管理職の振る舞いに、よく似ています。

その人が言う「自分でやったほうが速い」も、目の前の一件だけを見れば事実です。だから手放さない。手放さないので、その部下が大きな仕事を引き受けられるかどうかは、いつまでも確かめられないままになります。

以前「AIにマイクロマネジメントするなかれ」という文章で、細かすぎる指示がAIの性能を抑え込む、と書きました。あれは指示の書き方についての話でした。

今回はその一つ手前です。どう書くかではなく、一度にどれだけ渡すか。

大きく渡せる相手になっている

任せられる単位は、この数年でかなり変わりました。

「方針駆動開発」という文章で書いた例があります。仕様を一つずつ決める代わりに、このアプリの利用者は五種類います、という数行のユーザ像を渡してみました。返ってきたのは、五者それぞれが何を要求するかの整理と、そこから導かれる設計方針でした。以後、画面の言語をどうするかといった何十個もの判断が、その数行を根拠に決まっていきました。

数行を渡して、数十個が返ってくる。この比率なら、説明のコストは完全に回収されます。

AIを、一件ずつ頼む相手だと思っているうちは、頼み方もそこで止まります。

大きく渡せばいい、という話でもない

ただし、逆を示す研究もあります。

Aayush Kumar らが Cursor を使う開発者19人を観察した2025年6月の研究「Sharp Tools」では、課題の説明をまるごと渡した参加者の成功率は38%でした。作業を分割して段階的に進めた参加者は83%です。

私の言っていることと、はっきり反対に見えます。ただ、著者らが挙げる最大の障壁は、渡した仕事の大きさではありませんでした。エージェントに暗黙知がないことです。個人的な経験から得られる種類の知識で、いつ何を伝えればいいのかの判断自体が難しい、と書かれています。

そう読むと、METRの結論と同じことを言っています。問題は単位の大きさではなく、文脈が渡っているかどうかです。

文脈を毎回の指示に混ぜようとすれば、一回あたりが重くなり、分割するしかなくなります。逆に、文脈をまとめて先に渡してしまえば、一回の単位は大きくできる。方針を先に渡すやり方が効くのは、たぶんここです。

大きく渡せば確認の手間が増えるだけだ、という反論もあります。コストは消えていません。指示を書く側から、結果を確かめる側へ移っただけです。ただ、移した先のほうが割はいいと思っています。指示は、まだ存在しないものについて書く作業です。確認は、目の前にある実物を見て、違うと言えば済みます。

それでも小さい仕事を頼む理由がある

では、小さな作業はすべて自分でやればいいのでしょうか。そうとも言い切れません。ただし、理由は速さではありません。

一行を直すだけの作業でも、人間は間違えます。似た名前のファイルを開く。数字を一つ写し違える。疲れているときほど起きますし、簡単な作業ほど確認せずに終わらせがちです。

AIも間違えます。知らないことを埋めることも、頼んでいないことまでやることもあります。ただ、注意力が切れて取り違える種類のミスは起こしません。集中に波がないからです。

だから小さな作業を渡すのは、速くするためではなく、安心するためです。速さで比べれば負けますが、測っている軸がそもそも違います。

罠は、この判断が自分で自分を証明すること

「AIに頼むより自分でやったほうが速い」は、測定結果としては正しいのだと思います。

正しいのですが、それは自分で選んだ切り方の中での正しさです。小さく切れば、速さでは自分が勝ちます。大きく渡せば、速さでもAIが勝ちます。小さく切ったまま渡すのなら、勝てるのは安心のほうです。

罠があるとすれば、ここです。この判断は、自分で自分を証明してしまいます。速くならないと分かった人は、次はもっと小さく切って渡します。小さくすれば、また速くならない。先ほどの、仕事を手放せない管理職と同じ形です。

批判をやめましょう、という話ではありません。ただ、測ったのがAIの限界だったのか、自分の切り方だったのかは、一度だけ確かめてみてもいいはずです。

遅いのはAIではなく、渡し方かもしれません。

【悲報】「AIより自分でやったほうが速い」は正しかった。ただし勝てる勝負しか挑んでいなかった」は、本記事のエンタメ版です。本記事が硬く感じられる場合はエンタメ版もお試しください。

いいなと思ったら応援しよう!