Lars Faye ・ 翻訳

エージェントによるコーディングは「罠」である

LLMは速度を最適化するが、本来重要なのは理解・整合性・簡潔さ。「監督のパラドックス」への警鐘。

読了目安 約 18 分日本語訳

〜認知の負債とスキルの退化を警戒せよ〜

「AIがコーディングし、人間はそのオーケストレーター（指揮官）になる」

いま、業界で煽られているのはこんな風潮だ。従来のコーディングは死に絶え、これからは「仕様駆動開発（SDD）」の時代が来る、と。人間は計画さえ作れば、あとはコードを書く作業から切り離される。エージェントの方が賢いのだから、実装はすべて任せておけばいい。人間は専門家として「筋の良さ」を担保し、出力をレビューし、自分が丹念に練り上げた計画を遂行させるべくエージェントを操るだけ、というわけだ。

現状、このワークフローの形は様々だが、大枠はこうだろう。まず誰かがプロジェクトの要件を（マクロ・ミクロ両方の視点で）定義し、計画を生成する。あとは、終わるまでスロットマシンのレバーを何度も引くように、複数のエージェントを何度も回してイテレーションを繰り返す。その間、「オーケストレーター」と、生成・コミットされるコードとの距離はどんどん離れていく。

コーディングエージェントは確かに便利で強力だ。が、議論すべき「代償」はすでに数値として現れ始めている。

この「エージェント・アプローチ」で成果を出すには、極めて重要な前提がある。それは、批判的思考ができ、アーキテクチャ階層での操作に習熟した「スキルの高い開発者」でなければ、生成された数千行のコードが問題を起こす前にバグを見抜くことはできない、ということだ。

皮肉なことに、AIツールはその個人の「批判的思考力」や「認知の明晰さ」に悪影響を及ぼすことがすでに証明されている。

単なる「抽象化」の進歩ではない

コミュニティでよく聞く反論に、「プログラマーは単にスタックの上位に移動し、別の種類の抽象化レイヤーに移るだけだ」というものがある。そもそもこれらのツールが本当に抽象化レイヤーなのかは決着がついていない（曖昧さのレベルが上がることは、抽象化のレベルが上がることと同義ではないからだ）。

まあそれは置いておくとして、確かにプログラマーという人種は新しい言語や手法に対して慎重になりがちだ。FORTRANが登場したときも、当時のプログラマーは懐疑的だった。「バグや不安定さの原因になる」「アセンブリを直接書くほうが効率的だ」なんて主張が飛び交ったものだ。その後も、コンパイラがプロセスに「魔法」を持ち込みすぎている、といった議論があった。これらは新しい技術を取り入れることで失われるものへの恐怖からくる、規範的な議論だったと言える。

ただし、今起きていることの決定的な違いは、かつての恐怖はあくまで「推測」や「理論」だった点にある。AIツールが登場してわずか数年だが、すでに深刻な影響が見え始めているのだ。しかも、それはジュニア層に限った話ではなく、10年以上の経験を持つベテランにさえ及んでいる。

（Coding Agents Paradox）

ジュニア開発者にとっては、さらに険しい壁が立ちはだかる。コードに触れる機会を奪われ、代わりに「生成されたコードの査読」をさせられるからだ。コードレビューは重要だが、学習プロセスのせいぜい半分に過ぎない。コードと直接格闘する摩擦や困難がなければ、学習能力は著しく低下してしまうだろう。

この現象の研究には時間がかかるため、リアルタイムの状況を把握するには経験談を集めることが重要だ。だが、すでに多くのレポートが、これが単なる気のせいではなく「実在する現象」であることを裏付けている。

「今回は違う」のだ

かつてC++からJavaやPythonに移行した開発者が、「脳に霧がかかった（ブレインフォグ）」なんて不満を漏らすことはなかった。インフラエンジニアがAWSに移行しても、ネットワークを理解する力が失われたとは感じなかったはずだ。

シニアエンジニアがマネジメント職に移り、コードを書く機会が減って「腕が鈍る」のは、今に始まったことではない。それは専門性の自然な進歩だった。何十年もの間、コードと摩擦を起こし、経験を積んできたエンジニアには、そのスキルと知恵を固める時間があった。だからこそ、仕事の主眼が構文（シンタックス）から上位のアーキテクチャ設計に移ったとしても、その知恵を応用できたのだ。 そういった人材は極めて稀少である。もし我々全員が「書くこと、解決すること、デバッグすること」に伴う摩擦を放棄してしまったら、次の世代のシニア層なんて現れやしないだろう。

いま起きているのは、深い理解に繋がるような「長年の摩擦」を経験したことのない開発者が、シニアエンジニアが数十年かけて手に入れたのと同じスキルを要求される「AIエージェントの管理」という上位ワークフローに放り込まれている、という歪なトレンドだ。

とはいえ、シニアエンジニアも無敵ではない。30年近い経験を持つSimon Willison氏は、「アプリケーションが何を行い、どう動くのかという確固たるメンタルモデルを持てなくなっている。その結果、機能を追加するたびに思考の難易度が上がっている」と報告している。

「熟練したオーケストレーター」のパラドックス

Anthropicの最近の調査の中に、コーディングエージェントを常用するリスクについて、驚くほど正直に語られている部分があった。

コーディングスキルの退化が懸念される理由の一つに、「監督のパラドックス」がある。……Claudeを効果的に使うには監督が必要だが、Claudeを監督するには、AIの使いすぎで退化してしまう恐れのある、まさにそのコーディングスキルが必要なのだ。

50人のエンジニアを統括するLinkedInのエンジニアリング・ディレクター、Sandor Nyako氏は、この傾向が組織全体に広がっていることに気づき、チームに対して「批判的思考や問題解決が必要なタスク」にはAIを使わないよう求めた。

「スキルを伸ばすには、苦労が必要だ。問題を考え抜くための筋肉を鍛えなければならない」と彼は言う。「批判的思考力がなければ、AIが正確かどうかをどうやって疑えばいいのか？」

「使いすぎ」の基準がどこにあるのかという問題もある。だが、データでも経験談でも、これらのスキルは数ヶ月という短期間で急速に退化し、消えてしまう可能性があることが示されている。

ここに、AI推進派が二枚舌を使わざるを得ない矛盾がある。「コーディングエージェントの利用は、そのエージェントを効果的に管理するために必要なスキルそのものを、能動的に削ぎ落としている」のだ。

LLMは「間違った部分」を加速させる

世間で喧伝されている言説とは裏腹に、我々は別に「コードをより速く書くこと」を切望していたわけじゃない。ましてや、十分に理解できていないコードや、妥当な時間内にレビューしきれないほどの大量のコードなんて、なおさらだ。

AI以前の（優れた）開発者の優先順位は、おそらくこうだった：

  1. コードの内容と、コードベース全体との関係を理解しているか
  2. コードがドキュメント化された効率的な標準に準拠しているか
  3. 目的を達成するために（可読性を保ちつつ）いかに少ない行数で書くか
  4. 納期（ターンアラウンドタイム）

エージェントによるコーディング、そしてLLM全般は、このリストを完全に入れ替えてしまう。 それらのツールの能力や用途は、特定の時間内に生成できるコード量を増やすこと、つまり「速度」に集中しがちだ。本来、速度とは高い習熟度の副産物である。それを無理に引き出そうとすれば、必ず精度は落ちる。今のツール群は、深い理解や簡潔さに焦点を当てているようには見えない。

「そういう使い方もできるか？」と言われれば、強い意志を持てば、もちろん可能だ。 「実際、みんなそう使っているか？」と言われれば、答えはノーだろう。組織内での強制的な通達やトークン使用量のお祭り騒ぎを見れば明らかだ。

コーディング ＝ 思考（プランニング）

開発者の間には、あまり強調されない「分断」がある。一部の人間は、コードを書きながらの方がうまく計画を立て、思考を深められるのだ。コードで考え、作業することは無意味な苦役ではない。セキュリティからパフォーマンス、UX、保守性に至るまで、あらゆることを技術的なレベルで考え抜くことを強制してくれるプロセスなのだ。

オープンソースのコーディングエージェント「OpenCode」の作者であるDax氏は、最近のインタビューでこう語っている。

「新しくて挑戦的な何かに取り組むとき、僕がコードを打ち込むこと自体が、そもそも何をすべきかを判断するためのプロセスなんだ。 じっと座って、機能がどう動くべきか巨大な仕様書を書くなんてのは、僕には無理だ。 型を書き、関数がどう絡み合うかを書き、フォルダ構成をいじって概念を整理するのが好きだ。これはほとんどのプログラマーが昔からやってきたことだと思う。個人的に、それをやめる理由が見当たらない。だって、それが僕にとっての『何をすべきか』を見つける方法だからね」

人間が言葉にしたことは、往々にして本意とは異なる。LLMはその曖昧さを「推測（あるいはハルシネーション）」で埋める。その結果、さらなるレビュー、さらなる修正指示、さらなるトークンの消費、そして「作っているもの」からのさらなる乖離を招くことになる。 逆に、これ以上ないほど美しく、曖昧さのない完璧なプロンプトを書けたとしても、LLMは平気で存在しないメソッドを出力してくる。なぜなら、LLMは根本的に「次のトークンを予測するエンジン」であって、コンパイラではないからだ。決定論的なシステムを確率論的なシステムに置き換えておきながら、「曖昧さをゼロにしろ」というのは土台無理な話なのである。

AIに最も熱心なシニア開発者でさえ、この「乖離」が深刻な問題になりつつあることに気づき始めている。

「ベンダーロックイン」

少し前にClaudeが落ちた際、LinkedInを見ていると、多くの開発者やチームの手が止まっているという投稿をいくつも目にした。彼らのワークフロー、あるいは彼ら自身のコーディング能力は、すでにこれらのベンダーに依存しきったレベルに達していたのだ。かつてはキーボードとテキストエディタさえあれば発揮できたスキルが、今やAIプロバイダーへのサブスクリプションなしには成立しなくなっている。

このパターンを突き詰めれば、かつては自分の批判的思考と問題解決能力の産物だったものを達成するために、トークン消費にお金を払い続けなければならない業界が出来上がる。これはある種の「ベンダーロックイン」だが、製品ではなく「業界全体のスキルセット」がロックインされるわけだ（モデルプロバイダーはさぞかし期待に胸を膨らませていることだろう）。 財政的な、あるいは知的財産的な梯子外しは、いつ起きてもおかしくない。ローカルLLMは、そのレベルの利用規模を吸収できるほど成熟していないのが現状だ。

これは理論上の推測ではない。いま現実に起きていることだ。モデルプロバイダー自身すらそれを指摘している。Anthropicの別の調査では、デバッグ能力が47%も急落したという結果が出ている。

「職場、特にソフトウェアエンジニアリングにAIを積極的に取り入れることには、必然的に代償が伴う……開発者は迅速な結果を出すためにAIに頼り、重要なスキル、とりわけ問題が起きたときのデバッグ能力を構築することを犠牲にする可能性がある」

トークンコストは予測できない

モデルプロバイダーには多額の補助金がつぎ込まれており、モデル自体も常に変化し続けている。新しいモデルがリリースされるたびに、「高いベンチマーク結果」が出て、「期待感」が煽られ、そして「実用段階」になると「弱体化（nerfed）した」「同じ仕事をするのに2〜3倍のトークンを消費するようになった」と皆が不平を漏らす。これがいつものパターンだ。

社員のコストは計算できるが、トークン代が日ごと、月ごと、年ごとにどうなるかは誰にもわからない。チーム全体がエージェントによるコーディングをデフォルトにしているなら、経費予算を相当柔軟に構えておく必要があるだろう。Primeagenが言ったように、「完全にエージェント化したワークフローを使っているとき、君は実質的にモデルプロバイダーの所有物になっている」のだ。

もちろん、これらすべてを回避する方法はある。LLMは技術的な大躍進であり、責任を持って使えば、学習やスキルアップのための最高のツールになる。概念や技術をより深く、広く探求することを可能にし、かつては実験するだけで多大な時間を要した新しいアイデアの検証を容易にしてくれる。これこそが、業界に長期的な価値をもたらす本来の姿だと僕は思う。

私のアプローチ：AIの役割を「格下げ」する

僕は、コードを手で打つべきだと言いたいわけじゃない。プログラマーはいつだって、コードを書かずにコードを生み出す方法を探してきた。Emmetやオートコンプリート、スニペットが存在するのもそのためだ。COBOLだって、「MOVE」や「WRITE」といった英語に近い言葉を使うことで、少ない記述で多くの命令をこなせるように設計された。jQueryのモットーは「write less, do more（より少なく書き、より多くをこなす）」だった。LLMも、そうしたコード生成ツール群の新たな一行に過ぎない。

僕が提案したいのは、LLMやコーディングエージェントを「補助的なプロセス」として活用することだ。生産性という祭壇に、個人のスキルを供物として捧げないやり方である。主導権をひっくり返して、計画のブレインストーミングにはAIを頼りつつ、実装中は能動的に関わり続け、必要に応じてのみタスクを委譲する。そうすれば、理解度の欠如という負債を抑えつつ、生産性の向上を享受できる。

僕の毎日のワークフロー：

このリストを要約するならこうだ。「AIを『データ』ではなく、『艦内コンピュータ』のように使え」 （スタートレックのファンなら、この比喩の意味がわかるはずだ）

速くはないが、より良い仕事ができている

これらのモデルによる生産性の向上は本物だ。そして、実感を伴って頻繁に仕事に向き合うことで得られる摩擦や理解も、また本物である。

「コーディングを理解しなくてもコーディングを民主化できる」という試みが幾度となく失敗してきた歴史を鑑みれば、コードに触れずしてコードを理解することはできないという現実に突き当たる。そして、書き続けることをやめれば理解力は失われ、結果として「オーケストレーター」としての能力も下がり、AIコーディングというこの時代が、奇妙で不必要にストレスフルな幕間劇になってしまうだろう。

僕の考えすぎかもしれないが、歴史は常に教訓を与えてくれる。 これは、かつて自分たちに対して行ってきた別の巨大な実験に似ている気がしてならない。ソーシャルメディアが登場したとき、僕らは長期的な影響を理解しないまま受け入れ、いまや広範囲に及ぶ注意欠陥（他にも多くの問題があるが）に直面している。

今回、僕らが賭けているものは、それよりもはるかにリスクが高い。

「いまAIエージェントに全振りしている連中は、自分の時代遅れを自ら保証しているようなものだ。思考をすべてコンピュータにアウトソーシングすれば、スキルアップも学習も止まり、有能な人間にはなれなくなる」 ―― Jeremy Howard（fast.ai 創設者）