はじめに
OpenAIによるChatGPTの公開から、早くも3年以上の月日が経ちました。
企業における生成AI活用は、2023〜2024年の試験導入のフェーズを経て、2025〜2026年にかけて、本格的な業務適用のフェーズへと移りつつあります。
特に2025年末のコーディングエージェントの台頭をはじめとするAIエージェントの性能が大きく向上し、個々人の業務効率化だけでなく、業務プロセスや組織全体を対象としたAI活用の検討が急速に進んでいます。
連日のように新しいモデルやツール、活用事例に関するニュースが飛び交い、生成AI市場はますます盛り上がりを見せています。
一方で、実際の企業導入に関するレポートを見てみると、以下のような内容が報告されています。
- 2025年末までに生成AIプロジェクトの少なくとも50%がPoC後に中止（Gartner）
- 企業の56%がAIによる売上増加・コスト削減のいずれも実現できておらず、AIが生む経済価値の74%を上位20%の企業が占めている（PwC）
- 生成AIのパイロットプロジェクトの88%が本番展開に至らなかった（IDC）
単刀直入に言えば、これだけ大きな盛り上がりを見せている一方で、多くの企業では、AI活用が上手くいっていないという事です。
これまでは、技術やトレンドそのものの新規性によって、AIを導入すること自体に一定の価値が認められる、いわば「ボーナス期間」のような状態でした。
しかし、ハイプサイクルが進行し、AIの導入自体の新規性が薄れていくにつれて、今後は「AIを使っているか」ではなく、「AIによってどのような価値を生み出したか」が問われるフェーズへと入っていきます。
では、どうすればAI活用はうまくいくのでしょうか。
残念ながら、こうすれば必ず成功するという普遍的な法則を定義することはできません。組織の規模や人材、業務プロセス、データ、システム、企業文化によって、取るべきアプローチは大きく異なるためです。
成功の形は組織や業務によって異なりますが、一方で、AI活用が失敗する組織にはある程度共通したパターンがあります。
本稿では、これまで複数の組織でAI導入や業務適用に関わってきた経験をもとに、AI活用が進まない組織に見られる代表的なアンチパターンを整理します。
日々更新されるAIのニュースやツールの情報に少し疲れている方にとっても、目の前のAI活用を一度立ち止まって見直すためのチェックポイントとして、本稿が役立てば幸いです。
それぞれのセクションは独立しているため、気になるところから読んで頂ければと思います。
AIの推進がうまくいかない組織アンチパターン【目次】
- 「AIは初速が出やすい」ということを理解していない
- AIを「買ってくるもの」だと思っている
- AIの創出効果で価格を判断できていない
- AI検討の議論の抽象度が高すぎる
- E2E自動化にこだわる
- 真の問題がAIではない事に気づいていない
- ROIに対する考え方が間違っている
1.「AIは初速が出やすい」ということを理解していない
AIの最も面白く、同時に最も注意すべき特性の一つが、「AIは初速が非常に出やすい」という点です。
なぜ世界的にここまでAIが盛り上がったのか。その大きな理由の一つは、使い始めた直後から、目に見えるアウトプットが出やすいからです。
「多くのPoCが失敗している」という現象を改めて読み解くと、これは要するに、「最初はいけると判断した人が非常に多かったものの、実際に進めてみると想定以上に難しかった」ということです。
最初から難しそうだと判断されていれば、そもそもPoC自体が立ち上がりません。
したがって、多くのPoCが失敗しているという現象の本質は、AIの実際の難しさに対して、「これはいけそうだ」と初期段階で判断した人が多かったことにあります。
AIを実務で使っている方であればよく分かると思いますが、資料作成や文章作成、アプリ開発などをAIに任せてみると、一見するとそれなりに良さそうなものが最初から出来上がってきます。
この段階では、関係者の第一印象は共通して、「おお、すごい」「これならいけそうだ」となります。
しかし、細部まで確認すると、修正や手直しが必要な箇所が数多く見つかります。最終版として仕上げようとすると、想定以上に時間がかかり、場合によっては、AIを使わない場合よりも時間がかかることさえあります。
さらに実務担当者ではなく、意思決定に近い上位レイヤーの人ほど、業務を見る解像度が抽象的になるため、最初に出てきた70-80点程度の成果物を見て、「十分に実用化できる」と判断してしまいやすくなります。
つまり、AIは初速が速いため、従来の感覚であればPoCや導入検討を進める基準となる70-80点を、容易に超えてきますが、一方で、本当に実務で安定して使える90-95点以上の水準まで引き上げることは非常に難しいという事です。
この70-80点から90-95点までの距離が見えにくいことによって、多くのAIプロジェクトは一度は立ち上がるものの、実業務への適用段階で停滞します。
ベンダーや営業担当者もこの特性をよく理解していて、見栄えの良いデモや提案資料を用意し「AIを使えばこれだけ簡単に業務を効率化できます」と非常によく作られたプロトタイプを見せてきます。
AIにおいては、魅力的なプロトタイプを作るところまでは比較的簡単で、難しいのは、そこから実際の業務条件や例外、品質基準、既存システム、運用体制に適応させ、安定的に使える状態まで持っていくことです。
そのため、AI導入を検討する際には、「AIは初速が出やすい」という特性を前提に置き、多少割り引いて評価する必要があります。
多くのIT導入では、成果は技術のSカーブのように、時間をかけて徐々に立ち上がっていきますが、AIは立ち上がりが極端に速く、その後の伸びが鈍化しやすいという特性を持っています。この違いを理解していないと、プロトタイプ段階の印象を過大評価してしまいます。
特に、組織の意思決定層が日常的にAIを使っていない場合、この特性に気づかないまま、楽観的な見立てでPoCを繰り返すことになります。
もちろん、初速が出やすいこと自体は悪いことではなく、そもそもプロジェクトが立ち上がらなければ何も始まりません。
重要なのは、その初速をプロジェクト立ち上げの推進力として上手く活用しながら、同時に、実用化までの難しさについても適切に期待値をコントロールしていくことです。
初版のデモについては少し割り引いて評価しつつ、そこをスタート地点として、組織での実務適用まで着地させる設計が必要です。
今こうして私が書いている間にも、企業側とベンダー側の意思決定層の間では、抽象度の高い楽観的な見立てに基づく無謀なPoC計画が無数に立ち上がっているでしょう。
自社の意思決定層に当たる人達が、AIと業務への解像度が低いほど注意が必要です。
2. AIを「買ってくるもの」だと思っている
これは「DX推進」という言葉が出始めた頃の、SaaSやパッケージ製品の導入イメージを強く持っている担当者に多いパターンです。
AIも従来のITツールと同じように、既存の製品を外から買ってきて導入し、社内に展開すれば活用が進むと考えてしまいます。
このような組織では、「どのLLMが最も性能が高いのか」「もっと良いAIツールや製品はないのか」と、常に社外の製品や最新技術を探し回る傾向があります。
モデルやツールの選定はもちろん重要ですが、ChatGPTのような汎用AIを社内に配るだけでは、活用効果が早い段階で頭打ちになることからも分かるように、製品の導入だけで本質的な価値が生まれるわけではありません。
AI活用の本質は、自社が持つ業務知識やデータ、ルール、判断基準といったコンテキストを、どのようにAIへ渡すかにあります。さらに言えば、既存業務の一部をAIに置き換えるだけではなく、自社のビジネスモデルや業務プロセスそのものを、AIを前提とした形にどう作り変えていくかが重要になります。
既製品は、どの企業でも利用できるように汎用化・抽象化されています。そのため、製品を導入しただけで、自社固有の業務課題や組織構造、複雑な例外処理にまで踏み込んでくれることはありません。
近年、AIベンダーがFDE（Forward Deployed Engineer）と呼ばれる職種を用意するようになっていることもその象徴になります。
ベンダーとしては、本来であれば標準化された製品をそのまま販売し、少ない工数で多くの顧客に展開できる方が効率的ですが、それにもかかわらず、顧客企業の現場に深く入り込み、個別の業務やシステムに合わせて実装を支援するFDEが重視されているのは、製品やツールを導入するだけでは、実際の業務価値につながらないからです。
これは、少し前に広がったカスタマーサクセスという役割だけでも不十分であることを示しています。
製品の利用を支援し、利用率を高めるだけではなく、FDEのように顧客企業の業務プロセスやシステム、データ、組織課題にまで踏み込まなければ、AIを実務に定着させることは難しいということです。
つまり、AI推進担当者は、社外の製品や技術だけではなく、もっと自社の内側に目を向ける必要があります。
従来のツール導入の延長線上で、展示会に足を運び、ベンダーの提案を受け、次々と新しい製品を試しているだけでは、本質的な課題は解決しません。
AI推進担当者が、社内の業務部門との対話よりも、社外のベンダーや製品の情報収集に奔走している場合は注意が必要です。
3. AIの創出効果で価格を判断できていない
これも先ほどの担当者のようなケースで多いのですが、従来のSaaS導入の延長でAI導入についても考えがちだという事です。
つまり、一般的なSaaS導入の価格感のイメージでAIについても捉えてしまうため、「ユーザー当たり月980～1500円」といったなんとなくの価格感があり、それ以上は高額だと考えてしまうという事です。
典型的なケースが、ClaudeやOpenAIを始めとするCowork系の導入になります。
これらは最も安いProプランではトークンが足りず、本格利用のケースでは100ドルプラン(ユーザー当たり月15000円程度)が推奨になります。
この時点で従来のSaaSの延長で「月15000円は高すぎる」と判断してしまうのですが、会社が負担する社員の時給は年収500万円で約4000円、年収1000万円の場合は約8000円になります。
つまり、Coworkを利用した従業員が、月に2-4時間以上削減できれば費用対効果が出る計算になります。
社内の主要ツールとCoworkを接続し、自身の業務を代替・支援する業務スキルを定義することで、月に数時間という削減効果は容易に達成できるでしょう。
また、スキルは容易に横展開できるので、各人が個別にスキルを作る必要もありません。デスクトップ操作も可能なため、最初はRPAのような使い方で重宝するケースもあるでしょう。
従来のSaaSの価格帯に強いアンカリングがあり、月15000円の時点で高いと感じてしまうようですが、全員が自分専属のアシスタントや部下を持つような形になるので、費用対効果で考えると破格と言えるでしょう。
いわゆるITツールというイメージと価格帯のままで捉えてしまうと、導入の意思決定を見誤る形になってしまいます。
最近では、AIはIT費用ではなく人件費として捉えるべきだという議論もよく出ており、今後は、AIに一見高額なコストを払うもののそれ以上の効果を得る企業と、AIをITツールの延長として捉え、安いツールや無償版で限定的な効果しか得られない企業に二極化していく可能性があります。
私は職業柄、AIに月10万円以上課金していますが、アシスタントを雇うには何倍ものコストがかかるため破格の安さだなと感じています。
むしろ破格のリソースが自由に調達できる状態であるため、どちらかというと今後もっと課金が必要な状態にしていく必要があるなと思ってます。
AI時代においては、AIにかかるコストと予算の考え方を根本的に見直していく必要があるため、担当者や意思決定に関わる人達が、従来のITツールのイメージや予算感で捉えている場合は注意が必要です。
4. AI検討の議論の抽象度が高すぎる
AIの初速の速さと相まって課題となるのが、そもそもAI活用に関する議論の抽象度が高すぎるという事です。
よくあるプレゼン資料や提案資料などでは、業務機能や組織機能、かなり抽象度の高い業務プロセスの上に、AIエージェントのアイコンが置かれ、「AIを活用して業務を効率化」などの大きなメッセージだけが書いてあります。
AsIs/ToBeプロセスも概念レベルにとどまり、具体的に何をインプットとして何をアウトプットするのか、どの程度効果が期待できるのかが見えてきません。
なんとなくこの当たりでAIが使えるのではないか、という事を意思決定者とベンダーの営業担当者で会話している状態です。
これはある程度仕方のない事ですが、FDEのように、現場の業務プロセスやデータ、システム環境の構築状態などを実際に見てみないと具体的な絵は書けないためです。
現場の実務の所はよくわかっていない上位レイヤーの担当者と、他社のため当然内側まではよくわかっていないベンダーの営業担当者の間で、抽象度が非常に高い状態で、この領域でAIを使って効果を出すという緩やかな合意だけが握られてしまいます。
そして初速の速いプロトタイプや検証結果を基に、関係者間で楽観的な目標設定がなされ、実際にプロジェクトを進めていくと、当初想定していなかった様々な課題にぶつかり、着地が難しくなる(＝PoC失敗)ということです。
もちろん構想策定から始める以上、概念レベルの検討フェーズは必要ですが、問題になるのは、実際に業務の土地勘がある人とAIプロジェクトの目利きができる人による検討が甘いまま、プロジェクトが先に走ってしまうというケースです。
というのも実際のところ、AI活用を検討しているプロジェクトで、実際はAIが不要であるというケースは少なくありません。
AIの業務適用を実装する立場の人であれば、ある程度進んだフェーズで「これ実はAIいらないんじゃないか？」と思った事は一度や二度ではないのではないでしょうか。
ユーザーの入力情報がバラバラであり、AIに整形・構造化させた上で後続プロセスで利用したいのであれば、そもそも入力フォーム側を整備すれば良いですし、従業員がデータの内容に応じて判断している箇所をAIに代替させたいという事であれば、ルールやマスタを定義してプログラムで振り分け、ルールで定義できない一部の例外系だけを人のチェックに回せばよいだけです。
ルールで定義できない箇所は結局AIにも正解がわからないので、人の最終チェックが必要になります。1割の例外系の対処のために、残りの9割までAIで処理させる必要はありません。
端的に言ってしまえば、AIが必要になるのは「揺れのある情報を扱う時だけ」です。揺れのない情報は全て、プログラム・ルールベースの自動化で解決すべき問題になります。
そして、業務プロセス構築の観点でいえば、そもそも揺れのある情報が生まれないようにする事が重要になります。
業務が整理されていないために、バラバラで構造化されていないデータ、属人性が高いためにルール化されていない業務プロセス。この揺れをAIで解消しにいこうとするわけですが、そもそもこの揺れは本来生まれるべきではない揺れだという事です。
上流プロセス側の問題を下流プロセスでAIによって解決するというのは、基本的には筋の悪い戦略になります。
議論の抽象度が高い段階では、「ここでAIを使えば業務が効率化できるのではないか」と考えがちですが、業務の解像度を上げていくと、ここはAIで解くべき問題ではないという事がよくあります。
私もかつてのプロジェクトで、業務を真面目に整理していった結果、AIを使うべき箇所がなくなり、「目的は達成できるけど、AIプロジェクトなのにAIを使う場所がなくなってしまったな。。」という変な悩みを経験したことがあります。
ただ、AIを推進する立場としてはおそらく、「AIを使わない」という意思決定ができ、その理由をステークホルダーに説明できるスキルが非常に重要で、業務コンサルタントの視点で言えば、業務プロセスの再構築を進めた結果、AIが不要になったという事であれば、ある種一流の業務コンサルタントと言えるのかもしれません。
当然ですが、AIは目的ではなくあくまで手段である上に、AIを使う場所には必ず、「信頼性」や「再現性」という難しい議論がついて回ります。
これは、AIはなるべく使わないほうが良いという話ではなく、まず、「AIを使わずに解決する方法はないか？」という問いを立て、関係者間でディスカッションした結果、その問いが明確にNo(AIが必要である)という場合にのみ、AI活用を検討すべきだということです。
ルールベースのプログラムは、AIに比べて高速かつ再現性が100%であるため、AI活用は1stオプションではなく2ndオプションになります。
AI活用に最初はワクワクしていた業務ユーザーの方も、ディスカッションや実務適用の検討を進めてリテラシーがどんどん上がっていくうちに、ある日「もしかしてこれAI必要ないですか？」と気づく事があります。
そして、AIの活用をやめて、そもそも論に立ち返ったところ、別の方法で問題が解決するというケースが少なくありません。
こうしたAIに関するリテラシーがないまま、上位レイヤーだけで抽象度の高いAI活用の意思決定を進めると、AIで解くべきではない問題をAIで解こうとすることになります。その結果、不必要に難易度が上がってしまい、プロジェクトがうまく進まなくなります。
AIプロジェクトを開始するタイミングでは、誰がどのレベルまで議論したのかという見極めが重要になります。
5. E2E自動化にこだわる
これはどちらかというと真面目すぎることによって起きる問題ですが、AIを使う業務プロセスにおいて、E2E自動化にこだわってしまうケースです。
自動化率を高めるために、可能な限りすべての工程を自動化しようと試みますが、E2E自動化にこだわるあまり、プロジェクトが上手く進まなくなるケースがあります。
大前提として「AIとE2E自動化は非常に相性が悪い」という事を念頭に置いておく必要があります。
これまで扱えなかった非構造化データもAIで扱えるのだから、より広範なレベルでE2E自動化を実現できるのでは？と思ってしまいがちですが、AIが持つ柔軟性の大きな代償として、再現性が100%になる事はないという性質があります。
ルールベースのプログラムの場合は単純で、事前に決められたロジックに関しては再現性100%で実行します。逆に事前に決められていないケースが来た場合、再現性100%でエラーになります。
AIの歴史自体は長いですが、身の回りにある実世界のシステムの大半は、ルールベースのプログラムで動いています。これは、実世界では信頼性が非常に重要だからです。
生成AIの活用事例で言えば、アイディア出しやサマリ、資料のドラフト作成、情報検索支援などが真っ先に上がりますが、これらに共通するのは、AIが失敗しても直ちに致命的な事象にはならないという事です。
基本的には後工程で人間のチェックが入り、最終的な責任分界点が人間に移るという前提があるため、AIを使っても問題ないという事です。
例えば、作成に時間がかかっている資料作成をAIに代替させ、それをそのままクライアントに提出するというAIプロジェクトを立ち上げた場合、上手く作りこめばほとんどのケースでは問題なく運用できるようになるかもしれません。
ただし、全く予想していなかった形で、個人情報が誤って含まれていたり、クライアント名が誤っていたりという可能性を完全に排除する事はできません。
発生したエラーをもとにプロンプトを強化したり、チェック用のAIを繋げてダブルチェックする形にしても、エラーとなり得るケースは無限にあるため、容易にルール爆発してしまいます。
仮にPoCやパイロットを入念に実施し、一度もエラーが出なかったという検証結果が得られたとしても、それはあくまで「これまでのケースは大丈夫だった」というだけです。安全性は高いとは言えても、将来の安全性までを保証するものではありません。
つまり、再現性100%を保つ事はAIにはそもそもできないため、E2E自動化をAIで目指そうとすると終わりのない試行錯誤が始まってしまいます。
AIを使う際に最初に検討すべき点は「どこで妥協するか」言い換えれば「どこまでで諦めるか」という事です。
再現性100%にはならないAIの特性を前提として、AIを利用する箇所と範囲の線引きをしていきます。
AIを活用した自動化プロジェクトの基本方針は「中間プロセスの自動化効果の最大化」になります。
E2E自動化は諦めるものの、人間によるチェック工程が細かく入るほど効率化効果は下がるため、現行のAsIsフローを眺めて、人が入る工程を前と後ろに可能な限り寄せ、中間プロセスをAIを使って自動化していくという形です。
最終的に人が確認しやすい形にするため、トレーサビリティの確保やログ出力の機構なども備え、AIが実施したタスクと判断理由の透明性を高める形で、チェック工程の労力も減らしていきます。
部下にタスクを依頼した際も、「できました」と結果だけ報告されるより、「このステップで作業を実施し、この内容に基づいてこの判断を実施しました」と報告されるほうが明らかに楽だと感じるのではないでしょうか。
もっと言えば「この点は少し不安なのでチェックしてもらえませんか？」や「この箇所については明確な対応方法がわからなかったため保留にしています。対応について教えて頂けますか」という形で、全てそれっぽいアウトプットを出されるより、わからなかったところはわからなかったと報告してくれるほうが有難いでしょう。
また、中間プロセスを可能な限りAIに任せていく分、最初の指示出しや認識の擦り合わせが重要になります。そのため、業務の性質によっては、最初の工程もなるべく人間が入ったほうが良いでしょう。多くのケースでは、人間がAIの処理の前と後ろを挟む形になるはずです。
AIを活用した自動化戦略として、最初から自動化率100%のE2E自動化の領域拡大を目指すと、プロジェクトの難易度が極端に高くなる上に、適用できる領域もかなり限定されてしまいます。その結果として「AIはやはり難しい」という関係者間でのイメージが定着し、他のAI施策まで停滞する可能性があります。
AIの特性を踏まえると、点と線のような限定的な領域でのE2E自動化を目指すのはなく、領域横断的に70-80%程度の自動化率から始め、その割合を徐々に90-95%へ引き上げていくような、全体を面で塗りつぶしていく戦略のほうが有効でしょう。
1つの業務で自動化率100%を目指すよりも、2つの業務で自動化率70%を達成するほうが、難易度が低い上に、より高い効果が得られます。
「AIは再現性100%にはならない」という前提をプロジェクトの立ち上げ段階から関係者間で念頭に置き、「どこを目指すのか(どこで線を引くのか)」という事の擦り合わせがある種最も重要になります。
最初から自動化率80%を目標として運用設計を検討していれば、自動化率95%のプロジェクトは大成功ですが、最初から自動化率100%を目標にしてしまうと、運用設計の検討が甘くなるため、自動化率95%では運用が耐えられず、そもそも本番稼働が難しくなるという可能性があります。
PoCが失敗する原因の多くは、AIの特性を適切に踏まえていない、無謀な目標設定にあります。
私自身としては、AIプロジェクトの検討の際はまず、「AIを使わずに解決する方法はないか」という事を最初に考えます。そして、AIを使うべきだとなった場合は次に、「どこまでで諦めるか」という事を考えるようにしています。
最初から全てをAI前提で検討し、解像度の低いままE2E自動化を目指すプロジェクトは、高確率で失敗すると言ってしまってよいでしょう。
ただ、最初から現実的な事をあまり言い過ぎても、プロジェクト関係者の温度感が下がってしまい、それはそれでプロジェクト失敗の大きな要因になってしまいます。
このようなケースでは、AIに対する関係者の温度感とプロジェクトの推進力は保ちつつも、現実的なラインを段階的に見せながら、上手く目標を適正値にもっていくというスキルが重要になります。
6. 真の問題がAIではない事に気づいていない
AIプロジェクトの最も典型的な失敗事例、そしてAIプロジェクトの難しさは、解決すべきほとんどの問題はAI以外の点にあるという事です。
AIプロジェクトなので、優秀なAIエンジニアがいれば上手くいくのでは？と考えがちですが、優秀なAIエンジニアが仮にうまく採用できたとしても、それだけでは借りてきた猫のような状態で、思ったような成果が出せないでしょう。
なぜならAIプロジェクトの成否を決める要因において、AIが担う要素はおそらく1-2割程度だからです。
というのも、既にAIの性能は非常に高く、ある種コモディティ化している状況であるため、最新モデルを使っておけば、誰が使ってもそれほど大きな差はでません。
生成AIが出た当初はプロンプトエンジニアリング技術が注目され、「プロンプトエンジニア」のような職種も一時期登場しましたが、今はもうAIがプロンプトを書く上に、プログラムもAIに書かせるようになっています。
AIの使いこなし自体は当然重要な要素ではあるものの、AIプロジェクトの成否という観点で言えば、大きな割合を占めるものではありません。
根本的なボトルネックは「業務プロセス」「データ」「システム基盤」「推進組織体制」になります。
まず、業務プロセス自体が複雑で属人化されており、ルールも定義されていない状況であれば、どれだけ高性能なAIを使ったところで業務効率が上がる事はありません。
整理されておらず、既に変数だらけの業務に対して、更にAIという大きな変数を追加する事になるので、収拾がつかなくなるどころか、AIのエラー対応という新しい業務まで発生してしまいます。
複雑な業務プロセスをAIでなんとか解決しようとするのではなく、シンプルな業務プロセスに再定義した上で、プログラムやAIに高速に処理させるべきです。先に動かすべき変数は業務プロセス側であり、AIではありません。
次にデータです。これについては当然ですが、必要なデータが適切に整備されているかという事です。
AI自体は供給されたデータが誤りかどうかを判定する事はできないので、一般常識からみて明らかに間違いでない限り、与えられたデータは正として判断します。
古くなっているドキュメントや誤ったデータが含まれているような場合も、AIのコンテキストに一度積まれてしまうと、その前提でAIが処理を進めてしまうため、AIに渡す情報の品質がまず何よりも重要になります。
そして、もう一つ重要なのがAIに情報を渡すタイミングです。
「AからCのタスクを順番に処理して。必要な情報は全部このフォルダとこのデータベースの中にあるから」と指示する場合と、「Aのタスクを実施する際は、この2つのファイルとこのテーブルを参照して、Bのタスクの場合は・・」とステップ毎に必要な情報を限定して提示するという事が重要になります。
全て正確な情報であったとしても、渡された情報はAIの判断に影響を及ぼすため、その時点で不要な情報は渡さないという選択が重要になります。
この時に、データが整理されていない状態だと「どこかにある」と言うしかなく、AIが情報を探索するという新しいタスクが生まれてしまうため、当然業務品質も下がってしまいます。
AIがタスクを実施する際に、必要最小限の情報を適切なタイミングで渡してあげる形にする事によって、AIの信頼性と再現性も大きく向上します。これには当然ですが、データが適切に整理・管理されている必要があります。
データベースを丸ごと渡すのではなく、その業務プロセスでAIが使うのに最適な形のデータマートを整備してあげるほうが、全体の品質の大幅な改善が見込めるでしょう。
次にシステム基盤ですが、これはある種ボトルネックというよりノックアウトファクターに近く、そもそも社内で利用しているシステムにAPIやSQLの口がなく、AIが必要なデータにアクセスする手段がないというケースです。
AIプロジェクトの構想を進めるのは良いのですが、そもそも必要なデータにAIがアクセスできるのかという確認が先になります。
とはいえ、すぐにそのようなシステム基盤を準備する事は難しため、やむを得ない場合は、夜間バッチでデータをダンプしたり、RPAで画面からデータを抜くという事もありますが、リアルタイム性の欠如により、効率化効果が大きく低下してしまったり、そもそも運用上難しいという事が多くあります。
システム環境がAIネイティブな環境になっていないと、議事録作成や要約、資料のドラフト作成などの表面的なAI施策しかできないため、AIの活用を検討する領域においては、AIが動くための環境を整えておく必要があります。
AIが動く足場が非常に悪い状態、場合によっては動けない状態では、どれだけAIの話をしても意味はありません。
最後は推進組織体制です。これまで述べてきたように、AIプロジェクトは業務プロセスの整備やデータ基盤の整備、システム環境の整備など、あらゆる観点での対応が必要になります。
つまり、非常に強い権限が必要かつ、部門を超えてステークホルダーを巻き込んでいく推進力が必要だという事です。
基本的には、経営層直轄のDX推進部という形で、攻めのDXがミッションのチームを組成し、適切な権限を与えない限りは難しいでしょう。
典型的な失敗例が、いわゆる従来型の情シスになんとなくAI施策も任せているケースです。
これは従来型の情シスが悪いという訳ではなく、そもそもKPIが違い過ぎる事に問題があります。というのも、評価指標などで明文化されているわけではないものの、多くの場合、組織の運営方針が加点方式ではなく、減点方式になっているためです。
減点方式のため、ミスをしないこと、つまりシステムやセキュリティ障害を起こさないことが最優先になります。そして、ミスをしないための最適な戦略は、新しい事はなるべく実施しない事(変化点を作らない事)です。
あらゆる変化点は成功も失敗の確率も含んでいるので、変化点を起こさない事が重要になり、結果的に業務部門からの要望はなるべく断る事が内部の空気として求められるようになっていきます。
私自身はあまり見た事がないのですが、情報システム部が業務部門と密に連携していて、社内でも非常に信頼されているという会社は非常に少ないのではないでしょうか(そうではない場合は素晴らしい会社)。
これは情報システム部やそこにいる方達が悪いというわけではなく、そういう経営判断だという事です。
優秀なIT人材は海外では年俸数千万円という事は当たり前ですが、従来型企業の場合は、むしろIT部門は、給与テーブルが抑えられるという逆の傾向が未だにあります。
そういった歴史と背景のある情報システム部に、不確実性が非常に高く、業務部門の巻き込みや、難しいステークホルダーの期待コントロール、高い推進力が必要となるAIプロジェクトを手放しで任せることは無理があります。
組織文化を一気に変える事はなかなか難しいため、経営層直轄で動ける攻めのDX部隊を作り(テクノロジーに強い中途採用者と社内業務に詳しい人材のハイブリッドが望ましい)、加点方式のKPIを設定する必要があるでしょう。
ここまでの内容をまとめると、業務プロセスとデータが整備されていること、システムが持つデータへアクセスする基盤が整備されていること、そして推進組織が高いリーダーシップを持っていることが重要であり、これが満たされている場合、AIプロジェクトはよほど目標設定を間違えない限り良い結果が出るでしょう。
スキル視点のロールで言えば、業務コンサルタントやデータベース・インフラエンジニアのほうが優先度が高く、いわゆるAIエンジニアが出てくるのはある種最後の段階であると言えます。
最新のAIモデルはどれを使えば良いか、どのようなAIツールを使うのが良いかという事は、このような課題からすれば非常に小さな問題であり、LLMはClaudeかGPT、Geminiのどれが良いかと言われれば、どれでもよい(今議論すべき問題はそこではない)という事になります。
社内のAIプロジェクトで、AIに関する話題だけが踊っていれば要注意で、社内システムやデータ・業務課題の解消がメイントピックとして議論されている状態であれば健全なプロジェクト(良いプロジェクト)であると言えます。
AIを使わないという意思決定も含め、今何がボトルネックで、どの変数を動かすべきかという目利きができる人材が重要になってきます。AIの話だけをしていても、真のボトルネックが解消することはありません。
7. ROIに対する考え方が間違っている
最後に、ROIについてです。
AIにそれほど詳しくない人であっても、「ROI」という言葉はビジネスの共通語として誰しもが理解できるため、現場の状態やAIの特性を十分に把握していない人がROIを試算した場合、その数字がかえってプロジェクトのボトルネックになってしまうことがあります。
大前提として、ROIは出るか出ないかというゼロイチの話ではなく、「どの期間で切り取るか」によって、同じ取り組みであってもプラスにもマイナスにもなります。
わかりやすい例が新卒採用です。特に大手企業などでは、入社後に半年から1年単位にわたる研修期間があります。そして、長い研修を終えて現場に配属されたとしても、現場ですぐに役に立てるわけではありません。
むしろ、右も左もわからない新人社員のために先輩社員が指導役としてつき、自分の業務時間を削りながら教育していく必要があります。
つまり、新卒採用を半年から数年という期間で切り取った場合、ROIとしては完全にマイナスになります。しかし、新人社員が徐々に経験を積み、現場の戦力として活躍できるようになると、どこかのタイミングで損益分岐点を超え、そこからROIがプラスになっていくという長期的な施策だということです。
自分でROIを試算する場合も、自分以外の誰かが試算したROIを見る場合も、まず確認すべきなのは、どの期間で切られているのか、そしてその設定期間が適切なのかという点です。
ROIを求める期間が極端に短く「1カ月でわかりやすい効果が出るAI施策」を求められると、実施できることは非常に限られてきます。
誰でも使えるちょっとしたAIツールの導入や、部門間の調整を必要としない当たり障りのないAI研修など、表面的な施策しか実施できなくなるでしょう。
重要なのは、投資としての視点を持ちながら、施策の性質に応じてROIを評価する期間を適切に設定することです。
短ければよい、長ければよいという話ではなく、例えば短期施策は数カ月単位、中期施策は半年から2年単位、長期施策は2年から5年単位というように、複数の時間軸で施策を分けて検討していけばよいでしょう。
短期的なROIを中心に設定し、いくつかのAIプロジェクトで試行錯誤したもののうまくいかず、「AIはやはり難しい」「AIはROIが出ない」と結論づけても、それでは組織の改善にはつながりません。
AIに限った話ではありませんが、改善の痛みを伴わない即効性のある施策は、多くの場合、本質的かつ持続的な効果をもたらしてくれることはありません。
そして、AIプロジェクトでROIが出ない根本的な理由は多くの場合、AIが難しいからではなく、組織に「これまでの借金」が積み上がっている状態だからです。
この借金の正体は、前述した業務・データ・システム・組織のボトルネックで、これらが未整備の状態であることは、すでに大きな負債を抱えているのと同じ事になります。
この状態でAIプロジェクトに短期的なROIを求めることは、これまで蓄積してきた組織の負債を、すべてAIに返済させようとしていることに等しいでしょう。
しかし、本来はAIで成果を出す前に負債を返済する必要があるため、基盤が整っていない状態で、AIによっていきなり大きな効果を出そうとすることには無理があります。
これは、誰も耕していない荒れ果ててしまった農地に、いきなり作物を植えるようなもので、どれだけ優れた作物を外から探して買ってきても、土壌に根本的な問題がある限り、作物がうまく育つことはありません。同様に、AIプロジェクトの成否を決めるのは、AIのモデル性能ではなく、AIを活用する組織環境になります。
AIによって一足飛びに既存の問題を解決できるかに思えましたが、実際には逆の現象が起きており、生成AIの登場以前から地道にDXへ取り組んできた企業、つまりAI-Readyな企業が、AIを活用することで加速度的に大きな効果を生み出している状態です。
逆に、丁寧に耕された肥沃な土壌であれば、多少扱うことが難しい作物であっても、十分に育てることができ、極端に言えば、業務やデータが整理されていない組織がClaude FableやMythos、GPT-5.6といった最新モデルを導入するよりも、地道にDXへ取り組んできたAI-Readyな組織がGPT-4oを使うほうが、高い成果を出せるでしょう。
AI-Readyな組織の状態であれば、どのプロジェクトでもROIが出やすくなり、その投資を回収するまでの期間も短くなります。
そのため、AIプロジェクトでROIが出にくい場合に考えるべきなのは、「どのAIモデルを使えばよいか」ではなく、「どの組織課題がボトルネックになっているのか」ということになります。
一足飛びには進まないからこそ、自社の状態に向き合って地道なDXに取り組み、将来的にROIが出やすい環境をつくっていくことで、大きな果実を継続的に刈り取ることができる状態になります。
AIは良くも悪くも、これまで組織に蓄積されたDX視点の負債の存在を、一気に表面化させる技術ということもできます。
短期的には痛みを伴いますが、AIの進化がさらに加速していく数年先の未来に向け、このような組織課題を解消できた企業ほど、今後更に大きな効果を享受できるようになります。
仮に目先のAIプロジェクトが期待どおりの成果を出せなかったとしても、その失敗によって関係者が組織課題を臨場感を持って認識し、AI-Readyな組織へ変わる必要性について共通認識を持てたのであれば、そのAIプロジェクトは長期的に見て、大きなROIを生み出したと言えるのではないでしょうか。
一方で、組織の負債という観点を持たず、短期的なROIだけを求める施策を繰り返してしまうと、気づいたときには既に、取り返しがつかなくなるほどの差が生まれているでしょう。
AIの最新モデルへのスイッチ自体はすぐにできますが、組織課題の解決にはかなりの時間がかかるためです。
具体的には、次のようなサイクルを回していくことが重要になります。
- 組織の現在の環境面の課題を可視化し、AIに対する期待値と難しさを関係者間でそろえる
- 比較的足場が整っている、勝ち筋の高い領域からプロジェクトを立ち上げる
- 業務やデータの課題を改善しながら、プロジェクトを本運用まで持っていく(PoCでは終わらせない)
- 成果を社内に共有し、他部署からも「自分たちも取り組みたい」と思われる状態をつくる
- 他領域におけるAI活用の可能性とボトルネックを可視化する
- プロジェクトを横展開しながら、組織の足場をさらに固めていく
このサイクルを繰り返すことで、組織は徐々にAI-Readyな状態へ変わっていきます。
当然ですが、最初から「業務プロセスとデータの整理が重要です」と伝えるだけでは、多くの人は具体的に動こうとはしません。
出口やリターンが見えない状態では、単に労力だけがかかる取り組みに見えてしまい、なぜ今それをやる必要があるのか、関係者が腹落ちしにくいからです。
そこで逆に活用できるのが、AIの初速の速さで、まずAIでプロトタイプをつくり、目に見える形で将来の業務を示すことで、関係者が「これが実現すれば、自分たちの仕事がこれだけ変わる」と具体的にイメージできる状態をつくります。
一方で、実際にAIを動かしてみることで、業務プロセスやデータ、権限、システム連携など、うまくいかない原因も明らかになってきます。
しかし、AIによる明確な出口が見えていれば、「この業務を整理すれば実現できる」「このデータを整備すれば、さらに大きな効果が出る」という形で、地道な改善に取り組む理由とモチベーションが生まれます。
AIという出口が見えているからこそ、業務やデータ管理に対する関係者の意識が高まり、これまで後回しにされてきた組織課題にも取り組めるようになるということです。
つまりAIは、組織課題を可視化し、環境を整備していくための有効なトリガーにもなり得ます。
AIで未来の姿を見せ、現状とのギャップを明らかにし、そのギャップを一つずつ埋めながら成果を出し、さらに次の領域へ展開していくという、正のサイクルを回していくことが重要です。
未来に向けた投資という観点を大きく含むため、この辺りの多面的な要素を考慮しない機械的なROI設定は、組織のDX推進をむしろ鈍化させる要因になってしまいます。
AIはどちらかというと下流の話なので、組織課題の改善という上流の改善のほうが、あらゆるAI施策への波及効果が大きく、本当の意味でROIが出やすいのは後者への取り組みになります。
実際に現場レベルでAIを推進しているプロフェッショナルの知人達と話すと、ほとんどがAIの話ではなく、組織課題をどう解消するかという話題に終始します。
まとめ
いかがだったでしょうか。
重要なものからそうでないものまで、AIに関する情報が目まぐるしく飛び交う毎日ですが、AI活用がうまくいかない組織には、概ね共通するパターンがあります。
今は、目先の新しいモデルやツールをとにかく試すというフェーズではなく、今後も続くAIの進化による利益を持続的に享受できるよう、本格的に組織の足場を固めていくフェーズだと思っています。
組織がAI-Readyな状態になっていれば、AIの性能が向上するたびに、その恩恵をより大きく受けられるようになります。言ってしまえば、AIの進化にフリーライドできる状態をつくるということです。
最新のAIに関するキャッチアップももちろん重要ですが、変化が速く、賞味期限の短い情報の収集に奔走するよりも、自社の業務やデータ、システム、組織体制に中長期的に向き合い、ボトルネックを一つずつ解消していくことのほうが重要になります。
大切な話というのは、得てしてつまらないものですが、派手で面白そうなことは誰でも取り組むため、本当に大切なことを粛々と進められる組織が、AI時代において大きな競争力を持つ事になるのかもしれません。