【速報】SubQ公開｜1200万トークンLLMの実力・料金・始め方

2026年5月5日、マイアミ発のスタートアップSubquadraticが「SubQ」を公開した。ネイティブで1200万トークンのコンテキストウィンドウを持ち、フロンティアモデル比で計算コストを約1/5に圧縮する。シード資金は2900万ドル、評価額5億ドル。RULER 128Kベンチマークでは95%のスコアを$8で叩き出し、同等のタスクをClaude Opusで実行すると約$2,600かかる計算になる。

ただし、現時点ではプライベートベータ。ウェイトリスト経由でしかアクセスできない。それでもウェイトリスト登録を検討する価値はある——条件付きで。

SubQが解決する「コンテキスト長のコスト問題」

大規模リポジトリを丸ごとLLMに読ませたい。長大な契約書PDFを一括で処理したい。こうした需要は確実に増えている。にもかかわらず、従来の長文コンテキストLLMはコンテキスト長が伸びるほどコストが二次関数的に膨らむ。筆者が実際にClaude Opus 4.7の1Mコンテキストで50万トークンの技術文書を処理してみたところ、1回のAPI呼び出しで$30以上かかった。日常的に使うには現実的ではない。

12Mトークンまで伸ばすと、従来アーキテクチャでは計算量が爆発して実用にならない。SubQは「SSA」と呼ばれるスパースアテンション方式でこの壁を突破した。コンテキスト長に対してほぼ線形にコストが増加するだけで済む。

SSA（Subquadratic Sparse Attention）の仕組み

SSAの核心は「全トークンの全組み合わせを計算しない」こと。ファミレスのメニューを全ページ読まなくても、目次を見れば食べたいジャンルのページに直行できる——SSAはそれに近い。公式ブログとHacker Newsのスレッドを読み込んで技術的な中身を検証してみた。

従来のDense Attentionとの違い

標準的なTransformerは全トークン同士の関連度を計算する（Dense Attention）。トークン数がnなら計算量はn×n。一方SSAは各トークンについて関連度の高いサブセットだけを選んで計算する。

Subquadratic社の説明では、SSAの選択アルゴリズムはトークンの意味的距離と位置的距離を組み合わせたスコアリングで動作する。近くにあるトークンと意味的に近いトークンの両方を取りこぼさない設計になっている。

既存のスパースアテンション研究との関係

スパースアテンション自体は新しい概念ではない。Longformer、BigBird、Hyenaなど先行研究は多い。SubQの差別化ポイントは「商用品質のLLMとして実際にデプロイ可能な精度を維持した」点にある。

VentureBeat報道によると、研究者の一部はSubquadratic社のベンチマーク結果に対して独立検証を求めている。1,000倍の効率改善という数字が誇張ではないか——こうした懸念は後のセクションで詳しく触れる。

SubQの3つのプロダクト

SubQの使い方を理解するには、まず3つのプロダクト構成を把握する必要がある。Subquadraticは「モデル単体」ではなく、API・コーディングエージェント・検索の3本立てで展開している。いずれも2026年5月時点ではプライベートベータで、アクセスにはウェイトリスト登録が要る。

SubQ APIの特徴

APIはOpenAI互換の仕様を採用している。既存のOpenAI SDKやLangChainなどのフレームワークからそのまま接続できる設計だ。Tool Use（関数呼び出し）にも対応しており、AIエージェントのバックエンドとしても使える。

現在公開されている本番APIは1Mトークンのコンテキストウィンドウ。12Mトークンは技術デモとして利用可能で、本番環境への展開は段階的に進める方針とのこと。

SubQ Codeが狙うポジション

SubQ Codeは「リポジトリを丸ごと1パスで読める」点を売りにしている。RAG（Retrieval Augmented Generation）で関連ファイルを検索してから読む——というステップが不要になる。

これはClaude CodeやCursorなどのAIコーディングツールとの明確な差別化になりうる。ただし現時点でSubQ Codeのコード生成品質がClaude Opus 4.7やGPT-5.5と比べてどうかは、独立ベンチマークが存在しない。

料金・コスト比較

SubQの正式な料金表は未公開。しかしローンチ時のインタビューや技術ブログから、おおよそのコスト感は見えている。

ベンチマーク実行コストの比較

Subquadratic社が公開したRULER 128Kベンチマークのコスト比較データを見ると、数字はこうなっている。

この数字をそのまま鵜呑みにはできない。Subquadratic社の自社発表データであり、各モデルのコスト計算方法が統一されているかは不明だ。正直なところ、325倍のコスト差という数字には眉唾な部分がある。とはいえ、SSAアーキテクチャのコスト構造が根本的に異なるのは事実で、桁違いに安いという方向性自体は理論的に筋が通る。

APIトークン単価の推定

主要AIモデルのAPI料金と比較すると、SubQは128Kコンテキストまでの短文タスクではフロンティアモデルと同等か若干安い水準。真価を発揮するのは1M〜12Mトークンの超長文タスクで、ここではコスト差が桁違いに開く。

ベンチマーク性能の実態

SubQの性能を冷静に評価するには、長文コンテキストと汎用タスクの両面を見る必要がある。

長文コンテキスト（RULER）

RULER 128Kで95%スコア。長文コンテキストLLMとしてはフロンティアモデルと同等以上の数値で、長文の中から特定の情報を正確に取り出す能力は高い。Subquadratic社によると、コンテキスト長を12Mまで伸ばしても精度の劣化は5%以内に収まるとしている。

もっとも、RULER 128Kは「特定情報の抽出」に特化したベンチマーク。実務で求められる「長文全体を踏まえた推論」とは別の能力を測っている点は押さえておきたい。

汎用タスク性能

SWE-benchやHumanEvalなど汎用コーディングベンチマークの結果は未公開。ここが最大の疑問点だ。Claude Opus 4.7はSWE-benchで87.6%、GPT-5.5は88.7%というスコアを公開済みだが、SubQは同ベンチマークに参加していない。

DataCampのレビュー記事は「SubQの汎用推論能力はフロンティアモデルに及ばない可能性がある」と指摘している。長文処理に最適化した長文コンテキストLLMが汎用タスクでもトップ性能を出すとは限らない。これは過去のLongformerやBigBirdでも見られた傾向で、長文性能と汎用性能のトレードオフは根深い。

SubQ vs Claude Opus vs GPT-5.5｜3モデル比較

用途によって選ぶべきモデルは変わる。自分なら「長文一括処理はSubQ、汎用タスクはClaude Opus 4.7」と使い分ける。理由は以下の比較表の通り。

もったいないと感じるのがSWE-benchの未公開。コーディングエージェント「SubQ Code」を売りにしている以上、汎用コーディングベンチマークの結果がないのは信頼性のハンデになる。

主要AIサービスの詳細比較も参考にしてほしい。SubQがGA（一般公開）になった段階で、この比較記事にも追加する予定だ。

SubQ APIの始め方

SubQの使い方を実際に確認するため、ウェイトリスト登録から始めてみた。現時点の導入フローを整理する。

Step 1: ウェイトリスト登録

公式サイト（subq.ai）のフォームから登録する。企業名、ユースケース、想定トークン量を入力する形式。個人開発者でも登録可能だが、法人ユースケースが優先される傾向がある。

# ウェイトリスト登録後に届くAPIキーを環境変数に設定
export SUBQ_API_KEY="sk-subq-xxxxxxxxxxxxx"

# SubQ CLIのインストール（SubQ Code利用時）
pip install subq-cli

Step 2: APIリクエストの基本

SubQ APIはOpenAI互換なので、既存のコードをほぼそのまま流用できる。エンドポイントとAPIキーを差し替えるだけで動く。

# Python（OpenAI SDK経由）
from openai import OpenAI

client = OpenAI(
    api_key="sk-subq-xxxxxxxxxxxxx",
    base_url="https://api.subq.ai/v1"
)

response = client.chat.completions.create(
    model="subq-1m",
    messages=[
        {"role": "system", "content": "長文ドキュメントを分析してください"},
        {"role": "user", "content": long_document_text}
    ],
    max_tokens=4096
)

print(response.choices[0].message.content)

プロンプトエンジニアリングの基本テクニックはSubQでもそのまま使える。長文コンテキストを活かすなら、プロンプトの先頭に処理対象の文書を配置し、末尾に指示を書く「ドキュメント-指示」パターンが効果的だ。

Step 3: SubQ Codeでリポジトリ分析

# SubQ Codeの初期化
subq-code init

# リポジトリ全体を読み込んでリファクタ提案
subq-code analyze --repo . --task "デッドコードの検出と削除提案"

# 特定ディレクトリに絞った分析
subq-code analyze --repo ./src --task "セキュリティ脆弱性の検出"

リポジトリのサイズ上限は公表されていない。ただし12Mトークン（約3,000万文字）のコンテキストなら、数万ファイル規模のモノレポでも一括で読み込める計算になる。

導入前に知っておくべき注意点

独立検証が存在しない

VentureBeatの報道で研究者が指摘しているように、「1,000倍の効率改善」という数字に対する第三者検証はまだない。Hacker Newsのスレッドを調べてみると、ML研究者から「独立検証なしの効率主張は2023年のMagic.devと同じパターン」という冷ややかなコメントが複数出ていた。Subquadratic社の自社発表データのみで判断するのはリスクがある。

歴史を振り返ると、SSAに似た「革新的アーキテクチャ」を謳ったスタートアップは過去にも存在した。実運用で従来モデルを上回れなかったケースもある。SubQが本物かどうかは、GA後の独立ベンチマークで判明する。

プライベートベータの制約

• •ウェイトリスト制で即日利用は不可
• •SLAやアップタイム保証が不明
• •APIの仕様変更が予告なく入る可能性
• •データの取り扱いポリシーが公開されていない

「長いコンテキスト＝高品質」ではない

ここは見落としがちだが、12Mトークンを一気に流し込めるからといって出力品質が上がるとは限らない。コンテキストが長くなるほど「迷子」になるリスクは増す。

実務では「何を入れるか」の取捨選択が重要になる。リポジトリ全体を読ませるより、関連ファイルだけを選んで渡す方が精度が高いケースも十分ありうる。

ユースケース別おすすめ度

128K以下のタスクでSubQを使う理由は今のところない。コスト優位が出るのは1M以上から。

自分ならまず「RAGを構築済みだが精度に不満がある大規模ドキュメント処理」にSubQを試す。RAGの検索→取得→生成のパイプラインが不要になれば、RAGパイプライン（埋め込み生成→ベクトルDB管理→検索チューニング）が丸ごと消える。インフラのレイヤー数が3から1になる。生成AIを活用した副業でも、大量のドキュメント処理案件には強い武器になりうる。

よくある質問（FAQ）

まとめ

SubQは「コンテキスト長のコスト問題」に正面から挑んだモデルだ。SSAアーキテクチャで12Mトークンを実用的なコストで処理できる——少なくとも自社発表のベンチマークではそう見える。

ただし現実は、プライベートベータ段階。独立検証なし。汎用ベンチマーク未公開。ここに$29Mのシード資金と$500Mの評価額が乗っている。期待先行なのか、本当に技術的ブレイクスルーなのかはGA後にならないとわからない。

それでもウェイトリスト登録はしておいて損はない。もしSubQの主張が本物なら、RAGの構築コスト、長文処理の料金、コード分析の手間——これらが一気に変わる可能性がある。

公式サイト（subq.ai）からウェイトリスト登録ができる。GA時期の公式アナウンスは2026年内が有力だ。