高性能モデルはローカル開発で使えるのか――Junie Localの新ブレンドモデルを検証する

ローカルAIエージェントに求められる「賢さ」と「速さ」

AIコーディングエージェントを開発環境へ導入する際、モデルの性能だけを見て判断することはできません。コードベースを理解し、複数のファイルを編集し、テストやツール実行を繰り返してタスクを完了するには、回答の正確さと待ち時間の短さの両方が必要です。

高性能なモデルほど推論に多くのトークンを使い、タスク完了までの時間が伸びる傾向があります。一方、軽量なモデルは反応が速くても、複雑な修正やデバッグで行き詰まりやすくなります。

Junie Localの今回のアップデートは、このトレードオフを緩和する試みです。Qwen3.6とQwen3.8を統合した27Bモデル、Qwen3.8-3.6-27B-blendが、ローカルでのコーディングエージェント利用を想定した新しい選択肢として提供されます。

Qwen3.6とQwen3.8を等比率で統合

新モデルは、同じアーキテクチャを持つQwen3.6-27BとQwen3.8-27Bの重みを、追加のポストトレーニングなしで等しい割合に統合したものです。

単純なモデルマージでありながら、内部の100タスクによるコーディング評価では、Qwen3.6とQwen3.8の中間的な性能ではなく、Qwen3.8に近いタスク完了数と、より少ない出力トークン数を示しました。

さらに、Qwen3.8とブレンドモデルの両方が完了した30タスクだけを比較すると、ブレンドモデルの出力トークンは約279K、Qwen3.8は約935Kでした。ブレンドモデルは30タスク中29タスクで、Qwen3.8より少ないトークンで処理しています。

これは、単に失敗時の出力が短かったという説明だけではありません。共通して成功したタスクでも、より短い推論経路を選べていたことを示しています。

トークン削減は開発体験にどう効くのか

ローカル実行では、出力トークンの削減は複数の面で効果があります。

• モデルが生成を続ける時間が短くなり、修正結果を確認しやすくなる
• 長時間の推論によるCPU・GPU負荷や消費電力を抑えやすい
• エージェントが同じ方針を繰り返す時間を短縮できる
• コード編集、テスト実行、追加指示という開発サイクルを回しやすくなる

特にJavaやSpring Bootのように、複数のクラス、設定ファイル、テストコードを横断する作業では、1回の回答品質だけでなく、エージェントが何度もツールを呼び出す一連の時間が重要です。

ただし、トークン数が少ないことは、常に正しいことを意味しません。推論を短くしすぎると、設計上の前提や既存コードへの影響を十分に検討しない可能性があります。実務では、単純なリファクタリングやテスト追加には高速モデルを使い、設計変更や障害解析ではより慎重な設定を使うなど、タスク単位で使い分けるのが現実的です。

公開ベンチマークでも示されたバランス

内部評価だけでなく、公開ベンチマークでも複数回の実行が行われました。LiveCodeBenchでは、4回の実行における平均正答率が次のようになっています。

この結果は、ブレンドモデルがすべての用途で最適だと証明するものではありません。ベンチマークには問題の種類や実行条件によるばらつきがあり、視覚系ベンチマークでは別のトレードオフも確認されています。

重要なのは、単一回のスコアではなく、複数回の結果と処理コストを合わせて見ることです。ローカルエージェントの導入評価でも、成功率だけでなく、完了までの時間、生成トークン数、同じタスクを再実行した際の安定性を記録する必要があります。

MTPによる高速化と、長いコンテキストの限界

Junie Localは、MTP（Multi-Token Prediction）を利用しています。小さなMTPヘッドが複数のトークンを先に予測し、メインモデルがそれらをまとめて検証する方式です。予測が正しければ、1回の処理でより多くのトークンを生成できます。

M5 MacBook Proでの測定では、1ラウンドに2トークンを提案した場合、MTPなしと比べてデコードが60％高速になりました。一方、4トークンに増やすと高速化幅は36％に低下しました。候補を作成・検証するGPU処理が増え、追加の予測が効率化を打ち消したためです。

この結果から、MTPは「提案数を増やせば増やすほど速くなる」仕組みではないことが分かります。ハードウェアやコンテキスト長によって、最適な設定が変わります。

また、4ビットのMTPヘッドと8ビットのMTPヘッドを比較したところ、提案の受理率はQ4が63.0％、Q8が63.6％でした。Q8に一貫した速度上の優位性は見られなかったため、メモリ節約を優先してQ4が採用されています。

一方、長いコーディングセッションでは注意が必要です。トークン検証時のアテンション処理時間は、コンテキストが長くなると8.4ミリ秒から40.2ミリ秒へ増加しました。つまり、エージェントが大量のファイルや過去のツール実行結果を抱えたまま作業を続けると、予測精度が保たれていても応答は遅くなり得ます。

実務では、次のような運用が有効です。

• 1つのエージェントセッションに過剰な作業を詰め込まない
• 大きなタスクを調査、実装、テスト、レビューに分割する
• 不要になったログやコンテキストを引き継がない
• 同じ方針を繰り返している場合は処理を中断し、目標を狭めて再実行する

評価では乱数シードにも注意が必要

今回の検証では、評価環境の乱数シードが結果を歪める問題も明らかになりました。再現性を高めるため、すべてのリクエストに同じシードを設定していたところ、モデルが似た予測を繰り返し、プロンプトが変わっても失敗した行動へ戻されるケースが発生しました。

この影響はQwen3.8でより大きく確認されました。対策として、エージェントの各ステップやリフレクション試行ごとにシードを進める方式へ変更し、再現性を保ちながら異なる経路を試せるようにしています。

これは、ローカルLLMの評価を設計するエンジニアにとって重要な示唆です。固定シードは再現性に役立ちますが、実際のエージェント利用では、同じ失敗パターンを固定化する可能性があります。評価時には次の項目を分けて記録すべきです。

• 固定シードでの再現性
• 複数シードでの成功率
• タスク完了までの出力トークン数
• 同一タスクを再試行した際の経路の違い
• ツール実行やテスト結果を受けた後の改善性

MacとWindows RTXでの利用条件

M5搭載Macでは、Junieを最新版へ更新したうえで、junie Run /localからローカルモデルを導入し、Qwen3.8-3.6-27B-blendへ切り替えられます。

Windowsでは、ナイトリービルドに実験的なNVIDIA RTX対応が追加されています。対象はAmpere以降のアーキテクチャを採用し、VRAMが24GB以上あるNVIDIA RTXカードです。試す場合のコマンドは次のとおりです。

junie --channel=nightly

Windows版は実験的なプレビューであるため、業務の標準開発環境へすぐに固定するというより、既存のGPU環境で性能や安定性を評価する用途に向いています。MacとWindowsではGPU構成やメモリ帯域が異なるため、同じモデル名でも体感速度が一致するとは限りません。

導入判断で見るべきポイント

このアップデートから得られる実務上の結論は、モデルのパラメータ数だけでローカルAIの価値を判断してはいけないということです。

導入前には、実際のリポジトリから代表的なタスクを選び、次の指標を測定すると判断しやすくなります。

• タスク完了率
• 完了までの経過時間
• 出力トークン数
• テストを壊した回数
• 人間による修正時間
• 長時間セッションでの応答速度
• 複数回実行時の結果のばらつき

たとえばSpring Bootプロジェクトであれば、REST APIの変更、バリデーション追加、JPAクエリの修正、テストコード生成、設定ファイルの変更といった実際の作業を評価対象にできます。ベンチマークの正答率が高くても、自社の命名規約やモジュール構成を理解できなければ、開発者の負担は減りません。

まとめ：ローカルAIの実用性は「性能÷待ち時間」で決まる

Qwen3.8-3.6-27B-blendは、Qwen3.8に近いコーディング性能を保ちながら、出力トークンを大幅に削減することを狙ったモデルです。Qwen3.6とQwen3.8の単純な等比率マージでも、ローカルのAIエージェントにおいて有用な改善が得られた点は注目に値します。

同時に、MTPは短いコンテキストでは大きな高速化に貢献する一方、長いセッションではアテンション処理がボトルネックになります。また、評価結果は乱数シードの設定にも左右されます。

ローカルAIを実務へ導入する際は、「最も賢いモデル」を選ぶのではなく、自社のタスクを、許容できる待ち時間とリソースで、安定して完了できるモデルを選ぶことが重要です。今回のアップデートは、その判断をモデルの正答率だけでなく、推論効率やランタイム設計まで含めて考えるきっかけになります。

出典： JetBrains Blog