Claude 3.5 SonnetのSWE-bench Verified 49% — 最小スキャフォールドで前SOTAを抜いた設計

Anthropicのengineeringブログ「Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet」(2025年1月6日公開)は、アップグレード版Claude 3.5 SonnetがSWE-bench Verifiedで49%を達成し、前のstate-of-the-artであった45%を上回ったことを報告しています。注目すべきは数値そのものより、Bash ToolとEdit Tool 2つだけの最小スキャフォールドで到達した点です。

本記事では、Anthropicが採ったエージェント設計の判断、ツール定義の作り込み、評価ハーネスの構造、そして公表されている制限事項を、Claude / Agent SDK / MCP(モデルコンテキストプロトコル、外部サービスをClaudeに繋ぐ標準仕様)でエージェントを組む読者向けに読み解いていきます。

何が起きたのか — 数値の位置付け

SWE-benchは、GitHub上の実際のissueとそれを解決したpull requestのペアから構成される、ソフトウェアエンジニアリングタスクのベンチマークです。エージェントはissue直前のリポジトリ状態とPython環境を与えられ、コードを理解・修正・テストして「人間のPRと同じ機能を実現するパッチ」を出すことが求められます。評価は、元のPRに付属する実際のunit testでパッチを検証する形で行われます。

SWE-bench Verifiedは、このうちタスク定義が曖昧でない500問を選び直したサブセットで、OpenAIが公表しました。Anthropicの今回の数値はこのVerifiedサブセット上のものです。

モデル別スコアの推移

3か月で33% → 49%という伸び幅は、ベンチマークの上限値が問題定義そのものに引きずられる(unit testの曖昧さや環境構築の難しさが残る)性質を踏まえると無視できないギャップです。前SOTAとの4ポイント差も、この種のベンチマークでは大きな差と読めます。

このスコアの読み方

ここで注意したいのは、スコア = モデル単体の能力ではないという点です。同じモデルでも、ハーネス設計・ツール定義・プロンプトの作り方しだいでスコアは大きく動きます。実際、本記事の主題はモデルの強さの自慢ではなく、「汎用ツール2つだけで設計したシンプルなエージェントが、複雑なスキャフォールドを上回った」という設計上の主張にあります。

エージェント設計の評価そのものについてはAIエージェントのEval設計で扱っていますが、SWE-benchはpass@1で測られる、いわば「1発勝負」の評価です。pass^kのような安定性指標とは別の軸で見る必要があります。

エージェント設計の哲学 — なぜスキャフォールドを最小化したのか

本記事でAnthropicが明示している設計方針は明快で、「言語モデル自体に可能な限り制御を委ね、スキャフォールディングを最小限に保つ」というものです。複雑な計画立案のロジックや、専用のタスク分解モジュールを挟まず、モデルが自分で探索・修正・検証を回すループに任せる。

この判断の背景には、Claude 3.5 Sonnetのアップグレードでツール使用とコード理解の能力が伸びたという事実があります。能力が上がった段階で外側を固めすぎると、モデルが自然に発揮できる柔軟性を殺してしまう。逆にハーネスを薄くしておくと、モデルの能力向上分がそのままベンチマークに乗りやすい、という発想です。

スキャフォールドの構成要素

実装は次のように非常に薄い構成です。

この薄さは、後段で扱う「失敗要因の分析」と表裏一体です。複雑な計画モジュールを後付けせず、素のモデル能力 + 良いツール定義 + 良いプロンプトだけでどこまで行けるかを示すサンプルになっています。

ツール定義の作り込み — Bash ToolとEdit Toolの正体

本記事の最大の実装的見どころは、汎用ツール2つの定義そのものを丁寧に作り込んでいる点です。エージェント用ツール設計の原則についてはエージェント向けツール設計の原則で扱っていますが、本記事のBash Tool / Edit Toolはその実例として読めます。

Bash Tool

Bash Toolは、本文で公開されているinput_schemaを見ると、パラメータはcommand(文字列)1つだけのきわめてシンプルな定義です。代わりにdescriptionに運用上の前提や落とし穴を細かく書き込んでいます。

これは「人間の運用者が新人エンジニアに最初に伝える注意事項を、そのままツール定義に注入する」設計です。モデルが事前に知らない実行環境の癖を、プロンプトでなくツール側のdescriptionに書くことで、毎ターン参照されやすくしています。

Edit Tool(str_replace_editorパターン)

Edit Toolはサブコマンド方式で、ファイル操作を5種類に分解しています。

主要パラメータはcommand(サブコマンド指定)とpath(絶対パス必須)で、サブコマンドごとに必要な追加パラメータが分岐します。

ここでの設計判断として読み解けるのは、undo_editの存在です。コード編集エージェントは「やってみて間違ったら戻す」というループを高速に回せると探索効率が上がります。undoがないと、誤編集を訂正するために再度str_replaceを考える必要があり、トークンとターンを浪費します。

また、viewが行範囲指定をサポートしているのは、200kコンテキストといえど巨大ファイル全文をすべて入れると後続のターンを圧迫する、という現実的な配慮です。

プロンプトの構造 — モデルに何を頼んだか

本記事はsystemプロンプトの一部を引用しています(原文ママのテンプレートとして本文で公開済)。骨子は次の構造です。

<uploaded_files>
{location}
</uploaded_files>
I've uploaded a python code repository in the directory {location} (not in /tmp/inputs).
Consider the following PR description:
 
<pr_description>
{pr_description}
</pr_description>
 
Can you help me implement the necessary changes to the repository so that
the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described
in the <pr_description>. This means you DON'T have to modify the testing
logic or any of the tests in any way!
 
Your task is to make the minimal changes to non-tests files in the
{location} directory to ensure the <pr_description> is satisfied.
 
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to explore the repo to
   familiarize yourself with its structure.
2. Create a script to reproduce the error and execute it with
   `python <filename.py>` using the BashTool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
 
Your thinking should be thorough and so it's fine if it's very long.

このプロンプトには、5ステップの解法手順が明示されています。「探索 → 再現スクリプト作成 → 修正 → 再実行で確認 → エッジケース検討」という流れは、人間のソフトウェアエンジニアがバグ修正をする際の自然な順序で、モデルを特殊な手順に縛り付けず、現実の開発フローに寄せています。

最終行の「Your thinking should be thorough and so it's fine if it's very long」も重要です。これはモデルに「長い推論を出してよい」という許可を明示し、トークン削減方向のバイアスをかけないようにしています。think toolやextended thinkingが登場する前の時点での、思考スペースの確保パターンと読めます(後発のthink toolについてはAnthropicのthink toolとはで詳しく扱っています)。

テストファイル改変禁止の指示

「テストには触らなくていい」と明示しているのも、SWE-benchの評価特性を踏まえた工夫です。SWE-benchは元PRの実際のunit testでパッチを検証するため、モデルがテストを書き換えて通したとしても評価上は意味がありません。むしろ、モデルがテストを見て「自分の修正が通るようにテストを甘くする」ハックに走るリスクがあるため、最初から「触らなくていい」と明文化しているわけです。

評価ハーネス — SWE-Agent frameworkを基礎に

評価環境としては、Princeton大学のSWE-Agentフレームワークを基礎に、Anthropic側で必要な調整を加えた構成です。各タスクで:

1. issue解決直前のリポジトリ状態をPython環境とともに用意
2. PR descriptionをプロンプトに埋め込んでモデルに投入
3. モデルがBash ToolとEdit Toolを使って探索・修正
4. モデルが「完了」と判断したら、または200kコンテキスト上限に到達したら停止
5. 元PRに付随するunit testを実行してpass/failを判定

ハーネス側で「何ターンまで」「どのテストを見せるか」を細かく制御するというより、モデル側の判断にタイミング決定を委ねているのが特徴です。エージェント実行ハーネスの設計論については長時間実行エージェントのハーネス設計も参照してください。

公表されている制限事項 — 何が原因で失敗したか

本記事は失敗事例の分析にも紙幅を割いており、これが運用知見として最も価値の高い部分です。主要な失敗カテゴリは次の通り公表されています。

コストと所要時間

成功した実行の多くが数百ターン、10万トークン以上を消費したと記載されています。SWE-bench Verifiedの1問あたりこの規模ということは、500問評価するだけで膨大なAPI課金が発生する計算になります。スコア比較を実務に持ち込む際には、このコスト面の現実を忘れない必要があります。

採点環境の問題

評価環境側の問題として、環境設定の難しさやパッチの重複適用などのシステム的不具合が一定数あったと記述しています。これはモデルの能力とは独立した要因で、ベンチマークの「天井」を押し下げる方向に効きます。

隠れたテスト(Hidden tests)

評価ハーネスでは、モデルがunit testそのものを参照できません。そのため、モデルが「修正できた」と思っても、評価フェーズで実際のテストにかけると失敗する、というケースが残ります。これはモデルの自己評価精度の限界とも言えますが、現実のソフトウェア開発でも「テストを見ずに本当に正しいか判断する」のは難しい問題です。

画像処理の未対応

本ハーネスはファイルシステム上の画像やURLの画像を表示する機能を実装していないため、特にMatplotlibを使う可視化タスクで誤生成が起きたと記述しています。グラフのプロット結果を見ずにコードを書く必要があるため、生成された画像が要求通りかをモデルが推測で判断するしかなく、誤った修正につながる場合があるわけです。

これは現在のClaudeのcomputer use系機能や、画像入力の進歩によって埋まる可能性が高い領域で、当時のハーネス側の設計選択の限界として読めます。

「最小スキャフォールド + 強いツール定義」の系譜

本記事が示した設計判断は、Anthropicのエージェント記事の一貫した思想として読むと面白い位置付けになります。

この時系列で見ると、「ハーネスを薄くしつつ、ツール定義の品質を高める」という方向はずっと一貫していて、後発の機能(think tool、Tool Search、Programmatic Tool Calling)はその思想の延長線上に位置付きます。Claude Codeのアーキテクチャ思想を扱ったClaude Code Best Practicesも同じ系譜にあり、フレームワーク的な抽象化より、シェル + エディタという身近な道具立てを素のモデルに使わせる設計が貫かれています。

自社のエージェント設計への置き換え

本記事を自分の運用に持ち帰るとき、いくつかの観点で読み替えができます。

ツール数を増やしすぎていないか

SWE-bench級の難易度のタスクが、汎用ツール2つで49%まで行けたという事実は、「専用ツールを足しすぎていないか」という問いを投げかけます。自社のドメインで「Edit / Bashに相当する2つのコア動詞」が何かを特定し、まずそれだけで通るかを試す手はあります。

ツール定義のdescriptionは説明書になっているか

Bash Toolのdescriptionが運用上の前提を細かく書き込んでいたように、ツール定義は単なるI/O仕様ではなく、新人向けの説明書として書く価値があります。エラーになりがちなパターン、避けたほうがいい使い方、状態の永続性などをdescriptionに書き込むだけで、エージェントの安定性は大きく変わります。

モデルの自己判断ループに任せる範囲

Anthropic側は「モデルが完了と判断するまで継続」というシンプルなループを採用しています。自社のハーネスで、ターン上限・タイムアウト・強制中断のロジックがモデルの自然な完了判断を阻害していないかを確認する価値があります。

評価コストの現実

成功実行で10万トークン規模というコスト構造は、SWE-bench並みの難度のタスクをエージェントに任せる場合の参考値になります。本番運用ではここまでかからない設計を目指すにしても、評価フェーズではコストを抑える方向の最適化を後回しにしてよい(モデルの能力上限を測ることが優先)、という判断の根拠になります。

まとめ

• アップグレード版Claude 3.5 SonnetはSWE-bench Verifiedで**49%**を達成し、前SOTAの45%を上回った
• ハーネスはBash ToolとEdit Toolの2つだけの最小スキャフォールドで、計画モジュールを挟まない設計
• ツール定義はdescriptionに運用上の前提を細かく書き込み、Edit Toolはundo_editを含む5サブコマンド構成
• プロンプトは5ステップの解法手順を明示し、思考の長さを許容する一文を入れている
• 成功実行で数百ターン・10万トークン超の計算コスト、画像処理未対応によるMatplotlibタスクの誤生成などの制限事項が公表されている
• 「ハーネスを薄くしつつツール定義の品質を高める」という思想は、その後のthink tool / Advanced Tool Use / Claude Codeに連続している

エージェント設計を一段引き上げたいときに、専用ツールを増やす前に汎用ツールの定義品質を磨くという選択肢があることを、本記事は具体的な数値とコードで示しています。