実業務で動くAIエージェントは、すでに「チャットで答える」段階を越えている。Arenaが7日間・160,480タスクの実利用ログを集計したところ、セッションの75.6%が少なくとも1回ツールを実行し、bashコマンド実行は41.1%に達した。一方、複数の要素を含む依頼が完全に満たされたのは58%、8%は無言で一部を落としていた。任せられる範囲は広がったが、検収を人間が持つ前提は変わっていない。
この数字は誰が測ったものか（利害関係の明示）
先に出どころをはっきりさせる。この記事は Arena（Arena Intelligence）自身による発表であり、同社は当該製品の提供者である。計測対象となった Agent Mode（arena.ai/agent）はArenaが提供するプラットフォームそのもので、自社製品の利用ログを自社が集計・公表した数値だ。第三者による検証ではない（出典：Arena（Arena Intelligence、2026）、2026-06-04、https://arena.ai/blog/agent-arena-methodology/）。
そのうえで、この種のデータには他にない価値がある。ベンチマークの点数ではなく、実際に人が金と時間をかけて回している業務のログだからだ。ベンチマーク上の合格と実務で採用される成果物が別物であることは、ベンチマークの合格とマージ可能なPRは別物かでも扱った論点で、実利用ログはその隙間を埋める材料になる。
対象範囲
| 項目 | 内容 |
|---|---|
| 計測対象 | ArenaのAgent Mode実ユーザートラフィック |
| タスク数 | 160,480件 |
| セッション数 | 128,244セッション |
| 観測期間 | 7日間 |
| ツール呼び出し総数 | 2,060,159回（bash 936,046回、write_file 549,893回、web_search 275,660回） |
| ファイル操作で書かれたコード行数 | 4,030万行（7日間・160,480タスクの合計） |
| 集計・公表主体 | Arena（当該製品の提供者本人） |
エージェントは何をしているのか
タスク種別の構成比は次の通り（分母＝タスク、5%以上のカテゴリのみ掲載）。
- コード記述17.5%、調査10.8%、計画・ブレスト10.6%
- 画像動画10.2%、文書作成9.1%、デバッグ8.9%
- 雑談6.8%、教育5.7%、創作5.3%
コード関連（記述＋デバッグ）で26.4%を占める一方、調査・計画・文書作成といった非エンジニア業務が30.5%ある。エンジニア専用の道具ではない、という点はまず押さえておきたい。ただし5%未満のカテゴリは掲載されておらず、残り約15%分の内訳は不明である。
より重要なのは実行の中身だ。少なくとも1回ツールを使用したセッションは75.6%、うちbashコマンド実行が41.1%、Web検索が27.1%。つまり4件に3件は、文章を返して終わりではなく、コマンドを叩きファイルを書いている。エージェントという言葉の定義そのものはAIエージェントとは何かに譲るが、実利用の重心が「実行」側にあることは数字が示している。
人間はどこで手綱を握り直しているか
Arenaは応答後のユーザー操作も集計している。応答が返ったあとにユーザーが制御を取り戻す操作は、追加で委任する操作の約2.3倍だった。初手では45%が完成物の引き渡しを委任し、14%が自律動作を指示している。入口では任せるが、出口では人が握り直す——という形だ。
そして最も実務に効くのが充足率である。複数のパートを含むリクエストのうち、完全に充足されたのは58%。8%は一部が無言で落とされていた。エラーも警告も出さずに、頼んだ3つのうち1つが消える。これが8%起きる。なお、ユーザーが修正を依頼したケースのうち、エージェントがそれを拒否した割合は2.7%だった。
コストはどこで膨らむか
入力トークンの分布も公表されている（分母＝セッション）。
- 128kトークン超：32%
- 256kトークン超：22%
- 100万トークン超：8%
長い作業ほど文脈が積み上がり、従量課金は非線形に膨らむ。12セッションに1回は100万トークン超が発生する計算になる。料金設計の考え方はAIのコスト構造にまとめているが、実務上の結論は単純で、予算は平均値ではなく上振れ側で組むしかない。
読者への意味：中小企業が導入前に決めるべき3つ
1. 権限設計と実行環境の分離が先。 75.6%がツールを実行し、41.1%がbashを走らせる運用が既定路線である以上、「試しに入れてみる」の前に、どのディレクトリに書き込めるか、どの認証情報を渡すか、本番系から切り離された実行環境をどう用意するかを決める必要がある。順序を逆にすると、事故が起きてから設計することになる。
2. 検収を人間の工程として残す。 完全充足58%・無言の欠落8%という数字は、「頼んだことは全部やられている」前提で成果物を受け取る運用が成り立たないことを意味する。対策は地味だが確実で、依頼を分割して投げること、そして納品物を依頼のチェックリストと照合する工程を人間側に置くことだ。
3. 工数は「介入し続ける前提」で見積もる。 制御を取り戻す操作が委任の約2.3倍という比率は、丸投げして完了という運用が現場では成立していないことを示す。導入効果を試算するなら、監督・修正の時間を工数から抜かないことだ。
TOEの読み筋
前提として、この計測結果の追試はTOEでは未実施である。ArenaのAgent Modeを使った検証も行っていない。以下は数字から引ける読み筋であり、TOEの実測ではない。
そのうえで見立てを書く。この数字が示しているのは、AIエージェントの導入判断が「性能が足りるか」から「業務プロセスをどう組み替えるか」に移ったということだ。58%という充足率は、裏を返せば42%は人の確認が価値を生む余地があるという意味でもある。であれば、投資すべきはより賢いモデルを探すことより、依頼の粒度を揃えるテンプレートと、納品物の照合手順を社内に定着させることになる。評価軸の作り方は自社の評価基準を持つで扱った通りで、外部の点数ではなく自社の業務で測るしかない。
もう一点。bash実行41.1%という数字は、情報システム担当にとっては仕様変更に近い。エージェント導入は「新しいSaaSを1本入れる」ではなく「新しい実行主体が社内ネットワークに増える」話として扱うのが妥当だと考えている。
この数字の限界
そのまま自社に当てはめられない理由を並べる。
- 集計・公表しているArenaは、計測対象であるAgent Modeの提供者本人であり、第三者検証ではない。
- 対象はArenaのAgent Modeを能動的に使うユーザーのトラフィックに限定される。自己選択されたアーリーアダプター層であり、中小企業の一般従業員の利用実態とは母集団が異なる。企業規模・業種・国の内訳は本文に記載がない。
- 観測期間は7日間のスナップショットにすぎず、季節性や特定期間のイベントの影響を排除できていない。
- Arena自身が「現行のリーダーボードはオーケストレーター（統括役）のみを評価しており、それ以外のコンポーネントは評価していない」と明示している。エージェント全体の能力評価ではない。
- 新モデル投入による分布シフトを時間減衰重みで補正していると同社が述べており、計測期間中もモデル構成が動いている。数値は安定した定常値ではない。
- タスク種別の構成比は5%以上のカテゴリのみの掲載で、残り約15%分の内訳は開示されていない。
つまり、この数字は「AIエージェント一般の性能」ではなく「あるプラットフォームの、ある1週間の、ある種のユーザーの使われ方」である。中小企業が使うべきは絶対値の引き写しではなく、想定していなかった論点——実行権限、無言の欠落、トークン上振れ——を導入前チェックに追加することだ。
まとめ
- Arenaが自社Agent Modeの実利用160,480タスク・128,244セッション（7日間）を集計。この記事はArena社自身による発表であり、同社は当該製品の提供者である。
- セッションの75.6%が少なくとも1回ツールを実行し、bash実行41.1%・Web検索27.1%。導入前に権限設計と実行環境の分離が要る。
- 複数要素を含む依頼の完全充足は58%、8%は無言で一部が落ちる。依頼を分割し、納品物のチェックリスト照合を人間の工程として残す。
- 応答後に制御を取り戻す操作は追加委任の約2.3倍。丸投げ完了ではなく、監督工数を見積もりに入れる。
- 入力トークン128k超が32%、100万超が8%。予算は平均でなく上振れ側で組む。
- 対象は7日間・自己選択されたユーザーに限られ、評価対象もオーケストレーターのみ。TOEでの追試は未実施である。