インドのFMCG大手 Dabur India の Global CIO が、同社のAI変革について語った記事を読んだ。DaburGPT という社内生成AI基盤、Project Genesis という業務AIプログラム、GCC (Global Capability Centre) 戦略という3層構成の話だが、私が引っかかったのは技術の中身ではなく、「AIを技術プロジェクトとして扱わない」という運用設計のほうだ。この記事では、その設計を受託開発・AIエージェント事業をやっている側から評価し、SIer・開発会社にとって何が変わるのかを書く。
要点 (出典の事実のみ)
- Global CIO の Manas Mehra 氏は「AIを技術プロジェクトとして見てはいけない。それでは失敗する」と述べ、Dabur はAIを事業変革として位置づけたとしている。
- 社内生成AI基盤 DaburGPT は「代替」ではなく「イネーブルメントツールであり、デジタルな同僚」として意図的に位置づけられた。財務分析・コンテンツ制作・マーケ素材・調達業務などに使われ、社内環境に情報をとどめる。将来的には役割に応じてAI機能を選べる社内版「Dabur Play Store」構想がある。
- 業務AIの旗艦プログラムが Project Genesis。商談投資計画、売上分解、需要予測、デマンドパルスなどのパイロットを進めている。
- ガバナンスとして「技術KPIは置かない。狙うのは事業KPIである」としている。Mehra 氏はこの移行を「テストマッチ型からT20型へ」とクリケットに喩えた。
- 営業向けの「AIによる推奨必達ライン」では、50メートルしか離れていない個店ごとに別々の商品を推奨できる。推奨9品を15品に増やせるか、10〜20%の押し上げが出るかを見ており、業界水準のAI押し上げ幅として15〜25%を挙げている。
- GCC は現在IT・デジタルマーケの2機能が稼働。SAP Ariba (調達)、SAP SuccessFactors (人事) をグローバル展開し、将来の財務・人事・調達・製造・サプライチェーンGCCの土台とする位置づけ。
- Mehra 氏はAI採用の決定要因を変革管理 (change management) だとし、「技術が失敗するのではない。変革を適切にやれないから失敗する」と述べている。
「技術KPIを置かない」は正しい。ただし前提条件がある
私はこの方針に基本的に賛成する。受託の現場で見てきたAI案件の失敗のかなりの割合は、精度やレイテンシではなく「誰の業務がどう変わるかが決まっていない」ことに起因していた。技術KPIだけを置くと、モデル評価が良好なまま業務に乗らない、という状態で終わる。
ただし「技術KPIを置かない」を額面通りにやると危険な領域がある。推論コスト、レイテンシ、データ鮮度、失敗時のフォールバックは、事業KPIには直接現れないのに、事業KPIを後から破壊する種類の指標だ。個店ごとに推奨を出し分ける仕組みは、需要予測の更新頻度が落ちた瞬間に「当たらない推奨」を営業に出し続ける機械になる。事業KPIを唯一の物差しにするのは経営の号令としては正しいが、運用の物差しは別に持っておかないと、劣化に気づくのが数ヶ月遅れる。研究出身の癖で言えば、評価指標と再現条件を捨ててはいけない。捨てるべきは「技術KPIを成果として報告すること」であって、計測そのものではない。
順番として学べるのは「社内GPTを入口にした」こと
DaburGPT を先に置き、その後に業務AI (Project Genesis) へ進んでいる順番は、模倣する価値がある。私が相談を受ける会社の多くは逆順で、いきなり基幹業務のAI化から入って、現場が出力を信用せず止まる。
この順番の本質は「AIに慣れさせる」ことより、組織のAIリテラシーの分布を可視化することにあると私は見ている。全社に生成AIを開放すると、どの部署が使い倒し、どの部署が触りもしないかが数週間で分かる。その分布は、次に業務AIをどこから入れるかの一次情報になる。使わない部署に自動化を入れても運用されない。DaburGPT を「デジタルな同僚」と表現したのは対外的な言い回しだが、実務的には低リスクな観測装置として機能している。
開発会社の事業判断としてどう効くか
ここが本題だ。この形が広がると、開発会社側の受注の形が変わる。
第一に、「AIシステムを作って納める」という単位の案件が痩せる。事業KPIで測られるということは、納品時点では成否が判定されないということだ。発注側が求めるのは「動くもの」ではなく「3ヶ月後に営業の推奨採用率が上がっている状態」になる。一括請負で切りやすい仕事ではない。パイロットから本番運用まで伴走し、業務側の指標を一緒に見る体制を持てるかどうかが、受注の分かれ目になる。
第二に、社内AI基盤 (DaburGPT に相当するもの) は内製かSaaSに寄り、外部開発会社の取り分は薄い。一方で Project Genesis 側 — 需要予測、売上分解、個店ごとの推奨といったその会社固有のデータと業務ロジックに張り付いた領域は、外に出しづらく、ドメイン理解が要るため、外部が入る余地が残る。AI関連の営業をかけるなら、社内チャット基盤の構築ではなく、こちらの層を狙うほうが単価も継続性も高いというのが私の判断だ。
第三に、「変革管理が決定要因」というCIOの発言を、開発会社が自分の仕事の範囲外だと思わないほうがいい。現場が使わないAIは、開発会社の実績にもならない。要件定義の段階で「誰がこの出力を見て、何を判断し、使わなかった場合どう検知するか」まで詰められるチームは、まだ多くない。ここは単価を上げられる差別化点として素直に有望だと考えている。
15〜25%という数字の扱い方
記事にある「業界水準のAI押し上げ幅 15〜25%」は、CIO本人が業界水準として挙げた数字であり、Dabur の実測値として報じられているものではない。この種の数字は提案資料で一人歩きしやすい。使うなら出典と前提 (どの業務の、何に対する押し上げか) をセットで示すべきで、自社案件の期待値としてそのまま置くのは避けたほうがいい。ROIの定量化が難しいという点は、Mehra 氏自身も認めている。
出典: How Dabur is leveraging intelligence for business transformation
