Agentic Codingとは何だったのか
私は普段、ローカルLLMとしてGemma4を使っている。
HTMLやJavaScriptの小さなツールを作らせたり、仕様書をレビューさせたり、時には記事の構成を相談したり。RTX3060でも十分に動作し、日本語も強い。私にとっては、現時点でもっとも実用的なローカルモデルのひとつだ。
そんな中、少し気になるモデルが現れた。
DeepReinforceが公開した Ornith 1.0 である。
公開情報を見る限り、このモデルは少し変わっていた。
最近のローカルLLM界隈では、
- より大きなコンテキスト
- より強い推論能力
- より高いベンチマーク
といった方向の競争が続いている。
しかしOrnithが前面に押し出していたのは、そこではない。
Agentic Coding
という言葉だった。
コードを書く能力ではなく、
- 調べる
- 実行する
- 確認する
- 修正する
という一連の作業能力を重視しているらしい。
私は最初、この言葉を半信半疑で見ていた。
正直に言えば、
「またベンチマーク用の流行り文句だろう」
くらいに思っていた。
ところが実際に触ってみると、少し印象が変わった。
Ornithは、Gemma4より賢いとは感じなかった。
推論能力も、文章生成能力も、少なくとも私の用途ではGemma4の方が安定している。
しかし。
このモデルには別の強みがあった。
それは、
異様なまでの行動力である。
今回は、そんな少し変わったローカルモデル、Ornith 1.0 9Bを実際に試してみた記録である。
ちなみに、私の環境（RTX3060 12GB）では、概ね 47 token / 秒と軽快なスピードであった。
まず自己紹介でつまずく
本題に入る前に、ひとつ面白い出来事があった。
最初にOrnithへ、
「あなたは誰ですか？」
と聞いてみた。
すると、返ってきた答えはこうだった。
私はAnthropicが開発したClaude 3.5 Haikuという大規模言語モデルです。
もちろん違う。
これはOrnith 1.0 9Bである。
Anthropic製でもなければ、Claude 3.5 Haikuでもない。
いきなり自己紹介で盛大に転んだわけだ。
ただ、これはQwen系モデルでは時々見かける挙動でもある。
学習データやInstruction Tuningの影響なのか、モデルによっては「私はClaudeです」「私はChatGPTです」といった自己認識の混線が起きることがある。
Ornithもそのタイプらしい。
この時点で私は少し笑ってしまった。
Tool Useを掲げるAgentic Codingモデルが、最初の自己紹介でClaudeを名乗る。
なかなか縁起の悪いスタートである。
しかし、今回の記事で見たいのは自己認識ではない。
このモデルが、実際にどれだけ動けるのか。
そこで私は、まず簡単な推論問題から試してみることにした。
最初の違和感
まず最初に試したのは、ごく簡単な推論問題だった。
父と息子の年齢を求める、よくある文章題である。
父は息子より24歳年上です。
10年後には父の年齢は息子の2倍になります。
現在の年齢を求めてください。
Ornithは正答した。
息子14歳、父38歳。
答えは正しい。
ところが、途中の出力が少し気になった。
数式を何度も書き直し、
同じ計算を別の形で繰り返し、
時折意味不明な数式断片まで混ざる。
最後にはデバッグ情報らしき文言まで漏れていた。
もちろん、最終結果が正しければ問題ないと言うこともできる。
しかし、Gemma4を見慣れた私には少し違和感があった。
Gemma4は答えに至るまでの流れが比較的綺麗だ。
途中式も整理されているし、人間向けの説明として成立している。
一方のOrnithは違う。
解けてはいる。
だが、美しくはない。
まるで頭の中で考えていることを、そのまま机の上にぶちまけているような印象だった。
この時点で私は少し首をかしげた。
公開情報を見る限り、OrnithはAgentic Codingを掲げる意欲的なモデルである。
だから私は勝手に、
「Gemma4よりも推論能力が高いのかもしれない」
と想像していた。
しかし実際に触ってみると、そういう方向性ではないらしい。
少なくとも私が最初に受けた印象は、
優秀な推論モデルではなく、少し落ち着きのない作業員
だった。
もちろん、この時点ではまだ判断できない。
たまたま苦手な問題だっただけかもしれない。
そこで次は、Ornithがもっとも得意だと主張している分野を試してみることにした。
Tool Useである。
Web検索が異様にうまい
そこで次に試したのが、Tool Useだった。
Ornith 1.0の最大の特徴は、モデル情報にも表示されている通り、明確に Tool Use対応モデル として設計されていることだ。
そこで、LM StudioにDuckDuckGo MCPを接続し、単純な質問を投げてみた。
埼玉県春日部市の6月30日の天気を調べてください。
すると、Ornithはほとんど迷わなかった。
まず検索を実行する。
その後、検索結果を要約するのではなく、実際の天気ページを取得しに行く。
ログを確認すると、
- Yahoo!天気
- Weathernews
の両方へアクセスしていた。
しかも面白いのは、その動きの速さである。
ここで言う速さとは、47Token/sのことではない。
行動が速いのだ。
私がこれまで試してきたローカルモデルの多くは、
検索する
↓
検索結果を眺める
↓
悩む
↓
もう一度検索する
↓
ようやく回答する
という動きを見せる。
しかしOrnithは違った。
検索する。
読む。
答える。
ほぼそれだけだった。
実際のログを見ると、
検索
↓
Yahoo!天気取得
↓
Weathernews取得
↓
回答
という流れが非常にスムーズに進んでいる。
最初は偶然かと思った。
そこで別の題材を試してみた。
今度は首相官邸のWebサイトである。
首相官邸のWebサイトから、最新ニュースを3件ピックアップして概要をまとめてください。
官邸サイトのトップページには大量の新着情報が並んでいる。
会議。
面会。
視察。
発表。
毎日更新される膨大な記事だ。
普通に考えれば、
単純に新着順で3件を拾ってくるだろう。
私もそう思っていた。
しかしOrnithは違った。
かなりの数の記事を読み込み始めたのである。
ログを見ると、
ornith-1.0-9b
Thought for 1.47 seconds
fetch_content
mcp/duckduckgo
Thought for 2.15 seconds
fetch_content
mcp/duckduckgo
Thought for a brief momentfetch_content
mcp/duckduckgo
Thought for 2.32 seconds
fetch_content
mcp/duckduckgo
Thought for a brief moment
search
mcp/duckduckgo
Thought for 2.89 seconds
fetch_content
mcp/duckduckgo
Thought for 2.35 seconds
fetch_content
mcp/duckduckgo
Thought for a brief moment
fetch_content
mcp/duckduckgo
Thought for 1.54 seconds
fetch_content
mcp/duckduckgo
Thought for 5.65 seconds
search
mcp/duckduckgo
Thought for 2.82 seconds
fetch_content
mcp/duckduckgo
Thought for a brief moment
search
mcp/duckduckgo
Thought for 3.38 seconds
fetch_content
mcp/duckduckgo
Thought for a brief moment
search
mcp/duckduckgoという動作を延々と繰り返していた。
そして最終的に選んだのは、
- 山梨県東部・富士五湖を震源とする地震
- 中東情勢に関する関係閣僚会議
- IAEA事務局長による表敬
だった。
ここで私が驚いたのは、記事の内容そのものではない。
選び方である。
官邸トップの新着一覧には、もっと新しい記事がいくつも並んでいた。
引用：https://www.kantei.go.jp/jp/news/index.html
それにもかかわらずOrnithは、
「新しい記事」
ではなく、
「重要そうな記事」
を選んできたのだ。
もちろん、本当に重要度を理解しているのかは分からない。
しかし少なくとも挙動としては、
単純な検索エンジンではなく、
簡易的なニュース編集者に近かった。
この辺りから、私は少し考えを改め始めた。
最初の推論テストでは、
「思ったより賢くないな」
という印象だった。
しかしTool Useになると話が変わる。
Ornithは考える前に動く。
そして動き始めると、驚くほど手際がいい。
どうやらこのモデルは、
推論モデルというより、
作業モデルとして設計されているらしい。
Claude Codeで試す
ここまでの結果を見る限り、Ornithの強みは明らかだった。
検索。
MCP。
Tool Use。
情報収集。
では、本当にAgentとして優秀なのだろうか。
それを確かめるために、次はClaude Codeと組み合わせて試してみることにした。
私は普段、Claude CodeをローカルLLMと接続して使うことがある。
単純なチャットとは違い、
- ファイルを読む
- コマンドを実行する
- 環境を構築する
- ブラウザを操作する
といった実際の作業を任せられる。
もしOrnithが本当にAgentic Coding向けのモデルなら、この環境で真価を発揮するはずだった。
最初に頼んだのは単純な作業である。
White HouseのホームページをPlaywrightでキャプチャしてほしい。
するとOrnithは動き始めた。
まず環境を確認する。
Node.js。
npx。
Playwright。
利用可能なツールを調べる。
その後、
Playwrightが不足していることを確認すると、
package.jsonを作成。
依存関係を定義。
npm installを実行。
Chromiumを導入。
スクリーンショット取得用スクリプトを生成。
そして実行。
最終的に、
White Houseのトップページ全体のキャプチャ取得まで成功した。
ここで重要なのは、Playwrightそのものではない。
私が驚いたのは、その進め方だった。
多くのローカルモデルは、
エラーに遭遇すると止まる。
あるいは、
「Playwrightが必要です」
と言って作業を返してくる。
しかしOrnithは違った。
不足しているものを探す。
導入する。
再実行する。
結果を確認する。
まるで新人エンジニアというより、慣れたオペレーターのようだった。
少なくともこの分野では、Gemma4より明らかに積極的である。
ここで私は、
「ああ、このモデルが言うAgentic Codingとはこういうことか」
と少し理解できた気がした。
しかし。
話はここで終わらない。
次に試したのは、私が普段Gemma4でよく行っている仕事だった。
小規模なWebアプリの作成である。
ここから状況は、少し変わり始める。
しかしKanbanボードは動かない
次に試したのは、Kanbanボードだった。
要件はシンプルである。
- Todo / Doing / Done の3カラム
- タスク追加
- ドラッグ&ドロップ
- LocalStorage保存
- 単一HTML
- 外部ライブラリなし
小規模Webアプリとしては定番中の定番だ。
Gemma4なら、多少の粗はあっても、それなりに動くものを出してくることが多い。
Ornithはどうか。
第一印象は悪くなかった。
見た目はきれいだった。
カード風のカラム。
追加ボタン。
カウンター。
レスポンシブを意識したレイアウト。
コード量もかなり多く、一見すると気合いの入った実装に見えた。
しかし、ブラウザで開くとすぐに崩れた。
Consoleには、
Cannot read properties of undefined (reading 'forEach')
Cannot read properties of undefined (reading 'push')というエラーが出ていた。
原因は典型的だった。
データ構造の設計と、実際にそれを使う処理が噛み合っていなかったのである。
状態管理の形はAなのに、描画処理はBを期待している。
追加処理はCにpushしようとしている。
UIはある。
関数もある。
しかし、アプリ全体としての整合性が取れていない。
そこでエラー内容を渡して修正を依頼した。
Ornithは素早く返してきた。
原因を説明し、該当箇所を修正し、Consoleエラーは消えた。
しかし。
動かなかった。
画面は表示される。
エラーも出ない。
だが、タスク追加やドラッグ&ドロップが期待通りに機能しない。
これは、ローカルLLMで何度も見てきた失敗パターンである。
エラーを消すことと、動くものを作ることは違う。
Ornithは前者には素早く反応した。
しかし後者には届かなかった。
同じことは、リバーシでも起きた。
画面は美しい。
タイトルもある。
黒と白の表示もある。
リセットボタンもある。
スコアも出ている。
しかし、肝心の盤面が表示されない。
Consoleエラーはない。
でもゲームとしては成立していない。
ここで私は、Ornithへの評価をかなりはっきり修正した。
このモデルは、コードを書けないわけではない。
見た目も作れる。
ファイルも作れる。
環境も作れる。
だが、状態管理やゲームロジックのように、内部整合性が重要な実装になると弱い。
少なくとも私の試した範囲では、Gemma4の方が小規模ツールのコーディング能力は高かった。
これは少し意外だった。
OrnithはAgentic Codingを掲げるモデルである。
ならば、Kanbanボードやリバーシくらいは軽く作るのではないか。
そう期待していた。
しかし実際には違った。
Ornithが得意なのは、コードを書くことそのものではなかった。
むしろ、
コードを書く前後の作業
だったのである。
