Amazon Science、AI エージェントの業務手順評価ベンチマーク「SOP-Bench」を公開
本文の状態
日本語全文を表示中
詳細モードで約13分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Amazon Science
Amazon Science は、AI エージェントが実務手順(SOP)を実行する能力を評価するためのベンチマーク「SOP-Bench」を発表し、既存のテストでは捉えきれない文脈理解や判断力を測定する。
AI深層分析を開く2026年8月22日 02:01
AI深層分析
キーポイント
SOP の複雑性とAIの課題
標準手順書(SOP)は簡潔に書かれているが、実際には暗黙知や状況に応じた判断を必要としており、これがAIエージェントの実行失敗の原因となる。
SOP-Benchの独自性
本ベンチマークは、ドメイン専門家による実在の企業手順と機能するツール、そして正解データを組み合わせた初の試みであり、単なるテキスト生成評価ではない。
既存ベンチの限界
現在の多くのエージェント用ベンチはAPI選択や制約遵守など単一能力に焦点を当てており、複雑な文脈下での計画実行能力を十分に評価できていない。
SOP-Bench の構成要素と特徴
SOP-Bench は曖昧さを残した現実的な手順、多様な業界の網羅性、実行可能なツール、および正解に基づく評価機能を統合している。このフレームワークは各タスクを手順テキスト、利用可能なツール、仕様、既知の答えを持つテストケースという4つの要素で構成する。
評価と検証の仕組み
エージェントがツールを呼び出して手順を実行し、その結果はモデルの意見ではなく正解データと比較して検証される。すべてのタスクの実行記録と推論プロセスが保持され、失敗した箇所を特定可能な形でスコアリングする。
重要な引用
SOPs are hard for AI agents to execute because they look cleaner than they actually are.
It is the first benchmark of its kind to pair genuine enterprise procedures with functioning tools and ground-truth answers
Rigorously measuring what agents can and cannot handle is essential for building assistive tools that genuinely help rather than silently fail.
It brings together elements that have previously appeared only separately: realistic procedures with the ambiguity left in, coverage across many different industries, working tools an agent can call, and a way to grade the result against ground truth.
編集コメントを表示
編集コメント
Amazon Science が公開したこのベンチマークは、AIエージェントの「実務適性」を測る新たな基準となる。既存の評価手法がカバーしきれない暗黙知の扱いや文脈依存タスクへの対策が、今後の研究開発の鍵となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
標準作業手順書(SOP: Standard Operating Procedure)とは、組織が重要な定型業務を毎回正確に同じように遂行するために策定された、一連の文書化された手順のことです。ほぼすべての業界で、この SOP が業務の根幹を支えています。
病院では新規患者の登録に、物流チームは荷物が危険物に該当するかの判断に、銀行は新規法人顧客の審査に、そして信頼と安全(Trust and Safety)チームはコンテンツ削除の可否を決定するためにそれぞれ SOP を活用しています。SOP には、組織が長年の経験から築き上げたノウハウやコンプライアンス規則、意思決定のロジックが凝縮されており、訓練を受けた者であれば誰でもこれを理解し、実行することができます。その結果、従業員やシフト、拠点の違いを超えて、業務の一貫性と安全性を維持できるのです。
しかし、AI エージェントにとって SOP の実行は容易ではありません。それは、SOP が実際よりも簡潔に書かれているからです。実際の業務手順では、読者は完全に明文化されていない指示を読み解き、業界で共有されている暗黙の知識を動員し、状況の変化に応じて臨機応変な判断を下すことが求められます。
例えば、患者受付の手順に関する以下の記述を考えてみてください。「ステップ4 と 6 で、オペレーターは患者の保険情報を確認する」とあります。しかし、どのように確認すべきか、あるいはなぜ 2 回も確認が必要なのかについては言及されていません。一方、受付業務に携わった経験のある者であれば、最初のステップが保険会社との被保険者資格の確認であり、2 つ目のステップが医療機関の管理システムへの患者情報の正確な入力確認であることを理解しています。
エージェントにはそうした背景知識がないため、ここで「検証」が何を意味するのかを推測し、手順の前半で何を行ったかを記憶し、ほぼ同じように見えるツールの中から選択する必要があります。これは、洗練されたデモ挙動が静かに崩壊する瞬間であり、多くのアジェンティックベンチマークでは決してテストされないような事象です。支援ツールの構築において、実際に役立つものを作り、静かな失敗を招かないためには、エージェントの能力と限界を厳密に測定することが不可欠です。
本日、私たちはドメイン専門家が作成した実際の標準業務手順(SOP)を AI エージェントがどの程度実行できるかを評価するオープンなベンチマーク「SOP-Bench」を発表します。これは、本物の企業手続きと動作するツール、そして正解データ(ground-truth answers)を組み合わせた初のベンチマークです。エージェントは、自動採点者が好むテキストを生成して点数を得るのではなく、手順を完遂することで評価されます。
私たちはこのベンチマークを 2026 年知識発見・データマイニング会議(KDD)で発表しました。その際、強力な基盤モデルでも足踏みしてしまう箇所を示す実験結果と、コミュニティが拡張可能な評価フレームワークも併せて紹介しています。
既存のベンチマークがなぜ不十分なのか
多くのエージェント向けベンチマークは、特定の一点において優れた性能を発揮します。あるものは、リクエストに対して適切な API を選択できるかを確認し、別のものは書かれた制約への準拠をテストし、さらに他のものは目標達成に向けた手順の計画能力を測定しています。
これらはいずれも価値ある要素ですが、それぞれが単一の能力に焦点を絞り、実際の人間が記した手順に見られる曖昧さやばらつきを排除した、機械が読みやすい形式のプロンプトでテストを行っています。しかし、SOP(標準作業手順書)を実行するには、これらすべてのスキルに加え、相互依存するステップ間で複数のツールを協調して使いこなし、これまでの進捗を追跡し、予期せぬ事態が発生した際に復旧する能力も必要です。
これまでにも、より現実的なビジネス手順に近づけようとする取り組みはありましたが、限界に直面しました。一部の試みでは文書化された手順を実行可能なワークフローに変換していますが、対象となるのは狭い分野の短い記述に限られており、背後にあるデータセットも公開されないことがほとんどです。また、実際のビジネス手順を収集して公開する取り組みもありますが、テキスト段階で止まっており、エージェントが手順を実行しその成果を検証するために必要なツールや正解情報が用意されていません。
SOP-Bench はまさにこのギャップを埋めるために構築されました。これまで別々に存在していた要素——曖昧さを残した現実的な手順、多様な業界への対応範囲、エージェントが呼び出せる実働中のツール、そして正解との比較による評価方法——を一つにまとめました。私たちが開発した SOP-Bench は、実際の業務手順を実行可能なタスクへと変換します。医療受付、危険物分類、カスタマーサポート、コンテンツモデレーション、金融コンプライアンス、倉庫検査など 12 のビジネス領域を網羅し、総数は 2,000 を超えるタスクを含んでいます。
各タスクには、エージェントが使用する必要があるツールインターフェースと、正解となる出力結果が含まれています。エージェントはツールの呼び出しを通じて手順を実行し、その成果物はモデルの主観的な評価ではなく、実際の正解(ground truth)と比較して検証されます。
SOP-Bench は固定されたタスクセットというよりも、拡張可能なフレームワークです。このフレームワークには2 つのベースラインエージェントが用意されていますが、チームは独自のエージェントを簡単に組み込み、含まれる手順でテストしたり、新しい手順を追加したりすることが可能です。その理由として、各手順は以下の 4 つの要素だけで構成されているからです。
- SOP(標準作業手順書)テキスト
- エージェントが呼び出せるツールのリスト
- それらのツールの仕様定義
- 正解が既知であるテストケースセット
このフレームワークはすべてのタスクを実行し、各意思決定の背景にあるツール呼び出しと推論プロセスを完全に記録します。そして、既知の正解に対して結果を採点します。得点は再現可能であり、失敗が発生した具体的なステップまで遡って追跡可能です。
実務的には、この仕組みにより、チームは本番環境に導入する前に、独自のエージェントを独自の手順で試すことができます。業界横断的な現実的な SOP を構築するのは容易ではありませんが、ここには Amazon の強みがあります。Amazon には、関連分野の専門家が並行して作業できる体制があり、彼らはすでに業務内容を文書化された手順として残す文化を持っています。また、数千ものタスクを同時に実行するための十分なインフラも整備されています。
SOP-Bench を構築するにあたり、私たちは専門家と AI をペアリングし、回答の正誤判定は専門家に委ねました。
実務のワークフローから実際の業務手順を記述し、各タスクの文脈を設定しました。その後、Anthropic の Claude 3.5 Sonnet v2 モデルが、これらの手順を機械が実行可能な形式に変換する手間のかかる作業や、データスキーマ・モック API・ツール仕様書の作成、そして通常ケースとエッジケース、さらには明示的な失敗事例を意図的に混ぜ合わせたデータセットの生成を担当しました。生成されたすべての成果物は再度専門家に確認され、ロジックの妥当性検証、手順の修正、データのチェック、コードの実行による動作確認が行われました。どの段階でも機密情報や proprietary なデータは使用されていません。
私たちが得た知見として、関数呼び出し型エージェントと推論スタイルのエージェントという 2 つのシンプルな設計を、11 の最先端モデルでテストしました。これらエージェントは「最良のシステム」であることを主張するものではなく、他者が改善するためのベンチマークとしての役割を果たします。それでも、いくつかの明確なパターンが浮かび上がりました。
新しいモデルが自動的に優れているわけではないという驚くべき知見です。推論スタイルのエージェントにおいて、最新の Claude 4.5 ファミリーは、以前の Claude 4 ファミリーよりも低いスコアを記録しました。同じ設定で個別モデルを比較した場合も、同様の逆転現象が見られました。
プロダクション環境でエージェントを運用するチームにとって、最も重要なのは「単純なアップグレードが成功率を低下させる可能性がある」という発見です。これには明確な兆候がないため、問題を検出できる唯一の確実な方法は、実際に運用している手順に基づいたテストを行うことです。
ツールが増えすぎるとエージェントのパフォーマンスが悪化します。私たちは単一の動画アノテーション手順を対象に、2 つの異なるツールキットバージョンで実験を行いました。一方はタスクに必要な 6 つのツールのみを保持し、他方は同じ 6 つのツールに加え、有用性はないがそれらしく見える 20 の追加ツールを埋め込みました。その結果、必要なツールはすべて利用可能だったにもかかわらず、ツール数が多い環境では成功率がほぼ半分になりました。これは「機能は無料ではない」という教訓を示しており、デプロイ前にエージェントを準備する上で、タスクに合わせたツールの選別が重要な要素であることを意味します。
特定の構成がすべての場面で優位になるわけではありません。モデルとエージェントの組み合わせにおいて、ある手順では最良の結果を出したものが、別の手順では弱い選択肢となるケースが多々あります。手順間の性能差は顕著でした。最も簡単なタスクである「メールの意図によるトリアージ」では正答率が約 90% に達しましたが、最も難しい「運転動画内の物体アノテーション」では約 25% にとどまり、全体を通じて 3 倍以上の開きがありました。単一のベンチマークスコアに依存すれば、同じ構成が次のユースケースでどのように振る舞うかについて、チームはほとんど何も知ることができません。
エージェントの構築方法も、その内部で動作するモデルと同じくらい重要です。同じモデルを搭載した 2 つのエージェントを直接比較すると、推論スタイルのエージェントが平均的にはわずかに上回りましたが、13 回の手順実行のうち勝ったのはわずか 8 回でした。また、タスクあたりの所要時間は約 3 割長くなりました。
ある手順では明らかに一方のエージェントに有利で、別の手順では他方が有利になるなど、結果は手順の形状によって大きく異なります。したがって、エージェントを選ぶ際は単なる全体平均ではなく、手順そのものの特性を基準にするべきです。
なお、予想と反する一つの疑問が残っています。読み取りが大半を占め、意思決定が必要な箇所が数カ所しかない手順の方が、多くの意思決定を含む手順よりもエージェントにとって難易度が高いという結果でした。通常は複雑なロジックこそが難しい部分だと考えがちですが、ここではより長く、単純に見える手順の方がはるかに低いスコアとなりました。
読書の長さ自体が原因だとは主張していません。両方の手順にはツール数の違いなど、他の要因も含まれているからです。しかし、このベンチマークはまさにこうした疑問を検証するために作られたものであり、他チームにも一緒に検討してほしいと考えています。
これらの結果を総合すると、特定のモデルに対する最終判決を下すものではありません。これは、業界がまだ投資を集中させるべき領域を示した地図であり、ビジネスが依存する手続き的な業務において、単なる能力の高さが信頼性を保証するものではないことを思い出させてくれます。より実用的には、チームが人間の監督が不可欠な具体的なステップを特定するための手助けとなります。
AI の弱点が顕在化するのは、現実的な手順に対してツールを駆使して持続的に実行する際だけであり、そのため人間のオペレーターと並行して運用されるエージェントにとって、静的なスキルテストだけでは不十分です。
SOP-Bench への取り組みを開始するには、完全なベンチマークを GitHub と HuggingFace で公開しました。リリースには、12 の専門家による手順、生成されたツールとデータセット、2 つのベースラインエージェント、そして実行結果を正解と比較してスコアリングする評価コードが含まれています。
研究者やチームは、既存の手順で自社のエージェントを評価したり、私たちが採用した人間と AI を組み合わせた手法を用いて、ベンチマークを新たなドメインに拡張したりできます。特に、これまでカバーしていない業界の手順については特に関心を持っています。
今後は、同じ手順のより困難なバリアントや、画像・表を含む指示、途中でコンテキストを切り替える必要があるネスト構造を持つ手順も追加する予定です。
エージェントを開発している方、評価を行っている方、あるいは日常業務における AI の現状をより明確に把握したい方は、ぜひご協力とフィードバックをお寄せください。
原文を表示
A standard operating procedure, or SOP, is the written set of steps an organization follows to correctly complete an important piece of routine work the same way every time. Almost every industry runs on SOPs. A hospital uses one to register a new patient, a logistics team uses one to decide whether a shipment qualifies as hazardous, a bank uses one to verify a new business customer, and a trust and safety team uses one to decide whether to remove a piece of content. SOPs carry an organization's hard-won knowledge, its compliance rules, and its decision logic in a form that any trained person can adopt and follow. As a result, they keep operations consistent and safe across different employees, shifts, and sites. SOPs are hard for AI agents to execute because they look cleaner than they actually are. A real procedure asks the reader to interpret instructions that were never fully spelled out, to draw upon knowledge that everyone in the field already shares, and to make judgment calls as conditions change. Consider the following passage from a patient intake procedure: Steps four and six tell the operator to verify the patient's insurance, without saying how the verification should be done or why it needs to be done twice. Someone who has worked an intake desk, however, knows that the first step confirms the patient’s coverage with the insurer, and the second step confirms that the patient’s information is correctly entered into the medical provider’s management system. An agent has none of that background, so it must guess what verification means here, remember what it did earlier in the procedure, and choose between tools that look nearly identical. This is the kind of moment where polished demo behavior quietly falls apart, and it is the kind of thing that most agentic benchmarks never test. Rigorously measuring what agents can and cannot handle is essential for building assistive tools that genuinely help rather than silently fail. Today we are sharing SOP-Bench, an openly available benchmark that measures how well AI agents carry out real SOPs authored by domain experts. It is the first benchmark of its kind to pair genuine enterprise procedures with functioning tools and ground-truth answers, so that an agent earns its score by completing the procedure rather than by producing text that an automated grader happens to like. We presented the benchmark at the 2026 Conference on Knowledge Discovery and Data Mining (KDD), along with experimental results showing where even strong foundation models come up short and an evaluation framework the community can build upon. Why existing benchmarks fall short Most agent benchmarks do one thing well. Some check whether a model can pick the right API for a request; others check adherence to a written set of constraints; still others measure the ability to plan a sequence of steps toward a goal. All of these are valuable, but each one isolates a single capability and tests it with clean, machine-formatted prompts that leave out the ambiguity and variability of procedures written by actual people. Executing an SOP requires all these skills, along with using multiple tools in a coordinated way across steps that depend upon one another, keeping track of what has happened so far, and recovering when something does not go as expected. Past efforts to adhere more closely to real business procedures have encountered limits. Some translate written procedures into executable workflows, but only for short descriptions in narrow domains, and the datasets behind them are often not released publicly. Others publish collections of genuine business procedures but stop at the text, without the tools or the known answers that would let anyone run an agent through the procedure and check its work. That is the gap SOP-Bench is built to close. It brings together elements that have previously appeared only separately: realistic procedures with the ambiguity left in, coverage across many different industries, working tools an agent can call, and a way to grade the result against ground truth. What we built SOP-Bench turns real procedures into runnable tasks. It covers 12 business areas, including healthcare intake, dangerous-goods classification, customer service, content moderation, financial compliance, and warehouse inspection, with more than 2,000 tasks in total. Each task comes with the tool interfaces an agent requires and a correct outcome. An agent runs the procedure by calling tools, and we can validate its work against ground truth rather than against a model's opinion of it. SOP-Bench is a framework rather than a fixed set of tasks. It comes with two baseline agents, but a team can drop in an agent of its own, test it against the included procedures, and even add its own procedures. That's because each procedure is just four things: the SOP text, the tools an agent can call, the specifications for those tools, and a set of test cases with known answers. The framework runs every task, keeps a full record of the tool calls and reasoning behind each decision, and grades the outcome against the known answers. Scores are reproducible, and failures can be tracked back to the steps where they happened. In practice, this lets a team try its own agents on its own SOPs before trusting them in production. Constructing realistic SOPs that span industries is difficult, but it’s where Amazon has an advantage. It Amazon provides experts from all relevant fields working in parallel, a culture in which those experts already document their work as written procedures, and enough infrastructure to execute thousands of tasks simultaneously. To construct SOP-Bench, we paired experts with AI, while letting the experts determine whether an answer was correct. They authored the original procedures from real industrial workflows and set the context for each task. An Anthropic Claude 3.5 Sonnet v2 model then handled the slow, mechanical work of turning each procedure into something a machine can run and generating the data schemas, the mock APIs and tool specifications, the tool code, and datasets that deliberately mix ordinary cases with edge cases and outright failures. Every generated item went back to the experts, who confirmed that the logic held, corrected the procedures, checked the data, and ran the code to be sure it behaved. No proprietary or sensitive data was involved at any stage. What we found We ran two deliberately simple agent designs, a function-calling agent and a reasoning-style agent, across 11 frontier models. These agents are a baseline for others to improve upon rather than an assertion of the best possible system. Even so, a few patterns came through clearly. Newer is not automatically better The most surprising insight was that upgrading the model sometimes lowered performance. On the reasoning-style agent, the newer Claude 4.5 family scored lower than the older Claude 4 family. The same reversal held when we compared individual models on the same setup. For a team running agents in production, this is the finding that matters most, because a routine upgrade can lower the success rate with no obvious signal that anything changed, and the only reliable way to catch it is to test on the procedures the team actually runs. More tools can make an agent worse We took a single video-annotation procedure and gave the agent two versions of its toolkit. One held exactly the six tools the task required. The other kept those six but buried them among 20 extra tools that looked plausible but did nothing useful. Success nearly halved with the larger toolkit, even though every tool the agent needed was available. The lesson is that capability is not free, and trimming an agent's tools to fit the task may be a key component of getting it ready to deploy. No single setup wins everywhere No one pairing of model and agent came out ahead across the board, and the combination that performed best on one procedure was often a weak choice on another. The gap between procedures was wide. On the easiest ones, such as triaging incoming e-mails by intent, agents arrived at the correct answer approximately nine out of ten times, while on the hardest, such as annotating objects in a driving video, they were correct approximately one out of four times, a more-than-threefold gap across the suite. Trusting a single benchmark score would tell a team almost nothing about how the same setup would behave on the next use case. How an agent is built matters as much as which model runs inside it When we compared the two agents head-to-head on the same model, the reasoning-style agent came out slightly ahead on average, yet it won on only eight of the thirteen procedure runs in the comparison, and it took about a third longer per task. Some procedures clearly favored one agent and some the other, so the shape of the procedure, rather than a single overall average, should drive the agent choice. One open question remains and runs counter to what might be expected. A procedure that was mostly long stretches of reading, with only a couple of points where a decision had to be made, gave agents more trouble than one packed with many more decisions. The natural assumption is that complicated logic is the hard part, but here the longer, simpler-looking procedure scored far worse. We are not claiming that the length of the reading is the cause, since the two procedures differ in other ways as well, including how many tools they involve. But this is a question that the benchmark was built to help examine, one we hope other groups will examine with us. Taken together, these results are not a verdict on any single model. They are a map of where the field still needs to invest and a reminder that raw capability does not guarantee reliability on the kind of procedural work that businesses depend upon. More practically, they help teams identify the specific steps where human oversight remains essential. AI’s weakness on those steps surfaces only in sustained, tool-using runs against realistic procedures, which is why a static skills test is not enough for agents that are being deployed alongside human operators on procedural tasks. Get started with SOP-Bench We are releasing the full benchmark on GitHub and on HuggingFace. The release includes the 12 expert-authored procedures, the generated tools and datasets, the two baseline agents, and the evaluation code that scores an agent's runs against ground truth. Researchers and teams can evaluate their own agents against the existing procedures or extend the benchmark to new domains using the same human-and-AI method we used to build it. We are especially interested in procedures from industries we have not covered yet. We also plan to add harder variants of the same procedures, instructions that include images and tables, and procedures with nested structures that force an agent to switch context partway through. If you build agents, evaluate them, or want a clearer picture of where they stand on everyday operational work, we would welcome your contributions and feedback.
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み