AIエージェント効果測定、SAP実測92.92%と10万件自動化の中身

「AIエージェントを導入しました」という発表は、もう珍しくありません。僕が本当に知りたいのは、その先です。導入して、実際に何%効率が上がったのか。何件の作業が、人の手を離れたのか。

2026年6月から7月にかけて、SAPとDatabricksが相次いで具体的な実測値を公開しました。SAP Business AIのQ2 2026リリースハイライトには、Bosch DigitalやLC Waikikiといった実在企業の効果測定値が並んでいます。デンマークの卸売企業Lemvigh-Müllerの事例では、年間10万件超の注文確認処理がAIエージェントに移りました。その内訳まで、公開されています。Databricksは自社のGenie Oneについて、ベンチマークテストの正答率を発表しました。比較対象は、汎用コーディングエージェントです。

今回は、この3つの実測データを僕なりに整理し、「AIエージェントがチャットの実験段階から、業務処理の実装段階に移った」と言える理由を数字で確認します。そのうえで、この数字を自社の導入判断にどう使うか、3つの視点に落とし込みます。

先に断っておくと、僕自身はSAPやDatabricksのような大規模基幹システムを直接運用したことはありません。ひとりマーケターとしてClaude CodeやMCPサーバーを触っている立場から見ています。この記事で紹介する数字は、「自分より一段大きい現場で、何が起きているか」を知るための材料です。だからこそ、数字を鵜呑みにしません。出典に当たって、裏側の前提条件まで確認したうえで紹介します。

AIエージェントが「チャットの実験」から抜け出した、2026年Q2の変化

これまでのAIエージェント関連の発表は、「こんなことができるようになりました」というデモが中心でした。実際に使ってみると、チャット画面で質問に答えてもらう用途がほとんどです。業務プロセスそのものを置き換えるところまでは至っていない、という印象を持っていた方も多いと思います。以前、SAP 200超エージェント、基幹システムがAI化する前に知る3つのことという記事を書きました。あのときの僕は、導入企業数の多さに注目していました。何社が導入したか、という「量」の話です。

ですが今回のSAP Business AI Q2 2026リリースハイライトは違います。個社ごとに「何%変わったか」という「質」の数字が並んでいます。しかも対象は、開発現場・経理業務・人事業務・受発注業務と、企業のバックオフィス全般に広がっています。チャットで質問に答えるだけの存在から、実際の業務フローの中に組み込まれて処理を代行する存在へ。AIエージェントの立ち位置が変わったことが、この実測値の広がりからわかります。

同じタイミングで、Databricksも自社のエージェント型AI「Genie One」を一般提供（GA）しました。こちらは企業データに関する質問への回答精度をベンチマークで示しています。つまり、SAPとDatabricksという異なる領域のベンダーが、同じ時期に「実測値で語る」フェーズに入ったということです。これは偶然ではなく、AIエージェントの評価軸が「できるかどうか」から「どれだけ効いたか」へ移った証拠だと僕は見ています。

ここで気になるのが、「なぜ今、実測値が揃って出てきたのか」という点です。僕なりの見立てはこうです。AIエージェントを試験導入した企業の多くは、2025年のうちに1〜2個の業務で先行導入を終えています。その先行組が2026年に入って半年〜1年分の運用データを蓄積し、ちょうど「効果を数字で語れる段階」に到達した。ベンダー側から見ても、デモや機能一覧だけでは差別化しづらくなったタイミングで、顧客の実測値という「他社が簡単には出せない証拠」を出せるようになった。導入企業とベンダーの双方にとって、実測値を公開する動機が揃った時期が、たまたま2026年のQ2だったというのが僕の理解です。

僕がAIエージェント関連の記事を書き始めた2026年前半を振り返ると、当時の話題の中心は「エージェントに何ができるか」という機能紹介がほとんどでした。複数のツールを連携させて自律的にタスクをこなすデモ動画がSNSで拡散され、導入企業数の発表が相次いだ時期です。それ自体は重要な進展でしたが、読者から見ると「結局、自社に導入したら何が変わるのか」という肝心な部分が見えづらい状態が続いていました。今回のように、企業名・部門名・改善率がセットで公開される事例が増えてきました。ようやく「導入した場合の期待値」を具体的にイメージできる材料が揃ってきたと感じています。

SAP Business AI Q2 2026の4つの実測値が示す、業務ごとの効き方の違い

まず、SAP Business AI Q2 2026のリリースハイライトに掲載された、個別企業の実測値を確認します。出典はSAP News Centerの公式記事「SAP Business AI: Release Highlights Q2 2026」（2026年7月）です。

1つ目は、ドイツの自動車部品大手ボッシュのIT部門であるBosch Digitalの事例です。開発チームが「Joule for Developers」をコーディング作業に組み込みました。定型的なコーディング作業の自動化とコード最適化によって、開発生産性が20%向上したと報告されています。さらにJouleはテストケースの自動生成も行っています。ユニットテストの実行速度を15〜20%高速化させ、シニア開発者がより難易度の高い業務に集中できる時間を生み出しました。

2つ目は、業務プロセスの稼働時間に関する数字です。「Joule Work」を導入した企業では、稼働時間が92%から92.92%に改善しました。わずか0.92ポイントの変化に見えるかもしれませんが、これは生産プロセスのエラーや接続エラーの分析にかかる時間を20%削減した結果です。具体的には、エラー対応にかかる時間が4.5時間から3.6時間に短縮されています。稼働率が既に92%まで最適化されている状態から、さらに1ポイント近く積み増すのがどれだけ難しいか。この領域で仕事をしたことがある方なら、この数字の重みが伝わると思います。実は、稼働率のような指標は「100%に近づくほど、残り1%を削るコストが跳ね上がる」という性質を持っています。92%から93%への1ポイントは、50%から51%への1ポイントとは、まったく違う難易度なんです。

3つ目は、経費精算業務です。SAPの「Expense Automation Agent」は、従業員が出張費などの経費を申請する際に、取引データを自動収集してドラフトレポートを作成します。手入力の手間を減らし、レポート作成にかかる時間を最大30%削減しました。経費精算は多くの企業で「誰もが嫌がるが、誰かがやらなければならない」業務の代表格です。従業員自身が申請書を作る手間と、経理担当者がそれを確認する手間の両方に負荷がかかる構造になっているため、削減効果が従業員体験にも直結しやすい領域だと言えます。

4つ目は、トルコのファッション小売大手LC Waikikiの事例です。「Joule」をベースにしたAIエージェントが、休暇申請や給与に関する問い合わせといったHR業務を自然言語での対話で処理しています。その結果、HRプロセスのサイクルタイムを40〜60%削減しました。従業員数の多い小売業では、HR担当者1人あたりが対応する問い合わせ件数が膨大になりがちです。自然言語での対話が、そのままHRシステムへの申請につながる設計になっています。従業員側は「聞けばすぐ終わる」という体験を得られ、HR担当者側は定型的な問い合わせ対応から解放される。双方にメリットがある設計だからこそ、40〜60%という大きな削減幅が出ているのだと思います。

ここで気になるのが、「この数字はどこまで信用できるのか」という点です。ベンダー自身が公開する事例である以上、うまくいった案件だけを選んで紹介している可能性は当然あります。実際、SAP News Centerの発表はSAP自身によるプレスリリースであり、第三者機関による監査を経た数字ではありません。この点は、読者として割り引いて受け止める必要があります。それでも、企業名・部門名・具体的な業務内容まで明記したうえで数字を公表している点は、匿名の「導入企業の声」よりは検証可能性が高いと僕は判断しています。

この4つの事例を並べて気づくのは、「効いている業務」と「効いている度合い」が、業務の性質によって大きく違うという点です。開発やHRのように「判断の余地はあるが、パターン化しやすい」業務では、40%を超える改善が出ています。一方、既に高度に最適化されていた稼働率のような指標では、1ポイント未満の改善でも大きな価値を持ちます。導入効果を「何%改善したか」という単一の数字だけで比較するのは危険です。その業務がもともとどれだけ非効率だったかを踏まえて読む必要があります。

Lemvigh-Müllerの10万件事例、その裏側にある175,000件という前提

次に、SAPが2026年6月に公開したデンマークの卸売企業Lemvigh-Müllerの事例を見ます。出典はSAP Newsの記事です。タイトルは「AI Agents to Take Over 100,000 Manual Order Confirmations at Lemvigh-Müller」（2026年6月）です。

Lemvigh-Müllerは、年間およそ175,000件の発注を2,000社を超える取引先に送っています。このうち一部はEDI（電子データ交換）で構造的に処理されています。ですが、およそ60%にあたる取引先からの注文確認は、いまだにPDFなどの非構造化文書で返送されてきます。人間の担当者が、この非構造化文書を1件ずつ読み、内容をシステムと照合する作業をこれまで担っていました。

今回導入されたのは、単一の万能AIではなく、役割ごとに分けられた複数のAIエージェントです。ある担当者はPDFの読み取りに、別の担当者は照合に、また別の担当者は比較に特化しています。この複数エージェントを1つの自動化されたワークフローとしてオーケストレーション(連携・統合)しました。SAP Business AIの基盤上に構築したことで、年間10万件を超える注文確認処理が自動化の対象になっています。この仕組みは、導入パートナーであるNTT DATA Business Solutionsとの協業のもとで開発されました。

ここで気になるのが、「これは従来のRPA(ロボティック・プロセス・オートメーション)と何が違うのか」という点です。従来型のRPAは、あらかじめ決められた画面操作や定型フォーマットの読み取りを繰り返す仕組みです。フォーマットが少しでも崩れると、処理が止まってしまう弱さがありました。Lemvigh-Müllerの取引先の60%が送ってくる注文確認書は、まさに「フォーマットが統一されていない非構造化文書」です。AIエージェントは、文書の体裁が多少崩れていても内容を解釈できる柔軟性を持っているからこそ、この非構造化領域まで自動化の対象を広げられました。従来のRPAが手を出しづらかった領域に、AIエージェントが踏み込んだ、というのがこの事例の本質だと思います。

結果として、タッチレス処理率（人手を介さず完結する処理の割合）は90%を超え、マッチング精度は98%に達しています。SAP側の発表では、この仕組みによって年間5,000〜7,000人時の作業時間が削減されるとしています。将来的にはフルタイム従業員3〜4名分に相当するリソースが、より付加価値の高い業務へ再配置されると見込まれています。この「3〜4名分」という表現は、実際に3〜4人を解雇するという意味ではありません。これまで注文確認の照合作業に充てていた時間を、取引先との関係構築やイレギュラー対応など、人間の判断が必要な業務に振り向けるという意味です。単純な人員削減の話ではなく、人の時間の使い道を変える話として読む必要があります。

僕がこの事例で注目したいのは、「10万件」という数字そのものより、「175,000件のうち、なぜ全部ではなく10万件超なのか」という点です。全量自動化ではなく、非構造化文書という「AIが最も威力を発揮しやすい領域」に絞って導入している。ここに、AIエージェント導入の現実的な進め方のヒントがあると感じます。最初から100%を狙うのではなく、人間の作業のうち最も定型化しづらく、かつ量が多い部分から着手する。この順番が、実測値で成果を出している企業に共通しているように見えます。逆に言えば、残り7万5千件のEDI経由の構造化データは、もともと人手をほとんど介していなかったため、今回の自動化の対象にすらなっていません。「自動化できるところを全部自動化する」のではなく、「人間が一番苦労している場所から自動化する」という優先順位づけが、このプロジェクトの設計思想として一貫しています。

Databricks Genie Oneの84.5%対52.4%が意味すること

3つ目のデータは、Databricksが2026年6月のカンファレンス「Data + AI Summit」で発表した「Genie One」です。出典はDatabricks公式ブログの記事「Introducing Genie One, Genie Agents, and Genie Ontology」（2026年6月）です。

Genie Oneは、企業内の構造化データと非構造化データの両方をまたいで業務を自動化する「エージェント型の同僚」として発表されました。あわせて、企業内のアプリケーションから業務知識を継続的に学習する「Genie Ontology」というコンテキスト層も発表されています。

注目すべきは、実務に近いベンチマークでの評価です。28問の実務的な企業データに関する質問に対して、Genie Oneは初回の試行で84.5%の正答率を記録しました。これに対し、比較対象とされた「最も優れた汎用コーディングエージェント」の正答率は52.4%にとどまっています。32ポイントというこの差は、汎用的なAIエージェントと、企業データの文脈を理解するように設計されたエージェントとの間に、まだ大きな性能差があることを示しています。

ここで気になるのが、「28問という数の少なさで、性能差を語れるのか」という点です。一般的なAIベンチマークは数百〜数千問の設問で構成されることが多く、28問は決して大規模とは言えません。ただし、これは不特定多数のユーザーに向けた汎用ベンチマークではなく、実際の企業データ(構造化データと非構造化データが混在した状態)を使った実務的な質問に絞られている点が特徴です。母数は小さくても、実務に近い状況を再現したテストという意味では、参考にする価値があると僕は考えています。もっとも、この28問がどの業種・どのデータ量を前提にしているかまでは公開情報からは追い切れていないため、自社に当てはめる際は「同じ精度が出る保証はない」という前提を忘れないようにしたいところです。

僕はこれを、「AIエージェントは何にでも使える万能ツールではない」という事実の裏付けだと受け止めています。汎用エージェントに企業固有のデータ構造や業務ルールを都度説明しながら使うのと、その企業のデータ構造をあらかじめ学習したエージェントを使うのとでは、成果に大きな差が出る。同時に発表された「Genie Ontology」は、企業内のアプリケーションから業務知識を継続的に学習し続けるコンテキスト層だとされています。つまりGenie Oneの強さは、モデル単体の賢さというより、企業固有の文脈を学習し続ける仕組みとセットになっている点にあるようです。

Databricks Genie One、企業AI四極化が完成した理由でも触れましたが、AIエージェント市場は「汎用か特化か」で明確に分かれつつあります。今回のベンチマーク数値は、その分岐が実際の精度差として現れ始めていることを示す一例だと思います。汎用エージェントを万能ツールとして売り込む動きと、企業固有の文脈に特化したエージェントを売り込む動きが、今後さらにはっきり分かれていくはずです。自社でAIエージェントを選ぶ際も、「何でもできる汎用型か」「自社のデータに特化させる前提の設計か」という軸で比較検討する必要が出てきていると感じます。

この3つの実測値から、自社導入の判断軸を3つに絞る

ここまで確認した3つの実測値を、自社にどう当てはめるか。僕は次の3つの視点に整理しています。

1つ目は、対象業務に非構造化データが混ざっているかどうかです。 Lemvigh-Müllerの事例が示すように、AIエージェントが最も威力を発揮するのは、PDFや自由記述のメールのように、構造化されていないデータを人間が目視で処理している領域です。すでにシステム間でデータが構造化されて流れている業務は、そもそも自動化の伸びしろが小さくなっています。たとえば、受発注業務ならEDI連携済みの取引先はすでに十分効率化されている一方、FAXやメール添付でやり取りしている取引先が残っていないか。経理業務なら、会計システムに自動連携している支出と、紙の領収書や手入力のExcelでしか管理できていない支出が混在していないか。こうした「構造化から漏れている部分」を洗い出す作業が、最初の一歩になります。

2つ目は、複数のAIエージェントを役割ごとに分けられるかどうかです。 単一の万能AIに全工程を任せようとすると、精度が落ちやすくなります。Lemvigh-Müllerが読み取り・照合・比較という工程ごとにエージェントを分けたように、業務を分解してから任せる設計ができるかどうかが、タッチレス処理率90%超・マッチング精度98%という数字の裏側にあります。ここで気になるのが、「工程を分けるとかえって複雑になるのでは」という懸念です。実際には逆で、1つのエージェントに複数の判断を同時にさせようとするほど、どこでミスが起きたのか特定しづらくなります。工程ごとに責任範囲を分けておけば、精度が落ちた箇所をピンポイントで見直せるという利点があります。

3つ目は、既存システムへの反映まで自動化できるかどうかです。 チャットで回答を得るだけで終わる導入と、SAPシステムへの反映まで一気通貫で自動化する導入とでは、削減できる工数が桁違いです。今回紹介した事例は、いずれも「回答して終わり」ではなく、既存の基幹システムに結果を書き戻すところまでを自動化の範囲に含めています。チャットボットに質問して答えをもらい、その答えを人間が別のシステムに手で転記しているようであれば、それは「業務処理の自動化」ではなく「検索の高速化」でしかありません。この違いを意識しないまま導入を進めると、体感的な便利さはあっても、実測できる工数削減にはつながりにくくなります。

導入を検討する際は、この3つのうち何個当てはまるかを、先に自社の業務で棚卸ししておくことをおすすめします。3つとも当てはまる業務ほど、SAPやDatabricksの実測値に近い改善が見込みやすいはずです。逆に1つも当てはまらない業務にAIエージェントを導入しようとしている場合は、いったん立ち止まって、本当にAIエージェントが必要な領域なのかを見直したほうがいいかもしれません。

今週から動かせる3つの確認ステップ

最後に、この記事を読んで「自社でも検討したい」と思った方向けに、今週中にできる確認ステップを3つ用意しました。

ステップ1: 非構造化データが残っている業務を1つ、書き出す。 PDF、手書きのFAX、フォーマットが統一されていないメールなど、「人間が目で見て判断している」業務を探します。Lemvigh-Müllerの60%という数字は、決して特殊な状況ではなく、多くの企業の受発注業務に共通する構造だと思います。書き出す際は、1つの業務にかかっている月間の作業時間もあわせてメモしておくと、後で優先順位をつけやすくなります。

ステップ2: その業務を、工程ごとに分解してみる。 「読み取る」「照合する」「比較する」というように、1つの業務を最低3工程に分けられるか確認します。分解できない業務は、複数エージェントでの分業設計がしづらく、導入効果も出にくい傾向があります。もし分解した結果、どの工程も「担当者の経験と勘に頼っている」ようであれば、その業務はまだAIエージェント向きではないかもしれません。まずは工程を言語化できる業務から着手するのが現実的です。

ステップ3: 自動化した結果を、どのシステムに書き戻すかを決めておく。 チャットボットで質問に答えるだけの導入で終わらせないために、「結果をどこに反映すれば、人間の後工程がなくなるか」を先に決めておきます。この設計があるかどうかが、今回紹介した実測値と、単なるデモ止まりの導入とを分ける最大の違いです。反映先のシステムが決まっていない状態でAIエージェントの導入を始めると、せっかく処理した結果を人間が二重に確認・転記する羽目になり、工数削減どころか作業が増えるという逆効果も起こり得ます。

この3つのステップは、いずれも社内の会議室とホワイトボードだけで完結します。ベンダーに問い合わせる前に、まず自社の業務を自分たちの言葉で棚卸ししておくこと。それだけで、導入後に「思っていたのと違った」というギャップを大きく減らせるはずです。

僕自身がひとりマーケターとして日々の業務にAIエージェントを組み込むときも、最初にやるのは同じ棚卸し作業です。規模はまったく違いますが、「非構造化な作業はどこにあるか」「工程を分解できるか」「結果をどこに反映すれば後工程がなくなるか」という3つの問いは、企業規模を問わず共通して使える判断軸だと考えています。まずは自社の業務を1つ選んで、非構造化データが混ざっていないか確認するところから始めてみませんか。

まとめ

SAP Business AI Q2 2026の実測値では、Bosch Digitalの開発生産性20%向上、Joule Work導入企業の稼働率92%から92.92%への改善、LC WaikikiのHRサイクルタイム40〜60%削減など、業務ごとに異なる改善幅が報告されました。Lemvigh-Müllerの事例では、年間175,000件の発注のうち10万件超の注文確認処理が自動化され、タッチレス処理率90%超・マッチング精度98%を達成しています。Databricks Genie Oneのベンチマークでは、汎用コーディングエージェントの52.4%に対し84.5%という正答率が示されました。

これらの数字に共通するのは、AIエージェントが「チャットで質問に答える存在」から「業務プロセスの中に組み込まれて処理を代行する存在」へ移ったという変化です。導入を検討する際は、非構造化データの有無、複数エージェントへの分業可否、既存システムへの反映範囲という3つの視点で、自社の業務を棚卸しすることから始めてみてください。数字は既に、実験段階を抜け出しています。次に動くべきは、自社の業務データです。