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

出典: 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は |
公開時期 | 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サイズのラインナップと選び分け

出典: 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段階で構成されます。
- タスク提案: 環境やコードベース、タスク種別の高レベル指示、過去の解答履歴を与え、すでに解ける問題より一段難しいタスクを生成する
- scaffold(harness)生成: そのタスク専用の指示・ツール・分解戦略・オーケストレーションを設計する
- 解答ロールアウト: タスクとscaffoldを条件に解答を生成する
報酬は3段階すべてに伝播し、GRPOで同時に最適化されます。結果として「モデルが強くなる → より難しいタスクを作れる → 学習信号が良くなる」という閉ループが回る設計です。自己改善という概念そのものについてはRecursive Superintelligenceの解説も併せて読むと理解が深まります。
報酬設計が「掛け算」である意味
公式ブログでは、タスクの報酬が次の乗算形式で定義されています。
R_task = V(q,s) × D(q,s,{τ}) × N(q)
信号 | 意味 | 内容 |
|---|---|---|
V(検証可能性) | 有効で検証できる学習環境か | scaffoldが正常に実行され、正解が通り不正解が落ちるか。 |
D(フロンティア難易度) | 難易度が能力の限界近くか | N回ロールアウトの成功率pを |
N(新規性) | 過去タスクと重複していないか | 既存タスクバッファとの最大類似度を1から引いた値 |
掛け算になっているため、3条件のどれか1つでも欠けると報酬がゼロになります。「壊れているが難しそうに見えるタスク」で報酬を稼ぐことを構造的に防ぐ設計です。
評価環境側にも同様の報酬 R_harness = C(q,h) × F(h,{τ}) × H(h) が用意され、Cはタスク仕様への整合、Fは報酬の忠実性、そしてHは「リワードハッキング耐性」(評価器の抜け道やショートカットに対する強さ)を測ります。自己生成データで学習させるアプローチにおいて最大の懸念であるリワードハッキングに、設計段階から対策を入れている点が技術的な見どころです。
「Claude Opus 4.8並み」の中身を17指標で分解する

397Bがしのぎを削れているのはターミナル操作系とコード修正の一部で、難問推論・長尺タスク・ツール操作では明確な差が残っています。公式表の17指標で数えると、Ornith-1.5-397BはClaude Opus 4.8に7勝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 0731やGLM 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の |
判定モデル | 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に置き換わる

出典: 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なので自由)
- オフライン環境・閉域網で動かす必要がある
導入方法と必要なランタイム

出典: 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推奨サンプリングパラメータ
用途 | 設定 |
|---|---|
一般利用 |
|
公式ベンチマークの再現 |
|
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つのセーフガードが説明されていた
運用側で自社が担保すべきこと
- 学習データの説明可能性が低い。モデル自身が生成したタスクと環境で学習しているため、「どんなデータで訓練されたか」を外部から追跡することは人手キュレーション型より難しい
- ローカル実行でもエージェント用途の危険度は下がらない。ターミナル操作やファイル書き換えを行う以上、権限分離・サンドボックス・実行前承認フローは必須です(AIエージェントによるデータ削除事故の事例も参考に)
- 公式のセーフティ評価・利用ポリシーが公開されていないため、業務利用では自社側でレッドチーミングとガードレール整備が必要
- 重みを自社環境に置ける=データが外部に出ないのは明確なメリット。機密コードを扱う組織にとっては最大の採用理由になり得ます
- サードパーティのホスティングを使う場合は、そのプロバイダのデータ取り扱いポリシーを別途確認すること
推奨する導入ステップ
自己申告ベンチマークしか存在しない現状では、次の3段階で進めるのが安全です。
- PoC: 9Bまたは35B-A3BのQ4_K_Mを1台のGPUで動かし、自社の実タスク(バグ修正・リファクタ・テスト生成)で挙動を見る
- 独立評価: 公式スコアではなく、自社のコードベースで自前のタスクセットを作って測る。Claude Opus 4.8など既存の選択肢と同条件で比較する
- 本番: サンドボックス・権限分離・監査ログを整えたうえで、限定的な業務から段階導入する
こんな人におすすめ
- 機密コードを外部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技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。
最新記事

Cursorとは?料金・使い方・できることを解説【2026年8月最新】
2026/03/31

LLM-jp-4 33Bとは?国立情報学研究所の国産オープンLLM・Apache 2.0・gpt-oss-20b超えの日本語性能を解説【2026年8月速報】
2026/08/20

MiniMax H3(Hailuo 3.0)とは?2K+音声同時生成・$0.13/秒・VRAM 12GB〜で動く33Bオープンウェイト動画AI|LTX-2.5・Wan 3.0との違い【2026年8月最新】
2026/08/04

OpenAIがフロンティアAIの強化学習を一部停止|Hugging Face侵害後の新セーフガード・30分アラート体制・再開条件を解説【2026年8月速報】
2026/08/19

Mistral OCR 4とは?最新4.1の変更点・170言語対応・料金$4の実情・Google/Azure OCR比較を解説
2026/06/28

NVIDIAがOpenAIのオハイオDCに最大1050億ドル債務保証|残余価値保証の仕組み・SB Energyの役割・循環取引批判を解説【2026年8月】
2026/08/19

