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

AIマニアが世界の意思決定を蝕んでいる

概要

  • 本記事はAI導入に関する企業の集団心理と現場の実態を批判的に考察
  • 著者自身の経験や観察から、AI投資の失敗例が多発している現状を指摘
  • 成果が出ていないにも関わらず、AI信仰が組織に蔓延する現象を分析
  • 批判や懐疑が許されない空気が生まれ、現場の健全な議論が困難に
  • 実際のプロダクト利用や現場の声に基づくリアルな問題提起

企業に蔓延するAI集団心理と現場の実態

  • AI導入 に関して、企業の多くが 理性的な議論 を行えていない現状
  • 著者自身が グローバルなプロフェッショナル と300回以上の対話経験
  • 現場観察から、 民間・公共セクター 問わず「集団的な錯乱」状態
  • 経営層の多くが 具体的な計画や明確な方針を持たない
  • 組織内では AIに対する過度な期待と現実とのギャップ が拡大

AI投資の現実:ほとんどが失敗

  • AIプロジェクト の多くが 実質的に失敗 している現状
    • 1年半観察した全案件で 成功率0%
    • Copilot等の ライセンス購入だけで成果を誇張 する事例多数
  • 内部向け・顧客向けチャットボット の導入例が典型
    • 社内利用が定着せず、 実用性に乏しい
    • 顧客対応も 満足度向上に直結しない
  • プロジェクトのKPI計測回避ごまかしの指標設定 が常態化
  • 現場での率直な質問やフィードバック がタブー視される空気
  • AI投資の失敗要因
    • ソフトウェア開発力の未熟さ
    • LLM(大規模言語モデル)の限界
    • 組織文化や意思決定プロセスの問題

AI信仰と組織の異常な空気

  • AI懐疑論や批判的意見排除・抑圧 される傾向
  • 500人以上の大企業 では「AIの変革力」への信仰告白が出世や雇用維持の条件
  • 技術者以外の経営層 によるAI戦略推進が目立つ
    • 実際はAIツール未経験でも AI中心の戦略を打ち出す 例多数
  • 「AIを使っていないと評価されない」 という現象
    • 実際は従来通りの業務を行い、 AI利用を偽装
    • AI利用量を競う「トークンリーダーボード」など 不毛な指標で評価
  • 組織の意思決定や現場の健全な議論 が困難に
    • 本質的な成果よりも AI活用アピールが優先 される構造

まとめと今後の課題

  • AI導入の現場で成果が見えないケースが大半
  • AI信仰が組織文化や評価制度に組み込まれ、現実的な議論や改善が阻害
  • 経営層・現場双方が冷静にリスクとリターンを見極める視点 の重要性
  • 実用性や現場での実効性を重視したAI活用 の再考が求められる

Hackerたちの意見

昨日ちょっとした議論があったね(43ポイント、7コメント) https://news.ycombinator.com/item?id=48956153

私たちがチームとして観察したすべてのAIプロジェクトは失敗しています。すべてのプロジェクトがそうです – 1年半で成功率は0%です。「AIプロジェクト」って何ですか?投稿では定義されていません。ゼロからソフトウェアを書くことですか?非プログラマーが内部または外部でLLMチャットボットを使うことですか?それとも全く別の何かですか?具体例があると助かります。

AIの有用なアプリケーションは、静かにワークフローに統合されていく気がする。技術的に理解していない人たちのための無謀なムーンショットが「AIプロジェクト/イニシアチブ」としてラベル付けされて、失敗するんだよね。

彼らの会社はデータプロジェクトをやってるみたい。これに加えて、内部の業務プロセスの自動化を話してるんじゃないかな。ただ、会話型インターフェース(チャットボット)についても言ってるように見える。業務プロセスの自動化に関しては「裸の王様」論には完全に賛成だよ。AI支援のエンジニアリングについて触れないのは意外だね。多くの人にとってはうまくいってるみたいだけど(持続可能性には疑問があるけど)。チャットボットの成功については、問題が狭く定義されていて適切に選ばれれば、違う意見だな。前の会社ではベクターデータベースへの会話型インターフェースを作って、いい結果が出たよ。(ただ、ベクターデータベースが本当の魔法だったかもしれないし、従来のUIの方が早くて正確だったかも。)一般的に、OPの言ってることは間違ってるより正しいと思う。特にAIの熱狂とC-suiteを席巻する非現実的な期待についてはね。

彼らは「ハーミットテック」っていうコンサルティング会社を運営してる。ウェブサイトは古いスタイルのフォントを使ってるし、2000年以前に書かれた本の「古代の技術」を自慢してる。 > 「自分のコントロールを超えたものを届けるのに苦労している非経営管理者のために、1986年から1999年に書かれた本を参考にした古代の技術があります。これを使えば、あなたのチームを組織の羨望の的に変えられますし、直接お手伝いして、苦しんでいるプロジェクトを救うために必要なリソースを提供できます。」だから、もちろん彼らはAIやその周りの全てを嫌ってるよ。真剣な会社は、AIプロジェクトの助けを求めてこれらの人たちに連絡することはないね。

この投稿は正しい気がするけど、自分がclaudeを使って高度なSQLやPythonコードを書く時の使い方とは合わないな。実際にAIチャットボットが自然言語でデータをクエリできるユーザー体験を提供しているのを見たことはないけど、自然言語を使って非常に高度なクエリを書くことは経験したことがある。自分の推測では、80-90%のところまでは行けると思う。確かに、競争相手を超えて進んでいる企業もあるはず。彼らは大声で発表するのではなく、静かにやっているんじゃないかな。この記事のポイントは、管理職や人がたくさんいる大企業についてだよね。自分の主張は、彼らは昔からそうだったってこと。AIの前は「データサイエンスと分析」や(著者が言うように)「ブロックチェーン」だった。

どうかな、そうでもないかも。大きな組織では、LLMを使って価値を生み出している人の数よりも、価値を壊している人の方が多いと思う。ボブは以前は一人の時間を無駄にするだけだったけど、今は組織全体の時間を無駄にできるようになった。誰でもLLMを使って悪いアイデアを良いアイデアに聞こえさせることができる。これが原因で、組織全体が平凡なVPの悪いアイデアに従うことになって、すごい生産性の損失が出るんじゃないかな。

私たちがチームとして観察したすべてのAIプロジェクトは失敗しています。すべてのプロジェクトがそうです – 1年半で成功率は0%です。私たちが参加を求められたプロジェクトだけでなく、全く関係ない仕事をしている時に通りすがりに観察したプロジェクトでもそうです。これは誇張だと思うし、信頼性を損なうよ。彼らは「AI」と言うことを選んだけど、例えばLLMやトランスフォーマーモデル、拡散モデルではなくて。つまり、彼らの主張にはエキスパートシステムに遡る広範なものが含まれているってこと。確立されたAI技術からの生産性向上を見たことがない人はいないよね - 少なくともセマンティックサーチみたいなものは。手作業でやっていた仕事をする役割でコンテンツを生成する拡散モデルを見たことがない人もいないはず。回帰アルゴリズム(監視されたコンテキストで線形回帰を使うこともAIとしてカウントされるから、ExcelのようなツールでもAIを使える)で運用生産性が向上したことがない人もいないよね?最近のAIへの関心を再燃させたトランスフォーマーモデルLLMに絞ったとしても、エンジニアリングスタッフに簡単だけど退屈なタスクを自動化するために提供するという、あまり野心的でないプロジェクトは一般的に成功しているよ。モデルができることを合理的に期待する範囲を超えた、より野心的なものは確かに失敗しがちだけどね。これらのほとんどは、事前に失敗が予測できるし、いくつかは可能性の境界にあるから、予測が難しい(これらは本当に合理的なR&Dプロジェクトだよ)。

オンラインの統計のゼロパーセントは作り話だよ!

脚注を読むと、彼らは持ち込まれたAIプロジェクトを100%拒否したって言ってるね。ホームページに行くと、彼らのコンサルティングの売り文句の一つが、苦しんでいるプロジェクトを復活させることなんだ。フロントページの売り文句の一つは、2000年以前に書かれた本の「古代の技術」を使っているってこと。つまり、それ以降のものは全部ダメってこと? > 「自分のコントロールを超えたものを届けるのに苦労している非経営管理者のために、1986年から1999年に書かれた本を参考にした古代の技術があります。これを使えば、あなたのチームを組織の羨望の的に変えられますし、直接お手伝いして、苦しんでいるプロジェクトを救うために必要なリソースを提供できます。」これは完全に彼ら自身が作り出した選択バイアスの問題だね。失敗しているプロジェクトを救うコンサルティングサービスを、内部の専門知識がない会社に宣伝しておいて、見えるプロジェクトは100%失敗しているってブログを書いてるんだから。さらに、助けることを拒否して、成功プロジェクトに変わることができないようにして、成功数を0%に保ってるんだ。

彼らのプロジェクトの詳細について学びたいな。

AIツールを使って生産性を上げる個々の従業員と、企業がLLMの上にカスタムソフトウェアを構築する「AIプロジェクト」には大きな違いがあると思う。前者は簡単にうまくいく。今の時代、どんなソフトウェアエンジニアでも(技術に抵抗していなければ)Claude Codeから有用な結果を得られるからね。後者は本当に難しい。LLMの上にソフトウェアを構築するのは奇妙なもので、この記事で説明されている内部チャットボットのような明白なプロジェクトは、過剰な期待をかけて、実際には期待外れになることが多いんだ。

Hacker Newsで議論の続きを見る