MIT Technology Reviewの記事は、AIを「とりあえず導入する」だけでは大きな変革は起きない、とかなりはっきり言っています。
代わりに提案しているのが customer-back engineering という考え方です。
これはざっくり言うと、
「この機能で何ができるか？」から始めるのではなく、
「顧客は何に困っているか？」から始めて、必要な技術を逆算して作る
という発想です。
正直、言われてみれば当たり前にも見えます。
でも現実の大企業では、どうしても「持っている技術に何を載せるか」で考えがちです。この記事は、そのズレがデジタル投資の成果を目減りさせている、と指摘しています。McKinseyの調査を引きつつ、デジタル投資で期待した価値の3分の1も取り切れていない、という話が出てきます。ここはかなり耳が痛い話です。
この言葉は少し堅そうですが、中身はシンプルです。
つまり、技術起点ではなく顧客起点。
「何ができるAIか」より「何を解決するAIか」を先に決めるわけです。
この記事の中でCapital OneのAshish Agrawal氏は、エンジニアを顧客に近づけると “sideways innovation” が増えると言っています。
これは直訳すると少し変ですが、要するに既存の枠にない、横から入るような新しい改善が出やすくなる、という意味合いだと思います。
この感覚はかなり重要です。現場の人間が顧客の不満や行動を直接見ると、「そんな使われ方してたのか」「そこが詰まっていたのか」と、技術者ならではの解決策が出やすいんですよね。
この記事が面白いのは、単なる「顧客第一主義」のお説教で終わっていないところです。
AI、特に agentic AI の登場で、この逆算型の発想が現実的になってきたと説明しています。
簡単に言うと、ただ答えるだけでなく、目的に向かって複数の手順を自動で進めるAIです。
たとえば、
といった動きをします。
従来のAIは「1回質問したら1回答える」感じが強かったのに対し、agentic AI はもう少し**“仕事を手伝う”というより“仕事の一部を進める”**方向に寄っています。
ここがかなり大きいです。単なるチャットボットとは違って、業務フロー自体を変えられるからです。
記事ではCapital Oneの例がいくつか出てきます。
顧客対応の会話って、実際かなり長いです。
過去のやり取りを全部読んでから対応するのは面倒だし、ミスも起きやすい。
そこでAIが会話を瞬時に要約し、担当者に
を渡す。
これは地味ですが、かなり効きます。現場のストレスが減るし、顧客も待たされにくくなるはずです。
agentic AI は、やり取りの内容を読みながら「この点が足りない」と判断して、追加の質問を投げかけられるとしています。
人がスレッド全体を読み込む時間を減らせるので、業務の回転が速くなります。
さらに面白いのが、車の購入者と販売店向けの Chat Concierge という多段のAIフレームワークです。
これは複数の logical agents（論理的な役割を持つAI）が連携して動く仕組みで、たとえば
などを1つの会話の中でこなせます。
個人的には、ここがいちばん「AIが業務を変える」感じが伝わる部分でした。
単にFAQに答えるだけじゃなく、比較して、提案して、予約まで進める。これができると、ユーザー体験の質がかなり変わります。
記事の主張は一貫しています。
大事なのは、既存業務にAIをちょい足しすることではなく、AIを前提に業務や体験そのものを再設計することです。
これが「AI-first mindset」です。
つまり、
で満足せず、
そもそもその仕事の流れはAI時代にどうあるべきかを考える。
この視点は、かなり本質的だと思います。
AI導入がうまくいかない会社って、たいてい「今ある仕事をそのままAIで少し改善しよう」として終わるんですよね。もちろんそれでも価値はありますが、ブレークスルーにはなりにくい。
記事では、Agrawal氏の実践的な助言としていくつかのポイントが挙げられています。
「AIだからすごい」ではなく、
“顧客のどんな困りごとを解消するのか” を先に決めるべきだとしています。
これは当たり前に見えて、実は難しい。
AIはできることが多すぎるので、つい「何かできそう」に引っ張られやすいからです。
でも本当に価値が出るのは、意味のある問題を解くときです。
この記事では、data readiness と unified information across systems が非交渉の土台だと強調しています。
要するに、
ということです。
ここは派手さはないけれど、超重要です。
AIプロジェクトが失敗する理由って、最先端モデルが悪いというより、たいていデータ整備が足りないからです。地味ですが、現実はそういうものです。
AIを後付けするのではなく、最初からAIが組み込まれた業務設計にするべきだとしています。
このとき大事なのが、AIを black box（中身が見えない箱）として扱わないこと。
agentic systems は特に、誤作動や暴走を防ぐために厳密な管理が必要です。
だから responsible AI、つまり「安全性・公平性・説明責任を意識したAI運用」が欠かせない、という話になります。
私はここ、かなり現実的だと思いました。AIは便利ですが、業務に組み込むほど「ちゃんと制御できるか」が本質になります。
データサイエンス、engineering、product、design、その他の関係者が一緒に動くべきだと記事は言います。
これも重要です。
AIはもはや「技術チームだけの話」ではありません。
顧客体験を変えるなら、見た目、業務、データ、運用、ルールが全部絡むからです。
さらに、AI初心者の組織には crawl, walk, run、つまり
という段階的な進め方が勧められています。
いきなり全部をAI化しない、というのはかなり賢いです。
この記事を読んで強く感じるのは、AIの競争って「モデルの性能比べ」だけでは終わらない、ということです。
むしろ差がつくのは、
のほうではないかと思います。
つまり、AIの勝負は技術の勝負であると同時に、組織設計の勝負でもあるわけです。
ここがこの記事のいちばん面白いところです。
特に金融のような業界では、スピードと正確さ、そして信頼が全部必要です。
だからこそ、顧客起点で業務を作り直しつつ、AIでそれを実装するという発想はかなり相性がいい。
逆に言えば、見栄えのするAIデモだけでは何も変わらない、という厳しい現実も見えてきます。
MIT Technology Reviewの記事は、AI活用の本質を「技術導入」ではなく顧客体験の再設計に置いています。
そのためのキーワードが customer-back engineering です。
これは単なる流行語ではなく、
顧客の課題 → 必要な業務 → 必要なデータ → 必要なAI
の順で考える実践的なフレームだと言えます。
個人的には、こういう記事はかなり大事だと思います。
AIの話はどうしても「何ができるか」に寄りがちですが、本当に価値があるのは「誰のどんな面倒を消すのか」です。
そこを忘れない企業ほど、たぶんAIで強くなるのではないでしょうか。
参考: Fostering breakthrough AI innovation through customer-back engineering
