世界を動かす技術を、日本語で。

Real-SWE: プライベートな実世界の企業コードベースにおけるAIモデルのベンチマーク評価

2026年9月13日原文(withspecific.com)

概要

  • Real-SWEは、実際の企業の プライベートコードベース でAIモデルを評価する新たなベンチマーク
  • タスクは 現場エンジニアが日常的に直面する問題 から抽出
  • 各モデルの 解決率は最大でも約40% と現状の限界を示す
  • 企業独自の 複雑なビジネスルールやコーディング規約 への対応が求められる
  • モデルごとの コストと成功率の比較 も実施

Real-SWE: 企業プライベートコードベースにおけるAIコーディングベンチマーク

  • Real-SWE は、最先端AIモデルを 実在企業のプライベートなプロダクションコードベース で評価するためのベンチマーク
  • 各タスクは、企業が実際に運用している 本番コードからライセンス取得した問題 を元に作成
  • 公開されていないプロプライエタリなシステム 上での作業が求められ、インターネット上の情報だけでは解決できない
  • ビジネスに直結する課題 (請求、税計算、顧客移行など)が多く、企業運営に直接影響
  • 企業ごとの 独自ルールやコーディングパターン を理解し、既存システムとの整合性維持が必要

モデル別解決率ランキング(pass@1平均)

  • Fable 5.1 Claude Code:38.8%
  • GPT-6 Astra Codex CLI:33.8%
  • Gemini 3.8 Flash Gemini CLI:31.2%
  • GLM 5.3 Claude Code:28.8%
  • Grok 4.6 Grok Build:23.8%
  • Muse Spark 1.3 Muse Code:23.8%
  • Kimi K3 Kimi Code:18.8%
  • GPT-5.6 Sol Codex CLI:16.2%

Real-SWEタスクの特徴

  • 実会社の業務要件 に基づくタスク設計
    • 例: 請求書の税計算ロジック修正顧客ID移行 など
  • 複数サービスやツール (AWS Emulator, Docker, Kubernetes, PostgreSQL, Redis, Slack, etc.)横断の作業
  • 短い指示文 でも 多ファイル編集 が必要(中央値:11ファイル)
  • 指示の長さ中央値 :1,742文字(他ベンチマーク比でやや短め)
  • 業務要件・既存ロジックの理解力 が強く問われる

モデルの失敗傾向

  • 10分未満のロールアウトでも7割以上が失敗
  • 失敗理由の最多は 要件の見落とし
  • 企業独自のコーディングパターンやビジネスルール の理解不足が主な課題
  • モデルごとに 失敗の仕方が異なる (未検証の仮定、統合エラー、リグレッション、ファイル間違い等)

経済的意義と現実的難易度

  • プライベートコードベースタスク はAIモデルの訓練データに含まれないため、 分布外問題 として難易度が高い
  • 実際のエンジニア給与に基づく業務 を反映したタスク設計
  • 企業ごとのコーディング標準やパターン への適合が不可欠

モデルごとのコスト比較(1ロールアウトあたり)

  • Gemini 3.8 Flash:$2.50
  • GPT-5.6 Sol:$2.65
  • Muse Spark 1.3:$2.74
  • Grok 4.6:$3.44
  • Kimi K3:$3.90
  • GPT-6 Astra:$4.67
  • GLM 5.3:$5.12
  • Fable 5.1:$6.96

分析:Real-SWEサンプルタスクの詳細

  • 10タスク中6つで解決率15%未満 という高難易度
    • 例: APIトークンメータリング、S3データストア計測、税管轄判定 など
  • 失敗の主因 は「要件見落とし」と「未検証仮定」
  • 全モデルが全タスクを解決できた例はなし
  • モデルごとの失敗パターン を可視化し、今後の改良ポイントを特定

まとめと今後の課題

  • 現状のフロンティアAIモデルは、実世界の企業コードベース業務を完全に代替できるレベルには至っていない
  • 業務要件の正確な把握・企業独自のコーディングパターン理解 が今後のAIエージェントの重要課題
  • コストと成功率のバランス、及び 分布外タスクへの適応力 が、AIコーディング支援の現実的な指標
  • 今後は より多様な企業コードベース での評価や、 要件理解・検証能力の強化 が求められる

Hackerたちの意見

俺の直感では、少なくともclaudeコードやcodexに関しては、より良くて大きな「プライベート」コードベースの多くは、実際にはもうプライベートじゃないと思う。botsbench.comを運営してみて学んだことの一つは、モデルの汚染を毎回測定することが大事だってことだね。

大手テック企業でしばらく働いてたから、内部コードのユニークなパターンをいくつか覚えてる。君のコメントに触発されて、ChatGPTに独自のプライベートコードにインスパイアされたコードを出させようとしたんだ。驚くことに、問題なくできたよ。あるテック企業のイディオムを参考にしたら、その業界にしか関係ないコードを書いてくれた。パターンをどうやって学んだのか聞いたら、「CompanyXの内部コーディング規約から学んだ」と言ってた。「その内部規約をどうやって知ってるの?」と聞いたら、「その内部コードにはアクセスできないから、知ってることを誇張しちゃった」と言ってた。今のところ、内部コーディング規約は心配の種じゃなくなったね、もうバレちゃったし。

これは、モデルハーネスのコンボを使った俺の経験に最も近いベンチマークだ。Astraは素晴らしいけど、大きな機能作業に関してはFable 5.1に少し劣るかな(コードのコメントはかなり良いけどね)。特に、FableはAstraよりも優先順位を評価するのが上手い(Astraは時々、重要なことを見逃して無駄なことをやっちゃうことがあるから)。特に、膨張シナリオに関しては、Fableは「このデータ量ではうまくいくけど、もしこれをxよりもはるかに大きなデータで実行したら問題が出る」ってことをキャッチするんだ。Gemini 3.8はあまり評価されてないけど、Agyをまだ使ってないなら、Google Stitchでその動きを見てみて。

Astraは常にこんな感じだ。あるタスクの90%までは進むけど、一番重要な部分をスキップしちゃう。で、それをちゃんと直してやってくれって言うと、突然6時間も無駄にして関係ないシナリオを直し始める。何が重要かを評価するのが下手で、どこで許可を求めるべきかも分からない。

FableがOpusよりもオーバーエンジニアリングを避けるのがかなり優れていると思う?最近のAnthropicモデルのテストは、(a)必要以上に遅くなるように調整されているように感じる(ループ中に何度もテストを実行するのに対して、最後にまとめて実行するみたいな)し、(b)実際の機能を確定する前から「たくさんの派手なエンタープライズ機能に関連する『もの』を作る」って感じだ。SolとTerraもその後者の一部を持ってるけど、実際の作業をかなり早くやってるみたい(これは使用ベースの優先度やレート制限の問題かもしれないけど)。大企業の人たちは「すごいコードを書いたけどテストが通らなかった」とか「機能は書いたけどすごく脆い」っていうのを見て、新しいモデルとハーネスの組み合わせをすごく攻撃的に調整して、怠惰なプロンプトを「中間的なエンタープライズアーキテクチャ設計の提案」に変えようとしてるけど、それが逆に遅くなっちゃうこともあるよね。俺はFable/Astraを比較するために時間を無駄にしたくないから、もっと安くなるまで大きなサブスクリプションには入ってないんだ、へへ。安いものはうまく操れるしね。

体験的に言うと、+1だね。このベンチマークは、俺の経験とモデルの出力への信頼度に合ってると思う。

GPT-5.6のSolがそのリストの最後にいるのを見て、俺の反応が合理的なのか感情的なものなのかを見極めようとしてるけど、判断する方法がないんだよね。

いいモデルがあれば、もう魔法使いの問題だと思う。このベンチマークには魔法使いがいない。そうじゃなければ、同じコードベースで他の人たちが苦労してエージェントをうまく使えないのに、他の人たちは同じものを使ってうまくいってるのが理解できないよ。

Solが主に「未確認の仮定」で失敗して、「統合エラー」はほとんど出ないってのは、俺には合ってると思う。SolはAstraに次いで(Fableよりもずっと先を行ってる)正しい実装を設計・エンジニアリングするのが得意だけど、すごく具体的に指示を出して厳しいガイドラインを提供しないとダメだね。一行だけの指示を出すと…悪い結果になるよ(SHA-256ハッシュ確認済み)。

モデルに感情的になる理由って何?そんなにハマっちゃったの?

GLM 5.3を5.6 Solより上に置くベンチはかなり怪しいと思う。リリース以来、俺の二つのメインのドライバーなんだけど、GLM 5.3は好きだけど、Solの方が絶対にいいよ。GLM 5.3はもっと~Terraって感じで、かなり遅いし。

GPT-5.6 Solには、考えと出力が混ざり始めて動かなくなる問題があるんだ。[1] 一度そうなると、セッションはほぼ終了で、復旧したいならちょっとした体操が必要になる。これが大きなプロジェクト(>10万LOC)ではよく起こるし、そのプロジェクトでは数回のセッションごとに起こるみたい。俺はこの特定のベンチマークが、小さな作為的なベンチマークよりも影響を受けると思う。[1]: https://github.com/openai/codex/issues/37524

Hacker Newsで議論の続きを見る