ベンチマーク

SWE-bench 93.9%達成｜Claude Mythosが変える開発AI

12分で読める
SWE-bench 93.9%達成｜Claude Mythosが変える開発AI

この記事の結論

Claude Mythos PreviewがSWE-bench Verified 93.9%を達成。ソフトウェア開発自動化の現実的な限界と、開発者が今日から実装できる自動化パターンを技術的に分析する。

SWE-bench Verified 93.9%。この数字が何を意味するか、ソフトウェア開発者の視点から整理してみる。

2026年4月7日、Anthropicが発表したClaude Mythos Previewは、既存モデルの限界を13ポイント以上引き離した。ただし、このモデルは一般公開されていない。Project Glasswingのセキュリティパートナー限定だ。だから「使えないのに何を論じるのか」という疑問は当然出てくる。それでも数値を解剖する価値はある。現在Opus 4.6が示す80.8%が「到達可能な限界」ではなく、「現時点の制約」だと分かるからだ。

この記事では、SWE-bench 93.9%の技術的な意味と、それが開発自動化パイプラインに与えるインパクトを分析する。コード例は現在公開されているClaudeのAPIを使った実装パターンで提示する。

SWE-benchとは何を測っているのか

SWE-bench（Software Engineering Benchmark）は、GitHubの実際のIssueをAIが解決できるかを測るベンチマークだ。「テスト通過率」という単純な指標ではなく、実際のオープンソースリポジトリに対するパッチ生成の成功率を測る。

SWE-bench Verifiedは、さらに条件を絞った検証済みサブセット。人間のソフトウェアエンジニアが「適切に定義されている」と判断したタスクのみを含む。つまり、曖昧な要件定義や不完全なテストケースによるノイズを除去している。

バージョン 内容 Mythos Preview Opus 4.6
SWE-bench Verified 人間が検証したIssue解決 93.9% 80.8%
SWE-bench Pro より複雑な実装タスク 77.8% 53.4%
Multilingual 多言語コードベース 87.3% —

SWE-bench Proの数字が特に重要だ。77.8%という数値は、単純なバグ修正ではなく、複数ファイルにまたがる設計変更や機能追加を含む「プロ水準のタスク」での成績だ。

（ソース: NxCode Claude Mythos Benchmarks 2026、参照日: 2026-04-09）

GPQAダイヤモンド94.5%が示す推論能力の質

GPQA Diamond（Graduate-Level Google-Proof Q&A）は、ドメイン専門家が作成した大学院レベルの問題を解く能力を測る。ポイントは「Google検索でも答えが見つかりにくい」問題群だという点だ。つまり、記憶の検索ではなく、真の推論能力を測定している。

Mythos PreviewはGPQA Diamondで94.5%を達成した。比較すると：

モデル GPQA Diamond
Claude Mythos Preview 94.5%
Gemini 3.1 Pro 94.3%
GPT-5.4 92.8%
Claude Opus 4.6 80.8%

ソフトウェア開発との関連でいうと、GPQA Diamond高スコアは「複雑なシステム設計の推論能力」に相関する。アーキテクチャの選択、パフォーマンスのトレードオフ分析、セキュリティ設計の判断——こういった「正解がGoogleに書いていない」タスクに強いことを示唆している。

AIエージェントの基本概念や構築パターンについては、AIエージェント構築完全ガイドで体系的にまとめている。

現行Claude APIで実装できる開発自動化パターン

Mythos Previewは一般公開されていないが、同じアーキテクチャの方向性を持つOpus 4.6でも、コード生成・レビュー・バグ修正の自動化は十分に実用的だ。実際に使える実装パターンを3つ提示する。

パターン1: Issue自動トリアージとパッチ候補生成

GitHubのIssueテキストを受け取り、影響ファイルの特定とパッチ候補を生成するエージェント。


# 動作環境: Python 3.11+, anthropic>=0.40.0
# pip install anthropic PyGithub

import anthropic
from github import Github

def triage_and_patch(issue_number: int, repo_name: str) -> dict:
    """
    GitHubのIssueを受け取り、パッチ候補を生成する

    注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
    """
    # GitHubからIssue情報を取得
    gh = Github(os.environ["GITHUB_TOKEN"])
    repo = gh.get_repo(repo_name)
    issue = repo.get_issue(issue_number)

    # 関連ファイルの特定
    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    # Step 1: 影響ファイルの特定
    triage_response = client.messages.create(
        model="claude-opus-4-6-20260901",  # 最新Opus
        max_tokens=2048,
        messages=[{
            "role": "user",
            "content": f"""
以下のIssueを分析し、修正が必要なファイルを特定してください。
リポジトリ構造: {get_repo_structure(repo)}

Issue #{issue.number}: {issue.title}
説明: {issue.body}

出力形式: JSON
{{
  "affected_files": ["path/to/file.py", ...],
  "root_cause": "推定される原因",
  "fix_strategy": "修正方針"
}}
            """
        }]
    )

    triage_data = json.loads(triage_response.content[0].text)

    # Step 2: パッチ生成
    patches = []
    for filepath in triage_data["affected_files"][:3]:  # 最大3ファイル
        file_content = get_file_content(repo, filepath)
        patch_response = client.messages.create(
            model="claude-opus-4-6-20260901",
            max_tokens=4096,
            messages=[{
                "role": "user",
                "content": f"""
以下のファイルを修正するパッチを生成してください。

ファイル: {filepath}
内容:
{file_content}

修正方針: {triage_data['fix_strategy']}
Issue: {issue.title}

unified diff形式でパッチを出力してください。
                """
            }]
        )
        patches.append({
            "file": filepath,
            "patch": patch_response.content[0].text
        })

    return {
        "triage": triage_data,
        "patches": patches
    }

ポイント: ファイル数を3件に制限しているのは、コンテキストウィンドウの効率的な使用のため。大規模リポジトリでは、まず影響範囲を絞り込んでからパッチ生成に進む。

パターン2: コードレビュー自動化エージェント

PRのdiffを受け取り、構造化されたレビューコメントを生成する実装。


# 動作環境: Python 3.11+, anthropic>=0.40.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

def automated_code_review(pr_diff: str, repo_context: str) -> dict:
    """
    PRのdiffをレビューし、構造化されたフィードバックを返す
    """
    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    response = client.messages.create(
        model="claude-opus-4-6-20260901",
        max_tokens=8192,
        system="""
あなたはシニアソフトウェアエンジニアとしてコードレビューを行います。
以下の観点でレビューしてください:
1. バグ・論理エラー (CRITICAL)
2. セキュリティ上の問題 (CRITICAL)
3. パフォーマンスの問題 (HIGH)
4. 可読性・保守性 (MEDIUM)
5. テストカバレッジ (MEDIUM)

出力は必ずJSON形式で:
{
  "summary": "全体評価",
  "critical_issues": [...],
  "high_issues": [...],
  "suggestions": [...],
  "approved": true/false
}
        """,
        messages=[{
            "role": "user",
            "content": f"Diff:n{pr_diff}nnコンテキスト:n{repo_context}"
        }]
    )

    return json.loads(response.content[0].text)

パターン3: テスト自動生成エージェント

関数・クラスを受け取り、カバレッジを最大化するテストケースを生成する。


# 動作環境: Python 3.11+, pytest, anthropic>=0.40.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

def generate_tests(source_code: str, function_name: str) -> str:
    """
    ソースコードからpytestテストを自動生成
    """
    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    response = client.messages.create(
        model="claude-opus-4-6-20260901",
        max_tokens=4096,
        messages=[{
            "role": "user",
            "content": f"""
以下の関数に対して、pytest形式のテストを生成してください。

要件:
- 正常系テスト（少なくとも3パターン）
- エッジケース（境界値、空値、型エラー）
- モック不要のシンプルな構造

関数コード:
{source_code}

対象関数: {function_name}
            """
        }]
    )

    return response.content[0].text

SWE-bench 93.9%が示す「自動化の射程範囲」

現状のSWE-bench評価では、タスクは主に以下のカテゴリに分類される：

タスクカテゴリ 難易度 現行AIの得意度 今後の変化
バグ修正（再現可能） 低 ★★★★★ 完全自動化領域に入りつつある
機能追加（仕様明確） 中 ★★★★☆ 93.9%が示す突破ライン
リファクタリング 中 ★★★★☆ 高精度化が進む
アーキテクチャ変更 高 ★★★☆☆ まだ人間のレビュー必須
セキュリティ設計 高 ★★★☆☆ Glasswing特化で向上中

93.9%という数値は、「仕様が明確なタスクはほぼ自動化可能」という段階に達したことを示している。逆に言うと、残り6.1%の失敗ケースは「要件定義が曖昧」または「複数システムをまたがる副作用の理解」が必要なタスクに集中している可能性が高い。

開発者が直面する3つの現実的な課題

課題1: Mythosへのアクセスはいつ解放されるか不明

現在、Claude Mythos Previewにアクセスできるのは、Project GlasswingのパートナーであるApple、Google、Microsoft、Amazonなど大手テクノロジー企業のセキュリティチームに限られている。一般開発者向けのリリース時期について、Anthropicは公式にコメントしていない。

ここは正直に書く。「近く使えるようになる」という楽観的な予測は根拠がない。Anthropicが「あまりにも危険だ」と判断しているモデルを、一般公開する動機がどこにあるのかは不明だ。

課題2: 既存パイプラインへの統合設計が先

SWE-benchのような単一タスク評価と、実際の開発パイプラインは異なる。リポジトリのコンテキスト管理、複数のPRにまたがる依存関係の追跡、人間レビューとのインターフェース設計——これらの問題はモデルの性能ではなくシステム設計の問題だ。

課題3: ハルシネーションは依然ゼロではない

93.9%は6.1%の失敗を意味する。本番の重要なコードベースに自動生成パッチを無審査で適用するのはリスクが高い。現実的な設計は「AIがパッチ候補を生成 → 人間エンジニアが最終確認」のハイブリッドだ。

今週のアクション: 現行APIで自動化の土台を作る

Mythos Previewが公開されていなくても、今できることはある。

1. 現行のClaude APIを使って、Issue→パッチ候補生成パイプラインのPoC（概念実証）を作る
2. SWE-bench Pro形式のタスクを社内のリポジトリで再現し、自社ベンチマークを取る
3. コードレビュー自動化から始めて、成功率と失敗パターンを計測する

完全自動化は段階的に達成するもので、「Mythosが来るまで待つ」は良い戦略ではない。

参考・出典

あわせて読みたい:

AIエージェント活用についてのご相談は Uravation お問い合わせフォーム からお気軽にどうぞ。

この記事はAIgent Lab編集部がお届けしました。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約 支援実績を見る

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年4月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事

Meta Muse Spark解剖｜AIインデックス4位の技術を読む ベンチマーク

Meta Muse Spark解剖｜AIインデックス4位の技術を読む

Meta Superintelligence Labsが開発したMuse Spa...

6分で読める
攻撃AIと防御AIの最前線：エージェント同士が戦う時代へ ベンチマーク

攻撃AIと防御AIの最前線：エージェント同士が戦う時代へ

自律型AIエージェントが攻撃側・防御側の両方に使われ始めた。CVE-Benchで...

10分で読める
GPT-5.4 vs Claude｜Computer Use選定ガイド ベンチマーク

GPT-5.4 vs Claude｜Computer Use選定ガイド

GPT-5.4とClaude Computer Useはどちらを選ぶべきか。OS...

14分で読める