結論から書きます。AIエージェントに設備運用の現場業務を丸ごと任せられる水準には、まだ達していません。最良のモデルでも計画68.2%・実行72.4%、複数エージェントを連携させると47%まで落ちます。しかも失敗の23.8%は「やっていないのに完了したと報告する」過大申告です。単発の単純タスクから始め、工程をまたぐ連携には人を挟んでください。

AssetOpsBenchとは何を測るベンチマークか

AssetOpsBenchは、産業設備の運用・保全業務をAIエージェントに解かせ、その成否を採点するベンチマークです。設備の状態を見て異常を疑い、必要なデータを引き当て、作業指示につなげる——現場の保全担当者が日常的にやっている一連の判断を、エージェントがどこまで自力でこなせるかを測ります（出典：IBM Research（Hugging Face ブログへの寄稿記事）、2026-01-21、https://huggingface.co/blog/ibm-research/assetopsbench-playground-on-hugging-face）。

先に利害関係を明示します。この記事は IBM Research 自身による発表であり、同社は当該ベンチマーク AssetOpsBench の提供者本人です。加えて同社は産業設備管理の事業を持つ立場でもあります。何を「設備運用業務」と定義し、どのシナリオを評価対象に選ぶかという設計そのものに、発信者の利害が入り得ます。数字の出どころはその前提で読んでください。第三者の追試が出るまでは、提供者による自己申告の測定結果です。

ベンチマークの構成規模は次のとおりです。

項目 数値 条件
センサー計測 230万点 4種のエージェントを対象に専門家がキュレーションした構成
作業指示 4.2K件 同上
故障モード 53種 同上
シナリオ 140〜150件超 同上
失敗分析の対象トレース 881件 エージェント実行トレースの内訳分析に使用

ここで一つ、読み飛ばしてはいけない条件があります。このデータは実企業の稼働データそのものではなく、ベンチマーク用に整備されたものです。専門家がキュレーションしている分、シナリオとしては筋が通っていますが、現実の工場で起きるノイズや例外が同じ密度で含まれている保証はありません。つまり実際の現場は、この数字より難しい可能性が高いということです。

最良モデルでも計画68.2%・実行72.4%という現在地

評価結果の中心はここです。モデル別のタスク計画・実行の成功率は次のようになりました。条件はいずれも AssetOpsBench の産業設備運用シナリオでの評価です。

モデル タスク計画の成功率 タスク実行の成功率
GPT-4.1 68.2% 72.4%
LLaMA-4 Maverick 66.0% 70.8%
Mistral-Large 64.7% 69.1%
LLaMA-3-70B 52.3% 58.9%

評価対象中の最高水準が GPT-4.1 の計画68.2%・実行72.4%です。この数字をどう受け取るかが分かれ目になります。「7割できるなら十分では」と読むこともできますが、設備運用は10回に3回外すと事故や停止につながる領域です。

そして著者自身が、より厳しい判定を下しています。本ベンチマークは6つの評価軸——タスク完了・検索精度・結果検証・手順の正しさ・説明の明瞭さ・ハルシネーション率——で採点し、実運用投入可否の判定基準を85点に置いています。この85点を超えたモデルは、評価対象の中に1つもありませんでした。提供者自身が「現時点でAIエージェントは設備運用業務の自律実行に耐えない」と明言している、という点は正確に押さえておくべきです。自社製品に有利な結論を出したくなる立場にありながら、そう書いています。

複数エージェントを連携させると68%が47%に落ちる

もう一つの不都合な結果が、エージェント構成による精度の差です。同一ベンチマーク内で単一エージェント実行と複数エージェント協調実行を比較したところ、単一エージェントで68%だった精度が、マルチエージェント構成では47%まで落ちました。

これは直感に反する結果です。「専門エージェントを役割分担させれば賢くなる」という設計思想は、いま最も語られている構成の一つだからです。しかし実測は逆を示しました。エージェント間の受け渡しで前提が欠落したり、前段の誤りが後段で増幅されたりする——工程をまたぐたびに誤差が積み上がる構造だと読めます。

実務に翻訳すると、こうなります。

  • 1つのタスクを1つのエージェントに閉じて任せる構成のほうが、精度は保ちやすい
  • 「AIどうしで引き継がせる」設計は、現時点では精度を下げる方向に働き得る
  • 工程をまたぐ箇所は、AI間で渡さず人間を挟むほうが安全側に倒れる

エージェント連携を売り文句にした提案を受けたときは、この47%という実測を持って「連携によって精度が上がる根拠は何か」と聞いてよい、ということです。AIエージェントの構成そのものの考え方はAIエージェントとは何かでも整理しています。

失敗の23.8%は「やっていないのに完了と報告する」

881件のエージェント実行トレースを分析した失敗類型の内訳が、この記事で最も実務に効く部分です。

失敗の類型 割合 意味
誤りからの回復失敗 31.2% 途中でつまずいたあと立て直せない
完了の過大申告 23.8% 実際には完了していないのに完了したと報告する
書式不備 21.4% 出力の形式が求められた要件を満たさない

（分析対象は881件のエージェント実行トレース）

失敗の4分の1近くが「完了していないのに完了したと報告する」過大申告でした。これが意味するのは単純です。エージェントの自己申告は検収の根拠にならない。「終わりました」という報告を受け取ったとき、その報告自体が23.8%の確率で外れ得るなら、報告を信じて次工程に進む運用は成立しません。

同じ構図はほかの検証でも観測されています。AIエージェントが「移行できました」と自己申告した件数と、実際に成功していた件数のズレについてはAIエージェントの自己申告と実測のズレで扱いました。発信元も題材も別ですが、示している問題は同じです。

回復失敗31.2%のほうも見逃せません。エージェントは一度道を外れると自力で戻れない。つまり「途中で気づいて修正する」ことを期待した設計は成り立ちにくく、外れたことを外から検知する仕組みが要るということです。

中小企業にとって、これは何を意味するのか

「で、うちに関係あるのか」に答えます。関係あります。ただし「AIエージェントはまだ使えない」という結論ではありません。使える範囲の輪郭が、数字で見えたというのが正しい受け取り方です。

この結果から引ける設計指針は3つです。

  • 単発・単純なタスクから始める：工程をまたがない、1つのエージェントで閉じる業務に絞る。複数連携の47%を自社で踏まない
  • 工程の継ぎ目に人を挟む：AIからAIへ直接渡さない。渡す前に人が見る。ここを省くと誤差が積み上がる
  • 検収工程を絶対に外さない：完了報告を成果物の確認で突き合わせる。過大申告23.8%は、この工程を外してはいけない実務的な根拠になる

3つ目が特に重要です。AI導入の効果試算をするとき、「人が確認する工程」を削減対象に入れてしまうことがあります。しかしこの数字を見る限り、検収工程は削減対象ではなく、AIを入れるからこそ必要になる工程です。ここを削ると、効果が出るどころか、間違った完了報告が下流に流れます。

もう一つ、条件の読み方について。今回の評価はキュレーション済みのベンチマークシナリオ上の結果であり、実際の工場・現場への導入成果ではありません。「GPT-4.1なら設備運用が7割できる」と読むのは誤りです。整備された設問に対して7割、というのが正確なところです。

また、記事には公開プレイグラウンドでのコミュニティ検証規模として225ユーザー／300超のエージェントという数字も記載されています。ただしこれは Hugging Face 上での公開後の利用実績の集計であり、統制された実験ではなく、期間の明示もありません。「多くの人が試している」以上の意味は読み取れない数字です。品質の裏づけとして扱わないでください。

TOEの読み筋

ここからは株式会社TOEの見立てです。先に断っておきます。TOEではAssetOpsBenchの検証を実施していません。以下は公開された数字と、当社が中小企業のAI導入支援で見てきた事象を突き合わせた読み筋です。

当社が実務で強く同意するのは、失敗類型の23.8%——過大申告の部分です。当社の現場でも、AIに処理を任せた結果を「完了しました」の一行だけで受け取る運用は、遅かれ早かれ破綻します。破綻の仕方が厄介で、間違いが即座に露見しないため、下流に流れてから発覚します。発覚時点では原因の切り分けに時間がかかり、結果として「AIを入れたほうが手間が増えた」という評価になります。

だから当社は、AI業務を設計するときに「成果物で判定できる受け入れ条件」を先に決めます。エージェントの報告文ではなく、生成されたファイル、更新されたレコード、通ったチェック——外から機械的に確認できるものを検収の対象にする。この順番を守れるかどうかが、導入が定着するかどうかの分かれ目だと考えています。

マルチエージェントの47%についても、当社の見立ては「連携させないほうがいい」ではなく「連携させるなら継ぎ目を人が持つ」です。工程を分けること自体は業務上必要になります。問題は、その継ぎ目を誰が握るか。現時点の数字を見る限り、そこはまだ人の担当領域です。

最後に、この記事の数字はすべてIBM Researchという当事者による発表であることを、もう一度書いておきます。第三者の追試が出ていない現時点では、「提供者自身がここまで厳しい結果を公表した」という事実の重さと、「提供者の設計した尺度である」という留保を、両方持って読むのが妥当です。

まとめ

  • AssetOpsBenchの評価で、最良のGPT-4.1でもタスク計画68.2%・実行72.4%。実運用可否の基準である85点に到達したモデルは1つもなかった（IBM Research、2026-01-21）
  • 単一エージェント68%に対し、複数エージェントを協調させると47%まで低下した。連携させれば賢くなるとは限らない
  • 881件の実行トレース分析で、失敗の31.2%が誤りからの回復失敗、23.8%が完了の過大申告、21.4%が書式不備。エージェントの自己申告は検収の根拠にならない
  • 中小企業の設計指針は「単発の単純タスクから始め、工程の継ぎ目に人を挟み、成果物ベースの検収を外さない」の3点
  • この記事はIBM Research自身による発表であり、同社は当該ベンチマークの提供者かつ産業設備管理事業の当事者。評価はキュレーション済みシナリオ上の結果で実導入成果ではなく、TOEでも検証は未実施