Vertical AI最後の1マイル問題―AI Agentを100社売ったら100回作業するのか？

AI Agentは100社ごと違う。各社「仕事のやり方」は同じではない。

AIが回答するだけなら、多少違っても人が直せる。
しかしAIが見積を書いて、配送を決めて、請求を進めるようになれば、各社の違いをどうするのか？
企業AIエージェントはココがちがう。
Vertical AIの企業を20社ほど調べていて、ここがずっと引っかかっていた。

僕自身は出版社でAIを担当している。AIを現場へ入れていくと、業界知識よりも、その会社、そのプロジェクト固有の判断や例外処理をAIにどう教えるかが問題になる。これは出版だけの問題なのか。他業界ではどうしているのか。そう思ってVertical AIを調べ始めた。

各企業でAI Agentを作るところまでは、かなり進みつつある。
しかし、それを100社に提供した場合、100社分（100回）判断、例外処理、承認条件を、誰がどうやってAIに教えるのだろうか？

100社には、100通りの「仕事のやり方」がある。
※これは100プロジェクトともいえる。
型にはめて、コピペする訳にはいかない。
Vertical AI最後の1マイル問題をひも解きたいと思う。

◆サクッと動画はこちら

１：AI見積は自動化されても本当に使えるか？

建設業向けクラウドを展開するCONOCは、SaaSからAI Agentへ軸足を移した。すでにAI見積を提供していて、積算、原価管理、工程管理など16以上のAI Agentを投入する計画を立てている。
彼らは目指す世界を「入力ゼロ、確認だけ」と表現している。

人がシステムへ入力するのではない。
AIが自走して仕事を進め、人間は必要なところだけを確認する。
多くのVertical SaaSは、AI対応でこの方向へ向かうだろう。

しかし、AIが標準的な見積を作れても、それだけでは仕事にならない。

このような個別条件は、建設業の一般常識ではない。
その会社が、仕事を通じて作ってきた個別判断の蓄積だ。
AIはまるっと建設業は知っていても、これらを知らなければ、使い物にならない。っていうかAIエージェントの意味がない。

２：Vertical AIには、２種類の知識がある

1️⃣一つは業界共通知識だ。
法律、専門用語、業界慣行、標準的な業務フロー。こ
れはVertical AI企業が共通機能として装備することで、複数の顧客へ展開できる。

2️⃣もう一つが顧客固有知だ。
何を優先するのか。どこまで担当者が決めてよいのか。何が例外なのか。何を絶対にしてはいけないのか。どの数字を信用するのか。問題が起きたら誰に確認するか。

・前者はコピーできる（スケールする：儲かる）
・後者は顧客ごとに違う（スケールしない：儲かりにくい）

人が判断し、SaaSへ結果を入力していた時代には、この差を人間が吸収していた。しかしAI Agentは、仕事を自分で判断して、次の処理へコマを進める。だから、手順だけでなく、その会社の「ものさし」を教えてやらねばならない。

このようなAI向けの「知識基盤」をどう準備すればいいか、各社は工夫をしている。

３：物流でも、個社開発は残る

物流のHacobuも「AI-Driven Logistics」を掲げている。
その一方、Hacobu Solution Studioでは、物流企業ごとのシステム連携、AI導入、個社開発まで手掛けている。公式サイトにも「個社の強みや業務知見を標準機能にアドオンする」とある。

同じ物流会社でも、距離、積載率、重要顧客、ドライバーの残業時間のどれを優先するかは違う。遅延から何分で顧客へ連絡するか、どこから上司判断へ切り替えるかも違う。

個社開発が残るのは、業界の標準と、顧客企業の違いが浮かび上がる場所だからだ。

Hacobu自身も、この「作る」と「現場で使われる」の隔たりをかなり正面から書いている。CTOの戸井田氏は4カ月で40回以上物流現場へ足を運び、紙の日報、配車担当者の判断、部門ごとに違う前提を拾っているという。
AIに任せようとすると、結局、人が普段何を見て、何で判断しているのかを言葉にし直す必要がある。

４：最後の1マイルで人間が必要になる

AIの話をしているのに妙だが、本番導入へ近づくほど人間の役割が大きくなる。僕はこれをAIパラドクスの一種と呼んでいる。

パランティアが有名にしたForward Deployed Engineer、「FDE」が必要になる。AI企業の技術者や専門家が顧客企業へ入り、現場を見て、業務を聞き、AIを実際の仕事へ接続する。

FDEは常駐エンジニアではない。
顧客企業へ深く入り、現場の業務を理解し、経営者視点を持ちながら、AIが実際に仕事をできるところまで設計・実装する役割だ。

Emergence Capitalは、FDEの仕事をDiscovery、Integration、Trustの三つに整理している。実際の仕事を再構築し、AIを業務システムへつなぎ、文書に書かれていないニュアンス（暗黙知）を現場から拾いあげる。彼らは、この繋ぎ込みを「last-mile work」（ラスト・マイル・ワーク）と呼んでいる。

会社にはマニュアルがある。
だが、そこに書かれているのは「仕事がどう行われることになっているか」であり、「実際にどう行われているか」ではない。
FDEが機能しているのは「その差」を埋める事であり、本質的な構造把握であり、実装である。単なる常駐エンジニアとは違う。

OpenAIの企業向けAI Agent基盤「Presence」も、ポリシー、権限、ガードレール、人間へのエスカレーション、エッジケース、評価、更新までを一体で扱う。しかも現時点ではセルフサービスではなく、FDEが企業と一緒に導入する。

世界最高水準のモデルを持つOpenAIですら、「Agentを渡したので、あとは御社でおまかせ」になっていない。最後は人間が企業へ入りこんで、仕事の実態とAIをつなぎ込んでいるのだ。

ここで興味深いのは、CONOCと建設業向けAI Agentを共同開発するJAPAN AIも、まさに同じ問題に向き合っていることだ。

JAPAN AIにはFDEチームがあり、顧客業務へ深く入りながらAI Agentを実装している。その一方で、自社noteでは「FDEにしかできないことを、なくしていく」と書いている。

つまり、FDEを増やし続けること自体を最終回答にはしていない。
FDEが顧客ごとに見つけた解き方を、再利用できるプロダクトへ戻していく。その先にスケールを作ろうとしている。

５：標準化したい。でも、顧客ごとの差は消えない

では、FDEを増やせば解決するのか？
顧客が10社なら、優秀な人を送り込めばできる。20社でもできるかもしれない。しかし100社、1000社になったらどうするのか。
この問題を考えていて、BPaaSにもよく似た構造があると思った。

kubell執行役員の角田剛史氏は、BPaaSについて面白いことをnoteに書いている。これまで各企業がバラバラに作ってきた経理、労務、採用などのバックオフィス業務を、BPaaSによって「社会全体の標準化」へ広げていくという考え方だ。これは、とてもよく分かる。

一社ごとにゼロから仕事のやり方を作っていたら、社会全体では同じような業務を何万回も作り直すことになる。
だから、できるだけ「型」にする。
ここまではVertical AIも同じだ。

ところが、角田氏は同じ記事の中で、kubellのBPaaSの強みについて、顧客が使うツールを限定せず、「あらゆるお客様の環境に合わせて柔軟にオペレーションを行える」ことだとも書いている。
ここが面白い。重要な部分だ。

標準化したい。でも、顧客ごとの差には対応しなければならない。

この二つを同時に成立させなければ、BPaaSもVertical AIもスケールしないからだ。

さらにkubellは、BPaaSのオペレーション効率を上げるためにAI Agentの開発を進めている。角田氏自身も、バックオフィスの実務を知らないエンジニアだけではAI Agentは作れず、ドメインエキスパートと一緒に業務フローそのものをAI前提で組み直す必要があると書いている。

ここから先が、僕が気になっているところだ。
人間が業務を回している間は、「この会社だけは違う」という例外を、人間が吸収できる。しかしAI Agentに仕事をさせると、その違いも明確に教えなければならない。

・この顧客だけ締め日が違う
・この場合だけ担当者へ確認する必要がある
・この金額を超えたら承認が必要
・この取引先だけ別ルール
・このデータを正として扱う

こうした違いは、標準業務ではない。
顧客固有の「仕事のやり方」なのだ。
だから問題は、標準化できる部分と、どうしても顧客ごとに残る部分を、どう分けるか。になる。

さらに、その顧客固有部分を、人間が毎回ゼロから聞いて、設定して、テストして、更新するしかないのだろうか？
ここがVertical AIの「100社問題」だ。
それでは、ソフトウェアはスケールしても、事業はスケールしない。

AI Agentが売れれば売れるほど、人員と原価も増えていけば、最後はSI企業に近づいていく。
Vertical AIの経営上の矛盾は、「共通化」と「個社適合」を、同時にスケールさせられるかにある。
この事を、経営者視点から書いてる新聞記事やnoteをまだ読んだ事がない。

６：モデルより、顧客の仕事を移植する力が競争になる

Stanford Digital Economy Labは、本番で成果を出している企業AIの51事例、41組織、7カ国を調査した。
そこで難所として浮かんだのは、モデルそのものより、業務プロセスの再設計、現場からの信頼、データ基盤、組織への実装だった。
42％の事例では、AIモデルは完全に交換可能だった。

モデルは安くなり、性能差も縮まる。
Agentを作る技術も一般化する。
そうなれば競争は、「誰が一番賢いモデルを使うか」から、「顧客の仕事を、どれだけ速く正確にAIへ移植できるか」へシフトするのは明快だ。

７：「Vertical AIの最後の1マイル」問題

ここでいう最後の1マイルとは、Vertical AI企業が、自社のAI Agentを顧客企業の「仕事のやり方」に適合させる最後の工程のことだ。

しかも必要なのは、判断基準だけではない。

AI Agentへ教えるのは、単なるナレッジではない。
会社が仕事をするための判断構造そのものだ。
会社は「知識基盤」／「判断OS」が必要になる。

その方向を先行して実装している例としてユビーがある。

最後の1マイルは導入支援の問題ではないのだ。
顧客が100倍になっても、粗利と品質を落とさない「顧客固有知識の生産方式」の問題になっていく。
個社にとっては１回で済むが、Vertical AI（バーティカルAI）にとってこれはとても大きな問題だ。

８：本当に、100社分を100回作るしかないのか？

ここが、一番気になっている。

顧客ごとの判断、例外、権限、人間へ戻す条件を、毎回ゼロから聞き、実装し、テストし、更新し続けるのか。それとも、業界共通部分と顧客固有部分を分け、AIと人間で再現可能な工程にできるのか。

さらに、その判断構造は誰の資産なのか？
Vertical AI企業の設定としてロックインするのか？
それとも顧客企業が持ち、別のAgentや別のベンダーにも渡せる状態にするのか？

まだ答えは出ていない。
ただ、世界ではすでに、会社固有の仕事のやり方をAIへ教えるための動きが始まっている。

必要になるのは、顧客ごとに設定を代行するだけの人の問題ではないのだ。
現場に埋もれた判断、暗黙知、例外処理、権限の付与、評価基準を採録して、AIが使える形へ変え、更新できる状態にする。

この仕事に派手さはない。
しかし、AIが実際の仕事をするようになるほど、この部分の重要性は増していくと思う。

そもそも、それは誰がマネジメントするのか？
僕はこの役割を「AIナレッジエンジニア」と呼んでいる。

時間があれば、後編として、100社分の仕事のやり方を100人で作り続けない方法があるのか、「企業の知識基盤」について世界の最新動向と照らしながら考えを書いてみたい。

◆スライドはこちら

参考情報

Emergence Capital｜FDE
OpenAI｜Introducing Presence
Stanford Digital Economy Lab｜Enterprise AI Playbook


#AIエージェント #VerticalAI #SaaS #AI導入 #経営戦略 #100社問題 #AIナレッジエンジニア

#AIエージェント #VerticalAI #SaaS #AI導入 #経営戦略 #100社問題 #AIナレッジエンジニア 　#仕事での気づき