投稿者 投稿日: カテゴリー Claude
AutomationBenchとは、AIが業務フローを最後まで完了できるかを測る評価のことです。
Anthropic が2026年9月1日に公開した Claude Fable 5.1 は、業務フローの完遂率を測る AutomationBench で31.4%を記録しました。前のモデルの Fable 5 は17.1%だったので、ほぼ倍増です。ただし裏返せば、最上位クラスのAIでも、10件の業務のうち約7件は最後までやり切れていないことになります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、31.4%という数字の正しい読み方と、自社のEC業務でAIにどこまで任せられるかを確かめる5つの手順を、プロンプト3本つきで解説します。
AutomationBenchは何を測るのか：「文章の出来」ではなく「業務の結果」
AutomationBench の特徴は、AIが書いた文章の質ではなく、業務が正しく終わったかどうかだけを判定する点にあります。開発したのは業務自動化ツールの Zapier で、同社の発表は、これを「出力ではなく成果のためのベンチマーク」と位置づけています。正しいレコードが更新され、正しいメッセージが送られたか、それとも送られなかったか。判定はその2択です。
評価の舞台は、実際の職場を模した環境です。生きたデータが入ったCRM、やり取りの続くメールの受信箱、予定がぶつかったカレンダーが用意され、AIは「依頼のメッセージ」や「Slack の投稿」を起点に、自分で何をすべきか判断して動きます。領域は営業、マーケティング、オペレーション、サポート、経理、人事の6つで、Zapier の利用者に多い自動化のパターンから選ばれました。
意図的に「現場の面倒さ」が仕込まれているのもポイントです。似た名前の取引先担当者、そろっていない書式、1回の誤った操作が後の手順すべてに波及する複数ステップの処理など、実務で人がつまずく条件がそのまま入っています。採点は、最終的な環境の状態を成功条件と突き合わせる機械的な方法で、AIに採点させる方式や主観的な評価は使われていません。公開用の問題セットに加え、モデル提供企業が学習に使えない非公開セットでの検証も用意されています。
この設計は、EC事業者が知りたいことにかなり近いと言えます。商品説明文の上手さを競うベンチマークは多くありますが、店舗運営で本当に困るのは「受注データを確認し、在庫を引き当て、お客さまに連絡し、記録を残す」という一連の流れが途中で止まることです。AutomationBench は、まさにその流れを最後までやり切れるかを測っています。
31.4%をどう読むか：3つの見方
Vellum のまとめによると、AutomationBench の成績は Fable 5.1 が31.4%、Opus 5 が26.9%、GPT-5.6 Sol が19.6%、Fable 5 が17.1%でした。この数字は、少なくとも3つの角度から読む必要があります。
見方1：無人での完全自動化は、まだ現実的ではない
最も大事な読み方は、31.4%が「約7割は失敗する」という意味だということです。しかもこれは、最上位クラスのモデルの成績です。複数のシステムをまたぐ業務を、人の確認なしにAIへ丸ごと任せる段階には、まだ来ていません。EC業務の自動化を考えるときは、「AIが下ごしらえをし、人が確認して確定する」という分担を前提に設計するのが現実的です。
見方2：倍増の一部は「止められていた分」の回復
Fable 5 から Fable 5.1 への伸びには、注意すべき事情があります。Anthropic によると、Fable 5 は安全のための仕組み（セーフガード）が介入した課題では0点として扱われていました。Fable 5.1 では、問題のない依頼まで止めてしまう過剰な遮断が減ったとされています。つまり倍増の一部は、能力の向上ではなく「止められていた分が戻った」ことによるものです。逆に言えば、正当な業務が安全装置に止められるリスクは、モデル選びで見落とせない要素だということでもあります。
見方3：順位はすぐ入れ替わる
AIモデルの成績表は、数か月で塗り替わります。Fable 5.1 の公開から3週間後には、Claude Opus 5.5 が Fable 5.1 と同等の性能を約40%低い費用で出せると報じられました（うるチカラの解説はClaude Opus 5.5は運用費40%減でFable 5.1並み）。ベンチマーク集計サイトでは、Claude Sonnet 5.5 が AutomationBench の非公開セットで44.7%と掲載されていますが、これはモデル提供企業が報告した値で、公開セットの数字とは別枠です（要確認）。特定の時点の1位に合わせて業務を組むのではなく、モデルを入れ替えられる設計にしておくことが大切です。
ほかのベンチマークも見ておくと、Fable 5.1 はパソコン操作を測る OSWorld 2.0 の厳格判定で41.7%、知識労働の質を測る GDPval-AA v2 で1,853点でした。いずれも前モデルを上回っていますが、パソコン操作でも厳格に判定すれば6割近くは完了できていません。
EC業務に置き換えると：6つの領域はこう対応する
AutomationBench の6領域を、EC事業の業務に置き換えてみます。対応関係が分かると、自社のどの業務がAIに向き、どこでつまずきやすいかの見当がつきます。
営業は、卸先や法人顧客とのやり取り、見積もりの作成と記録にあたります。マーケティングは、メルマガの配信設定、広告の入稿、キャンペーンの準備です。オペレーションは、受注の確認、在庫の引き当て、出荷の指示といった店舗運営の中心業務。サポートは、配送や返品の問い合わせ対応です。経理は、入金の確認や請求書の発行、人事はアルバイトのシフト調整などが該当します。
ベンチマークに仕込まれた「現場の面倒さ」も、EC業務にそのまま現れます。似た名前の取引先担当者は、同姓同名の購入者や、旧姓と新姓で登録が分かれた会員に相当します。そろっていない書式は、全角と半角が混ざった住所や、モールごとに形式が違う注文番号です。誤った操作の波及は、在庫数の更新を間違えたまま楽天市場と Amazon と自社ECに同期してしまう事故そのものです。アパレルのように色違い・サイズ違いの商品コードが並ぶジャンルでは、AIがコードを1つ取り違えるだけで在庫の引き当て先がずれ、欠品と過剰在庫が同時に起きます。
一方で、AIが比較的得意とするのは、1つのシステムの中で完結し、判断の基準がはっきりした作業です。たとえば、問い合わせメールを読んで種類を分類し、返信の下書きを作るところまでなら、成功率はかなり高くなります。業務を「1つのシステムで完結する部分」と「複数のシステムをまたぐ部分」に切り分けて考えると、任せ方が見えてきます。
具体例で考えてみます。楽天市場の注文でのし指定がある注文を処理する場合、楽天RMSの受注画面で注文を確認する、のしの種類と名入れの内容を読み取る、受注管理システムに反映する、倉庫に出荷指示を送る、という流れになります。このうち、注文内容からのしの種類と名入れを読み取って一覧にする部分は1つの画面で完結し、AIに向いています。反対に、受注管理システムへの反映と倉庫への指示は、システムをまたぐうえ、誤ると誤配送に直結します。ここは人が確認してから確定する、という線引きが自然です。
自社の業務でAIの実力を確かめる5つの手順
ベンチマークの数字は参考にはなりますが、自社の業務で何%成功するかは、自社で試さないと分かりません。AutomationBench の考え方を借りて、小さく検証する手順を5つに分けて説明します。プロンプトは3本用意しました。ChatGPT・Claude・Gemini のどれでも使えます。
手順1：業務フローを「手順」と「判断」に分解する
最初に、自動化したい業務を、手順と判断のポイントに分解します。AIがつまずくのは、たいてい判断のポイントか、システムをまたぐ受け渡しの部分です。分解しておくと、どこまでをAIに任せ、どこで人が確認するかを決めやすくなります。
プロンプト1：EC業務フローの分解
あなたはEC業務の自動化設計に詳しいコンサルタントです。
以下の業務を、AIエージェントに任せる前提で分解してください。
業務名：{例 楽天市場の注文で、のし指定がある注文を確認して出荷指示を出す}
使っているシステム：{例 楽天RMS、受注管理システム、倉庫への出荷指示メール}
現在の担当者がやっている手順の説明：{手順を文章で}
次の形で出力してください。
1. 手順を番号付きで並べ、各手順で使うシステムを明記
2. 判断が必要なポイントと、その判断基準（基準が曖昧なものは「曖昧」と明記）
3. システムをまたいでデータを受け渡す箇所
4. 1回の誤りが後の手順に波及する箇所と、その影響
5. AIに任せやすい手順と、人が確認すべき手順の切り分け案
手順2：「成功」を最終状態で定義する
次に、業務が成功したとはどういう状態かを、最終状態のチェックリストで定義します。AutomationBench が「正しいレコードが更新され、正しいメッセージが送られたか」で判定するのと同じ考え方です。「いい感じに処理できた」ではなく、「受注ステータスが出荷待ちになっている」「倉庫へのメールに注文番号とのし種別が正しく書かれている」のように、確認できる状態で書きます。
プロンプト2：成功条件のチェックリスト作成
あなたは業務の品質管理の専門家です。
以下の業務について、AIが処理を終えたあとに「成功」と判定するための最終状態のチェックリストを作成してください。
業務名：{業務名}
業務の手順（手順1で分解したもの）：{手順}
関係するシステム：{システム名}
条件：
1. 各項目は「はい／いいえ」で判定できる形にする
2. 文章の出来ではなく、データやメッセージの最終状態で判定する
3. 1項目でも「いいえ」なら失敗とみなす前提で書く
4. 見落としやすい項目（記録の残し忘れ、通知の送り忘れなど）を必ず含める
出力は番号付きのチェックリストと、各項目を確認する方法（どの画面で何を見るか）にしてください。
手順3：「意地悪な条件」を含むテストケースを作る
3つ目の手順は、実際の業務で起こりうる面倒な条件を含んだテストケースを10件ほど用意することです。きれいなデータだけで試すと、成功率は高く出ます。同姓同名の顧客、住所の表記ゆれ、在庫が1つしかない商品への同時注文など、現場で起きる条件を混ぜて初めて、実力が分かります。
プロンプト3：意地悪な条件を含むテストケースの作成
あなたはEC業務のテスト設計の専門家です。
以下の業務について、AIエージェントの実力を確かめるためのテストケースを10件作成してください。
業務名：{業務名}
業務の手順：{手順}
過去に人が間違えたことのある事例：{あれば}
条件：
1. 10件のうち3件は、問題のない標準的なケースにする
2. 残り7件には、次のような面倒な条件を1つずつ含める
・似た名前の顧客や商品
・全角と半角、旧字体などの表記ゆれ
・在庫が足りない、または同時に注文が入る
・指示があいまいで、確認が必要なケース
・処理してはいけない（保留すべき）ケース
3. 各ケースに、期待される正しい最終状態を書く
個人情報は架空のものを使い、実在の人物や住所を使わないでください。
手順4：人の承認つきで試走する
テストケースがそろったら、本番のデータには触れない環境、または承認を挟む設定で試走します。AIが提案した操作を人が確認してから実行する形にすれば、失敗しても実害は出ません。
モールの管理画面には、本番と切り離した練習用の環境が用意されていないことがほとんどです。その場合は、受注データや在庫データをCSVで書き出し、AIにはその写しを渡して「どのデータをどう変更するか」を提案させる形で試します。提案された変更内容を、手順2のチェックリストと突き合わせれば、本番に触れずに成功率を測れます。実際の画面操作まで試したい場合は、テスト用の商品ページや、自分宛ての注文など、影響が店舗の外に出ない対象を選びます。
試走の記録も大切です。各テストケースについて、AIがどの手順で何をしたか、どこで止まったか、どの判断を誤ったかを残しておくと、指示文の改善点が見えてきます。同じ失敗が繰り返されるなら、指示文に判断基準を書き足すか、その手順だけ人に戻すかを決めます。複数のシステムを操作するエージェントを試す場合は、1回あたりの費用の上限も決めておきます。費用の上限設定についてはClaude Managed Agentsのセッション予算でAI暴走コストを止める5手順で詳しく解説しています。
手順5：成功率で任せ方を決める
最後に、10件のテストの成功率を見て、任せ方を決めます。現場感覚での目安として、9割以上なら「AIが処理し、人は抜き取りで確認」、5割から9割なら「AIが下ごしらえし、人が全件確認して確定」、5割未満なら「AIは情報の整理だけに使い、操作は人が行う」という3段階に分けると判断しやすくなります。モデルを入れ替えたときは、同じテストケースで測り直せば、比較も簡単です。
よくある失敗例と回避策
1つ目は、ベンチマークの順位だけでモデルを決める失敗です。AutomationBench で1位のモデルが、自社の業務でも1位とは限りません。業務の種類、使っているシステム、データの汚れ具合で結果は大きく変わります。回避策は、手順3で作ったテストケースを社内の「物差し」として持ち、候補のモデルを同じ条件で比べることです。
2つ目は、成功率の高い部分だけを見て、全体を自動化してしまう失敗です。問い合わせの分類は9割以上うまくいっても、その後の返金処理まで任せると、金額の誤りという重大な失敗が起きることがあります。失敗したときの影響の大きさは手順ごとに違うため、影響の大きい手順ほど人の確認を残します。
3つ目は、安全装置による停止を想定していない失敗です。Fable 5 の例のように、正当な業務でもAIの安全の仕組みが介入して処理が止まることがあります。健康食品や化粧品の説明文、返品に関するやり取りなど、言葉の選び方で止められやすい業務では、止まったときに人へ引き継ぐ流れを必ず用意しておきます。
KPI設計と費用の目安
検証と運用は、3つの指標で管理します。1つ目は「テストケースの成功率」で、手順5の判断に使います。2つ目は「本番での人の修正率」で、AIの処理のうち人が手直しした割合を追います。3つ目は「1件あたりの処理時間」で、人だけで処理した場合と比べます。修正率が下がらないまま処理件数だけが増えている場合は、確認の負担が人に偏っているサインなので、任せる範囲を見直します。
費用の面では、Fable 5.1 の料金は入力100万トークンあたり10ドル、出力50ドルで、Fable 5 から据え置かれました。キャッシュの読み取りは100万トークンあたり0.25ドルと、前のモデルより75%安くなっています。Anthropic は、一般的な処理で約25%、エージェント的な処理では最大約45%費用が下がると説明しています。複数のシステムを何度も行き来する業務ほどトークンを多く使うため、まずは10件のテストで1件あたりの費用を実測し、月間の処理件数を掛けて見積もるのが確実です。最上位モデルにこだわらず、同じテストケースで Opus や Sonnet など下位のモデルも測り、成功率と費用の釣り合いで選ぶのが現実的です。
今後の展望：「業務を完遂できるか」がモデル選びの主軸になる
AutomationBench のような「成果で測る」ベンチマークの登場は、AIモデルの評価軸が、賢さから業務の完遂力へ移りつつあることを示しています。数学やプログラミングの問題を解く力はすでに高い水準にありますが、複数のシステムをまたいで仕事を終わらせる力は、まだ3割前後にとどまっています。この差が埋まっていく過程で、EC業務の自動化の範囲も段階的に広がっていくでしょう。
EC事業者にとって重要なのは、その日に備えて「自社の業務を測る物差し」を今から持っておくことです。手順1から3で作る業務の分解図、成功条件のチェックリスト、テストケースは、モデルが入れ替わるたびに使い回せる資産になります。新しいモデルが出るたびに同じテストを回せば、「自社の業務では何%成功するか」がすぐ分かり、乗り換えの判断にも迷いません。うるチカラではClaude Fable 5.1をECで使う｜キャッシュ75%減の効かせ方でも、費用面からモデルの使い方を整理しています。
よくある質問
AutomationBenchとは何ですか
AutomationBenchとは、業務自動化ツールの Zapier が開発した、AIが業務フローを最後まで完了できるかを測るベンチマークのことです。営業、マーケティング、オペレーション、サポート、経理、人事の6領域で、CRMやメール、カレンダーを模した環境を使い、最終的なデータの状態で成否を判定します。
31.4%は高いのですか、低いのですか
現時点では上位の成績ですが、業務を任せる水準としては低いと言えます。31.4%は10件中約3件しか最後までやり切れないことを意味します。複数のシステムをまたぐ業務は、AIが下ごしらえをして人が確認する分担を前提に設計するのが現実的です。
Fable 5からなぜ倍近く伸びたのですか
能力の向上に加えて、安全の仕組みによる過剰な遮断が減ったことが理由の1つです。Fable 5 では、安全の仕組みが介入した課題は0点として扱われていました。Fable 5.1 では問題のない依頼を止める場面が減ったとされ、その分が成績に反映されています。
EC事業者はFable 5.1を使うべきですか
いいえ、必ずしも最上位モデルである必要はありません。Fable 5.1 の公開後、Claude Opus 5.5 が同等の性能を約40%低い費用で出せると報じられています。自社の業務で作ったテストケースで複数のモデルを比べ、成功率と費用の釣り合いで選ぶのがおすすめです。
自社の業務でAIの実力を測るにはどうすればよいですか
業務を手順と判断に分解し、成功を最終状態のチェックリストで定義し、面倒な条件を含むテストケースを10件ほど作って試すのが基本です。成功率が9割以上なら抜き取り確認、5割から9割なら全件確認、5割未満なら操作は人が行う、という3段階で任せ方を決めると判断しやすくなります。
楽天市場やAmazonの業務にも当てはまりますか
はい、当てはまります。受注確認、在庫の引き当て、問い合わせ対応など、複数の画面やシステムをまたぐ業務ほど、AutomationBench が測っている難しさがそのまま現れます。モールの規約で外部ツールの利用や自動操作が制限されている場合もあるため、各モールの規約を確認したうえで検証してください。
まとめ
Claude Fable 5.1 は AutomationBench で31.4%を記録し、前のモデルから倍近く伸びました。ただし、これは最上位モデルでも業務の約7割を最後までやり切れないことを示す数字で、伸びの一部は安全装置による過剰な遮断が減った効果です。EC事業者がとるべき姿勢は、ベンチマークの順位でモデルを決めるのではなく、業務の分解、成功条件の定義、意地悪なテストケースという自社の物差しを作り、成功率に応じて任せ方を決めることです。最初の一歩として、毎日繰り返している業務を1つ選び、プロンプト1で手順と判断のポイントに分解するところから始めてください。
参考文献
- Zapier・Introducing AutomationBench
- Vellum・Claude Fable 5.1 & Claude Mythos 5.1 Benchmarks Explained
- The Decoder・Anthropic’s Claude Fable 5.1 promises better coding and research at up to 45 percent less
- DeepLearning.AI The Batch・Fable Holds The Top Spot (For Now)
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
