【2026年版】AIモデルの選び方が変わった 〜効率・ベンチマーク・キャッシュ・メモリの今〜

はじめに

このブログの第一弾は、昨年12月のAI用語整理ガイドでした。 あの頃は「モデルって何？」「セッションって？」から始めていました。

社内の勉強会が始まって約1年。メンバーはClaude CodeやCodexを毎日使うようになりました。 その一方で、この9か月でモデルの世代が3〜4回入れ替わり、選び方の常識もだいぶ変わっています。

この記事では、2026年9月時点で「これは知っておいたほうがいい」と思う話を、基礎から順に並べます。 数字は調べた時点のもので、来月には動いている前提で読んでください。

1. モデルは「効率」で別物になる

いまのモデルには、どれだけ考え込むかを指定する 効率（effort） という設定があります。 Claude系は low / medium / high / xhigh / max の5段階、GPT-5.6系も同じ5段階に none を足した6段階です¹²。

同じモデルでも、効率を変えると賢さ・コスト・速さが変わります。 コーディングベンチマークのDeepSWEで見てみます。 DeepSWEは、91のリポジトリから作った113本の長丁場の実装タスクを解かせ、正解率（1回の試行でテストが通った割合）を測ります³。 一言でいえば「動くコードを書けるか」です。 下の図は、ここから主要6モデルの効率別（30構成）を取り出し、横軸に1タスクあたりのコスト、縦軸に正解率で並べたものです³。 Fable 5とSonnet 5の max は横に飛び出すので、点を置かず数値だけ注記しています。 同じ色の点が、同じモデルの効率違いです。

見どころは、赤い帯に並んだ4点です³。

正解率だけ見れば、4つは誤差の範囲で同じです。 ところがコストは12倍の幅があり、ステップ数（AIが道具を使った回数。時間の目安）も2倍違います。 Lunaは安いけれど、たくさん試行して時間をかけて同じ点に着いている。 Fableは少ない手数で着くけれど高い。 そして緑のAstraは、low でも67%と帯の上にいて、max まで6ポイントしか動きません。 ピンクのSonnet 5は、max で$26.40かけても54%で、帯に届きません。

図の上部、点線の枠の中では、30構成のうち19が60〜74%の14ポイント幅に収まり、その中でコストは$0.61から$21.63まで35倍の開きがあります³。 正解率は頭打ちに近づいていて、差はコストと時間のほうに出ています。

上位5構成を抜き出すと、こうです³。

同じ74%でも、AstraとOpus 5ではコストが2倍近く違います。 Astraは medium でも73%で、Opus 5の max の4割弱のコストです。

1. モデル名だけで比べても意味がない。 「Opus 5とSol、どっちが賢い？」は「どの効率で？」を付けないと答えが出ない。Opus 5の low とFable 5の low は、Solの medium と同じ位置にいる
2. 同じ点数でも、同じではない。 DeepSWEでは、60%以上の帯に入ると点数は14ポイント幅に収まり、コストと時間の差が残る。速さの観点を入れないと、現場での使い勝手は比べられない

2. ベンチマークは1つの数字で見ない

「モデルの力を測る」と言っても、何を測るかはベンチマークごとに違います。 代表的な5つを並べます。 DeepSWEは第1章で見たので、残り4つを順に見ます。

2-1. FrontierCode: マージしたくなるコードか

Cognition（Devinの会社）が2026年6月に出したFrontierCodeは、視点が違います⁴。 テストが通るかだけでなく、テストの質・変更範囲の節度・コードベースの流儀に沿っているかを、リポジトリのメンテナ自身が作った基準で採点します。 「マージ可能性」を測るベンチマークです。

各モデルを全効率で5回ずつ走らせているので、効率ごとの点も見られます⁴。 リーダーボードから5モデルを取り出し、横軸にコストを置いたのが図2です⁵。

見どころはOpus 5です。 medium の53.4%が最高で、high 48.0%、xhigh 43.6%、max 48.0%と、high 以上はいずれも medium より低い⁵。 ほかのモデルは上がるか、ほぼ平らです。 同じ53%台に、Astraは max で$4.49、Opus 5は medium で$4.31と、ほぼ同じコストで着いています。 Sonnet 5は max で$17.12かけても42.4%。 Lunaの max は$0.36で39.8%なので、50倍近いコストで3ポイントしか上にいません。

FrontierCodeの採点には「範囲の節度」の基準があります。 Cognitionはこう書いています。 「良いPRは抑制が効いている。必要なところだけを変え、無関係なファイルに触れず、不要なリファクタリングを持ち込まない」⁴。 効率を上げるほど、モデルは頼まれていない改善にも手を伸ばしやすくなる。 それがこの基準で減点される、と考えると辻褄が合います。 ただしこれは採点方式からの推論で、Cognitionが効率との関係を明言しているわけではありません。

Opus 5で「頼んだこと以外はやらないで」と感じることが増えたら、medium を試す価値があります。 なお、Fable 5.1の最高は50.9%で、Fable 5の53.5%より低い。新しいほど高いとも限りません⁵。

DeepSWEで70%台のモデルが、ここでは50%台。測り方でこれだけ変わります。

2-2. VulcanBench: どれだけの手間で解けるか

VulcanBenchはオープンソースのベンチマークで、正解率に加えて 1タスクの所要時間・コスト・トークン数 を記録します⁶。 ここに、第1章で言った「同じ点数でも同じではない」の証拠があります。

Opus 5を効率だけ変えて同じ23タスクを解かせた結果です（2026年7月）⁷。 前提として、VulcanBenchには1タスクの制限時間があり、時間切れは不正解に数えます。 high は考え込みすぎて、4タスクが時間切れになりました⁷。

間違えた数だけ見れば high が最も少なく、時間切れを含めた結果では low が勝ちました。 レポートの結論は「lowはhighより悪くならず、コストは3分の1」です⁷。 時間を測らないと、この差は見えません。

ここまでのベンチマークは、測定側が用意した共通の実行環境でモデルだけを動かしています。 この実行環境を ハーネス と呼びます。 モデルにファイル操作やコマンド実行の手足を付け、段取りを組む側の道具です。 これを各社公式のハーネスに替えた比較もあります。 同じ41タスクを、Claude Code上のOpus 5と、Codex上のGPT-5.6 Solで解かせた結果です⁸。

点数はOpus 5が約10ポイント上、時間とお金はCodex側が軽い。 Claude Code側は1タスクで16〜38回ツールを呼び、Codex側は1〜3回。 これは「Opus 5とSol」の差ではなく「Claude CodeとCodex」の段取りの差を含んだ数字で、レポート自身も「モデルの差であると同時にハーネスの差」と書いています⁸。 ベンチマークを1つの数字で見てはいけないのは、ここです。

2-3. AA-Omniscience: 知らないと言えるか

ハルシネーション（もっともらしい嘘）も測られています。 Artificial AnalysisのAA-Omniscienceは、正解に加点、誤答に減点、「わからない」は減点なし、という採点です⁹。 つまり 知らないことを知らないと言えるモデル が高得点になります。

この指標の「ハルシネーション率」は少し読み方に注意が要ります。 全体のうち嘘をついた割合ではなく、正解できなかった問題のうち、黙らずに答えてしまった割合 です⁹。 主なモデルで並べます（Lunaは一次情報で値を確認できず、載せていません）。

Fable 5.1は正答率が最も高い一方で、質問の93.4%に答えます（Opus 5は87.8%）¹¹。 知っていることが多いぶん、知らないときも黙らない。 Astraは逆で、Solの92%から51%へ半減させ、正答率も落としていません¹³。 Opus 5はOpus 4.8より正答率を7ポイント上げましたが、ハルシネーション率も14ポイント上がって50%です¹⁴。 賢くなると自信も増える、というのはモデルにもあるようです。

コードを書かせるときは、テストが嘘を暴いてくれます。 調べ物をさせるときは、この指標を頭の片隅に置いて「出典は？」と聞く癖をつけるのが現実的な対策です。

2-4. ARC-AGI-3とAstraの「99.9%」

GPT-6 Astraが、ARC-AGI-3で99.9%を取ったと話題になりました¹⁵。 ARC-AGI-3は初見のパズルを解く、汎用的な推論力のベンチマークです。

ただし、この99.9%には条件があります。

標準ハーネスだと62.7%。 推論の途中状態をリクエスト間で持ち越し、長い会話は圧縮する「Provider Adapter」ハーネスだと99.9%です¹⁵。 ARC Prizeは両方を条件のラベル付きで併記しています¹⁵。

「推論の途中状態」は、答えを出す前に考えている中身（thinking）です。 標準ハーネスでは持ち越されず、モデルが文章に書き残したメモだけが次へ渡ります¹⁵。 Provider Adapterはこの思考を次へ持ち越すので、前の考えを再利用でき、時間もトークンも減ります¹⁵。 第4章の自動メモリとは別物で、Claude Codeならセッションをクリアせず続けている状態に近いです¹⁶。

他モデルと比べるなら、同じ条件で測った62.7%を使うのが筋です。 Claude系の最高はOpus 5（high）の30.2%です¹⁷。

※ Fable 5とFable 5.1は、ARC Prizeが「測定中」としていて、まだ値がありません¹⁸。

「Opus 5も100%を取った」という話もあります。 NVIDIAが自社のエージェント基盤AVOでOpus 5を動かし、公開セット（問題が公開されている側）の183レベルを全部解いた結果です¹⁹。 Provider Adapterよりさらに手厚いハーネスで、問題もARC Prizeの計測とは別です。 NVIDIA自身も、モデル単体ではなくシステム全体の結果だと書いています¹⁹。

同じモデルでも、ハーネスで数十ポイント動く。 ベンチマークの数字を見るときは「どのハーネスで？」も一緒に見る必要があります。

3. 道具のつなぎ方: MCPからCLIへ、いまはハイブリッド

前回の記事では、MCPを「AIエージェントの拡張スロット」と紹介しました。 Salesforce MCPで組織のメタデータを引く、Context7 MCPで最新ドキュメントを引く、という使い方です。 ただ、つなぎ方の第一候補は、この9か月で入れ替わりました。

3-1. おさらい: MCPは何をしていたか

MCPサーバーは、AIに「使えるツールの一覧」を渡します。 一覧には、ツールの名前、何をするかの説明、引数の型が入っています。 AIはその一覧を読んで必要なツールを呼び、結果を受け取ります。

問題は、この一覧が 起動時にまとめてコンテキストへ載る ことでした。 使うかどうかに関係なく、つないだサーバーの全ツールぶんです。

3-2. 前回の記事の頃: つないだだけで満杯

前回の記事の頃、Claudeのコンテキストは200Kトークンが上限でした。 Anthropicが1Mを標準価格で一般提供したのは2026年3月です²⁰。

Anthropic自身が2025年11月に書いています。 「数千のツールにつながったエージェントは、依頼を読む前に数十万トークンを処理することになる」²¹。 同じ記事で、ツールを直接呼ぶと15万トークンかかった作業が、必要な定義だけをコードから読む形（MCPをコードから呼ぶ提案）にすると2,000トークンで済んだ例を出しています。

Codexにも2026年1月に「MCPツールがコンテキストを食いすぎる。遅延ロードと検索が欲しい」というissueが立ちました²²。 Claude Codeは同じ月のv2.1.7で ツール検索 を既定にしました²³。 MCPのツール定義がコンテキストの10%を超えると定義は後回しにされ、必要になったときに検索して数個だけ読み込む形です。

3-3. 「CLIでよくない？」

そこで出てきたのが「MCPを挟まず、コマンドを直接叩けばいい」という話です。 gh や git、Salesforceの sf コマンドなら、モデルはもう使い方を知っています。 定義をコンテキストに載せる必要がありません。 振る舞いの説明は スキル に置けば足ります。 スキルは起動時に名前と説明だけが載り、本文は使うときに読まれます²⁴。 Codexも同じ仕組みで、起動時のスキル一覧はコンテキストの2%以内に収める設計です²⁵。

いい例がMicrosoftのPlaywrightです。 Playwright MCPを出していた同じチームが、2026年1月にPlaywright CLIを出しました²⁶。 MCP側のREADMEにはこう書いてあります。 「コーディングエージェントは、MCPよりもスキルとして公開したCLIベースのワークフローを好むようになっている。CLI呼び出しのほうがトークン効率がよく、大きなツールスキーマや冗長なアクセシビリティツリーをモデルのコンテキストに載せずに済むからだ」²⁷。 MCPだと画面のアクセシビリティツリーがそのままコンテキストへ流れ込みます。 Playwright CLIは結果をファイルに保存し、ハーネスが必要なぶんだけ読みます。

結果をファイルに置くのはPlaywright CLIの設計で、CLI一般の性質ではありません（gh pr view の出力はそのまま入ります）。 ただ、ファイルに残せば「どこを読むか」をハーネスが選べる、という道が開きます。 Playwrightチームの計測を引いた記事では、同じブラウザ操作でMCP約11.4万トークン、CLI約2.7万トークンと、約4分の1でした²⁸。 playwright-cli install --skills でスキルとして入れる形になっていて、「CLI + スキル」の型そのものです。

3-4. いま: CLIが第一候補、統制が要るところはMCP

MCPが終わったわけではなく、役割が絞られました。

MCPが強いのは 認証・認可・監査 です。 CLIでは認証は各メンバーが自分のPCで個別に行い、「誰がどこへつなげるか」を一か所で決める場所がありません。 リモートのMCPサーバーなら、2026年6月に追加された Enterprise-Managed Authorization で、社内のIdP（Okta等）がその決定を持ち、監査ログも一本にできます²⁹。 2026年7月の仕様改定の告知では、Tier 1 SDKのダウンロードが月5億近い、と書かれています³⁰。 使われなくなったわけではありません。

PlaywrightのREADMEも「MCPは、状態を持ち続けて反復する専用のエージェントループでは今も有効」と続けています²⁷。 2026年7月のPlaywright 1.62では、MCPサーバーとCLIの両方を本体に同梱しました³¹。 どちらかに寄せるのではなく、用途で使い分ける形に落ち着いています。 認証と状態、2つの軸で整理すると次の図になります。

社内の例で言えば、Salesforceの操作は sf コマンドをスキルで包むのが第一候補です。 今入れているSalesforce MCPやContext7 MCPを外す必要はありません。 ツール検索が効くので、載る量は前より減っています。 「誰がつなげるか」をIdPで一括管理したい社内SaaSが出てきたら、そのときにリモートMCPの統制を検討する。 この順番でいいと思います。

4. 日々の使い方で差がつくところ

4-1. キャッシュのTTL: 途切れずに続けるほうが得

Claude Codeは、毎回のやり取りで会話の全履歴をAPIに送り直しています。 モデルは前のリクエストを覚えていないからです。 そのままだと毎回フル処理なので、前回と同じ部分（プレフィックス）を プロンプトキャッシュ で使い回します³²。 キャッシュから読んだ分は、通常の入力料金の約10%です（Fable 5.1だけは2.5%）³²³³。

このキャッシュには寿命（TTL）があります。 5分と1時間の2種類 で、どちらになるかは課金の種類で決まります³²。

ポイントは、キャッシュにヒットするたびに寿命が延びる ことです³²。 作業を続けている限り切れません。

「得」の中身は、課金の種類で違います。

差の大きさを、APIキー課金で絵にします。 履歴が20万トークンたまった状態で、Fable 5.1に1ターン投げるときの入力コストです³³。

TTLを過ぎてから再開するたびに、続けて使う50ターン分が1ターンで飛びます。

効率を途中で変えると、キャッシュが消える

セッションの途中で効率（effort）を変える と、キャッシュは消えます。 効率ごとに別のキャッシュを持つので、切り替えた直後のリクエストは全履歴を読み直します³²。 モデルの切り替え（/model）も同じです³²。 加えて、それまでの思考（thinking）は生成したモデルか、それより新しいモデルしか読めません。 Fable 5.1からOpus 5へ下げると、会話の途中で考えた中身は捨てられます¹⁶。

Claude Codeは、キャッシュがまだ温かいうちに効率やモデルを変えようとすると「本当に変えますか」と確認を出します³²。 公式ドキュメントの助言はシンプルで、モデルと効率はセッションの最初に決めて、/compact はタスクの区切りで打つ、です³²。

例外として、Fable 5.1をAPIキーまたはサブスクで使う場合は、Claude Code v2.1.260以降、効率を変えてもキャッシュが保たれます³²。

4-2. 会話が長くなるほど、精度が落ちる

最近の主流モデルは100万トークンの窓を持ちます。 Claude Codeの自動圧縮（compact）は、既定ではその上限に達してから走ります³⁵。 つまり、放っておけば上限近くまで会話が伸びます。

問題は、長いほど精度が落ちることです。 MRCR v2 というベンチマークがこれを測っています。 長い文章の中に8つの事実を埋め、モデルがそれを全部拾えるかを、文脈の長さ別に見るものです。

落ち方はモデルで大きく違います³⁶。 Astraはほぼ落ちませんが、Solは18ポイント落ちます。 なお、Claude系はこのベンチマークの値が公開されておらず、比べられませんでした。 長いコンテキストで精度が下がる現象（Context Rot）自体は、主要モデルに共通して観測されています³⁷。 別のベンチマーク（NVIDIA RULER）は、ほとんどのモデルが公称の長さに届く前に合格ラインを割る、と報告しています³⁸。 128Kを掲げる21モデルのうち17が届かず、実際に使えていたのは64Kや32Kまででした。

上限まで使い切るのは、コスト以前に精度で損です。 しかも「ここまでは無傷、ここから急降下」ではなく、じわじわ落ちます。 自動圧縮が走るのを待つのではなく、自分で区切るほうが確かです。

どこで区切るか。 ここからは計測値ではなく、手元で使っていての体感です。 使用率が50%を超えたあたりから、精度も動作の速さも曲がり始めます。 ひと仕事は、50%に届く前に閉じます。 次のセッションは30%以内から始めると、いちばん快適です。

1. 引き継ぎ資料を書いて、新しいセッションで始める。 決まったこと・次にやることをファイルに書き出し、セッションを閉じる。次はそのファイルだけを読ませる。文脈がいちばん短い状態から再開できる
2. 区切りで自分で /compact を打つ。 資料を作るほどでもないときに。上限まで引っ張るより、タスクが1つ終わった時点で打つ

4-1と逆のことを言っているようですが、軸が違います。 空けないほうがいいのは 時間の間隔、伸ばさないほうがいいのは 会話の長さ です。 区切り直せば4-1のキャッシュは捨てることになりますが、精度が落ちたまま進むほうが高くつきます。

/rewind が意外な穴です。 圧縮は新しい要約を作るので次のターンが高くつきますが、巻き戻しはキャッシュ済みの地点に戻るだけなので安く済みます³²。

4-3. 自動メモリ: 放っておくと古くなる

前回の記事では「セッションが終わるとAIは白紙から始まる」と書きました。 この前提が、いまは変わっています。 AIが自分でメモを取り、次のセッションで読み返す 仕組みが加わったからです。

出典はそれぞれの公式ドキュメントです³⁹⁴⁰。

便利な半面、メモリには 古くなる という宿命があります。 「このプロジェクトはReact 18」と3か月前に覚えたメモリは、19に上げた後も残ります。 AIはそれを「今の事実」として読み、判断を誤ります。

1. 月に1回 /memory を開いて読む。 古い行は消す、間違いは直す
2. チームで共有すべき決まりはメモリに頼らない。 AGENTS.md やリポジトリの文書に書く。Codexの公式ドキュメントも「必ず守るルールはメモリではなくリポジトリの文書に」と念を押しています⁴⁰
3. メモリは機械ローカルだと覚えておく。 別のPCや同僚の環境には引き継がれない

5. 所感: 差が分からないほど、平均が上がった

最後に、数字ではなく手元の感触を書きます。

FableやAstraのような最上位モデルが出ても、手元のシステム開発では「すごさの差」が分からなくなってきました。 DeepSWEの効率別の数字を見ると、Fable 5の low が60%、Opus 5の low が58%、Astraの low が67%、Solは medium で61%です³。 Astraは low から max まで6ポイントしか動きません。 DeepSWEの図1で、60%以上の点が団子になっていたのも同じことです。 最上位を全力で使わなくても、上位モデルを軽く使えば、日々の実装は十分回ります。

上位モデルを低い効率で使う のが、点数・時間・コストのバランスがよい選択になりやすいです。 VulcanBenchのOpus 5は、時間切れ込みで low が最も正解率が高く、最も速く、最も安いという結果でした⁷。 「安いモデルを頑張らせる」より「良いモデルを軽く使う」ほうが、結果として安く済むことがあります。

まとめ

9か月で、AIは「賢いかどうか」から「どう使うと安くて速くて確かか」の話に移りました。 来年の記事では、また半分くらい書き換えることになると思います。

参考文献