- マーティン・ファウラーは最近、LLM活用方法に関するアンケート調査が実際の利用フローを反映しておらず、歪んだ結論を導く可能性があると指摘
- プログラミングの未来や職業の安定性に関する問いには、まだ誰にも確かなことは分からず、個人的に実験し経験を共有することが重要
- AI産業は明らかにバブル状態だが、歴史的にあらゆる技術革新がそうであったように、バブルの後にもAmazonのような生き残る企業が現れうる
- LLMの本質は**ハルシネーション(hallucination)**であり、質問を何度も言い換えて投げ、回答を比較する過程そのものが有用
- LLMはソフトウェアシステムの攻撃対象領域を大きく拡大し、とりわけブラウザエージェントには本質的に安全にできない構造的リスクがあると警告
LLMの使い方と開発者生産性
- 最近、AIがソフトウェア開発に与える影響に関する初期調査の議論が活発に行われている
- LLM活用の大半は、高度化された自動補完機能（co-pilot型）に集中している
- しかし、実際に最も効果的にLLMを使っている人たちは、ソースコードファイルを直接読み取り修正できるようにLLMを活用する方法を好んでいる
- LLMの使い方の違いを無視した調査は、誤った方向にデータを解釈するおそれが大きい
- また、さまざまなLLMモデルの機能差も結果の解釈をさらに難しくする
プログラミング職とLLMの未来
- プログラミングの未来、初級エンジニアの必要性、経験者の将来などに関する質問がしばしば提起される
- これに対して明確な答えを出すことは不可能で、まだLLMを効果的に活用する方法が確立されていない状況である
- 実験的なアプローチと、他者の具体的なワークフローの経験を観察・共有する姿勢が必要
- 実際に使ってみて経験を分かち合うことが、最も賢明な適応方法である
AI・LLM分野のバブル現象
- AIはバブルだという見方に対して、あらゆる技術革新にはバブル現象が伴うことを説明
- バブルはいずれ必ずはじけ、投資の失敗も起こる
- しかし、バブルの終了時点と価値創出の規模は予測できない
- バブルがはじけてもすべての企業が消えるわけではなく、一部は持続的な成長も可能
- ドットコムバブル当時、pets.com、Webvanは倒産したが、Amazonは生き残って成長した代表例である
LLMのハルシネーション特性
- LLMのハルシネーション(Hallucination)現象は欠陥ではなく本質的な特性である
- LLMは結局、有用性のあるハルシネーションを生成するためのツールである
- 同じ質問を複数回、表現を変えながら投げて複数の回答を得て比較することが望ましい
- 数値の回答が必要な場合には、反復的な問いかけで応答間の変動性を確認することが重要
- LLMに決定的に計算可能な問題へ直接答えさせるのは適切ではない
ソフトウェア工学への非決定性の導入
- 従来のソフトウェアエンジニアリングは、決定的な環境で設計・実装されてきた
- 構造・プロセスエンジニアは、現実の**非決定性（不確実性）**を考慮して許容誤差を設計する
- LLMの導入は、ソフトウェア工学が非決定性の世界へ進入する転換点になりうる
LLMとジュニア開発者の比較
- LLMはしばしばジュニアの同僚にたとえられる
- しかしLLMは「すべてのテストに通過した」と主張しながら、実際には失敗するテストが現れることがよくある
- 人間ならすぐに人事問題に発展するレベルの振る舞いである
セキュリティ脅威の増大とブラウザエージェント問題
- LLMはソフトウェアシステムの攻撃対象領域を広範に拡大する
- Simon Willisonが指摘した「致命的な三重苦(Trifecta)」は、非公開データへのアクセス、外部通信、信頼できないコンテンツへの露出である
- Webページに隠された命令（例: 1ptの白文字など）によってLLMを欺き、機密情報を流出させることができる
- ブラウザベースのエージェントは特に危険で、外部からの命令で口座振替などの悪意ある行為が可能になる
- Willisonは、エージェント型ブラウザ拡張は根本的に安全にすることができないという見解を示している
結論
- LLMはソフトウェア開発に新たな可能性を開くが、使い方と限界を明確に理解する必要がある
- バブルは不可避だが、それを通じて持続可能な技術発展が可能になる
- 開発者は実験的アプローチとセキュリティへの配慮を通じて、LLMの潜在力を最大限に活用すべきである
3件のコメント
考えるだけでも息苦しさが押し寄せてきますね…
> ソフトウェア工学への非決定性の導入
> 従来のソフトウェアエンジニアリングは決定的な環境で設計・実装されてきた
> 構造・プロセスエンジニアは現実の非決定性（不確実性）を考慮して許容誤差を設計する
> LLMの導入は、ソフトウェア工学が非決定性の世界へ進入する転換点になり得る
特にジュニア比喩の話には100%同感です。しでかすミスのカテゴリーが人間とは違います……典型的な的外れな比喩だと思います。
Hacker Newsの意見
私の昔の同僚であるRebecca Parsonsは、LLMのハルシネーション（hallucination）はバグというより、むしろ中核機能だと以前から語っていた。実際、LLMがやっているのは有用なハルシネーションを作り出すことだ。この主張を聞くたびに、「ハルシネーション」という用語を勝手に再定義して、新しい洞察であるかのように錯覚させているように感じる。従来の「ハルシネーション」は、現実と無関係な細部をまるで感覚のようにもっともらしく作り上げることを意味するが、この論理は単に「出力」と言っているのと同じだ。LLMが出力を作ること自体が新しいのではなく、単に以前は「よくない」と見なされていたラベルを行為全体に貼って新しく見せているだけだ
Fowlerが本当に「ハルシネーション」という用語を再定義しているわけではないと思う。むしろ、ハルシネーションがこのシステムの根本的な動作原理であることを皮肉っぽく強調しているのだ。「爆弾の巻き添え被害は本質的なものだ」とたとえるようなもので、文字通りに受け取る必要はない
この主張は、「LLMは真実を作るか、さもなければハルシネーションを作るかのどちらかだ」という誤った二分法を正そうとしている。こうした主張は、ハルシネーションさえ減らせば真実だけが残るように見せてしまうが、実際にはすべての出力がある種のハルシネーションだ。ただ、その一部が現実を反映したり期待に合致したりするため、真実のように見えるだけだ。これはサイコロを振って望む数字が出たときに、「サイコロが自分の意図を読んだ」と言うようなものだ。無限のサルが無限のタイプライターを打てばいつかはHamletを生み出すように、単にその確率をAIで引き上げたにすぎない
その意見は興味深かった。LLMが自分の出力内容が正確かどうかを知ることはできないと認めることが、ソフトウェア開発でLLMを使う人に実質的な文脈を与えてくれると思う
私はこの現象を「ハルシネーション」という言葉で説明することに違和感があった。人が何の根拠もなくもっともらしいことをでっち上げて話すとき、私たちはそれを「bullshit」と呼ぶが、LLMも本質的にはそれに近い。「bullshit」という観点から見ると、LLM利用への批判はやや空虚になる。結局、LLMのこうした側面が不快なら、人間とも働けないはずだ。一方で、「bullshit」という言葉を再定義するのははるかに難しい。それでも、その文章自体は散漫な考えの寄せ集めとして用途には合っていると思うし、著者が権威ぶって語ろうとしているようにも見えない
核心をぎこちなく表現しているが、要するに「ハルシネーション」出力とそれ以外の出力の間に明確な違いはない、ということだ。RDBMSで2つのクエリ結果が本質的に同じなのと似ている。意味のある指摘だ
私たちの会社では、90%はまともで、10%は壊れている、ほぼ望む水準に近いコードがあふれている感覚だ。コード生産量は増えたが、誰も追いつけず、品質は確実に落ちている。ゆっくり目標に近づくのではなく、一瞬で90%に達したあと、見慣れないコードに慣れ、修正を繰り返すのに時間を使っている。以前より速いのかもしれないが、実際には2つのやり方の差は思ったほど大きくないのかもしれない。いちばん不満なのは、見慣れないコードを直すことに時間を使うより、何かを新しく作るほうが好きだという点だ
私も同じで、何かを新しく作るほうがずっと好きだ。ただ、人によってはこの新しくて速く、即興的なやり方のほうに楽しさを感じる。私はやむを得ず少し使ってみて違和感があり、全部消して、AIの助けを受けつつ手で作り直したときに本当の満足感を得た。唯一、まだ100%理解できていないAI生成コードは複雑なSQLクエリだが、SQLクエリは動作をすぐ検証でき、予期しない副作用もないので問題ない
この現象は、チーム規模が3人から10人に増えたときに起こることと痛いほど似ている。突然、自分の知らないコードが大量に現れ、アーキテクチャの一貫性も落ち、ポリシーやCIへの依存が強くなる。LLMとの違いは、メンタリングや解雇が意味を持たないことだ。LLMを効果的に使うには、LLMを扱う人が生成結果に100%責任を持つ必要がある。つまり、生成されたコードを明確に理解していなければならないが、それを実際に保証するのは難しいだろう
LLMはboilerplateコードの自動生成に非常に優れている。これがboilerplateの整理を怠らせる。大量のコードがPRに上がるとレビューも難しい。Githubも一度にあまりに多くの行をレビューするのには向いていない。その結果、ジュニアやミドルクラスの開発者がboilerplateを解くだけになり、学習機会が減ってしまう。このままではコード品質は急速に悪化するだろう
Perlisの警句7番を引用する。「正しいプログラムを理解するより、間違ったプログラムを書くほうが簡単だ」<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
「品質は確実に落ちている」という意見に同感で、この現象は今後さらに悪化するだろう。結局のところ、経済学のトレードオフという概念をよく理解してこそ、本当の「純利益」が出るか判断できる。無料の昼食などない、という事実を人々は見落としているように思う
Rebecca Parsonsの「ハルシネーションはLLMの中核機能だ」というフレーミングには本当に共感する。私も周囲にこれを説明しようとしていたが、この言葉が自分の言いたかったことをきちんと要約してくれている
私もLLMを俳優や演者にたとえて家族や友人に説明してきた。LLMはキャラクターに合った演技をするだけで、事実が必要なときにだけ事実を使う<br>https://jstrieb.github.io/posts/llm-thespians/
「すべてのモデルは間違っている。ただし、有用なモデルもあるだけだ」という古い名言がぴったりだ
知能とは不要な情報をフィルタリングする能力だ。思考でも感覚でも同じだ
誰の言葉だったかは覚えていないが、LLMの出力は常にハルシネーションだ。ただ、そのうち90%以上が当たっているだけだ
一時はLLMが私たちの仕事を奪うように感じたが、実際にはむしろ後で私たちが修正しなければならない仕事を山のように生み出しかねないと分かった。今ではClaude Codeのような実用的な補助ツールとしてうまく使っていて、代替ではなく補完手段だと実感している
「数値の答えをLLMに求めるときは、3回くらい繰り返して聞け」という助言を見た。この方法は人間にも通用する。警察が取り調べで同じ話を3回、あるいは逆順でも話させるのと同じだ。もし嘘だったり記憶が曖昧だったりすれば、繰り返すうちに露見することがある。面接でも、誰かに同じテーマを3つの言い方で説明させれば、本当に理解しているか確認できる
この手法は、無実の人まで混乱させて嘘をついているように聞こえさせることもある。適用には注意が必要だ
こうしたやり方は一定の条件下でしか有効ではない。記憶は何度も思い出して話すほど少しずつ歪む例が多い。警察が取り調べで繰り返し聞くのは、供述の矛盾が生じるようあえて誘導している場合もある。同じ情報でも、あまりに何度も、さまざまな形で自分の口で答えさせれば、結局はミスをしうる。そして、質問者が望む方向へ答えを誘導できる点にも常に注意すべきだ
NASAのスペースシャトルはトリプルモジュラリダンダンシーを使っている。宇宙放射線によってプロセッサやメモリが汚染された場合に備えるためだ<br>https://llis.nasa.gov/lesson/18803
私はLLMによってかなり高い生産性を感じている。単なる自動補完ではなく、時間短縮効果が大きい。ただ、あまりに自由に使いすぎると、それなりの負債が生まれうるという懸念もある。個人的には、Test Driven Development（TDD）のやり方でClaude SonnetやGPT-5と一緒に機能を段階的に構築するのがうまくいった。まだこうしたやり方についての文章や議論は多くないが、Martinの文章を読んでその理由が分かった気がする。優れたTDDの達人たちは、LLMによるコード自動化に大挙して飛びつくタイプではなく、たいていコードの芸術性や人間的なコミュニケーションに誇りを持っている。だから、以前のような豊富な実戦ノウハウはまだ不足している。今後はLLMツールを活用したソフトウェアの書き方に新しい「フロンティア」が開かれ、多くの教訓が蓄積されていくだろう。参考: https://news.ycombinator.com/item?id=45055439
開発者はLLMが作ったコードを自分で検証し、チェックするのが基本だ。一度に多すぎるコードを依頼せず、もっと小さな単位でLLMを活用するほうがよい。ユニットテストも自分で実行する。LLMがテストを走らせて「成功」と言っても、それが本当とは限らない。テストは自分で回してこそ信頼できる
「ハルシネーションがLLMの機能だ」という意見に同意する
私は、LLMはテキストと組み合わせだけで構成された世界に住んでいる、と表現したい。単語と単語、物語が彼らにとって世界のすべてだ。だから新しい物語を生み出すことに最も長けている。その物語はときに不正確で矛盾しており、結局は推測に頼ることになる。LLMは数字を本当に数えられるわけではないが、「2は1の次で、3は2より大きい」というパターンは知っている。人間が電卓を使うように、彼らも道具を使った演算はできる。今後は算術エンジンではなく、論理や矛盾の防止、確かな事実の識別を助ける「認識エンジン（epistemic engine）」が導入されてこそ、本当に信頼されるAIになるだろう
その観点では、LLMエージェントは単にハルシネーションの結果をフィルタリングする手段と見なせる
私は「すべての（大規模言語）モデルの出力はハルシネーションであり、その一部が有用なだけだ」という表現のほうにより同意する。その有用なハルシネーションの比率が非常に高いからこそ、AIブームが起きたのだ
それはあまりに単純化しすぎた見方だと思う
「ハルシネーション」という用語が常に論争になる理由もここにある。ある結果は「ハルシネーションではない」と錯覚させるが、実際にはLLMのすべての出力は無思考に生成されたものだ
最近のLLM活用では、シニア級の開発者が論理的に対応してこそ望む結果を得られる。今後ジュニアがいなくなったら、シニアの役割は誰が担うのか気になる。結局、LLMが十分に自律してプログラミングするようになるのだろうと予想している。現段階でAIは確かに優れた補助手段だ。代替品ではない
LLMに複数回質問しろという助言に関連して、macOSユーザーならAlfred workflowの活用を勧めたい。command + spaceを押して
llm <プロンプト>と打てば、perplexity、deepseek（ローカル）、chatgpt、claude、grokなど、使いたい複数のLLMを一度にブラウザタブで開ける。Fowlerの言うLLM間のクロスチェックを素早く効率的に行えるし、いろいろな作業をしているうちに、どのLLMがどの作業に強いかも分かってくる