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

AI2: オープンコーディングエージェント

概要

  • Ai2 Open Coding Agents は、オープンかつ低コストで強力なコーディングエージェントを構築可能にする新手法とモデル群の公開
  • SERA (Soft-verified Efficient Repository Agents)を中心に、プライベートなコードベースにも迅速・安価に適応可能
  • 合成データ生成 や新しいトレーニング手法による効率化と高性能化を実現
  • ハードウェア要件の緩和 と再現性の高いパイプラインで、研究者や開発者の参入障壁を大幅に低減
  • 完全オープンなリリース で、モデル・コード・データ・レシピを全公開

コーディングエージェントの進化と課題

  • 過去1年で コーディングエージェント は、ソフトウェア開発の方法を大きく変革
    • デバッグ、リファクタリング、Pull Requestの自動化などの実現
  • 既存の多くは クローズド・高コスト・適応困難 という制約
  • プライベートなコードベースに適応するには 合成データ生成 が必須だが、従来は高コストかつ困難
  • Ai2 Open Coding Agents は、これらの課題を解決するために開発

SERAとその特徴

  • SERA は、オープンソースのコーディングエージェントモデル群の最初のリリース
  • SERA-32B は、SWE-Bench Verified問題の54.2%を解決し、同規模の従来オープンモデルを上回る性能
    • 40 GPU日以内で訓練可能(NVIDIA Hopper/RTX PRO 6000 Blackwell対応)
  • Claude Code との互換性や、NVIDIAとの協業による推論最適化
    • 4xH100 GPUでBF16精度時1,950トークン/秒、FP8精度時3,700トークン/秒
    • Blackwell 4xB200 NVFP4時8,600トークン/秒
  • 全コンポーネントがオープン で、ワンラインで立ち上げ可能な手軽さ

合成データ生成と効率化の革新

  • Soft-verified generation (SVG)
    • 完全な正解でなくても有用な合成パッチを生成し、インフラコストを大幅削減
  • バグタイプメニュー
    • 51種のバグパターンから多様なバグプロンプトを生成し、データ多様性を確保
  • 開発者ワークフロー再現性
    • コードの正確性よりも、開発者の実際の作業プロセスを模したデータ生成を重視
  • SFT(Supervised Fine-Tuning)だけで高性能
    • 複雑なRLパイプライン不要で、シンプルな教師あり学習でモデルを強化

性能とコストの両立

  • 8B~32Bパラメータの Qwen3ベース モデル群
  • SWE-Bench Verifiedで SERA-32B は49.5% ±1.9%(32Kコンテキスト)、54.2% ±1.4%(64Kコンテキスト)
    • Devstral Small 2やGLM-4.5-Airと同等の水準
  • 専門化による大規模モデル超え
    • DjangoやSymPyなどのリポジトリで、32Bモデルが100B+の教師モデルを上回る性能
    • 小型モデルでもメモリ・推論コストが低く、高速動作

再現性・導入容易性・コミュニティへの貢献

  • モデル・コード・データ・レシピ全公開
    • 2行で推論サーバー立ち上げ、Claude Code連携も簡単
  • 再現コストの大幅削減
    • 最高性能のオープンモデル再現が約$400、業界最高水準でも$12,000
  • ローカル・クラウド・独自データへのファインチューニングが容易
    • 研究・開発の民主化と、コミュニティ主導の進化促進

まとめ:SERAがもたらす新しいコーディングエージェントの世界

  • 低コスト・オープン・高性能 なコーディングエージェントの普及
  • プライベートコードベースへの簡単な適応 と、研究・産業界双方での活用促進
  • コミュニティ主導の検証・発展 が可能な新たな基盤の提供

Hackerたちの意見

記事の主張は間違ってるよ。MetaのCWMモデルを無視してるのが都合良すぎる。これらはオープンソースで[1]、オープンウェイト[2]で、65%のSWE-benchで検証済み(TTSあり)で、54%のpass@1も達成してるし、サイズも同じ(32Bの密なモデル)。だから「同じサイズとコンテキスト長のオープンソースの最先端コーディングモデルを超えた」みたいな主張や、評価表から以前のOSS SOTAを省くのは…ちょっと怪しいよね。

違いは、アレン研究所のモデルはオープンなトレーニングデータを持ってるけど、Metaは最終モデルを再現するために必要なトレーニングデータを共有してないってこと。オープンウェイトモデルは多くの用途でほぼ同じくらい良いけど、研究を進めるにはすべてオープンにしておく方がずっといいよ。

リンク先のオープンウェイトは商業利用を禁じていて、研究目的のライセンスしかないよ。

こんにちは!いい観察だね。まず、TTSはパフォーマンスを向上させることができるけど、私たちはモデルの生の能力を評価したかったんだ。だから、評価インスタンスごとに1回だけのロールアウトを生成することにした。これはSWE-smithやBugPilotのような他の論文に従ってるんだ。それに、TTSは追加の推論コストがかかるし、ロールアウトのランキングに依存するから、メモリや推論速度が非常に重要なデプロイ可能なモデルには混乱要因が多いんだ。その流れで言うと、コンテキスト長も大きな混乱要因だよ。長いコンテキスト長はパフォーマンスを向上させるけど、KVキャッシュサイズやメモリ要件が膨大に増える結果にもなる。私たちはこの点を論文で制御することにして、32Bサイズモデルの32Kコンテキスト長に焦点を当てたんだ。このコンテキスト長は、ローカルで「デプロイ可能」とされる範囲を押し広げるものだよ。それでも、YARNを使って64Kのコンテキスト長で評価して、CWMの54%のパフォーマンス(TTSなし)を上回ることができたんだ。CWMは128Kのコンテキストを使ってるから、私たちが使ってるものよりもかなりの増加だよ。これも重要なポイントで、私たちは32Kのコンテキストでしかトレーニングしてないけど、CWMは128Kでフルにトレーニングしてるからね。

すごい仕事だね!AI2を本当に尊敬してる。彼らはすべてをオープンソースにしてるから。モデル、ウェイト、トレーニングパイプライン、推論スタック、コーパスまで。

記事の主張の一つは、確実に間違ってるか、少なくとも狭める必要があるよ。Claudeは唯一のクローズドエージェントハーネスで、オープンなものは約2ダースあるからね。多くのモデルはクローズドだけど、人々が「エージェント」と言うときは、一般的にハーネスを指してるんだよ、基盤となるモデルではなくて。

「Devstral Small 2のような強力なクローズドウェイトコーディングエージェントは、重要な比較ポイントだ。」Devstral Small 2はオープンウェイトモデルだよ:https://huggingface.co/mistralai/Devstral-Small-2-24B-Instru...

ローカルリポジトリでファインチューニングトレーニングをする実際の利点は何?それともローカル情報の要約をコンテキストに入れる方がいいのかな?つまり、各チームには自分たちのスタイルやコーディングパターンの好みがあって、それを一般化できるかもしれないけど、大規模モデルはそれらを全部見てきたから、コンテキストで説明できるんじゃない?それとも、特定のドメインレベルのパターンがあって、組織外では見られないから、モデルが新たにチューニングしないと推測が難しいのかな?

私は世界最大のコードベースで働いています。私たちのコードベースには微調整されたモデルがありますが、あまり感心していません。非調整モデルよりも良いコードは生成しません。特定の問題には優れているかもしれませんが、私が投げる99%の問題は、結局文脈や近くのコードから得られるものです。社内ライブラリを使っていても(ほぼすべてのコードがそうですが)、モデルはそのライブラリを掘り下げてヘッダーを読むのに十分な能力があります。もしかしたら、スピードには役立つかも? コーディングを始める前にリサーチが少なくて済むなら。

ここでの完全オープンなアプローチは、単なるデプロイメントを超えて研究を進めるために本当に価値がありますね。オープンウェイトモデルは実用的なアプリケーションには素晴らしいですが、完全なトレーニングパイプラインとデータにアクセスできることで、実際のブレークスルーを生むような反復的な改善が可能になります。この基盤の上にコミュニティが何を作り出すのか楽しみです。

トレンドを止めたのがOpenAIだなんて皮肉ですね。

低コストのチューニングには、LoRaみたいなものがGLM-4.7-Flashで使われるのがいいんじゃないですか?

これは、APIに非常によくマッチするコードを生成する必要がある消費者向けアプリ(Lovableのような)を専門化するための超面白い技術でもあります。カスタム言語を構築するための素晴らしいアプローチでもありますね。

つまり、この「オープン」なシステムを実際に使うにはClaudeを使わなきゃいけないってこと?

いいえ。例えば、OpencodeやCline、Roo Code、Kilo Codeを推論エンドポイントに向けることができます。でも、CCは高いインストールベースがあって、ユーザーもそれに慣れているので、ターゲットにするのは理にかなっています。

この数週間で見た面白い変化は、私たちが素のLLM自体を「エージェント」と呼び始めていることです。以前は、エージェント=LLM + スカフォールド/ハーネス/ループ/何かだったんですが。

最近の「ベアLLM」は、より目的に特化して作られていて、「エージェント」特有の強化学習(RL)で強化されているから、一般的に「エージェント」の要求に合わせて微調整されているんだよね。特定の推論能力やツールの呼び出しなど、そういう要素があって、「ベアLLM」は「エージェント」ハーネスの中で使うのに適していると思う。だから、単に「エージェント」と呼ぶんじゃなくて、「エージェンティックLLM」って呼ぶ方が正確だと思う。今そうなってる理由は、多分人間の怠惰さと口語表現のせいだね。