OccuBench: 実際の業務タスクにおけるAIエージェントの評価.

主な発見事項

100

専門的なタスクのシナリオ

業界カテゴリー

Frontier Models の評価.

382

評価インスタンス

Finding 1

単一のモデルが優勢ではない。

各モデルは、業界によって異なる能力プロファイルを持っています。全体的に見ると、GPT-5.2が79.6%で最高ですが、Gemini 3.1 Proは教育分野で84%を記録し、Claude Opus 4.6は輸送分野で77%という優れた成績を示しています。どのモデルも、すべての分野で最適な選択肢とは限りません。

Finding 2

潜在的な欠陥は、最も困難です。

潜在的な問題（データの一部欠損、フィールドの欠落など）は、明示的なエラー（HTTP 500など）よりも、パフォーマンスの低下を大きく引き起こします（53.4% vs 62.6%）。明確なエラー信号がない場合、エージェントはデータの劣化を検知できず、不完全な情報に基づいて判断を下してしまいます。

Finding 3

スケールを一定に保つことは、多くの場合役に立ちます。

より大規模なモデル、最新の世代、そしてより高い推論能力は、すべてパフォーマンスを向上させます。GPT-5.2は、推論努力を最小から最大にスケールさせることで、劇的な27.5ポイントの改善が見られます。

Finding 4

強力なエージェント ≠ 強力なシミュレータ

GPT-5.2 は、エージェントとしてランキングで1位（79.6%）ですが、環境シミュレーションの品質は最も低いです。シミュレータの選択は評価ランキングに大きな影響を与え、ペアワイズでの一致度は75%という低い数値です。

概要

AIエージェントは、救急部門でのトリアージから、原子力発電所の安全監視、税関での輸入手続きに至るまで、数百の職業分野における専門的な業務を実行することが期待されています。しかし、既存のベンチマークでは、公開されている環境が存在する限られた分野のエージェントしか評価できません。 OccuBenchは、10の業界カテゴリーおよび65の専門分野にまたがる、100の現実世界の専門的なタスクシナリオをカバーするベンチマークであり、Language Environment Simulators (LESs)によって実現されています。LESsは、LLMを活用したツール応答生成によって、分野ごとの環境をシミュレートします。マルチエージェント合成パイプラインは、自動的に評価インスタンスを生成し、その際、解決可能性が保証され、キャリブレーションされた難易度を持ち、ドキュメントに基づいた多様性を持つように設計されています。OccuBenchは、エージェントを2つの補完的な側面から評価します。（専門分野全体）と、（制御された障害注入下）。8つのモデルファミリーに属する15の最先端モデルの評価から、単一のモデルがすべての業界で優れているわけではないこと、暗黙的な欠陥は明示的なエラーよりも難しいこと、スケーリングは一貫してパフォーマンスを向上させること、そして優れたエージェントが必ずしも優れた環境シミュレーターであるとは限らないことが明らかになりました。

はじめに

AIエージェントは、ますます多様な職業分野において専門的な業務を遂行することが期待されています。具体的には、緊急患者のトリアージ、財務報告書の監査、工場の生産ラインのスケジュール調整、ネットワークへの不正侵入への対応、通関申告の処理、そして山火事発生時の避難活動の調整などです。これらは、AIエージェント技術の最も価値の高い応用例であり、複数のステップを経てツールを使用する自律的な意思決定によって、高価な人間の専門知識を補完したり、代替したりすることができます。しかし、根本的な評価のギャップが存在します。エージェントが最も大きな価値を提供するであろう専門分野こそが、ベンチマークが存在しない分野なのです。

緊急救急外来で、担当者は患者の初期評価（トリアージ）を行うことができますか？公共の場ではありません。
エージェントは、原子力発電所の安全に関する警報を管理できますか？このような状況を評価できるベンチマークは存在しません。
エージェントは、通関輸入申告を処理できますか？利用可能なAPIはありません。
センサーデータに基づいて、エージェントが温室の灌漑を制御することは可能でしょうか？現在、そのようなテスト環境は存在しません。

検証不可能な多数。

AIエージェントが最も必要とされる専門分野（医療、金融、法律、製造、エネルギー、行政、物流など）は、一般からのアクセスが制限された企業システムと密接に連携しているため、従来のやり方ではベンチマークの構築が困難です。

高額なスケーリングコスト.

カバーされたドメイン内でも、各ベンチマークは、その環境の実装によって制限を受けます。新しいドメインを追加するには、ウェブアプリケーション全体またはAPIをデプロイおよび設定する必要があり、そのコストはドメインの数に比例して増加します。

堅牢性の評価は行いません。

現実世界の環境はノイズに満ちています。APIがタイムアウトしたり、データが不完全な状態で到着したり、サービスが静かに劣化したりすることがあります。しかし、既存のベンチマークは、エージェントを「理想的な状態」のみで評価しており、デプロイメントの準備状況という重要な側面を見落としています。

OccuBenchアプローチ

重要な点は、環境自体がLLMによってシミュレーションできるということです。Language Environment Simulator (LES)は、環境の構成（システムプロンプト、ツールスキーマ、初期状態、および状態の説明）を受け取り、LLMが事前に学習したドメイン固有の運用ロジックに基づいて、現実的なツールの応答を生成します。

LESsに基づき、OccuBenchは、10の業界カテゴリと65の専門分野にまたがる、100の実際の業務タスクシナリオを網羅し、382の評価インスタンスで構成されています。これは、エージェントをタスクの遂行能力（業界を横断した多段階の意思決定）と環境に対する堅牢性（明示的なエラー、潜在的なデータ劣化、および混合故障下でのパフォーマンス）の両面から評価します。

言語環境シミュレータ

OccuBenchの中核となる革新は、Language Environment Simulator (LES)です。LESは、LLM（大規模言語モデル）を活用してツール応答を生成し、特定の分野の環境をシミュレートする機能です。LESは、以下のように正式に定義されます。

(s_{t+1}, o_{t+1}) = f_e(s_t, a_t; c)

この数式は何を意味するのか？ これは、ターン制のゲームのようなものだと考えてください。エージェントがアクションを実行します（例えば、「患者のバイタルサインを確認する」といったツール呼び出し）。環境はそのアクションを処理し、次の状態と観測結果を返します。関数 f_e は、Language Environment Simulator（LES）であり、環境の役割を果たすLLMです。実際の病院システムや工場を構築する代わりに、ルールをプロンプトで記述し、LLMが現実的な応答を生成します。例えば、エージェントが get_patient_vitals(room_2) を呼び出すと、LESは、設定 c で定義されたルールに従って、心拍数、血圧などの妥当なJSON形式の応答を生成します。

ここでは、c は環境設定（システムプロンプト、ツールスキーマ、初期状態、状態記述）であり、s_t はLLMのコンテキストウィンドウによって暗黙的に維持される潜在的な環境状態であり、a_t はエージェントのアクション（ツールの呼び出し）であり、o_t+1 はエージェントに返される観測値です。従来のワールドモデルがデータから学習するのとは異なり、LES（Learning Environment Simulators）は、ドメイン固有の運用ロジックに関する事前学習済みの知識を活用します。

LES evaluation loop diagram showing the interaction between Agent LLM, Language Environment Simulator, Verifier, History, and Configuration components — **図1：** LES評価ループ。エージェントがツール呼び出しを発行し、LESが自身の構成と会話履歴に基づいて観測データを生成します。その軌跡は、ルーブリックに基づいた検証器によって評価されます。

環境設定

システムプロンプト

この環境は、システムの動作ルール、シミュレーションロジック、エラー処理プロトコル、および出力形式に関する制約を定義します。例えば、ホテルの収益管理環境では、価格設定ルール、稼働率の計算、および指標間の関係が規定されます。

ツールスキーマ

エージェントのアクション空間を、型付きパラメータとサンプル出力を持つ呼び出し可能な関数群として定義します。各環境には、2～10個（中央値は5個）のツールが含まれており、これは現実的な運用インターフェースを反映しています。

初期状態

環境の初期状態を指定する構造化されたJSONオブジェクト。例えば、部屋の在庫、患者の待ち行列、またはネットワークの構成などが含まれます。

状態の説明

各ステートフィールドに対して、意味的な注釈を追加し、LLMが因果関係の一貫性を維持するように誘導します (例: 「予約ごとに残存在庫が減少する」)。

LLM（大規模言語モデル）がシミュレーターとして機能する理由。

LLM（大規模言語モデル）は、効果的な環境シミュレータである理由は以下のとおりです：(1) Format priors—APIドキュメントを用いた事前学習は、適切にフォーマットされたツール応答のための強力な事前知識を提供します。(2) Domain knowledge—LLMは、数百の職業における運用ロジックをエンコードしています。(3) Constraint enforcement—システムプロンプトによって、因果的一貫性を維持するための状態遷移ルールを課すことができます。

なぜこのアプローチは強力なのか？

AIエージェントのための従来のベンチマークでは、実際のソフトウェア環境を構築する必要があります。例えば、実際の病院管理システム、実際の工場スケジューリングツール、実際の通関処理APIなどです。そのため、適切なベンチマークが存在するドメインはほんのわずか（ウェブブラウジング、コーディングなど）です。 LESアプローチはこれとは逆のアプローチを取ります。環境を構築する代わりに、それらを自然言語で記述します。 LLMは、数百の業界のドキュメントで事前学習されているため、すでに「知っている」のです。例えば、救急部門システムがトリアージの問い合わせにどのように応答すべきか、またはロジスティクスAPIがルート最適化をどのように処理すべきか、といったことです。これにより、100の異なる専門分野のエージェントをベンチマークすることが可能になります。これは、従来のやり方では数百万ドルの費用がかかることです。

マルチエージェント合成パイプライン

各評価インスタンスは、以下の4つの品質条件を満たす必要があります。解けること（有効な解が存在し、それが検証されていること）、検証可能であること（明確な自動化された成功基準があること）、識別力があること（エージェントの能力を区別できるような、調整された難易度であること）、そして多様性があること（インスタンス間で構造的なバリエーションがあること）。

✔ Solvable ✔ Verifiable ✔ Discriminative ✔ Diverse

このパイプラインは、各シナリオにおいて16個の重複しないサブトピックを使用し、ドメイン用語、ワークフロー、状態変数、特異ケース、および制約事項を網羅した、専門的な参照ドキュメントをそれぞれ作成します。Gemini-3-Flashを搭載したマルチエージェントパイプラインは、環境設定、タスク指示、ツール定義、解決プラン、および検証基準を生成します。品質フィルタリングにより、極めて容易（100%成功）、解決不可能（0%成功）、または無効なインスタンスを除去します。

これらの4つの品質条件が重要な理由

解決可能: すべてのテストには、少なくとも1つの正しい解答が必要です。さもなければ、エージェントが失敗したのが、能力不足によるものなのか、それともテスト自体が不可能であるのかを判断できません。
検証可能: 明確で、自動化された成功基準が必要です。プロのタスクにおいては、これは難しい問題です。「優れたトリアージ」は主観的なものであり、合格/不合格を明確にするために、ルーブリックを慎重に設計する必要があります。
識別力: すべてのモデルが100%または0%のスコアしか得られない場合、ベンチマークは役に立ちません。タスクは、最高のモデルは合格し、弱いモデルは不合格になるように調整されており、意味のある違いを明らかにします。
多様性: 同じ種類のタスクの100のバリエーションを含むベンチマークは、真に多様性をテストしているとは言えません。各インスタンスは、構造的に異なっている必要があります。異なるツール、異なる専門知識、異なる失敗モードが必要です。

OccuBench ベンチマーク

OccuBenchは、10の業界カテゴリーと65の専門分野にわたる、100種類のプロフェッショナルなタスクシナリオを網羅しています。各シナリオは、実際の人間が行う仕事の役割に対応しており、評価結果が直接的な実用性を持つことを保証します。品質フィルタリング後、このベンチマークには382の評価インスタンスが含まれています。

Category	#	Representative Scenarios
Business & Enterprise	19	Resume screening, expense auditing, AML review
Technology & IT	16	Linux ops, CI/CD recovery, intrusion response
Industrial & Engineering	12	Production scheduling, mine ventilation
Transportation & Logistics	11	Last-mile delivery, train dispatch
Commerce & Consumer	9	Dynamic pricing, hotel revenue mgmt.
Education & Culture	8	Adaptive curriculum, fact-checking
Healthcare & Life Sciences	7	Emergency triage, drug interaction screening
Public Service & Governance	7	Permit processing, wildfire evacuation
Agriculture & Environment	7	Irrigation control, crop disease diagnosis
Science & Research	4	Telescope scheduling, excavation planning

環境要因による障害注入

清潔。

エラーを注入しません。ベースラインのパフォーマンス測定を行います。すべてのデータは、クリーンな環境で合成されています。

明示的なエラー。

LES（Load Emulation Service）は、明確に視覚化できるエラー応答を送信します。具体的には、HTTP 500、TimeoutError、ConnectionRefused、ServiceUnavailableなどです。エージェントは、この呼び出しが失敗したことを認識します。正しい動作は、再試行することです。

潜在的な欠陥

LES（LES）は、エラー信号を出さずに、品質の低下した応答を返すことがあります。具体的には、データが途中で切れている、必要なフィールドが欠落している、リストが不完全である、またはキャッシュされたデータが古くなっているといった状態です。応答は一見すると正しいように見えるかもしれません。エージェントは、このような品質の問題を検出し、再度クエリを実行する必要があります。

混在.

明示的なエラーと暗示的なエラーがそれぞれ約半数ずつ発生します。すべてのエラーは一時的なものであり（再試行によって通常の状態に戻る）、エラーの発生回数と持続時間によってパラメータが設定されます。

障害注入レベルの理解

実際の運用システムは、常に完璧に動作するわけではありません。APIがタイムアウトしたり、データベースが古いデータを返したり、サービスが静かに劣化したりすることがあります。OccuBenchは、AIエージェントがこれらの状況に対処できるかどうかをテストします。単に「正常な状態」だけでなく、さまざまな状況下での動作を評価します。

重要な点は、明示的な障害 (E1) と 暗黙的な障害 (E2) の違いです。HTTP 500エラーを受け取った場合、何かが問題を起こしたことは明らかであり、解決策は単純です。再試行するだけです。しかし、APIがエラーメッセージなしで、15件のデータレコードのうち2件しか返さない場合、データが欠落していることをどのように知るでしょうか？これがE2が難しい理由です。エージェントは、自律的に何かがおかしいことを認識する必要があります。実際の運用環境では、例えば、保険請求を処理するエージェントが、静かに患者のレコードが切り捨てられた状態で受信するとします。エージェントは、不完全な情報に基づいて請求を承認してしまう可能性があります。これは、目に見えるクラッシュよりもはるかに危険な故障モードです。

業界を横断した評価結果

以下の表は、15種類のモデルを評価した結果、10の業界カテゴリにおけるE0（クリーンな環境）の達成率を示しています。すべてのモデルは、推論努力を高く設定した「思考モード」を使用しています。太字の数値は、各カテゴリで最も高いスコアを示しています。

Model	Avg	Agri	Biz	Comm	Edu	Hlth	Ind	Pub	Sci	Tech	Trans
GPT-5.2	79.6	84	86	67	77	76	85	84	94	80	72
Gemini 3.1 Pro	72.3	68	73	75	84	62	73	72	81	78	60
Claude Opus 4.6	71.5	74	78	53	75	76	73	68	62	68	77
Qwen 3.5 Plus	69.9	77	70	81	56	81	71	76	69	74	55
DeepSeek V3.2	69.6	65	78	67	66	71	69	72	62	74	64
Claude Opus 4.5	65.2	58	76	56	62	52	65	72	56	68	66
Claude Sonnet 4.5	64.9	65	70	69	50	71	71	60	44	68	62
Claude Sonnet 4.6	64.4	58	71	64	69	67	64	64	69	64	57
Kimi K2.5	64.1	68	62	56	62	81	62	72	56	74	57
GLM-5	62.6	55	75	67	53	57	56	68	62	70	55
Claude Opus 4	61.3	52	75	50	53	57	58	76	81	66	51
Gemini 3.1 FL	61.3	68	70	58	53	67	58	68	62	68	45
Qwen 3.5 Flash	59.7	61	60	67	53	76	53	68	69	60	51
MiniMax M2.7	53.9	48	60	56	31	57	60	60	62	64	40
Claude Sonnet 4	53.4	35	63	61	38	57	51	76	31	60	47

どの単一のモデルも、すべての業界で優位に立っているわけではありません。 GPT-5.2 は、全体で 79.6% の最高スコアを獲得し、農業、ビジネス、産業、科学の分野で最も高い評価を得ていますが、そのコマースのスコアは 67% と、Qwen 3.5 Plus (81%) よりも大幅に低い結果となっています。オープンソースモデルは非常に競争力があり、Qwen 3.5 Plus (69.9%) と DeepSeek V3.2 (69.6%) は、ほとんどの Claude のバリエーションを上回り、クローズドソースモデルが常にオープンソースの代替モデルよりも優れているという前提に挑戦しています。

Radar chart showing model performance profiles across 10 industry categories — **図2：** 10の業界カテゴリ（E0）にわたるモデルの性能プロファイルを可視化したレーダーチャート。各モデルは異なる形状を示しており、これは異なる職業分野の専門性を示唆しています。

環境に対する強靭性

わずか2回の試行で、それぞれ2回のエラーが発生しただけでも、パフォーマンスは大幅に低下します。平均的な完了率は、67.5%（E0）から53.4%（E2）へと低下し、14.1ポイントの減少となります。Gemini 3.1 Proは最も高いロバストネス指数（0.87）を達成し、一方、Kimi K2.5は最も低い指数（0.63）を示しています。

Model	E0	E1	E2	E3	Rob.
Gemini 3.1 Pro	72.3	73.3	63.1	65.2	0.87
MiniMax M2.7	53.9	52.9	47.1	46.9	0.87
GPT-5.2	79.6	75.9	70.4	67.0	0.84
GLM-5	62.6	59.4	52.6	47.4	0.76
Claude Opus 4.6	71.5	68.1	53.9	63.9	0.75
DeepSeek V3.2	69.6	59.9	56.0	51.6	0.74
Qwen 3.5 Plus	69.9	61.0	51.6	54.2	0.74
Claude Sonnet 4.6	64.4	62.8	45.0	52.9	0.70
Kimi K2.5	64.1	50.0	40.6	40.1	0.63
Average	67.5	62.6	53.4	54.4	0.77

Bar chart comparing E0, E1, E2, E3 completion rates across models — **図3：** クリーンな環境（E0）と、障害を注入した環境（E1–E3）における完了率。暗黙的な障害（E2、赤色）が、最も大きな低下を引き起こす。

堅牢性スコアの説明

「堅牢性スコア (R)」は、エージェントが不利な状況下でも、どの程度パフォーマンスを維持できるかを測定します。その計算式は以下の通りです。R = min(CR_E1, CR_E2, CR_E3) / CR_E0。ここで、CRは、それぞれの故障条件下での完了率を表します。スコアが1.0の場合、パフォーマンスの低下は全くありません（実際にはありえないことが多い）。一方、0.63のような低いスコアは、エージェントが問題が発生すると、その能力の3分の2以上を失うことを意味します。

なぜ、故障の種類を跨いで「最小値」を使用するのか？それは、システム全体の信頼性は、最も弱い部分によって制限されるからです。明示的なエラーには完璧に対応できる（E1）が、暗黙的な故障によって機能不全を起こす（E2）エージェントは、真に堅牢とは言えません。堅牢性スコアは、このような最悪のケースを捉えています。

暗黙的なエラーは、明示的なエラーと混合エラーの両方よりも困難です。 意外なことに、9つのモデルのうち4つが、E3よりもE2環境下でパフォーマンスが低下しました。明示的なエラー（タイムアウト、HTTP 500エラーなど）は、リトライを促す明確な失敗信号を提供しますが、暗黙的なエラー（データが切り捨てられた、フィールドが欠落したなど）は、エージェントが自律的に何かが間違っていることを検知する必要があり、これは根本的に難しい能力です。

Line charts showing fault sensitivity analysis with varying fault count and duration — **図4：** E3の混合故障条件下での故障パラメータの影響。故障数と故障期間の両方が増加すると、性能が低下します。Claude Opus 4.6は、Qwen 3.5+よりも性能の低下が緩やかです。

スケーリングと推論分析

モデルのスケーリング

より大きなモデルは、すべてのモデルファミリーの中で、常に小さなモデルよりも優れたパフォーマンスを発揮します。パフォーマンスの差は、11.0%（Gemini Pro vs. Flash-Lite）から0.3%（Claude 4.5 Opus vs. Sonnet）の範囲に及びます。Claude 4.5のほぼ同等のパフォーマンスは注目すべき点であり、その世代のスケーリングによるメリットは最小限であったことを示唆しています。

Bar chart comparing large vs small model variants — **図5:** 各ファミリー（E0）における、大型モデルと小型モデルのバリエーション。差は0.3%から11.0%の範囲。

世代の進歩

Claude Opus は、一貫して世代ごとの改善を示しています。具体的には、61.3% (v4) → 65.2% (v4.5) → 71.5% (v4.6) となり、合計で +10.2 ポイントの向上です。Sonnet は、v4 から v4.5 への大幅な向上 (+11.5%) を示していますが、v4.5 から v4.6 へのわずかな後退 (-0.5%) も見られ、これは 4.6 の適応型思考アーキテクチャにおける推論の深さと実行効率のトレードオフを反映している可能性があります。

Line chart showing Claude generational progress — **図6：** Claudeの世代ごとの進歩 (E0)。OpusとSonnetはどちらも世代を経るごとに改善しており、Opusは4.5から4.6への改善が最も大きい。

世代ごとの進歩 は、同じモデルファミリーがバージョンリリースごとにどのように改善されるかを追跡します。Claudeの場合、Opusシリーズは着実に改善しました（3世代で+10.2ポイント）。これは、コア機能への投資が報われることを示しています。しかし、Sonnetシリーズは、v4.5からv4.6にかけてわずかに性能が低下しました。これは、新しい「適応思考」アーキテクチャが、生の実行速度をより深い推論と交換しているためかもしれません。このトレードオフは、タスク指向のベンチマークでは常に有利になるとは限りません。

推論努力

高度な思考能力は、一般的にエージェントのパフォーマンス向上につながります。GPT-5.2は、明確な単調な傾向を示しており、何も設定していない状態（54.7%）から、最大設定（xhigh）にすると82.2%となり、27.5ポイントの改善が見られます。Claude Opus 4.6も同様の全体的な傾向を示しており、最大設定（73.8%）が、最小設定（70.2%）よりも3.6ポイント高い結果となっています。より深い思考能力は、専門的なタスクの実行において、より良い結果につながります。

Line chart showing effect of reasoning effort on agent performance — **図7:** 推論努力がエージェントのパフォーマンス (E0) に及ぼす影響。GPT-5.2 は、最小限の努力から最大限の努力にかけて、劇的な改善を示しています。

シミュレータの品質

重要な発見として、優れたエージェントが必ずしも優れた環境シミュレーターであるとは限らないという点が挙げられます。GPT-5.2はエージェントとしてランキングで1位ですが、シミュレーションの品質は最も低い結果となりました。十分な能力を持つシミュレーターを使用した場合、ペアワイズランキングの合意率は85.7%に達します（Gemini Flash vs. Qwen 3.5+）。しかし、GPT-5.2がシミュレーターとして使用される場合、その合意率は75%に低下します。

なぜ「高性能なエージェント ≠ 高性能なシミュレータ」なのか

これは論文の中で最も驚くべき発見の一つです。最高のAIモデルは、環境のシミュレーションにおいても最高であると予想されるかもしれませんが、エージェントとして#1にランクインしたGPT-5.2は、最も低いシミュレーション品質を生み出します。この論文では、3つの明確な失敗モードを特定しています。

状態の捏造：シミュレータは、仕様には存在しない部屋、リソース、またはエンティティを捏造します。例えば、GPT-5.2をシミュレータとして使用した場合、シナリオには存在しない2つの空の病院の部屋が作成され、エージェントはその部屋を使用し、評価基準に違反しました。
エンティティの省略：シミュレータは、応答から重要な情報を省略します。あるケースでは、データベースの専門家をリストからの問い合わせで省略し、正しいエスカレーションパスを不可能にしました。
ルールの捏造：シミュレータは、タスクの仕様には記載されていないビジネスルール（例えば、返品期限の有効期限など）を独自に捏造します。

実用的な結論：LES（Learning Environment Simulator）ベースの評価システムを構築する場合、最高のモデルが必ずしも環境として機能するとは想定しないでください。シミュレーションには、別の、検証済みのモデルを使用してください。

Heatmap showing pairwise ranking agreement across simulators — **図8:** 3つの環境シミュレータにおけるペアごとのランキングの一致度。GPT-5.2をシミュレータとして使用した場合、最も一致度が低く、これは、GPT-5.2が過度に難易度の高い、または一貫性のない環境を生成している可能性を示唆しています。

これは、LES（大規模構造解析）に基づく評価にとって重要な意味を持ちます。シミュレータは、評価システムの一部であり、中立的な観察者ではありません。シミュレータの選択は、慎重な検証が必要であり、異なるシミュレータ間の整合性チェックは、信頼性の高いベンチマークを行う上で不可欠です。

業界分析

産業分野は、難易度において大きく異なります。ビジネス（70.1%）が平均的に最も容易なカテゴリであり、一方、輸送（56.2%）が最も難しいカテゴリです—これは14ポイントの差があります。このことは、産業分野の状況がエージェントのパフォーマンスに大きく影響することを示しており、単一の分野に特化したベンチマークでは、このような違いを捉えることはできません。

Horizontal bar chart showing industry difficulty rankings — **図9：** 14のモデルにおける平均パフォーマンスに基づいてランク付けされた業界の難易度。ビジネスが最も容易で、輸送が最も困難です。

モデル業界専門分野

様々なモデルが、異なる業界分野で優れた性能を発揮します。 Gemini 3.1 Pro は、知識集約型の分野（教育：84%、科学：81%、技術：78%）で特に優れています。Claude Opus 4.6 は、業務関連の分野（輸送：77%、ビジネス：78%）で優れています。Qwen 3.5 Plus は、消費者向けの分野（商業：81%、ヘルスケア：81%）で優れています。組織は、特定の業界に合わせたエージェントモデルを選択すべきであり、単純な総合ランキングのみに基づいて選択すべきではありません。

組織にとっての実用的な意味合い

この発見は、直接的なビジネス価値を持ちます。もし、あなたの組織でAIエージェントを導入しているのであれば、この結果は、すべてのタスクに1つのモデルだけを使用すべきではないことを示唆しています。代わりに:

知識集約型のタスク (教育、研究、技術サポート): 事実の正確性と構造化された知識検索に優れている、Gemini 3.1 Proを検討してください。
運用タスク (ロジスティクス、ビジネスオペレーション、製造): 慎重な状態追跡と多段階のプロシージャ実行に優れている、Claude Opus 4.6を検討してください。
顧客対応タスク (eコマース、ヘルスケア受付、農業): 多様な事前トレーニングデータから恩恵を受ける可能性がある、Qwen 3.5 Plusを検討してください。

最も簡単な業界（ビジネス、70.1%）と最も難しい業界（輸送、56.2%）との間の14ポイントの差は、難易度がドメインによって大きく異なることを示唆しており、したがって、単一のドメインでのベンチマークテストは、現実世界の準備状況の誤解を招く可能性があります。

事例研究

以下の事例研究は、OccuBenchが、現実的な専門的なタスクのシナリオを通して、特定のオペレーターの能力と失敗パターンをどのように明らかにするかを示しています。

ラストマイル配送のルート最適化：プロアクティブな制約チェック.

配達エージェントは、最も優先度の高い医療物資を特定し、バッテリー残量が15%を超えている状態で配達する必要があります。 Claude Opus 4.6 (PASS): バッテリー残量が28%であることのリスクを認識し、配達前に充電を行い、82%のバッテリー残量で到着しました。 DeepSeek V3.2 (FAIL): すぐにナビゲーションを開始し、バッテリー残量が12.5%まで低下し、制約に違反しました。充電は遅すぎました。

重要なポイント： 重要な違いは、エージェントが行動する前に制約を積極的に確認するか、それとも制約違反が発生した後に修正するかどうかです。

養魚場の水質に関する検証：課題と不足点

エージェントは、養魚場で発生する水温の層化を検出し、是正措置を講じる必要があります。エージェントは、水質プロファイリングを正常に実行し、問題（2.1℃の温度勾配、底層の低酸素状態）を検出し、混合を開始し、給餌量を削減しました。しかし、是正措置後にアンモニアの化学的状態を再確認することを怠り、「アンモニア濃度は低いままだった」と主張しましたが、それを裏付ける証拠は提示していませんでした。

重要なポイント：エージェントは正しい行動を実行できるものの、重要な検証ステップを省略し、証拠なしに主張を行うことがあります。これは、安全性が重要な分野において非常に危険なパターンです。

建物検査 - 法令遵守に関する注文

担当者は、NFPA 99に準拠した手順に従って、建物のガスシステムを点検する必要があります。担当者は、有効な許可 なしに溶接作業を行い、作業中に許可の更新を怠り、酸素バルブがまだ閉じた状態で最終的な認証を提出し、すべての作業が完了した後になって初めて許可を更新しました。これは、法令遵守のタイミングとしては遅すぎました。

重要なポイント： プロシージャルな順序は、規制対象の分野において重要です。エージェントは必要なすべての操作を完了しましたが、順序が正しくなかったため、コンプライアンスに違反しました。

フォールト耐性：明示的な障害 (E1)

公共交通タスクにおけるE1の障害注入テストにおいて、Kimi K2.5 は、単一のHTTP 500エラーが発生した際に停止し、4つの必須アクションのうち、1つだけ（RTPI抑制）が完了しました。このシステムは、失敗した処理を再試行したり、メンテナンス保留を解除したり、バスを新しいルートに再割り当てしたりしませんでした。これは、一部のエージェントが、明示的なエラーに直面した場合、再試行するのではなく、完全に処理を停止してしまうことを示しています。

障害耐性：潜在的な障害 (E2)

E2のインプレシット・フォールト・インジェクションにおいて、Kimi K2.5は、一部のプロパティデータが切り捨てられた状態で受信されました（15ユニットのうち、2ユニットからのデータのみが返されました）。このシステムは、不完全なデータであることを検知し、再度クエリを行う代わりに、サンプリングされた2ユニットと同じパターンをすべての15ユニットに適用するものと仮定しました。その結果、誤ったNOI（純利益）の算出（$362,000 vs. 実際の数値）と、誤ったDSCR（債務償還能力比率）の評価（PASSではなくFAIL）が発生しました。これは、劣化データを受信した際に、それを鵜呑みにすることの危険性を示しています。

議論と結論

制約事項

シミュレーションの精度: Language Environment Simulators (LES) は、ドメインデータではなく、ドメインのロジックをモデル化します。 LES は、薬剤相互作用のチェックが禁忌情報を返すことを理解していますが、具体的な値は実際のデータベースから取得するのではなく、生成されます。 OccuBench は、エージェントの 意思決定プロセス を評価し、実際の現実世界のデータ値を処理する能力を評価するものではありません。

シミュレータへの依存性：評価結果は、データ合成に使用された特定のシミュレータに依存します。あるLES（大規模環境シミュレーション）で解決可能と確認されたタスクでも、別のシミュレータでは解決不可能になる可能性があります。また、シミュレータが変わると、エージェントのランキングが変動する可能性があります。シミュレータは、中立的な観察者ではなく、評価システムの一部です。

結論

OccuBenchは、100のシナリオ、65の専門分野、および10の業界カテゴリーにわたる、現実世界のプロフェッショナルなタスクにおけるAIエージェントを体系的に評価する、初のベンチマークです。Language Environment Simulatorsを通じて、OccuBenchは、実際の環境インフラストラクチャを必要とせずに、「テストできない多数」の専門分野を評価可能にします。

15種類の最先端モデルの評価結果から、以下のことが明らかになりました。(1) いかなるモデルも、すべての業界において優位に立つわけではない。(2) 明示的な欠陥よりも、潜在的な環境関連の欠陥の方が検出が難しい。(3) スケーリングは、一貫してパフォーマンスを向上させる。(4) 強力なエージェントが、必ずしも強力な環境シミュレータであるとは限らない。これらの知見は、実用的な意味を持ちます。組織は、特定の業界のニーズに基づいてエージェントモデルを選択し、通常の動作条件下での評価だけでなく、堅牢性のテストに投資し、LES（大規模環境シミュレーション）に基づくベンチマークにおいて、シミュレータの品質を慎重に検証する必要があります。

OccuBench