SubQ 1M-Previewとは？仕組み・性能・料金を徹底解説

マイアミ拠点のAIスタートアップSubquadraticは、2026年5月5日に「SubQ 1M-Preview」を発表しました。フロンティアスケールで初めて、計算量がコンテキスト長に対して線形にしか増えない「完全サブクワドラティック」アーキテクチャを採用したと主張する大規模言語モデルです。

独自アーキテクチャ「SSA（Subquadratic Sparse Attention）」によって、研究モデルでは最大1,200万トークンまでの動作を確認し、RULER 128KではClaude Opus 4.6を上回る95.0%を記録しました。Subquadratic自身は「Transformerの二次計算量こそAI応用の最大の経済制約であり、それが外れた今、これまで成立しなかったワークロードが商用規模で動き始める」と位置づけています。

本記事では、フロンティアスケールでサブクワドラティックが解けてこなかった理由から、SSAの仕組み・ベンチマーク・解放されるユースケース・推論経済学への影響・3つのプロダクト構成・主要フロンティアモデルとの比較・現時点の制約と料金までを、公式発表と一次・二次ソースをもとに整理します。

SubQ 1M-Previewとは？

SubQ 1M-Previewは、マイアミ拠点のAIスタートアップSubquadraticが発表した、フロンティアスケール初の「完全サブクワドラティック」アーキテクチャを採用した大規模言語モデル（LLM）です。
コンテキスト長に対する計算量を線形オーダーまで落とすことで、これまで二次計算量に阻まれていた長文ワークロードの経済性を一気に書き換えることを目的としています。

Subquadratic公式は、SubQの位置づけを「効率化アーキテクチャの改良」ではなく「Transformerの二次計算量という根本制約への正面回答」だと整理しています。同社は、コストが推論ワークロードの主要な制約になりつつある現状を指摘し、SubQによってその制約が外れた領域で「これまで成立しなかった応用が商用規模で動き始める」と主張します。

発表の概要

2026年5月5日のステルス解除と同時に、Subquadraticは次の3つを公表しました。

• SubQ 1M-Preview 本番モデル。公式announcement上は「SubQ 1M-Preview」として1Mトークンを強調する一方、公式トップページのAPI項目には「12M token context window」とも掲示されており、API実提供上限は申請時の最終確認が必要
  
  
• 研究モデル 内部では12Mトークンまでの動作を確認済み
  
  
• 3つのプロダクト SubQ API／SubQ Code／SubQ Searchを同時にローンチ（非公開ベータ）
  
  

本番モデル名に「1M-Preview」とプレビュー扱いを明示している点は重要です。SLAや継続提供のコミットは、Anthropicの「Opus 4.6」のようなGAモデルと同列に扱うべきではなく、ベータ段階のリスクを織り込んだ評価が前提になります。

Subquadratic（運営企業）の概要

Subquadraticは、長文コンテキストの計算量問題を「効率化の継ぎ足し」ではなく「アーキテクチャの再設計」で解こうとしている研究主導型のスタートアップです。シードラウンドで2,900万ドル（想定バリュエーション約5億ドル）を調達し、フロンティアモデルを学習させるためのインフラと資金を確保しています。

創業者のJustin Dangel氏は、ヘルスケア・保険・消費財領域でCEOを5度経験した連続起業家。CTOのAlex Whedon氏は元Meta、生成AIスタートアップTribeAIで生成AI部門を率い、企業向けAI実装を40件以上手掛けた経歴を持ちます。研究チームはMeta・Google・Oxford・Cambridge・ByteDance・Adobe・Microsoftから集まった博士研究員11名で、人員規模は競合フロンティアラボより小さい一方、専門性の密度では引けを取らない構成です（VentureBeat・The New Stackの発表当日報道に詳細）。

【関連記事】
大規模言語モデル(LLM)とは？その仕組みやAIとの違い、活用例を解説

---

長文LLMがフロンティアスケールで解けてこなかった理由

SubQの立ち位置を理解するには、まず「なぜ既存のサブクワドラティック研究はフロンティアスケールで成立しなかったのか」を押さえる必要があります。Subquadratic公式は、ここを記事冒頭のメッセージとして強調しています。

二次計算量という根本制約

標準的なTransformerの自己注意は、シーケンス長nに対して計算量・メモリ消費ともにO(n²)で増加します。
コンテキスト長を128K→1Mに伸ばせば計算量は約60倍、1M→12Mで約144倍、128K→12Mまで広げれば約9,000倍に膨らみ、長文ワークロードでコストとレイテンシが現実的に持たない、というのが既存アーキテクチャの構造的な限界でした。

既存アプローチの壁

過去5年でMamba・RWKV・Linear Attention・State Space Modelなどの劣二次アーキテクチャが多数提案されてきました。いずれも線形に近いスケーリングを実現する一方で、フロンティアレベルの性能を維持できないという共通課題を抱えていました。代表的なアプローチと制約を並べると次のようになります。

アプローチ	利点	制限
固定パターン疎注意（Sliding Window等）	計算量を削減できる	位置ベースで固定。重要情報がパターン外にあると拾えない
状態空間モデル（Mamba・RWKV等）	線形スケーリング	固定サイズの状態に圧縮するため、長文中の事実検索精度が落ちやすい
ハイブリッド（密＋線形）	性能と効率の折衷	密注意層が支配的になり、長文で計算コストが下がりにくい
DeepSeek系の疎注意	インデックス併用で密注意より軽い	全体としてはO(n²)スケーリングが残る

この表が示しているのは、効率と精度の二律背反です。Subquadratic公式は「サブクワドラティック化の概念自体は既知。未解決だったのはフロンティア性能を維持しながら実装すること」と整理しており、これまで提案されてきたアーキテクチャは「短文では密注意と互角→長文・難易度の高いベンチで失速する」という壁を共通して抱えていました。

Subquadraticのアプローチ

Subquadraticは、効率化レイヤーを後付けするのではなく、初期計画段階からフロンティアスケール前提で「線形スケーリング」「コンテンツ依存ルーティング」「任意位置からの精密取得」の3要件を同時に満たすアーキテクチャを設計したと主張しています。後述するSSAは、この3要件を1つの注意機構に統合した実装です。

言い換えると、SubQの新規性は個々のアイデアそのものではなく、「これまで個別に追求されてきた性質を、フロンティアスケールで両立させた最初の実証主張」という点にあります。再現性と独立検証は今後のピアレビュー次第ですが、業界が長らく解けずにいたボトルネックを正面から突いた発表という意味合いが大きい一件です。

【関連記事】
コンテキストエンジニアリングとは？AIの精度を最大化する次世代技術を解説

---

SubQが採用したSSA（Subquadratic Sparse Attention）の仕組み

SubQの中核技術が「SSA（Subquadratic Sparse Attention）」です。SSAは、各クエリについて「シーケンスのどこを見るか」をモデル自身に意味的に選ばせ、選ばれた位置に対してのみ密注意と同じ精度で計算する設計を取ります。

SSAの3つの特性

SSAは、これまで個別にしか実現できていなかった3つの性質を1つのアーキテクチャに同居させた点が要点です。

• 線形スケーリング 計算量とメモリは「選ばれた位置の数」に比例する。選択数を一定に保てば、シーケンス長が伸びても計算は線形にしか増えない
  
  
• コンテンツ依存ルーティング どの位置を選ぶかは固定パターンではなく、クエリと候補トークンの意味的な関連で決まる。Sliding Windowのような位置依存の疎注意とは根本的に異なる
  
  
• 任意位置からの精密取得 選ばれた位置に対しては密注意と同じ精度で値を取り出す。状態圧縮型のSSMが苦手としていた「ピンポイント検索」に強い
  
  

結果として、文章の冒頭にある定義や、コードベースの離れたファイルにある関数定義のような「遠くにある重要情報」を、12Mトークン規模でも追跡できるとSubquadratic側は主張しています。

SSAの効率指標

公式の技術解説ページでは、密注意（FlashAttention-2想定）との比較で、コンテキスト長ごとの注意計算FLOP削減・スピードアップが提示されています。

コンテキスト長	注意FLOP削減	スピードアップ（B200想定）
128Kトークン	約8倍	約7.2倍
256Kトークン	—	約13.2倍
512Kトークン	—	約23.0倍
1Mトークン	約62.5倍	約52.2倍
12Mトークン	約1,000倍	—

マーケティング上の見出しになっている「1,000倍削減」は12Mトークン時の比較です。実用域として多い128K〜1Mの帯域では「8倍〜62.5倍」のオーダーであり、ワークロードごとに効果は変わる前提で読み取る必要があります。
逆にいえば、密注意でも処理できる中短文タスクではSSAの優位性は薄く、長文域に近づくほど経済的・性能的なギャップが開く構造です。

SSAの優位性が崩れる条件

SSAは万能ではなく、「コンテンツ依存の選択メカニズム」が外れる条件下では密注意と互角以上を出すのが難しい設計です。具体的には、参照対象が極めて多くて選択肢自体が選び切れないケースや、選択ロジックの学習データが薄いドメインでは、選ばれる位置の精度が落ちて性能が劣化しうる可能性があります。後段のMRCR v2のスコアは、この弱点が顕在化しやすい指標として読み取れます。

---

SubQ 1M-Previewのベンチマーク性能

ここではSubQ 1M-Previewの公開ベンチマーク結果を、競合フロンティアモデルとあわせて整理します。Subquadratic自身が公開している数値と、その自己評価のトーンも併せて押さえておくと、読み解きが正確になります。

RULER 128K：「frontier-level accuracy」を強調する領域

RULERは、長文中の事実検索や多段推論を測るNVIDIA公開のベンチマークです。SubQはこのうち128Kトークン設定で次の結果を報告しています。

モデル	RULER 128K スコア
SubQ 1M-Preview	95.0%
Claude Opus 4.6	94.8%

差は0.2ポイントとごくわずかですが、Subquadratic公式はこのスコアを「frontier-level accuracy」と位置づけています。注目すべきは絶対値の僅差そのものよりも、「同等精度を、Subquadratic側の主張ではOpus 4.6比で約1/300のコストで達成した」と整理されている点で、性能あたり推論コストの軸で議論が組み立てられています。

SWE-Bench Verified：ハーネス依存を自社で認める透明性

SWE-Bench Verifiedは、実在のGitHub Issueをエージェントが修正できるかを測るベンチマークです。

モデル	SWE-Bench Verified スコア
Claude Opus 4.7	87.6%
SubQ 1M-Preview	81.8%
Claude Opus 4.6	80.8%
Gemini 3.1 Pro	80.6%
Deepseek 4.0 Pro	80.0%

SubQはOpus 4.6・Deepseek 4.0 Proをわずかに上回る一方、Opus 4.7には届いていません。Subquadratic自身は「SWE-Benchの差はモデル本体よりエージェントハーネス（実行枠組み）の影響が大きい」と論文中で認めており、コーディング性能で「SubQが頭ひとつ抜けている」と読むのは過大評価です。実務上は、Opus 4.7と比較して「コーディング能力では一段下、コストとコンテキスト長では大きく上」という住み分けで読むのが妥当です。

MRCR v2：研究と本番の17ポイント差を公式が開示

MRCR v2は、長文中で複数の参照を辿って答える多段検索能力を測るベンチマークで、長文LLMの実力差が出やすい指標です。

モデル	MRCR v2 スコア
Claude Opus 4.6	78.3%
GPT-5.5	74.0%
SubQ 1M-Preview（本番）	65.9%
SubQ 研究モデル	83.0%
Gemini 3.1 Pro	26.3%

ここで注目すべきは、SubQが研究モデルでは83.0%を出している一方、第三者検証された本番モデルは65.9%にとどまり、約17ポイントのギャップが存在する点です。Subquadratic側はこのギャップを公式announcementで開示しているものの、その原因の詳細説明は本稿執筆時点では出ておらず、VentureBeatの検証記事もこの差を「largely unexplained」と評しています。理由の解明は今後公開予定の技術報告書・モデルカード待ちです。
フロンティア比較では「Opus 4.6・GPT-5.5には届いていない」のが現状で、SubQが圧倒しているのは「Gemini 3.1 ProがMRCR系で著しく低い」という分布の中での相対優位です。

Subquadraticの自己評価のトーン

3指標を通じてSubquadratic自身の自己評価は、強みは控えめに、弱みは透明に開示するトーンで一貫しています。
RULER・SWE-Benchでは「frontier-level」「favorably」と慎重な表現を使い、MRCR v2では研究と本番のスコア差を自ら開示しました。これは独立検証コミュニティへの透明性を担保するための姿勢ですが、同時に「現時点では特定領域でしか勝負できていない」という現実認識でもあります。読者側は、ここを踏まえて「長文＋低コスト」の領域に絞ってSubQを評価するのが現実的です。

ベンチマークを読む際の注意点

ベンチマーク数値を引用する際に押さえておきたい制約を整理しておきます。

• 単発実行・信頼区間なし SubQの公開ベンチは推論コストの都合で各モデル1回のみ実行されており、信頼区間が示されていない。0.2ポイント差や1ポイント差は誤差範囲に含まれうる
  
  
• 本番／研究モデル差の未解明 MRCR v2の17ポイント差は公式に開示されているが、その理由は技術報告書未公開時点では推測に頼るしかない
  
  
• エージェントハーネス依存 SWE-Benchはエージェント実装の差で数ポイント動きやすく、SubQ自身がそれを認めている
  
  
• モデルウェイト未公開 第三者が再現実験することは現時点ではできない。VentureBeatの検証記事も「研究者は独立証明を求めている」と指摘している
  
  

---

SubQが解放するユースケース

Subquadratic公式は、SubQによって新たに「単一パス処理」が可能になる領域を強調します。これまで二次計算量を回避するためにRAG／分割エージェント／チャンク化といった迂回手段で対処していたワークロードが、長文LLM単体で素直に解けるようになる、というのが主張の核心です。

全コードベースを単一コンテキストに

最もハマるのは、「分割すると文脈が壊れるが、分割しないと全部入らない」という典型課題を抱えたコードベースです。

• 数百〜数千ファイル規模のモノレポで、設計の影響範囲を一望したい
  
  
• レガシーシステムのリファクタリング前に、どのモジュールがどこから呼ばれているかを把握したい
  
  
• 設計書・実装・テストコードを横断したコードレビューを自動化したい
  
  

RAGで関連ファイルを抽出する方式では、どうしても「呼び出し関係」「暗黙の前提」がこぼれます。SubQ Codeは1コンテキスト投入で全体像をモデルに持たせたまま推論できるため、レガシーコード調査・大型リファクタリングのフェーズで強みが出やすい設計です。

大規模ドキュメント・契約書の単一パス分析

法務・コンプライアンス・監査領域でも、単一パス処理は実務メリットに直結します。

• 数百ページ単位の規程・契約書を分割せずに比較したい
  
  
• 過去数年分の議事録・社内文書を横断したナレッジ検索を行いたい
  
  
• 長文の規制文書（業法・会計基準など）と社内文書を突き合わせて差分分析したい
  
  

RAGベースの社内検索で「意味が近そうな断片」しか拾えず精度が頭打ちになっているケースで、長文LLMで全文を読ませる構成は有効な代替手段になります。

RAGの代替・補完としての役割

公式の論調は、RAGやマルチエージェント調整は「二次計算の制約に対する対症療法」だ、というものです。SubQはこの二次計算の制約が外れることで、検索パイプラインや分割エージェントの設計負荷が消えると主張しています。

ただし、現実的にはSubQ単体に置き換えるのではなく、ハイブリッド構成で進めるのが妥当です。

• 重要文書はSubQ全文ロード／FAQ系は既存RAG 用途で住み分けてコストとレイテンシを最適化
  
  
• チャンキングが構造を壊しているケースだけSubQ 法務・特許・医療など引用元の正確さが品質を決める領域から
  
  
• 既存RAGの精度に頭打ちを感じる箇所から差し替え 一気の置き換えではなく漸進的に
  
  

【関連記事】
GraphRAGとは？その仕組みや実装方法、活用事例を徹底解説！

長期記憶・継続対話の再設計

エージェントが数日・数週間にわたるセッションを保持し続ける用途も、長文耐性の効きどころです。Mamba系・状態空間モデルが苦手としてきた「履歴を圧縮せずに持ち続ける」設計が、SubQでは現実的な選択肢になります。

• 顧客対応エージェントが過去のやり取りすべてを文脈として保持する
  
  
• 開発エージェントが過去の修正履歴・議論・テスト結果を踏まえて次の提案を出す
  
  
• リサーチエージェントが過去の検索結果と分析履歴を全文保持したまま深掘りする
  
  

Subquadraticの技術解説ページでは、研究モデルが扱う5,000万トークン水準で「持続的状態と深い推論を要するアプリケーション」がさらに開けると論じられており、長期記憶を前提としたエージェント設計のアーキテクチャ選択肢が広がる可能性があります。

【関連記事】
自律型AIエージェントとは？その仕組みや自動化との違い、活用事例を解説

---

SubQが変える推論経済学

Subquadratic公式が記事の中盤に置いているのが「Economics matter」のセクションです。コストが推論ワークロードの主要な制約になっている現状認識から、SubQが価格構造そのものを書き換えると論じています。

「コストが主要な制約になった」という診断

長文LLMが業務に入っていない理由は、性能不足ではなくコスト不足だ、というのがSubquadratic公式の論点です。
RULER 128K相当の精度を出すために、Opus 4.6では推論1回あたり相当のコストがかかり、これが大量バッチ処理・長期エージェント・全社展開を阻んでいた、という現状認識を示しています。SubQの「Opus比1/5」「同精度を出す計算量はOpus比1/300」という主張は、この制約を直接外しに行く打ち手として位置づけられています。同様のコスト破壊論はfelloaiのレビューでも「フロンティアレートの約1/5」と整理されています。

「対症療法」としてのRAG・マルチエージェント

Subquadratic公式論調で印象的なのが、RAG・マルチエージェントを「二次計算量の制約への対症療法」と整理する点です。
分割境界で精度が落ちることを承知でチャンキングしているのも、複雑なオーケストレーションをエージェント間で組んでいるのも、本来であれば長文を素直に読ませれば済む話を、コスト制約で迂回しているからだ、という主張です。同様の論点はThe New Stack・Codisteの解説記事でも取り上げられており、仮にこの論立てが正しければ、SubQ普及後の数年で現在のRAGパイプラインや分割エージェントの設計が大幅に簡素化される可能性があります。

POC止まりの構想が本番化する

経済論のもう一つの軸は、「POCで止まっていた構想が商用規模で動き出す」というメッセージです。
コストが10倍下がれば、同じ予算で10倍の規模・頻度・深さのワークロードが回せます。これまで「精度は出るが本番では合わない」と判断されていた長文ユースケースが、コスト要因だけで本番化判断のラインを越える可能性があるという論立てです。

コスト主張の現状の限界

ただし、Subquadratic自身の経済論には現時点で2つの留保があります。

• 公式pricingが未公開 「Opus比1/5」は性能あたり推論コストをベースにした相対表現で、絶対値のトークン単価表は出ていない
  
  
• 同精度の前提に依存 「Opus比1/300」はRULER 128K相当の精度を出すための計算量比であり、短文や別領域では差は縮まる可能性がある
  
  

本格採用を検討する場合は、ベータ期間中に対象タスクで実利用ログを取り、トークン単価を実測値ベースで把握する運用が現実的です。後段の料金セクションで補足します。

---

SubQが提供する3つのプロダクト

SubQ 1M-Previewはモデル単体の発表ではなく、3つのプロダクトを同時に立ち上げています。いずれも非公開ベータでの提供で、利用には公式サイトからアーリーアクセス申請が必要です。

SubQ API

SubQ APIは、SubQ 1M-Previewのフルコンテキストにアクセスできるエンドポイントで、OpenAI互換のSDK／REST APIとして提供されます。代表的な仕様は次のとおりです。

• モデル名 subq-1m-preview
  
  
• コンテキスト長 公式announcementはSubQ 1M-Previewとして1Mを強調する一方、公式トップページのAPI項目では「12M token context window」とも掲示されており、本番APIの実提供上限は要確認
  
  
• 対応機能 Tool Use（関数呼び出し）／ストリーミング応答
  
  
• 互換性 OpenAI互換のSDKを利用可能。既存のOpenAI／Anthropicベースのコードからの移行コストが低い
  
  
• ステータス 非公開ベータ。利用には公式サイトのアーリーアクセス申請が必要
  
  

OpenAI互換であることはPoCの観点では大きな利点です。既存のClaudeやGPT-5.5を使ったエージェント実装の「モデル切り替えだけ」でSubQをA/B検証しやすい設計になっています。一方、Vision・構造化出力・Code Executionなど一部機能は記載が曖昧で、本番運用時には個別確認が必要です。

【関連記事】
Model Context Protocol (MCP) とは？仕組みやRAGとの違いを解説

SubQ Code

SubQ Codeは、コードベース全体を1つのコンテキストウィンドウに読み込むCLI型のコーディングエージェントです。設計思想はClaude CodeやCodex CLIに近い「ターミナルから自然言語で指示してリポジトリを修正させる」スタイルですが、12Mトークン級の長文耐性を活かして、コードベース全体を分割せずに1コンテキストに載せることを売りにしています。

公式が示している差別化点は次のとおりです。

• コードベース全体を一括読み込み RAGで関連ファイルを抽出する代わりに、リポジトリ全体を直接コンテキストに入れる
  
  
• 25%安い請求と10倍速い探索 既存のClaude Code／Codex比で、同等タスクにおけるコスト・所要時間の優位性をマーケティングしている
  
  
• OpenAI互換APIから呼び出し可能 自前のCI／CDパイプラインに組み込みやすい
  
  

「25%安・10倍速」のうち、「探索時間」は再現可能性が高く、外部レビュアーによる実測も今後出てくると見られます。一方、コスト比較は公式pricingが未公開のため、Subquadratic側のフルコストモデル次第で前後する可能性があります。

【関連記事】
Claude Codeとは？主な特徴や使い方、料金体系・拡張機能まで徹底解説

SubQ Search

SubQ Searchは、長文対応の検索／Deep Researchツールで、社内ドキュメントや大量レポートに対する深掘り調査を想定しています。GeminiのDeep ResearchやChatGPTのDeep Researchに近い位置づけですが、12Mトークンの一括処理を活かした「分割せずに本文をそのまま読む」検索が差別化点です。

用途としては次のような場面が想定されます。

• 数百ページ規模のレポートや契約書を、要約せず全文ベースで参照したい場合
  
  
• 長期間のチャット履歴・会議録に対して、複数論点を横断する分析を行いたい場合
  
  
• 既存RAGパイプラインで「分割境界」が答えの精度を落としている場合の代替手段
  
  

SubQ Searchは公式announcement上はprivate betaとされており、SiliconANGLEの報道など二次報道では初期無料と伝えられています。実装の検討段階で「RAGとどう住み分けるか」を社内で議論するための叩き台として、まず触ってみる価値があります。

【関連記事】
生成AIのRAGとは？その仕組みや作り方、活用事例を解説！

---

SubQと主要フロンティアモデルの比較

ここではSubQ 1M-Previewを、現時点の主要フロンティアモデルと比較します。用途別の住み分けを見極めるための基準として参照してください。

スペック・性能比較

主要モデルのスペックとベンチマークを並べると、SubQの位置づけが明確になります。

項目	SubQ 1M-Preview	Claude Opus 4.6	Claude Opus 4.7	GPT-5.5	Gemini 3.1 Pro
最大コンテキスト	1M（研究12M）	1M	1M	1M	約1M
アーキテクチャ	SSA（完全サブクワドラティック）	Transformer	Transformer	Transformer	Transformer
RULER 128K	95.0%	94.8%	—	—	—
SWE-Bench Verified	81.8%	80.8%	87.6%	—	80.6%
MRCR v2	65.9%	78.3%	—	74.0%	26.3%
提供形態	非公開ベータ	GA	GA	GA	Preview

この表から読み取れるのは、SubQが全方位で勝っているわけではない点です。RULERのような事実検索系では同等以上、SWE-Benchではミドル、MRCR v2のような多段推論ではOpus・GPT-5.5に劣るという、得意・不得意の分布があります。これはSSAが「重要位置だけを取り出して計算する」設計上、参照本数が増えるほど選択ロジックの精度に依存する構造とも整合的です。

コーディングエージェント比較

CLIエージェントとしてSubQ Codeを評価する場合、競合はClaude CodeとOpenAI Codex CLIです。

項目	SubQ Code	Claude Code	Codex CLI
ベースモデル	SubQ 1M-Preview	Claude Opus 4.7／Opus 4.6／Sonnet 4.6など	GPT-5.5系
コードベース投入方式	全体を1コンテキストに	RAG＋必要時コンテキスト拡張	RAG＋必要時コンテキスト拡張
強み	巨大リポジトリの一括把握	エコシステムの厚さ・実績	OpenAI製品との統合
弱み	ベータ・実績不足	12M級リポジトリでは分割が必要	12M級リポジトリでは分割が必要

「分割せずに全部読ませる」設計は、設計書・テストコード・ドキュメントを横断するリファクタリングや、レガシーコード調査のように「どこに何があるか分からない」探索系タスクで特に効きます。一方、すでにRAG＋エージェントで運用が回っている案件で、わざわざSubQに切り替える優先度は高くありません。実装の選定基準としては「コードベース規模が1Mトークンを超えるか」「分割境界で精度が落ちている自覚があるか」を最初の問いに置くのが実務的です。

競合の他モデル比較記事

各フロンティアモデル単体の解説については、以下の関連記事を参照してください。

【関連記事】
GPT-5.5とは？使い方や料金、GPT-5.4との違いを解説！

【関連記事】
Gemini 3とは？使い方や料金、利用上限について解説

【関連記事】
DeepSeek V4とは？特徴や使い方、料金体系を徹底解説

---

SubQ導入で注意すべき制約・懸念点

ベータ段階のフロンティアモデルを採用検討するうえで、現時点で押さえておくべき制約と懸念点を整理します。

第三者による独立検証が限定的

VentureBeatによる検証記事やHan Heloir氏のMedium分析、felloaiのレビュー記事では、研究者コミュニティから「モデルウェイト・技術論文を公開しないままの性能アピールは独立検証ができない」「Kimi／DeepSeekの疎注意ファインチューニングではないかという疑い」が指摘されています。Subquadratic自身も「包括的なモデルカードを近日公開予定」とアナウンスしており、本格採用判断は技術報告書のリリース後に持ち越すのが妥当です。

研究モデルと本番モデルの17ポイント乖離

前述のとおり、MRCR v2では研究モデル（83.0）と本番モデル（65.9）に約17ポイントの差が公式に開示されています。原因の詳細説明は本稿執筆時点では出ておらず、VentureBeatもこの差を「largely unexplained」と評している状況で、技術報告書・モデルカードのリリースを待つ必要があります。
PoCで触る場合は、公式ベンチマークの数字をそのまま実環境性能と読み替えず、自社データでベンチを取り直すプロセスを必ず挟むべきです。

エージェントハーネス依存と単発実行

SWE-Benchの差は「ハーネス（エージェント実装枠組み）の影響が大きい」とSubquadratic自身が認めており、ベンチ結果がそのまま「モデルの実力」とは言い切れません。加えて、VentureBeatの検証記事が指摘するとおり、各ベンチが推論コスト都合で1回ずつしか走らせていないため、0.2〜1ポイント差は誤差範囲に入りえます。

公開導入事例ゼロ

Subquadratic公式announcementを含め、本稿執筆時点でSubQ／SubQ Code／SubQ Searchの公開導入事例は確認できません。Anthropic／OpenAI／Googleであれば、エンタープライズ採用事例（Accenture・NYSE等）から運用可否を逆算できますが、SubQはこのレファレンスがゼロです。SLA・障害対応・データ取扱いといった企業要件は、ベータ申請時に直接ヒアリングする以外に確認手段がありません。

機密データ取扱いと学習除外規約の不透明さ

SubQ APIはSubquadratic側のクラウドインフラで動作するベンダーホスト型サービスで、業務データは外部に送信される前提になります。学習除外・データ保持期間・ZDR（Zero Data Retention）・SOC 2／ISO 27001／GDPR等の認証取得状況については、公式pricingページ・公式announcementを確認した時点で明示が整っていません。Anthropicが商用利用規約（Commercial Terms）で「商用契約上、入力データはモデル学習に使わない」と明示しているのと比較すると、ここが弱い領域です。機密データを扱う場合はマスキング前提か、エンタープライズ営業に書面で要件確認を取る必要があります。

料金・利用条件の不透明さ

公式pricingページには現時点で具体的な料金表がなく、「Opus・GPTの約1/5」という相対表現のみが示されています。本番採用に向けたコストシミュレーションを行うには、ベータでの実利用ログから単価を逆算する必要があります。

ベータ申請の必要性

API・SubQ Code・SubQ Searchはすべて非公開ベータで、利用するには公式サイトからアーリーアクセス申請を行う必要があります。即日利用できるOpus／GPT-5.5／Geminiと比較して、PoC開始までのリードタイムが大きく異なる点は計画段階で織り込んでください。

よくある導入の失敗パターン

ベータ段階のフロンティアモデル採用で陥りがちなパターンも押さえておきます。

• 公式ベンチをそのまま運用想定値として使う
  研究モデルと本番モデルの17ポイント差・単発実行・ハーネス依存といった注意点を踏まえず、公式ベンチを「自社業務での期待値」にしてしまうケース。必ず自社データでベンチを取り直す
  
  

• コスト試算を「Opus比1/5」前提で固定する
  公式pricingが未確定の段階で、相対表現を絶対値の前提に変換してしまう失敗。ベータでの実利用ログを取って単価を逆算する手順を踏む
  
  

• ZDR要件を未確認のまま機密データを投入する
  ベータ段階のデータ取扱いポリシーは商用APIほど整っていない。機密データの投入前にエンタープライズ営業へ書面確認を取る
  
  

• 既存スタックを置き換える前提で予算を組む
  Claude／GPT-5.5を本線に置いたまま、SubQはサンドボックス検証で並行運用するのが現実解。「全部置き換え」を前提にすると、ベータの不安定性で本番が止まるリスクがある
  
  

---

SubQの料金体系

ここではSubQ 1M-Previewの料金について、本稿執筆時点で公開されている情報を整理します。フロンティアモデルとしては珍しく具体的な料金表が未公開で、相対比較とユースケース別のヒントのみが提示されている段階です。

公開情報の整理

Subquadratic公式pricingページ・announcementが開示している料金関連情報は次のとおりです。

• API 単価表は非公開。Opus・GPT-5.5の約1/5を主張
  
  
• SubQ Code 単価表は非公開。Claude Code／Codex CLI比で「25%安い請求」を主張
  
  
• SubQ Search 公式announcement上はprivate beta。SiliconANGLE等の二次報道では初期無料と伝えられている（公式pricingに明記なし）
  
  
• アーリーアクセス 公式サイトから申請。承認後にAPIキーが発行される
  
  

「Opus・GPTの約1/5」という比率は、RULER 128Kにおける性能あたりの推論コストをベースにした主張で、フロンティアレートの単純比較ではない点に注意が必要です。同様の精度を出すために必要な計算量が少ないという文脈で出てきている数字なので、短文タスクではこの差はそこまで広がらない可能性があります。

競合フロンティアモデルの料金参考

比較の基準として、主要モデルの公開料金を参考までに掲載します。

モデル	入力（per 1M tokens）	出力（per 1M tokens）	出典
Claude Opus 4.6	約$5	約$25	Anthropic Pricing
GPT-5.5	公式参照	公式参照	OpenAI Pricing
Gemini 3.1 Pro	標準 約$2〜$4 / Batch・Flex 約$1〜$2	標準 約$12〜$18 / Batch・Flex 約$6〜$9	Gemini API Pricing

SubQが本当に「Opus比1/5」を実装できるなら、Opus 4.6の出力$25/1Mを基準にした場合、出力単価は$5/1M前後がレンジとして見えてきます。ただし、これはあくまで仮の概算で、公式pricingが出るまでは予算策定の根拠としては使えません。本格採用を検討する場合は、ベータ期間中に対象タスクで実利用ログを取り、トークン単価を実測値ベースで把握する運用が現実的です。

料金面の意思決定基準

ケース別に、SubQの料金面で意思決定するときの整理軸をまとめます。

• PoC段階 SiliconANGLE等の二次報道で初期無料と伝えられるSubQ Search、API／SubQ Codeはベータ申請後に利用可能。コスト比較より「精度・体感速度・運用負荷」を先に評価する
  
  
• 本格採用検討 公式pricing公開と技術報告書リリース後に判断。それまでは「OpenAI／Anthropicとの併用前提」で構成を組む
  
  
• エンタープライズ要件 SLA・データ取扱い・サポートは申請時に直接確認。社内のセキュリティ要件と突き合わせて要件未充足なら、現時点では本番ワークロードを載せない
  
  

---

SubQをどう試すべきか

ここまでの整理を踏まえ、長文LLMを業務で扱うチームが「SubQを今どう触るか」をケース別に整理します。本格採用判断の手前で、導入判断で詰まる論点として読んでください。

ケース1：長文ワークロードを既に扱っている開発チーム

社内文書の長文RAG／巨大コードベースのレビュー／長期エージェントなど、すでに「コンテキスト長の壁」にぶつかっているチームは、ベータ申請を前向きに検討する価値があります。

• 既存RAG構成で「分割境界の精度劣化」「チャンク間の整合性」を体感している
  
  
• Claude Code／Codex CLIで「リポジトリ規模の大きさが原因で精度が落ちる」と感じている
  
  
• 1Mトークンを超える文脈を扱うエージェント設計を計画している
  
  

こうしたチームは、PoCの上位選択肢として「現状ベース＋SubQの並行A/B」を組むのが妥当です。OpenAI互換APIなのでSDK差し替えが容易で、検証コストが小さい点もポジティブに働きます。

ケース2：フロンティアモデルの動向をウォッチしているCTO・技術リーダー

SubQは「サブクワドラティックがフロンティアスケールで成立した最初の実例」として、アーキテクチャの潮目を変えうる発表です。
ただし本稿執筆時点では本番採用するには検証材料が足りません。動向把握は必要ですが、すぐに既存スタックを置き換える判断には至らないのが妥当です。

• 技術報告書・モデルウェイト公開・第三者ベンチを定点ウォッチする
  
  
• 競合のAnthropic／OpenAI／Googleが類似アーキテクチャを発表してくるかをモニタリングする
  
  
• 自社のロードマップ上で「コンテキスト長の制約で諦めた要件」を棚卸ししておく
  
  

SubQに限らず、「サブクワドラティックでフロンティアスケール」が業界で再現されれば、RAG中心の現アーキテクチャは2〜3年スパンで再設計が必要になります。そのタイミングで動けるよう、社内のデータパイプライン側を整理しておくことが、現時点での最大の打ち手です。

ケース3：ミッションクリティカル業務での即時採用を検討している組織

金融・医療・公共など、SLAと監査要件が厳しい業務での即時採用は、現時点では推奨しません。

• 公開導入事例がゼロ
  
  
• 第三者検証が限定的
  
  
• 公式pricingが未確定
  
  
• 研究モデルと本番モデルのスコア乖離が未解明
  
  
• ZDR・コンプライアンス認証の整備状況が未公開
  
  

これらの条件が整うまでは、Anthropic／OpenAI／Googleのフロンティアモデルでの本番運用を維持しつつ、SubQはサンドボックス環境での検証に留めるのが安全です。

導入判断で詰まりやすい論点

最後に、PoCを進めるうえで多くのチームが詰まる論点を先回りで整理します。

• 既存RAGとどう住み分けるか SubQですべて置き換えるのではなく、「重要文書はSubQ全文／FAQはRAG」のハイブリッド設計を起点にする
  
  
• データガバナンスをどう担保するか 機密文書を含む場合、ベータ環境のデータ取扱いポリシーを書面で確認する
  
  
• コストの上振れリスクをどう抑えるか 公式pricing未確定の段階では、月次ベース・タスク単位での上限設計と、Opus／GPT-5.5への切り戻しプランを用意しておく
  
  
• 複数モデルの切り替え基盤をどう整えるか OpenAI互換APIの利点を活かすには、モデル切り替えを抽象化したゲートウェイ層を持つ構成が有効。AI総合研究所のAI Agent Hubのような統合基盤を入れておくと、SubQの本番化判断時に乗せ替えやすい
  
  

これらを満たさずにいきなり本番ワークロードを載せると、ベータの不安定性・料金変動・データガバナンスの不備が同時に効いてきます。検証フェーズで設計を固めておくことが、本格採用時の判断スピードを左右します。

---

フロンティアモデルの世代交代を業務影響なく進めるなら

SubQ 1M-Previewの登場は、長文LLMの選択肢が「ClaudeかGPTかGeminiか」だけではなくなる流れの一例として読めます。今後さらに新しいフロンティアモデルが登場するたびに業務システム側を作り直すのは現実的ではなく、検証から本番運用へつなぐレイヤーをどう設計するかが、長期で効いてくるテーマになります。

このレイヤーを担うのが、自社のAzureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、SubQのようなベンダーホスト型モデルでの検証から、自社テナント内での本番運用への橋渡しまでを一貫して設計できる構成になっています。

• 複数フロンティアモデルを切り替えながら運用
  SubQ・Claude・GPT・Geminiをユースケース別に使い分けられるよう、OpenAI互換APIを前提としたモデル切り替え層をAIエージェント基盤側に持たせます。新興モデルが本番候補に上がっても、業務システム側を改修せずに乗せ替えられる設計です。
  
  
• ベンダー側検証→自社テナント本番運用の橋渡し
  SubQ APIのようなベンダーホスト型での検証フェーズから、データを外に出せない業務については同じエージェント設計を自社のAzureテナント内に再構築する流れを、設計段階から伴走支援します。
  
  
• クラウド環境を問わずAIエージェントを一元管理
  Microsoft Foundry・Copilot Studio・n8nといった構築基盤を横断して、AIエージェントの実行ログ・アクセス権限・セキュリティスキャンを1つのダッシュボードで管理します。
  
  
• データは100%自社テナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完結する設計のため、機密データを外部に流出させずに長文モデルを試せます。

AI総合研究所の専任チームが、フロンティアモデルの選定から自社テナント内でのAIエージェント運用設計まで一貫して支援します。まずは無料の資料で全体像をご確認ください。

---

まとめ

SubQ 1M-Previewは、Subquadraticが2026年5月5日に発表した、フロンティアスケール初の完全サブクワドラティックLLMです。SSAアーキテクチャによってコンテキスト長に対する計算量を線形に近づけ、研究モデルでは12Mトークンまでの動作を実証しました。RULER 128Kで95.0%とClaude Opus 4.6を上回り、SWE-Bench Verifiedで81.8%を記録するなど、特定領域では既存フロンティア勢と競合しうる水準にあります。

同社の主張で核心になっているのは、Transformerの二次計算量こそAI応用の最大の経済制約だったという論点です。RAGや分割エージェントは「二次計算の制約への対症療法」であり、SubQによって制約が外れた領域では、これまで成立しなかったワークロードが商用規模で動き始める、という整理です。

一方で、技術報告書・モデルウェイト未公開、第三者検証の限定、研究モデルと本番モデルの17ポイントスコア差、公式pricing未確定、公開導入事例ゼロ、コンプライアンス認証未整備といった懸念は無視できません。長文ワークロードを既に抱えるチームによるPoC・ベータ検証は積極的に進める価値がある一方、ミッションクリティカル業務への即時採用は時期尚早と整理できます。

Subquadraticの主張が再現されれば、業界全体のコンテキスト長と推論コストの常識が更新される可能性があります。今後リリースされる技術報告書と第三者検証を見極めつつ、自社のデータパイプラインとAI基盤を「長文LLMが本格化したときに乗せ替えられる構造」に整えておくことが、現時点で取れる最も確実な打ち手です。