LLMによるコード生成は信頼性の低下につながる可能性
(jaysthoughts.com)- 最近、LLMベースのコード生成が開発者の間でますます利用されるようになっている
- 自動生成されたコードによって、コード品質と信頼性への懸念が高まっている
- 開発者はコード理解の不足や検証不十分により、プロジェクト保守の難易度上昇を経験している
- 信頼できないコードの利用拡大がソフトウェア生態系全体に影響を及ぼしている
- 技術の進歩とともに、信頼性を確保する方策を整える必要性が強調されている
概要
Jayは自身のブログで、近年登場したLLM（大規模言語モデル）ベースのコード生成技術がソフトウェア開発の現場に与える影響を扱っている。こうしたツールの発展によって開発効率は向上している一方で、コードの信頼性と品質の問題が浮上している。
LLMコード生成技術の台頭
- 開発現場では、LLMを活用したコード自動生成ツールが急速に広がっている
- 複雑な機能実装や反復的なコーディング作業で高い生産性を提供している
- 迅速なプロトタイプ作成や新しい言語の学習負担を軽減する利点がある
信頼性の問題
- LLMが生成したコードが意図したとおりに常に動作するわけではないという現象がある
- コード内部の意図や設計ロジックが不明瞭で、理解と検証のプロセスが難しくなる
- レビューやテストの工程が不十分な場合、予期しないバグや脆弱性が発生する可能性がある
プロジェクト保守と生態系への影響
- 自動生成コードに対するドキュメント不足や説明不足の問題が生じる
- 開発者がコードの動作原理を把握しにくくなり、保守の複雑性が増す
- 信頼性のあるソフトウェア開発文化が損なわれるリスクがある
結論と提言
- LLMベースのコード生成技術は革新的だが、信頼性の確保が必須の課題である
- 自動生成コードを導入する際には、検証の強化と体系的なコードレビューの必要性が強調される
- 長期的には、コンピューティング生態系の信頼保護のための基準整備が重要である
1件のコメント
Hacker Newsの意見
https://archive.is/5I9sB
古いブラウザーでも動作し、CloudSnare を通過するとき以外は JavaScript は不要
友人がいつも「イノベーションは 信頼の速度 で起こる」と言うのだが、GPT-3 以降この言葉がずっと頭に浮かんでいる
検証には大きなコストがかかり、そのコストを下げる鍵となる手段が信頼だ。LLM をどうすれば信頼できるようになるのか分からない。コードでも自然言語でも非常に流暢だが、同時にフラクタルのようにどこまでも掘り下がるウサギ穴に進んで入り込み、人間なら悪意があると見なされるような振る舞いもする
常にすべてを検証しなければならないこの新しい世界はかなり消耗するし、正直かなり遅い
有用すぎて無視できず、信頼は常にレンガを一つずつ積むように築かれる。そもそも人間もそれほど信頼できる存在ではないことを忘れてはならない。自動車の運転のように、あらかじめ定義された道路の上で バグの少ないコード を作る能力は、まもなく人間を追い越し、その次は複雑性を改善するための基礎力勝負になるだけだろう
科学では進みながら信頼を積み上げていく
職場で、予想とは違う形でこうしたことを経験した。同僚と私は進捗を見せなければならないというプレッシャーを受けており、私が進めていたかなり大きな リファクタリング を急いでマージすることにした。ドラフト PR だったが勢いをつけるためにマージし、その翌週、未テストのコード領域でいくつかバグが出た
デバッグ中、同僚は私が AI で書いたはずだと決めつけていたことを明かし、事後的に AI 生成物を理解しようとすると苛立つとも言った。だが、このコードでは AI を使っていなかった。もちろんコードを書くのに AI を使うことはあるが、このコードは全体設計を慎重に考えながら手で書いたものだった。バグはリファクタリング自体の根本的欠陥ではなく、変更された API に合わせて既存コードを調整する中で生じた小さな見落としだった
結果として、同僚と緊張関係について明示的に話すことができ、信頼を築く経験 になった。いま起きていることの力に、かなり穏やかな形で向き合えたわけだ。振り返ると、こういう形で解決してよかったし、別の職場環境だったらもっとずっと厄介になっていたかもしれないとも思う。気をつけるべきだ
4年ほど前、自分でかなり愚かなことをしたことがある。地元紙が、ある人物について写真を主な証拠として使い、ばかげた主張を含む記事を出した。私は編集者に直接メールを送り、その画像が加工されていると確信する理由を説明した。だが私の理屈は自分の誤解に依存しており、その人物が meet-and-greet で何人もの人とポーズを取る間、位置や姿勢がほとんど変わっていなかったことを誤って解釈していた。編集者は気分を害して私をからかうような返事をしたが、私が引き下がらないので、私が扇動家ではなくただの間抜けだと分かると、写真が撮られた 未公開のフル映像 を共有してくれた。そのとき私は深く謝罪し、寄付もしたし、その後1年ほどは自尊心がほどよく小さくなっていた
メールを送る前にも、虚偽の非難はしたくなかったので、落ち着いた友人たちに写真を共有して意見を求めたのだが、彼らも画像が加工されている可能性が高いと結論づけたので、かなり自信を持っていた。今ではその新聞と関係者たちを暗黙に信頼しているが、たった一人を納得させるだけでも本当に大変なことだった
前提を理解しにくい。誰かが良いコードを書くから信頼するとしても、その信頼はその人のコードがうまく動いたことで学習したものであって、その人の頭の中に「良いコードを生み出す」何らかの先験的な精神モデルがあるからではない。
誰かがLLMを使ってバグのないコードを作れば信頼するだろう。誰かがLLMを使ってバグの多いコードを作れば信頼しないだろう。その人が自分の頭だけでコードを書いていた時と何が違うのか？
LLMのせいで、提出されたコードだけを見てパッチを出した開発者の品質を即座に判断するのが非常に難しくなる。相手がどんなタイプの人か見極められなければ、「無信頼」に戻ってすべてを非常に細かくレビューしなければならない。つまり、もはや安全な「レビューの近道」はなく、そのようなシグナルに依存して仕事を回していた場では苦痛になりうる。すでに有能で信頼度の高いチームであればこの問題は当てはまらず、概念自体がなじみにくく感じられる可能性が高い
コントリビューターが変更内容をうまく説明すればより信頼する。過去に優れた仕事をしていればより信頼する。妥当なコミットのように変更単位を適切に管理していればより信頼する。新機能を追加する前にバグを修正するように、正しい問題を選べばより信頼する。既存コードを保守できることを示せば、単に上に積み増すだけの場合より信頼する。定期的に貢献していればより信頼する
問題はしばしばコミュニケーションエラーだ。作業者にとっては課題が明確でも、頻繁なコンテキストのリセットのため、LLMも全体像を把握しているとは限らず、曖昧さがあれば安易な仮定をしがちだ。4oのdeep researchが何かをする前に追加情報を尋ねるやり方は、コード生成でも標準になるべきだと思う。そうすれば山のような問題を防げる
単純なケースもある。このルーチンが望む値を返すかどうかの問題だ。しかし別の状況では、システムの他の部分とどう相互作用するか、目立たない境界ケースが何かを予測しなければならず、はるかに複雑になる。そうした状況で「バグのない」コードを書くには、書き手がコードの含意を理解していなければならないし、開発者がLLMの書いたコードが正確に何をしているか理解していなければ、その含意も理解できない。そうなるとその負担はレビューアに移り、レビューアの作業量が増える。それが前提だった
良い経験則は、LLMが関与した作業はそのまま拒否し、LLMが書いたコミュニケーションも無視することだ。英語を外国語として使う人であっても、ChatGPTに代わりに話させるより、その人の「たどたどしい」英語のほうがはるかに良いと思う。LLMの深刻な問題がより明確になるほど、こうした方針が全体的な標準になっていく気がするし、そうなることを望む
LLMは、どんな種類の悪い仕事でももっともらしく良い仕事のように見せてしまう。だから、AIを使った人の成果物を自動的に割り引いて見るのは合理的だ。
以前、親戚の一人が詐欺師だと判明したことがある。発覚した後、私は連絡を絶ってその人を知らないと言った。すると彼は「私はこの10年間、君が知っていたそのままの人間だ」と言った。私は「そうかもしれない。だが、今になってようやく、私はその人が誰なのかまったく知らなかったし、これから先も知りようがないのだと気づいた」と答えた。
私たちは皆、人生に登場する人々が積極的に自分を害そうとはしていないと仮定している。その信頼が壊れるときは、ひどく激しく壊れる。AIを使う人は誰も「これは自分の仕事だ」と主張できない。なぜなら、それが本当にあなたの仕事なのか分からないからだ。AIを使った人は、それを徹底的に理解していない限り良い仕事だと主張することもできないし、おそらく徹底的には理解していないだろう。私の学生のかなり多くが、私の書いたものを読んで理解したと主張したが、実際にはそうではないことが分かった。もし私がAIで、彼らが私の仕事を受け取って自分の名前を著者として載せていたらどうだろうか。彼らは何ひとつ説明も弁護もできず、その先の作業もできないだろう。こうした問題はAI以前からあったが、今では10倍は悪化している。
私は有用なLLMが登場する前に、複雑なアプリケーションプログラミングに「1万時間以上」を費やした人間だ。何年もの間、毎晩ドキュメントや他人のソースコードを掘り下げ、フルスタックの熟達に完全に没頭していた。最終的にその没頭は深刻なバーンアウトにつながり、健康も悪化し、結婚生活も揺らいだ。アプリケーションをリリースした直後、回復のために3年間まったく手を離さざるを得ず、二度と戻れないだろうと確信していた。
LLMがコードにかなり強くなったという話を数多く聞き、慎重にコンピュータの前に戻ったのだが、その時点で私の経験は懸念とは大きく分かれた。「AIを使う人は『これは自分の仕事だ』と主張できない」という言葉には同意できない。私がLLMを使うとき、私は設計者であり最終レビュアーだ。ビジョンを指示し、システムを設計し、diffツールでLLMが生成したすべての行を確認する。最近では、事業の見積もりエンジン向けの複雑な最適化モデルをLLMと一緒に作った。本物の最適化モデルを使うことが常に「正しい」やり方だったが、以前ならライブラリの細部をすべて学び、他人のコードを読むために何か月もの過酷な作業が必要だっただろう。今回は1週間で終わった。これが自分の仕事のように感じられるか？ 完全にそうだ。疲れを知らず有能だが、ときどき欠陥のある助手がいただけだ。
利用者が「徹底的に理解していないだろう」という話についても、私の経験は逆だ。些細ではないことにLLMを効果的に使うには、LLMを導き、頻出する微妙なミスを見抜くために、基礎についてより深い理解が必要になる。私の長年の経験がなければ、複雑なマルチモジュール開発を導いたり、出力をデバッグしたり、もっともらしく良さそうに見える仕事が実際にはN+1問題のような形で間違っていると見抜いたりはできなかっただろう。
教師としての経験には共感する。学生がこうしたツールで理解したふりをする問題は現実であり、難しい。学界では、学習過程、つまり1万時間の何らかの実質的な部分を得ること自体が目標だ。しかし専門の世界では結果が目標であり、これはより良い結果を得るための新しく強力な道具だ。教師がこの新しい現実の中で学生をどう教えるべきかは分からないが、LLMの利用を悪魔化することがおそらく最善ではない。
私にとってこれは、悪い仕事を良く見せるものではなかった。優れた仕事を再び可能にしてくれたし、同時に自分の人生も取り戻させてくれた。自分や家族を壊さずにソフトウェア開発というcraftの喜びを取り戻させてくれたし、今の人生ははるかにバランスが取れていて感謝している。
私にとっては、もうすでにそういう状態だ。「見落としていてすみません、あなたの言う通りです」を読んだ回数はものすごく多い。10回中8〜9回くらいだ。
一方で、有料LLM生成コードを何も考えずにコピーして、期待通りに動かないと激怒する人たちも相変わらずよく見かける。ちなみに、そのほうがまだマシな選択肢だ。表面上は動いているように見えるものより、明らかに壊れているもののほうがむしろ良いからだ。
とはいえ、予測エンジンはまだ本当のエンジニアリングはできない。Python generatorのようなものを使えと具体的に指示しない限り、膨大なメモリを食うコードが出てくる可能性が高い。残念ながら私の知る多くのPythonプログラマとも大差ないが、LLMが言われる通りの意味で悪いことの一例でもある。前向きな面としては、人々に「機能追加」という一行よりも詳しい仕様作業を実際に書かせるようになることだ。
私たちにとってAIエージェントが最も有用なのは、誰も優先順位を付けないレガシーコードだ。前世紀に書かれたデータ抽出器があり、FAXで届く特定の文書タイプからデータを抽出するために、ハードコードされた座標を約200個使っている。その文書は30年近く変わらなかったので問題なく動いていたが、最近変更され、Copilotは座標修正に30秒ほどしかかからなかった。人間なら、ひどく退屈な丸一日作業になっていた可能性が高い。ただ、vibe codingの時代に、この業界がどうやって専門家を育てるつもりなのかはまったく分からない。
LLMに逆らって戦うのは、風に向かって放尿するようなものだと思う。
現在の方式のLLMは、開発者の生産性を高めているように見える。経験の浅い開発者にとっては、熟練開発者よりもさらに大きな恩恵をもたらす可能性もある。生産性の向上、ひょっとすると非常に大きな倍率での生産性向上は、何らかの理由で技術に反対する人たちが築いた障害のせいで放棄されることはないだろう。
新しい生産性ツールが甚大な被害をもたらした例、たとえば大規模サービスをかなり長時間停止させるバグが出たとしても、その技術が相当な生産性を提供するなら止まらないだろう。技術とともに働き、その弱点を緩和することだけが唯一合理的な道だ。そして、その緩和策は新技術の生産性メリットを完全に打ち消すようなルールの集合であってはならない。緩和策は技術と連携して導入を増やす方向で機能すべきであり、そうでなければ回避されるだろう。
私の経験では、LLMのおかげで生産性が10倍になったと強く主張する人たちは、たいてい比較的ジュニアなフロントエンド開発者か、ひたすら新しいアプリをゼロから作り続ける連続起業家的なスタートアップ開発者だ。もちろん完全に妥当なユースケースではあるが、だからこそジュニアのフロントエンド開発者とシニアの組み込みC開発者は、AIによる生産性向上を語るときに話が食い違いやすい。
技術とともに働き、その弱点を緩和することだけが合理的だと言う代わりに、単にもっと分別を持って使えばいい。たとえば、AI「エージェント」という発想そのものは良いのだろうか。最近のCopilot事件[0]は、MSとAIを笑いもののように見せた。AIに自律的に作業させようとする試み自体が、あまり賢明ではない可能性がある。
最近の類推としては、ブロックチェーンと暗号資産がある。好き嫌いはともかく、Coinbaseなどの成功を見ると、ブロックチェーンが実在しつつも狭いユースケースを見つけたのは明らかだ。しかし暗号資産の過熱期には、「コーヒー豆のサプライチェーンをブロックチェーンで追跡する」といったことを言う人たちがいた。2025年にはTwitterの大げさなジョークのように聞こえるが、2020年にはIBMが実際にこうしたものを売ろうとしていた[1]。いつか振り返ったとき、AIエージェントや現在の生成AIアプリケーションの一部が、このバブルにおけるコーヒー・ブロックチェーンだったと見なすことになるかもしれない。
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
だが、これはモデルと人間の組み合わせがユーザーのニーズをより効果的に満たす、という意味ではない。「より多くのコード」を生み出すという意味だ。2000行のコードを削除する変更セットを出力するLLMは存在しない。だから、「エンジニアをより生産的にする」という言い方が、生成されるコード量についての話だとわかる。
まるでLLMを使うか使わないかという二分法で主張しているかのようだが、著者が主に語っているのはリスク緩和だ。たとえて言えば、著者は車が何台か爆発したと指摘し、昔の馬は爆発しなかったのだから、接着剤工場を稼働させる前に車がもう少し爆発しにくくなるようにすべきだと言っただけなのに、あなたは著者が自動車開発そのものに根本的に反対していると見ているようなものだ。
今でもGPTを使いたくない気持ちはあるが、最近は同僚たちが「ChatGPTがこう言っていた」とか「このコードはChatGPTが作った」と言う。私は自分でコードを書き、GPTを使わないことに誇りを感じているが、同時にGoogleやStack Overflowは使っている。それもGPTのもっと遅いバージョンだと言えなくもない。
不完全で確率的な行為主体でも、信頼できる決定論的システムを作れるという点を著者は見落としているように思う。
ガベージコレクションのツールを著者の信頼性ゆえに信じることはないし、広範なテストの後に意図した仕事を果たすことが証明されるから信じるのだろう。今後、信頼が弱まっていく姿は十分に想像できるし、その結果テスト駆動開発がさらに弾みを得るように思う。信頼してはいけない、検証すべきだ。
さらに重要な問いは、テストそのものは誰がテストするのかということだ。伝統的な開発では、すべてのロジックは二度実装される。一度はコードに、もう一度はテストに実装される。テストはコードを検査し、逆にコードは暗黙のうちにテストを検査する。バグがアプリケーションコードではなくテスト側にあったというのはかなりよくあることだ。テストを盲信したまま、エージェントがテストのバグをコードに複製する方法を見つけるまで待つわけにはいかない。
ガベージコレクションの例で言えば、もちろんいつかエージェント型システムが何かを立ち上げて、テストハーネスやバグ修正などで叩いて仕上げられるようになるかもしれない。しかし、モデルをガベージコレクタ／ツールそのものとして使うことを想像してみてほしい。たとえば毎回の sweep のたびにプログラムのメモリをモデルに投げ込み、不要なブロックを解放しろと指示するようなものだ。モデルが正しいメモリブロックを正確に識別すると絶対に信頼することはできないし、どんな「パッチ」や「微調整」をしてもそこには到達しないだろう。
JVM のような過去の抽象化では、決定論的な出力、つまりこの場合 JIT が出力するアセンブリに誤りがあれば、そのバグは修正され、その抽象化が二度と同じ欠陥を持つことはない。LLM はそうではない。業界の性格そのものを変えた過去の開発ツールについて語るとき、私にとってこの違いは非常に重要だ。LLM が未来の働き方に深い影響を与えないと言っているわけではない。ただ、歴史的な先例がほとんどない、完全に未知の領域に入っていると見ている。
テスト駆動開発がさらに弾みを得るという話についても、なぜ TDD がソフトウェア構築のあらゆる問題を解決する銀の弾丸であるかのようにいつも提示されるのか分からない。間違ったテストから出発して TDD が間違ったソフトウェアを作った例を見た回数は、正直言って気まずいほど多い。
成果物を明示すべきであって、プロセスを明示すべきではない。貢献者がパッチを理解すべきだと期待するのはよい考えだ。
しかし、オンボーディング期間中のジュニアに LLM 補助ツールをしばらく避けるよう勧めたり要求したりするのはひどい考えだ。オンボーディングにはランダムな環境設定の問題が多く、LLM はこういう場面でかなり強いことが多い。コードやドキュメントに追いつく作業でもあるし、共有したい優れたテキスト検索／要約ツールもある。
人生のあらゆる困難や複雑さを滑らかに取り除いてしまえば、ほどなくして困難や複雑さに直面したとき何をすればよいのかまったく分からなくなる、というのはとても明白に思える。そう思うのは私だけだろうか？
LLM が「一定時間は正解に近いものを近似するが、時間が経つと精度が急落する」という、著者がAI の崖と呼ぶ現象は初めて聞いた。他の人も経験したことがあるのだろうか？
現在の生成器は、時間が経つほど単純にするよりも複雑にする傾向がある。LLM にもっと単純にリファクタリングしろとプロンプトを出すのも、LLM にとって複雑すぎる状態になったときに私自身がリファクタリングするのも、いつも私の側だ。だから少なくとも現世代の LLM では、ただ「LLM に手綱を放して」好きにやらせると、最終的には巨大なルーブ・ゴールドバーグ的なごちゃごちゃを作り出し、あなたがその片づけをする羽目になるのはかなり必然的に思える。
記事の要旨と結びつけるなら、熟練者なら LLM があなたを沖へ引っ張り始めていることを早めに見抜き、少し遠くまで出ても浅瀬へ戻る道を見つけられる。初心者は何が起きたのか理解する前に自分の深さを超えて海で道に迷ってしまう。
コンテキスト入力として 99% 正しい 1 万トークンがあると想像してほしい。LLM は応答するたびに 90% 正しい 1000 トークンを追加する。何度かやり取りして LLM を修正していくと、コンテキストウィンドウはほとんど LLM 自身のかすのような出力で埋まってしまう。さらに悪いことに、誤りは蓄積する。正しい 90% でさえ、間違ったコードについての議論を正しく外挿したにすぎない場合があり、しかも LLM はより新しいトークンをより重要に評価するからだ。同じ問題は散文でも起こる。
思考モデルではこの問題がさらに悪化しうる。思考過程がすべて文脈の中にあり、思考が本当に脇道へそれると、腐敗を育てる毒の種を植えることになるからだ。何らかの形で文脈の剪定を実装して、無関係な文脈が生じたときに切り落とせるとよいのだが。今のところ、腐敗が起きていると感じたら要約を作って新しいインスタンスへ移っている。
claude code、codex、gemini cli のようなエージェント型ツールでは、はるかに少ない問題だ。これらは自分でコンテキストウィンドウを管理し、開発ツールを実行しながら自力で sanity check できるからだ。
この過程は、新しいエージェントが追いつけるように現在の作業状態を文書化する習慣を鍛えてくれる。