「このモデルはエージェントに使える？」——この問いは、実は2つの別の問いが混ざっています。①モデルは原理的にこのタスクをこなせるか（賢さ）と、②そのモデルを“この機材で”実用的に動かせるか（速さ・メモリ）。当サイトはこの2つをL1／L2の2層に分けて測ります。混同すると「速いから良い」「賢いから使える」という誤った機材選びになるからです。この記事は、その測り方そのものを公開します。
結論（先に要点）
- L1＝能力天井: モデルが原理的にできるかを、最上位機（A6000）で機材に頭打ちさせず測る。→ スコアカード
- L2＝デバイス実行性: そのモデルを各機材で実用速度・メモリで動かせるかを測る。→ 検証DB・動くか診断
- 両方が同時に閾値を超える組み合わせだけが「推奨」。能力と実行性は別物で、片方だけ見ると失敗する。
2層で測る
測り方
- ・最上位機（A6000 48GB）で計測＝機材で頭打ちさせない
- ・単発ツール呼び出し／多ターン連鎖／過剰拒否
- ・最終状態で合否判定（軌跡でなく結果）
わかること / 行き先
- ・モデル間の能力の上限（機材非依存）
- ・→ エージェント実用度スコアカード
多くの比較が「能力」と「実行性」を混同して誤解を生む。L1で能力を確定→L2で機材適合を判定と分けるのが当サイトの計測方針。経験則（要検証）。
なぜ分けるのか。たとえば「Gemma4 26Bはエージェントに最強」（能力＝L1の話）は本当ですが、それを「Jetson 8GBで動かせる」（実行性＝L2の話）かはまったく別の問いです。L1とL2を混ぜて語ると、「最強モデル」を非力な機材に勧めてしまう。だから当サイトはまずL1で能力を確定し、次にL2で機材適合を判定します。
L1：能力天井（モデルは原理的にできるか）
L1はハードウェアの制約を取り払った、モデルそのものの上限を見る層です。
- 最上位機で測る: 計測は RTX A6000 48GB（このサイトを計測している運営者の実機）で行います。非力な機材だと「モデルが悪いのか、機材が足りないのか」が切り分けられません。機材で頭打ちさせないことがL1の条件です。
- 測る軸: 単発のツール呼び出し／多ターン連鎖（前の結果を次に使う本物のエージェント）／過剰拒否（正当な質問を断らないか）。これらはチャット能力とは別の軸です。
- 最終状態で判定する: 途中の言い回しや手順（軌跡）ではなく、最後にゴール状態へ到達したかで合否を採点します。「東京と大阪の気温をそれぞれ調べて足す」なら、最後の合算値が正しいかだけを見る。エージェント評価の研究でも、会話の最終的なデータベース状態を正解と比較する方式が標準です（根拠: τ-bench（Sierra/arXiv））。
L1の出力がエージェント実用度スコアカードです。
L2：デバイス実行性（この機材で実用的に動くか）
L1を通った（＝能力が足りる）モデルでも、手元の機材で実用速度・メモリに収まるかは別問題。これがL2です。
- 各機材で測る: Jetson Orin Nano／Raspberry Pi 5／Mac mini M4／RTX／A6000…と、実機ごとに計測します。
- 測る軸: 生成速度 tok/s・初動 TTFT・VRAM/RAMに載るか・消費電力。さらにエージェント特有の指標として、レイテンシ × ステップ数 ＝ 総実時間。1ステップが遅い機材は、連鎖が長いほど不利になります。
- 実用閾値で判定: 対話なら「黙読に追いつく」目安の約10 tok/s、エージェントなら総実時間で評価します。
統合：能力（L1）×実行性（L2）マトリクス
2層を掛け合わせると、機材選びはこの2×2に整理できます。
（載らない・遅い）
（載る・速い）
△ 能力は十分・機材が不足
例: Gemma4 26B を Jetson 8GB で → 載らない／激遅。量子化を上げるか上位機材へ。
◎ 推奨（両立）
例: Gemma4 26B を A6000／Qwen3.5 4B を Mac mini M4 で。能力も速度も実用域。
△ 速いが能力不足
例: Qwen3.5 2B を A6000 で → 速いが連鎖56%。単純タスク限定なら可。
「速い＝良い」でも「賢い＝使える」でもない。能力（L1）と実行性（L2）が同時に閾値を超える組み合わせを選ぶのが失敗しないコツ。
右上（両立）だけが「推奨」。残りは「能力は足りるが機材が非力（→量子化や上位機材）」「速いが能力不足（→単純タスク限定）」「どちらも不足（→不適）」と、打ち手が変わります。
なぜこの分離が効くのか（実例）
当サイトの実測には、L1／L2を分けたからこそ見えた発見があります。
- 「単発が得意＝エージェント向き」ではない（L1内部の発見）: 単発のツール呼び出しは7モデルが89〜100%でほぼ横並びでも、多ターン連鎖にすると56〜100%に開きました。単発100%のモデルが連鎖67%に急落します（実測）。だからL1は単発で止めず連鎖まで測ります。
- 「量子化で壊れる」は形式の話ではなかった（L1×実装の発見）: 同じモデルをfp16/Q8/Q4で測ると、壊れたJSON・ツール誤選択は全量子化で0件。落ちるのは僅かな判断だけでした。量子化はL2（速さ・メモリ）に効く一方、L1（構造化出力の“形”）はQ4でも保たれる、と切り分けられます。
- 電力効率の逆転（L2内部の発見）: 絶対消費電力が最小のRaspberry Pi 5が、効率（tok/s/W）では最下位——という逆転も、L2を機材横断で測ったから見えました（実測）。
- 「ツールを使わざるを得ないタスク」で測る（測定設計の教訓）: L1で5段の純粋算術チェーンを試したところ、強いGemma4 26Bはツールを使わず暗算で正答しました（ツール0回で「答えは210」）。算術はメンタルで解けるため、ツール連鎖の測定にならない。最終状態で判定するなら、ツールを使わないと解けないタスク（気温取得・検索・メール送信など）でなければエージェント能力は測れない——この気づき自体が、軌跡でなく最終状態で測るべき理由でもあります。
限界と今後（正直に）
- 連鎖は2〜3段・小サンプル（連鎖9試行・単発18〜48試行）。現実のエージェントはより深い連鎖・多引数・ネストしたツールでさらに難しく、追検証が要ります（より長い連鎖・MCP実タスクでの最終状態検証は今後の課題）。
- L2の電力は測定境界が機種で異なる（Mac=SoC全体／A6000=GPUのみ等）ため、横断比較は目安です。
- 閾値・重み付けは経験則（要検証）。用途により実用ラインは変わります。
「速いローカルAI」でも「賢いローカルAI」でもなく、あなたの用途で“能力も実行性も足りる”組み合わせを選ぶ——そのための測り方が、このL1／L2プロトコルです。総合の結論はエージェント実用度スコアカード（L1）と動くか診断（L2）にまとまっています。