AIエージェントの「物理工学の最終試験」PLE、最高でも48.3%。GoogleとMercorが85課題を公開、安全チェックを全部通る成果物は41.3%だけ

まず初めに

教科書のテストでは90点を取るAIが、現場のフォルダを渡された途端に半分も取れない。渡されるのは綺麗な問題文ではなく、旧版の図面や途中の計算書や、要求が途中で変わったメールが詰まった61ファイル入りのフォルダだ。しかも採点は「だいたい合っている」では通らない。安全のチェックを1つでも落とせば、その設計は0点である。物理の世界の試験は、部分点のごまかしが利かない。AIの「賢さ」の物差しが、暗記勝負から実務勝負に移り始めた、という話である。

※個人の感想です

PLEとは何か

PLEは、AIエージェントが物理世界を作る仕事——高層ビルや電力網、コンピューターチップの設計につながる工学の実務——を最後までやり切れるかを測るために作られたベンチマークです。Googleによると、フロンティアモデルは学術系ベンチマークの多くで90%を超えるスコアを出すようになっていますが、それらは教科書式の問題や単発のツール呼び出し、小さく切り取られた設計問題が中心で、現場の技術者が受けるような、規範に適合し安全でコスト効率のよい設計を成果物として出せるかは測れていませんでした。

PLEの課題は全85件で、分野別の内訳は機械30件、電気27件、土木18件、構造10件です。課題の作り方は2通りあり、44件は実務の技術者がプロジェクトフォルダ、指示文、採点ルーブリックまでを作った専門家作成の課題、残る41件は技術者が最初の課題を設計し、エージェントのパイプラインが環境と採点器を組み立て、技術者が検証して難易度を上げた共同作成の課題です。

課題の中身——「現場のフォルダ」をそのまま渡す

各課題は、MercorのArchipelago環境の上に作られたコンテナ化されたプロジェクトフォルダの中で解きます。1課題あたり平均61ファイル、全体で5,170ファイルが含まれ、中身はPDF、スプレッドシート、メール、2DのCAD図面、3DのBIMモデル、改訂版の文書などです。エージェントはこれらを読み解き、適用される建築規範や物理的な限界を見つけ、計算を行い、有資格のレビュアーが審査する前提の成果物を出す必要があります。

Mercorの発表によると、エージェントにはインターネットアクセスが与えられず、制限時間は最大6時間です。フォルダには旧版の資料が「罠」として混ざっている場合もあり、難しさの相当部分は「そもそも何を解くべきか」を見極める段階にあります。分野ごとの課題例としては、機械分野の冷却ループ設計や干渉のない3D設備ホールの配置、電気分野の配電盤のサイジングとケーブルスケジュール、土木分野のキャンパス全体の区画整理とユーティリティ配置、構造分野の屋根デッキの設計などが挙げられています。

結果——50%の壁と、91%と41.3%の落差

GoogleとMercorは、14のフロンティアモデルを、Antigravity、Claude Code、Codex、Hermes、OpenCode、OpenHands、Piの7種類の公開ハーネスで測定しました。非公開のテストセット（Mercorの図表では56課題）では、全モデルが50%未満にとどまりました。Mercorの発表によると順位は次のとおりです。

モデル（実行構成）	非公開テストセットの平均スコア
Claude Opus 5.5（Claude Code）	48.3%
GPT 6 Astra	45.8%
Gemini 4 Argon	40.6%

首位のClaude Opus 5.5の構成は、1課題あたり平均2,700万トークン、平均63分を費やした、とMercorは報告しています。なお、この48.3%は非公開テストセットでの値です。論文側の全85課題での集計値とは対象が異なるため、本記事では混同しないよう分けて扱います。

もう1つの数字が、このベンチマークの性格を表しています。トップの構成は、共同作成の課題で個別の制約の91%を満たしました。それでも、成果物が安全・実現可能性のハードチェックをすべて通過したのは41.3%だけでした。つまり「だいたい正しい設計」と「そのまま通る設計」の間には、大きな段差があります。PLEでは、ハードチェックをすべて通過した設計だけが、コスト効率などの得点対象になります。

モデルとハーネスの影響の違いも示されました。モデル間のスコア差は最大で約50ポイントに広がる一方、同じモデルを別のハーネスで動かした場合の差は中央値で約3ポイントでした。ハーネスの選択は主に実行コストに効く、とGoogleは説明しています。ハーネスの1つであるAntigravityを含むGoogleのエージェント環境の動向は、Claude Opus 5.5とあわせて扱った記事でも整理しています。

参加方法——課題29件は誰でも試せる

Googleは、29件の公開課題、採点ツール、評価用コンテナをGitHubリポジトリで公開し、技術的な詳細をまとめた論文をarXivで公開しています。公開コンペティションはple-bench.comで開かれており、自分のエージェント構成を持ち込んで非公開テストセットでの評価を受けられます。Googleがスポンサーする13モデルは同社のサーバー上で無料で実行でき、賞の詳細は今後発表するとしています。

IT Postの見方

IT Postでは、PLEの面白さは「AIの弱点を、知識ではなく実務の作法の側に見つけた」点にあると考えます。旧版の図面を最新と取り違える、規範の版を確認しない、制約を1つ落として全体を通らなくなる——どれも人間の新人技術者がやる失敗とよく似ています。逆に言えば、この種の失敗は、モデルの賢さだけでなく、渡すフォルダの整理や検証の段取りといった、使う側の実務設計で減らせる部分でもあります。

もう1つは採点の考え方です。IT Postでは、安全に関わる成果物に部分点の発想を持ち込まなかったのは正しい線引きだと考えます。ソフトウェアなら90%の出来でベータ版として出せますが、建物や電力設備はそうはいきません。「個別の制約は91%満たしたのに、全部通った成果物は41.3%」という数字の落差こそが、AIエージェントを実務に迎える前に越えるべき壁の正体です。もっとも、これはGoogleとMercorという提供側の設計した試験での結果であり、課題の作り方自体が難易度を決めている点は割り引いて見る必要があります。

今後どうなりそうか

公開コンペティションのリーダーボードが動き始めれば、48.3%という数字がどこまで押し上がるかが見えてきます。あわせて、賞の詳細や、論文で示された評価の内訳が更新されるかも確認点です。

日本語の読者にとっての実用面では、PLEのような「フォルダごと渡して成果物を出させる」評価は、設計・開発の現場でエージェントを試すときの物差しとして転用できます。新しい公式情報が確認できれば、続報として整理します。