英語の原文: https://argusic.com/methodology

拘束力を持つのは英語版です。この日本語版と英語版が異なる場合は、英語版が適用されます。

最終更新日 2026年10月8日.

Argusic の評価方法

Argusic が実際のソフトウェアが動作するかどうかをどのようにテストし、AI コーディングエージェントをどのように採点するかを説明します。ここに書かれたルールはすべて、意図して公開しています。誰でも私たちの作業を検証できることこそが目的だからです。これらのルールの変更はすべてページ末尾の変更履歴に記録され、次のテストサイクルから適用されます。過去にさかのぼって適用することはありません。

1. 要点

2. この評価が答える問い

実際のオープンソースプロジェクトを与えられたとき、AI コーディングエージェントは完全に自力で、それをインストールし、起動し、エラーを解決し、ソフトウェアが動作することを検証できるでしょうか。初日のエンジニアのように、人の手を一切借りずに。

3. なぜ新しいプロジェクトを使うのか

静的なベンチマークは、その答えが学習データに漏れるにつれて劣化します。SWE-rebench (Badertdinov et al., 2025) は、同じエージェントを SWE-bench Verified と、そのベンチマークの公開後に収集したタスクの両方で実行し、スコアは大きく変わりました: 同論文の Table 2 では、DeepSeek-V3-0324 が SWE-bench Verified の 39.7% を解決し、時期で絞り込んだセットでは 21.3% にとどまっています。1 つのモデルだけで 18 ポイントの差です。Argusic はここ数週間でトレンドになっているプロジェクトをテストし、非公開プールを毎月入れ替えるため、暗記できるものは何もありません。

4. 計測するもの

計測するのはただ 1 つ、実際のソフトウェアを自律的に動かす能力です。テスト対象の各エージェントは、固定バージョンのモデル、固定バージョンのハーネス、Argusic が公開している標準の指示、そして同一の時間とリソースの制限の、決まった組み合わせです。すべてのエージェントにまったく同じ条件が与えられます。

5. テスト対象のエージェント

最初のサイクルは進行中です。エージェントの一覧は最初のリーダーボードとともに公開します。各エージェントは固定された構成で、中立的な Argusic の名義で表示されます。正確なバージョンは記録・保管されており、ボード上のすべての数値は、それを生み出した構成を正確にたどることができます。また、リクエストに応じて Argusic を通じて結果を再現できます (「結果の再現方法」を参照)。

6. プロジェクトプール

6a. テスト対象になれるもの

テスト対象とは、エージェントにセットアップと実行を依頼できるものです。Argusic は現在 1 種類をテストしており、結果の得られ方を一切変えずに他の種類を追加できるように作られています: 採点基準、証拠のルール、判定の語彙はソースが違っても同一なので、あるソースの数値は別のソースの数値と同じ意味を持ちます。

ソースここでの「動作する」の意味状態
オープンソースリポジトリ固定されたコミットをクローンし、インストールし、起動し、自身の README に書かれた役割を果たすことを検証します使用中。 3669 件のプロジェクトをテスト済み
Hugging Face のモデル固定されたリビジョンでモデルをダウンロードし、GPU ワーカー上でモデルカードの記載どおりに推論を実行します。ドキュメントのスニペットが、テスト担当が書き直すことなく、クリーンなマシンで出力を生成すれば動作するとみなします使用中。 1 件のプロジェクトをテスト済み
Hugging Face SpaceSpace を自身の定義からビルドして起動し、そのインターフェイスにアクセスして、うたわれている操作を完了します宣言済み、未開始
公開パッケージ (npm、PyPI)固定されたバージョンを空のプロジェクトにインストールし、自身の README のクイックスタートを実行します宣言済み、未開始
ベンダーツールベンダー自身が公開しているビルドを、ベンダー自身の手順だけに従ってインストールし、起動します宣言済み、未開始
構築済みのクラウドテンプレートテンプレートを掲載ページの記載どおりにデプロイし、テスト担当が事前に修正することなく、起動してうたわれているものを提供することを確認します宣言済み、未開始
コンテナイメージ固定されたダイジェストでイメージをプルし、自身の説明に書かれたコマンドを実行して、その説明がうたうとおりに動作することを確認します宣言済み、未開始
MCP サーバードキュメントどおりにサーバーをインストールして起動し、クライアントを接続して、うたわれているツールを一覧表示し応答することを確認します宣言済み、未開始

上の表の「状態」列は手で書かれたものではありません。このページが表示されるたびにデータベースから読み込まれます: その種類の公開済みテスト対象に記録された実行が 1 つでもあれば、そのソースは使用中と表示され、件数が示されます。これはこのサイトの他のすべての数値と同じルールであり、新しいソースが最初の結果を出したときに、誰かがこのページの更新を覚えておく必要はありません。

Hugging Face のテスト対象がリポジトリと異なる点は 2 つあり、どちらもあいまいにせず実行とともに記録されます。GPU ワーカーが必要なため、試行あたりのコストが高く、その予算は別に決められます。また、モデルカードはアプリケーションではなくコードスニペットを説明していることが多いため、検証される振る舞いは「製品が動作する」ではなく「ドキュメントのスニペットが出力を生成した」です: 実行ページにはどちらなのかがその言葉で書かれ、スコアは同じ方法で与えられます。

表で「近日公開」ではなく「未開始」と書いているのは意図的です。あるソースが使用中と数えられるのは、その種類の実際の実行が証拠とともに記録された日からであり、1 日たりとも早まることはありません。 それまでは、その行は範囲の表明であって、結果の表明ではありません: まだ実行されていないソースについて、判定、件数、ランキング、シェアカードを表示するページはなく、予定中のソースの名前が出るのはこの表だけです。

7. 1 回の計測

  1. クリーンな使い捨てのマシン (その正確な環境は公開されています)。外部からの接続は受け付けず、実行が終わると破棄されます。この版では外向きのネットワークアクセスはフィルタリングしていません。実行を制限するのは、使い捨てのマシンと、この一覧の下にあるモデルキーのルールです。マシンは固定されたコミットのみを取得し、プロジェクトの履歴は取得しません。履歴はテストの一部ではないためです。
  2. エージェントは 1 つのミッションを受け取ります: 公開されている標準の指示のもとで、このプロジェクトを動かすことです。
  3. 時間制限。すべての実行には、ちょうど 3 種類ある予算 (一覧の下の表) のいずれかが与えられ、与えられた予算はその実行ページに表示されます。
  4. 独立した 3 回の実行。中央の結果を採用します。3 つの結果が 30% を超えて離れている場合、そのセットは不安定としてフラグが付き、そのサイクルのボードから除外されます。
  5. すべての実行は完全なログと完全なターミナル録画を保存し、結果とともに公開します。
  6. デスクトップアプリケーションは、マシン内の仮想ディスプレイ上で起動します (v1.1 から)。「起動した」とは、アプリケーションのメインプロセスがそのディスプレイ上で開始して動き続けたこと、またはバージョンやヘルプのコマンドに応答したことを意味します。何もクリックしません。計測するのは、そのソフトウェアが新しいマシンで立ち上がるかどうかであり、他のすべてのプロジェクトに問うのと同じ問いです。エージェントはモデルに画像を送らないよう指示されています (v1.3 から): 標準のモデルはテキストしか受け付けず、メッセージに添付されたスクリーンショットによって、レポートの前にセッションが終了したことがあったためです。

項目 3 の時間予算:

区分予算
standard90 分
heavy120 分
gpu120 分

standard の予算は v1.3 より前は 45 分でした: 最初の週のある 1 日に、38 件のタイムアウトのうち 36 件が、予算を使い切った時点でまだ実行中のビルドだったため、倍にしました。heavy の区分は v1.2 からあり、Owner が heavy と指定したプロジェクト、または GitHub の報告でリポジトリが 500 MB を超えるプロジェクトが対象です。大きなゲームやデスクトップアプリケーションはビルドにそれだけの時間がかかるためです。GPU が必要なプロジェクトにも同じ 120 分が与えられます。

上の 3 つの数値は飾りではありません。scripts/check-ttl-methodology.sh がこの表を読み、オーケストレーターに実際に設定されている予算と比較し、一致しなければ make test が失敗します。このチェックがあるのは、2026-09-06 から 2026-09-11 までの間、稼働中のシステムの GPU 予算は 240 分だったのに、このページには 120 と書かれており、両者を比較するものが何もなかったためです (ISSUE-072)。

モデルキー。エージェントがモデルを呼び出すにはキーが必要で、実行では信頼できないプロジェクトのコードを実行するため、そのキーは最も制限すべき認証情報です。Argusic のルーティング層を通じてモデルにアクセスするエージェントでは、実行ごとに、その実行のためだけに作成されたキーが与えられます。 各実行のモデルキーの支出上限: 3 USD。 キーは実行が終了したとき、キャンセルされたとき、またはタイムアウトしたときに削除され、定期的なスイープが、実行中のジョブに属さなくなったキーをすべて削除します。実行のキーを作成できない場合、その実行は開始されず、再試行されます。共有キーで代用することは決してありません。モデル提供元自身のサービスを使うエージェントは、実行ごとのキーではなく、Argusic が保持する共有キーでそのサービスを呼び出します。これらを実行ごとのキーに移行することはバックログに入っています。上の上限の行は scripts/check-cost-methodology.sh が読み取り、設定値と一致しなければ make test を失敗させます。理由は時間予算と同じです。

8. 採点 (100 点満点)

実行の結果は次のいずれかです:

結果意味
pass_full実行され、実際に検証された
pass_mock実行され、モックサービスに対して検証された
failインストールできなかった、または起動できなかった
timeout時間切れになった

4 つの採点項目だけでは、暗黙のままになるケースがあります。それらはコードの中だけでなく、ここで定めます。誰も読めないルールは、誰も検証できないルールだからです。採点は決定論的なプログラムで行われ、以下のすべてのルールをテストがカバーしています。採点のどの段階にも AI モデルは関与しません。

9. 多数の実行から 1 つのボードスコアへ

採点は、プロジェクトとエージェントの 1 つの組を評価します。リーダーボードにはエージェントごとに 1 つの数値が必要で、それらをどう組み合わせるかは評価方法の選択なので、ここに明記します。

エージェントのボードスコアは、プロジェクトごとの中央値スコアの、さらに中央値です。平均ではなく再び中央値を使う理由は同じです: 1 つのひどいプロジェクトが有能なエージェントを引き下げるべきではなく、1 つの幸運なプロジェクトが弱いエージェントを押し上げるべきでもありません。

この数値から除外される結果は 2 種類あり、どちらもボードには表示されるので、除外は黙って行われるのではなく目に見えます: 不安定としてフラグが付いた結果 (次のセクションを参照) と、確認中としてフラグが付いたプロジェクトのすべての結果 (環境の品質管理を参照) です。

すべての結果が除外されたエージェントにはボードスコアがありません。削除するのではなく、スコアなしで最下部に表示します。テストされて使える結果を何も出せなかったエージェントは、それ自体が 1 つの結果であり、それを隠すと全体を不当によく見せることになるためです。

合格率は、そのサイクルでエージェントが行ったすべての試行を数えます。失敗とタイムアウトも含みます。後述の「独立性と結果の選り好みの禁止」を参照してください。

10. ばらつきと不安定性

ばらつきとは、3 回の実行の範囲を、その中央値に対する割合で表したものです:

spread = (highest - lowest) / middle * 100

ばらつきが 30% より厳密に大きい場合、そのセットは不安定としてフラグが付きます。ちょうど 30% は 30% 超ではないため、ボードに残ります。この式から 2 つの例外的なケースが導かれます:

11. プロジェクトの判定

ボードはエージェントをランク付けします。判定は、プロジェクトそのものについての別の問いに答えます: 新しく来た人が、AI エージェントという形で、今日このソフトウェアを動かせるでしょうか。

証拠が一方向にしか働かないため、テストは適応的に行います。1 回の合格はプロジェクトが動作することを証明します。1 回の失敗はそれだけでは何も証明しません。失敗の原因はプロジェクトではなくエージェントにあるかもしれないからです。

  1. まず、標準のエージェントが 1 回実行します。合格すればそこで終わりです: 完全な合格なら「動作する」、モックサービスに対する合格なら「モックで動作する」になります。動作することがすでに示されたものを、テストし続ける理由はありません。
  2. 失敗した場合、同じエージェントで 1 回再試行し、一度限りの偶然を排除します。
  3. それでも失敗した場合、判定は「壊れている」ではなく「検証できず」になります: Argusic はエージェントにできたことを報告し、まさにそのことを述べます (v1.3 から: 標準のエージェントで完全な試行が 2 回行われれば判定が確定します)。リクエストに応じて、より強力なエージェントを実行することがあります。その場合、その合格によってプロジェクトは「動作する」になり (記録には検証したエージェントが示されます)、その失敗もまた「検証できず」を確定させます。

完全な試行とは、エージェントが自身の終わりまで、または制限時間まで作業している様子が録画に示されている試行です。Argusic 自身のツールが途中で打ち切った試行 (エージェントのレポートを読めなかったハーネス、プロジェクトと無関係な計測機器のエラー) は、理由を実行に保存したうえで無効とされ、証拠とともに公開されたまま残り、数には入りません。

判定は、いずれかの試行が到達した最良の結果です:

判定がどうであれ、すべての試行は完全な証拠とともに公開されます。例外は 1 つだけです: 有効な認証情報が含まれていないことを証明できない録画は公開を保留され、その実行は再実行されます (セクション 17「セキュリティのための秘匿」)。

12. Argusic が計測しないもの

誤読を防ぐため、はっきり述べます。Argusic は、エージェントが書くコードの長期的な品質、その修正のセキュリティ、機能レベルの深い製品体験を計測しません。計測するのはただ 1 つ、実際のソフトウェアを自律的に動かす能力です。

13. 独立性と結果の選り好みの禁止

14. ハーネスの開示

ハーネス (モデルを取り巻く足場、ツール、指示、制限) は公開されており、1 つのサイクル内ではすべてのエージェントで同一です。スコアの違いは、仕組みではなくエージェントに帰せられるものでなければなりません。ハーネスの変更はサイクルの間にのみ行われ、変更履歴に記録されます。

15. 環境の品質管理

あるプロジェクトがすべてのエージェントで失敗した場合、自動的に確認中としてフラグが付き、人が確認するまで採点から除外されます: その失敗の原因は、エージェントではなく環境やプロジェクトにあるかもしれないからです。共通のセットアップの問題を、エージェントの失敗として採点することがあってはなりません。

16. 検証とはデコードすることであり、調べることではない

ファイルが存在することは結果ではなく、そのヘッダーを読むことはチェックではありません。ffprobe -show_streams、file、バイト数は、どれもコンテナを報告するだけで何もデコードしません: すべてのフレームが緑一色の動画も、正常な動画とまったく同じようにこの 3 つすべてを通過します。v1.4 から有効なルールは、エージェントは自分がデコードしたものを報告し、予想したものを報告してはならない、というものです。

17. 証拠の完全性

2 つの層があり、決して混同しません。

証拠の層は未加工で永続的です: すべての実行は、実際のセッションの完全なターミナル録画を生成し、グラフィカルなアプリでは未加工のセッション動画も生成し、さらに完全なログを生成します。各ファイルは到着時にフィンガープリントが取られ、永久に保存されます。誰でも、編集されていないセッション全体を再生できます。

表示の層は派生物です: ソーシャル向けの動画や画像はすべて、証拠からレンダリングしたものです。許可される編集は、早送り、長さのためのトリミング、記録されたエラーと修正のタイムラインから作る字幕、ナレーションです。禁止される編集は、出来事の順序の入れ替え、別々のセッションのつなぎ合わせ、失敗の隠蔽、エージェントが行ったことの実質の改変です。公開されるすべての動画は、その証拠にリンクしています。

録画には、配信される前に 3 つの派生的な変換が適用されますが、どれもエージェントの作業の実質を変えるものではありません:

引用されたテキストには、表示上の変換が 1 つ適用されます (Owner の決定 2026-09-04): ページがエージェント自身の最終状態の文 (「テストでわかったこと」) やリポジトリの GitHub の説明を表示するとき、作者が入力したダッシュは、サイトの句読点の方針に合わせてカンマまたはピリオドとして表示されます。保存されたレポート、リポジトリの記録、ログ、録画、録画からレンダリングされた画像はそのままです。言葉とその順序が変わることはありません。

常設のルール: すべての数値はログにたどり着き、すべてのフレームは実際のセッションの録画にたどり着きます。

18. 結果の再現方法

すべての結果のプロジェクト側は完全に公開されています: テストされた正確なコミット、公開されている環境、標準の指示、そして完全なログと録画です。各実行のページにはこれらがすべて掲載されています。エージェントは中立的な名義のもとで固定された Argusic の構成であり、Argusic がその正確なバージョンを保持し、結果を再現するために再実行できます。公開プロジェクトの一覧と非公開プールの開示は、最初のリーダーボードとともに公開されます。

19. 結果への異議申し立て

メンテナーや研究機関が結果を誤りだと考える場合、異議を申し立てることができます。実行のリンクを添えて [email protected] までご連絡ください。私たちは完全なログと録画を主張と照らし合わせて確認し、返信します。結果が私たちの側の環境やセットアップの問題の影響を受けていた場合は、再実行し、注記を付けて記録を訂正します。証拠が元の結果を支持している場合は、録画が何を示しているかを説明します。元の証拠が編集または削除されることはありません。

20. 変更履歴

各版には 2 つの日付があり、それぞれ別の問いに答えます。記載日は、そのルールがこの文書に記録された日です。適用開始日は、そのルールのもとで最初の実行が実際に計測された日で、このファイルではなく実行記録から読み取ります。通常は一致します。一致しない場合は実行記録が優先され、ここに記載されます。このページに届く前にマシンに届いていた版こそ、変更履歴が開示するために存在するものだからです。どの版も過去にさかのぼって適用されることはありません: 実行は、それが行われた日に有効だったルールを保持します。

v0.2 から v1.0 までの版はすべて 2026-08-31 に、最初の公開版を作成したコミットで記録されました。以下の日付は、最初の計測より前に、ルールそのものが決定された日です。

付録: ハードウェアの推定値、何が収まり、どれだけ速いか

以下の推定値は、Argusic が掲載しているプログラミング、AI、データサイエンス向けのノートパソコンとデスクトップの横に表示されます。

この付録は上記のベンチマークのルールの一部ではなく、どの版も変更しません: Argusic が販売中として掲載しているノートパソコンとデスクトップの横に表示する推定値について説明します。これらはメーカーが公開している数値に基づく計算であり、計測値ではありません。ここに示す数値は 1 つの共有ファイル (lib/hardware-estimates.ts) で計算されており、そのファイルとそのテストを同じコミットで変更しない限り、どの数値も変更できません。

Argusic のハードウェア一覧では、ノートパソコンとデスクトップごとに、保持できる最大のモデルサイズと、テキスト生成速度の上限を表示しています。どちらも推定値です: メーカーが公開している仕様から、以下の式で計算しています。Argusic はこれらのマシンでモデルを実行していません。Argusic が実際にマシンを計測した場合、その数値には計測値のラベルが付き、実行ログにリンクし、推定値と混同されることはありません。

推定値は、すべての入力がわかっている場合にのみ表示されます。メモリ容量、メモリの種類、チップの帯域幅のいずれかが不明な場合、ページには推測ではなく「不明」と表示されます。

入力とその出所

メモリ: どのモデルサイズが収まるか

モデルには 3 つのものを置く場所が必要です。

  1. 重み。 Argusic は llama.cpp の Q4_K_M 量子化を想定し、重みあたり 4.8944 ビットとします (llama.cpp quantize README):
  2. 重みのバイト数 = パラメーター数 x 4.8944 / 8。 例 (計算値であり、計測値ではありません): 70B のモデルには 42.8 GB の重みが必要です。

  3. コンテキスト (KV キャッシュ)。 NVIDIA の式によります (Mastering LLM Techniques: Inference Optimization、NVIDIA Technical Blog、2023-11-17):
  4. トークンあたりの KV キャッシュのバイト数 = 2 x レイヤー数 x (ヘッド数 x ヘッドの次元) x 値あたりのバイト数。 最近のモデルはアテンションヘッド間でキー/バリューのヘッドを共有する (grouped-query attention) ため、ここでの「ヘッド数」は、モデルが実際にキャッシュするキー/バリューのヘッドの数です。Argusic は 16 ビット精度 (2 バイト、llama.cpp のデフォルトのキャッシュ型) で 8,192 トークンのコンテキストを見込み、区分ごとに 1 つのオープンな dense モデルの公開構成を使います: Qwen3-8B、Qwen3-14B、Qwen3-32B、Qwen2.5-72B-Instruct、Mistral-Large-Instruct-2411。

  5. ランタイムのオーバーヘッド。 Argusic は推論ランタイム自身のバッファ用に 1 GB を見込みます。

8,192 トークンのコンテキストと 1 GB のオーバーヘッドは Argusic の見込み値であり、計測ではなく方針としての選択です。より長いコンテキストにはより多くのメモリが必要です。ここで収まるモデルでも、ずっと長い会話では収まらない場合があります。

マシンのメモリのうちどれだけを数えるか。 ディスクリート GPU の VRAM はすべて数えます。ユニファイドメモリまたはシステムメモリについては、Argusic は 75% を数え、25% をオペレーティングシステムと他のプログラムのために残します。これは AMD が自社のユニファイドメモリのチップについて述べている内容と一致します: 128GB のうち最大 96GB を VRAM に変換でき (AMD)、64GB では最大 48GB まで可能です (AMD)。

メモリ容量は、メーカーが帯域幅に使うのと同じ単位である 1 GB = 10^9 バイトとして読みます。メモリは実際には 2 進単位で容量が決まっているため、これにより容量を約 7% 少なく見積もることになり、収まるかどうかの判定はすべてやや控えめになります。

上記のルールから計算した、各区分に必要な量:

区分重み (Q4_K_M)コンテキストの見込みオーバーヘッド必要量VRAM の下限ユニファイドメモリの下限
7-8B4.89 GB1.21 GB1 GB7.10 GB7.10 GB9.47 GB
14B8.57 GB1.34 GB1 GB10.91 GB10.91 GB14.54 GB
27-32B19.58 GB2.15 GB1 GB22.73 GB22.73 GB30.30 GB
70B42.83 GB2.68 GB1 GB46.51 GB46.51 GB62.01 GB
120B 以上73.42 GB2.95 GB1 GB77.37 GB77.37 GB103.16 GB

たとえば、8GB の GPU には 7-8B の区分が、24GB の GPU には 27-32B の区分が、64GB のユニファイドメモリには 70B の区分が収まります。最初の行を下回るマシンは、どの区分も収まらないと表示されます。

速度: 上限であり、予測ではない

各トークンを生成するには、モデルのすべての重みをメモリから 1 回読み込む必要があるため、テキスト生成はメモリ帯域幅によって制限されます (NVIDIA: "Model execution is frequently memory-bandwidth bound")。これにより上限が決まります:

1 秒あたりのトークン数の上限 = メモリ帯域幅 / 重みのバイト数。

例 (計算値であり、計測値ではありません): 546 GB/s のチップで 8B のモデルを Q4_K_M (重み 4.89 GB) で実行すると、1 秒あたり約 111 トークンを超えることはできません。

実際の速度は常にこれより低くなります。 この上限は、コンテキストの読み込み、計算、ソフトウェアのオーバーヘッドにかかる時間を無視しています。llama.cpp discussion #4167 に集められた計測では、速度は帯域幅とともに上がりますが、比例よりは低くなっています。Apple silicon 上の Llama 2 7B (Q4_0) では: M3 Max (400 GB/s) で 1 秒あたり 66.31 トークン、M4 Max (546 GB/s) で 83.06、M2 Ultra (800 GB/s) で 94.27。400 から 546 GB/s (帯域幅 1.37 倍) で速度は 1.25 倍、800 GB/s に倍増すると 1.42 倍でした。この上限は「このマシンはこれより速くなれない」と読み、「このマシンはこの速度で動く」とは決して読まないでください。

この上限は、トークンごとにすべての重みを読み込む dense モデルを想定しています。Mixture-of-experts モデルはトークンごとに有効なエキスパートだけを読み込むため、総サイズから想定される上限より速く動作することがあります。

1 ドルあたりのモデル用メモリ

この一覧の並べ替えの 1 つは、1 ドルあたりのモデル用メモリです: モデル用メモリ (VRAM またはユニファイドメモリ) のギガバイト数を現在の Amazon の価格で割ったもので、価格の日付も表示します。「この金額で最も大きなモデルを保持できるのはどれか」に答えるものです。品質や速度のランキングではなく、手数料によって変わることもありません。

これらの推定値ではないもの