1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • 過去18か月に観察した、または参加を依頼されたAIプロジェクトの成功率は 0% であり、技術の不確実性と既存ソフトウェアプロジェクトのずさんな運営が重なって、投資は成果につながらなかった
  • 従業員500人以上の組織では、AIの有効性に疑問を示すだけで昇進や雇用が危うくなり、従業員は AIウォッシング やトークン使用量の操作によって組織の要求に従っている
  • 自然言語によるデータ問い合わせのような派手な AIデモ は、精度や運用上の限界を警告しても購買熱を引き起こし、売り手に評判・法的リスクまで招きうる
  • 顧客と取締役会が互いの誇張された生産性主張を否定できない 調整問題 のため、懐疑的な役員でさえAI投資を公に支持し、非AI事業にも無理やりAI要素を付け加えるようになる
  • 組織を立て直すには 1対1の対話・匿名アンケート・現場検証 が必要であり、社内政治を避けにくい従業員はAI生成コードで燃え尽きる前に転職や契約社員化を準備すべきである

18か月にわたって観察されたAIプロジェクトの失敗

  • 過去1年間、会社の営業と大半の技術業務を担い、世界中の専門家と約 300回対話 した経験から、民間・公共組織の責任者たちは計画なしにAIにのめり込むか、沈黙していた
  • AIプロジェクトの実際の成果を確認しにくいのは、取締役会・経営陣・従業員・ベンダー・コンサルタントの誰にも失敗を公表する動機がないためである
    • 経営陣は失敗を認めれば地位を失いかねない
    • 従業員は解雇やリストラの対象になりうる
    • 一部の上場企業はCopilotライセンスを購入した後、それを AIによる生産性向上 として発表している
  • 観察した、または参加を依頼されたプロジェクトは18か月のあいだすべて失敗しており、チームはAI実装業務を全面的に断り、OpenAIの存続可否に直接左右されない契約だけを維持した
  • AIツールが特定の作業を速めたとしても、現在の投資手法と規模は妥当ではなかった
    • 通常のソフトウェアプロジェクトにおけるあらゆる失敗要因がそのまま存在する
    • 新しい技術という追加リスクのため、実装を正しく行っても失敗しうる
    • このリスクを引き受けられるほどソフトウェア提供能力に優れた企業はまれである

社内向け・顧客向けチャットボットが成果を出せない理由

  • 社内チャットボット は企業文書の品質が低く、十分な回答を作れず、実際の従業員利用率も有意なものではなかった
  • 顧客向けチャットボットでも満足できる事例はまれで、医療診療中のリアルタイム文字起こし程度が例外だった
  • プロジェクト責任者たちは、ツールが実際に使われているかを示す基本指標を避け、簡単に操作できる指標を選ぶ
  • Mitsubishiの自動車故障支援音声ボットは、自然な音声、速い応答、実運用環境という点で完成度が高かったが、約束された返答は 6か月間来なかった
    • 依頼自体が消えたのか、人の介入なしに解決したものとして集計されたのかは分からなかった
    • システム上の不具合が見えなくても、顧客はMitsubishi車を再び購入しないと判断した
  • 進行中のAIプロジェクトの目標・利用者・成果を問うだけでも責任体制への攻撃と受け取られかねず、危機が訪れる前には介入しにくい
  • コンサルティングは相手が求めたときに人へ影響を与える行為だというGerry Weinbergの原則に従い、一般的なデータ戦略について明示的に助言を求められない限りプロジェクトに介入しない

疑念を許さない組織文化

  • 従業員500人以上の観察対象企業ではすべて、昇進と雇用維持のために AIの変革的な力を繰り返し宣言 する必要があった
  • それは技術的な活用案を提案するレベルではなく、宗教的な信仰告白に近く、主に非技術系人材が主導し、一部の技術者も同調していた
  • 「AIがすべてを変える」と言いながら、組織内でのLLM活用事例や変化した点を一つも示せない場合があった
    • 年商 20億ドル以上 の組織でAI中心の技術戦略を作った役員が、ChatGPTを含むAIツールを一度も使ったことがなかった事例もあった
  • 単なる広報目的の嘘よりも、技術的背景のない責任者が自分の言葉を本当に信じている場合のほうが危険だった
    • 嘘をつく人とは私益を媒介に交渉できるが、本物の信奉者は自分の利害でも揺らがない
    • ある組織は、LLMなしで高い成果を出していたという理由でトップパフォーマーたちを解雇した
  • “My AI Skeptic Friends Are All Nuts” と批判的立場は異なっていても、経営陣による LLM使用義務化は悪い戦略 であり、専門職の従業員に異常な作業制約を課す点では一致している

AIウォッシングと操作可能な評価指標

  • 管理者が結果よりAI使用の有無を重視するようになると、エンジニアたちは従来の方法で仕事をした後、それをClaudeが行ったと報告する AIウォッシング を始めた
  • 一部の組織では、トークン消費量が多いほど高く評価するランキング表を運用している
    • システム最適化能力を見込まれて採用された従業員たちは、LLMが自分でプロンプトを繰り返すよう設定した
    • 出力物がデプロイに不適切でも、トークン使用量だけ満たした後は別の仕事をしていた
  • あるソフトウェアエンジニアは、GoリポジトリのコピーをAIに渡して全体をZigで書き直させたうえで結果を捨てる方法で使用量ノルマを埋めていた
  • 実際に解雇対象となったのはAI戦略に目立つ疑問を投げかけた人たちであり、従業員は経営陣のAIビジョンを称賛するのが安全だと学習した
  • 病院や土木企業の非専門経営者が現場の専門家の同意なしに具体的な手順を強制しないのと同様に、非技術系の経営陣がソフトウェア専門家に特定ツールを義務づけるのも不適切である

Snowflake Cortexデモが引き起こした購買熱

  • Snowflakeは従量課金で、一般的な企業データは1日1分ほどで処理できるため分析用データベースとして活用されていたが、AIチャットボット層である Cortex は使われていなかった
  • Cortexはデータ列の意味といったメタデータをもとに、「先週の売上はいくらか?」のような自然言語の質問をデータベースクエリに変換する
  • Snowflake社員の発表では、最適設定での精度は約 92% であり、大企業データでは数字10個のうち約1個が誤る可能性があり、デプロイ管理にも深刻な問題があった
  • 本番環境には適さないと警告したうえでデモを見せたが、消極的だったすべての見込み顧客が即座に購入を望んだ
    • 非AIの方法で数百万ドルの価値を生み出せるという提案も関心の外へ追いやられた
    • 合理的判断の空白を利用するのは無責任だと考え、販売を中止し、Cortexをデモ一覧から外した
  • チームが2時間で作った低品質なデモでさえ、見込み顧客がそれまで見てきた成果物より優れていた
    • すでにAI活用を宣伝していた ASX上場企業 でさえ、既存投資で示せる成果物がなかった
  • AIに一時的な好奇心以上の関心を示した見込み顧客は、販売過程で非合理な行動と崇拝に近い管理環境を露呈し、契約が評判・法的リスクを生みうるため、すべて取引を断念した

役員たちが誇張をやめられない調整問題

  • 年間経常収益 10億ドル以上 の企業の一部AI責任者は、自分の職務が実質的に虚偽だと考えながらも、組織内で唯一の昇進ルートだから引き受けたと明かした
  • あるFortune 500企業の技術力ある役員でさえ、会社の「生産性100倍」といった対外発言を個人的には擁護できなかった
  • 誇張の中核的な原動力は、販売文句より 顧客側役員の面子と契約関係 だった
    • ベンダー側の役員が顧客の生産性100倍という主張を否定すれば、顧客役員の信頼を傷つける攻撃と受け取られかねない
    • その結果、大企業との契約が破棄されれば、そのベンダー役員も解雇されうる
  • 企業同士が互いに顧客であり供給者でもある関係では、どの役員も最初に真実を口にしにくい
    • 皆が誇張に協力すれば地位を維持できる
    • 一人が離脱すれば、同僚を嘘つき・臆病者・無能にしたも同然となり、解雇されうる
    • 全員が同時に認めれば状況を変えられるが、それを調整する方法がない
  • S&P 500企業の取締役会メンバーたちもAI投資のリスクを疑いながら、自分の地位を守るには投資を要求せねばならないと感じていた
    • ある取締役は「こんなに早い段階で投資するのは、上振れ余地なしにリスクだけを抱えるようなものだ」と評価した
    • 約2年後、その数十億ドル規模の組織は自らを AI-native と宣伝するようになった

あらゆる事業をAIで装う純度検査

  • 組織内政治が絡むあらゆる提案は、実際の価値が不明でも AIとの整合 を含めなければ承認されない
  • 相当数のAIプロジェクトは、既存の非AIプロジェクトに事後的にAI要素を付けて純度検査を通した形だった
  • OracleからSnowflakeへデータベースを移行した事例では、ベンダーがOracle SQLをSnowflake SQLへ変換する作業をLLMで自動化する段階を追加した
    • 権限不足で自動化が失敗すると、人が直接変換した
    • 一部のSQLがAIで翻訳されたという理由だけで、プロジェクト全体をAIベースの成功として報告した
    • 実際の購入対象は、ライセンス更新前に既存システムを廃止するための一般的な データベース移行 だった
  • LLMが唯一の中核メカニズムであり、具体的な数値で成否を判断できる真のAIプロジェクトはまれだった
    • 主にスタートアップで見られたが、販売過程の終盤で、すでに完成済みだと宣伝していた製品を代わりに作ってほしいという要求が繰り返され、取引を中止した
  • AIを付けにくい事業は資金申請が却下されるか、「十分にAIらしい」提案になるまでコミュニケーションが遅延した
  • 追加人員を求める際、まずAIを使ってみたことを証明するよう求める企業もある
    • AIを使ってもなお人員が必要だと言えば、「AIをうまく使えない人」と分類され、解雇されうる
  • AIが最優先課題と本当に一致しているごく少数の企業を除けば、大規模組織は適切なソフトウェア購入・人材採用・正直なプロジェクト報告・合理的な新規事業推進に集中しにくくなる

特定のプロジェクトを立て直さなければならないとき

  • AIプロジェクトの問題は、集団会議より 1対1の対話 で扱うほうが効果的である
    • 公の場では、各参加者が同僚に懐疑派だと思われるのを恐れる
    • 意見を別の場所に伝える際は、身元を隠すと約束しなければならない
    • 直接引用のように出所を推測できる方法は避けるべきである
    • 6人に1人程度しか問題を語らないなら、改善可能性の高い別の組織へ移るほうがよいかもしれない
  • 進行中のプロジェクトには、Secrets of Consulting から得た 匿名アンケート の手法を活用できる
    • 成功可能性を1〜10点で評価してもらうと、一部は3点、一部は8点という二極分布が現れることがある
    • すでに3年遅れているプロジェクトでもこの乖離が見られ、CEOに重要な情報が隠されていることを示しうる
  • プロジェクトの実際の成功可否は、毎日ツールを使う 現場従業員 に確認しなければならない
    • 彼らが尊重される環境で意見を述べられるようにすべきである
    • ある顧客企業では、従業員が自分にAIツールのライセンスが付与されていることすら知らず、生産性向上という主張の土台が揺らいでいた
  • 特定の問題を解決しようとしている状況なら、「AIがすべてを変える」のような包括的命題は反論しないほうがよい
    • 組織の現実認識そのものに挑戦するには、まず最高責任者の信頼を得る必要がある
    • 公の場で恥をかかせるより、私的な食事の場で不安を和らげるべきである
  • 会議参加者が過去にどんな公的発言をしたか分からないため、「LLMは人のレビューなしにコードをデプロイすべきではない」のような常識でさえ、初期の信頼形成を壊しかねない
  • 別の公益的目標を達成しなければならず、誠実なアプローチが不可能なら、プロジェクトに 1万ドルのAIチャットボット を付けてその部分だけを強調する方法まで現実的な選択肢とみなしている

組織を変えるより生き残らなければならないとき

  • AIへの集団的執着は技術そのものより 機能不全の企業文化 の問題であり、個人が有意義に抵抗するのは難しい
  • 正社員ではなく契約社員に転じれば、より高い報酬を得て社内政治から離れられ、耐えがたい環境にも明確な終了日が生まれる
  • AIニュースは必要な分だけ消費し、Hacker NewsやRedditのように継続的に関連情報を供給するチャネルを避けるほうが精神的負担を減らせる
    • 友人に不満を話すときも、なぜこの会話が必要なのかを明かし、適度なところで止めるべきである
  • 周囲の人が危険ではない用途で不適切にAIを使っているなら、議論せずに受け流し、プログラマーとして意見を求められたら「誇張された面がある」と短く答えたうえで話題を変えるやり方を勧める
  • 2,000行のAI生成PR を継続してレビューしなければならないなら、燃え尽きと解雇を前提に、まだエネルギーが残っているうちに求職を始めるべきである
    • 生成した本人を説得して大量の低品質コードを止めさせるのは難しい
    • 業務速度の低下と管理者の不満は、今は転職活動のせいで、後では燃え尽きのせいで生じるだけで、避けがたい
  • 管理者が明らかなAI生成文で返答してくるなら、こちらもAIで応答してエネルギーを節約しつつ新しい仕事を探すべきである
  • トークン使用量を最大まで埋めろと要求される場合でも、現実感覚を失う前に転職準備を進めるべきである
    • こうした会社は採用プラットフォームにあまり現れない小規模組織に存在することがある
    • 見つけるのに数か月かかることもあるため、早めに始める必要がある

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsの意見
  • 私たちの多くは、AIが社会を完全に変革し、シンギュラリティをもたらすとある程度確信していたが、現実はそうならなかった。誤りを認めて再評価する代わりに、AIをあらゆる隙間に無理やり押し込み、進歩だと叫ぶ未来ロールプレイをしている
    Nintendo Power Gloveを着ければハッカーになれると信じる1990年代の子どもに近く、これはシンギュラリティではない。この熱狂が終わり、皆が次の万能解決策を待つ時期に戻ってほしい

    • どうしてLLM以前の世界に戻れると思えるのか理解しがたい。Opus 4.5以降を使っていないのだろうかと疑う
      ソフトウェア業界を離れ、毎週40時間もコーディングできない私にとって、エージェント型AIは検索エンジン、電子掲示板、コンパイラに匹敵する技術的飛躍だ。Claude CodeにホームラボのSMTP設定、2017年のAndroidアプリのモダナイズと署名、複数のOS・アーキテクチャ向けGitHub Actionsランナーの構成を任せると、皿洗いをしている間に結果を出してくれる
      これを大したことではないと否定する側こそ、むしろAI精神病への精神病に陥っている。モデル知能が今ここで限界にぶつかっても、すでにゲームチェンジャーな技術だ
    • どんな革命も、計画された通りにも誇張された通りにも進まず、始まった後は人間の行動の結果として、しかし人間が設計していない形で展開する
      個人は仕事でLLMを適切に活用しながらも、自分の仕事や他人が求める結果を十分に理解できず、多くのミスを犯すだろう。メール・SMS・電話以外の技術をほとんど使わない経営層は、技術を理解しないまま語り続けるだろう
      最終的な結果は誰にも分からないが、Claudeを5分使うだけでも、すべての事務職の仕事が以前とまったく同じまま維持されるとは想像しにくい
    • 10代の頃からシンギュラリティには納得できなかった。人間が設計したハードウェアとソフトウェア上で動くAIの能力が、なぜ突然天文学的に向上するのか疑問だ
      人間の脳と同等になっても、人間社会全体の生産量に追いつくには効率をさらに何桁も高める必要があり、そうして初めて人類の進歩速度を上回れる。AIシンギュラリティが可能だとしても、加速には一生かかるかもしれない
    • シンギュラリティは、一部の著名人が提案したいくつかの可能性の一つにすぎない。AIが発展する経路は非常に多様で、私たちが予想していない方向も多いだろう
    • 変化の速度をあまりに速く見積もっているようだ。産業革命も1712年のNewcomen蒸気機関から大量生産の自動車に至るまで数百年かかった
      AIもまた、1950年にTuringテストが提案されてから、それに合格したように見えるシステムが出るまで約75年かかったのだから、もっと時間を与えるべきだ
  • 「ひどいAIコードが入った2,000行のPRを大量にレビューしろと言う組織は、結局あなたを燃え尽きさせて解雇するのだから、すでに解雇されたつもりで新しい仕事を探せ」という一節に共感する。エージェント型開発が広く導入されるほど、こうしたことはもっと頻繁に起きると思う

    • エンジニアリング責任者なら、教育、手順改善、自動品質検査、より良い計画で自ら解決すべきだ。耳を塞いで拒絶するやり方は持続可能ではない
      スループットを2〜3倍に高める条件を見つけて組織化し、ボトルネックと最も難しい部分に集中すべきだ。実際にそれをやった立場から言っている
  • 「1年半の間に観察したすべてのAIプロジェクトが失敗し、成功率は0%だった」という表現は誇張で、信頼性を損なう。AIと言えば、エキスパートシステムからLLM、トランスフォーマー、拡散モデルまで幅広く含まれる
    意味検索や拡散モデルによるコンテンツ生成、さらには教師あり学習の文脈での線形回帰でさえ生産性向上は見られる。最近の関心を呼び戻したトランスフォーマーLLMに限っても、単純で退屈な業務を自動化する小規模プロジェクトはおおむね成功していた
    モデル能力以上を要求する野心的なプロジェクトは失敗しやすく、その大半は事前に予測可能だが、可能性の境界線上にある一部は正当な研究開発プロジェクト

    • 脚注を見ると、彼らはレビュー依頼を受けたAIプロジェクトを100%断ったと明かしている。ホームページでは、問題を抱えたプロジェクトを立て直すコンサルティングを販売し、2000年以前の本で学んだ「古代の技法」も強みとして掲げている
      社内専門性がなくて失敗している会社だけを対象に宣伝し、そのうえ自分たちが見たプロジェクトはすべて失敗だったと書くのは選択バイアスだ。支援まで断っているので、成功事例に転じる可能性も遮断している
    • 筆者はもともと誇張を多用する。以前の記事タイトルも「I Will Fucking Dropkick You If You Use That Spreadsheet」(https://ludic.mataroa.blog/blog/i-will-fucking-dropkick-you-...)、「I Will Fucking Piledrive You If You Mention AI Again」(https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...) のような調子だ
      丁寧な企業調の話し方は好まないようだが、この文体が好きで、業界の慣行に逆らう洞察に富んだ視点もよく提示している
    • 生産性向上を主張するなら、非常に慎重であるべきだ。作業フローの一部が速くなっても、他の部分を遅くすることがあり、全体的な向上はまだ実証的に測定・検証されていない
      コード行数、単体テスト、文書、PR速度のような指標は増えたが、実際の事業成果は不明確だ。PRの増加は機能リリースを早めるかもしれないが、レビューを遅らせたり、バグでユーザー体験を損なったりすることもある。より多くのコードが実際の売上にどう結びつくのかを企業は語っていない
    • 社員個人がClaude CodeやCodexで生産性を高めることと、会社がLLMの上にカスタムソフトウェアを構築するAIプロジェクトは大きく異なる
      前者は、その技術を積極的に拒否しない限り、ソフトウェアエンジニアが有用な結果を得やすい。後者はLLMという特異な土台の上に構築しなければならず非常に難しく、社内チャットボットのようなありがちなプロジェクトは、過大な約束と期待外れの結果につながりやすい
  • 地球の反対側にあるまったく別の2社で、経営陣が法的・財務的な波及の大きい対外文書をLLMで作成しようとする様子を見た。発送前には必ず専門家が読んで事実確認すると言うが、編集とファクトチェックを専門としない人は、最初から正確に作成する場合より、レビュー時のほうがずっと甘くなりがちだ

  • 「別の作業をしている間に Go リポジトリのコピー全体を Zig に書き直させないと職を守れない」とか、顧客企業の経営陣が生産性100倍を主張しているのに対し、供給側の役員が現実的ではないと言うと顧客側役員の信頼を損ねて企業契約が取り消されかねない、といった逸話は非常に良い

  • 「観察したすべての AI プロジェクトの成功率が 0%」と言うが、AI プロジェクトの定義がない。ソフトウェアを最初から書くことなのか、非開発者が社内外で LLM チャットボットを使うことなのか、あるいは別の何かなのか、具体例が必要

    • この会社がデータプロジェクトを手がけていることと文脈を見ると、社内業務フローの自動化と対話型インターフェースを指しているようだ
      業務自動化に関する裸の王様批判には全面的に同意するが、多くの人にとって前向きな AI 支援エンジニアリングに触れていないのは意外。チャットボットも問題範囲を狭めて適切に選べば成功しうる。前職ではベクターデータベース向けの対話型インターフェースで良い結果が出たが、実際の中核はベクターデータベースであり、従来型 UI のほうがより速く正確だったかもしれない
      全体として文章の方向性はおおむね正しく、とくに経営幹部を席巻したAI 狂騒と非現実的な期待に関する部分は妥当
    • 彼らは "Hermit Tech" というコンサル会社を運営しており、ホームページでは 2000 年以前の本にある「古代の手法」を誇っている。この傾向なら AI に関するあらゆるものを嫌っていても不思議ではなく、真面目な会社が AI プロジェクト支援を任せる可能性も低そう
    • 有用な AI 応用は既存のワークフローにひっそり統合される一方、非技術者向けに作られた無理な大規模計画だけがAI プロジェクトや「AI イニシアチブ」という名前を掲げて失敗しているようだ
  • Claude で高度な SQL や Python コードを書いた自分の経験は、記事の主張と一致しない。自然言語でデータを問い合わせる満足のいくチャットボットは自分では見たことがないが、非常に複雑なクエリを自然言語で書けば80〜90%程度までは到達できた
    AI で競合他社より先行している企業は、大々的に宣伝せず静かに活用している可能性が高い。記事が念頭に置いているのは管理職だらけの大企業だが、そうした組織は AI 以前にもデータサイエンス・分析やブロックチェーンでまったく同じ振る舞いをしていた

    • 大企業では、LLM で価値を生む人より壊す人のほうが多いかもしれない。以前は一人分の時間しか無駄にしなかった Bob が、今では組織全体の時間を無駄にできる
      誰でも LLM を使って悪いアイデアをもっともらしく見せられるので、平凡な副社長の誤ったアイデアに組織全体が追従し、甚大な生産性損失が発生しうる
    • 記事の誇張には同意しないが、大きな方向性は正しい。AI は 1 時間かかっていた複雑なクエリを数秒で書くなど、小さな作業と日常業務では優れている
      機能開発は依然として同程度の時間がかかるか、生産性向上が限定的。たぶん大半の組織がソフトウェア構築そのものを慢性的にうまくできていないからだろう
  • 先週、別々の 2 か所から業務で AI をどう使っているか尋ねるアンケートを受けたが、どちらも複数選択式なのに0 個選択は許可されておらず、必須質問に設定されていた

  • 企業の AI 導入で莫大な生産性向上が実際に起きるのかは分からないが、シャベル売りである Nvidia と Anthropic には完璧に筋が通っている

  • 王様が裸だと明かしても狂騒は止まらない。17 世紀のチューリップ狂騒だけでなく、アジャイル手順、作業スケジュール、コード行数ベースの生産性測定も似たようなもので、企業は時代ごとに新たな集団的狂騒を繰り返す
    コンサル専門家のプロセス主義、セキュリティ担当者の過剰な統制、取り残されるかもしれないという恐怖、AI ベースの現代企業に見せたいという発表上の目標がそれを引き起こす。顧客・企業・サプライチェーン・政府・思想家のすべてがこの世界的なダンスに参加しており、音楽はいずれ変わり、踊りも変わるだろう

    • こうした狂騒は群集行動や群集心理とも呼べる。群衆の知恵より、群衆の愚かさと狂気のほうがはるかにありふれている
      ビジネスと政治は主にこれに左右され、技術業界も流行と誇張、あとから見れば明白に思える何十年単位の失敗に繰り返し陥る
    • 正しい問いは、他人の狂騒を利用してどう金を稼ぐか