2〜9BのローカルLLMでも「実タスク」を完遂できる——Mingbirdが示す「モデルではなくハーネスが問題」という視点

はじめに：ノートPCの小型モデルは、なぜエージェントになれないのか

パラメータ数2〜9B級のオープンウェイトモデルは、すでに普通のノートPCで動く。統合GPUと16〜32GB程度のメモリがあれば、量子化したモデルをローカルで走らせられる。要約、翻訳、質疑応答といった単発のタスクであれば、実用に耐える品質が出ることも珍しくない。

ところが、同じモデルを「エージェント」として使った瞬間に挙動が崩れる。コードを書いてテストを通す、フォルダの中身を整理する、検索して根拠付きの調査結果をまとめる。こうした多段のタスクを最後までやり切れないのだ。途中で同じ操作を繰り返す、成果物がないまま「完了しました」と答える、あるいは何も言わずに止まる。失敗の仕方にも共通の型があり、再現性がある。

長らくの通説は「小型モデルはエージェントに向かない」だった。これに対し、2025年に発表された位置づけ論文は、エージェント用途こそ小型モデルの出番だと逆の主張を掲げた。両者の間で、本論文が取る立場は中間にある。小型モデルはたいていの場合、次に取るべき正しい行動は分かっている。分かっていないのは、それを一歩ずつ確実に出力し、実行しきることだ。

ここで重要になるのがハーネス（harness）である。ハーネスとは、モデルと環境の間に立つソフトウェア層を指す。モデルに何を見せるか、どのツールを呼ばせてよいか、いつ終わらせてよいかを決める。いわば足場であり、外枠だ。プロンプトの組み立て、ツール呼び出しの解析と実行、結果のフィードバック、ループ制御、完了判定、ファイルやシェルの安全境界がここに含まれる。

本論文の主張は明快である。小型モデルが実タスクで失敗する原因の相当な割合は、モデルではなくハーネス側にある。これは能力の限界ではなく、足場の設計不良というエンジニアリング上の欠陥だ。同じ2Bモデルが、ハーネスを替えるだけでスコア0.017から0.821へ動いた、という観測がその根拠になっている。

ハーネスの重要性そのものは新しい知見ではない。ハーネスの構成がモデル選択よりも性能の分散を支配するという議論や、同一モデル内でもスキャフォールド次第で最大28点の差が出るという報告がある。本論文の新しさは、それを2〜9Bのローカル環境、とりわけWindowsとOllamaという手薄な領域で、メカニズム単位まで分解して示した点にある。

エージェントハーネスとは何か

ハーネス（harness）とは、モデルと環境の間に立つソフトウェア層である。モデルの重みそのものを指す言葉ではなく、モデルの外側で「何を見せ、どのツールを実行させ、いつ終わらせてよいか」を決める部分を指す。英語の harness は馬具や安全帯を意味し、日本語では足場・外枠と訳される。LLMがエージェントとして振る舞うとき、その挙動はこの層の設計に大きく左右される。

代表的な構成要素は、タスク文とツール定義を並べたプロンプトの組み立て、ツール呼び出しの解析と実行、結果のフィードバック、ループ制御、完了判定、ファイルやシェルの安全境界である。権限・状態・引き継ぎ・再実行といった管理もこの層の役割として整理される。

同じモデル、同じマシン、同じ時間予算でも、この層を替えるだけでスコアは大きく動く。したがって「モデルの実力」と「ハーネスの実力」を切り分けて測らないと、能力評価を誤る。実際、同じ2Bモデルが一方のハーネスでは18タスク平均0.017だったのに対し、別のハーネスでは0.821を示した。この差はモデルの重みでは説明できない。

用語は混同しやすいため整理しておく。

• prefill（プリフィル）：タスク本文より前にモデルへ入る固定テキスト。システムプロンプトとツール定義を含む。クラウド向けのハーネスでは数十個のJSONスキーマを並べ、数千トークンに達することもある。
• スキャフォールド：ハーネスとほぼ同義で、足場を指す。
• ハーネス機構：ループ検出や完了ゲートのような、ハーネス内部の個別の仕掛け。

モデル・ハーネス・環境の3層関係と、1ターンの流れは次のように模式化できる。ハーネスは推論を行わず、モデルと環境の間で入出力を仲介し、各ターンの終わりに続行か終了かを判断する。

sequenceDiagram
    participant U as 利用者
    participant H as ハーネス
    participant M as モデル
    participant E as 環境（OS・ツール・ファイル）
    U->>H: タスク文
    H->>M: prefill（システムプロンプト＋ツール定義）
    M-->>H: ツール呼び出し
    H->>E: 実行（シェル・ファイル操作）
    E-->>H: 実行結果
    H->>H: ループ制御と完了判定
    alt 未完了
        H->>M: 結果をフィードバックして次ターン
    else 完了
        H-->>U: 成果物を返す
    end

この図のどこを厚くし、どこを固定予算に収めるかが、小型モデルを実タスクで完遂させるかを分ける。

小型モデルが失敗する4つの型

小型モデルが実タスクで崩れるとき、その崩れ方には共通の型がある。論文の著者らは2B級のモデルをクラウド規模のエージェントフレームワークで動かし、同じ失敗が繰り返し現れることを確認して「失敗形態（failure form）」として類型化した。型が4つに整理できるという事実自体が重要である。不規則な偶発障害ではなく、再現性のある機構的な失敗だということを意味するからだ。

flowchart LR
    T[タスク文] --> P[prefill 構築]
    P --> R[モデルの推論]
    R --> X[ツール実行と観測]
    X --> R
    P -. 失敗1：文脈圧迫 .-> R
    X -. 失敗2：自己修正の破綻 .-> R
    R -. 失敗3：ツール実演ループ .-> X
    R -. 失敗4：静かな放棄 .-> Z[完了宣言]

失敗1：ツールprefillによるコンテキスト圧迫

prefill（プリフィル）とは、タスク本文より前にモデルへ入る固定テキストで、システムプロンプトとツール定義からなる。クラウド向けのハーネスはここに数十個のJSONスキーマを並べ、数千トークンに達することがある。タスクが始まる前の時点で文脈を食い潰してしまい、以降の指示追従が崩れる。長い入力の中央付近にある情報が失われる「Lost in the middle」や、文脈が長引くほど推論品質が落ちる「Context rot」として知られる現象と同じ機序である。対照的にMingbirdがハーネス自身に課す固定予算は774トークン（計測に使った版）〜797トークン（v1.6.0）で、単体テストによって固定されている。

失敗2：自己修正の破綻

ツール呼び出しが失敗しても、小型モデルは自力で誤りに気づいて直せない。エラー文を読んだうえで同じ引数のまま再試行したり、別のツールへ切り替える判断ができなかったりする。失敗を言語化して次の試行に反映する自己修正の枠組みは、小型モデルではそのままでは機能しにくい。

失敗3：ツール実演ループ

「何ができる？」と聞かれた小型モデルが、答えを返す代わりにツールを延々と実演して終わらない。4Bモデルによるあるタスク（WF-08）では、156回のツール呼び出しを経て成果物ゼロという実行が観測された。個々の呼び出しは成功しているためエラーとしては現れず、ループを検出する仕掛けがない限り止まらない。

失敗4：静かな放棄

成果物がないのに「完了しました」と答える、あるいは何も言わずに途中で止まる。288セルの記録では、クラッシュせずに最終スコア0.5未満で終わった「途中終了」が、goose 23セル、opencode 32セル、agent-mini 44セルに達した。成果物チェックに失敗した「不完全な納品」はそれぞれ44・53・61セルである。誤りを報告するのではなく、静かに諦めるのが最も始末の悪い型だ。

この4類型に共通するのは、どれもモデルを再学習しなくても直せる決定論的な工学問題だという点である。文脈の与え方、失敗の検出、完了の受理条件——いずれも足場の側の設計で決まる。

Mingbirdの全体像：Windows＋Ollamaで完結するローカルファースト・ハーネス

Mingbirdは、WindowsとOllamaを前提に設計されたローカルファーストのエージェントハーネスである。ここでいうハーネスとは、モデルと環境（OS・ツール・ファイル）の間に立つソフトウェア層を指す。Mingbird自身は推論エンジンを持たず、Ollamaが提供する任意のモデルに話しかける。GUIとCLIは同一のエージェントループを共有しており、どちらから起動しても振る舞いは変わらない。モデル・ツール・音声認識・メモリのすべてが利用者のマシン上で動き、既定構成では外部通信はゼロである。唯一の任意の外向き経路は、利用者が明示的に設定した検索プロバイダだけに限られる。

設計は「失敗形態 → メカニズム → トレードオフ」という形式で文書化されている。失敗形態とは、小型モデルが繰り返す再現性のある崩れ方の型であり、10の中核メカニズム（M1〜M10）と5リングの安全モデル（M14）が、それぞれの型に逐一対応する。ハーネス自身が追加する静的な前置きテキスト（prefill）は797トークン（v1.6.0。計測に使ったv1.5.0では774トークン）に抑えられ、単体テストで固定されている。CIは1バイトでも増えた時点で失敗する。

品質基盤として441のテスト（v1.6.0。執筆時点のv1.8.2では461＝unit 435＋integration 26）を持つ。対象モデルは2〜9Bで、上限は35Bまで検証済み、既定コンテキストは128K（最大256K）である。開発元は公開リポジトリ（github.com/Mingbird/Mingbird-agent、Apache-2.0）で、現行リリースはv1.9.2。READMEには「同じ2Bモデルで0.017→0.821。問題はハーネスだった」と記されている。

flowchart TD
    U[利用者] --> I[GUI / CLI<br/>同一エージェントループ]
    I --> C[M2 チャット／タスク階層化]
    C --> P[M1 フラットprefill・正味ゼロ予算]
    P --> O[Ollama バックエンド<br/>2〜9B・上限35B]
    O --> G[M3 finish gate・完了ゲート]
    G --> L[M4 シグネチャ単位アンチループ]
    L --> T[ツール実行器<br/>シェル・ファイル・MCP]
    T --> O
    G -->|検証通過| D[成果物]
    R[M7 耐障害層] -.-> T
    S[M8 セキュリティ境界・M14 5リング] -.-> T

図が示すように、利用者の入力はまずチャットかタスクかに分類され、タスク側だけがツールを解放する。推論はOllamaに委ね、返ってきたツール呼び出しを実行して観測を戻すサイクルを、完了ゲートとループ検出が監視する。M7の耐障害層がOS固有の不具合からこのサイクルを守り、M8とM14が実行の外側に安全の境界を張る。以降の節では、M1からM14までの各機構が、どの失敗形態にどう効くのかを順に読み解いていく。

10のメカニズムを読み解く

Mingbirdの設計は「失敗形態 → メカニズム → トレードオフ」の形式で文書化されている。失敗形態とは、小型モデルが繰り返す再現性のある崩れ方の型であり、10の中核メカニズム（M1〜M10）と5リングの安全モデル（M14）がそれぞれの型に逐一対応する。以下の各機構は独立した工夫の寄せ集めではなく、1つの失敗形態に対して1つの決定論的な介入を割り当てた対応表として読むことができる。

M1：フラットprefillと正味ゼロ予算

prefillとはタスク本文より前にモデルへ入る固定テキストで、システムプロンプトとツール定義を含む。クラウド向けハーネスのように数十個のJSONスキーマを並べると、タスクが始まる前に文脈を食い潰す。M1はまずタスクの領域を分類し、そのカテゴリに必要なツール定義だけをフラット（入れ子なし）形式で読み込む。MCPツールも同じ経路を通り、引数が8個を超えるスキーマは必須項目のみに圧縮される。

コストは実測されている。4Bモデルではprefillトークンあたり約0.20msでほぼ線形（19ツールで1.5秒、31ツールで1.7秒、256ツールで5.6秒）。一方2Bモデルは超線形で、256ツールを載せると1ターンあたり33.6秒、20ターンで生成に入る前に11分を消費する。ルータ自体の固定オーバーヘッドは+330トークンであり、797トークンの一部として1ターンあたり68ms（4B）〜217ms（2B）に相当する。作業点をコスト曲線の左端に固定する仕掛けは、ほぼ無料で効くというわけだ。新機能は静的なprefillを正味ゼロしか増やせず、CIがバイトレベルで検査する。トレードオフはカテゴリ誤分類で必要なツールが隠れる可能性だが、分類器は保守的で再ルーティングを要求できる。

M2：チャット／タスクの階層化

「何ができる？」という雑談に対し、ツールを見せられた小型モデルは答えの代わりに実演を始めてしまう。M2はリクエストをチャットとタスクに分類し、チャットには最小限の専用prefillだけを与え、答えを返した時点でループを終了させる（継続を提示しない）。全ツールが解放されるのはタスクモードだけである。成果物を生んだ会話への短い追記はタスク継続として扱われ、これが多段の修正パイプラインを成立させる。本物のタスクをチャットと誤分類するとツールなしで立ち往生するため、成果物を生んだ履歴があればタスク側に倒す設計になっている。

M3：finish gate（完了ゲート）と完了時のプロンプト再注入

成果物が欠けたまま「完了」を宣言する型への対処である。完了宣言を受け入れる前に、ハーネスが元のタスク文を読み直し、項目ごとに納品を検証させる。長期計画では圧縮後に計画文自体が消えるため、todo／計画パイプラインは圧縮後に計画文を逐語で再注入する。todoインタフェースには明示的な完了出口（todo(update, all=true)）があり、完了は文体のドリフトではなく明示的な行為になる。ゲートの検証段はタスク自身のチェックを実行し、実際の失敗（ファイル、行、エラー文）をそのまま会話に戻す。タスクあたり1ターン余分にかかるのが代償だが、タスク文が文脈にある状態での二度目のパスを強制し、多くの静かな放棄を「完了」か「明示された詰まり」に変換する。

M4：シグネチャ単位のループ検出

小型モデルは同じ引数で同じツール呼び出しを10回、50回、150回と繰り返し、成果物を何も生まないことがある。実測例では4Bモデルが1タスク（WF-08）で156回のツール呼び出しを行い、成果物ゼロだった。M4は呼び出しのシグネチャ（ツール名＋正規化した引数）を計算し、同一呼び出しが6回以上、または出力なしの連続呼び出しが15回以上で発動する。是正は段階的で、3回目の拒否では強い修正ヒントを添え、空ターンが6回連続するとターンを強制リセットする。修正後、同じ4B×WF-08の構成は15回のツール呼び出しで3つの成果物を出し、prefillは修正前後でビット単位で同一だった。

隣接する失敗も別途ふさぐ。出力上限を2048から8192トークンへ引き上げ（2048では大きなファイルの出力が途切れ、空ターンの螺旋に落ちる）、切り詰め時は「骨組みを書いて追記せよ」という分割フィードバックを返す。ファイル読み込みにはバイト予算のクロールガードがあり、予算はファイルサイズの2倍で64KB〜512KBにクランプされる。超過しても拒否せず、要求範囲の先頭2000文字を位置情報付きで返してクロールを継続させる。閾値（6、15）は観測された正当な反復より十分高く設定されており、誤発動しても代償は修正プロンプト1回で実行終了にはならない。

M5：偽の完了の拒否とフォーマット救済

小型モデルはツール呼び出しを本文テキストとして出してしまうことがある。プレースホルダ引用の疑似XML、散文に埋もれたJSON断片、二重引用符の疑似呼び出しという3つの形が繰り返し現れ、厳格なパーサはこれを捨ててターンを崩壊させる。M5はこの3形を認識して実呼び出しに変換し、拒否した偽の完了メッセージには常に次の実行可能な行動を添える。文法制約付きデコーディングのような厳格なスキーマ強制ではなく、2〜9Bには「救済＋フィードバック」が選ばれている。救済はヒューリスティックであり、3形の外は投機的に解釈せずフィードバック付きで拒否する。

M6〜M8：編集安全性・耐障害性・セキュリティ境界

• M6 編集安全性：破壊的な編集に対して、書き込みごとに自動で.bakを残し、ロールバックはモデル自身が発行できる1コマンドにする。差分もマージもせず意図的に単純で、モデル自身が復旧道具として使えることを優先する。
• M7 耐障害性：Windowsではプロセス出力がレガシーコードページ（GBKなど）で届き、厳格なUTF-8リーダーが黙って落ちると診断なしに固まる。読み取り側はUTF-8＋置換でデコードし、どのバイト列でもリーダースレッドを落とさない。可視内容が推論ラッパーだけで行動可能な出力がない「Thinkタグの殻」は空として扱い、中断した実行はチェックポイントから再開する。
• M8 セキュリティ境界：作業ディレクトリの境界を正規化パスで検査し（Windowsのシンボリックリンク・区切り文字に安全）、.ssh、.env、資格情報ストアなどはゲートの内側に置く。範囲外操作は明示確認を要求し、並列サブエージェントは既定で拒否する。確認ダイアログは上級者には摩擦になるが、単一の個人マシンを非専門家が使う構成を優先した選択である。

M9・M10：能力面と品質基盤

M9はM1の予算内に収まる能力だけを加える。同梱のローカル音声認識（純CPU、実時間の約20倍）、画像入力、永続・検索可能なセッションメモリ、フラットJSONでのMCP接続、段階的開示（progressive disclosure）のスキル（数十個で数百トークンに圧縮）、Ollamaからのモデル識別とコンテキスト長の自動検出などが含まれる。M10は品質基盤で、441テスト（v1.6.0）のうち特に重要なのがバイトレベルのprefill正味ゼロ表明とループ検出閾値の回帰ガードである。テスト群は実装速度を制約し、より豊かなシステムプロンプトや常時オンのツール索引といった設計を却下してきた。段階的開示はモデルがスキルファイルを開くことを知っていなければ機能しないため、スキル索引を常設文脈に置いてコストを1回の読み込みに抑えている。

M14：5リングの安全モデル

失敗した依存関係やシステムファイルを消そうとする行動は、実際の実行で観測されている。M14は安全挙動を5つのリングで構成する。①サブエージェントは本体より厳密に狭い権限で砂箱化、②フォーマットや生デバイス書き込みなど不可逆操作は即座に拒否、③システム変更操作はオペレータの在席で格付け（無人実行は既定拒否、実行単位の上書きあり）、④再帰削除は作業ディレクトリに限定し、拒否時はファイル単位の代替を提示、⑤書き込み前の.bak、削除のtrash化、大きな上書きへの明示要求という可逆性の確保である。

評価は54ケースのプローブ（5リングにわたる44の敵対的ユーザ要求＋10の良性コントロール）を両小型モデルで各1回実行して行われた。不可逆操作を担うリング2は全試行を阻止し、確認された漏れは通っていない。確認されたエンドツーエンド効果は2Bで44中2、4Bで44中11で、いずれも生のbashコマンド面を通る。論文はこれを「パターンリスト施行の実測された境界」と位置づけ、衝動的なツール使用には効くが同格の方法論的敵対者には効かないと明示する。プロンプトインジェクション対策とは相補的であり、M14はエージェント自身のツール列がホストに何をしうるかを統制するが、注入された内容が何を言わせうるかは扱わない。

flowchart LR
    F1[失敗1 prefill圧迫] --> M1[M1 フラットprefill<br/>正味ゼロ予算]
    F3[失敗3 ツール実演ループ] --> M2[M2 チャット／タスク階層化]
    F3 --> M4[M4 シグネチャ単位アンチループ]
    F4[失敗4 静かな放棄] --> M3[M3 finish gate<br/>計画の再注入]
    F2[失敗2 自己修正の破綻] --> M5[M5 偽完了拒否・<br/>フォーマット救済]
    M3 --> M6[M6 編集安全性 .bak]
    M3 --> M7[M7 耐障害層]
    M3 --> M8[M8 セキュリティ境界]
    M1 --> M9[M9 能力面]
    M8 --> M14[M14 5リング安全モデル]
    M10[M10 品質基盤 CI] -.-> M1
    M10 -.-> M4

この図が示すとおり、機構は失敗形態ごとに割り当てられ、M10の回帰ガードだけが他の機構そのものを監視する位置にある。

どう測ったか：LRABという「対照実験」

ハーネスの効果を主張するなら、モデル・マシン・時間予算・採点方法のすべてを固定し、ハーネスだけを変数にしなければならない。そこで著者らはLRAB（Local Real-task Agent Benchmark、ローカル実タスク用のエージェント評価基盤）を自作した。LRABは順位表ではなく、原因を切り分けるための対照実験として設計されている点が重要である。構成は4ハーネス × 4モデル × 18タスク＝288セルで、実際に使われたハーネスはMingbird、goose（1.48.0）、agent-mini（0.3.1）、opencode（1.18.23）の4つ。いずれも素のまま未改変で走らせている。マシンは1台だけ、バックエンドはOllama（0.33.2）に統一した。

参加モデルはすべてオープンウェイトで、Q4_K_M量子化に揃えられている。

タスクは4段のはしごを成す。T1検索（WF-01/02）、T2合成（WF-03〜06）、T3ワークフロー（WF-07〜15）、T4長時間（LH-01〜03）の順に、必要なターン数と成果物の数が増えていく。LH-03は実行を途中で強制終了して再開させるkill-and-resumeのストレステストを兼ねる。時間予算はワークフローが90分、長時間が180分。温度（temperature＝サンプリングのばらつきを決めるパラメータ）は全アームで0に固定し、設定口を持たないgooseとopencodeについては輸送層のプロキシで正規化したうえで、通信内容が実際にそうなっているかを検証している。採点は決定論的で、生成された成果物そのものを対象にする。

288セルすべてが生データとして公開されており、集計値は公開CSVから再計算できる。マシンは統合GPU・32GB共有メモリ・Windows 11という、ごく普通のノートPC構成である。

自作ベンチには「自分に有利なタスクを選んでいるのではないか」という疑いがつきまとう。これを補うため、第三者ベンチマークのτ²-bench（278タスク、retail 114・airline 50・telecom 114の3ドメイン）でも検証している。τ²-benchでは利用者シミュレータがエージェントと会話し、エージェントはポリシーに従ってドメイン固有のツールを操作し、採点は最終的なデータベース状態を検証する。ツール列を迂回して「呼んだふり」をしても通らない構造になっている。

flowchart LR
    subgraph L[LRAB 自作ベンチ＝因果の切り分け]
        LH1[4ハーネス]
        LH2[4モデル 2B〜35B]
        LH3[18実タスク T1〜T4]
        LH1 --> C288[288セル]
        LH2 --> C288
        LH3 --> C288
        C288 --> SC[決定論的・成果物ベース採点]
    end
    subgraph T[τ²-bench 第三者ベンチ＝外挿]
        U[利用者シミュレータ] <--> A[エージェント]
        A --> TL[ポリシー下のドメインツール]
        TL --> DB[最終データベース状態を検証]
    end
    SC --> J[二重の証拠]
    DB --> J

図のように、LRABは「何が効いたか」を因果として示すために条件を搾り込み、τ²-benchはその結論が自作ベンチの外側でも成り立つかを確かめるために使われている。役割が違うため、両者のマージンをそのまま並べて比較することはできない。

結果：数字が示す「ハーネス効果」

条件をすべて固定してハーネスだけを替えたとき、スコアはどこまで動くのか。18タスク×4モデルの288セルを平均すると、結果は次のように分かれた。ここでいうスコアは、各タスクが要求する成果物の実在と品質を決定論的に採点した0〜1の値である。

モデルサイズ別に見ると、Mingbirdは2B級で0.821、4Bで0.876、12Bで0.906、35Bで0.941と、小型側でも大きく崩れない。差には信頼区間が付いており、goose比は+0.255（95%信頼区間 +0.188〜+0.322）、opencode比は+0.407（+0.328〜+0.491）、agent-mini比は+0.481（+0.410〜+0.555）である。半分以上の得点を取ったセルはMingbirdが68/72、gooseが48/72、opencodeが38/72、agent-miniが28/72で、平均だけでなく分布も分かれる。

ただし過大な主張は避けられている。4Bではgooseが0.801まで迫り有意差に届かず、35Bではopencodeの0.896と分離しない。「頑健に言える優位は小型モデル領域と全体マージン」という留保が付く。

小型モデルの崖

各ベースラインは、どこかで性能が急落する「崖」を持つ。opencodeは2Bで0.017まで崩壊し、gooseは2Bで0.271、agent-miniは4Bまでは持ちこたえるが35Bで0.092に落ちる。Mingbirdは自分の最高値から0.15以内に留まる唯一のハーネスで、2Bセグメントではベースラインが0.017〜0.271に散る中で0.821を出す。2B級は統合GPUのノートPCで快適に動く最大サイズであり、ローカル完結の用途では実用的な意味が大きい。

層とモデルファミリが交絡する（各サイズにつき1モデルしか使っていない）ことを補うため、第2の2B級モデルqwen3.5:2bでも同じ18タスクを4ハーネスすべてで走らせている。Mingbirdが0.779なのに対し、gooseは0.096、opencodeは0.017、agent-miniは0.239だった。崖は特定のモデルファミリの性質ではなく、ハーネスの性質だというわけである。

長時間タスクと第三者ベンチマーク

3つの数時間規模のタスクでは、Mingbirdが0.827、agent-miniが0.484、gooseが0.394、opencodeが0.354となる。ターン数が最も伸びる場所でマージンが最大になるが、このセグメントは単発実行でばらつきが大きく、1セルにつき1回の実行しかない参考値である。

自作ベンチの外側でも確かめられている。第三者ベンチマークのτ²-bench（3ドメイン・278タスク）では、Mingbirdが0.856、ベンチ付属のネイティブエージェントが0.791、opencodeが0.737だった。

278タスク全体では、Mingbirdはネイティブ比で+0.065（McNemar検定 p=0.030）、opencode比で+0.119（p=2.7×10⁻⁵）と有意である。ただし区別力のあるretailとairline（164タスク）に限ると、opencodeとは分離するがネイティブとは分離しない（p=0.22）。ネイティブとの有意差は飽和したtelecomに依存している点に注意したい。また自作ベンチと第三者ベンチではマージンの大きさが異なる。共通の比較相手であるopencodeに対して、自作ベンチでは+0.407、第三者ベンチでは+0.119で、外側では約29%しか残存しない。

モデルを固定してハーネスを替える

ハーネス自身の寄与を切り出すため、18タスクすべてを1つの固定フロンティアモデルで4ハーネスに走らせた実験がある。結果はMingbird 0.997、goose 0.989、opencode 0.925、agent-mini 0.478である。目を引く0.52の差は1つのアームが担っており、整った足場3つは0.072以内に収まる。

同じ表を逆に読むと、モデルのレバーはより大きい。ローカル4B級からフロンティア級へ替えたときの伸びはMingbird +0.121、goose +0.188、opencode +0.460で、agent-miniだけは−0.228と逆方向に動く。つまり主張は「ハーネスが常に拘束条件」ではなく、より狭く、欠陥的な足場はフロンティアモデルで測れる能力の半分以上を埋めてしまうというものだ。整った足場同士では、フロンティア級の差は0.072〜0.12程度に留まり、モデルが依然として支配的なレバーであり続ける。失敗の現れ方も確率的ではなく機構的で、あるタスクではopencodeのモデルが「何のタスク？」と返して終了し、別のタスクでは前面のサーバーで永久にブロックする間に、gooseは同じタスクを776秒で終えている。

どのメカニズムが効いたのか（アブレーション）

ここまではハーネス全体の効果を見てきた。次に知りたいのは、10あるメカニズムのうち実際に効いているのはどれかである。論文はv1.5.0のコード上で、18タスク×gemma4:e2b（各アームn=18）を対象に、1つのメカニズムだけを無効化して再実行するアブレーション（ablation＝要素を1つずつ外して寄与を見る実験）を行っている。

外して良くなる機構は1つもなく、方向としてはfinish gateが最大である。ただし論文自身がこれを「方向性のみ」と明示する。タスク単位のブートストラップ95%信頼区間は広く、finish gateでさえ−0.266〜+0.063とゼロをまたぐ。n=18では機構の効果とタスクごとの分散を切り分けられない。

さらに共通原因の問題が開示されている。長時間タスクのLH-01は、4つのアブレーションすべてでベースライン0.929から0.214〜0.259へ落ちる。4つの異なる機構を外した独立の実行が同じ量だけ落ちるのは、機構の効果ではなく共通原因であり、LH-01がバッチ条件に敏感な二峰性のタスクであることを示す。LH-01を除くと、方向が生き残るのはfinish gate（−0.062）だけで、アンチループとフラットprefillは符号が反転する。

graph LR
  A[ベースライン 0.821] --> B[LH-01 0.929]
  B --> C[4アーム共通で 0.214〜0.259]
  C --> D[LH-01が二峰性 = 共通原因]
  D --> E[LH-01除外後: finish gateのみ方向維持]

決着をつけたのは追試である。2026-09-22に全機構を有効にしたまま再実行すると、低いモードに入り18タスク平均は0.740だった（マトリクスでは0.821）。同夜の同一アームの反復は平均を最大0.069動かし、これは表のすべての名目デルタと同じ大きさである。つまり公表された4つのデルタは単発試行からの方向性推定であって、測定された限界効果ではない。

唯一きれいなバッチ一致比較が、実行可能なガードの価値を支持する。タスク文の再注入だけを残し、4つの実行可能ガードとtodo同期リマインダを無効化したアームとペアで比べると、3回の反復すべてで実行可能ガード側が優位だった（+0.096、+0.133、+0.056、平均+0.095）。テキストを読み直すだけでは足りず、実際に検証コマンドを走らせて失敗を会話に戻す部分に約0.1の価値がある、という読みになる。

機構がどれだけ働いたかも公開されている。Mingbirdの72セルでの発火回数は、配達自己点検（タスク文の再注入）65回、todo同期拒否43回、要約と成果物の突き合わせ23回、pytestガード拒否13回、計画完全性拒否11回、no-work完了拒否0回。アンチループ系は95回、計画陳腐化ナッジは99回である。ツール呼び出し量の中央値はMingbird 33.5、goose 15.0、opencode 5.0、agent-mini 7.0で、Mingbirdが最もツール集約的だった。ピークのプロンプト使用量は中央値14,624トークン、最大32,767トークン（設定済み32K予算）で、最も重いセルでも予算内に収まっている。

正直な限界と、それでも残る意味

ここまでの数字は強い。しかし論文は結果の直後に妥当性への脅威（threats to validity＝結論を弱めうる要因）を11項目並べ、自分の主張の射程を自分で狭めている。主要なものは次の通りである。

なかでも効くのは「単発試行」と「自作ベンチ」の組み合わせである。長時間セグメントのマージン（Mingbird 0.827対0.354〜0.484）はバッチ条件に敏感で、論文自身が「1セル1ドローの参考値」と位置づける。安定した量は全タスク平均とワークフローセグメントのマージンだという。

限界は、外部ベンチに出たときのマージンの縮小にも表れている。共通の相手であるopencodeに対する差は、内製ベンチでは+0.407、第三者ベンチでは+0.119で、残存率は29%である。

graph LR
  A["内製LRAB: opencode比 +0.407"] --> B["第三者τ²-bench: +0.119"]
  B --> C["残存 29%"]
  B --> D["retail+airline 164タスクでは native と分離せず (p=0.22)"]

それでも残る意味は小さくない。288セルの全公開、機構ごとの発火回数とトークンコストの公開、そしてここまで挙げた限界の明示は、この種の主張としては異例に誠実である。そして「小型モデルの不能力とされてきたものの相当部分は、実は足場の欠陥であり、その欠陥は対処可能である」という結論は、方向としては第三者ベンチでも一致している。著者の主張は「ハーネスが能力の上限を決める」ではなく、より狭く「欠陥的な足場は、フロンティアモデルでさえ測れる能力の半分以上を埋めてしまう」という点にある。

自宅環境で「使える」エージェントにするための設計指針

自宅のノートPCで2〜9B級のモデルをエージェントとして使いたいとき、最初に疑うべきはモデルの地力ではなく、モデルと環境をつなぐハーネス（harness＝足場）の設計である。順序が重要で、モデルを替える前にハーネスを替える。小型モデルが崩れる兆候はおおむね3つに集約される——固定前置きテキスト（prefill）が太すぎる、完了判定が甘い、ループ制御がない。以下はこの3点を含む、実装レベルのチェックリストである。

prefillを固定予算として扱う。 ツール定義はカテゴリ別に、入れ子のないフラットな形式で、必要になったときだけ読み込む。固定部分は単体テストで凍結し、1バイトでも増えたらCIで落とす。「新機能は正味ゼロ」という制約は、小型モデルでは性能そのものに効く。ツール数が増えたときの前置きコストは線形では収まらず、20ターンの実行では生成を始める前に分単位の待ち時間へ膨らむ。

完了を明示的な行為にする。 完了宣言を受け入れる前に元のタスク文を読み直させ、項目ごとに成果物の実在とテストの成否を実行して確かめる。失敗したときは、ファイル名・行番号・エラー文をそのまま会話に戻す。これだけで、成果物がないまま「完了しました」と答える失敗のかなりの部分が、正しい完了か、明示された詰まりに変わる。

ループをシグネチャで検出する。 ツール名＋正規化した引数を呼び出しのシグネチャとして数え、同一呼び出しが6回以上、または出力を伴わない連続呼び出しが15回以上で介入する。介入は段階的にし、修正ヒントの付与からターンの強制リセットへ進める。閾値は正当な反復（編集ごとのテスト再実行など）より十分高く取り、誤発動の代償を修正プロンプト1回に抑える。

壊れた出力は捨てずに救済する。 小型モデルはツール呼び出しを本文テキストとして書いてしまう。プレースホルダ引用、生のJSON断片、二重引用符の疑似呼び出しという頻出3形を実呼び出しに変換し、外れた形はフィードバック付きで拒否する。厳格なスキーマ強制は2〜9Bでは過剰になりやすい。

可逆性を最優先する。 書き込みごとに自動バックアップを残し、ロールバックはモデル自身が発行できる1コマンドにする。多ターンの修復が成立するかどうかは、この復旧手段の単純さで決まる。

OSの現実に合わせる。 Windowsではプロセスの出力がレガシーコードページで届く。読み取り側をUTF-8＋置換でデコードし、どのバイト列でもリーダーを落とさない。パス正規化やシンボリックリンクの扱いを誤ると、診断を出さないまま固まる。

安全は多層にし、しかし限界を知る。 不可逆操作の即時拒否、システム変更操作の在席格付け、作業ディレクトリ境界の検査、サブエージェントの既定拒否を重ねる。パターンリストによる防御は衝動的なツール使用には効くが、方法論的な敵対者には効かないと前提しておく。

壁時計（wall-clock）を設計変数にする。 ローカルモデルの利用者は待ち時間に敏感である。時間予算を明示し、締切が近づいたら収束を促す。

自分のハーネスを見直すときは、失敗の現れ方から逆引きすると速い。

再現性の前提も押さえておきたい。公開されているスコアは特定のコード版、特定のバックエンド、特定の収集期間に対してのみ再現可能である。競合するハーネスは生きた対象であり、後のリリースは別の実験になる。数値を突き合わせるときは、モデル・ハーネス・バックエンド・日付の4点を揃える。

よくある質問

結局、小型モデルでもエージェントは実用になるのか？

条件付きで「なる」。2B級のモデルでも、ハーネスが失敗形態ごとに対処していれば18タスク平均0.821に達し、同じモデルを素のクラウド向けフレームワークで動かしたときの0.017〜0.271とは桁が違う。一方で「どんな小型モデルでも」ではない。スキーマとして妥当なツール呼び出しすら形成できないモデルはハーネスでは救えない、というモデル側の床も明示されている。

ハーネスを替えるだけで、そんなに変わるのか？

同じモデル・同じマシン・同じ時間予算・同じ採点で、ハーネスだけを替えると平均0.886対0.405という差になる。ただし内訳が重要で、フロンティア級のモデルを固定して測ると、整った足場3つは0.072以内に収まる。つまりハーネスは万能薬ではなく、まず性能の下限を押し上げる装置である。

一番効くメカニズムはどれか？

方向性としては完了ゲート（finish gate）が最大で、除去すると−0.098。ただしこれは単発試行からの方向性推定であり、信頼区間はゼロをまたぐため、効果量として断定はできない。一方、実行条件を揃えたペア比較では、タスク文の再読だけの場合に対して実行可能な完了ガードが平均+0.095の価値を持ち、3回の反復で一貫して同じ側に出る。1つの銀の弾丸というより、失敗形態ごとの当て込みの束と考える方が実態に近い。

自宅のノートPCで本当に動くのか？

統合GPUと16〜32GBメモリの普通のノートPCが対象で、2〜4Bはほぼバックエンド素の速度でストリーミングする。32GBあれば35Bの長時間タスクも端から端まで走るが、約26トークン/秒と速くはない。主対象はWindowsで、LinuxとmacOSは実験的と位置づけられている。

クラウドのフロンティアモデルと比べてどうなのか？

論文はそこを直接比べていない。統制されているのは「同じモデルを別のハーネスで動かす」比較である。参考になるのは、フロンティアモデルを欠陥的な足場で動かすと0.478まで落ち、整った足場では0.925〜0.997に収まるという結果だ。ローカル小型モデルは絶対性能では及ばないが、「足場次第で測れる能力が大きく変わる」という性質は共通している。

この研究の一番の限界は何か？

自作ベンチであること、単一マシンであること、単発試行であることの3点が挙げられている。タスクと採点基準は作者自身が書いており、機構の一部はベンチを回しながら開発されたため、有利な方向のバイアスを完全には排除できない。緩和策は全288セルの公開と第三者ベンチでの複製で、方向は一致するものの外部で観測されるマージンは内部より小さい。

まとめ

2〜9B級のオープンウェイトモデルが実タスクでつまずくとき、その失敗の相当部分はモデルの能力不足ではなく、モデルの周りにあるハーネスの欠陥である。タスク開始前のツール定義でコンテキストを食い潰すprefill圧迫、失敗した呼び出しを自分で直せない自己修正の破綻、答えの代わりにツールを延々と実演するループ、成果物がないまま黙ってやめる静かな放棄。この4類型はどれも、モデルを再学習しなくても直せる工学上の問題だ。同じ2Bモデルが足場を替えるだけで0.017から0.821へ動いた、という観測がその端的な証拠になっている。

Mingbirdは、この4類型に逐一対応する10の中核メカニズムと5リングの安全モデルを、WindowsとOllamaで完結するローカルファースト構成として実装した。ハーネス自身が追加する固定テキストは797トークンに抑えられ、単体テストで値が固定され、CIが1バイトの増加も拒む。完了宣言の前に元のタスク文を読み直して成果物を検証し、ツール名と正規化した引数のシグネチャを数えてループを断ち、崩れた出力は救済して実行可能な呼び出しに変換する。書き込み前の自動バックアップとtrashへの削除で、多ターンの修復そのものを成立させている。

効果は対照実験で測られている。4ハーネス×4モデル×18タスクの288セルでMingbirdは平均0.886に達し、比較対象の0.631、0.479、0.405を引き離した。第三者ベンチの278タスクでも0.856（対0.791、0.737）で、方向は一致する。とくに2Bセグメントではベースラインが0.017〜0.271に散るなかで0.821に到達し、第2の小型モデルでも崖は消えた。崖は特定モデルファミリの癖ではなく、ハーネス側の性質だった。

ただし限界も明示されている。自作ベンチであること、単一マシンであること、単発試行であることの3点が残る。アブレーションは方向性のみとされ、フロンティア級のモデルを固定すると整った足場同士の差は0.072まで縮む。ハーネスは万能薬ではなく、まず性能の下限を押し上げる装置だ。

それでも結論の意味は変わらない。ローカルAIの次の焦点は「より大きなモデルを動かすこと」だけでなく、「手持ちのモデルを確実に動かしきる足場を設計すること」にある。そしてその設計は、288セルの生データとともに誰でも検証できる形で公開されている。

参考資料

• Mingbird: A Local-First Agent Harness Enabling Small Open Models to Complete Real Tasks（arXiv:2610.02001）
  • https://arxiv.org/abs/2610.02001
  • https://arxiv.org/html/2610.02001v1
• Mingbird-agent（コード・ベンチ・採点コード・288セル結果）
  • https://github.com/Mingbird/Mingbird-agent
• OpenCode 公式
  • https://opencode.ai/
• Block goose 公式ドキュメント
  • https://goose-docs.ai/
• Ollama 公式
  • https://ollama.com/
• Gemma 4 モデルカード（Google AI for Developers）
  • https://ai.google.dev/gemma/docs/core/model_card_4

関連記事

• エッジAIとローカルLLM：デバイス上での推論が変える未来
• ローカルPCでAIエージェントを動かす落とし穴: 推論時スケーリングを増やしても解決しないCUAの失敗モード