Prime Agent Benchmark 2026：実測と検収

「タスク完了」と表示されたのに、テスト失敗や大量の手戻りが残っている。
最短の解決策は、公式ランキングを採用根拠にせず、同じモデル、タスク集、権限、予算で既存エージェントとPrime Agentを並行実行し、完了率・総時間・呼び出し量・人的修正率を記録することです。

この記事は、Prime Agentが既存のコーディングエージェントより優れているか検証する開発責任者、長時間タスクのAPI消費を見積もるインフラ担当者、Agent Evalsの回帰テスト体系を作るAIエンジニア向けです。

最終更新：2026年8月11日。Prime Agentの現行リポジトリ、公式ドキュメント、ライセンス、実行コマンドを同日に確認しています。

公式情報を検収の出発点に限定する

Prime Agentの公式リポジトリでは、RLMによる再帰的なサブエージェント呼び出し、永続的なIPythonカーネル、バックグラウンドセッション、目標保持、コンテキスト圧縮などが説明されています。端末を閉じてもセッションを再接続できる設計は、短い補完型ツールとは異なる評価軸を必要とします。

一方、公式説明にある機能や公開ベンチマークの結果は、あなたのリポジトリで同じ納品品質が出ることを保証しません。特に、評価タスクの種類、モデル、ツール権限、制限時間、失敗時の再試行条件が違えば、数値を横並びにしても意思決定には使えません。

Prime Agentの構造と現在の機能は、公式リポジトリのREADMEと公式クイックスタートで確認できます。検収では、そこに書かれた機能を「評価項目」に変換し、結果そのものは自分の環境で取り直してください。

正確率を三つの層に分ける

最終回答が自然に見えるだけでは、開発タスクの成功とは言えません。少なくとも、次の三層を別々に記録します。

• タスク完了：要求されたファイル変更、設定変更、ドキュメント更新などが実施されているか。
• テスト合格：既存テストと追加した回帰テストが通り、禁止された変更や未処理の警告が残っていないか。
• 保守可能な成果物：差分がレビュー可能で、命名、依存関係、エラー処理、将来の変更容易性を損なっていないか。

ここで重要なのは、テストが通っても保守可能とは限らない点です。たとえば、例外を広く握りつぶしてテストだけを通す、既存の仕様を変更して期待値を書き換える、不要なファイルを大量に変更するといった成果は、表面上の成功率を押し上げますが、実運用の納品品質を下げます。

検収時には、公開テストとは別に隠しテストを用意してください。評価対象に知らせない入力、境界値、権限不足、既存仕様との競合を含め、次の記録を残します。

• 隠しテストの合否。
• 変更差分に対するコードレビュー結果。
• 人が修正した行数ではなく、修正に要した時間。
• エージェントが成功と報告したが、受け入れ条件を満たさなかった件数。

この方法なら、自報の成功率をそのまま採用基準にする危険を抑えられます。

エンドツーエンド時間を分解する

速度の比較で、モデルが返答を始めるまでの時間だけを測ってはいけません。Prime Agentのようにサブエージェント、永続カーネル、バックグラウンド実行を使う構成では、実際の納品までに複数の待ち時間が発生します。

計測対象は、次の合計です。

• 環境の起動とリポジトリの準備。
• 初期調査と計画。
• ファイル読み込み、シェル、テストなどのツール呼び出し。
• 子エージェントの実行と結果待ち。
• モデルの再試行、コンテキスト圧縮、失敗後のやり直し。
• 最終テスト、差分確認、人による受け入れ判定。

短いタスクだけでは、起動コストや状態保持の価値を測れません。最低でも、短時間の単一ファイル修正、複数ファイルのリファクタリング、テスト補完、長時間の調査と修正を分けてください。各タスクは一回の最速値ではなく、複数回の実行結果から中央値と最悪値を記録すると、偶然の速さに引きずられにくくなります。

公式の利用説明では、/usageからトークン、費用、コンテキストの内訳を確認でき、セッションはJSONL形式で保存されるとされています。したがって、画面に表示された完了時刻だけでなく、セッションログと外部の開始・終了時刻を突き合わせる運用にしてください。詳細は公式の利用ガイドで確認できます。

総費用を一回の納品単位で集計する

Prime Agentの費用を主モデルのAPI料金だけで計算すると、長時間タスクでは過小評価になりやすいです。総費用は、次の式で管理すると比較しやすくなります。

有効納品コスト ＝ 主モデル費用 ＋ 子エージェント費用 ＋ 再試行費用 ＋ コンテキスト圧縮費用 ＋ 外部ツール費用 ＋ 実行環境費用 ＋ 人的修正費用

ここでの「有効納品」は、受け入れ条件を満たし、レビュー後に実用可能な成果物だけです。失敗したタスクを分母から外すと、失敗するほど安く見えるため、次のように分けて記録します。

• タスク単位の総呼び出し量。
• 成功、部分成功、失敗の件数。
• 失敗後に必要となった再実行回数。
• 人が引き継いだ時間。
• 1件の有効納品に必要だった平均費用。

Prime Agentは、rlm(...)による子エージェント呼び出しや、長時間セッションの保持を備えています。これらは作業を分担できる一方、子エージェントが増えるほど呼び出し量と待ち時間が増える可能性があります。子エージェントを使ったかどうかだけでなく、何件起動し、どの結果が最終成果に使われたかまでログ化してください。

長時間タスクの復旧性を確認する

長時間動くエージェントでは、処理が続いたことと、正しい状態から再開できたことを分けて評価します。公式ドキュメントでは、端末切断後の再接続、保存セッション、永続目標、ハートビート、スケジュールなどが説明されていますが、実際のプロジェクトで重複実行や進捗欠落が起きないかは別途確認が必要です。

次の中断試験を、少なくとも一度は実施してください。

1. クリーンな作業コピーを用意し、コミットIDと環境変数を記録します。
2. Prime Agentに、複数ファイル変更とテスト実行を含むタスクを与えます。
3. 計画、調査、実装、テストのいずれかの段階で端末接続を切断します。
4. セッションを再接続し、目標、作業済みファイル、子エージェントの状態を確認します。
5. 再開後に同じコマンドやマイグレーションを重複実行していないか調べます。
6. 最終差分、テスト結果、ログを中断なしの実行結果と比較します。

プロセスが再開しただけで合格にしてはいけません。進捗を失って最初からやり直していれば、復旧性の評価は不合格です。また、Prime Agentはモデル生成のPythonやプロジェクトコマンドをユーザー権限で実行し、公式にもセキュリティサンドボックスではないと明記されています。機密リポジトリや未検証の指示を直接投入せず、隔離環境で権限と秘密情報を制限してください。構成上の境界は公式アーキテクチャ資料に整理されています。

公平な比較条件を固定する

Prime Agentと既存のコーディングエージェントを比べるとき、ツール側だけを変えて他の条件を動かすと結果が崩れます。比較開始前に、次の項目を固定してください。

• 同じリポジトリ、同じコミット、同じ依存関係。
• 同じモデル名とモデルのバージョン。
• 同じシステム指示、タスク文、入力ファイル。
• 同じネットワーク、ファイル、シェル、Gitの権限。
• 同じ時間上限、トークン上限、再試行上限。
• 同じ合格条件と、同じ人によるレビュー担当。

タスク集は、修正難度が異なる三種類以上に分けます。具体的には、既存の不具合修正、跨数ファイルのリファクタリング、テスト補完を基本セットにし、必要に応じて依存関係更新や設定移行を追加します。タスク文をPrime Agentだけに詳しく書き、既存ツールには短く渡すような設計は、比較ではなくプロンプトの差になります。

チェック項目は次のように運用できます。

• [ ] 正解を判定する隠しテストがある。
• [ ] テスト合格とレビュー合格を分けた。
• [ ] 冷起動、短時間、長時間の実行を含めた。
• [ ] 主モデル、子エージェント、再試行の呼び出し量を保存した。
• [ ] 中断と再接続を試した。
• [ ] 人的修正時間を記録した。
• [ ] 同じ予算と権限で既存ツールも実行した。
• [ ] 評価後に使用モデルやプロンプトを変更していない。

なお、Prime Agentのソースから実行する場合、公式クイックスタートではNode.js 22.8.0以上が必要とされています。公開インストーラーを使う場合とソース実行を使う場合で準備条件が異なるため、どちらを採用したかを実験記録に残してください。

判定条件を三段階にする

測定結果をそのまま「勝ち負け」に変換すると、短いタスクで優れたツールが長時間運用で失敗するケースを見落とします。次の条件分岐で、導入範囲を決めてください。

• タスク完了率、テスト合格率、保守可能性が既存ツール以上で、総費用も許容範囲内の場合
  → 監査ログと権限制御を付けたうえで、限定チームに導入します。
• 完了率は高いが、呼び出し量、待ち時間、人的修正が不安定な場合
  → 低リスクの調査、テスト作成、文書化に限定して試用を続けます。
• 長時間タスクで目標を失う、重複実行する、失敗を成功扱いする場合
  → 本番移行を保留し、復旧手順と品質ゲートを先に整備します。
• 物理デバイス、特定のローカル認証、社内ネットワークへの直接接続が必須の場合
  → クラウド環境を無理に標準化せず、専用の実行場所またはローカル運用へ戻します。
• 複数タスクを並列で回し、実行時間とAPI消費を継続的に測りたい場合
  → 共有環境ではなく、ジョブ単位で分離できる環境を選びます。

Prime Agentのセッション、サブエージェント、モデル、費用内訳を継続的に確認する方法は、長時間エージェントの公式資料とRLMの公式説明に沿って設計できます。

環境選定と次の一手

自分のMacで試す方法は、物理デバイスやローカル認証を扱える反面、空き時間の確保、環境差、作業中断、複数担当者による再現性の低さが問題になります。共有サーバーだけに寄せる方法も、同時実行による性能変動、権限分離の難しさ、長時間セッションの管理負荷が残ります。

Prime Agentを短期間で検収する段階なら、隔離されたクラウドMacに同じイメージ、同じリポジトリ、同じモデル設定を用意し、既存ツールと並行実行する方が比較しやすいです。必要な期間だけ日本向けMacレンタル環境を確保し、利用後はログと作業コピーを廃棄する運用なら、自社端末を検証専用に占有せずに済みます。環境の権限や接続条件に不明点がある場合は、ZavCloudのヘルプセンターで事前に確認してください。

自前のMacは、長期にわたり同じ負荷をかけ、物理アクセスや社内システム接続が必要な場合に向いています。ただし、検証のたびに環境を作り直す手間、担当者の端末差、長時間タスク中の占有が発生します。検収期間だけクラウドMacをレンタルすれば、Prime Agentと既存ツールを同じ条件で隔離し、先に自社の基準値を取ってから購入や本番移行を判断できます。必要ならZavCloudへの相談窓口から、検証期間と接続要件を伝えてください。