SWE-CIが崩す「テストが通れば正解」という前提、PyPy終焉の連鎖が始まった (2026-03-08)
SWE-CIが問う「短期記憶の優等生」問題
SWE-benchが「バグを直せるか」を測っていたとすれば、SWE-CIが測ろうとしているのは「コードを腐らせずに育てられるか」だ。
【補足】SWE-benchは実際のGitHubイシューとそのマージ済みパッチを使い、LLMが「既存テストを通すパッチを生成できるか」を単一タスクとして評価するベンチマーク。評価は1コミット単位の静的スナップショットで行われる。この違いは小さく見えるが、エージェント評価の根本的な前提を崩している。
SWE-CIはそこに異議を唱える設計になっている。平均233日・71コミットの進化履歴を持つリポジトリに対して、エージェントが「何十ラウンドもの分析とコーディングの反復」を通じてタスクを解決することを要求する。
ここで崩れる前提がある。「テストが通る＝品質が保たれている」という等式だ。静的なfunctional correctnessは一時点のスナップショットに過ぎない。実際のコードベースは要件が変わり、依存が増え、設計の負債が積み重なる。エージェントが「今この瞬間のテストを通す」ことに最適化されていても、3ヶ月後の変更で全体が崩れるなら、それは保守性を持つコードとは言えない。SWE-CIはその差を可視化するために設計されている。
100タスクというスケールも意図的に見える。SWE-benchの2294インスタンスと比べると少ないが、1タスクあたりの深さが根本的に異なる。単一のパッチ適用ではなく、長期の進化シナリオを再現することで、エージェントが「コンテキストを跨いで一貫した判断を維持できるか」が問われる構造になっている。
この評価軸のシフトが示唆することは、現在のエージェントが「短期記憶の優等生」であるという仮説だ。SWE-benchで高スコアを出すエージェントは、局所的なパターンマッチングと即時的なコード生成が得意なだけで、長期的な設計意図の維持や技術的負債の管理には対応できていない可能性がある。CIループというフィードバック機構を評価に組み込むことで、エージェントが「失敗から学んで反復できるか」という能力が初めて測定対象になる。これはRLHFやtool-useの訓練パラダイムとも直結する問いだ。
233日分のコミット履歴を扱うということは、エージェントのコンテキストウィンドウ管理戦略が評価結果に直接影響する。現在のlong-context LLMが本当に「長い歴史を理解して作業できるか」の試金石にもなる。71コミット分の履歴をそのままプロンプトに詰め込む設計では早期に破綻する。変更の意図と設計判断をサマリーとして蓄積するメモリ層を持つアーキテクチャが必要になる。
SWE-benchスコアだけでエージェントを選定しているなら、評価軸を見直す根拠がここにある。静的ベンチマークで高性能なエージェントが、自社の長期プロジェクトで機能するとは限らない。CIループをエージェントのフィードバック機構として設計に組み込んでいないなら、テスト結果・lint・型チェックをエージェントが自律的に解釈して次の行動を決める構造にしておかないと、SWE-CI型の評価で機能するエージェントワークフローは作れない。
MonoGameが今も商業タイトルで使われている理由
XNAの後継として生き残ったMonoGameが、今なお商業タイトルの選択肢として機能している。Streets of Rage 4、Celeste、Stardew Valleyといった実績が示すのは「インディーの習作用フレームワーク」ではなく、商業出荷に耐える実装基盤だという事実だ。
MonoGameの本質はXNA APIの互換再実装にある。Microsoftが2013年にXNAを終了させたとき、すでにXNAで書かれたコードベースを持つ開発者は移行先を失った。
【補足】XNA（2004年発表）はMicrosoftが提供したゲーム開発フレームワークで、C#とDirectXを組み合わせてWindows・Xbox 360向けゲームを作れた。MonoGameは2009年頃からXNA APIをオープンソースで再実装するプロジェクトとして始まり、XNA終了後に事実上の後継として広まった。MonoGameはそのコードをほぼそのまま動かせる。「新しいフレームワークを学ぶ」ではなく「既存資産を延命しながらクロスプラットフォームに展開する」という用途で価値が出る。
対応プラットフォームの幅が実務上の最大の強みだ。PC（Windows/macOS/Linux）、iOS、Android、そして登録開発者向けにPS4/PS5/Xbox/Nintendo Switch 1&2まで一つのコードベースから届く。UnityやGodotと違い、MonoGameはエンジンではなくフレームワークなので、レンダリングパイプラインやECSの設計を自分で決められる。自由度が高い分、初期コストは上がるが、エンジンの抽象化レイヤーが邪魔になる場面では逆に有利に働く。
3.8.5プレビューでVulkanとDirectX 12のサポートが入りつつある点も見逃せない。これまでOpenGLとDirectX 11相当のAPIに留まっていたグラフィックスバックエンドが、モダンなAPIに対応し始めた。ただし現時点ではソースコードユーザー向けの実験的実装であり、NuGetパッケージで即使える状態ではない。
MonoGameが今もアクティブに使われている理由は、Unityのライセンス騒動と無関係ではない可能性がある。2023年のランタイムフィー問題でUnityへの依存リスクが顕在化したとき、「エンジンに依存しない選択肢」として再評価された可能性が高い。MonoGameはMicrosoft Public Licenseで提供されており、ランタイムフィーのような後付けコスト変更が構造的に起きにくい。オープンソースで実装がすべて読めるため、プラットフォームサポートが突然打ち切られるリスクも低い。
一方でコンテンツパイプライン（mgcb）の存在がUnityに慣れた開発者には障壁になる。アセットのビルドをパイプラインに通す設計は、XNA時代の思想をそのまま引き継いでいる。自動化しやすい反面、CI/CDに組み込む際にはmgcbの挙動を理解する必要がある。
PS5やNintendo Switch向けに出荷する予定があるなら、MonoGameは登録開発者向けに公式コンソールサポートを提供している唯一に近いオープンソース系フレームワークだ。Unityやアンリアルと比較する際は、ライセンス構造とランニングコストを数字で並べてみると判断しやすい。Vulkan/DX12対応は現時点でソースビルドのみの実験的実装なので、プロダクションコードへの採用は正式リリースを待つべきだ。
uvがドキュメントに刻んだPyPy終焉のシグナル
uvのドキュメントに「PyPyは活発に開発されていない」という警告が追加された。小さな変更に見えるが、背景を読むと、これはPyPyというランタイムの終焉を、主要なPythonツールチェーンが公式に認め始めた最初のシグナルだ。
きっかけはnumpyのissue（numpy/numpy#30416）だ。そこで発言したのは外部の批評家ではなく、PyPy開発者自身だった。「公式声明はない」が、プロジェクト内部からすでに撤退の意思が漏れている状態だ。uvはその事実を受けて、ユーザーが「PyPyはCPythonと並ぶ選択肢」という誤解のまま環境を構築するのを防ぐために動いた。
因果の連鎖はこうなる。numpyがPyPyサポートを段階的に外す → SciPy・pandas等の主要科学計算ライブラリも追随する → PyPyの「科学計算でも使える高速Python」という価値命題が崩れる
【補足】numpyはCPython C APIに強く依存しており、PyPy向けにはcffiベースの別実装（numpy-pypy）が存在していたが、メンテナンスの遅れが常に問題だった。PyPyがCPython C API互換レイヤー（cpyext）を持つものの、完全互換ではなくパフォーマンスオーバーヘッドも大きいため、C拡張を多用するライブラリとの相性は構造的に悪い。 → PyPyを採用している本番環境がライブラリ互換性の問題にぶつかる → 移行コストが顕在化する。この連鎖が起きる速度は、numpyの動きに引っ張られる。
PyPyが「遅い」わけではない。今でもマイクロベンチマークではCPythonを上回る場面がある。問題はランタイムの速度ではなく、エコシステムの維持コストだ。CPythonはここ数年でGIL廃止（PEP 703によるfree-threading対応）、JITコンパイラの試験的導入（CPython 3.13）と、PyPyの差別化ポイントを内側から侵食し続けている。
【補足】PEP 703（free-threading）はCPython 3.13で実験的オプトインとして導入され、GILを無効化してマルチスレッドの真の並列実行を可能にする。PyPyはSTM（Software Transactional Memory）による並列化を長年研究してきたが、実用化には至っていない。CPythonがfree-threadingを取り込んだことで、この領域でもPyPyの優位性が薄れつつある。PyPyが強みとしていた「JITによる高速化」は、CPython自体が取り込みつつある。開発リソースが限られるPyPyが、この変化に追随するのは構造的に難しい。
uvがPRのタイトルを「unmaintained」から「not actively developed」に変えたのも示唆的だ。法的・政治的リスクを避けつつ、実態を伝えようとする慎重な表現選択だ。「公式声明がない」状態でどこまで踏み込むかという判断が、この1文に凝縮されている。
PyPyを本番環境で使っているなら、今すぐ依存ライブラリのPyPy対応状況を棚卸しすべきだ。numpyが外れた時点でサイエンス系スタックは実質的に使えなくなる。「PyPyの方が速い」という理由でランタイムを選んでいるなら、CPython 3.13以降のJIT（--enable-experimental-jit）を実際に計測して比較すべきだ。
【補足】CPython 3.13で試験的に導入されたJITはcopy-and-patch方式を採用しており、起動時のコンパイルコストを抑えた設計。現時点では多くのワークロードで速度改善は限定的（数%程度）だが、3.14以降での継続的な改善が予定されている。PyPyのJITとは成熟度・最適化の深さで差があるため、ベンチマーク対象のワークロードを絞って比較することが重要。差が縮まっているケースは多い。新規プロジェクトでPyPyを選択肢に入れている場合は、uvがドキュメントに警告を入れた事実を「選定根拠として使えない状態になりつつある」という外部シグナルとして記録に残す価値がある。
総括
3つのトピックに共通するのは、「静的な一時点の評価」から「時間軸を持った持続性の評価」へという軸のシフトだ。SWE-CIはベンチマークの時間軸を、MonoGameはライセンスの持続可能性を、PyPyの終焉はエコシステム維持コストの時間的劣化を、それぞれ問題の核心に据えている。ツール・ランタイム・フレームワークを選ぶ根拠として「今この瞬間のスコアや速度」だけを見ていると、この3つのどれかで足をすくわれる。