「DX/AI推進室を立ち上げて2年になるんですけど……正直、何が変わったか、うまく説明できなくて」——そんな言葉をお客様からいただくことは、一度や二度ではありません。
『DX』という言葉は、もうすっかり当たり前になりました。AI活用も企業にとってはもはやマストのミッションになっています。 あちこちでDX/AI推進部門が立ち上がり、ツールを入れて、研修も実施して。
それなのに、気づいたら現場の仕事はほとんど変わっていない——そんなモヤモヤを抱えている会社、実はとても多いんです。
いろんな会社のDX支援をしていると、「変わらない会社」は、驚くほど同じ轍を踏んでしまっていることに気づきました。しかも最近は、従来のIT導入の失敗に加えて、生成AI特有の落とし穴にハマるケースが急増しています。今回は、その話をしていきます。
よくある失敗パターン① ツール導入で「やった感」が完成する
事例：「ChatGPTを全社員に配布しました」で終わる
あるお客様の会社では、全社員にChatGPTの有料アカウントを配布して、使い方の説明会を1回実施されました。3ヶ月後、使っているのは一部の若手だけ。「結局、何に使えばいいかわからない」という声が大半だったそうです。
ツールの導入って、DXのゴールではなくスタートラインです。ただ、予算を使って、ベンダーと契約して、社内に発表した時点で「やりきった感」が出やすいのが厄介なところです。
特によくあるのが、ツール選定にたっぷり時間をかけるのに、「どの業務にどう使うか」を決めないまま展開してしまうパターンです。現場からすると「なんか便利そうなものが来たけど、で、何をすればいいの？」という状態になってしまいます。
💡 ツール導入の前に一度立ち止まって確認してほしいのは、「このツールで、誰のどの業務が、具体的にどう変わるのか」を言葉にできているかどうか、です。
よくある失敗パターン② AI特有のリスクを想定せずに走り出す
従来のITツール導入（SaaSやRPA）と、生成AIの業務適用では、失敗の構造がまったく異なります。ここを理解しないまま「とりあえずAI使ってみよう」と進めてしまい、後から大きな問題に発展するケースが増えています。
事例：AIが作った提案書をそのまま顧客に送ってしまった
あるお客様の営業チームでは、ChatGPTで提案書の下書きを作る運用を始めました。ところが、あるメンバーがAIの出力をほぼそのまま送付してしまい、実在しない機能やサービスが記載されていることが発覚。取引先の信頼を大きく損なう事態になりました。
生成AIにはハルシネーション（もっともらしい嘘を生成する）という特性があり、これは従来のITツールにはなかったリスクです。AIの出力を「正解」として扱う文化が社内にできてしまうと、こうしたトラブルは必然的に起きます。
さらにAI活用を本格化しようとすると、こんな壁にもぶつかります。
データガバナンスとセキュリティの壁——社内の業務データや顧客情報をAIに読み込ませたい。でも「その情報、外部のAIサービスに送って大丈夫なのか？」という問題が立ちはだかります。情報漏洩リスクやAIの学習データとして利用される可能性など、情報セキュリティ部門との調整を避けて通ることはできません。
「AIの出した結果に誰が責任を持つのか」問題——AIが作成した報告書に誤りがあったとき、利用した担当者の責任なのか、AI導入を推進した部門の責任なのか。この線引きが曖昧なまま運用を始めてしまい、トラブルが起きた途端に「AI活用は危険だ」と全面停止になる——そんなケースも実際に見てきました。
💡 AI導入には、従来のIT導入とは別の「AIガバナンス」という視点が不可欠です。利用ガイドラインの策定、出力に対する人間のレビュー体制、情報セキュリティポリシーとの整合——こうした土台を先に整えることが、AI活用を一時的なブームで終わらせないための条件になります。
よくある失敗パターン③ 「AIのことは○○さんに聞いて」——推進担当だけがAIを使っている皮肉
事例：AI活用が進んでいるのは、推進担当のPCの中だけだった
あるお客様の会社では、AI推進担当が精力的に動いていました。議事録の要約、競合調査、提案書の下書き——あらゆる業務にAIを取り入れ、成果も出していました。ところが半年後、社内アンケートを取ったところ、「AIを日常業務で使っている」と答えたのは推進担当を含めてわずか3名。他の社員にとってAIは、「○○さんに頼めばやってくれるもの」でしかなかったのです。
これは珍しい話ではありません。推進担当が優秀であればあるほど、周囲は「自分で使う」のではなく「あの人に頼む」方を選びます。 結果、AI活用のスキルも知見も一人に集中し、その人が異動や退職をした途端にすべて止まる——そんな構造ができてしまいます。
私自身も同じ経験があります。
DX推進担当として日々GASやPythonで業務改善ツールを作っていた頃、ChatGPTやGeminiが登場し、自分の生産性は一気に上がりました。でも気づけば、AIを使っているのは自分だけ。周囲からは「AIのことは推進担当に相談して」と。本来であれば各個人がAIで生産性を上げ、組織全体で業務改善を進められるはずが、そうはなりませんでした。
本当に必要だったのは、自分がAIで成果を出すことではなく、「自分がいなくてもAIが使われ続ける状態」を作ることでした。
業務ごとの活用事例をまとめる、AIの利便性を数字だけではなく肌で感じてもらう、そして「まずは自分で試してみて」と背中を押す——地味ですが、この「仕組み化」と「手離れ」の意識が、推進担当の仕事の本質だと今は思っています。
よくある失敗パターン④ 経営層の理解がないまま現場だけ動かそうとする
事例：「上が全然わかってくれない」の構造的な理由
熱心な現場担当者が新しいツールや仕組みを提案しても、「コストがかかる」「今のやり方で問題ない」という返答で却下される。AI活用の提案ではさらに「情報漏洩のリスクは？」「精度は保証できるのか？」という懸念も加わります。一方、経営層からすれば「具体的なROIが見えない」「失敗リスクが怖い」という本音があります。
この構図、本当にどこの会社でも起きています。現場は「現状の非効率」を肌で感じているのに、それを経営言語（コスト・時間・リスク）に翻訳する手間を省いてしまうことが多いんです。
AI活用の場合は特に、セキュリティやコンプライアンスへの懸念に正面から答える準備がないと、提案の段階で止まってしまいます。
逆に、リスク対策まで含めて経営層の承認をきちんと取り付けられたDX/AI施策は、たとえ小さな改善でも組織に定着しやすい傾向があります。「上を動かす」ことに苦手意識を持つ技術寄りの担当者ほど、ここで詰まりがちです。
DX/AIで本当に変わった会社は、「ツールを入れた会社」ではなく、「業務の設計と、それを支える技術基盤の両方を見直した会社」です。
では、変わっている会社は何が違うのか
いろんなお客様を見てきた中で、実際に変化が起きている組織には共通した特徴があります。
変化が起きている組織の共通点
・ツール導入より先に「現状の業務フロー」を言語化している
・小さく始めて、成果を可視化することを繰り返している
・業務理解と技術力の両方を備えた人材が推進の中心にいる
・AI利用ガイドラインやデータ取り扱いルールを早期に整備している
・「DX/AIのゴール」を数値で定義している（工数削減〇時間/月 など）
・経営層と現場をつなぐ「翻訳者」的な役割の人間がいる
特に3つ目は重要です。DX/AI推進が本格化するにつれ、「業務を知っている人」だけでも「技術に強い人」だけでも足りないという現実に多くの企業が直面しています。
業務フローを見直す力は不可欠です。しかし同時に、レガシーシステム（古い基幹システム）のデータ構造を理解し、全社的なセキュリティ設計を踏まえたうえでAIを業務に組み込める——そうしたITアーキテクチャの知見がなければ、本格的な変革には至りません。
私自身、営業職/企画職を経てエンジニアになった立場ですが、現場で痛感しているのは「業務理解」と「技術力」は二者択一ではなく、掛け合わせて初めて力を発揮するということです。業務を知っているからこそ「何を変えるべきか」が見える。技術を理解しているからこそ「どう変えられるか」が描ける。DX/AI推進に必要なのは、その両輪です。
DX/AIが「変化」になるための、最初の一歩
ここまで読んで、「うちの会社も当てはまるかも」と感じた方もいらっしゃるのではないでしょうか。では、何から手をつければいいのか。
まずおすすめしたいのは、「変わらない構造を言語化すること」です。なぜ変わらないのか。誰が何を恐れているのか。どこで意思決定が止まっているのか。ツールやAIの話をする前に、この問いに正直に向き合うことが、実はもっとも重要な第一歩になります。
そしてAI活用に踏み出す際には、「AIにできること」だけでなく「AIのリスクとその対策」まで含めて設計することが欠かせません。ガイドラインの策定、出力のレビュー体制、データの取り扱いルール——面倒に感じるかもしれませんが、この土台があるかないかで、AI活用が定着するかどうかが決まります。
DX/AIは技術の問題だけでもなく、組織と人の問題だけでもありません。技術・業務・ガバナンスの三位一体で取り組むことが、変化を本物にする条件だと、多くの現場を見てきて実感しています。
