StartupXO
言語設定

Language

B2Bツール

AIはコードを書くのに、なぜ事務のルーティンは残るのか

公開日: 2026-07-26

業務自動化コンピュータ操作エージェントバックオフィス成果報酬課金検証レイヤー

解決すべき課題

コンピュータ操作エージェントは短い作業はこなすが、実際の事務業務の長さでは5件に1件しか完結しない。それでもベンダーは削減額を基準に請求する。何がいくら削減されたかを測る層が存在しない。

なぜ今なのか

成果報酬型の課金が業務自動化の標準契約になりつつあるのに、その成果を実測し、失敗分を人に戻す配管を誰も作っていない。

推薦人材

業務プロセスを秒単位で実測した経験のある人と、エージェントの実行ログ基盤を触ったことのある人が同じチームにいること

どんな問題か

プレンティスは、リタンカル・ダス氏がリード・ホフマン氏、マーク・ピンカス氏と今年4月に立ち上げたAIラボだ。企業価値10億ドルで1億ドルを調達する交渉中で、医療マネジメント会社や複数のメーカーを含む顧客と最大5,000万ドル規模の契約をすでに結んでいる。従業員は25人ほど、第3四半期の年換算売上は7,500万ドルを見込む。注目すべきは課金方式で、実際に削減された金額の20%を受け取る構造だ(TechCrunch)。同社の賭けは一文で要約できる。日常的な事務作業の自動化が、まもなくコーディングを抜いてAI最大の用途になる。

方向は正しい。問題は、その一文と現場のあいだに何が抜けているかだ。

OSWorld 2.0は、人間が終えるのに中央値で約1.6時間かかる実務ワークフロー108件でコンピュータ操作エージェントを評価するベンチマークである。結果は厳しい。500ステップの予算で最高成績はClaude Opus 4.8の20.6%、部分点では54.8%まで届くものの、最後まで単独で完結した割合は5件に1件だった。GPT-5.5は13%付近で頭打ちになっている(arXiv)。論文が挙げた失敗要因もGUI操作やコーディング能力ではない。制約条件の追跡、作業途中で現れた情報の処理、自己検証、隠れた状態からの復帰。どれも長い仕事を人がどう抱えているかに関する能力だ。

現場に残る問いは二つになる。5件のうち4件が途中で止まったとき、その残骸は誰が片づけるのか。そして「削減額の20%」の削減額は、誰がどう測るのか。

いまはどちらもスライドで処理されている。導入前にコンサルタントが見積もった1件あたり処理時間に人件費を掛けた数字が契約書に入り、その後の実測はない。エージェントが途中で止まれば、担当者が画面を見てどこまで進んだかを推測し、引き継ぐ。何が終わり何が終わっていないかの記録が残らないので、翌月の請求書を検証する手立てもない。

なぜ今か

成果報酬型の課金が急速に広がっている。削減額ベースの請求はプレンティス固有の仕組みではなく、席数課金では稟議を通せない市場が見つけた答えに近い。ただしこの構造は計測があって初めて成立する。売り手が自分で削減額を計算して請求書を送る状態は長続きしない。財務は二度目の更新で必ず尋ねる。日本の現場ならなおさらだ。RPAが全社導入された時期に「稼働ロボット台数」は積み上がったのに要員計画がほとんど動かなかった記憶が、多くの経理・業務部門に残っている。

技術的な前提はすでに揃った。エージェントは画面キャプチャ、クリック座標、DOMアクセス、ツール呼び出しをすべてログとして吐く。基幹システム側も案件のステータスをAPIで返す。欠けているのはデータではなく、二つの流れを突き合わせて「この案件は本当に完結したのか」を判定する層である。

採用市場の信号も同じ方を向いている。AIインフラ企業の公開求人を眺めると、いま増えているのはモデル研究者よりソリューションアーキテクトとセキュリティエンジニアだ。ボトルネックがモデル性能ではなく、現場への実装と監査可能性に移ったということになる。

時間割も決まっている。今年前半に結ばれたパイロット契約が更新面談に到達するのは、おおむね2四半期から3四半期先だ。その会議に持ち込む資料を作る道具は、それより前に存在していなければならない。

どう作るか

flowchart LR
    A[人の作業画面ログ] --> C[工程マップ]
    B[エージェント実行ログ] --> C
    C --> D[工程ごとの通過判定]
    D -->|通過| E[完結記録]
    D -->|未達| F[状態と証跡を束ねて人のキューへ]
    E --> G[月次の実測削減レポート]
    F --> G

MVPは狭く取る。業務系ひとつ、顧客ひとつ。保険金請求の受付でも関税還付でも請求書の突合でもいい。人が30分から90分かけて繰り返す定型業務をひとつだけ選ぶ。まず人がやっている画面をログとして受け取り、工程に分解して工程ごとの所要時間を実測する。次にエージェントの実行ログを同じ工程マップの上に重ねる。各工程には通過条件を付ける。モデルの判断ではなく、システムで確認できる条件であることが重要だ。登録されたか、金額が元帳と一致するか、書類が提出されたか。条件を満たさなければ、そこまでの状態と証跡を束ねて人のキューに渡す。月末には完結件数と実測削減時間を掛け、顧客が自分で検証できる請求根拠を出す。

エージェントを自分で作らないことが肝になる。プレンティスもAnthropicもOpenAIもそのモデルを作っており、あの競争には9桁の資金が要る。どのベンダーのエージェントでも同じ物差しで測り、同じ形で引き渡す層は、中立であるほど値がつく。スタック自体は平凡だ。イベントログの収集、工程マップのエディタ、通過条件を書く小さなDSL、人のキューがひとつ。難所はモデルではなく工程マップを誰が描くかで、顧客が増えるほどそのライブラリが防衛線になる。

成功の条件

第一の仮説は、企業が本当に削減額を検証したいのかどうかだ。成果報酬型の自動化契約をすでに結んでいる会社5社の財務担当に、前四半期の請求書を何で確認したかを聞けば2週間で分かる。「ベンダーのレポートをそのまま上げた」という答えが3回出れば、市場はある。

第二の仮説は、エージェントのベンダーが採点者を隣に置くことを受け入れるかだ。嫌がる会社はある。だからこれは売り手ではなく買い手に売る。ただし成果報酬で課金するベンダーほど、更新を守るために同じ証跡を必要とするようになる。最初に強く押し返した相手が1年後に問い合わせてくる可能性は低くない。その転換がいつ来るかが、この事業の速度を決める。

一緒に作りましょう

一緒に作る人材を見る