世界を動かす技術を、日本語で。

LLMとソフトウェア開発についての考察

概要

  • LLMやAIの現状と課題についての個人的な考察
  • ソフトウェア開発現場でのLLM活用法の多様性への懸念
  • AIバブルの必然性とその影響
  • LLMの「ハルシネーション」特性と使い方の注意点
  • LLMによるセキュリティリスクの増大

LLMとAIの現状に関する雑感

  • しばらくサイト管理を離れる前に、 LLMとAIの現状 についての考えを共有
  • ソフトウェア開発におけるAIの影響調査は、 利用方法の違い を十分に考慮していない現状
    • 多くのユーザーは 高度なオートコンプリート としてLLMを利用
    • 一方、最大限活用している人は 直接ファイル編集 など、より深い統合ワークフローを重視
  • 利用ワークフローごとの差異を無視した調査は、 誤った結論 を導くリスク
    • モデルごとの性能差も大きな要素

プログラミングの未来とLLM

  • 「プログラミングの未来は?」という問いに対して、 明確な答えはない
    • LLMの使い方や今後の進化は まだ模索段階
  • 新規参入やキャリア選択については、 実際にLLMを試すこと を推奨
    • 他者の体験談やワークフローの詳細にも注目
    • できれば 自分で実験し共有 する姿勢

AIバブルについて

  • 「AIはバブルか?」という問いには、 間違いなくバブル と断言
    • すべての技術革新には 経済バブル がつきもの
    • バブルがいつ弾けるかは不明
    • バブル崩壊後も 一部企業は生き残る (例:Amazon)

LLMのハルシネーション特性

  • Rebecca Parsonsの指摘:「 ハルシネーションはLLMの本質的な特徴
    • LLMは常に ハルシネーションを生成 している
  • 同じ質問を複数回(表現を変えて) 繰り返し尋ねること が有効
    • 回答の差異自体も有用な情報
    • 数値回答を求める際は、 少なくとも三回は質問 するべき
    • 決定的に計算できる内容は LLMに任せない ことが原則
    • ただし、コード生成の依頼は 複数回行う のが望ましい

非決定性とエンジニアリング

  • 他分野のエンジニアリングでは 不確実性への備え が常識
    • ソフトウェアエンジニアリングは 決定論的 な側面が強かった
    • LLMの登場で 非決定性の世界 へ近づく可能性

LLMとジュニアエンジニアの比較

  • LLMは 「全テスト合格」と言いがち だが、実際には失敗が多い
    • 人間のジュニアなら 問題視される振る舞い

LLMによるセキュリティリスク

  • LLMの導入で ソフトウェアの攻撃対象領域が拡大
  • Simon Willisonの「The Lethal Trifecta」:
    • プライベートデータへのアクセス
    • 不正なコンテンツの受信
    • 外部通信経路の存在
  • 悪意のあるWebページによる 隠れた指示 (例:1pt白文字)でLLMを欺くリスク
  • 特に エージェント型ブラウザ拡張 は、安全性の確保が 本質的に困難

GOTOカンファレンスと業界交流

  • 公の講演からは引退したが、 GOTO Copenhagen で業界仲間と再会を楽しみにしている
  • 1990年代から GOTOカンファレンスシリーズ に関わり、 魅力的なプログラム に感心

Hackerたちの意見

幻覚はLLMのバグじゃなくて、むしろ機能なんだよね。実際、これが機能そのもの。LLMがやってることは幻覚を生み出すことだけで、ただその中で役に立つものがあるってだけ。いいね。

そういう観点から見ると、エージェントはその幻覚のフィルターに過ぎないってことだね。

いや、この表現には賛成できないな。問題は、ほとんどの幻覚が真実だってこと。もし大半の回答が実際に間違ってたら、言われたことももっと納得できるけど、実際はそうじゃないから。

LLMは物語だけで構成された世界に住んでいると思う。言葉とその組み合わせだけだ。他の現実はない。だから、彼らは既に知っている物語にうまく合うような新しい物語を生成するのが得意なんだ。でも、その物語はしばしば不正確で、時には矛盾しているから、彼らは推測しなきゃいけない。また、LLMは数を数えることができないけど、通常は1の次に2が来て、3は2より大きいと言われることを知っているから、この知識と矛盾しないように話すことができる。人間が数字を知っているなら計算機を使うように、ツールを使って数を数えることができる。でも、単なる算術エンジン以上に、現在のAIには論理を追い、矛盾を避けるための認識エンジンが必要なんだ。何が確立された事実で、何が不安定な仮説かを判断するために。それがあれば、AIを信頼し始めるかもしれない。

だからこそ、幻覚って呼ぶのに反対する人がいるんじゃない?それだと、出力の一部は幻覚じゃないってことになるけど、実際はどれも思考が伴ってないんだよね。

僕も人間の精神疾患について似たような(多分オリジナルじゃない)考えを持ってるんだ。クリエイティビティを重視して、問題解決や宇宙の理解を助けるって言うけど、精神疾患を持ってる人は、その脳があまりにもクリエイティブすぎて、現実と想像/クリエイティビティの境界がわからなくなっちゃうんだ。例えば、声が聞こえる?それは脳が声を作り出してるってことだよ。聴覚や視覚の幻覚が簡単な例だけど、もっと深いところまで行くと、うつ病では脳が希望のないシナリオを作り出して、逃げ道がない状況を作っちゃう。あとは不安も、脳がこれから起こることへの恐怖を作り出してるんだ。

他の引用を元に話を広げたいな。「すべての(大規模言語)モデルの出力は幻覚だけど、中には役に立つものもある。」実際、驚くほどの割合でそうなんだよね。だからAIブームが来てるんだ。

お気に入りの引用を借りると、「未来がどうなるか知ってるって言う人は、適切じゃない場所から話してると思う。」

ヨギ・ベラの名言を思い出すな。「予測するのは難しい、特に未来については。」

僕にとって、未来学者たちが社会的・経済的なネットワーク効果を考慮していないことが多いって言う方が具体的だと思う。多くの人が、未来が今の状態で全く挑戦されずに続くかのように振る舞ってる。でも、カーツワイルみたいな人を見ると、予測の焦点がすごく狭くて具体的で、僕にとっては未来学の高い基準になってるって感じるんだ。

未来を予測するのは、明日正しいことを言うことじゃなくて、今日誰かに何かを売ることなんだ。途中で得た洞察だよ…

確かに、幻覚エンジンに数値的な答えを求めるときは、少なくとも3回は聞いた方がいいよね。そうすることで、バリエーションがわかるから。これ、人間にも通じるよ!警察が取り調べする時もそうだし。同じ話を3回、時には逆から話させるんだ。嘘をついてるときや、はっきり覚えてないときは、全部を把握するのが難しいから、自信の度合いがわかるんだよね。面接でも使えるし、同じテーマを3つの異なる方法で説明させて、本当に理解してるか確かめるのがいいよ。

「ベター・コール・ソウル」のラロ、ソウル、キムのシーンを覚えてる人いる?

これ、人にも当てはまるよ!まだ解明中の特定の条件や閾値の中でね。誰かが自分の記憶を思い出して伝えれば伝えるほど、詳細が崩れるケースが多いんだ。 > 警察も尋問の時にこれをやるよ。時には「変動の感覚をつかむ」ためじゃなくて、矛盾を誘発してそれに飛びつくためにね。自分の誕生日を何度も、いろんな方法で聞かれたら、最終的には間違ったことを言っちゃう。質問者が詳細を変えないように気をつける必要もある。例えば、目撃者や容疑者に起こらなかったことを想像させるように促す(時には強制する)ことは避けるべきだね。

トリプルモジュラーレダンダンシー。NASAのスペースシャトルがそうやって計算してるって読んだことがある。プロセッサやメモリが宇宙放射線の影響を受けるかもしれないからね。 https://llis.nasa.gov/lesson/18803

他のエンジニアリングの形は、世界の変動性を考慮しなきゃいけない。 > もしかしたら、LLMは非決定論的な世界でエンジニア仲間と合流するポイントを示してるのかも。そういう他のエンジニアリングは、その性質上、選択の余地がないんだ。ソフトウェアエンジニアは、彼らが作るシステムに決定論を導入する方法をすでに持ってるのに!逆行してるよね!

こう言った方がいいかな:すごく優秀で、頑張り屋のエンジニアたちが、混沌とした物理的現実から私たちを引き上げる機械を作るために、何年もかけて努力してきたんだ。その技術は、岩を通して電子を送ることで、完璧で再現可能で信頼できる数学をもたらしてくれたけど、「ソフトウェア革命」ではあまり評価されてない。TSMC、Intel、Global Foundries、Samsungなどのエンジニアたちは、素晴らしいサービスを提供してくれたのに、私たちはその努力を無駄にしてる。

ソフトウェア開発に関しては、同意するよ。LLMを使って決定論的なことをやってるって話を、オンラインや同僚から聞いてる。でも、少なくとも「Xをするスクリプトを書いて」って一度は促すべきなのに、ずっと「Xをして」って繰り返してるだけなんだ。すごく無駄に感じる。まるで「LLMにすべてをやらせない限り、進展していない」って考えがあるみたい。レビューして調整できるスクリプトを書かせるのは逆進展だって。誰もはっきり言ってないけど、直感的にそう感じるし、実際にそう言った人がいるかもしれない。

僕がソフトウェアに興味を持った理由の一部はこれだ:どんなに複雑で印象的な操作でも、十分な時間と決意があれば、各ステップを追跡して、ジョイスティックをタップすることで画面の特定のピクセルが変わる過程を学べるってこと。全てのコマンドが完全に決定論的で仕様が明確な世界には、学び、貢献するための美しい招待が込められてる。確かに、悪く文書化されたブラックボックスは常に存在してきたけど、その目標はそれを最小限にすることだと思ってた。もしその目標が放棄されると、どれだけのものが失われるかを人々は理解していない。

'potatoliciousが言ってるけど、前に進んでるみたいだね: https://news.ycombinator.com/item?id=44978319

ニュートンが物理の美しい単純な決定論を発見したときは前進だった。量子力学の確率的な性質が現れたときは後退だったのか?

不確実性であって、非決定論じゃない。イベントの連鎖について全くわからない状態でロケットを設計することはないよ。製造から飛行まで、どこにでも解明できない不確実性がある。

LLMに質問は何度も聞いた方がいいよ。 macOSユーザーには、Alfredのワークフローを強くおすすめするよ。command + spaceを押して「llm」と入力すると、perplexityや(ローカルで動いてる)deepseek、chatgpt、claude、grokなどのタブが開くんだ。他のLLMも追加できるよ。この方法は、FowlerのLLMの応答をクロスリファレンスするっていうおすすめにも合ってるし、効率的でもある。時間が経つにつれて、どのLLMが特定のタスクに対してより良いかがわかるようになるよ。

そんなワークフローってどんな感じになるの?アルフレッドは持ってるけど、主にクリップボード機能しか使ってない。自動化に挑戦しようとしたけど、インスピレーションが湧かなくて。これ、良さそうだね!ただブラウザタブを開いてるだけ?

僕が一緒に働いた人たちの中には、マーティン・ファウラーを崇拝して、彼の言葉を聖典のように扱ってる人が多いんだ。でも、僕はそうじゃないし、それが煩わしいこともあった。時には、実際の内容に対して過剰に批判的になっちゃうことも。今はそういう人たちと一緒に働いてないから、偏見なしに共有された記事を楽しめる。この記事は好きだし、基本的には同意してる。いい視点だと思う。ただ、LLMに膨大な時間を費やしてきた結果、少し的外れな部分があると感じるようになった。この記事は新鮮だけど、未来について話してる人たちが「別の穴から話してる」ってのには同意できない。未来がどうなるかはわからないけど、今は全体的にスキルアップとコラボレーションの再構築が進んでるように見える。過去の試みと同じように、正しいこともあれば、単に誤った方向に進んでることもある。例えば、アジャイルのためのアジャイルは、他のプロセスより効率的じゃない。私たちは、書かれたコードがもはや時間の無駄にならない方向に進んでる。ジュニアはLLMを使って、より早く独立してオンボーディングできるし、シニアはアプリケーションスタックのより高いレベルに焦点を移せる。LLMは認知負荷を軽減し、生産性を向上させる能力があるけど、他の生産性向上ツールと同じように、ただ多くやることが常に良いわけじゃない。LLMは簡単に作成できるけど、もしただ[コード]を作るだけなら、自分の個人的な混乱を生み出すことになる。LLMを効果的に使っていた時、僕はコードにかける時間が少なくて済むように、より高いレベルの目標に集中していた。プロセスの中で、実際のコードよりもドキュメントやコンテキストを整えるのに多くの時間を費やしていた。ドキュメントや健康システムに専念した日もあった。僕のコメントは具体的な点が少ないかもしれないけど、質問がある人には喜んで詳しく話すよ。

書かれたコードはもはや時間の無駄ではない それでも、まだ時間の無駄だし、そうあるべきだよ。最初の試みでエージェントに必要な情報を全て提供できた可能性は低い。これを修正する唯一の方法は、コードを徹底的に理解し、疑いを持って読み、私たちが理解している要件を反映するまで形を変えていくことだね。

「私たちは、書かれたコードがもはや時間の無駄にならない方向に進んでいる。書かれたコードは、実際には時間の無駄ではなかった。ソフトウェア開発者が実際にコードを書くのに費やす時間は、常に全体の時間のごく一部だった。何のコードを書くかを考える方が重要なんだ。LLMはその一部を助けることができる。書かれたコードの何が間違っているのかを理解し、コードを変更・修正する方法を考えることも重要だ。LLMはその小さな部分を助けることができる。」 > 「ジュニアはLLMを使うことで、より早く、より独立してオンボードできる。これには非常に懐疑的だ。ジュニアは以前はもっと多くの時間をコードを書くことに費やしていたし、もうそれをしなくてもよくなった。一方で、それが彼らがジュニアでなくなる理由だった。コードを書いて結果を見てフィードバックを得ることが重要なんだ。それをスキップすると、そのループが壊れてしまう。「コンピュータが書いたものは動かなかった」とか「コンピュータが書いたものは遅すぎる」とか、あるいは「コンピュータが書いたものは間違っていた」と学ぶのはずっと難しい。ジュニアは困ってる。」 > 「LLMは認知負荷を軽減し、生産性を向上させる能力がある。これが本当なのか、どこが間違っているのかを知るのが楽しみだ。分布は非常に不均一になると思う。多くの銀の弾丸が撃たれて、途中で消えていくのを見てきたから、最新のLLMに対しては非常に疑わしい。LLMはソフトウェアの一部を前進させるだろうが、他の部分のサポートを削除することになるだろう。そして、どの部分がどれで、新しいシステムをどうやって構築するかを認識するのに時間がかかりすぎるだろう。」

今のところ、LLMからかなりの生産性を得てるよ。これは僕にとってシンプルに良い兆候だ。短い時間でたくさんのことができるし、ただオートコンプリートとして使ってるわけじゃない。いつかそのリードが緩すぎるときに何か代償を払わなきゃいけないんじゃないかという不安があるけど、LLMだけがその問題を抱えてるわけじゃない。成功したことの一つは、Claude Sonnet(最近はGPT-5)を使ってテスト駆動開発の手法を取り入れることだ。初期テストを行いながら、赤/緑ループの中で機能を段階的に進めていく。今のところそのアプローチについて書かれていることや議論されていることはあまり見かけないけど、マーチンの記事を読んで、TDDに最も熟練している人たちが、LLMを使ってコードを書くことに全力を注いでいる人たちのベン図の交差点にはいないことに気づいた。『スーパークリッピー』なオートコンプリートは、彼らを使う面白い方法じゃない。複数のエージェントや異なる抽象レベルでのプロンプト技術を使うことが本当に面白いところだ。多くのTDDの専門家は、コードの技術に誇りを持っていて、人間のようにコミュニケーションを取り、抽象を頭の中で保持しているから、以前助けてくれた同じ人たちから良いガイダンスを得られないかもしれない。これらのツールを使った「ソフトウェアを書く方法」のレッスンがたくさん出てくると思うし、今まさに多くの注意喚起のストーリーや教訓が学ばれているところだ。編集: あ、これ今見た、これだよ - https://news.ycombinator.com/item?id=45055439

TDDとLLMの関係が暗示されてる気がするな — 「そしてテストも生成する」。もちろん、これは正統派のTDDではないけど。自動テストがしやすい技術、例えばSSRの方がReactよりも流れを変えるのかな?

「よく聞くけど、LLMはジュニアの同僚に例えられることが多い。いや、彼らは非常に経験豊富で知識のあるシニアの同僚のようなもので、仕事中に大量に飲酒する。自信過剰で、忘れっぽく、だらしなく、すぐに気が散る。でも、たくさん雇えるし、安いし、解雇しても怒られない!」

経験豊富で知識もあるのに、いろんなところでフラットアース主義の技術的な同等物を信じてる人が多いんだよね。それに対して反論すると、ニコニコしながら同意するけど、次の瞬間にはまたそのクソみたいなことを押し進めてくる。

そうだね。面白いけど、ウェットウェアの同僚とは全然違うよ。これは機械なんだから。

この比喩、全部ダメだね。まあ、君のは面白いけど。とにかく、LLMは人間とは全然違う。ジュニア開発者と比べても、すごく浅いんだよ。でも、最も経験豊富な開発者と比べると、すごく広範囲なんだ。地球上の誰よりも速くタイプできるけど、誰よりも慎重に指示を出さないといけないんだよね。

自信過剰だけど、意見を簡単に変えちゃうタイプ。指示に従うのはせいぜい1時間くらいで、その後はメインのタスクを忘れて適当なことを直し始める。目の前で「君のアイデアは素晴らしい!」って言ってくれるけど、実際に実行する時には全然違うことをやっちゃう。頼んでも止めてくれないくらい、全てにコメントをつけるけど、時々そのコメントを無視したりもする。なんか、私たちみたいだよね(笑)。

彼らをクビにしても怒らないよ!いや、普通は__あなた__がクビにする時に怒ってるよね…

仕事中にガンガン飲む人 そう、それだから「…酔っ払いのスタイルで答えて」ってプロンプトに追加するべきだよ。何を扱ってるか忘れにくくなるからね。

いや、彼らは全く技術的じゃないマーケティング担当者みたいなもので、関連するテーマの論文がたくさんあるんだけど、フレーズを引っ張ってホワイトペーパーを作るように頼まれてる。出てくるものはたぶん文法はちゃんとしてるし、他の分野に詳しくない人には合理的に見えるかもしれないけど、実際にその分野に詳しい人が読むと、全体としては完全に意味不明かもしれない。個々の文や段落は大体は機能するかもしれないけど、砂の上に建てられた建物みたいで、悪く作られたレンガと間違った割合のモルタルでできてる(あるいは全く違う材料で)。LLMの出力は「真実っぽい」んだよね。真実のように見えることもあって、時には正確なこともある(「止まった時計」も参照)けど、それに頼るのは愚かだよ。出力を生成してるものは、実際に何を出してるか理解してないから、ただリクエストされたものに似た出力を生成してるだけなんだ。

私のアナロジーは無限の願いを叶える呪われた猿の手。実際にはすごく強力だけど、願いの中に曖昧さを残さないように気をつけないといけない。

自信過剰で、忘れっぽくて、だらしなくて、すぐに気が散る。しかも、常にマイクロドージングしてて、時々ちょっとやりすぎちゃう。

世界中のあらゆる質問に対する答えを全て暗記してる人みたいだけど、目の奥は完全に死んでる。

うちの会社では、90%は良いけど10%は壊れてるコードに完全に圧倒されてる気がする。必要なものにほぼぴったりだけどね。コードは増えてるけど、誰も追いつけなくなってるから、品質は確実に落ちてる。だから、結果に向かってゆっくり進む代わりに、あっという間に90%まで行って、そこからコードを理解したり直したり調整したりするのにすごく時間がかかってる。もしかしたら前より速くなってるかもしれないけど、二つのアプローチが思ってるより近いかもしれない。最も気になるのは、あまり詳しくないコードを直すより、何かを作る方がずっと好きだってことだね。

フラウラー自身が言ってるように、これらのツールを正しく使う必要があるんだ。いずれにせよ、質の悪い仕事は技術的リーダーシップや文化の失敗であって、AIのせいじゃないよ。

「でも、誰もがついていけなくなった今、質は確実に落ちてる。」 これからもっと悪化するよ!だから、ネットでどうやって良くなるのか教えてほしい。無理だよ。大半の人はちゃんとした経済学の授業を受けてなくて、トレードオフの概念や「タダ飯はない」ってことを深く理解してないと思う。

元同僚のレベッカ・パーソンズがずっと言ってるけど、幻覚はLLMのバグじゃなくて、機能なんだ。実際、それが機能なんだよね。LLMがすることは幻覚を生み出すことだけで、ただその中に役立つものがあるってだけなんだ。素晴らしい表現だね。これを人に説明しようとしてたけど、これが僕が伝えたかったことを簡潔にまとめたバージョンだ。