SubQ AI 徹底解説：1200万トークンのコンテキストウィンドウ LLM はどれほど優れているのか

2026年5月5日、マイアミに拠点を置く小さなスタートアップ Subquadratic が SubQ というモデルを公開しました。チームは小規模ながら、シードで2,900万ドルを調達し、このモデルが 一度の処理で最大1200万トークンまで扱えると主張しています。

さらに、FlashAttention に対して100万トークン時で最大52倍の効率、そしてコストは約1/20で Claude Opus に匹敵するコーディング性能といった、一見突飛に聞こえる主張もしています。

どれも大きな主張なので、実際のところを丁寧に見ていく必要があります。本稿では、SubQ とは何か、アーキテクチャの仕組み、そして初期情報や開発者コミュニティの反応がこれらの主張について何を示唆しているのかを解説します。

SubQ とは？

SubQ は Subquadratic が2026年5月5日にリリースした LLM で、目玉機能は1200万トークンのコンテキストウィンドウです。同社が初めて出荷したモデルであり、効率とコストに関する大膽な主張がすでに大きな議論を呼んでいます。

モデルはまだ一般公開されていません。API、SubQ Code、SubQ Search へのアクセスは現在、ウェイトリスト経由のアーリーアクセスに限られています。

このモデルは SSA（Subquadratic Sparse Attention）と呼ばれる仕組みに基づいています。

標準的な密なアテンションのように「すべてのトークン同士を比較」するのではなく、SSA は選択的なアプローチを取ります。各トークンに対して、最も関連性の高いトークンを選び、その部分集合内でのみ関係を計算します。

この設計には明確な効果が2つあります。

• 第一に、計算量が減るため、効率が直接向上し、コストが下がります。
• 第二に、選択がコンテンツ依存であること。つまり近傍のトークンだけを見るのではなく、シーケンス内のどこからでも、離れた場所にある関連トークンを引き寄せられます。

SubQ の特長は？

実運用では、SSA アーキテクチャにより、モデルは「すべてを同等に処理する」のではなく「本当に重要なもの」に集中します。狙いは、フルアテンションに近い精度を、はるかに少ない計算資源とメモリで実現することです。

まずは密なアテンションを確認し、その後に両者を比較してみましょう。

トランスフォーマーの二乗スケーリング問題

現在の GPT、Claude、Gemini といったモデルは密なアテンションに依存しています。大まかに言えば、入力内のすべてのトークンが他のすべてのトークンと比較されます。入力が増えるにつれ、比較の数は二乗で増加します。

長文ドキュメントで最後の語を生成する必要があると想像してください。モデルは文書中のすべてのトークンを参照し、関係を構築した上で次に来る語を決めます。密なアテンションがよく機能するのは、すべてを考慮するからです。

しかし、その強みにはコストが伴います。入力サイズが大きくなると計算量とメモリ要求が急増し、コンテキストウィンドウの制約が生じます。単純化すると、トークン数 n に対して O(n²) でスケールします。

このため多くのモデルには実用的な上限があります。標準モデルでは128kトークンが一般的で、Claude Opus のような強力なモデルでも最大は100万トークン程度です。

これを回避するため、AI システムの多くはフルデータセットをそのままモデルに与えるのを避け、次のような手法に頼ります。

• RAG（検索拡張生成）：データを外部に保存し、関連するチャンクのみを取得してモデルに渡す。
• チャンク化：大きなテキストを小さく分割し、関連する部分だけを送る。
• 要約戦略：長文を圧縮し、全文ではなく要約をモデルに与える。

アテンション機構をさらに深く理解したい場合は、LLM におけるアテンション機構のチュートリアルをご覧ください。最新 LLM の基礎を手を動かして学ぶには、Transformer Models with PyTorch コースをおすすめします。

SubQ の差別化ポイント

密なアテンションは入力サイズに対して二乗で増加しますが、SSA は O(n・k) に近い、より低い次数でスケールするよう設計されています（O(n²) ではなく）。ここで k は各ステップで選ばれるトークン数です。k が n に比べて小さく保たれる限り、フルアテンションより大幅に効率的です。

密な全結合と疎で選択的な接続を対比した、二乗 vs 線形アテンションの図。

ここで当然の懸念は精度です。入力の一部しか見ないなら、重要な関係を見落とす可能性があります。通常、このトレードオフが密なアテンションを採用する理由です。

SubQ の主張は、このトレードオフが実運用では表れないというものです。遠く離れた位置にあるトークンでも必要なものにはきちんと注意を向け、トップモデル並みの精度を維持できると言います。

Subquadratic Sparse Attention はどう機能するか

SSA は「すべてのトークン同士を比較」する代わりに、シーケンス中で重要なトークンだけを選択し、その位置に対してアテンションを計算します。では、どのように選ぶのかを見ていきましょう。

SSA による関連関係の選択

SSA はコンテンツ依存のルーティングを用います。平たく言えば、現在のトークンに対する関連度に基づいてトークンを選びます。similarity(query_i, key_j) のような類似度をトークン間で計算し、スコアが高い上位 k 個のみをアテンション対象として保持します。

時間の経過とともに、モデルは意味のあるトークンを優先し、ノイズを無視することを学習します。キーワード、重要なエンティティ、強い文脈信号を持つトークンなどがこれに含まれます。

SSA はコンテンツだけでなく、シーケンスの構造的関係も保持します。例えば、近傍トークンには常にローカルなアテンションパターンで注意が向けられ、特定のグローバルトークンはシーケンス全体にわたって注意を行き渡らせるよう設計されています。

SSA には階層的・クラスタリングに基づくアテンション手法も含まれます。たとえば類似トークンをクラスタにまとめ、最も関連するクラスタとの間でアテンションを計算します。これにより、モデルはすべてのトークンを逐一評価する必要がなく、まずグループ単位で推論し、必要に応じてそのクラスタ内のトークンへズームインできます。

長文コンテキスト検索に向けた学習

大きなコンテキストウィンドウだけでは魔法は起きません。たとえ1200万トークンを与えても、その文脈を有効活用する術が必要です。SSA はこの目的で学習されています。

• 事前学習：大規模で多様なデータセット上で、長文コンテキスト表現を含めてベースモデルを学習。
• 教師あり微調整：推論やコード生成などの構造化タスクで追加学習。
• 強化学習：モデルを近傍（ローカル）に限定せず、テキスト全体（グローバル）から関連トークンを活用するよう促す段階。

強化学習の段階は、エンタープライズのコーディング用途で特に重要です。生成中に一度により広い文脈、つまりコードベース全体を考慮できるようにします。

SubQ のベンチマークと性能

「SubQ 1M-Preview」は100万トークンでのベンチマーク対象バージョンを指します。完全な1200万トークンのコンテキストは API から利用できます。

Subquadratic が公開した3つのベンチマークでは、SubQ 1M-Preview は Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro と互角に渡り合っています。

ただし選ばれたベンチマークは限定的で、長文コンテキスト検索とコーディングに特化した3つのみ。これは SubQ が明示的に得意とする領域です。一般的な推論、数学、多言語性能、安全性といった幅広い評価は未公開です。

フルのモデルカードはサイト上で「近日公開」とされているため、今後はベンチマークが一般的なユースケースにも広がると見られます。

現時点では、長文コンテキスト検索とコーディングのユースケースでの結果は以下の通りです。

数字が示すもの

RULER 128K：SubQ は95%、Opus 4.7 は94.8% を記録。精度差は誤差レベルですが、重要なのはコストです。同一の文脈長でこの評価を走らせた場合、Subquadratic は SubQ で約8ドル、Opus では約2,600ドルかかったと主張しています。

MRCR v2（8-needle、1M）：このベンチマークは、100万トークンの文脈に埋め込まれた8つの事実を正しく取得・追跡できるかを評価します。SubQ は研究環境で83% を示す一方、プロダクションでは65.9% に低下。研究と実運用の約17ポイントの差は注目に値しますが、完全には説明されていません。それでもなお、GPT-5.5（74.0%）と競合し、Claude Opus 4.7（32.2%）やGemini 3.1 Pro（26.3%）を大きく上回ります。

SWE-Bench Verified：SubQ は81.8% で、Opus 4.6 の80.8% を上回る一方、Opus 4.7 の87.6% には及びません。Opus 4.6 に対する差は小さく、ハーネスの設定に敏感です。Opus 4.7 や GPT-5.5 に対しては、SubQ は明確に劣後します。

1200万トークン時：SubQ は 1200万トークンの「干し草の山に針」タスクで90%超を記録したと報告されていますが、公的なベンチマークでの検証はありません。他のフロンティアモデルはこの長さでテストされておらず、直接比較できる対象がありません。今回の発表で最もアーキテクチャ的に興味深い結果である一方、結論を出す前に独立した再現が必要です。

RAG、コーディングエージェント、AI コストに対する SubQ の意味

もし SubQ のアーキテクチャがスケールに耐えるなら、LLM システムの作り方は変わります。より長いコンテキストが現実的となり、過度なチャンク化、検索、トークン最適化の必要性が下がります。詳細を見ていきましょう。

RAG が「任意」になるとき

過去2年、Retrieval-Augmented Generation（RAG） は LLM の本質的な制約――モデルは一度にすべてを読めない――への標準解でした。ナレッジベースがコンテキストウィンドウを超えるなら、文書をチャンク化し、埋め込みを作成し、ベクターデータベースに保存し、関連部分だけを検索してプロンプトに添えて渡します。

このエコシステム全体は、コンテキストが不足しているからこそ存在しています。

一度の処理で数百万トークンを確実に扱えるモデルが登場すると、ワークフロー次第では検索にまつわる多くのエンジニアリング層が不要になります。どのチャンクを取るかに時間を費やすのではなく、生素材をそのまま取り込み、エンドツーエンドで推論できるようになるのです。

ただし、コンテキストウィンドウを超える観点では、RAG は次のような能力のために依然として重要です。

• セッション横断の記憶：LLM はセッションが終わると何も覚えていません。ユーザーが後から戻ってきても、モデルはゼロから再開します。検索システム（やデータベース）は過去の判断、文書、ユーザーデータなどを保存し、将来の対話で想起できるようにします。
• 権限とアクセス制御：検索システムは「このユーザーは自チームのデータのみアクセス可能」といったルールを強制できます。これにより、ユーザーが閲覧可能な文書のみがモデルに渡され、偶発的な情報漏えいを防げます。
• 監査可能性：エンタープライズでは、答えを出すだけでなく、その根拠も必要です。検索システムは使用した文書やソースを指し示せるため、検証や不具合時のデバッグが可能です。
• 構造化されたナレッジ管理：企業は絶えず文書を追加・更新・削除します。検索システムは埋め込みやインデキシングでこれらを整理し、毎回全再処理せずとも最新で関連度の高い情報に素早くアクセスさせます。

AI エージェントに永続メモリを持たせる興味深い新アプローチについては、Supermemory チュートリアルをご覧ください。そこでは、短期・長期記憶を備えたエクササイズトレーナーの作り方を学べます。

長文コンテキストのコーディングワークフロー

現状、多くのコーディングモデルはコードベース全体を見渡せません。そのため、適切な文脈をウィンドウ内に保ち、ファイル間の関係を構築するために、ファイル検索、チャンク化、ランキング、マルチステップ計画などの層を上乗せしています。

しかし SubQ の1200万トークンなら、コードベース全体を一度にモデルへ読み込めます。これはエージェント設計を意味のある形で単純化します。

• 計画がグローバルに：アーキテクチャ、依存関係、ファイル間の相互作用を、文脈抜けなく推論できます。
• 実行の一貫性：複数ファイルにまたがる変更を、段階的更新ではなく一度のパスで調整できます。
• レビューの信頼性：コードベース全体に照らして自己検証でき、矛盾を減らせます。

コスト経済性

標準的なトランスフォーマーでは、アテンションはシーケンス長に対して二乗でスケールします。コンテキストを2倍にしても、コストは単純に2倍では済まず、4倍に跳ね上がることがあります。

SubQ はこのトレードオフを打破すると主張しています。

• 同等のフロンティアモデル（Claude Opus）比で約1/20のコストを報告
• 1200万トークンの文脈で最大約1000倍の計算量削減

これが本番でも成り立つなら、長文コンテキスト処理は高価な特殊事例ではなく、日常的に使えるものになります。

ただし安価なコンテキストウィンドウがあるだけでなく、投入した情報を効率よく活用できる必要があります。ベンチマーク上は、SubQ は大幅に低コストで同等の精度を主張していますが、最終判断を下すには時期尚早です。

SubQ へのアクセス方法

SubQ はまだ一般公開されていません。コア API、SubQ Code、SubQ Search の3製品はいずれもプライベートベータで、アクセスには SubQ のウェブサイトからアーリーアクセス申請が必要です。

開発者の観点では、API は統合しやすい設計です。対応機能は次の通りです。

• ストリーミング応答
• ツール／関数呼び出し
• OpenAI 互換エンドポイント

つまり、既に OpenAI 形式の API を使っているスタックであれば、統合を一から書き直す必要は基本的にありません。

SubQ Code はコマンドラインのコーディングエージェント、SubQ Search は調査ワークフロー向けの長文検索に特化しています。いわば Claude Code と Perplexity の SubQ 版と捉えられます。

いずれのツールについても価格は未透明です。公開された per-token レートがなく、同社のコスト主張を独自に検証するのは困難です。

懐疑と未解決の疑問

ローンチから数時間で、SNS や Hacker News のような掲示板には既に多くの懐疑と賛否が渦巻いています。議論は二分され、真のブレークスルーと見る向きもあれば、「AI の Theranos（詐欺的な技術主張で失敗した血液検査スタートアップの比喩）」にたとえる声もあります。

主な疑問点は次のとおりです。

• 1200万トークンのコンテキストウィンドウをうたう一方で、共有されたベンチマークはすべて100万トークンです。
• 社名は Subquadratic（準二乗）なのに、一部では O(1) 的なスケーリングにも言及しています。もし O(1) なら1200万トークンをはるかに超えるコンテキストが期待されます。O(log n) でもより大きな上限が可能なはずです。

2024年の Magic.dev でも似た話がありました。1億トークン級の極端に大きなコンテキストと大幅な効率向上、特にコーディングワークフロー向けの強みを強く主張していました。

提案はほぼ同じでした。コードベース全体を読み込み、検索の複雑さを減らし、エージェント設計を単純化する。しかし少なくとも公開情報の範囲では、結果はより控えめでした。約5億ドルを調達したものの、2026年初頭時点で実世界での可視性や採用事例は限られています。

検証済みの点

SubQ の主張は純粋に理論上のものではありません。RULER、MRCR v2、SWE-Bench Verified のベンチマークは第三者のテストサービスによって実施されたとされ、長文コンテキスト検索での強さと、コーディングタスクでの競争力が示されています。

ただし、これらの結果は外部研究者による独立再現がまだなく、評価範囲も狭いままです。いずれのベンチマークも、SubQ が得意とする（巨大な文脈から信号を取り出し、コードを扱う）領域に的を絞っています。

もう一つ重要なのはアーキテクチャです。CTO は、SubQ はベースモデルをゼロから学習するのではなく、（DeepSeek や Kimi といった）オープンソース系のファミリーに基づいていると認めています。小規模チームにとって現実的な選択で、反復を速め、学習コストを抑えられます。つまり、中核の革新はベースモデルそのものではなく、アテンション機構とそれを取り巻くシステム設計にあるということです。

まとめ

SubQ が登場し、主張はかなり大胆です。狙いは明快で、コンテキストウィンドウの制約を取り払い、より大きな入力を扱えるようにすること。コーディングと長文検索でフロンティアモデルに匹敵または凌駕しつつ、はるかに低コストでの提供を掲げています。

とはいえ、まだ初期段階です。より広範な能力や検証に関する可視性を得るには、フルのモデルカード公開を待つ必要があります。これを基にした SubQ Code や API も一般公開前です。実際にこれらのツールを触り、主張が本番でどう立証されるかを確かめるのが楽しみです。