UKG の CIO が「AIエージェントを12,000超つくった」と語った Fortune の記事を読んだ。数を誇る話に見えるが、私が注目したのはその手前で何をやったかである。この記事では、全社にAIエージェントを展開する前に基幹システムとデータ基盤で何を片づけているのか、そして開発を生業にしている会社がこの事例から何を仕込むべきかを、受託開発とAIエージェント事業をやっている立場から整理する。
出典記事の要点
- UKG の CIO は Prakash "PK" Kota 氏。2025年4月に Autodesk から着任した。
- 着任から6か月で ERP を Microsoft に、CRM を Salesforce に集約し、複数のデータウェアハウスを統合した。最初の90日ではレガシーの Kronos 側と Ultimate Software 側にまたがっていた技術部門を中央に寄せている。
- 従業員14,000人規模に対し、社内AIアプリを387、Microsoft / Google Gemini / OpenAI ChatGPT にまたがるAIエージェントを12,000超つくったとしている。
- カスタマーサービスへの入電の27%を自律的に処理し、月あたり8,500時間の生産性効果を測定していると述べている。
- 新たに解決した顧客課題から約300件のケーススタディが継続的に生成され、300のシグナルを見るプロペンシティモデルがアップセル機会を特定しているという。
- Kota 氏は「AI時代には誰もが働き方の再設計を語っている。従業員と労働者はどう共存するのか。HR techは巨大な投資領域になる」と語っている。
順番が本体である
この事例で再現性があるのは、エージェントの数ではなく順番だ。ERPとCRMを一本に寄せ、データウェアハウスを統合し、そのうえで全社にAIを配った。逆順ではない。
エージェントは結局のところ、読める状態のデータと、叩ける状態のAPIの上でしか動かない。基幹が二重化していて、マスタの定義が事業部ごとに違い、DWHが3つあるまま「エージェントを入れましょう」と言えば、作るのはエージェントではなく、システム間の差異を吸収するためのその場しのぎの接着剤である。接着剤は動く。しかし壊れる。そして誰も直せない。私が受託の現場で何度も見てきたのは、この接着剤が数年後に技術負債として請求書になって戻ってくる光景だ。UKGは合併に由来する二重構造を先に潰した。ここが一番地味で、一番効いている。
12,000という数字をどう読むか
「12,000エージェント」を額面通りに受け取るべきではない。従業員14,000人でエージェント12,000超なら、一人あたりほぼ1個。これは中央の開発チームが企画・設計・運用しているプロダクションのエージェント群ではなく、業務担当者が自分の手元でつくった小さな自動化の総数と読むのが自然だ。実際、Microsoft / Gemini / ChatGPT の3系統にまたがっていると明記されている。ガバナンスの効いた統一基盤に載っている数ではない。
だから評価すべき指標は数ではなく、記事中にある「入電の27%」と「月8,500時間」のほうだ。業務のアウトカムに接続された数字が出ていることが、この事例の質を担保している。作る側の実感として、社内AI施策で一番難しいのは作ることではなく、効果を業務KPIに接続して測り続けることである。ツール数はダッシュボードにすぐ出るが、業務効果は誰かが定義しないと永久に出てこない。数を追う社内施策は、たいてい測定を後回しにしたまま終わる。
自社で同じものを作るとしたら、どこが難所か
私たちがこの構成を顧客に納めることを考えると、難所は明確に3つある。
第一に、基幹統合そのもの。ERP/CRMの集約は、技術課題である以上に、どの部門の業務定義を捨てるかという意思決定の課題だ。6か月で片づいたという記述の裏には、相当量の「やらないことを決める」作業があったはずである。ここを外部ベンダーだけで進めることはできない。
第二に、モデルではなくコストと運用。3系統のモデルにまたがる12,000のエージェントは、トークン予算・レイテンシ・障害時の切り分け・モデル更新時の回帰、すべてが分散する。誰がどのエージェントのオーナーなのかが曖昧なまま増えると、半年後には「動いているが誰も責任を持てないもの」の山になる。私はテクノロジー選定でコストと長期運用を優先する立場をとってきたが、この構成はまさにそこが勝負どころだ。
第三に、人材設計。業務担当者が自分でエージェントをつくれる状態は、教育と権限設計の結果であって、ツールを配れば生まれるものではない。全社展開の実務の大半は、技術ではなくこちら側にある。
開発会社の事業判断にどう効くか
同業の経営・事業責任者の立場で読むと、この記事は受注機会の輪郭を示している。顧客が「AIエージェントを入れたい」と言ってきたとき、そのまま作ると接着剤の仕事になり、単価は上がらず、保守で消耗する。一方で「エージェントを入れる前に、基幹とデータをこの順で整える」という提案ができれば、案件は基幹統合・データ基盤の再設計という上流に移る。UKGがやったのは、まさにその上流である。
内製と外注の切り分けも同じ線で引ける。業務担当者がつくる小さなエージェントは内製に寄せるほうが速い。統合と基盤と、権限・コスト・監視のガバナンスは外部の設計力が効く。この2階建てを最初に顧客と合意しておくことが、後から「あのエージェントは誰が直すのか」という問いで揉めないための唯一の方法だと私は考えている。
エージェントの数を提案書に書くのはやめたほうがいい。書くべきなのは、どの業務のどの指標を、いつまでに、どれだけ動かすかである。UKGが27%と8,500時間を出してきたのは、そこを先に決めていたからだ。
