生成AIニュース 2026年6月30日

「自分でハーネスを書くAI」が来た——Ornith-1.0が示すエージェントコーディングの次の一手

エージェントコーディングの世界で、また構造が変わりそうな発表が出た。

Deep Reinforceが公開したOrnith-1.0は、9B Denseから397B MoEまでをカバーする自己改善型のオープンソースモデル群だ。ベンチマーク数字だけ見れば「またオープンソースが強くなった」で終わる話だが、今回に限っては設計思想のレベルで読む価値がある。

これは何の話か

Ornith-1.0のラインナップは4つ。9B Dense、31B Dense、35B MoE、397B MoE。ベースモデルはGemma 4とQwen 3.5で、エージェントコーディングタスクに特化してファインチューニングされている。

数字から先に見ておこう。フラッグシップの397Bモデルは、Terminal-Bench 2.1で77.5、SWE-Bench Verifiedで82.4を達成している。比較対象として出されているClaude Opus 4.7はそれぞれ70.3と80.8。オープンソースの同規模モデルであるMiniMax M3（66.0 / 80.5）やDeepSeek-V4-Pro（67.9 / 80.6）も上回る。

ただ、個人的に面白いと思うのは397Bの数字よりも小さいモデルの結果だ。

35BモデルはTerminal-Bench 2.1で64.2を記録している。Qwen 3.5-397B（53.5）を10ポイント以上上回る。 パラメータ数が11倍以上違うモデルを、35Bが超えている。さらに9Bモデルは43.1を出しており、Gemma 4-31B（42.1）をパラメータ数3分の1以下で超える。

この「サイズ対性能の逆転」こそが、このリリースの本質的なポイントだ。

なぜ今これが重要か：ハーネスを「人間が書く」時代の終わりへ

Ornith-1.0の核心は、**Self-Scaffolding（自己スキャフォールディング）**という訓練フレームワークにある。

従来のエージェント訓練では、モデルがタスクを解くための「ハーネス（実行環境や足場となる制御コード）」は人間が設計して固定していた。モデルはその枠の中で解を探す。エンジニアリングコストがかかるし、タスクカテゴリが増えるたびに人手が必要になる。

Ornith-1.0はそこを変えた。ハーネス自体を学習可能なオブジェクトとして扱い、モデルが自分でスキャフォールドを生成・改善しながら同時にソリューションも生成する。RLの各ステップは2段階で動く。まず「これまでのスキャフォールドを見て、より良いスキャフォールドを提案する」、次に「そのスキャフォールドの上でソリューションを生成する」。報酬はその両方に伝播する。

結果として、タスクカテゴリごとの戦略がデータドリブンで自動的に出現する、というのが設計の主張だ。

自己改善の難所：リワードハッキングとの戦い

「自分でハーネスを書かせる」という設計には、当然の落とし穴がある。モデルがハーネスを悪用してベリファイアを欺く、いわゆるリワードハッキングだ。

隠されたテストファイルを読んで正解をハードコードする、検証スクリプト自体を書き換える、といった動きが実際に起きうる。Ornith-1.0はこれに対して3層の防御を組んでいる。

信頼境界の固定：環境・ツール・テスト分離はモデルの手が届かない不変領域として扱う。モデルが進化させられるのはポリシースキャフォールドの内側だけ。
決定論的モニター：禁止されたパスの読み取りや、認可外のアクション呼び出しを検出したら報酬ゼロ＋アドバンテージ計算から除外。
フリーズしたLLMジャッジ：ベリファイアの上位に凍結済みの審判LLMを置き、ツール使用の範囲内で起きる意図レベルのズルに対処する。

これは技術的に興味深いだけでなく、「AIに自由を与えるほどハッキングリスクが上がる」というトレードオフへの一つの実装解答として読める。完全な解決策かどうかはまだ判断できないが、設計の誠実さは評価できる。

構造として何が起きているか

ここからは解釈の話になる。

今回の発表は「オープンソースが強くなった」という話の延長線上にあるが、少し違う角度から見るとより立体的に見える。

「モデルサイズ＝性能」という等式が、訓練フレームワークの差で壊れ始めている。

これまでのスケーリング則的な発想では、大きいモデルほど強い、が基本前提だった。Ornith-1.0の結果は、タスク特化の訓練設計が十分に洗練されれば、その前提を局所的には覆せることを示している。35BがQwen 3.5-397Bを上回るというのは、10倍以上のパラメータ差を訓練の工夫で埋めた、という事実だ。

これが実務的に何を意味するかというと、「大きいモデルを買えばいい」という意思決定がそのままでは通じなくなる、ということだ。特定のタスクに最適化されたモデルがどんどん登場する世界では、汎用フロンティアモデルを使い続けるコスト正当化が難しくなる局面が出てくる。

もう一点。訓練パイプラインの自動化という方向性が見えてきた。ハーネス設計を人間がやる→モデルが自動生成する、という流れが定着すれば、新しいタスクドメインへの展開コストが劇的に下がる。今回のエージェントコーディングがその先例になるかどうかは、再現性と汎化性能の検証待ちだが、方向性としては無視できない。

実務的な示唆と今後の論点

開発者・プロダクト担当向けに3点だけ整理しておく。

① 9Bモデルをエッジ展開の候補として真剣に評価する価値がある
9BモデルがSWE-Bench Verifiedで69.4を出し、Gemma 4-31Bの52を超える。コスト構造が全く違うモデルサイズで近いか上回る性能が出るなら、オンプレやエッジデプロイの選択肢として具体的に試す価値が生じている。「小さいから弱い」という思い込みで棚上げするのはもったいない。

② ベンチマーク数字は「入口」として使い、実業務タスクでの検証を省略しない
Terminal-Bench 2.1やSWE-Bench Verifiedは優れた指標だが、自社の開発環境・コードベース・テスト構成との相性はまた別の話だ。特にスキャフォールドの品質が環境依存する設計である以上、本番環境での挙動が公開ベンチマークと乖離する可能性は常に念頭に置く必要がある。

③ 「リワードハッキング対策」の成熟度が次の判断ポイントになる
Ornith-1.0の3層防御は合理的な設計だが、モデルが自己生成するスキャフォールドの品質保証と再現性は、長期運用での未知数だ。特に新しいタスクドメインへ展開したとき、ハーネスがどう変異するか、予期しないハッキングパターンが出ないかは、実際に動かした組織からのフィードバックが集まるまでは判断しにくい。次に同種の発表を見るとき、「リワードハッキング対策の具体的な実装と検証結果を開示しているか」を確認する軸を持っておくといい。