AIを置く仕事はどう選ぶか。Impelが候補を6つの原因へ束ねた手順

社内でAIエージェントを増やそうとすると、最初に行き詰まるのは技術ではありません。候補が多すぎることです。議事録の要約、問い合わせの一次返信、レポートの下書き、競合の調査。どれも作れそうに見えて、どれから置くべきかは決まりません。結果として、作りやすいものから並べ、使われないものが残ります。

自動車ディーラー向けにAIを提供しているImpelの導入事例には、その決め方が手順として書かれています。候補を100件近く集め、40件未満へ削り、個別の案件ではなく「原因」の側で6つに束ね直してから、影響度と構築の難易度で採点する。振り分けの箱は fund-now、back-half、next-year の3つです。そして最初に資金が付いたのは、コンテンツ生成でも問い合わせ対応でもなく、営業担当の研修でした。

この記事で扱えるのは、Anthropicが公開している導入事例ページと、Impelの公式サイトに書かれている範囲だけです。数値は原文の表記のまま記載し、通貨や単位の換算はしていません。費用、売上への影響、うまくいかなかった取り組みについては、どの資料にも記載がありませんでした。確認日は2026年10月9日です。

Impelは何をしている会社か

導入事例の冒頭には、Impelは自動車のディーラーとOEM向けに業種特化型のAIを作っており、その中にはディーラーにかかってくる電話を受け持つ digital voice assistants も含まれる、と書かれています。公式サイトの Platform ページには、提供しているAIが Sales AI、Service AI、Chat AI、Voice AI、Marketing AI、Merchandising AI の6つとして並んでいます。販売、サービス入庫、チャット、電話、顧客への継続的な接触、在庫車両の掲載ページ。ディーラーの店頭業務が、そのまま製品の区分になっている構成です。

規模についても、記事に関わる範囲だけが公表されています。顧客に接する担当者は 150-plus で、従業員は nearly 500。社内で使っている Claude Enterprise は 400-plus seats です。日本の感覚で近いのは、自動車販売店へSaaSを売り、導入後の運用まで面倒を見ている会社です。売る相手が店舗であり、売る対象が業務の仕組みそのものである、という点が後の話につながります。

付け加えると、この会社は自社の製品としてもAIを売っています。つまり社内でAIを使う話と、顧客へAIを売る話が同じ会社の中にあります。事例に引かれているCMOのRob Murphy氏の言葉も、社内でやったことと顧客に対してやってきたことが同じ効果を持った、という趣旨になっています。

詰まっていたのは、作る側ではなく売る側だった

出発点になった問題が、やや意外です。Impelのプロダクトチームは Claude Code を使って開発の速度を上げ、事例の言葉では「10x engineers」になりました。ところがそこで新しい詰まりが生まれます。機能が出てくる速さに、150-plus の顧客担当が学ぶ速さが追いつかなくなったのです。

従来の手当ては、説明資料とFAQでした。それが足りない理由を、オペレーション担当のSVPであるBritt DeJohn氏はこう述べています。「People only really learn when they go and do the thing.」人は実際にやってみて初めて学ぶ、という意味です。

ではなぜ練習できないのか。事例には2つの理由が挙げられています。1つは、少人数で行うロールプレイが本物の会話に感じられないこと。もう1つは、実在のディーラーを相手に練習すれば、関係そのものを損ねる危険があることです。相手の中には20年以上その業界にいる担当者もいます。慣れていない担当者が当たって失敗すれば、取り返しがつきません。

その結果として起きていたのが、ソリューションエンジニアと営業の責任者が、担当者がまだ運べない会話へ呼び出され続けるという状態でした。人が足りないのではなく、任せられる状態になるまでの時間が長すぎたわけです。新しい製品ごとに、担当者が立ち上がるまで3〜6か月かかっていたと書かれています。

候補を100件近く集めて、40件未満へ削った

ここからが選び方の話です。事例によると、経営層はまず社内のエージェント候補を 100件近く集めました。そのうえで、リストを40件未満まで削っています。削るときの問いが書かれており、DeJohn氏は「私たちはこう問い始めた。いちばん大きな業務上の問題は何か」という言い方をしています。

重要なのはその次です。残った候補を、やりたいことの一覧としてではなく、原因のまとまりとして束ね直しています。束ねた先は6つのクラスタです。名称が本文で挙がっているのは revenue leak & retention risk（収益の漏れと解約リスク）と talent performance & ramp speed（人材の成果と立ち上がりの速さ）の2つで、残り4つの名称は確認できた記載の中にありませんでした。

採点は、個別の候補ではなくクラスタに対して行われています。軸は影響度と構築の難易度の2つで、結果は fund-now、back-half、next-year というラベルの箱に入ります。今期に金を出すもの、後半に回すもの、来年のもの。この3つに分けたうえで、ポートフォリオは毎月、新しく出てきた業務上の問題に対して採点をやり直すとされています。

この手順の効き目は、順序にあります。候補を並べて点を付けると、票は「作りやすいもの」と「見栄えのするもの」に集まります。原因の側で束ねてから採点すると、同じ原因に当たる候補が1つのかたまりになり、その原因を放置した場合の損失と比べることになります。社内でAIを広げるときに普及率を先に測る進め方はZapierの全社導入でも扱いましたが、Impelの事例は「どこへ置くか」を決める側の手順として読めます。

最初に資金が付いたのは「研修」だった

fund-now の上位に入ったのが研修でした。事例はその理由を、1つの問いの形で示しています。「ベテランの担当者が長年の経験で身につけた、その場の判断を、どうやってかたちにするのか」。立ち上がりの遅さは人材のクラスタに属し、しかも放置すれば製品を出すたびに同じ損失が出ます。

作られたのは、ディーラー役を演じるロールプレイのエージェントです。読ませたのは、通話記録ツールのGongに残っていたディーラーとの通話と、Salesforceの全データでした。通話の量は事例の表記で「more than 150 thousand」とされています。この規模について、Chief of StaffのBenjy Kest氏は、20 humans のチームでも2か月で読み切れる量ではない、という言い方をしています。

動き方も具体的に書かれています。音声認識と音声合成を使うため、やり取りは声で行われます。エージェントは最初から役に入っており、フロアミーティングまで30分しかないと前置きして自分の名前を告げるところから始まります。会話の中では、実際のディーラーが出すような反論や懸念をぶつけてきます。

終わったあとの採点は4つの軸です。objection handling（反論への対応）、rapport（関係づくり）、product knowledge（製品知識）、next steps（次の約束）。結果はスコアカードとして Slack のDMで届きます。練習した本人がその場で受け取れる形になっています。

ここでいちばん実務的なのは、かかった時間の内訳です。エージェント自体の構築は約3週間でした。一方で、どんな場面を練習させるか、どう採点するかを関係者で合意するまでに1〜2か月かかっています。作る時間より、決める時間のほうが長い。この比率は、自社で同じことをやる場合の見積もりにそのまま効いてきます。道具の調達計画だけを立てて、合意の期間を入れ忘れると、予定は必ず遅れます。

公表されている結果と、その読み方

公表されている数値を並べます。新製品についての立ち上がり期間は、以前の3〜6か月から平均1か月になったとされています。新製品を出した最初の2か月のエスカレーションは、最大で20%減りました。そして、go-to-market の組織のうち約25%が、直近1か月のあいだに自分の時間で練習のためにログインしていた、とされています。この点について事例は、義務づけたものではなく、本人たちが価値を見たからだという説明を添えています。

研修以外でも数値が出ています。サポートの担当者は、案件の振り分けと解決メモの下書きをエージェントに渡した結果、20%多い件数を扱えるようになりました。アカウント担当が作るディーラー向けの月次レビューは、1件あたり約30分で作れるようになり、準備時間は85%減ったとされています。以前は3〜4時間かかっていた作業です。下書きはSnowflakeのデータからそのまま起こされます。この仕組みで、1週間に close to 1,000 reviews を届けた週があり、社内記録になったと書かれています。

読み方には注意が要ります。これらは第三者の検証を経た数値ではありません。立ち上がり期間が短くなった背景には、エージェント以外の要因、たとえば製品の説明資料が整ったこと、担当者の構成が変わったこと、比較対象の製品が違うことなども含まれ得ます。約25%という比率についても、母数となる人数と、何回のログインを「練習した」と数えたのかは書かれていません。同じ仕組みを入れれば同じ比率になる、という因果を示すものではないと読むのが正確です。

型が決まった仕事は、軽いモデルへ降ろす

もう1つ、運用の設計として書かれているのがモデルの使い分けです。3段に分かれています。

複雑で手数の多い仕事には Opus を置いています。複数のシステムをまたぐ多段の作業、新しいエージェントそのものの設計、整っていない文脈をたどる作業です。Kest氏は Opus 4.5 が転機だったと述べ、MCPをまたぐ多段の仕事を渡しても、すべての手順を固く書かずに最後まで通せると感じた、という言い方をしています。

Fable は、推論の強さが効く場所に置かれています。エンジニアリング用途の70〜80%はコード生成で、業務手順の文書化やマッピングにも使われています。同氏はこのモデルを「ほかのモデルよりずっと意見を持っている。良い意味で」と評し、中立な道を選ばずに自分が最善と考える方へ踏み込むと述べています。実例として、Salesforceのオブジェクト、フィールド、リレーションをすべて対応表に落とし、再利用できる skill にしたことが挙げられています。

そして、工程が固まったあとは Sonnet を executor agents として置きます。Fable が作った対応表を参照して、決まった作業を回す役です。

モデルを1つに決めない設計そのものは、AtlassianのClaudeとGeminiの使い分けでも扱いました。今回の事例で違うのは、分ける軸です。Atlassianは仕事の複雑さで振り分けていましたが、Impelが語っているのは工程の成熟度です。道筋が決まっていないあいだは重いモデルで通し、決まった時点で軽いモデルへ降ろす。同じ仕事をずっと高いところに置き続けない、という運用になっています。エージェントそのものの仕組みを先に整理したい場合はAIエージェントをマーケティングに活用する方法もあわせてお読みください。

日本の実務者が参考にできる点

第一に、候補の選び方です。数を集めること自体は難しくありません。効いているのは、集めたあとに原因の側で束ねてから採点していることです。社内で候補を出すと、たいてい「部署ごとの要望リスト」になります。それを業務上の問題のまとまりへ組み替えると、同じ問題に当たる候補が1つのかたまりになり、放置した場合の損失と並べて比べられます。要望の数が多い部署が勝つ、という決まり方を避けられます。

第二に、置く場所の見つけ方です。この事例で最初に資金が付いたのは研修でした。出力物を作る工程ではありません。社内の作業を並べたとき、正解が人の頭の中にあり、件数が多く、しかも誰かが待たされている工程があれば、そこが候補になります。店頭の点検作業を写真の照合へ置き換えたAdvantage Solutionsの事例も、形は違いますが「待たされている定型作業」を選んでいる点では同じです。

第三に、見積もりの作り方です。構築が約3週間、合意が1〜2か月という内訳は、そのまま持ち帰る価値があります。研修に限らず、採点基準や判断の線引きを決める作業は、道具の準備より時間がかかります。計画の中に「合意」を独立した工程として置いておくと、着手してから止まりません。

第四に、置いたあとの降ろし方です。工程が固まったら軽いモデルへ移す、という前提を最初から持っておくと、費用の見通しが立ちます。逆に、最初に選んだモデルのまま運用を続ける設計にすると、件数が増えた分だけ費用が伸びます。どこで降ろすかを決める条件を、導入の設計に入れておくほうが安全です。

確認できなかったこと

記載が見当たらなかった項目を残します。まず、6つのクラスタのうち4つの名称です。公表されているのは2つだけでした。どんな原因で業務を分類したのかの全体像は分かりません。

次に、費用です。seat の数は公表されていますが、金額、構築にかけた人件費、社内の推進体制の規模は書かれていません。したがって、投資に対する効果を自分の数字で組み立てることはできません。

三つ目に、事業の結果です。立ち上がり期間やエスカレーションの件数は出ていますが、受注、解約率、売上に対する影響は公表されていません。研修が速くなったことと、売れるようになったことは、この資料では結びついていません。

四つ目に、うまくいかなかった取り組みです。40件未満に絞った候補のうち、作ったが使われなかったものがあるかどうかは書かれていません。失敗の記述が無い資料は、それ自体が偏りを含んでいると考えて読む必要があります。

最後に、自社製品との切り分けです。Impelは業種特化のモデルも自社で持っており、社内の仕事がどちらにどう振られているのかは、確認できた範囲では書かれていませんでした。

全体を1行でまとめると、この事例の価値は結果の数字ではなく、候補を原因で束ねてから採点するという選び方そのものにあります。どの仕事にAIを置くかで止まっているなら、候補を増やす前に、束ねる軸を作るところから始めるのが近道です。