企業AIの導入：デモが動くことはスタート地点にすぎない、本当の難所は4つ

テンセント研究院がこのほど公開したレポート「最前線での共創、双方向のエンパワーメント：FDEモデル業界観察と実践」は、複数の機関への一次インタビューと調査、さらにテンセントクラウド自身の顧客現場での経験を組み合わせ、企業のAI導入で繰り返し起きる問題を分析しています。あわせて、そうした困難がデリバリーの現場でどのように発生するのかも論じています。FDE（Forward Deployed Engineer、最前線配置エンジニア）は顧客現場に深く入り込み、技術を本当に定着させる役割です。ただし、このレポートが扱っている問題の多くは、企業内部のAIチームも同じように直面します。

視点をデリバリー側から企業自身に移すと、よくある4つの問題と、企業が変えるべき3つの点が見えてきます。

一、「デモが動く」を「製品がリリースできる」と同一視してしまう

AIプロジェクトでは、早い段階で実現可能性を検証するデモを作るべきです。モデルが自社データでどれだけ機能するか、インターフェースがつながるか、実際の効果が要件を満たすか——これらはすべてデモで確かめる必要があります。デモの価値もここにあります。実現可能性を検証し、リスクを早めに洗い出すことです。

問題は、見た目には華やかなデモが、本番環境に入った途端にほころび始めることです。たとえばAIカスタマーサポート。デモで「返品条件は何ですか」と聞けば、とても完成度の高い答えを返します。しかし実際の顧客の問い合わせはずっと複雑です。「商品はもう開封済み」「前の担当者が特別対応を約束してくれた」「結局、今この商品を返せるのか」。本番環境では、注文照会が失敗したらどうするのか、ツール呼び出しがタイムアウトしたらどうするのか、モデルの判断が不確かなときは処理を続けるのか人に引き継ぐのか——こうした例外パスには、明確な対処方法が求められます。

レポートは80%、95%、99%という3つの数字で、この落差を示しています。あるエージェントがシナリオの80%をカバーするのは、すぐに実現できます。大規模モデルと簡単なプロンプトで完了します。しかしカバー率を95%まで引き上げ、本番環境の信頼性を高めるには、業務知識を補い続け、プロンプトを改善し、エンジニアリングの作業を大量に積み上げる必要があります。最も難しいのは、カバー率を99%まで押し上げることです。

企業のAIと個人のAIは違います。一度の誤りが深刻な結果を招くことがありますし、接続するシステムが増えるほど、監査、ロールバック、人の引き継ぎも複雑になります。レポートは企業AIの導入を、シナリオの特定、プロトタイプ検証、試験運用、本番展開、規模拡大という5つの段階に分けています。ただし本番稼働の後にも、実際の業務の中で磨き続けなければならない仕事が大量に残ります。

二、AIアプリを作れることと、価値の高いシナリオを選べていることは別

レポートはFDEに必要な能力を2つに分けています。何をすべきかを判断する役割と、それを実際に作り上げる役割です。AIは後者、つまりエンジニアリング実装のコストを下げました。しかし価値の高いシナリオを見極め、業務を理解することは、依然として人の判断を必要とします。作ることが容易になったからといって、企業が自然と「何に取り組む価値があるか」を知るわけではありません。

典型的な例が「競合がAIカスタマーサポートを入れているから、うちも作ろう」です。これはニーズの手がかりではありますが、本当に解決すべき問題が何なのかは語っていません。問い合わせの重複が多すぎるのか、複雑な問題の処理が遅いのか、サービスの品質が安定しないのか、それとも情報がつながっていないのか。問題が違えば、打ち手も投資も変わります。AI導入が向く問題もあれば、情報をつなぐことや既存システムの調整で解決できる問題もあります。

企業がAIを適用できる場面は数多くありますが、それぞれの価値と実装の難易度は同じではありません。AIチームは業務と一緒に、どの問題を優先して解く価値があるのか、解決後にどの指標が改善するのか、その投資は割に合うのかを判断する必要があります。AIアプリを作れることと、それを作る必要があることは別問題です。

三、社員にできることを、AIがうまくやれるとは限らない

価値の高いシナリオを選ぶことは、「これをやる価値があるか」という問いに答えたにすぎません。もう半分の問い、つまりそれを完遂するために必要な業務知識、ルール、システムの条件がそろっているかは、まだ答えていません。

企業の多くの協働はタイムリーなコミュニケーションに依存し、意思決定はキーパーソンに依存し、大量のプロセスと判断ルールは社員の経験とチームの暗黙の了解の中に存在します。業務が毎日問題なく回っているからといって、その運用の仕組みが明確に言語化されているわけではありません。ましてや、AIが既存のドキュメントを渡されただけでそのとおりに実行できるわけでもありません。

レポートはERPの例を挙げています。企業がAIに受注フローを自動処理させようとし、実装の段階になって、適応させるべきルールが山ほどあることに気づきます。たとえば、受注金額が一定額を超える場合は総経理の承認を得なければ出荷できない、完成品倉庫と原料倉庫では入出庫のルールが異なる、といった具合です。汎用的なフローが動くことは、その企業が実際にどう業務を行っているかを理解していることを意味しません。

したがって、対象シナリオに関わる社員の経験、プロセスのルール、暗黙知は、整理を経て、AIが使えるコンテキストへと変換する必要があります。

四、個人の効率化は、組織の効率化ではない

一人がAIを使ってタスクを早く終えても、仕事は依然として従来の引き継ぎ、レビュー、意思決定を経ます。業務全体が速くなるとは限りません。企業が全体の効率改善を求めるなら、プロセスの協働と評価の仕組みを見直す必要があります。

第一に、業務プロセスです。 既存の業務にAIを「足す」ことと、AIを中心にプロセスを再設計することは、まったく別のやり方です。前者は従来のプロセスと組織を残したまま、AIで部分的に効率を上げるだけです。しかしAIがあるなら、こう問い直すべきです。この業務は本当に従来どおりのやり方で回す必要があるのか。どの作業は直接完了できるのか。どの工程は統合できるのか。どの重複した情報伝達を減らせるのか。プロセスの中の待ち時間と繰り返し作業が減らなければ、個人が節約した時間が全体の効率には変わりません。

第二に、AI導入の進め方、役割分担です。 企業の知識整理と効果検証には、業務の専門家が直接関わる必要があります。しかし企業が業務を「要件を出す側」と位置づけたままなら、誰が専門知識を出すのかという責任の空白が生まれます。プロダクトと技術は要件を受け取っても、要件を満たすために不可欠なドメイン知識を受け取っていません。作った後も、業務の専門家が継続的に効果を判断する必要があります。

第三に、評価とインセンティブです。 AIを中心にプロセスを再設計したとき、業務担当者はなぜ従来の働き方を変えようとするのでしょうか。業務の専門家が時間を割いて経験を整理し、誤りを分析し、効果を検証しても、従来の業務タスクが減らず、その投入が評価にも反映されず、業務の成果も改善しないなら、物事を前に進めるのは難しくなります。突き詰めれば、結果に共同で責任を負う人がいないのです。

企業に戻って：すぐに着手できる3つのこと

企業のAIへの期待はすでに高まっています。しかしプロジェクトへの投資、業務の関与度、組織マネジメントはそれに追いついていません。デモが早く安定的な製品になることを望み、技術チームが価値の高いシナリオを手にすることを望み、AIが社員の長年の経験を身につけることを望む。しかし検証、知識整理、継続的改善に相応のリソースが割かれなければ、こうした期待は実現しにくいままです。

前述の4つの問題を踏まえると、すぐに着手できる点が3つあります。

第一に、デモの速度で導入サイクル全体を測らないこと。 デモが通った後も、実データの処理、例外への対応、本番環境の信頼性は継続的に検証する必要があります。経営層はこれらの作業に時間とリソースを確保し、段階的な成果に応じて投資を続けるか判断すべきです。早すぎる全面リリースを求めると、デモで露呈しなかった問題を業務に持ち込みやすくなります。

第二に、価値の高いシナリオを中心に小さなチームを組み、業務と技術が結果に共同で責任を負うこと。 業務の責任者は何に取り組む価値があるかの判断に関わり、業務の専門家は知識整理に関わります。社内リソースを使うにせよ外部チームを招くにせよ、業務は要件を出すときだけ現れる存在であってはなりません。

第三に、プロセス、責任、評価の変更が絡むときは、経営層が本当に参画して推進すること。 CEO、あるいは決定権を持つ業務責任者が先頭に立ち、部門の投入を調整し、評価の仕組みを変える必要があります。こうしたことが常に「追加の協力」でしかないなら、AIチームだけで推進し続けるのは困難です。

企業はシステム開発を専門チームに任せられます。しかし業務をどう変えるのか、人をどう投入するのか、責任をどう負うのかは、経営層が自ら決めなければなりません。多くの企業がAIの導入を難しいと感じる理由もここにあります。