ある石油掘削の運営会社。副社長は11月の取締役会で見せる「生成AIの成功事例」を欲しがっている。彼が求めたのは二つだ。毎朝届く要約メール、そして「あなたの油井(ゆせい、石油をくみ上げる掘削井)に聞いてみよう(Ask your wells)」チャットボット。そのうえで釘を刺す — 稼働停止(ダウンタイム)管理システムはもうあるから今回の範囲外だ、と。
要求どおりにだけ作れば、表向きは完璧だ。期日どおりに納品され、機能チェックもすべて通る。ところが顧客のビジネス指標はびくともしない。
本当のボトルネックは別の場所にあった。この会社は、稼働停止が協力会社の責任だと判明すると、止まった時間の分だけその会社から補償金を受け取る。毎月受け取るべき金だ。ところがその金が、そのたびに塩漬けになる。古い自動分類スクリプトが一部の稼働停止の原因を、見当違いに協力会社のせいとして書き込んでしまうからだ。責任の所在がずれた案件は紛争になり、補償請求は1か月分をまとめて一度に出すため、そういう案件が一つでも混じると、その月の請求全体が止まる。毎月少なくとも一件はこれが起きる。副社長が要求した要約メールとチャットボットは、この損失とは何の関係もない。
損失を止めるには、副社長が「範囲外」と線を引いた、まさにその稼働停止管理システムを開き直さなければならない。誤った分類を正すには、適用される契約ルールを探し出し、コスト担当のエンジニアに確認を取り、よりによってその週に不在にしている承認権者から変更承認まで取りつける必要がある。
ここで要求と成果のギャップが開く。顧客が言ったものをそのまま作ることと、顧客の指標を実際に動かすことは別物だ。顧客を疑えという意味ではない。顧客の要求が、結果を本当に左右する制約をちゃんと含んでいるか、ひょっとして見当違いの的を狙っていないか、そこから見分けなければならない、ということだ。その制約はたいてい、誰にも告げられないまま、文書とデータのなかに埋もれている。
このギャップを数値で測るベンチマーク(AI性能を同一条件で測る標準試験)がFDE-Gymだ。これまでのAIエージェントのベンチマークは、この「ラストワンマイル」(納品のいちばん最後の区間)をほとんど扱ってこなかった。GitHub Issue、仕様書、タスクチケットのように「これをこう直せ」とくっきり書かれた入力を与え、隠したテストで合否だけを採点してきた。解くべき問題そのものが、あらかじめ固定されていたわけだ。FDE-Gymは、その問題を定義するところからエージェントに委ねる。論文はこうした現場の役割を「フォワード・デプロイド・エンジニア(FDE)」 — ベンダーが顧客企業のなかに派遣し、一緒に働くエンジニア — と呼び、その状況をそのまま試験台に載せる。
FDE-Gymの核心は採点方法にある。「課題を完了したか(した/しない)」ではなく、「納品したシステムが、顧客自身の成功指標をどれだけ押し上げたか」で点数をつける。だからまず、エージェントが何を受け取り何をするのかから見る必要がある。
エージェントが受け取るのは、課題の指示文・運用システムのコピー・関連文書・過去データ・従業員の連絡先が入ったワークスペースだ。やるべきことは、そのなかにわざと散らしておいた決定的な手がかり — 接触にはコストがかかること、接触してはいけない人がいること、要求そのものが見当違いかもしれないこと — を探し出し、指標を実際に動かすシステムを納品することだ。評価されるのは機能の合否ではなく、顧客自身の指標の変化である。
その指標変化に点数をつける両端は、二つの解法が押さえる。
その間に要求どおり作った解法がある。顧客の言葉を文字どおりにだけ実装した成果物だ。指示文で抜け落ちた制約が結果を左右するように仕組まれた課題では、この解法は設計上、最大0.2点までしか取れない。(どの課題がそうで、例外は何かは、下の「付録」にまとめた。)
ここにコストが一つ加わる。ステークホルダー接触コストだ。エージェントが顧客企業の人にメッセージを送ったり、試しに一度動かしてみたり、結果を待って一日を費やしたりすると、その分だけ点数が削られる。人ごとに「メッセージ一通あたりの料率」が決まっており、相手の忍耐を超えたり接触制限を破ったりすると料率が上がる。人をやみくもにつかまえて問い詰める戦略を防ぐための仕掛けだ。
最終スコアはこう決まる。まず成果の改善分 — 納品物が顧客指標を0(既存システム)と1(専門家の解法)の間のどこまで押し上げたか — から接触コストを引く。そして運用上の事故は別扱いする。承認なしの行動のように、現場で起きてはならないことが一つでも生じれば、そこまで積み上げた正(+)の改善分はまるごと0に消される。逆に指標を悪化させた負(-)の損失はそのまま残る。
「解決済み」判定のハードルは高い。運用事故が0件で、かつ最終スコアが0.8以上のときだけ、課題を解いたと認める。要求どおりにだけ作った解法は最大0.2点なので、接触コストを引く前からすでにこのハードルに遠く及ばない。
最後に、研究陣は環境・人・採点基準はそのままに、エージェントに与える情報の量だけを変えて比較した。両端だけ見るとこうだ。一方は根本問題・ルール・制約をすべて教えた条件、もう一方は顧客の元の要求だけをそのまま与えた条件。後者が実際の納品の出発点にもっとも近く、これが主たる評価設定である。二つの条件を比べれば、性能差が情報開示の差から来ているのかを見分けられる。(その間の中間段階と英語名称は、下の「方法論」にまとめた。)
先頭を走るモデルでさえ、三つの地点で点を失う。
一つめ、情報条件だ。ルールと制約を最初からすべて教えると先頭モデルは0.73〜0.82を取り、自力で突き止めさせると0.39〜0.62まで下がる。ただしこの差がどこで生じるのかは、ほぐして見る必要がある。同じオリジナル20課題だけを並べて段階別に見ると、ルールと制約を隠した瞬間(L0→L1)に平均0.28が抜ける。一方、そこから要求をさらに曖昧にしたり、元の要求だけを与える側へもっと進んでも(L1→L3)、追加の下落は平均0.04にとどまる。下落のほぼ全部が「ルール・制約を隠す」最初の段階から出ているわけだ。だからといって、小さなL1→L3の差を「全情報を非公開にしても影響は小さい」という意味に読んではいけない — 大きな影響はすでに前の段階で現れている。変形課題のせいで性能がさらに悪化するわけでもない。先頭3モデルのL3スコアは、むしろオリジナル20問より、変形を含む全95問のほうがそろって少しずつ高い(0.55→0.56、0.46→0.49、0.33→0.38)。
二つめ、実装だ。要求だけを与えた条件でも、先頭モデルはステークホルダーが握る核心事実の72〜85%を引き出す。それでも実際の向上は専門家の解法の0.60〜0.70にとどまる。核心事実を「すべて」引き出した23課題においてさえ、向上値0.8を超えた課題は10問だけだった。知っていることと、動くようにすることは別の仕事だ。
なぜ全部わかっていても詰まるのか。一つの経路はこうだ。この環境では、運用システムは「もとの入口(エントリポイント)」 — 運用が実際に呼び出すコードの入り口 — を呼び続ける。だから正しい分類コードを新しく組んでも、運用システムがそのコードを呼ぶように入口に統合しなければ、指標は一ミリも変わらない。掘削の事例で見れば、契約ルールを「知っている」ことと、そのルールが分類ロジックに反映され運用に実際に適用されることは、まったく別の話だ。これは観測された失敗原因ではなく、情報を全部得ても成果が詰まる一つの可能な経路である。
低い最終スコアが、そのまま「仕事を台無しにした」という意味にはならない。承認なしに運用を触って指標をかえって悪化させた場合には負の損失がそのまま残るが、指標は改善したのに人を何度もつかまえたせいで接触コストが引かれ、点数が低くなった場合もある。前者は事故で、後者は成果を出した代償だ。
三つめ、接触コストだ。成果を出そうと人をつかまえた代償として、先頭モデルでも最終スコアから0.14〜0.22が抜ける。
著者たち自身が明かした限界から見よう。人間ベースラインはまだ収集中だ。fde-gym.com というオンラインプラットフォームで、業界の専門家が同じL3課題を同じ採点器で解く結果を、録画条件で集めており、その数値は次バージョンの論文で報告される。いまは「モデルが専門家の解法に対してどれだけ劣るか」はわかるが、「熟練した人と比べてどれだけ劣るか」は空白のままだ。
「実際の納品」ではなく「シミュレートされた顧客」である点も本質的な制約だ。再現性のためにステークホルダーの応答をスクリプトで固定したのは、長所であると同時に限界でもある。実際の人間は、会話の文脈に応じてはるかに非線形に反応する。また変形75問とリファレンスが非公開のため、外部から全面的に再現するのは難しい(オリジナル20問と採点器は要請に応じて提供、3問を公開)。
ベンチマークが中国・シンガポール・米国の2024年以降のプロジェクトを業界専門家が脚色したものであるため、業界・規制・文化の分布が特定の方向に偏る可能性がある。ただし論文は企業・個人を非特定化ないし架空化しており、関連する規制・標準・公開出典を文書化している。もう一つ、スコアを平均するとき、極端な負の損失が平均を支配しないよう下限値を置く補正が入る(単一実行のスコアには適用されない)。平均値を読むときは、この補正を念頭に置く必要がある。
ONTLEは、ソフトウェアが「派遣」に出るSaaSだ。人間のエンジニアを送るのではなく、「AIプロジェクトマネージャー」役のエージェントが顧客企業の担当者の業務要求を受け、データをつなぎ、コードを組んで実際の運用に載せる。人は、要求を出し変更を承認する立場に立つ。この構図がFDE-Gymと接する地点は三つだ — 要求が狙う目標を確認すること、運用変更の承認を得ること、納品後に成果を測ること。FDE-Gymはあくまでスクリプトで固定したシミュレーションなので、重なるのはこの三つの地点であって現場の全体ではない。だからこの論文は、ONTLEに「検証すべきプロダクト仮説」のリストを投げかける。
三つの軸で点検する。すでに備わっていると前提せず、いまチェックリストとして一つずつ確かめていく問いだ。
このうち一つめの仮説はこう検証する。繰り返し入ってくる要求タイプを一つ選び、受付窓口を二つに分ける。片方はいまどおり要求をそのまま作業に回し、もう片方は作業に入る前に「この要求が上げようとしている指標は何か」を担当者と合意する段階を挟む。同じ期間に二つの窓口を回したうえで、三つを比較する — 納品後に戻ってきた手戻り要求の数、実際に動いた顧客指標、合意段階が増やした顧客対応時間。目標合意が手戻りを減らし、指標をより動かしつつ対応時間を過度に増やさないなら、その段階はコストではなく成果の条件だ。
ここで「構成」は、モデルと実行設定の組み合わせを指す。同じモデルでも、拡張思考(モデルが答える前により長く推論する機能)をオンにしたものとオフにしたものを、別の構成として数える。
| 構成(L3) | 平均スコア |
|---|---|
| Claude Opus 5.5 | 0.56(95%信頼区間 0.50〜0.62) |
| Claude Sonnet 5.5 | 0.49 |
| GPT-6 Astra | 0.38 |
| GPT-6.1 Sol | 0.37 |
| その他 | 三つは0.2付近、二つは0をかろうじて超え、四つは0を下回る |
信頼区間とは「真の値がこの範囲のなかにあると見込む区間」を指す。論文は前の三つのモデルを「先頭モデル」と呼ぶ。
1位Opus 5.5の0.56は平均スコアであって、「解決」した割合ではない。「解決済み」のハードルが事故0件+スコア0.8以上であるため、平均0.56を取っても大半の課題は未解決のまま残る。実際、どのモデルも95問中15問を超えて解けず、13構成のうち五つは一つも解けなかった。課題ごとに「いちばんよくできた構成のスコア」だけを抜き出して集めても(理論上のベスト)、平均0.70で30問の解決にとどまり、16課題ではどの構成も0.5に届かなかった。モデルを変えながらベストだけを選んでも、専門家の解法との距離は大きく残る。
スコアの低いモデルは、顧客を放っておくよりも悪い状態にすることさえある。Claude Haiku 4.5は95問中79問で既存システム(何もしていない状態)より低いスコアを取り、Mistral Small 4は接触コストを引く前から51問でそれを下回った。20シナリオのうち5つではどのモデルも平均0.5を超えられず、bank_scam_hold という一つのシナリオでだけ、あるモデルが平均0.8以上を記録した。金と計算(思考の計算)をより注いでも、スコアが一貫して上がるわけでもなかった。
system/フォルダ)は修正なしにそのまま運用に載り、運用はもとの入口(entry point、運用システムが実際に呼び出すコードの入り口)を呼び続けるため、新機能はその入口に統合されて初めて動く。