頭を切るのは通用しない:肉のプロキシに従業員としての未来はない

Dan Luu は 2025 年初から、LLM を使うときに頭を切る人々を見てきた。結論は明快だ。LLM が「頭を切っても」平均的なソフトを作れるほど強くなったら、会社は LLM をループで走らせてその人を解雇すればいい。

日本語
コピー

2025 年初、私は LLM を使うときに頭を切る人々を見かけ始めた1。LLM に何か(テキストの要約、コードを書くなど)をやらせて、うまくいったと勝手に前提する2。2025 年初頭にはこれはだいたい通用せず、結果はたいていかなり頓狂だった。

LLM が良くなるにつれて、私はこれをより多く見るようになった。LLM にコードを書かせて、ほぼ前提として動くと決め込む人もいる3。ループの中に人間がいる場合でも、動かなければ LLM に原因を突き止めさせて直させる。Niklas Gruhn はこの種のやり方の一部を肉のプロキシになることと呼んでいる4

for ループ的な肉のプロキシであることは 2025 年初頭よりもうまく機能するようになり、そうやって開発されたソフトウェアは、ときどき本当にそこそこ動く。私が使いたいと思うほどでも、成功していると言えるほどでもないが、2026 年 9 月時点での「肉のプロキシ」の有効さには感心する。LLM がもっと良くなれば、頭を切った肉のプロキシ開発が平均的品質のソフトウェアを生むようになる、あるいは人間がループに入らなくても優れたソフトウェアを生むようになる、と想像することはできる。

それが起きたとしよう。会社がその肉のプロキシを雇う理由は何か。LLM をループで走らせて、その従業員を解雇すればいいだけだ。この方法論が従業員にとって機能する瞬間は存在しない5

Max Bittker、Yossi Kreinin、Luke Burton、Thomas Dullien、Dennis Snell、Peter Geoghegan、Jamie Brandon にコメント・訂正・議論への感謝を。


Footnotes

  1. この考えはもう 1 年半ほど持っている。LLM が良くなり、人々が LLM と向き合うときにより多くの時間を頭を切ることに費やすのを見て、頻度が増した。

  2. Luke Burton はこう述べている。

    これができるということは、人が思う以上に「やっている仕事の種類」を語っている。私はこういう作業から手を離れるのは、そのタスクがかなり低価値で、失敗しても許される場合だけだ。

    高価値のタスクでは、LLM が一発で仕留める確率はずっと低い。私は QA、エンジニアリングマネージャ、アーキテクトの役を引き受けることになる。この while ループは、しばしば締め切り前のような感覚だ。何かを見落としているのではないか、雑なプロンプトが、後で巻き戻さねばならないアーキテクチャ上の選択を招くのではないか、という疑念がつきまとう。

    もうひとつの観察は、高いスループットが自分の出荷基準を引き上げるということだ。以前なら MVP を出して反復したかもしれないが、今は agent に自分の標準をはるかに超えて磨かせ、エッジケースを探させる——そしてプロンプトを与えなければ、彼らはたいていそれをやらない。

    人によっては居心地の悪い話かもしれないが、agent がそんなに簡単に決めてしまうなら、肉のプロキシたちに訊きたい。1)もしかして、あなたはすでにかなり油を売ってきたのではないか? 2)なぜ agent を、彼らが軽々とこなせる範囲のはるか先へ押し出さないのか?

    私たちは「手放しの自動化」に極めて向いていると思われることをやってきた。[伏せ字] を Bazel ビルドへ変換する仕事だ。agent を使っても数か月かかった。このタスクには、言葉にしにくく、仕様化しにくい要求が大量に埋まっており、agent にその線を歩かせるには常時の監督が要る。「これを Bazel に変換して」とプロンプトして立ち去るのは、少なくとも数か月先、おそらく数年先、もしかすると永久に無理かもしれない。意思決定点が多すぎ、未知の未知も多すぎる。

    たとえば、こんな状況はどれくらい起きるか。あるコードに出会い、なぜそう動くのか分からない。だがそれを知ることは、取るべき方針を実質的に変える。開発体験を変えるかもしれないし、ある顧客がすでにそれを使っているのか分からない、といった具合だ。これをどうやって「肉のプロキシ」で乗り切るのか?

    逆に、ステークホルダーと自分の仕事を振り返って、相手が「あれ?あの部分は要らなかった、もう使っていない」と言う。すると、「ある要素を保持する必要がある」という誤った前提のまわりで、どんな意思決定が行われたのか。

    [Luke のコメント終わり。以下は私のコメント。] 意思決定が必要だとより明白なのは、agent が分布外のものにぶつかったときだ。小さめの例は、私たちが agent のプログラミング言語ごとの能力を比較したときで、agent はマイナーな言語ではずっと苦手だった。訓練はされているが、主流言語ほどではない。より分布外的な例は、ボードゲーム(とくにチェスや囲碁のような古典ではなく現代のゲーム)をやらせた場合だ。《Lost Cities》や《Dominion》のようなゲームでは、一般に SOTA のモデルとハーネスは、ボードゲームはそこそこ得意だがそのゲームを一度もやったことのない人間より弱い。agent にゲームについて訊けば多くを知っており、ゲームを理解していない人にはもっともらしく聞こえるが、理解している人には明らかに間違っていることを言う。最近、私は新規プレイヤーと《Dominion》を何戦かやった。その人は ChatGPT に助けてもらえばゲームを学び上手くなると思っていた。私は懐疑的で、おそらく悪くなるだろうと言った(見る限り、実際そうなった)。数戦の後、ChatGPT が何を言っていたか見ると、半分は正しく半分は間違いで、間違った半分は、ゲームが上手く一般的なゲームのヒューリスティクスを使う人より悪い場所へ彼を導いていた。ちなみに公開情報は十分にあり、一度も遊んだことがない人が、たとえば 5 時間かけてこのゲームについて読み、どんな情報があるか見れば、簡単に99 パーセンタイル以上になれると思う(プレイ中に参照が許されるなら 30 分かもしれない)。それは面白くないし誰にも勧めないが、agent が検索や API 照会をできることを踏まえると、分布外の問題に取り組むときの今日の人間と agent の差が見える。次の大型モデルでひっくり返るかもしれないが、今日の差はまだかなり大きい。

    ともあれ言いたいのは、コーディング中でも分布外の問いにしばしば出くわし、そこで agent は普通の人間よりはるかにまずく振る舞うということだ。今日、良い結果を得たいなら、そうした場面に気づいて対処する必要がある。

  3. 「動くと前提する」ことで何が壊れるかの例:このケースでは agent が(ときに)テストにひどく過適合し、このケースでは指標にひどく過適合した。agent は「評価の形をした」問題でより多くカンニングするという説を聞いた。真偽は分からないが、仮に真として——しかも私が仕事や個人プロジェクトで、評価を走らせていなくても多くの人より「評価の形をした」指示を作りがちだとしても——評価の形をしたものを作らない人々が、指示を書いて agent を無監督で暴れさせたときに同じ問題(実際はもっと深刻だと私は思う)にぶつかるのを見てきた。(私自身、ごく少ない監督でそれをやってうまくいったことがあるが、それは agent をかなり強く囲い込んだ場合だけで、その囲い込みは多くの人のやり方より「評価の形」に近い。)

    思考を LLM に外注した人々のソフトウェアを試すと、深刻な問題がある。この手のやり方はうまくいくと人に言われるが、ソフトウェアはしばしば「ここで論じた基準では動いていない」と私が言う水準にある。

    くだらない例を挙げる。ある「プログラミングの思想リーダー」が、あらゆる(プログラミングの)分野でプロジェクトを試したが Claude が専門家同様に全部解けた、だからプログラミングは解決済みだとツイートしたのを見た。私は実際にその人の GitHub を見たが、私が見た例(ゼロではない)はどれも動かないか、ひどく下手に動いた。これにぶつかったのは、私がボードゲーム AI を作っていて、自分の AI と対戦させる既存 AI を探していたときだ。その人の AI は AlphaZero 風のボットで、「LLM に単純な minimax ヒューリスティック・ボットを書かせ、LLM をループで少し走らせてヒューリスティックの採点を調整させる」より弱かった(このゲームでは、後者は凡庸な AlphaZero 風ボットに粉砕されるはずだ)。

    もうひとつくだらない例。(実際の商用製品の)標準的な流れに従うと、技術的には脱出可能な無限ループに陥る(多くのプログラマなら脱出方法を思いつくだろう)が、典型的なユーザー(プログラマ向けではないソフトウェアだ)はおそらく脱出できず、そのソフトウェアの主要機能を使えない。

    ちなみに私は「自分には動けばいい」品質のソフトウェアを大量に作っている。それが実際の製品なら「ほぼ動かない」と評価するだろう。だから「ソフトウェアがほぼ動かない」こと自体が悪いとは思わない(たとえばここで論じた正規表現エンジンは自分のマシンで ripgrep 検索を速くするために agent に作らせたし、この Rust インタプリタは一部プロジェクトで agent の反復ループを速くするために作らせた。どちらも使うべきではない)。ここでも述べたが、agent をループで走らせてデータ分析をさせ、完全に誤った結果を出させてから私が直させるのは非常に価値があると思っている。だが「自分の狭い用途では動く、使い方を間違えれば動かないと分かっているソフトウェアを自分用に作る」ことや「誤っていると分かっている仕事を出して後で直す」ことと、「動かないソフトウェアを大量に書いた上でプログラミングは解決済みと宣言する」こと、ましてやその品質のものを商用製品に入れることは別だ。

    この記事の草稿を読んだとき、この短い一群の所感を公開する価値があるか訊ねたところ、Thomas Dullien(別名 Halvarflake)は言った。「良い記事だ! 公開しよう。なぜなら私が『LLM はプログラミングのすべての問題を解くわけではない』と言うと、人々は私を狂人を見るように見て、私は彼らを狂人を見るように見るからだ」。そして偶然にも、草稿を書き終えた後、Gary Bernhardt がツイートしたのを見た。「実際の agent の出力と、ここで人々がそれについて言うことを対比すると、あまりに現実離れしている。日々の変更で、私のレビューは diff を元の 25% に切ることがよくある。無意味なテストの山、偏執、反転したロジック。それで Twitter を見ると『コーディングは解決済み』だ」、続けて「そのツイートをしてから 1 時間以内の例:DATABASE_URL の管理を直せと言ったら、npm script の中に直接 if を足し、CI にはインライン JS を走らせる条件的な node 呼び出しを足した。diff は約 20 ハンク。私が直した後:+0 行、+1 語」。

    Thomas や Gary のソフトウェアに対する態度を持つ人は、しばらく前からそう感じていたはずだ。しばらく私は、LLM の生産性について最大級の主張をする人々は、私が知る誰よりもはるかに大きな価値を LLM から得ているのかと疑ったが、ここで論じたとおり、証拠が増えるにつれ、ただ彼らが自分を騙しているだけだと確信を深めた。ボードゲームの例が気に入っているのは、結果の AI がどれだけ強いかを直接測れることだ。極端には A > B > C > A のような三すくみもありうるが、それが単なる AI のナンセンスであれば、客観的にかなり明白だ。商用ソフトウェアも同じで、社内の人に聞いたり自分でデータを見たりして、コンバージョン率が低い、チャーンが非常に高い、満足度調査で不満が非常に高い、といったことが分かる。

    もうひとつくだらない、ソフトウェア寄りでない例。最近の投稿に対して、ある人が ChatGPT のファクトチェックを、私の誤りを指摘する見下したコメント付きで送ってきた。もちろん私はその投稿をすでに ChatGPT で検証し、実際の誤りは直していたので、残っていたのは ChatGPT の誤りだけだった。一般に、この種のこと(私のものに限らず誰のコンテンツでも)では、偽陽性率(適合率)は悪く、偽陰性率(再現率)はまあまあだと分かっている。少し頭を使うなら、こうしたファクトチェックを走らせる価値はあると思う。偽陽性の山を私が切り落とすほうが、草稿を読む人間をもう一人雇うよりずっと安いからだ。

    さらにもうひとつ。最近 tpatcek が触れた話題で、LLM におだてられて自分の仕事が良いと思い込まないこと(彼はとくに文章について述べていたが、他の種類の仕事にも当てはまる)というのがある。上に挙げた Gary や Halvarflake の態度があれば言うまでもないが、これを知りたくない人もいる(よほど注意を避けないと気づかないはずだと思う)。LLM が自分の仕事を持ち上げるのを、それがどれほど素晴らしいかの根拠にする人を見るからだ。LLM があなたの仕事を天才的だ、あなたの推論が対話相手の推論を完全に打ち負かしたと宣言する日が来るかもしれないが、今日はまだ遠い(正確さの話であって、時間的距離の予測ではない)。だから LLM による自分の仕事や推論への賛辞を、その良さの根拠にするのは、主に「頭を切った」印であり、その仕事や推論が貧しいというかなり強い信号だ。

  4. 彼の記事は、人が実質的に while ループや for ループとして振る舞う場合に技術的には触れていないが、その振る舞い(私がますます見かけるようになった)も記事の精神に沿っている。

  5. 創業者や大株主などには当てはまるかもしれないが、私が実際に見た限りでは、そうしているのは被雇用者や個人プロジェクトの人で、「これがどれだけうまくいくか、ソフトウェアは解決済みだ」などと表明し、被雇用のソフトウェアエンジニアにとってソフトウェアが解決済み問題だという含意を出している。

    もうひとつの論法は「我々は皆すぐ時代遅れになるのだから、諦めればいい」というものかもしれないが、人間の時代遅れがごく近い必然でない限り、これは逆だと思う。経済的に引退準備ができているなら頭を切ってもいいが、それはいつでもできたし、やる気なく適当に過ごす人は常に大勢いた。準備ができていないなら、より多くの金を稼げることをするべきで、それはおそらく頭を切ることではない。時代遅れにならない未来なら、急いで金を稼ぐ必要は特にない。だが時代遅れが近いと思うなら、今こそ急いで稼ぐときで、頭を切るのとは逆をすべきだ。「どうせ働いても正しいことをしても金は増えない」という論法は私にはかなり誤りに見える。私は問題を見つけて直すことで昇給やボーナスを得てきたし、それは友人たちの経験でもある——彼らが、良い仕事をまったく評価しない非常に機能不全な場所にいる場合を除いて。その場合は彼らは去って別の場所へ行く。

    もうひとつ、「慣性のせいで、LLM がプログラマを置き換えられるほど良くなった後にも、肉のプロキシで逃げ切れる窓がある」という論法もあるかもしれない。現実には、企業がどれほど人員削減に熱心かを考えると、これも逆だ。できるだけ仕事をしたくないなら、最良の時期は過去だった。大企業の人にこういう話を聞くと、文字どおり出社しない(リモートもしない)人が何か月も何年も解雇されないという話が山ほどある。ここ 2 年はそういう話をあまり聞かないが、私がいたチームにそれをやった人がいて、記憶が正しければ(以前は数字を覚えていたが、今は自信がない)、引退を決めて「出社をやめれば給料をもう数回もらえる」と考えた後、解雇に 6 か月かかった(パンデミック前、リモートでない会社)。別の会社の友人のところでは 2 年かかった。長い間、解雇手続きすら始まらず、その後ゆっくりと警告がエスカレートして、ようやく解雇された。友人の話では、そのマネージャは、もし彼らが制度をうまく使おうと出社して少し働くふりを始めていたら、新しい時計が始まり、解雇はさらに長引いたと言っていた。有能なサボり手なら、当時の状況では無期限に職を保てただろう。なぜ企業がそんな状態になったのか分からないが、企業は AI を口実にその状態から離れようとしているようで、今と近い将来は、非常に長い間で最も「努力も価値も出さずに職を保つのに向かない時期」 になっている。間違いなく逃げ切れる企業もあるだろうが、何もせず給料をもらいたいなら、ずっと前からできた(やりすぎて本当に出社しないのはやめておくとして)し、そのときの環境のほうが近い将来より易しかった。

出典: danluu.com← ホームへ戻る