- LLMをめぐる現在の議論は、明確な定量的根拠なしに行われている
- 各ユーザーの経験は非常に断片的であり、実際の活用環境や背景知識などの重要な要素がほとんど共有されていない
- 非決定論的な特性により、同じ作業でも時々で異なる結果を示し、信頼性には限界がある
- 業界リーダーによる誇張された主張が、批判なき受容と過度な期待をあおっている状況だ
- 実際に筆者もさまざまなAIツールを日常的に使っているが、望んだ結果を得られるのはおよそ半分という現実的な経験を共有している
LLMをめぐる論争と技術への見方
LLMに対する批判と空気感
- 最近のAI、特にLLM（大規模言語モデル）をめぐる論争では、批判的な見方がしばしば「技術をきちんと理解していない人の意見」として矮小化される空気ができている
- Hacker News などでは、「AIに疑問を投げかけるのは本質を理解していない無知さだ」という反応が繰り返されている
ユーザー間の経験の隔たり
- LLMの実際の有用性について、「ある程度は役に立つ」というユーザーと、「あらゆる試みをしたが大して役に立たない」というユーザーの間で意見の差がある
- この差が生まれる理由は、経験についての具体的な基準と情報が共有されていないためだ
- どのようなプロジェクトで使ったのか
- コードベースの状態（新規プロジェクト、成熟したコード、非公開ソースなど）
- ユーザーの専門性と、その専門性が実際の問題にどれほど結びついているか
- LLMが作成した成果物を実際にきちんと整えて配布するまでに追加でどれだけの労力がかかったかなど、具体情報の不足
経験比較の難しさと非決定論性
- あるユーザーがすべての情報を詳細に共有したとしても、別のユーザーとの経験比較はほとんど不可能な状況だ
- LLMや自動化エージェントは本質的に非決定論的である
- まったく同じ問題に同じやり方で依頼しても、毎回異なる結果になる
- プロジェクトの種類、使うモデル、ツール、言語など変動要因が多く、一貫した検証が難しい
業界リーダーと誇張された期待
- 業界リーダーがLLMの成果を過度に強調する事例は数多くある
- 例：ある業界リーダーが「Claude Code」を使って古いバグが驚くほど簡単に修正できたという体験を、詳細を共有しないまま語り、大衆的な反応を得た
- 具体的なコードの規模、バグの難易度、追加作業の有無、使ったプログラミング言語やフレームワークなど、重要な情報が省略されたまま、非常に肯定的なメッセージだけが広がる
- こうした事例は1,800件以上の反応と204件の再投稿を記録し、誇張マーケティングが容易に拡散していく
使用経験と現実認識
- 筆者もVercelの v0、Claude Code、Midjourneyなど、さまざまなAIツールを毎日活用している
- Swiftの知識がないまま SwiftUI でモニタリングアプリを制作
- Midjourneyでイベント用ポスターを自動生成
- Elixir ベースの MCP サーバー関数のコーディングなどの経験がある
- しかし**成功確率はおよそ50%**にすぎず、成果物は常に一貫していない
- LLMがあたかも魔法のように感じられることもあるが、実際には非決定論的な統計モデルにすぎない
- こうした現実にもかかわらず、業界の議論は**二項対立（魔法 vs. エンジニアリング）**にとどまっていると指摘する
結論
- LLMやAIをめぐる現場では、確実で明確な検証体系がないまま、誇張された想像、期待、信念が好まれる傾向がある
- 批判的思考を止めず、実際の機能と効果を細部まで検証しようとする努力が重要だ
- 議論で重要なのは、具体的かつ定量的な情報共有である
- LLMの限界と可能性を、バランスよく見つめる視点が必要だ
1件のコメント
Hacker Newsの意見
私が働いている会社の経営陣が「生産性が10倍向上する」という話を聞いていて、うんざりしている。うちの会社の初期導入者の中にも、実際にそういう話をする人がいる。だが、その期待値は高すぎる。Amdahlの法則も一因で、私の時間の大半はコーディングではなく、思考とコミュニケーションに使われている。仮にコーディングが本当に10倍速くなったとしても（たいていはそうならない）、全体の生産性向上はせいぜい10〜15%に過ぎない。それでもかなり良い結果ではあるが、10倍ではない
私の今の仕事がややR&D寄りだからかもしれないが、LLMは「思考」の部分でも「コーディング」と同じくらい大きな恩恵がある（コミュニケーションは自分でうまくやっている）。LLMで思考作業をする感覚は、20年前にWeb検索を使いこなすようになった時と似ている。昔の検索エンジンでは何を探すべきか自分で知っている必要があったが、今ではLLMが何を探すべきかまで見つけてくれる（しかも代わりに検索までしてくれる）。以前は難しいと分類していた仕事も、今ではLLMのおかげで簡単に解ける。今ではWeb検索の3分の1ほどをChatGPT o3でやっている。もうこれを手放すことは想像できない。しかも、LLMが私の未完成の考えを整理し、議論相手になってくれるという心理的な要素も大きい。そのおかげで、多くのことがずっと怖くなく感じられるようになり、その差も大きい
うちの会社でも状況は似ている。社内の初期導入者たちが主張する生産性向上は、非常に狭い測り方をしているか、計算そのものがかなり雑なことが多い
LLMはジュニアよりシニア開発者の方に大きな加速効果を与えるかもしれない（ジュニアは良いコードと悪いコードをうまく見分けられないから）。シニア1人が改善されたLLMワークフローを使えば、以前のジュニア10人分の生産性もあり得ると思う。逆に、できない開発者なら実質的に生産性をマイナスにすることすらある（シニアの時間を奪うので）。まともなジュニアであっても、LLMがすでにより上手くこなす反復作業にとどまってしまう。だから、実際に仕事がなくなる可能性もあると見ている
LLMツールを使っても生産性が10〜15%しか増えず、その一方でLLMツールの費用のせいで雇用コストが10〜15%高くなるなら、特別な利点はないと思う。生産の総コストを考えるべきだという立場だ
個人プロジェクトでは簡単に10倍近く速くなる。だが会社では、複数チームとの調整、要件変更、PRレビューなどがあるため、この環境には合わない。このような最適化された設計や標準パターンが可能なのは、小さなスタートアップか個人プロジェクトに限られる。人数が増えれば、それだけで合意形成も難しい。AIが最高の成果を出すにはすべてが標準化されている必要があるが、現実にはすべてが少しずつずれているので、実際の組織ではそこまでの効果は得にくい。少人数の気の合う開発者同士なら10倍も可能かもしれないが、企業環境ではほぼ不可能だ。AIは中間管理やプロジェクトプランニングの方に向いていると思う
筆者が文句を言っている側は私のことだ。ChatGPTがまだかなり未熟だった時代にグリーンフィールドの製品を立ち上げた。その後、ClaudeとWebチャット〜XCode間のコピペを使い、その次にCursorを使った。ビルドエラーはしばしば起きたが、それでも生産性は少なくとも3倍にはなった。今ではエージェントの性能が上がり、Claude 4も出てきたので、私はもうほとんどコーディングしていない。Architect/Managerの役割として、自分の専門知識でエージェントをうまくディレクションしている。スタートアップでここ数か月、一行も自分でコードを書いていない。自分でPRを上げる前にすべて確認し、テストも徹底しているが、Cursor+Sonnetの組み合わせはすごい。行数のようなものは重要ではなく、むしろ長年そのコードベースに関わってきた既存の専門家たちが、細かなバグについて私に質問してくる。Claudeのおかげでフロントエンド開発者の仕事にまで手を出しているので、そこは慎重にしている。ただクエリを投げるだけではなく、綿密なリサーチ、計画、段階的な探索プロセスを踏ませている。ドメイン知識は必須だ。それでも、これほど有効に使えていない人がいるのが不思議だ。こういう記事を毎週2本は見ている気がする
私も似たような経験だが、少し違う環境（PhD学生）にいる。LLMには懐疑的だったが、Claude Code以降、仕事のやり方が完全に変わった。それでもキュレーションは全面的に自分の役割だ（PhD課程で学ぶ重要なソフトスキルでもあるし、LLMは目標やコンテキストをすぐ失ったり覚えていられなかったりするからだ）。正確なコミュニケーションができれば、CCによって以前は不可能だった形で計算を組織できる。プログラミングが簡単になるわけではないが、まったく別の様式が生まれる
LLMが信用できないコードを素早く検査する方法や、LLMがユニットテストも書いているのか、平均的なプロンプト長はどれくらいかなど、実際の検証・確認プロセスが気になる
LLMの出力をそのまま信頼しているのか、という指摘。LLMはプロジェクト全体の文脈を把握できず、でたらめ（ハルシネーション）も多いので、検証が必要だ
LLMのコード品質は全体的にかなり不足していると感じる。何度も反復修正しなければならないので、自分で書いた方が速いことも多い。ただし、大規模な機械的リファクタリングにはエージェントが非常に有用だ。複雑なvim macroやASTスクリプトを書く代わりにエージェントを使っている
何か月も一行も自分でコードを書いていないなんて、個人的にはあまりにも退屈に感じそうだ
ブログ記事で主張されていた内容（検証不能、途方もない成果の主張など）をそのまま再確認してくれている。アカウントも新しく作ったように見える
私の考えでは、実際のサービス産業の労働の大半は、Excelシートを移したり、CRMやメールからExcelへデータを移したりするような手作業だ。大企業には、こういう反復業務をする常勤社員がソフトウェアエンジニアの100倍くらいいるはずだ。だからLLMがOCamlをできなくても問題ではなく、Excelで人間より少しうまくやれるだけで莫大な価値が生まれる。MCPのようなものでメール・CRM・Excelをつないで自動化すれば、エラー率やハルシネーションも大きく減る。人間も非決定的なのだから、こうしたプロセスでは決定論は重要ではない。LLMと暗号資産（crypto）は、ユーティリティや導入の面でまったく違う。スマートフォンの普及を思い出させる。技術職ではない私の友人たちも、今ではLLMを非常に幅広い用途で使っている
暗号資産との比較は建設的ではないと思う。技術的にはまったく関係がない。ただ、技術への過信という現象はある。今では、基本的な自動化にすら触れたことのない人にとって、LLMはSFのように見えるかもしれない。この分野がこれほどメインストリームになったことは以前にはなかった。これからは成功と失敗、さまざまな意見、実戦経験が入り混じるワイルドウェストになると思う。良い点は、友人のアプリのアイデアでも自分で実験できる時代が整ったことだ
手作業でデータを整えるFTE（Full-time Employee）にも、結果の検証、納期遵守、法的責任がある。LLMは一時的な例外状況（たとえば休日だから値が0であるべき、など）を文脈外から把握してチェックしたりはできない。このような検証のためにFTEを1人置く価値は十分にある
ソフトウェアエンジニア1人あたり100人のデータパイプライン手作業FTEというのは、どんな会社に限った話なのか気になる。実際にはバックオフィスやデータ入力業務が大半だとは思わない。AIの波及力には同意するが、ホワイトカラー全体がほぼメール＋データ入力要員だという主張には懐疑的だ
この種の職務の複雑さを過小評価していると思う
退職したプログラマーの立場だが、確率的に生成されたコードにミッションクリティカルな責任を持たせることは想像できない。少し修正すれば使える程度なら理解できる。コーディング以外の分野（ブレインストーミング、創造的思考、リサーチ支援）ではLLMは驚異的だ。私はLLMを思考のパートナーとして扱っている。ミスもあるが、別の情報源で検証したり、別のLLMにレビューさせたりすれば簡単に見つけられる
私も根っから懐疑的な性格だが、実際に使ってみると、あらゆる面で期待を上回った。数時間で、数か月かかるプロジェクトをプロトタイプからリリース直前まで進められた。自分ができることはより速く、自分にできないこと（外注や採用が必要だったもの）まで、些細なコストと短い時間でこなせる。もちろん完璧ではなく、腹立たしい点（明示的な指示を無視する、嘘をつくなど）も多いが、私にとってはゲームチェンジャーだ
LLMを思考のパートナーとして使うのはしばらくうまくいっているように見えたが、ある時点で妄想めいたものが露呈すると感じる。LLMは知識や推論をしているように見せるのが非常にうまい。特に自分が知らない分野ではもっと危険だ。検索エンジンなら情報源ごとに信頼性を比べられるが、LLMではそれができない。ミスを見つけるのもいつも簡単とは限らない
40年選手の開発者だが、数か月前からLLMを使い始めて、仕事のやり方が大きく変わった。ログのエラーメッセージを貼り付ければ1分以内に修正案が出るし、設計のブレインストーミングや新しい解決策の提案もしてくれる。コードは検証しているが、その正確さと知性には毎日驚かされている。（暗号資産とはまったく違う）
LLM懐疑派の立場ではあるが、実のところ人間が書いたコードも本質的にはすべて確率的だ。だからこそコードレビュー、ユニットテスト、ペアプログラミング、ガイドラインが存在する。LLMでも人間でも、出力結果を無批判に使ってはいけない。ただ、LLMは魔法ではないし、役に立つ部分以外では、効率や安全性、リファクタリングのような長期的価値を無視して、ボイラープレートを増やすために悪用されるのではないかと懸念している
私が思うに、LLMが最も得意なのはデータサイエンスだ。I/Oが明確なので結果検証がしやすい。特定のデータの特性を把握していれば、テストコード生成も簡単に任せられる。コンテキストが必要ならClaude Codeが大きな変化をもたらす。例として、PCAPファイル内の各UDPパケットから複数メッセージを抽出し、フィルタリングし、パターンマッチさせ、テスト用に分離する、といったことだ。「これらすべての関数のユニットテストを書いて」と言えば、LLMが自己検証まで可能だ
私は1年前からほぼ毎日LLMを使っていて、90%は私の問題を解決してくれる。AI/LLMに対する否定的な意見を、いつ深刻に受け止めるべきなのかわからない。私の経験では、コードベース全体を投入して魔法を期待するようなことはなく、自分が知っていて理解している、正確で具体的な質問だけを投げ、その解決策を検証可能な形で適用している。こういう使い方でなければ、LLMを誤用している。実際に魔法を体験したいなら、小さく、日常的で、一貫した活用こそが鍵だ
Weathermanのパロディのように「60%の確率で常に動く」と皮肉っている。私もGPTとClaudeをCursorで毎日使っている。GPT o3は一般知識の検索に良く、Claudeはしばしば失敗する。モデル自体は愚かだが、たまに核心を突くこともある。自分が何を求めているかを自覚し、LLMをうまく手なずけられれば、生産的に使えると思う
「自分の経験では90%うまくいく」という主張も、あまり信じられないという意見
筆者は論客たちの不正確な論評に腹を立てているようだ。実際には、LLMの問題点や限界は、日々使っているユーザー＝推進派がよく分かっていると思う。翻訳、文字起こし、コード生成（一定規模まで）など、本来は不可能だったか、ほとんど不可能だった問題が、完全に、あるいはほぼ解決された
翻訳、文字起こし、コード生成は本当に不可能に近かったのか？ Google TranslateやWhisperは、ずっと前から存在していたという指摘
実際の欠陥を明らかにしているのはdetractor（批判者）であり、むしろpromoter（称賛者）の方が、LLMを万能であるかのように無批判に持ち上げている
最近、AGIやAIという用語の使い方が、特に科学論文であまりにも曖昧に感じられる。せめて論文ごとに独自の定義を明確にしてほしいと思う。AGIが何かを明確に定義すれば、あるAIがその定義を満たすことを論理的に証明することもできる。実用性が薄く見えるとしても、無意味な用語よりはずっとましだ。現状では、AGIという定義を示さないまま逃げるように使っている印象がある。「人間と同等またはそれを超える、ほぼすべての認知課題」とWikipediaにはあるが、測定は不可能だ。なぜこんな中身のない用語を使うのか考えてしまう
皆が同じ意味で使う必要はない。AGIという言葉に自分なりの基準を持っていればいい（多数が同意しなくてもよい）。cryptoも私にとってはもともとcryptographyだ。主流の意味と自分の個人的な基準が違っていても構わない
AIに定義があるとすれば、「まだ実現されていないものをAIと呼ぶ」という AI effect の説明へのリンク
最近、会社でLLM活用を始めた。最初の仕事は、2万件の顧客対応コールを文字起こしし、データ抽出することだった（比較対象製品、問題点、代表的な利用事例など）。以前なら数週間かかっていたリサーチが、数時間で終わった。新しい事業戦略まで立て、実際に大きな価値を得た。LLMは自然言語処理エンジンとして非常に優れている。誇張された宣伝も多いが、実際に私たちには実用的な助けになっている。単なるツールにすぎず、誰かに証明する必要は感じない
誇大宣伝が決して無害ではないと思う。市場の歪み、過剰投資、組織縮小、非現実的な期待など、負の波及も引き起こす。こうした記事は市場や期待を冷ますうえで必要だ。LLMを売り込む人たちは、たいてい顧客対応コールの要約ではなく、人員を置き換えるようなあらゆる誇張シナリオを語る
大量データ処理を信頼できる形で解決した経験のない人だけが、LLMに使い道がないと言っているように見える。翻訳でさえ、今でははるかに文脈を踏まえて処理できる
信頼できるテック業界の人たちも、GenAIが開発生産性に大いに役立つと自ら語っている。その意味合いは5%から100%まで幅があるだろう。少なくとも、かなり有用なツールとして受け止めるべきだと思う。この種の主張のために、具体的な数字（コード行数、バイト数、CPUなど）は必要ないと考える
LLM技術にも、結局は正しく使われる場面があるのだろうが、すでにあまりに多くの人が誤用しているため、もう後戻りはできない。数多くの初級開発者がリスクを取って失敗し、膨大な投資が無駄になるだろう。企業も諦められず、すべてを賭けている状況だ