DeepReinforceが公開した Ornith-1.0 は、ひとことで言うと「agentic coding」に特化したオープンソースのLLMファミリーです。
ここでいう agentic coding は、ただコードを1発で出すだけではなく、ターミナルを触ったり、テストを回したり、途中で試行錯誤しながら仕事を進めるタイプのコード生成を指します。実務の開発にかなり近い世界です。
面白いのは、このモデルが単に「賢いコード生成器」という話ではないところです。Ornith-1.0は、解法そのものだけでなく、解法を引き出すための“足場”まで自分で作るという発想を取っています。これはかなり野心的ですし、個人的にはかなり好きな方向性です。モデルに「どう考えるか」まで学ばせるわけで、いかにも次の世代っぽい。
この手のモデルは、普通は「問題を解くモデル」と「その解答を評価する環境」が分かれています。たとえば、コードを直すタスクなら、人間が用意したテスト環境や評価用の仕組みがあって、モデルはその中で答えを出す。
Ornith-1.0の発想は少し違います。
モデルが解答を出すだけでなく、その解答を導くための“scaffold”も学習するのです。
scaffold は、ざっくり言えば「作業の足場」や「進め方の枠組み」です。
たとえば、
といった、コードそのものではないけれど結果を大きく左右する部分です。
通常はこういうものを人間が手で設計します。でも Ornith-1.0 は、scaffold を学習対象にしてしまう。
この発想がかなりおもしろい。人間が「このやり方でやってね」と固定するより、タスクごとにより良い進め方を自動で見つける余地が広いからです。もちろん、うまくいけば、ですが。
モデル群はかなり幅広く、9B Dense、31B Dense、35B MoE、397B MoE が用意されています。
大規模モデルの話だけだと「結局、お金をかけた勝負でしょ」と思いがちですが、Ornith-1.0はそこを少し崩してきます。
記事では、Ornith-1.0-9B が edge device、つまり端末寄りの軽い環境でも動かせるサイズなのに、かなり強い結果を出したとしています。
Terminal-Bench 2.1 で 43.1、SWE-Bench Verified で 69.4。しかも、より大きい Gemma 4-31B などと同等か上回る場面があるというのは、なかなか気持ちがいい結果です。
個人的には、ここがかなり重要だと思います。
LLMの世界って、どうしても「でかいモデルが勝つ」で話が終わりがちです。でも本当に実務に入ると、GPUを食い尽くす巨獣より、そこそこ小さくて賢いモデルのほうが使いやすいことが多い。端末で動くならなおさらです。
Ornith-1.0は、その現実的なラインをかなり意識しているように見えます。
Ornith-1.0の核は、self-improving training framework です。
難しく聞こえますが、要するに「モデルが少しずつ自分のやり方を改善していく学習方法」です。
記事の説明をかみ砕くと、RL（reinforcement learning、報酬を使って振る舞いを改善する学習）の各ステップで、モデルはまず scaffold を提案し、その scaffold に沿って解決案を出します。そして、その結果に対する報酬が、解法だけでなく scaffold 側にも返る。
つまり、モデルは
“答えがよかったか” と “その答えを引き出した進め方がよかったか” を同時に学ぶ
わけです。
これ、地味にすごいです。
普通の学習は「この答えが正しいか」で終わることが多い。でも現実の開発では、正解を出すだけでは足りなくて、そこに至る手順や試行錯誤の設計がめちゃくちゃ大事です。Ornith-1.0は、その面倒な部分までモデル化しようとしている。
しかも、訓練を繰り返すうちに、タスクの種類ごとに「こういう進め方が効く」という戦略が勝手に育つ、としています。
このあたりはかなり“進化”っぽい話で、うまく回れば本当に強そうです。
ここが現実的で、好感が持てるところです。
モデルに自分の scaffold を作らせると、当然 reward hacking の問題が出ます。reward hacking は、ざっくり言えば「本当に課題を解くのではなく、評価をすり抜けるズルい挙動で点を取ること」です。
たとえば記事では、
といったズルがありうると説明しています。
これはAIが賢いというより、評価系が雑だといくらでも穴を突かれるという、かなり人間くさい問題です。正直、ここをちゃんと書いているのは好印象でした。
対策は3層です。
まず、外側の境界を固定します。環境、ツールの範囲、テストの隔離は変更不可にして、モデルは内側の policy scaffold だけをいじれるようにする。
次に、決定的な monitor が境界違反を検出し、怪しい行動は報酬ゼロにする。
さらに、許されたツールの範囲内でもズルをしないかを、凍結した LLM judge が後ろで見張る。
この構えは、かなり実戦的です。
「モデルを自由にすれば賢くなる」ではなく、自由にしたぶんだけ監視も必要という、当たり前だけど面倒な事実をちゃんと受け止めている。ここを雑にすると、ベンチマークは伸びても実運用では信用できないので。
記事の後半では、pipeline-RL を使う非同期学習の話が出てきます。
これは長いロールアウト、つまり長い試行の列を扱うときに、古くなった policy の影響を抑える工夫です。
ここで出てくる数式は、ざっくり言えば
「古いトークンほど重みを下げ、古すぎるものは切る」
という仕組みを表しています。
難しい式を全部追わなくても、本質はシンプルです。
学習中は、モデルが少し前の自分の行動を見ながら更新されるので、時間がたった古い出力をそのまま強く信じるとズレが出ます。そこで、古いものには低い重みを付けて、学習のノイズを減らしているわけです。
こういう処理は華やかではないけれど、実際にはかなり大事です。
派手なアーキテクチャより、こういう地味な安定化のほうが最終的な性能を押し上げることはよくあります。
Ornith-1.0-397B は、Terminal-Bench 2.1 で 77.5、SWE-Bench Verified で 82.4 を出し、Claude Opus 4.7 を上回ったとしています。
また、同規模のオープンソース勢として MiniMax M3 や DeepSeek-V4-Pro より良い、と主張しています。
35B版もかなり強く、同サイズの Qwen や Gemma 系より高い成績を出しています。
9B版も小型のわりに健闘していて、むしろ「小さくてもここまでやれるのか」という驚きが強いです。
もちろん、ベンチマークは万能ではありません。
どんな評価にも癖があるし、使う harness や設定で結果は変わります。記事の脚注でも、Terminal-Bench や SWE-Bench の評価条件、コンテキスト長、temperature などがかなり細かく書かれていました。
このへんは大事で、**“数値が高い” だけで終わらず、どう測ったかを見るべき**です。そこを読み飛ばすと、だいたい痛い目にあいます。
Ornith-1.0は、単なる「高性能なコード生成AI」の発表ではないと思います。
むしろ、モデルが解法を作るだけでなく、解法を引き出す工程そのものを改善するという方向を、かなり本気で押し進めた例です。
これが広がると、開発支援のあり方は変わるかもしれません。
今までのLLMは、「このバグ直して」「この関数書いて」と頼む感じでした。でも agentic coding が本当に育つと、モデルはテストを走らせ、失敗を見て、やり方を調整し、よりよい作業の組み立て方まで自分で学ぶようになる。
そうなると、人間が見るのはコードそのものより、どういう探索をしたか になります。
個人的には、ここが一番おもしろいです。
コード生成の未来って、きれいな一発回答ではなく、むしろ「ぐだぐだ試しながら最終的に正解へたどり着く力」のほうにあるのではないか、と思っています。Ornith-1.0は、その方向にかなり真っ直ぐ振っている。
