Φ-Bench、85件の実世界インフラタスクでコーディングエージェントを評価――最高モデルでも総合スコアはわずか36.53%

新たに公開された[Φ-Benchの論文](https://arxiv.org/abs/2609.10226)は、自己言及的ともいえるエンジニアリング上の問いに答えようとしている。すなわち、大規模言語モデルは、自らの学習と推論を支えるソフトウェアスタックを改善できるのか、という問いだ。評価はTritonやCUDAのkernelを1つ生成することに限定されていない。システム研究と公開ライブラリをもとに85件のタスクを整理し、GPU kernel、分散学習、推論サービス、量子化、通信、チェックポイント、MoEルーティング、アテンションなど、9種類のインフラ領域を網羅している。

タスクは3段階に分かれる。55件のKernel Function Completion（KFC）では、対象の関数とインターフェースが指定される。20件のLong-Horizon Implementation（LHI）では機能のみが記述され、エージェントが変更箇所を自ら探す必要がある。10件のEnd-to-End Optimization（E2EO）では、システム上の目標と制約だけが与えられる。公開されている[プロジェクトページ](https://faibench.org/)によると、各問題はDocker環境で実行され、長期タスクでは複数回の修正が認められる。スコアは正確性、または参照実装に対する相対性能に基づいて算出される。これにより、評価は一度きりのコード補完ではなく、「既存システムを読み、ボトルネックを特定し、変更を加え、測定して再び反復する」という実際の作業に近づいている。

論文では8つの最先端モデルを評価した。加重総合スコアが最も高かったのはClaude Opus 5だが、それでも36.53%にとどまった。KFC、LHI、E2EOでは、それぞれ37.16%、21.60%、62.94%を記録した。実行軌跡の分析によると、より強力なモデルは一度に1つの変数だけを変更し、より安定したローカル検証環境を構築したうえで、失敗結果を探索範囲の絞り込みに活用する傾向があった。一方、性能の低いモデルは、ノイズの範囲内でハイパーパラメータ調整を繰り返すことが多かった。推論effortを引き上げても性能が単調に向上することはなく、GPT-5.6 Solは中間設定で特に不安定だった。

このベンチマークの価値は、パフォーマンスエンジニアリングにおけるコーディングエージェントの探索能力と実験設計能力を可視化した点にある。ただし、そのスコアを一般的なInfraエンジニアリングの生産性として直接解釈することはできない。性能の基準値はNVIDIA H20、または著者らのSapphire Rapids CPUを使って較正されており、ハードウェアを変更する場合はベースラインを再構築する必要がある。また、各モデルで使用されたエージェントフレームワークも完全には統一されていない。今後エンジニアリングチームが注目すべきなのは、第三者がランキングを再現できるか、そしてモデルが公開テストや特定のハードウェアにのみ適応していないかという点だ。