英語の原文: https://argusic.com/methodology
拘束力を持つのは英語版です。この日本語版と英語版が異なる場合は、英語版が適用されます。
最終更新日 2026年10月8日.
Argusic の評価方法
Argusic が実際のソフトウェアが動作するかどうかをどのようにテストし、AI コーディングエージェントをどのように採点するかを説明します。ここに書かれたルールはすべて、意図して公開しています。誰でも私たちの作業を検証できることこそが目的だからです。これらのルールの変更はすべてページ末尾の変更履歴に記録され、次のテストサイクルから適用されます。過去にさかのぼって適用することはありません。
1. 要点
- 実際のオープンソースプロジェクトを選び、AI エージェントに人の手を借りずにインストール、起動、デバッグを試みさせます。新しく入ったエンジニアが初日に行うのとまったく同じです。
- すべてのテストは最初から最後まで記録されます。公開されるすべての数値は、そのログとターミナル録画にリンクしています。
- 各プロジェクトには明確な判定が付きます: 動作する、モックサービスで動作する、または検証できなかった、のいずれかです。
- エージェントは同一の条件で比較されます。それぞれ 3 回実行し、中央の結果を採用します。結果のばらつきが大きすぎるものはフラグを付けて除外します。
- 私たちはエージェントを販売せず、結果を変えるための金銭も受け取りません。Argusic は審判です。
- 計測は自動化されています。文章はそうではありません: このサイトの文章はモデルが書いたものではなく、ページ上の数値はすべて記録された実行から埋められたテンプレートであり、公開前には必ず人が承認します。コンテンツの作成方法をご覧ください。
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. プロジェクトプール
- 80% は公開プール: 一覧と正確なバージョン (コミットハッシュ) を各サイクルの前に公開します。
- 20% は非公開プール: 過去 30 日間にトレンドになったプロジェクトから選び、サイクル終了後にのみ公開し、毎月入れ替えます。これにより、エージェントがテスト向けに調整されることを防ぎます。
- 選定基準: 寛容なライセンス、README があること、言語と難易度のばらつき、そして有料アカウントなしで基本的なレベルで実行できること。
6a. テスト対象になれるもの
テスト対象とは、エージェントにセットアップと実行を依頼できるものです。Argusic は現在 1 種類をテストしており、結果の得られ方を一切変えずに他の種類を追加できるように作られています: 採点基準、証拠のルール、判定の語彙はソースが違っても同一なので、あるソースの数値は別のソースの数値と同じ意味を持ちます。
| ソース | ここでの「動作する」の意味 | 状態 |
|---|---|---|
| オープンソースリポジトリ | 固定されたコミットをクローンし、インストールし、起動し、自身の README に書かれた役割を果たすことを検証します | 使用中。 3669 件のプロジェクトをテスト済み |
| Hugging Face のモデル | 固定されたリビジョンでモデルをダウンロードし、GPU ワーカー上でモデルカードの記載どおりに推論を実行します。ドキュメントのスニペットが、テスト担当が書き直すことなく、クリーンなマシンで出力を生成すれば動作するとみなします | 使用中。 1 件のプロジェクトをテスト済み |
| Hugging Face Space | Space を自身の定義からビルドして起動し、そのインターフェイスにアクセスして、うたわれている操作を完了します | 宣言済み、未開始 |
| 公開パッケージ (npm、PyPI) | 固定されたバージョンを空のプロジェクトにインストールし、自身の README のクイックスタートを実行します | 宣言済み、未開始 |
| ベンダーツール | ベンダー自身が公開しているビルドを、ベンダー自身の手順だけに従ってインストールし、起動します | 宣言済み、未開始 |
| 構築済みのクラウドテンプレート | テンプレートを掲載ページの記載どおりにデプロイし、テスト担当が事前に修正することなく、起動してうたわれているものを提供することを確認します | 宣言済み、未開始 |
| コンテナイメージ | 固定されたダイジェストでイメージをプルし、自身の説明に書かれたコマンドを実行して、その説明がうたうとおりに動作することを確認します | 宣言済み、未開始 |
| MCP サーバー | ドキュメントどおりにサーバーをインストールして起動し、クライアントを接続して、うたわれているツールを一覧表示し応答することを確認します | 宣言済み、未開始 |
上の表の「状態」列は手で書かれたものではありません。このページが表示されるたびにデータベースから読み込まれます: その種類の公開済みテスト対象に記録された実行が 1 つでもあれば、そのソースは使用中と表示され、件数が示されます。これはこのサイトの他のすべての数値と同じルールであり、新しいソースが最初の結果を出したときに、誰かがこのページの更新を覚えておく必要はありません。
Hugging Face のテスト対象がリポジトリと異なる点は 2 つあり、どちらもあいまいにせず実行とともに記録されます。GPU ワーカーが必要なため、試行あたりのコストが高く、その予算は別に決められます。また、モデルカードはアプリケーションではなくコードスニペットを説明していることが多いため、検証される振る舞いは「製品が動作する」ではなく「ドキュメントのスニペットが出力を生成した」です: 実行ページにはどちらなのかがその言葉で書かれ、スコアは同じ方法で与えられます。
表で「近日公開」ではなく「未開始」と書いているのは意図的です。あるソースが使用中と数えられるのは、その種類の実際の実行が証拠とともに記録された日からであり、1 日たりとも早まることはありません。 それまでは、その行は範囲の表明であって、結果の表明ではありません: まだ実行されていないソースについて、判定、件数、ランキング、シェアカードを表示するページはなく、予定中のソースの名前が出るのはこの表だけです。
7. 1 回の計測
- クリーンな使い捨てのマシン (その正確な環境は公開されています)。外部からの接続は受け付けず、実行が終わると破棄されます。この版では外向きのネットワークアクセスはフィルタリングしていません。実行を制限するのは、使い捨てのマシンと、この一覧の下にあるモデルキーのルールです。マシンは固定されたコミットのみを取得し、プロジェクトの履歴は取得しません。履歴はテストの一部ではないためです。
- エージェントは 1 つのミッションを受け取ります: 公開されている標準の指示のもとで、このプロジェクトを動かすことです。
- 時間制限。すべての実行には、ちょうど 3 種類ある予算 (一覧の下の表) のいずれかが与えられ、与えられた予算はその実行ページに表示されます。
- 独立した 3 回の実行。中央の結果を採用します。3 つの結果が 30% を超えて離れている場合、そのセットは不安定としてフラグが付き、そのサイクルのボードから除外されます。
- すべての実行は完全なログと完全なターミナル録画を保存し、結果とともに公開します。
- デスクトップアプリケーションは、マシン内の仮想ディスプレイ上で起動します (v1.1 から)。「起動した」とは、アプリケーションのメインプロセスがそのディスプレイ上で開始して動き続けたこと、またはバージョンやヘルプのコマンドに応答したことを意味します。何もクリックしません。計測するのは、そのソフトウェアが新しいマシンで立ち上がるかどうかであり、他のすべてのプロジェクトに問うのと同じ問いです。エージェントはモデルに画像を送らないよう指示されています (v1.3 から): 標準のモデルはテキストしか受け付けず、メッセージに添付されたスクリーンショットによって、レポートの前にセッションが終了したことがあったためです。
項目 3 の時間予算:
| 区分 | 予算 |
|---|---|
| standard | 90 分 |
| heavy | 120 分 |
| gpu | 120 分 |
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 点満点)
- インストールの成功: 30
- 起動またはテストの成功: 30
- エラーからの回復: 20。遭遇したエラーのうち正しく修正されたものの割合に比例
- 検証の深さ: 20 (実際に動作することを検証: 20、モックサービスに対して検証: 12、検証なし: 0)
実行の結果は次のいずれかです:
| 結果 | 意味 |
|---|---|
pass_full | 実行され、実際に検証された |
pass_mock | 実行され、モックサービスに対して検証された |
fail | インストールできなかった、または起動できなかった |
timeout | 時間切れになった |
4 つの採点項目だけでは、暗黙のままになるケースがあります。それらはコードの中だけでなく、ここで定めます。誰も読めないルールは、誰も検証できないルールだからです。採点は決定論的なプログラムで行われ、以下のすべてのルールをテストがカバーしています。採点のどの段階にも AI モデルは関与しません。
- 何も問題が起きなかった場合、エラーからの回復は満点の 20 です。0 点にすると、たまたまプロジェクトがすんなりインストールできたことでエージェントを罰することになり、それはエージェントではなくプロジェクトを計測していることになります。
- それ以外の場合、エラーからの回復は、遭遇したエラーのうち修正されたものの割合を 20 点満点で表したものです。実行が、遭遇したエラーより多くのエラーを修正したと主張することはできません。そのような実行は却下されます。
- 起動にはインストールが必要です: ソフトウェアをインストールしなかったエージェントが、それを起動できたはずはありません。
- 検証の深さには起動が必要です: 起動に成功していなければ検証するものがないため、深さは 0 点です。
- インストールと起動はできたが未検証の場合、合格ではありません。100 点中 80 点となりますが、失敗として数えます。問われているのはエージェントがソフトウェアの動作を検証したかどうかであり、未検証の起動はその問いに答えていないためです。
- タイムアウトはすべての項目が 0 点です。部分点ではありません: エージェントは、他のすべてのエージェントと同じ制限時間内に終えられなかったのです。
- 完全なログと録画のない実行は無効であり、再実行されます。採点されることも、ボードに載ることもありません。
9. 多数の実行から 1 つのボードスコアへ
採点は、プロジェクトとエージェントの 1 つの組を評価します。リーダーボードにはエージェントごとに 1 つの数値が必要で、それらをどう組み合わせるかは評価方法の選択なので、ここに明記します。
エージェントのボードスコアは、プロジェクトごとの中央値スコアの、さらに中央値です。平均ではなく再び中央値を使う理由は同じです: 1 つのひどいプロジェクトが有能なエージェントを引き下げるべきではなく、1 つの幸運なプロジェクトが弱いエージェントを押し上げるべきでもありません。
この数値から除外される結果は 2 種類あり、どちらもボードには表示されるので、除外は黙って行われるのではなく目に見えます: 不安定としてフラグが付いた結果 (次のセクションを参照) と、確認中としてフラグが付いたプロジェクトのすべての結果 (環境の品質管理を参照) です。
すべての結果が除外されたエージェントにはボードスコアがありません。削除するのではなく、スコアなしで最下部に表示します。テストされて使える結果を何も出せなかったエージェントは、それ自体が 1 つの結果であり、それを隠すと全体を不当によく見せることになるためです。
合格率は、そのサイクルでエージェントが行ったすべての試行を数えます。失敗とタイムアウトも含みます。後述の「独立性と結果の選り好みの禁止」を参照してください。
10. ばらつきと不安定性
ばらつきとは、3 回の実行の範囲を、その中央値に対する割合で表したものです:
spread = (highest - lowest) / middle * 100
ばらつきが 30% より厳密に大きい場合、そのセットは不安定としてフラグが付きます。ちょうど 30% は 30% 超ではないため、ボードに残ります。この式から 2 つの例外的なケースが導かれます:
- 中央値が 0 で、いずれかの実行が 0 より大きいスコアだった場合、ばらつきは上限がなく、そのセットは不安定です: 1 回だけ現れて他の 2 回は現れなかった結果は、最も再現性の低い結果だからです。
- 3 回の実行がすべて 0 点だった場合、式はゼロで割ることになり値を持たないため、このルールによりばらつきは 0 と定義され、そのセットは安定です。一貫した失敗は再現可能な計測であり、そのようなものとしてボードに載せるべきです。
11. プロジェクトの判定
ボードはエージェントをランク付けします。判定は、プロジェクトそのものについての別の問いに答えます: 新しく来た人が、AI エージェントという形で、今日このソフトウェアを動かせるでしょうか。
証拠が一方向にしか働かないため、テストは適応的に行います。1 回の合格はプロジェクトが動作することを証明します。1 回の失敗はそれだけでは何も証明しません。失敗の原因はプロジェクトではなくエージェントにあるかもしれないからです。
- まず、標準のエージェントが 1 回実行します。合格すればそこで終わりです: 完全な合格なら「動作する」、モックサービスに対する合格なら「モックで動作する」になります。動作することがすでに示されたものを、テストし続ける理由はありません。
- 失敗した場合、同じエージェントで 1 回再試行し、一度限りの偶然を排除します。
- それでも失敗した場合、判定は「壊れている」ではなく「検証できず」になります: Argusic はエージェントにできたことを報告し、まさにそのことを述べます (v1.3 から: 標準のエージェントで完全な試行が 2 回行われれば判定が確定します)。リクエストに応じて、より強力なエージェントを実行することがあります。その場合、その合格によってプロジェクトは「動作する」になり (記録には検証したエージェントが示されます)、その失敗もまた「検証できず」を確定させます。
完全な試行とは、エージェントが自身の終わりまで、または制限時間まで作業している様子が録画に示されている試行です。Argusic 自身のツールが途中で打ち切った試行 (エージェントのレポートを読めなかったハーネス、プロジェクトと無関係な計測機器のエラー) は、理由を実行に保存したうえで無効とされ、証拠とともに公開されたまま残り、数には入りません。
判定は、いずれかの試行が到達した最良の結果です:
- 動作する: いずれかの試行が実行され、実際に検証された。
- モックで動作する: 最良の試行が実行され、モックサービスに対して検証された。通常、プロジェクトが実際のサードパーティの認証情報を必要とするためです。
- 検証できず: 完全な試行 2 回の後 (または、より強力なエージェントを実行した場合はその後) も合格がない。ページにはそのことが書かれ、各試行がどこで止まったかを示すログにリンクしています。
- 未検証: テストがまだ終わっていない。
判定がどうであれ、すべての試行は完全な証拠とともに公開されます。例外は 1 つだけです: 有効な認証情報が含まれていないことを証明できない録画は公開を保留され、その実行は再実行されます (セクション 17「セキュリティのための秘匿」)。
12. Argusic が計測しないもの
誤読を防ぐため、はっきり述べます。Argusic は、エージェントが書くコードの長期的な品質、その修正のセキュリティ、機能レベルの深い製品体験を計測しません。計測するのはただ 1 つ、実際のソフトウェアを自律的に動かす能力です。
13. 独立性と結果の選り好みの禁止
- Argusic は、評価方法、採点、ランキングを変えるための金銭を一切受け取りません。
- 計算資源のスポンサーシップがある場合、それで得られるのはただ 1 つです: スポンサーのモデルが、他のすべてのエージェントと同一の条件でテスト対象の一覧に追加され、スポンサーシップは結果の隣に開示されます。
- すべてのエージェントのすべての実行が数えられ、公開されます。非公開でテストしてから最良の結果だけを公開することはありません。あるエージェントがボードに載っているなら、そのサイクルでのすべての試行が記録に残っています。
14. ハーネスの開示
ハーネス (モデルを取り巻く足場、ツール、指示、制限) は公開されており、1 つのサイクル内ではすべてのエージェントで同一です。スコアの違いは、仕組みではなくエージェントに帰せられるものでなければなりません。ハーネスの変更はサイクルの間にのみ行われ、変更履歴に記録されます。
15. 環境の品質管理
あるプロジェクトがすべてのエージェントで失敗した場合、自動的に確認中としてフラグが付き、人が確認するまで採点から除外されます: その失敗の原因は、エージェントではなく環境やプロジェクトにあるかもしれないからです。共通のセットアップの問題を、エージェントの失敗として採点することがあってはなりません。
16. 検証とはデコードすることであり、調べることではない
ファイルが存在することは結果ではなく、そのヘッダーを読むことはチェックではありません。ffprobe -show_streams、file、バイト数は、どれもコンテナを報告するだけで何もデコードしません: すべてのフレームが緑一色の動画も、正常な動画とまったく同じようにこの 3 つすべてを通過します。v1.4 から有効なルールは、エージェントは自分がデコードしたものを報告し、予想したものを報告してはならない、というものです。
- 生成したものをデコードする。 動画と音声には
ffmpeg -v error -i FILE -f null -、画像には実際のデコーダー、テキストなら出力して表示します。コマンドとその返した内容を報告します。 - 観察していないことを述べない。 モデルに与えたプロンプトは、何が出力されたかの証拠ではありません。README が約束していることは、それがここで起きた証拠ではありません。「81 フレームをエラーなしでデコードした」は発見です。「2 匹の猫の動画」はそうではありません。
- 最高の検証の深さを得られるのはデコードだけ。
test_depthは実行がどこまで到達したかを記録するフィールドです (セクション 8:tier1_realは「実際に動作することを検証」で 20 点、tier2_mockは「モックサービスに対して検証」で 12 点、tier3_noneは「検証なし」で 0 点)。tier1_realには、出力を説明できることではなく、デコードの成功が必要です。 verified_howが証明を運ぶ。 これは、エージェントが自身の出力を検証するために実行した正確なコマンドと、そのコマンドが返した内容を保持するレポートのフィールドです。"not verified" は受け入れられる、有用な回答です。final_stateは、何が起きたかについてのエージェント自身の締めくくりの文であり、実行ページとプロジェクトページにそのまま公開されます。そのため、そこに書かれる事実はすべて、エージェントが自分のコマンドで観察したものでなければなりません。
17. 証拠の完全性
2 つの層があり、決して混同しません。
証拠の層は未加工で永続的です: すべての実行は、実際のセッションの完全なターミナル録画を生成し、グラフィカルなアプリでは未加工のセッション動画も生成し、さらに完全なログを生成します。各ファイルは到着時にフィンガープリントが取られ、永久に保存されます。誰でも、編集されていないセッション全体を再生できます。
表示の層は派生物です: ソーシャル向けの動画や画像はすべて、証拠からレンダリングしたものです。許可される編集は、早送り、長さのためのトリミング、記録されたエラーと修正のタイムラインから作る字幕、ナレーションです。禁止される編集は、出来事の順序の入れ替え、別々のセッションのつなぎ合わせ、失敗の隠蔽、エージェントが行ったことの実質の改変です。公開されるすべての動画は、その証拠にリンクしています。
録画には、配信される前に 3 つの派生的な変換が適用されますが、どれもエージェントの作業の実質を変えるものではありません:
- セキュリティのための秘匿。 有効な認証情報の値は削除されます。信頼できないリポジトリが、エージェントをそそのかして環境変数を出力させることを止める手段はなく、そこにはエージェントが必要とする 1 つのキーが含まれているため、シークレットのような形の値はすべて、録画の保存または配信の前に消去されます。認証情報が含まれていないことを証明できない録画は公開を保留され、その実行は再実行されます。
- 生成された鍵素材。 鍵を生成することが機能そのものであるプロジェクト (パスワードマネージャー、PKI ツール) があり、エージェントがそれを実行して結果を出力することがあります。それは実際のテスト出力であり、Argusic の認証情報ではないため、実行の公開は保留されません: 録画とログの配信用コピーでは、そのような秘密鍵の本体がマスクされ、未加工のファイルは独自のフィンガープリントを実行に記録したうえでアーカイブされ、実行ページにはマスクが適用されたことが明記されます。マスクされたことを証明できない本体がある場合は、引き続き実行の公開を保留します (v1.2 から、Owner の決定 2026-09-05)。
- 中立的なエージェントの表示。 録画は Argusic Agent の名義で表示されます: 基盤となるツール自身の起動バナー (ベンダー、プロバイダー、モデルの名前が出るもの) は表示されません。整形されたビューが未加工のマシン出力を置き換えるのと同じです。これはエージェントが実行したコマンドや加えた変更を編集するものではなく、それらはすべて表示されます。また、ファイルパス、パッケージ名、リポジトリ自身のコードに自然に現れるベンダー名を検閲することもありません。それらは実際の作業の一部です。
引用されたテキストには、表示上の変換が 1 つ適用されます (Owner の決定 2026-09-04): ページがエージェント自身の最終状態の文 (「テストでわかったこと」) やリポジトリの GitHub の説明を表示するとき、作者が入力したダッシュは、サイトの句読点の方針に合わせてカンマまたはピリオドとして表示されます。保存されたレポート、リポジトリの記録、ログ、録画、録画からレンダリングされた画像はそのままです。言葉とその順序が変わることはありません。
常設のルール: すべての数値はログにたどり着き、すべてのフレームは実際のセッションの録画にたどり着きます。
18. 結果の再現方法
すべての結果のプロジェクト側は完全に公開されています: テストされた正確なコミット、公開されている環境、標準の指示、そして完全なログと録画です。各実行のページにはこれらがすべて掲載されています。エージェントは中立的な名義のもとで固定された Argusic の構成であり、Argusic がその正確なバージョンを保持し、結果を再現するために再実行できます。公開プロジェクトの一覧と非公開プールの開示は、最初のリーダーボードとともに公開されます。
19. 結果への異議申し立て
メンテナーや研究機関が結果を誤りだと考える場合、異議を申し立てることができます。実行のリンクを添えて [email protected] までご連絡ください。私たちは完全なログと録画を主張と照らし合わせて確認し、返信します。結果が私たちの側の環境やセットアップの問題の影響を受けていた場合は、再実行し、注記を付けて記録を訂正します。証拠が元の結果を支持している場合は、録画が何を示しているかを説明します。元の証拠が編集または削除されることはありません。
20. 変更履歴
各版には 2 つの日付があり、それぞれ別の問いに答えます。記載日は、そのルールがこの文書に記録された日です。適用開始日は、そのルールのもとで最初の実行が実際に計測された日で、このファイルではなく実行記録から読み取ります。通常は一致します。一致しない場合は実行記録が優先され、ここに記載されます。このページに届く前にマシンに届いていた版こそ、変更履歴が開示するために存在するものだからです。どの版も過去にさかのぼって適用されることはありません: 実行は、それが行われた日に有効だったルールを保持します。
v0.2 から v1.0 までの版はすべて 2026-08-31 に、最初の公開版を作成したコミットで記録されました。以下の日付は、最初の計測より前に、ルールそのものが決定された日です。
- v0.2 (2026-08-29): 採点基準が暗黙のままにしていたケース (エラーが 0 件の場合のエラーからの回復、インストールと起動の依存関係、タイムアウト、無効な実行) と、正確なばらつきの式とその 2 つの例外的なケースを明記しました。最初の計測の前に記載されたため、過去にさかのぼって適用されたものはありません。
- v0.3 (2026-08-30): プロジェクトごとの結果を 1 つのボードの数値にまとめる方法 (プロジェクトごとの中央値の中央値)、除外される結果、採点可能な結果が何もないエージェントは削除せずスコアなしで表示することを明記しました。
- v0.4 (2026-08-30): プロジェクトの判定を追加しました (適応的なテスト: 標準のエージェント、1 回の再試行、その後より強力なエージェント、最初の合格で終了)。ボードの採点は変わりません。
- v1.0 (適用開始 2026-08-31、記載 2026-08-31): 最初の公開版。v0.4 から変更されたルールはありません。この版では文書の構成を整理し、用語をわかりやすい言葉で定義し、再現と異議申し立てのセクションを追加しました。
- v1.1 (適用開始 2026-09-04、記載 2026-09-04): デスクトップアプリケーションをテストマシン内の仮想ディスプレイ上で起動するようにしました (セクション 7、項目 6)。これにより、グラフィカルなインターフェイスを持つプロジェクトを計測できます。マシンイメージには一般的なデスクトップランタイムとネイティブビルドツールも追加されました。イメージのダイジェストはすべての実行に記録されるため、前後の結果は区別できます。採点は変わりません。
- v1.2 (適用開始 2026-09-04、記載 2026-09-05): heavy の区分 (セクション 7、項目 3): 大きなプロジェクトには同じマシンクラスで 120 分が与えられます。これは Owner の指定または 500 MB のリポジトリサイズで決まり、予算は実行ページに表示されます。マシンは固定されたコミットのみを取得します。セクション 17 に、生成された鍵素材の変換が加わりました。採点は変わりません。この版は当初ここに 2026-09-05 から有効と記録されていましたが、実行記録によると 3 つの heavy プロジェクト (cataclysm-dda、veloren、supertux) が 2026-09-04 にすでに 120 分の予算で計測されていたため、上には早いほうの日付を記載しています。
- v1.3 (適用開始 2026-09-05、記載 2026-09-05): 判定は、標準のエージェントで完全な試行を 2 回行った後に確定します (セクション 11)。より強力なエージェントは、標準の手順の一部ではなくなりました。Argusic 自身のツールによって途中で打ち切られた試行は無効であり、数に入りません (2026-08-30 から 2026-09-05 までにそのような実行 92 件がそのようにマークされ、各実行に理由が記録されています)。標準の時間制限は 90 分 (セクション 7、項目 3)。モデルに画像を送らない (項目 6)。採点は変わりません。
- v1.4 (適用開始 2026-09-07、記載 2026-09-07): 検証とはデコードすることであり、調べることではない (セクション 16)。エージェントは生成したものをデコードし、使ったコマンドを報告しなければならず、観察していないことを述べてはならず、
tier1_realはデコードに成功した場合にのみ得られます。新しいレポートのフィールドverified_howがそのコマンドとその結果を運び、"not verified" は受け入れられる回答です。verified_howを含む最初の実行は 2026-09-07 に記録されました。採点は変わりません。この版は私たちからではなく、読者から生まれました。公開されたリール動画を見たある人が、有効な MP4 なのにフレームが壊れている失敗を確認したことがあるかと尋ね、セッションの cast を見ると、エージェントはまさにそれを検出できないヘッダーチェックを実行していました。報告された文の半分は検証可能 (コーデック、解像度、フレーム数、長さ、すべてヘッダーから読み取ったもの) で、半分はそうではありませんでした: 動画に何が映っているかの説明は、モデルカードのプロンプトを観察結果として言い直したものでした。その文は、リール動画、キャプション、プロジェクトページにそのまま公開されていました (ISSUE-056)。 - v1.5 (適用開始 2026-10-08、記載 2026-10-08): セクション 7 のテストマシンのネットワークとモデルキーの説明を、構築されたシステムと一致するように訂正し、時間予算の表を一覧の後ろに移すことでそのセクションの番号付けを修正しました (これにより、v1.1 と v1.3 の「セクション 7、項目 6」は再び項目 6 を指します)。この版より前、セクション 7 にはマシンが「制限されたネットワーク」を持つと書かれていましたが、マシンからの外向きの通信はフィルタリングされておらず、この版ではそのとおりに記載しています。また、実行ごとのモデルキー、その 3 USD の支出上限とその削除について明記しました。キャンセルされた実行と緊急停止でもキーが削除されるようになったこと (2026-10-08 より前はそうではありませんでした)、モデル提供元自身のサービスを使うエージェントは共有キーを使うことも含みます。これは説明の訂正であり、採点や計測のルールの変更ではありません: 以前の実行のラベルが付け直されることはなく、異なるルールのもとで計測されたものもなく、この版は過去にさかのぼって適用されません。採点は変わりません。
付録: ハードウェアの推定値、何が収まり、どれだけ速いか
以下の推定値は、Argusic が掲載しているプログラミング、AI、データサイエンス向けのノートパソコンとデスクトップの横に表示されます。
この付録は上記のベンチマークのルールの一部ではなく、どの版も変更しません: Argusic が販売中として掲載しているノートパソコンとデスクトップの横に表示する推定値について説明します。これらはメーカーが公開している数値に基づく計算であり、計測値ではありません。ここに示す数値は 1 つの共有ファイル (lib/hardware-estimates.ts) で計算されており、そのファイルとそのテストを同じコミットで変更しない限り、どの数値も変更できません。
Argusic のハードウェア一覧では、ノートパソコンとデスクトップごとに、保持できる最大のモデルサイズと、テキスト生成速度の上限を表示しています。どちらも推定値です: メーカーが公開している仕様から、以下の式で計算しています。Argusic はこれらのマシンでモデルを実行していません。Argusic が実際にマシンを計測した場合、その数値には計測値のラベルが付き、実行ログにリンクし、推定値と混同されることはありません。
推定値は、すべての入力がわかっている場合にのみ表示されます。メモリ容量、メモリの種類、チップの帯域幅のいずれかが不明な場合、ページには推測ではなく「不明」と表示されます。
入力とその出所
- モデル用メモリ: モデルが置かれるメモリです。ディスクリート GPU を持つマシンでは、GPU の VRAM です。Apple silicon、AMD Ryzen AI Max、NVIDIA GB10 では、CPU と GPU が共有するユニファイドメモリです。製品の掲載情報から読み取ります。
- メモリ帯域幅: チップまたは GPU のメーカー自身の仕様ページやデータシート (Apple、NVIDIA、AMD) から読み取り、チップごとに 1 行の参照があり、それぞれに出所のページへのリンクがあります。メーカーが帯域幅を公開していないチップは、ページに帯域幅が表示されません。Argusic はバス幅とメモリ速度から帯域幅を計算せず、サードパーティのデータベースからコピーすることもありません。
- モデルサイズ: パラメーター数で、フィルターの 5 つのサイズ区分です: 7-8B、14B、27-32B、70B、120B 以上。各区分はその最大サイズ (8B、14B、32B、70B、120B) で確認するため、収まるという判定は区分全体に当てはまります。
メモリ: どのモデルサイズが収まるか
モデルには 3 つのものを置く場所が必要です。
- 重み。 Argusic は llama.cpp の Q4_K_M 量子化を想定し、重みあたり 4.8944 ビットとします (llama.cpp quantize README):
- コンテキスト (KV キャッシュ)。 NVIDIA の式によります (Mastering LLM Techniques: Inference Optimization、NVIDIA Technical Blog、2023-11-17):
- ランタイムのオーバーヘッド。 Argusic は推論ランタイム自身のバッファ用に 1 GB を見込みます。
重みのバイト数 = パラメーター数 x 4.8944 / 8。 例 (計算値であり、計測値ではありません): 70B のモデルには 42.8 GB の重みが必要です。
トークンあたりの 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。
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-8B | 4.89 GB | 1.21 GB | 1 GB | 7.10 GB | 7.10 GB | 9.47 GB |
| 14B | 8.57 GB | 1.34 GB | 1 GB | 10.91 GB | 10.91 GB | 14.54 GB |
| 27-32B | 19.58 GB | 2.15 GB | 1 GB | 22.73 GB | 22.73 GB | 30.30 GB |
| 70B | 42.83 GB | 2.68 GB | 1 GB | 46.51 GB | 46.51 GB | 62.01 GB |
| 120B 以上 | 73.42 GB | 2.95 GB | 1 GB | 77.37 GB | 77.37 GB | 103.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 の価格で割ったもので、価格の日付も表示します。「この金額で最も大きなモデルを保持できるのはどれか」に答えるものです。品質や速度のランキングではなく、手数料によって変わることもありません。
これらの推定値ではないもの
- ベンチマークではありません。これらを得るために、掲載しているマシンでモデルを実行してはいません。
- バッテリー寿命、発熱、騒音、負荷時の持続性能は対象外です。
- 1 人のユーザー、1 つの会話、llama.cpp 方式の Q4_K_M の重みを想定しています。他のランタイム、他の量子化、より長いコンテキストでは答えが変わります。