「AIはしょぼい」で終わらせるのは、少しもったいない。成果を妨げる24の原因

「ChatGPTは嘘ばかりつく」

「AIに資料を作らせたけれど、内容が薄かった」

「会社でAIを導入したのに、期待したほど成果が出ない」

生成AIについて話していると、こうした声を聞く機会が増えました。

私は、この不満をすべて間違いだとは思いません。AIは実際に誤りますし、任せるべきでない業務もあります。確認工数まで含めると、人間が対応した方が速く、安く、安全なケースもあるでしょう。

ただし、「AIはしょぼい」という一言で終えてしまうと、本当に直すべき問題が見えなくなります。

同じ発言でも、その背景にあるのは、モデルの精度不足かもしれません。依頼や材料が足りないのかもしれません。業務設計、評価制度、責任分担、専門性を失う不安が原因になっている場合もあります。

原因が違えば、対策も変わります。

プロンプトが問題なら、依頼方法を改善すればよいでしょう。しかし、AIを使って失敗した人だけが責任を負わされる制度になっているなら、プロンプト研修を増やしても解決しません。

この記事では、「AIはしょぼい」「使えない」と評価する背景を、実務で扱いやすい24型へ整理します。

中心的に伝えたいことは一つです。

企業のAI活用が期待外れになるのは、珍しいことではない

まず、AI導入への失望そのものには相応の根拠があります。

IBMが2025年に公表したCEO調査では、回答者が関わるAI施策のうち、期待したROIを達成したものは25％、全社規模へ展開できたものは16％でした。AIを導入した企業の多くが、投資を事業成果へ変換する段階で苦戦していることが分かります。

2026年にAI企業Writerが公表した調査では、経営幹部の48％が、自社のAI導入を「大きな失望」と評価しています。同時に75％は、自社のAI戦略が実務上の指針というより、対外的に見せるためのものになっていると回答しました。AIベンダーによる調査である点には留意が必要ですが、期待と実装の隔たりを示す材料にはなります。

つまり、企業のAI活用には二つの問題が同時に存在します。

一つは、現在のモデルが本当に十分ではないこと。

もう一つは、企業がAIを使って価値を生み出すための業務、データ、評価、責任を設計できていないことです。

この二つを混同すると、モデルを替え続けても成果が出なかったり、反対に、使うべきでない業務へ無理にAIを導入したりします。

「AIは使えない」の原因は、4つの場所に分かれる

24型を一つずつ見る前に、全体像を押さえておきましょう。

AIへの不満は、大きく次の4領域に分けられます。

1. 使い方と期待の問題
   AIを検索エンジンや完全な専門家として扱い、適切な材料や環境を用意していない。

2. 評価方法の問題
   人間側の基準値を測らず、AIだけに100点を求めたり、利用回数を成果として扱ったりしている。

3. 業務と技術基盤の問題
   AIに合わない仕事を選び、業務、データ、承認、例外処理を設計しないまま導入している。

4. 組織とインセンティブの問題
   AIを使う人に負担と責任だけが集中し、成果、評価、役割の再設計が行われていない。

この4つを分けておくだけでも、「とりあえず全社員にプロンプト研修を行う」という単純な対応を避けやすくなります。

Ⅰ．使い方と期待がずれている5つの型

1．検索エンジン期待型

生成AIを、質問すれば正確な答えが返るデータベースとして使う型です。

古い情報や存在しない数値が一度でも出ると、「嘘ばかりで仕事には使えない」と判断します。

この批判には正しい部分があります。最新情報、法令、料金、製品仕様、固有名詞などを、情報源への接続や検証なしで確定情報として扱うのは危険です。

ただし、事実を確認する工程と、情報を整理・比較・文章化する工程は分けて考える必要があります。

対応

• 最新情報はWeb検索や公式資料を参照させる

• 出典と確認日を求める

• 推測と確認済みの事実を分けさせる

• 高リスク情報は人間が一次情報を確認する

• 「事実確認」と「考察・作成」を別工程にする

最初の検証として、同じ質問を「通常チャット」「Web検索あり」「公式資料添付」の3条件で比較すると、情報源の有無による違いが見えます。

「AIとはそういうものなので、利用者が慣れるしかない」と済ませるべきではありません。必要なのは慣れではなく、情報源と検証手順です。

2．一発生成期待型

「新規事業を考えて」「営業資料を作って」「システムを作って」と短く依頼し、完成品を期待する型です。

しかし、AIには、顧客、目的、材料、制約、予算、禁止事項、判断基準などが見えていません。不足部分は一般的なパターンで補われるため、「それらしいけれど浅い」成果になります。

対応

依頼を、少なくとも次の5項目へ変換します。

さらに、調査、設計、作成、検証を分けます。最初の出力を完成品ではなく、レビュー対象の初稿として扱うことも重要です。

ただし、長大な万能プロンプトを配るだけでは解決しません。固有の材料がなければ、指示だけ詳しくしても中身は一般論のままです。

3．デフォルト設定評価型

通常チャットの初期状態だけを使い、それをAI全体の能力として評価する型です。

実務では、目的に応じて次のような要素を組み合わせます。

• プロジェクト固有の指示

• 参照資料

• Web検索

• 社内データ

• コーディング環境

• 定型テンプレート

• テストと評価基準

• 複数回のレビュー

ただし、これを「機能を知らない利用者の責任」と片付けるのも適切ではありません。

専門的な設定をしなければ価値を出せないなら、製品のオンボーディングや、組織の標準環境にも改善余地があります。

頻繁に使う業務では、全員にプロンプトの工夫を求めるより、資料、指示、評価基準を含む再利用可能な環境を組織で用意した方が合理的です。

4．限定経験固定型

数回の失敗や、数年前に使ったモデルの印象から、AI全体を評価する型です。

「以前使ったら日本語がおかしかった」「一度コードを書かせたけれど動かなかった」といった経験を、現在の別製品や別業務にも当てはめます。

問題は二つあります。

一つは、少数の事例をAI全体へ一般化していること。もう一つは、変化の速い製品を、古い体験のまま評価していることです。

失敗を次の形式で記録すると、再検証しやすくなります。

そのうえで、同じ失敗が別モデル、別の使い方、別の利用者でも再現するかを確認します。

5．学習性無力感型

何度か失敗し、「自分にはAIを使えない」と感じている型です。

原因は本人の能力だけではありません。

研修が抽象的だった、自分の仕事で試していない、質問できる相手がいない、毎回ゼロから依頼している、周囲だけが使いこなして見える。こうした状況が重なると、改善できる感覚を失います。

この型に高度な機能や長いプロンプトを教えると、苦手意識をさらに強める可能性があります。

最初に選ぶべきなのは、10〜15分で終わり、本人が正解を確認できる小さな業務です。

AI研修の最初の目標は、AIの仕組みを理解することではありません。

Ⅱ．評価の仕方がずれている5つの型

6．基準値インフレ型

AIが短時間で作った成果物を、熟練者が時間をかけて作った成果物と比較し、「普通すぎる」と判断する型です。

品質しか見ておらず、時間、費用、処理量、修正速度、再現性が評価されていません。

AIの絶対的な能力が上がるほど、以前なら驚かれた要約や文章生成が当然になり、期待値だけが上がることもあります。

経営判断で見るべきなのは、「驚く成果だったか」ではありません。

人間だけで行う場合とAIを併用する場合で、総工数、差し戻し、品質を比較します。

7．100点主義型

「一度でも間違うなら使えない」

「人間の確認が必要なら意味がない」

このように、AIを補助ツールではなく、完全な代替要員として評価する型です。

一件の誤りが重大事故につながる業務で、高い精度を求めるのは正当です。しかし、下書き、分類、候補生成などの低リスク業務まで同じ基準で否定すると、部分的な効率化の可能性を失います。

まず、業務をリスク別に分けます。

• 低リスク：一定条件で自動化を検討する

• 中リスク：AIが作成し、人間が確認する

• 高リスク：AIは情報整理と判断支援に限定する

完全自動化できるかではなく、どの工程を減らせるかを評価します。

8．人間の失敗不可視型

AIの誤りは細かく記録する一方、人間が行っている現行業務の誤り率を測っていない型です。

比較対象となる人間側について、次の数字が分からないことは珍しくありません。

• 見落とし率

• 誤案内率

• 作業時間

• 差し戻し回数

• 担当者によるばらつき

• 担当者不在による停止

AIだけを監査すれば、AIの欠点だけが目立ちます。

導入前に、過去20〜50件程度の人間業務を使い、品質、時間、再作業を測定します。AIと人間には、同じ評価セットを適用すべきです。

9．実証的懐疑型

精度、確認時間、利用料、事故時の損失、規制などを測った結果、「現在の条件では使えない」と判断している型です。

この批判は正当です。

現在のAIには、適切な資料、指示、評価環境を整えても任せられない仕事があります。

この型に必要なのは、説得ではなく共同検証です。

これらを決め、条件を満たさなければ使わないという結論も認めます。

AIを導入しない判断まで選択肢に含める方が、検証への信頼は高まります。

10．KPIゲーム化被害型

利用者数、ログイン数、プロンプト数、生成文書数などを成果KPIにした結果、価値のないAI利用が増えている型です。

本来は使わない方がよい作業にまでAIが使われ、かえって時間がかかったり、品質が下がったりします。

問題なのは、AIではなく評価指標です。

測るべきなのは、次のような業務成果です。

• 完了時間

• 品質

• 売上

• 顧客満足

• 処理件数

• 欠陥率

• 再作業

• 創出された余剰時間

AIを使わなかった方がよいケースも記録し、成果の悪い利用は止めます。

Ⅲ．業務と技術基盤が整っていない6つの型

11．タスク不適合型

AIが苦手な仕事を任せ、その結果からAI全体を否定する型です。

たとえば、正解が曖昧で、例外が多く、一件の誤りによる損失が大きい仕事を、最初から全面自動化しようとします。

候補業務は、少なくとも次の観点で評価します。

• 繰り返し頻度

• 正解の確認しやすさ

• 例外の多さ

• 必要な情報の入手可能性

• 誤りが生じた場合の損失

最初は、頻度が高く、正解を確認しやすい仕事から始めます。大きな業務は小さな工程へ分け、暗黙知や例外が多い部分ではAIを補助に限定します。

12．丸投げ経営者型

全社員へ有料アカウントを配る、一般研修を行う、PoCを作る。それだけで成果が生まれると考える型です。

しかし、対象業務も成功条件も決めず、既存業務の上にチャット画面を追加しても、全社的な価値にはつながりにくいでしょう。

必要なのは「AIを導入する」というテーマではありません。

このように、改善したい業務と成果を具体化します。

McKinseyの2025年調査では、生成AIによるEBITへの効果と最も強く関連した要素として、業務フローの再設計が挙げられています。単にAIを使う人を増やすことより、仕事の流れそのものを変える必要があります。

13．人員削減先行型

既存業務を変えず、人間だけを取り除けば費用が下がると考える型です。

実際には、AI導入によって新しい費用や工程が発生します。

• モデル利用料

• システム開発

• データ整備

• セキュリティ対策

• 出力確認

• 例外処理

• ログと監査

• 保守

• 社員教育

• 障害時の代替運用

ROIは、削減人件費だけでは計算できません。

削減できた時間を、売上、顧客対応、品質改善、商品開発などへどう再配分するかも決める必要があります。

14．組織的負債転嫁型

社内情報やルールが整理されていないのに、「AIが自社を理解できない」と批判する型です。

よくあるのは、次のような状況です。

• 手順書が古い

• 規程が互いに矛盾している

• 最新版が分からない

• 決定事項がメールやチャットに埋もれている

• 指標の意味が部署ごとに異なる

• 業務が特定の社員の暗黙知に依存している

この状態では、AIだけでなく、新入社員や外部委託先も正しい仕事ができません。

まず一つの業務について、「正本となる資料」「最新版」「責任部署」を決めます。

大量の未整理情報を検索システムへ入れても、矛盾した情報を高速で探せるようになるだけです。

AIが組織の負債を作ったのではありません。以前からあった問題を見えやすくしたのです。

15．差別化消失型

「AIが作る企画や文章は、どれも似ている」

この批判は一部正しいものです。

複数の会社が、同じ汎用モデルへ、似た一般情報と似た指示を与えれば、成果も似てきます。

必要なのは、自社固有の材料です。

• 顧客の声

• 独自データ

• 実績

• ブランド基準

• 意思決定の履歴

• 採用・却下した事例

• 禁止表現

• 独自の評価基準

AIに差別化そのものを期待するのではなく、すでに持っている差別化資産の編集、再構成、展開に使います。

16．ベンダー被害型

誇張された営業説明、選別されたデモ、隠された運用費用によって失望している型です。

たとえば、次のようなケースです。

• 成功しやすい入力しか見せられなかった

• 精度や失敗条件を説明されなかった

• 人間を代替できると断定された

• データ整備や保守費用が後から判明した

• 手作業を隠したデモだった

• 単純なAPI連携を独自AIとして説明された

この場合、失敗をすべて自社のプロンプト不足として受け入れる必要はありません。

AI一般と、購入した製品・提案・導入支援を分けて評価します。営業デモではなく、自社で失敗すると困る10ケースを使い、実データと実ユーザーで試験します。

Ⅳ．組織とインセンティブが壊れている8つの型

17．AI利用強制反発型

AIそのものではなく、経営から利用を強制されることに反発している型です。

「AIを使え」と言われる一方、どの業務を改善するかは現場へ丸投げされる。利用回数は評価されるものの、追加負担や品質低下は考慮されない。

この状態で「AIは仕事を増やす」という反応が出るのは自然です。

AI利用率ではなく業務成果を評価し、使わない方がよい業務も認めます。「AIを使う業務」を経営が決めるのではなく、「改善したい業務」を現場から集める方が有効です。

18．責任非対称型

AI活用の便益は会社が得る一方、失敗したときの責任は現場個人が負う型です。

現場から見ると、次のような構造になります。

• 成功しても評価されない

• 時短しても仕事が増える

• AIを使わないと消極的と見られる

• AIを使って失敗すると本人が責められる

• 確認作業だけが追加される

これなら、AIを使わない方が合理的です。

業務ごとに、少なくとも次の役割を決めます。

• 実行者：AIを操作する

• 確認者：内容を検証する

• 承認者：外部利用や本番反映を許可する

• 責任者：事故時の最終責任を持つ

「最終的には利用者の自己責任」とだけ規程に書くのは、責任分界ではありません。

19．成果没収型

AIで仕事を早く終えても、追加業務や高い目標が与えられるだけの型です。

本人にとっては、改善方法を共有するほど負担が増えます。

導入前に、削減できた時間を何へ使うか決める必要があります。

売上活動、顧客対応、学習、休暇、裁量、報酬などへ、どのように配分するのか。改善ノウハウを共有した人をどう評価するのか。

時短した社員の目標だけを即座に引き上げる運用は、成功事例を地下化させます。

20．専門性・役割防衛型

AIによって、自分の技能、地位、役割の価値が失われると感じている型です。

文章作成、資料作成、翻訳、コーディング、調査、報告集約など、それまで専門性の中心だった作業が短縮されると、職業的な自己認識が揺らぎます。

中間管理職の場合は、情報の集約、資料作成、伝達、一次判断といった役割が圧縮され、自分の存在意義が問われることもあります。

「AIに仕事を奪われることはありません」と根拠なく安心させても解決しません。

業務を三つに分けます。

専門家には、品質評価、例外判断、ルール設計、暗黙知の形式化、最終責任などの役割があります。

管理職も、情報の中継から、意思決定、人材育成、部門間調整、障害の除去へ重心を移す必要があります。

21．評判リスク回避・隠れ利用型

AIを使ったと知られると、能力不足や手抜きだと思われるため、公には価値を認めない型です。

実際にはメール、調査、資料整理などで日常的に使っていても、「AIは大したことがない」と説明することがあります。

理由には、次のようなものがあります。

• 成果の価値を下げられたくない

• ノウハウを共有させられたくない

• 仕事を増やされたくない

• 専門家としての評価を失いたくない

• 自分の優位性を保ちたい

適切なAI利用を減点要素にせず、成果と確認品質を評価します。AI利用の開示が必要な場面も、業務のリスクに応じて限定すべきです。

22．投資失敗合理化型

成果の出ない原因を、AI技術全体の未成熟さへ転嫁する型です。

高額なシステムを導入し、大規模なPoCを行い、専任部署まで作った。それでも成果が出なければ、本来は要件、データ、業務、運用、ベンダー選定を振り返る必要があります。

しかし、「AIはまだ早かった」と結論づければ、経営判断そのものを検証せずに済みます。

振り返りは次の五つに分けます。

撤退は必ずしも失敗ではありません。検証によって「現在の条件では採算が合わない」と判断できたなら、それも成果です。

また、AI推進側が自分の判断を守るために、成果を過大評価する可能性もあります。自己正当化は批判派だけに起きるものではありません。

23．禁止反動・シャドーAI型

情報漏洩などを恐れて全面禁止し、未承認利用を地下化させる型です。

AIを禁止しても、業務上の需要が消えるわけではありません。公式環境がなければ、個人アカウントや未承認ツールが使われる可能性があります。

BCGの2025年調査では、回答者の54％が、会社に承認されていない場合でもAIツールを利用する意向を示しました。全面禁止だけでは、利用をなくすのではなく、組織から見えなくする可能性があります。

少なくとも、次の三つは先に定めるべきです。

そのうえで、法人向け環境、ログ管理、例外申請、相談窓口、安全な代替手段を用意します。

24．地位・組織政治防衛型

AIへの性能批判を使い、権限、予算、承認権、情報独占を守ろうとする型です。

AI導入によって、不必要な承認工程、特定部門だけが持っている情報、説明できない判断慣行が可視化されることがあります。

そのとき、「うちの仕事は特殊だからAIには無理」という主張に、正当な品質懸念と組織政治が混ざる場合があります。

ただし、反対者を一律に「抵抗勢力」と呼ぶべきではありません。

反対意見には、責任分界の不在、現場負担、品質低下、非現実的な経営目標への正当な警告が含まれることもあります。

個人の賛否ではなく、業務データと検証結果で判断します。

さらに、AI導入によって誰が何を得て、何を失うのかを、ステークホルダーごとに整理します。権限の再編とAIの性能評価を、意図的に分けて議論する必要があります。

24型を覚えるより、6つのギャップを見ればよい

ここまでの24型をすべて覚える必要はありません。

さらに抽象化すると、AIへの低評価は六つのギャップに整理できます。

1．能力ギャップ

現在のモデルが、本当に業務要件を満たしていません。

精度、処理能力、説明可能性、情報へのアクセスなどが不足している状態です。

2．期待ギャップ

一発で完成する、専門家をそのまま代替できる、完全自動化できるなど、期待が現実より高くなっています。

3．設計ギャップ

目的、材料、データ、評価、承認、例外処理、ツール連携が不足しています。

モデル単体ではなく、利用環境全体の問題です。

4．利害ギャップ

AI導入の利益と負担が公平に配分されていません。

会社は利益を得る一方、現場だけが確認作業や事故責任を負う状態です。

5．身分ギャップ

専門性、地位、評判、役割が脅かされています。

これは単なる感情論ではなく、収入やキャリアへ関係する現実的な問題です。

6．統治ギャップ

責任、権限、安全性、利用範囲が決まっていません。

全面禁止や、現場への自己責任化が起こりやすい領域です。

純粋にモデル性能だけの問題は、主に能力ギャップです。

それ以外では、モデルを交換するだけでなく、期待、業務、評価、責任、役割を変える必要があります。

「AIが間違えた」は、原因分析ではない

AIの利用では、「AIが嘘をついた」「AIが勝手に変更した」といった擬人化された表現が使われます。

分かりやすい一方で、これだけでは何を直せばよいか分かりません。

より具体的には、次のように表現できます。

• 根拠のない情報を生成した

• 最新情報へアクセスしていなかった

• 入力条件が不足していた

• 指示されていない変更を行った

• ツールの実行結果を誤解した

• 制約を途中で保持できなかった

• 不確実性を表示しなかった

• 人間の確認工程が実行されなかった

「AIが間違えた」は現象です。

原因は、モデル、入力、データ、ツール、評価、確認、承認のどこかにあります。

ここを分けなければ、次も同じ失敗を繰り返します。

多くの企業がたどる「AIは使えなかった」への道

企業のAI導入では、次のような流れが起きがちです。

経営者がAIに大きな期待を持つ
        ↓
有料アカウントを配布する
        ↓
具体的な活用方法は社員へ任せる
        ↓
社員ごとに品質がばらつく
        ↓
成果指標を設定していない
        ↓
誤回答や低品質な成果が目立つ
        ↓
確認工数が増える
        ↓
「AIは使えなかった」と評価する

しかし、欠けていた可能性が高いのは次の工程です。

対象業務の選定
→ 現行業務の測定
→ 要件と合格条件の定義
→ データと資料の整備
→ 標準的な利用環境
→ ツールとの接続
→ 人間の確認と承認
→ 評価基準と停止条件
→ 改善ログ
→ 本番展開

モデルを交換する前に、この工程のどこが抜けているかを確認するべきです。

経営者が最初に確認すべき5つのこと

誰かが「AIは使えない」と言ったとき、すぐに反論したり研修を始めたりする必要はありません。

次の順で確認します。

1．何が起きたのか

どのAIを、どの業務で、どの条件で使い、具体的に何が悪かったのでしょうか。

「品質が低い」だけではなく、誤り、抜け、時間、費用、操作性などへ分けます。

2．何と比較したのか

人間、従来業務、別製品、専門家、未処理状態のどれと比較したのでしょうか。

比較条件が違えば、評価は成立しません。

3．原因はどのレイヤーか

モデル、入力、データ、業務、評価、運用、組織のどこに原因があるのでしょうか。

複数にまたがる場合もあります。

4．発言者にどんな利害があるか

AI導入によって、追加作業、事故責任、目標増加、役割や権限の低下を受けるのでしょうか。

抵抗に合理的な理由がないかを確認します。

5．何を変えるべきか

• 理解不足なら職種別研修

• 要件不足なら業務設計

• 情報不足ならデータ整備

• 精度不足なら利用限定または停止

• 責任問題ならガバナンス整備

• 成果配分の問題なら評価制度の変更

• 本当に不適合なら導入しない

「使わない」という選択肢を認めておくことが、むしろAI導入への信頼を高めます。

私が避けたいのは、「使い方が悪い」で終わらせること

私は、AIの成果には、モデル性能だけでなく、指示、材料、参照情報、ツール、評価、テスト、レビュー工程が大きく影響すると考えています。

その意味では、数行の依頼と一度の出力だけで「AIは使えない」と結論づけるのは、少しもったいない判断です。

ただし、推進側が何でも「使い方が悪い」「プロンプトが下手」と説明するのも、同じくらい問題があります。

その人が困っているのは、プロンプトではなく、次のことかもしれません。

• 失敗責任だけを押し付けられる

• 意味のないAI利用KPIを追わされる

• 未整理の業務へAIを入れられる

• ベンダーの説明が誇張されていた

• 専門職としての将来が見えない

• 効率化の成果が本人へ還元されない

• 現在のモデル精度が本当に足りない

こうした問題に対して、便利なプロンプトを教えても解決しません。

むしろ、「本当の問題を理解してもらえなかった」という不信を強める可能性があります。

まとめ：「AIはしょぼい」は、結論ではなく診断の入口

「AIはしょぼい」という言葉は、経営判断としては情報が足りません。

モデルの能力不足なのか。

期待が高すぎたのか。

業務、データ、評価、責任、インセンティブの設計が不足しているのか。

まず、そこを分ける必要があります。

経営者が問うべきなのは、「AIを信用するか、しないか」ではありません。

条件を整えても採算が合わなければ、使わないと判断する。

それが健全なAI活用です。

「AIはしょぼい」は感想です。

一方で、

これは経営判断です。

AI活用に必要なのは、全員を推進派に変えることではありません。

その人がAIを低く評価するに至った原因を特定し、技術、業務、評価、組織のうち、問題のある部分だけを直すことです。

参考資料

• IBM, “IBM Study: CEOs Double Down on AI While Navigating Enterprise Hurdles,” 2025年5月6日

• Writer, “Enterprise AI adoption in 2026,” 2026年4月7日

• McKinsey & Company, “The State of AI: How organizations are rewiring to capture value,” 2025年3月12日

• Boston Consulting Group, “Companies Must Go Beyond AI Adoption to Realize Its Full Potential,” 2025年6月26日