AIツール2026年8月更新

Ornith-1.5とは?自己改善型オープンモデルの性能・3サイズ・必要VRAM・Opus 4.8との差を解説

公開日: 2026/08/20
Ornith-1.5とは?自己改善型オープンモデルの性能・3サイズ・必要VRAM・Opus 4.8との差を解説

この記事のポイント

Ornith-1.5は、モデル自身が学習課題と評価環境を生成して鍛えるMITライセンスのオープンウェイトLLMです。397B/35B/9Bの違い、Claude Opus 4.8との17指標の勝敗、必要VRAM、導入手順、ベンチマークの読み方まで整理します。

Ornith-1.5(オーニス 1.5)は、モデル自身が学習課題・評価環境・解答を生成し、その3つを同時に強化学習で改善する「自己改善ループ」で鍛えられたオープンウェイトLLMファミリーです。MITライセンスで重みがHugging Faceに公開されており、商用利用も無料ですが、公式のホスト型APIは現時点で提供されておらず、自前のGPUで動かすことが前提になります。

Ornith-1.5の定義と開発元、397B/35B-A3B/9Bという3サイズの違い、話題になっている「Claude Opus 4.8並み」という評価の中身、必要VRAMと導入手順、そして公式ベンチマークをそのまま信じてよいのかという検証上の留保まで、導入判断に必要な材料をまとめます。ローカルLLMでコーディングエージェントを動かしたいエンジニア、機密コードを外部APIに出せない企業の技術選定担当者を想定しています。

Ornith-1.5を検討する前に押さえる3点

  1. 強いのはターミナル操作系のコーディング。Terminal-Bench 2.1で86.1(Terminus-2ハーネス)を記録し、Claude Opus 4.8(85.0)をわずかに上回った一方、Frontier-BenchやNL2Repoなど難度の高い課題では依然として大差で負けている。公式表の17指標で数えると397Bは7勝10敗。
  2. 実用ラインは35B-A3B。アクティブ3BのMoEでSWE-bench Verified 79.0を出し、Q4_K_M量子化なら約21.7GBのファイルサイズ。RTX 4090クラスから現実的に扱える。
  3. 無料だが「タダで使える」わけではない。モデル利用料はゼロでも、397Bはbf16で約800GB(8×H200相当)が必要。コストがトークン単価からGPU調達・運用に置き換わる構造を理解してから検討すべき。

Ornith-1.5とは何か

Ornith-1.5の開発元ornith-aiのHugging Face公式Organizationページ

出典: Hugging Face - ornith-ai 公式Organization

Ornith-1.5は、AI研究スタートアップDeepReinforceのチームが開発し、2026年8月に公開されたオープンウェイトの大規模言語モデルです。公式ブログの表記は「Aug. 2026」で、2026年8月19日(現地時間)に公開されたと複数の海外メディアが報じています

項目

内容

名称

Ornith-1.5(オーニス 1.5)

開発元

Ornith Team/DeepReinforce(Hugging Face Orgは ornith-ai、GitHub Orgは deepreinforce-ai

公開時期

2026年8月(公式ブログ表記)。8月19日公開と報道

ライセンス

MIT(商用利用・再配布・ファインチューニング自由)

提供形態

Hugging Faceでの重み配布のみ。公式のホスト型API・チャットUIは確認できず

モデル種別

テキスト生成の推論モデル(thinkブロックを出力)/ツール呼び出し対応

コンテキスト長

262,144トークン(YaRN factor 4.0で約100万トークンまで拡張可)

ベース

Ornith-1.0を継承。Ornith-1.0はQwen3.5とGemma 4の上に継続事前学習を行って構築

得意領域

エージェント型コーディング(ターミナル操作・SWEタスク)、ツール呼び出し、Web検索系エージェント

注意しておきたいのは、公式の一次配布がHugging Faceの重みだけである点です。OpenAIやAnthropicのように「APIキーを取って課金すれば使える」形にはなっておらず、vLLM・SGLang・llama.cpp・Ollamaなどのランタイムで自前ホストするか、サードパーティのホスティングを探す必要があります。オープンウェイトモデル全般の潮流についてはThinking Machines Inklingの解説記事Anthropicのオープンウェイトに対する立場も参考になります。

なお、Hugging Faceのコレクションに収録されている12リポジトリはすべてText Generationタグで、画像・音声入力への対応は公式には記載されていません。マルチモーダル対応をうたう情報を見かけても、現時点では公式仕様として確認できない点に留意してください。

3サイズのラインナップと選び分け

Ornith-1.5-35B-A3Bの公式モデルカード(Hugging Face)

出典: Hugging Face - Ornith-1.5-35B-A3B 公式モデルカード

Ornith-1.5は、用途と機材に応じて3サイズが用意されています。前世代にあった31B Denseは廃止され、3構成に整理されました。

モデル

構成

総パラメータ

アクティブ

想定する使い手

Ornith-1.5-397B

MoE

397B

公式に明記なし

データセンター/複数GPUノードを持つ組織

Ornith-1.5-35B-A3B

MoE

36B(HF表記)

3B/トークン

ワークステーション/実用の中心ライン

Ornith-1.5-9B

Dense

9B

9B

単一GPU/エッジ・ノートPC

加えて、量子化・変換済みのビルドが同時公開されています。

  • bf16本体: Ornith-1.5-9B / -35B-A3B / -397B
  • GGUF(llama.cpp・Ollama向け): 3サイズすべて
  • FP8 / NVFP4: 35B-A3B と 397B
  • MLX(Apple Silicon向け): 9B と 35B-A3B

公式ブログではスマートフォン上での動作を想定した「Ornith-1.5-9B-Mobile」への言及もありますが、Hugging Faceのコレクション一覧では独立したリポジトリを確認できませんでした。GGUF/MLXビルドがその役割を担っている可能性があり、現時点では「公式ブログで言及されている」段階として捉えるのが妥当です。

どのサイズを選ぶか

こういう状況なら

選ぶべきサイズ

理由

H200/H100を8枚単位で確保できる

397B

フラッグシップ性能。Terminal-Bench 86.1

RTX 4090/A6000クラスが1〜2枚ある

35B-A3B

Q4_K_Mで約21.7GB。コーディング性能と機材要件のバランスが最も良い

VRAM 8〜16GBのGPU1枚、またはApple Silicon

9B

Q4_K_Mで約5.63GB。軽量タスク・補完用途向け

GPUを用意する予定がない

Ornith-1.5は選択肢に入らない

公式APIが存在しないため

自己改善ループ:Ornith-1.5の中核

Ornith-1.5の最大の特徴は、モデルが自分で問題集を作り、その採点基準(評価環境)も作り、実際に解いて、この3つを同時に上達させるという学習の仕組みです。前世代Ornith-1.0では「評価環境(scaffold)」と「解答(rollout)」の2段階を最適化していましたが、1.5ではタスク生成そのものまで最適化対象に加えられました。

学習ループは3段階で構成されます。

  1. タスク提案: 環境やコードベース、タスク種別の高レベル指示、過去の解答履歴を与え、すでに解ける問題より一段難しいタスクを生成する
  2. scaffold(harness)生成: そのタスク専用の指示・ツール・分解戦略・オーケストレーションを設計する
  3. 解答ロールアウト: タスクとscaffoldを条件に解答を生成する

報酬は3段階すべてに伝播し、GRPOで同時に最適化されます。結果として「モデルが強くなる → より難しいタスクを作れる → 学習信号が良くなる」という閉ループが回る設計です。自己改善という概念そのものについてはRecursive Superintelligenceの解説も併せて読むと理解が深まります。

報酬設計が「掛け算」である意味

公式ブログでは、タスクの報酬が次の乗算形式で定義されています。

R_task = V(q,s) × D(q,s,{τ}) × N(q)

信号

意味

内容

V(検証可能性)

有効で検証できる学習環境か

scaffoldが正常に実行され、正解が通り不正解が落ちるか。V=0 なら報酬もゼロになるハードゲート

D(フロンティア難易度)

難易度が能力の限界近くか

N回ロールアウトの成功率pを exp(-(p-p*)²/2σ²) で評価。目標成功率 p* は0.2

N(新規性)

過去タスクと重複していないか

既存タスクバッファとの最大類似度を1から引いた値

掛け算になっているため、3条件のどれか1つでも欠けると報酬がゼロになります。「壊れているが難しそうに見えるタスク」で報酬を稼ぐことを構造的に防ぐ設計です。

評価環境側にも同様の報酬 R_harness = C(q,h) × F(h,{τ}) × H(h) が用意され、Cはタスク仕様への整合、Fは報酬の忠実性、そしてHは「リワードハッキング耐性」(評価器の抜け道やショートカットに対する強さ)を測ります。自己生成データで学習させるアプローチにおいて最大の懸念であるリワードハッキングに、設計段階から対策を入れている点が技術的な見どころです。

「Claude Opus 4.8並み」の中身を17指標で分解する

比較対象となるAnthropicのClaude公式ページ

出典: Anthropic 公式サイト - Claude

397Bがしのぎを削れているのはターミナル操作系とコード修正の一部で、難問推論・長尺タスク・ツール操作では明確な差が残っています。公式表の17指標で数えると、Ornith-1.5-397BはClaude Opus 4.87勝10敗です。

ベンチマーク

Ornith-1.5 (397B)

Claude Opus 4.8

判定

Terminal-Bench 2.1 (Terminus-2)

86.1

85.0

◯ Ornith

Terminal-Bench 2.1 (Claude Code)

85.2

78.9

◯ Ornith

SWE-bench Verified

86.0

85.8

◯ Ornith

SWE-bench Pro

65.1

68.0

× Opus

SWE-bench Multilingual

79.6

75.7

◯ Ornith

DeepSWE

56.0

59.0

× Opus

Frontier-Bench v0.1

13.5

21.1

× Opus(大差)

NL2Repo

59.5

69.7

× Opus(大差)

SWE Atlas – QnA

55.6

59.7

× Opus

HLE(ツールなし)

44.6

49.8

× Opus

HLE(ツールあり)

56.1

57.9

× Opus

GPQA Diamond

92.8

93.6

× Opus

MCP-Atlas

80.0

82.2

× Opus

Toolathlon-Verified

71.2

76.2

× Opus

WideSearch

80.8

72.9

◯ Ornith

BrowseComp

86.6

84.3

◯ Ornith

ClawEval

81.4

80.2

◯ Ornith

勝敗を領域ごとに並べ直すと、得意・不得意の輪郭がはっきりします。

  • 勝っている領域: ターミナル型エージェント(Terminal-Bench 両ハーネス)、既存リポジトリのバグ修正(SWE-bench Verified/Multilingual)、Web検索系(WideSearch/BrowseComp)、実タスク分布のコードベンチ(ClawEval)
  • 負けている領域: 難問推論(HLE/GPQA)、ゼロからのリポジトリ生成(NL2Repo 59.5 vs 69.7)、新規性の高い難課題(Frontier-Bench 13.5 vs 21.1)、ツール操作(MCP-Atlas/Toolathlon)
  • つまり「Opus 4.8並み」という表現は、得意領域を切り取れば正しいが、全面的に肩を並べているわけではない

オープンモデル同士の位置づけ

公式表には他社モデルも並んでおり、Ornith-1.5-397Bがオープンモデル最強というわけでもありません

ベンチマーク

Ornith-1.5 (397B)

DeepSeek-V4-Flash-0731 (284B)

GLM-5.2 (753B)

Kimi K3 (2.8T)

Terminal-Bench 2.1 (Terminus-2)

86.1

82.7

81.0

88.3

SWE-bench Verified

86.0

81.6

83.0

86.2

DeepSWE

56.0

54.4

46.2

67.5

Frontier-Bench v0.1

13.5

6.1

5.1

23.0

GPQA Diamond

92.8

91.4

91.2

93.5

MCP-Atlas

80.0

74.6

77.8

82.3

BrowseComp

86.6

84.8

85.6

91.2

Terminal-Bench・DeepSWE・Frontier-Bench・BrowseCompではKimi K3が上回っています。一方、DeepSeek V4 Flash 0731GLM 5.2に対しては、Ornith-1.5-397Bがほぼ全面的に優位です。「同クラスのオープンモデルの中では上位、ただし最上位ではない」というのが実態に近い評価になります。

35B-A3Bと9B:実際に手元で動かすサイズの実力

35B-A3B:アクティブ3Bで大規模モデルを上回る

実務で最も現実的な選択肢は35B-A3Bです。 アクティブパラメータが3Bにもかかわらず、コーディング系では11倍規模のQwen3.5-397Bをほぼ全面的に上回っています。

ベンチマーク

Ornith-1.5-35B-A3B

Ornith-1.0-35B-A3B

Qwen3.6-35B-A3B

Qwen3.5-397B

Terminal-Bench 2.1 (Terminus-2)

67.8

64.2

52.5

53.5

Terminal-Bench 2.1 (Claude Code)

68.5

62.8

49.2

48.6

SWE-bench Verified

79.0

75.6

73.4

76.4

SWE-bench Pro

59.6

50.4

49.5

51.6

NL2Repo

46.2

34.6

29.4

36.8

GPQA Diamond

89.2

86.2

86.0

88.4

HLE(ツールあり)

33.4

30.1

28.9

48.3

WideSearch

67.8

63.4

60.1

74.0

BrowseComp

67.6

63.5

62.0

78.6

一方で、汎用推論(HLE)と検索系(WideSearch/BrowseComp)は大規模モデルに明確に劣ります。「コーディングエージェント用途に振り切ったモデル」と割り切って使う前提が必要です。同世代の30Bクラスとの比較では、Meta Muse Glimmer-30BがMCP-Atlasで75.5とOrnithの70.2を上回っており、ツール操作を重視するなら別の選択肢も検討する余地があります。

9B:同サイズ帯では圧倒、ただし公式ブログの表現には注意

ベンチマーク

Ornith-1.5-9B

Ornith-1.0-9B

Qwen3.5-9B

Qwen3.6-35B-A3B

Terminal-Bench 2.1 (Terminus-2)

46.2

43.1

21.3

52.5

SWE-bench Verified

70.6

69.4

53.2

73.4

SWE-bench Multilingual

54.4

52.0

39.7

67.2

NL2Repo

32.4

27.2

16.2

29.4

GPQA Diamond

86.4

82.5

81.7

86.0

BrowseComp

56.4

44.8

41.5

62.0

同じ9BクラスのQwen3.5-9Bに対しては、Terminal-Benchで21.3→46.2と圧倒しています。ただし、公式ブログの「はるかに大きいモデルを大幅に上回る」という表現は、9Bに関しては公式表の数字と食い違います。Qwen3.6-35B-A3Bには多くの項目で負けているため、9Bの評価は「同サイズ帯では強い」に留めるのが正確です。

公式ベンチマークをどこまで信じられるか

現時点でOrnith-1.5のスコアはすべて開発元の自己申告であり、第三者による独立検証は存在しません。導入判断ではこの前提が最も効いてきます。数字自体を疑う必要はありませんが、以下の条件を理解したうえで読むべきです。

公式が開示している実行条件

公式ブログのfootnoteには、他社モデルとの比較を読むうえで無視できない条件が書かれています。

項目

内容

試行回数

全結果が5回の独立実行の平均(単発のブレを排除しており、この点は誠実)

チャットテンプレート

Terminal-Bench評価時、学習・推論の一貫性のためにQwenチャットテンプレートを調整したと明記

ハーネス改変

HarborをvLLMのreasoning_contentキーに合わせて改変

判定モデル

HLEの判定にClaude Opus 4.6、MCP-Atlasの判定にClaude Opus 4.8を使用

コンテキスト

Terminal-Benchは128K、SWE-bench系は256K、NL2Repoは400K

アンチハッキング

SWE-bench系はGit履歴を削除しネットワークを遮断、NL2Repoは対象リポジトリ・pipパッケージへのアクセスを遮断

Claude Opus 4.8と競っているベンチマークの一部で、判定役としてClaudeを使っている点、自社モデル側だけチャットテンプレートを調整している点は、条件の対称性という観点で読者が把握しておくべき情報です。一方で、5回平均・アンチハッキング処理の明記は、この種のリリースとしては透明性が高い部類に入ります。

独立再現との食い違い

Hacker Newsの議論スレッドでは、あるユーザーがOrnith-1.5-35BとQwen3.8-27Bを自前で比較実行し、DeepSWEでOrnith 22.0に対しQwen3.8-27Bが42.2という、公式の印象とは異なる結果を報告しています。ただしこれは非査読の1件の非公式な実行であり、アクティブパラメータ数も異なるため厳密な同条件比較ではありません。比較対象となったQwen3.8-27BはApache 2.0の商用可モデルで、ローカル用途では有力な代替候補です。

海外の解説メディアも「自己改善の仕組み自体は技術的に妥当に見えるが、ベンチマークの主張は本番導入前に独立検証が必要」という評価に落ち着いています。日本語圏の記事ではこの論点がほとんど扱われていないため、社内で導入を提案する際は必ず触れておくべきポイントです。

料金:モデルは無料、実質コストはGPUに置き換わる

Ornith-1.5-397Bの公式モデルカード。bf16で約800GBのGPUメモリを要する

出典: Hugging Face - Ornith-1.5-397B 公式モデルカード

Ornith-1.5のモデル利用料は無料です。MITライセンスで公開されており、商用・研究のいずれも制限はありません(帰属表示のみ)。 ただし、公式のホスト型APIとトークン単価は存在しないため、コストはすべてGPU調達と推論インフラの運用費に置き換わります。

bf16での最小構成

モデル

bf16サイズ

最小構成

397B

約800GB

8× H200 141GB(8-way tensor parallel)/vLLMのmemory utilization 0.90推奨

35B-A3B

約70GB

2× 80GB GPU

9B

約19GB

単一80GB GPU

GGUF量子化のファイルサイズ(必要メモリの目安)

量子化

397B

35B-A3B

9B

Q4_K_M

241 GB

21.7 GB

5.63 GB

Q5_K_M

282 GB

25.3 GB

6.47 GB

Q6_K

326 GB

29.2 GB

7.36 GB

Q8_0

422 GB

37.8 GB

9.53 GB

BF16

約800 GB

71.1 GB

17.9 GB

よくある誤解:「アクティブ3B」=「3GBで動く」ではない

35B-A3Bは1トークンあたり3Bのパラメータしか活性化しませんが、どのエキスパートが選ばれるかは事前にわからないため、全パラメータをメモリに保持する必要があります。「アクティブ3Bだから軽い」という理解は誤りで、必要メモリは総パラメータ量(Q4_K_Mで約21.7GB)で見積もってください。MoEモデルを検討する際に最も多い勘違いです。

参考値として、前世代Ornith-1.0を対象にした国内の実測レポートでは、9B Q4_K_Mが約8.05GiB(VRAM 8GB級から動作し、12〜16GBで快適)、35B MoE Q4_K_Mが約15.5GB(RTX 5080 16GBはシステムRAMへのオフロード併用で動作、24GB以上推奨)とされています。これは1.0の測定値であり、1.5でそのまま再現される保証はありませんが、機材選定の目安にはなります。

API課金型と比べるべきか

外部APIにコードを渡せる環境なら、DeepSeek V4 Flashのような低単価APIのほうが総額で安く済むケースが多くあります。セルフホストが合理的になるのは、次のいずれかに当てはまる場合です。

  • 機密コードを外部に送信できない(重みを自社環境に置けばデータは外に出ない)
  • 推論量が大きく、従量課金だと月額が膨らむ
  • ファインチューニング・蒸留して自社用途に最適化したい(MITなので自由)
  • オフライン環境・閉域網で動かす必要がある

導入方法と必要なランタイム

Ornith-1.5の実行に必要なランタイムの一つvLLMの公式リポジトリ

出典: GitHub - vllm-project/vllm 公式リポジトリ

対応ランタイムとバージョン要件

Ornith-1.5は比較的新しいランタイムを要求します。古い環境では動きません。

  • vLLM ≥ 0.19.1(tool-callパーサー+reasoningパーサー対応)
  • SGLang ≥ 0.5.9
  • Transformers ≥ 5.8.1
  • llama.cpp(GGUF)
  • Ollama / LM Studio / Jan / Docker Model Runner
  • Unsloth Studio(高速推論・ファインチューニング)
  • MLX(Apple Silicon向け・9B / 35B-A3Bのみ)

いずれもOpenAI互換エンドポイントを提供するため、既存のコーディングエージェントやエージェントフレームワークからそのまま接続できます。ローカル実行の入口としてはOllamaが最も手軽です。

起動コマンド例

# vLLM(397B・データセンター構成)
vllm serve ornith-ai/Ornith-1.5-397B \
  --tensor-parallel-size 8 \
  --max-model-len 262144

# Ollama(9B・最も手軽)
ollama run hf.co/ornith-ai/Ornith-1.5-9B-GGUF:Q4_K_M

# llama.cpp(35B-A3B・OpenAI互換サーバとして起動)
llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M --port 8000

推奨サンプリングパラメータ

用途

設定

一般利用

temperature=0.6, top_p=0.95, top_k=20

公式ベンチマークの再現

temperature=1.0

YaRNの扱いに注意

コンテキストは262,144トークンがネイティブで、YaRN factor 4.0を適用すれば約100万トークンまで拡張できます。ただし公式モデルカードは、OSS実装のYaRNがスケーリング係数をリクエスト横断で一律適用するため、通常長の入力では品質が落ちると明記しています。長文が必要な処理を行うときだけ有効化し、常時オンにはしないでください。

弱み・制約の整理

制約

内容

公式APIがない

ホスト型の従量課金APIやチャットUIは確認できず。自前GPUかサードパーティのホスティングが必要

397Bは個人ではまず動かない

bf16で約800GB。8× H200 141GBが推奨構成

マルチモーダル非対応(公式記載なし)

HFの12リポジトリすべてText Generationタグ。画像・音声入力の記載はない

新しいランタイムが必須

Transformers ≥5.8.1 / vLLM ≥0.19.1 / SGLang ≥0.5.9

YaRNの静的適用問題

常時有効化すると通常長入力の品質が落ちる

難課題・新規生成が弱い

Frontier-Bench 13.5(Opus 4.8は21.1)、NL2Repo 59.5(同69.7)

オープンモデル最強ではない

Kimi K3にTerminal-Bench・DeepSWE・Frontier-Bench・BrowseCompで下回る

日本語性能の公式データがない

日本語ベンチマークの公式スコアは未公開。SWE-bench Multilingualはコードの多言語対応であり自然言語の日本語能力ではない

セーフティ評価が未公開

公式ブログ・モデルカードにレッドチーミング結果や利用ポリシーの記載を確認できない

日本語での実用性については、国内エンジニアがRTX 4090・llama.cpp(GGUF Q4_K_M)で35B-A3Bと9Bを検証した公開スクラップがあり、日本語タスク・システムプロンプトによるキャラ設定・マルチターン対話は問題なくこなせた、9Bは35B-A3Bと比べてわずかに品質が落ちる、と報告されています。ただしこれは個人の実機検証であり、公式ベンチマークによる裏付けはありません。

業務導入時に押さえるべきセキュリティ観点

MITライセンスで無料だからといって、すぐ本番投入できるわけではありません。 ライセンスの自由さとモデルの安全性は別問題です。導入検討時には以下を分けて考えてください。

学習側で公式が対策していること

  • リワードハッキング対策が報酬設計に組み込まれている(harness報酬のH(h)が評価器の抜け道への耐性を測る)
  • タスク妥当性のハードゲートV=0なら報酬ゼロ。壊れたタスクが「難しそう」という理由で報酬を得るのを防ぐ)
  • 評価時のアンチハッキング(SWE-bench系はGit履歴削除+ネットワーク遮断、NL2Repoは対象リポジトリ・pipパッケージ遮断)
  • Ornith-1.0では、不変の環境境界・ツールアクセスの決定的モニタリング・凍結LLM判定器という3つのセーフガードが説明されていた

運用側で自社が担保すべきこと

  1. 学習データの説明可能性が低い。モデル自身が生成したタスクと環境で学習しているため、「どんなデータで訓練されたか」を外部から追跡することは人手キュレーション型より難しい
  2. ローカル実行でもエージェント用途の危険度は下がらない。ターミナル操作やファイル書き換えを行う以上、権限分離・サンドボックス・実行前承認フローは必須です(AIエージェントによるデータ削除事故の事例も参考に)
  3. 公式のセーフティ評価・利用ポリシーが公開されていないため、業務利用では自社側でレッドチーミングとガードレール整備が必要
  4. 重みを自社環境に置ける=データが外部に出ないのは明確なメリット。機密コードを扱う組織にとっては最大の採用理由になり得ます
  5. サードパーティのホスティングを使う場合は、そのプロバイダのデータ取り扱いポリシーを別途確認すること

推奨する導入ステップ

自己申告ベンチマークしか存在しない現状では、次の3段階で進めるのが安全です。

  1. PoC: 9Bまたは35B-A3BのQ4_K_Mを1台のGPUで動かし、自社の実タスク(バグ修正・リファクタ・テスト生成)で挙動を見る
  2. 独立評価: 公式スコアではなく、自社のコードベースで自前のタスクセットを作って測る。Claude Opus 4.8など既存の選択肢と同条件で比較する
  3. 本番: サンドボックス・権限分離・監査ログを整えたうえで、限定的な業務から段階導入する

こんな人におすすめ

  • 機密コードを外部APIに送信できない組織。重みを自社環境に置けるため、データが外に出ない構成を作れます
  • エージェント型コーディングを大量に回す開発チーム。Terminal-Bench・SWE-bench系でオープンモデル上位の性能があり、従量課金の上振れを気にせず走らせられます
  • RTX 4090クラスのGPUを持つエンジニア。35B-A3BのQ4_K_M(約21.7GB)が現実的な実用ラインです
  • モデルをファインチューニング・蒸留して自社用途に最適化したい企業。MITライセンスで改変・再配布に制限がありません
  • オフライン・閉域網で動かす必要がある環境
  • 自己改善型の学習手法そのものに関心がある研究者・技術者。GitHubにサービングレシピとベンチマーク結果が同梱されています

おすすめしない人

  • GPUを用意する予定がない個人・企業。公式のホスト型APIがないため、そもそも使えません
  • ブラウザでチャットとして使いたい人。公式チャットUIは提供されていません
  • 画像・音声を扱いたい人。公式にはテキスト生成のみで、マルチモーダル対応の記載がありません
  • 難問推論や新規プロジェクトのゼロからの生成が主用途の人。Frontier-BenchやNL2RepoではClaude Opus 4.8との差が大きく、この領域は商用フロンティアモデルのほうが有利です
  • 第三者検証済みのスコアがないと稟議が通らない組織。現時点で独立検証は存在せず、自社での評価工数を見込む必要があります
  • 日本語の文章生成が主目的の人。日本語性能の公式データがなく、そもそもコーディングエージェント向けに最適化されたモデルです

Ornith-1.0からの変更点

項目

Ornith-1.0(2026年6月)

Ornith-1.5(2026年8月)

自己改善の範囲

scaffold+rolloutの2段階

タスク生成を含む3段階の同時最適化

モデル構成

9B Dense / 31B Dense / 35B MoE / 397B MoE の4構成

397B MoE / 35B-A3B MoE / 9B Dense の3構成(31B Denseを廃止)

Terminal-Bench 2.1 (Terminus-2, 397B)

77.5

86.1

SWE-bench Verified (397B)

82.4

86.0

DeepSWE (397B)

8.0

56.0

Frontier-Bench (397B)

2.7

13.5

量子化版

FP8 / GGUF / MLX / NVFP4を同時公開

特筆すべきはDeepSWEの8.0→56.0とFrontier-Benchの2.7→13.5という伸びです。長尺のエージェントタスクで実質的に機能していなかった領域が、タスク生成まで含めた自己改善ループの導入で一気に立ち上がった形になります。

よくある質問

Q. Ornith-1.5をクラウドのAPIとして使えますか?
現時点で公式のホスト型APIは提供されていません。Hugging Faceから重みをダウンロードし、vLLM・SGLang・llama.cpp・Ollamaなどで自前ホストするのが前提です。サードパーティによるホスティング提供の有無は、利用前に各サービスの最新情報を確認してください。

Q. 商用サービスに組み込んでも問題ありませんか?
MITライセンスのため、商用利用・改変・再配布に制限はありません。ただし公式のセーフティ評価や利用ポリシーが公開されていないため、出力に対するガードレールは自社側で設計する必要があります。

Q. ノートPCで動きますか?
9BのQ4_K_M(約5.63GB)であれば、VRAM 8GB級のGPUやApple Silicon(MLXビルド)で動作が見込めます。35B-A3BはQ4_K_Mで約21.7GBが必要で、ノートPCでは厳しい構成です。

Q. 「アクティブ3B」なので3GB程度のメモリで動きますか?
動きません。MoEは推論時に一部のエキスパートしか活性化しませんが、全パラメータをメモリに保持する必要があります。必要メモリは総パラメータ量ベース(Q4_K_Mで約21.7GB)で見積もってください。

Q. Claude Opus 4.8を置き換えられますか?
用途によります。ターミナル操作を伴うコード修正やWeb検索系のエージェントであれば十分に競合しますが、難問推論・リポジトリのゼロからの生成・ツール操作の総合力では差が残ります。既存のワークフローを一斉に置き換えるのではなく、タスク種別で使い分けるのが現実的です。

Q. 公式ベンチマークの数字はそのまま信じてよいですか?
5回平均・アンチハッキング処理が明記されている点は誠実ですが、第三者による独立検証はまだ存在しません。加えて、評価時に自社モデル側のチャットテンプレートを調整している点、一部ベンチマークの判定にClaudeを使用している点も踏まえ、本番導入前には自社タスクでの評価をおすすめします。

Q. 日本語は使えますか?
公式の日本語ベンチマークスコアは公開されていません。国内エンジニアによる実機検証では、日本語での対話やシステムプロンプトによる指示は問題なく動作したとの報告があります。ただし、このモデルの主戦場はコーディングエージェントであり、日本語の文章生成品質を期待する用途には向きません。

まとめ

Ornith-1.5は、モデルが自ら課題・評価環境・解答を生成して同時に鍛える自己改善ループという新しい学習アプローチを、MITライセンスのオープンウェイトとして公開した点に価値があります。397BはTerminal-Bench 2.1で86.1を記録しClaude Opus 4.8を上回りましたが、17指標全体では7勝10敗で、難問推論や新規リポジトリ生成では明確な差が残っています。

実務的に検討する価値が高いのは35B-A3Bです。アクティブ3Bで11倍規模のモデルをコーディング系で上回り、Q4_K_M量子化なら約21.7GBでRTX 4090クラスから扱えます。モデル自体は無料でも、コストはGPU調達と運用に置き換わる構造を理解したうえで、まずは9Bまたは35B-A3Bで自社タスクを試し、公式スコアではなく自前の評価結果で判断する進め方をおすすめします。

現時点で独立検証が存在しないこと、セーフティ評価が未公開であることは、業務導入における実質的なハードルです。オープンモデル全体の勢力図は中国製AIモデルの利用シェア動向も併せて見ておくと、選択肢の全体像を掴みやすくなります。

AIツールの導入でお困りですか?

お客様のビジネスに最適なAIツールをご提案します。まずは無料相談から。

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

採用募集中 AI時代の実装力が、身につく。FDE募集中・副業可・未経験歓迎枠あり
AI Revolution Growth Arrow

AIでビジネスを革新しませんか?

あなたのビジネスにAIがどのような価値をもたらすかをご提案いたします。