生成AIの請求額が増え、社内アカウントも広がった。

それでも経営会議で「結局、何が良くなったのか」と問われると明確な答えを出せない企業は少なくありません。

‍

利用率が高いことは、社員がツールを開いた証拠にはなります。

しかし、顧客対応が速くなったのか、受注率が上がったのか、月次決算が早まったのか、ミスが減ったのかまでは示しません。

AI導入の数字が「使った量」に寄りすぎると予算消化と成果が切り離されます。

‍

Uberが2026年に明らかにした「Agentic Pods」はこの停滞を考える材料になります。

同社はAIに習熟したエンジニアを財務、法務、人事などの現場へ短期間配置し、担当者の仕事を観察しながらエージェントを構築したと説明しています。

報道によれば、30人のエンジニアを複数部門へ送り込み、2カ月で16のPodを実施。財務レポート作成を2日から10分へ、150都市への資本配分作業を15時間から30分へ短縮した事例も示されました。

‍

ただし、これらはUber側が公表した時間削減値です。

第三者が監査したROIではなく、品質維持、例外対応、開発人件費、モデル利用料まで含めた投資回収率も公開されていません。

したがって、成功談として模倣するより、「なぜ現場へ入り、業務フローから作り直したのか」を読み解く方が有益です。

‍

企業の生成AI導入はしばしばライセンス調達から始まります。

セキュリティ条件を確認し、対象社員へアカウントを配り、研修を行う。

ここまでは必要ですが、導入の入口にすぎません。

‍

失敗しやすいのはその後の評価指標が「月間利用者数」「利用回数」「生成文字数」「消化トークン」へ偏るケースです。

これらは普及状況の把握には役立つ一方、業務成果との因果関係を示せません。

メールの下書きを大量に生成しても、確認と修正に同じ時間がかかれば生産性は上がらないからです。

‍

DORAの2025年調査は、AIが組織の強みと弱みを増幅する存在だと整理しています。

基礎となる業務システムや開発プロセスが整った組織では効果が出やすく、承認待ち、データ分断、責任の曖昧さを抱える組織では局所的な速度向上が下流の混乱に吸収されます。

AIが一工程を速くしても、次工程が詰まれば全体のリードタイムは変わりません。

‍

さらに、利用者自身の感覚も過信できません。

METRが経験豊富なオープンソース開発者を対象に行った2025年のランダム化比較試験では、参加者はAIによって作業時間が短くなったと感じたものの、実測では対象条件において完了時間が19％増えました。

この研究は特定の開発環境に限られますが、「便利に感じること」と「全体として速くなること」は別だと分かります。

‍

全社導入で最初に変えるべきなのは、ツールの数ではなく測定単位です。

「社員がAIを使ったか」ではなく、「請求書処理が何分短縮されたか」「一次回答の正答率が何ポイント変わったか」「差し戻し率がどう動いたか」を追います。

対象は個人の活動量ではなく、顧客や社内の成果へつながる業務フローです。.

‍

UberのAgentic Podsが特徴的なのは中央のAIチームが部門から要件票を受け取るだけで終わらず、現場へ入った点です。

担当者の隣でどの画面を開き、どこから数字を集め、誰に確認し、例外時に何を判断するかを観察したとされています。

‍

業務マニュアルには標準手順が書かれます。

しかし、実際の仕事には「この顧客だけ別処理」「月末だけ手作業」「数字が合わないときは担当者へチャット」といった暗黙知があります。

エージェントが複数システムをまたいで作業するほど、この差が事故につながります。

図だけを見て自動化すると、正常系は動いても例外で止まるか、誤った処理をそのまま進めかねません。

‍

Agentic Podsの設計は、次の五段階に分けられます。

第一に現場観察、第二に候補の優先順位付け、第三に担当者との共同開発、第四に短期検証、第五に再利用と横展開です。

中小企業が30人のAIエンジニアを用意する必要はありません。

業務担当者、改善責任者、システム担当の3人を一時的な小チームにし、一つの業務へ集中させれば構造は再現できます。

‍

ここで注意したいのはUberの「99％のエンジニアがAIを利用」といった普及率と、Agentic Podsが生んだ個別成果を混同しないことです。

普及率は文化や接触頻度を示しますが投資回収を証明しません。

また、Claude Codeの年間予算を早期に使い切ったとの報道もあり、利用拡大には費用管理の難しさが伴います。

‍

Uberの事例から得られる結論は、「大量導入すれば成果が出る」ではありません。

費用が膨らんだ後に、業務の現場へ入り、成果が測れる単位へ投資を寄せ直した点に注目すべきです。

‍

‍

候補選びでは「頻度が高い」「時間がかかる」だけでは足りません。

処理量が多くても、判断が高度で例外が多い仕事は、初期PoCに向かない場合があります。

反対に、月1回しか発生しなくても、複数部署が数日かける締め作業なら効果は大きいでしょう。

‍

候補を比べる際は、六つの軸を使います。年間の作業時間、入力データの取得しやすさ、手順の安定度、例外の多さ、誤処理時の影響、成果を測れるかどうかです。

最初の案件には、データへ正規にアクセスでき、正解例があり、人が承認してから実行できる業務が適しています。

‍

現場観察では、担当者へ「何を自動化したいですか」と聞くだけで終えません。

実際の作業を一度見せてもらい、開始条件、参照先、判断分岐、完了条件、差し戻し理由を記録します。

さらに、過去10〜30件程度の実例を集め、正常系と例外系を分けます。

文書上の手順と実態が異なる部分は、AI以前に業務整理が必要なサインです。

‍

初期候補として扱いやすいのは複数資料から

定型レポートを作る

問い合わせを分類して回答案を用意する

契約書の確認項目を抽出する

会議記録からタスクを登録する

といった「入力と出力を定義しやすい仕事」です。

一方、法的判断、採用合否、信用供与、重大な価格決定などは、説明責任と人権影響が大きく、単純な自動化候補に置くべきではありません。

‍

経済産業省と総務省のAI事業者ガイドライン、NISTのAI RMFはいずれもAIリスクを技術だけでなく組織的に管理する考え方を示しています。

PoCの段階からデータの出所、アクセス権、ログ、責任者、人による確認、停止方法を設計しておくと、本番移行時の作り直しを減らせます。

‍

PoCを短期間に区切る目的は急いで完成させることではありません。

投資判断に必要な不確実性を早く減らすためです。

二週間という期間は万能ではありませんが対象業務を一つに絞り、既存データを使い、人の承認を残すなら続行か中止かを判断する材料を集められます。

‍

最初の二日で基準値を測ります。

現行作業の平均時間、処理件数、ミス率、差し戻し率、担当人数、待ち時間を記録してください。

三〜五日目に最小構成を作り、六〜十日目に実データの一部で試します。

最後の数日は、例外処理、権限、ログ、担当者の確認負荷を点検し、次の判断をまとめます。

‍

ROIの計算では、削減時間をそのまま利益とみなさないことが肝心です。

たとえば月100時間を減らしても、その時間が別の価値ある仕事へ振り替わらなければ、会計上の費用削減には直結しません。

まず「回避できた外注費」「残業削減」「処理能力の増加」「売上機会の増加」「損失やミスの回避」を分けます。

‍

総コストにはモデルやAPIの料金、SaaSライセンス、連携開発、業務担当者の検証時間、セキュリティ審査、監査、保守、再学習、障害対応を含めます。

式にすると、次のように整理できます。

‍

年間純効果 ＝ 年間便益 − 年間運用費 − 初期構築費の年換算額

‍

成果1件当たり総コスト ＝（モデル費＋システム費＋確認人件費＋保守・監査費＋失敗対応費）÷ 完了した有効成果数

‍

測るべき指標は時間だけではありません。

正答率、再作業率、重大エラー件数、人による確認時間、処理完了までの待ち時間も並べます。

AIが下書きを速くしても、確認工数が増え、差し戻しが多くなれば総コストは悪化します。

‍

PoC終了時は「成功」「失敗」の二択にせず、拡大、条件付き継続、再設計、中止の四段階で判定します。

拡大は品質と費用の両方が基準を満たした場合。条件付き継続は対象データや利用者を限定する場合。

再設計は権限や前工程に問題がある場合。中止は効果が小さい、リスクが高い、測定不能と判断した場合です。

中止できる仕組みがあるからこそ、PoCを投資判断として機能させられます。

‍

一つのPoCがうまくいっても、そのまま全社展開できるとは限りません。

部署ごとにデータ形式、承認者、用語、例外が違うためです。

横展開に必要なのは、完成したエージェントをコピーすることではなく、再利用できる部品と変更すべき部分を分離する設計です。

‍

共通化しやすいのは、社内認証、アクセス権、ログ保存、個人情報のマスキング、承認画面、プロンプトや手順の版管理、評価データ、停止スイッチです。

部門固有になるのは、参照データ、判断基準、用語、例外処理、成果の定義でしょう。

この切り分けができると、二件目以降の導入費を下げられます。

‍

運用責任も三層に分けると整理しやすくなります。

業務責任者は正しさと成果を持ち、システム責任者は可用性と権限を管理し、AIガバナンス担当はリスク基準と監査を担います。

「AIチームが全部責任を持つ」形では、現場の判断基準が抜け落ちます。

逆に現場へ丸投げすると、モデル変更や情報漏えいへの統制が効きません。

‍

中小企業では、全社プログラムより「一業務・一責任者・一指標」から始める方が現実的です。

月次レポート、見積もり前処理、問い合わせ分類など、効果を測りやすい業務を一つ選びます。

二週間で検証し、三カ月運用して季節変動や例外を確認し、その後に類似業務へ広げます。

‍

予算も「AIツール費」として一括管理するのではなく、探索、PoC、本番運用、共通基盤の四つに分けます。

探索費が膨らんで成果が出ないのか、本番運用の従量課金が想定を超えたのかが分かるため、削減すべき箇所を特定できます。

‍

全社導入とは、全員が同じAIを使う状態ではありません。

成果が確認された業務フローを、責任とコストを管理しながら複数部門へ展開できる状態です。

利用率はその一部にすぎず、経営が見るべき中心指標は品質を保った有効成果とその成果一件を生む総コストになります。

‍

生成AIの導入効果が見えない企業ではツールの性能より先に導入と測定の単位がずれていることがあります。

アカウント数や利用率を追うだけでは現場の待ち時間、差し戻し、品質、顧客価値まで届きません。

‍

UberのAgentic PodsはAIに詳しい人材を現場へ置き、実際の仕事を観察し、短期間で業務フローを作り直す手法を示しました。

一方で、公表値は企業側の自己申告であり、費用を含めたROIが確認されたわけではありません。

見るべきなのは華やかな時間短縮ではなく、観察、共同開発、測定、再利用という導入構造です。

‍

小さく始めるなら、一業務、一責任者、一成果指標に絞ります。

現状値を測り、二週間で不確実性を減らし、三カ月の運用で品質と総コストを確認する。

続ける条件と止める条件を先に決めておけば、AI予算は「使い切るもの」から「成果に応じて配分するもの」へ変わります。

‍