SubQ 1M-Preview入門｜料金・性能・始め方2026

LLMのコンテキストウィンドウが1Mトークンを超えた2026年、compute cost（計算コスト）の壁がついに壊れた。Subquadratic社が5月5日に公開したSubQ 1M-Previewは、12Mトークンのネイティブコンテキストを持ちながら、フロンティアモデルの約1/5のコストで動く。attentionの計算量がO(n²)からO(n)へ——理論だけでなく商用APIとして出荷された初の事例だ。

コンテキスト長の問題をアーキテクチャで解いた、という主張の中身を分解する。

SubQ 1M-Previewとは何か

SubQ 1M-Previewは、マイアミ拠点のSubquadratic社が2026年5月5日に公開した大規模言語モデルだ。最大の特徴は、transformer系LLMが避けて通れなかったattention計算のO(n²)ボトルネックを、独自のSubquadratic Sparse Attention（SSA）で突破した点にある。

Subquadratic社の布陣も興味深い。CEOのJustin Dangel（5度の起業経験）とCTOのAlexander Whedon（元Meta）を中心に、11名のPhD研究者・エンジニアがMeta、Google、Oxford、Cambridge、ByteDance、Adobe、Microsoftから集結している。シードラウンドで2,900万ドル（約43億円）を調達済み。

なぜ「1M-Preview」なのか

アーキテクチャは12Mトークンまで処理できるが、現時点で商用提供されるのは1Mトークンまで。段階的なロールアウト戦略だ。12M対応はすでにベンチマークで実証されており、APIでの提供拡大は時間の問題といえる。

名前に「Preview」が付く通り、現在はprivate preview段階。早期アクセスは公式サイトからリクエストできる。

Subquadratic Sparse Attention（SSA）の仕組み

従来のtransformerは全トークン同士のattentionを計算する。計算量はO(n²)。10万→100万トークンに伸ばすと、attention計算だけで100倍に膨れ上がる。長い入力を扱おうとした開発者なら、この壁にぶつかった経験があるはずだ。

content-dependent sparse routing

SSAの核心はcontent-dependent sparse routing。全トークンに対してattentionを計算するのではなく、入力内容に基づいて「関連するトークンだけ」を動的に選び出し、そこだけattentionを計算する。

たとえるなら、図書館で本を探すとき、棚を端から端まで全部見る（O(n²)）のではなく、索引で必要な棚だけ特定して直行する（O(n)）ようなものだ。ただし、索引自体が内容に応じて動的に更新される点が従来のsparse attentionと異なる。

従来手法との技術的な違い

MambaやRWKVもO(n)だが、フロンティア規模で品質が落ちる。何度も期待しては裏切られてきた歴史がある。SSAは「exact attention on relevant tokens」を維持するため品質劣化が起きにくいとSubquadratic社は主張するが、第三者検証はまだない。

52倍のprefill高速化

1MトークンのprefillでFlashAttentionと比較して52倍の高速化。12Mトークンではattention計算量を約1,000倍削減するという数値をSubquadratic社は公表している。

実務的に何が変わるかというと、100万トークンの文書（約2,000ページの技術書）を入力しても、prefillが数秒で完了する。従来のtransformerでは数分かかっていた処理だ。

料金体系｜フロンティアの1/5は本当か

SubQ 1M-Previewの料金は、入力$0.50/1Mトークン、出力$1.50/1Mトークン。GPT-5.5やClaude Opus 4と比較すると、確かにフロンティアモデルの1/5前後に収まる。

見落としがちだが、Gemini 3.1 Flash-LiteとDeepSeek V3.2はSubQより安い。コスト勝負ならSubQは負ける。SubQの狙いは「長大コンテキスト×低コスト×フロンティア品質」の三拍子。価格表だけで判断すると本質を見誤る。

各社のAPI料金を詳しく比較したい場合は「AI API料金 比較2026」の記事も参考になる。

ベンチマーク性能｜SWE-Bench・RULER・MRCR

Subquadratic社が公開しているベンチマーク結果は3つ。コーディング能力を測るSWE-Bench Verified、長文理解のRULER@128K、そして超長コンテキスト精度のMRCR v2だ。

SWE-Bench Verified: 81.8%

SWE-Bench Verifiedはオープンソースのバグ修正タスクで実務的なコーディング能力を測る。81.8%というスコアは、主要AIコーディングツールの中でもトップクラスに位置する。

ただし、SWE-Benchは「短いコンテキストで解ける問題が多い」ため、SubQの長コンテキスト能力を十分に活かせていない可能性がある。真価が問われるのはリポジトリ全体を入力するような大規模コードベース解析だ。

RULER@128K: 95.0%

RULERは「長い入力テキストの中から特定情報を正確に取り出せるか」を測る。128Kトークンで95.0%は非常に高い数値。Needle-in-a-Haystackテストの進化版と考えるとわかりやすい。

MRCR v2@1M: 65.9%

MRCR v2は1Mトークンの超長コンテキストでの読解精度を測る。65.9%という数値をどう読むか。

Claude Opus 4.7の約2倍。Gemini 3.1 Proの約2.5倍。この差は正直驚いた。超長コンテキストの情報抽出でここまで開く数字は、Mamba以降見たことがない。SSAアーキテクチャの真骨頂がこのスコアに凝縮されている。

GPT-5.5・Claude・Geminiとの比較

3軸で切る。コスト効率、汎用タスク品質、エコシステムの成熟度だ。

コンテキスト長×コストの効率

100万トークンを処理するコストを単純計算すると、SubQは入力だけで$0.50。Claude Sonnet 4で同じことをやると$3.00、GPT-5.5 Instantなら$2.00かかる。6倍〜4倍の差。

もっとも、Claude Sonnet 4のコンテキスト上限は200Kトークン、GPT-5.5 Instantは128K。そもそも100万トークンを一度に投入できない。「コスト比較」以前に「できること」が違う。

汎用タスクの品質

SWE-Benchのスコアだけ見ると、GPT-5.5（74%）を上回りClaude Opus 4.7と同等クラスに見える。しかしSubQは汎用ベンチマーク（MMLU、HumanEval等）の公開スコアがまだ少ない。

自分なら、汎用的なチャットや日本語の文章生成にはClaude Sonnet 4を使い、大量の文書を一括処理する場面だけSubQを投入する。使い分けが現実的だ。各モデルの特性は「AIサービス比較15選」でも網羅している。

エコシステムの成熟度

GPT-5.5はOpenAI APIの巨大なエコシステムに乗っている。Claude Agent SDKはエージェント開発フレームワークとして急成長中。一方、SubQのエコシステムはまだ生まれたばかり。

SubQ APIはOpenAI互換のため既存コードの移行は容易だが、サードパーティの統合やドキュメント、コミュニティの規模はこれからだ。プロダクション投入はGA後が安全だろう。

APIの使い方｜セットアップからコード例まで

SubQ APIはOpenAI SDK互換。既にOpenAI APIを使っているなら、base URLとAPIキーを差し替えるだけで動く。

セットアップ手順

まずsubq.aiでアカウントを作成し、early accessをリクエストする。承認されるとAPIキーが発行される。

# OpenAI SDK のインストール（まだの場合）
pip install openai

# 環境変数にSubQ APIキーをセット
export SUBQ_API_KEY="sk-subq-your-key-here"

基本的なAPIリクエスト（Python）

from openai import OpenAI

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

response = client.chat.completions.create(
    model="subq-1m-preview",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain subquadratic attention in 3 sentences."}
    ],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

OpenAI SDKのbase_urlをhttps://api.subq.ai/v1に変えるだけ。ストリーミングも標準対応しているため、レスポンス体験は他のAPIと変わらない。

大容量コンテキストの投入例

筆者が最も気になったのは大量コード投入のユースケースだ。リポジトリ全体を読み込ませてバグを探す——従来はチャンク分割で文脈が切れていた処理が、一発で通る:

import glob

# リポジトリのソースコードを結合
code_files = glob.glob("src/**/*.py", recursive=True)
full_code = ""
for f in code_files:
    with open(f) as fp:
        full_code += f"\n--- {f} ---\n{fp.read()}"

response = client.chat.completions.create(
    model="subq-1m-preview",
    messages=[
        {"role": "system", "content": "You are a senior code reviewer."},
        {"role": "user", "content": f"Review this codebase for bugs:\n{full_code}"}
    ]
)
print(response.choices[0].message.content)

100ファイル、合計10万行のPythonプロジェクトを試算すると約70万トークン。1M以内に余裕で収まる。Claude Sonnet 4でこれをやろうとすると200K上限で4分割が必要だった。分割すると「ファイルAの定義がファイルBで矛盾している」といったクロスファイルのバグを拾えない。SubQなら一発で全体を見渡せる。

tool use（関数呼び出し）

SubQ APIはtool useにも対応している。AIエージェントのバックエンドとして使う場合、長大なコンテキストを保持しながらツールを呼び出せるのは大きなアドバンテージだ。

実用シナリオ｜12Mトークンが活きる場面

「12Mトークンのコンテキスト」が活きるのは、情報を分割すると文脈が失われるタスクだ。

逆に、短いやり取り（チャットボット、Q&A）や日本語の文章生成ではSubQを選ぶ理由が薄い。その場合はClaude Sonnet 4やGPT-5.5 Instantのほうが日本語品質・レスポンス速度ともに上だろう。

プロンプトエンジニアリング入門で解説しているテクニックはSubQでもそのまま使える。長コンテキストだからといって特別なプロンプト設計が必要になるわけではない。

懸念点と注意すべきリスク

SubQには期待と同じくらい疑問符もつく。VentureBeatの報道では、研究者コミュニティから独立検証を求める声が上がっている。研究コミュニティの反応は辛辣だ。

技術レポートが未公開

2026年5月時点で、SSAの完全な技術レポートは公開されていない。モデルの重みもクローズド。MambaやRWKVが公開論文と重み公開で信頼を積み上げてきたのと対照的だ。

自社ベンチマーク結果だけで「フロンティア」を名乗ることへの批判は当然ある。第三者機関（例: LMSYS Chatbot Arena）でのランキング入りが信頼の分水嶺になるだろう。

subquadratic attentionの過去の実績

O(n)やO(n log n)のattention手法は過去にいくつも提案されてきた。Mamba、RWKV、DeepSeek Sparse Attention——ML関連の論文を追ってきた人なら、期待→失望のサイクルを覚えているだろう。いずれもフロンティア規模ではtransformerに及ばなかった。

SSAが「今度こそ」本物なのか。答えはGAまでの数ヶ月で出る。検証済みのベンチマーク3つだけでプロダクションに全面採用するのは、さすがにリスクが高い。

private previewの制約

APIは申請制。承認までの待ち時間は不明で、SLAの保証もない。プロダクションのバックエンドに突然入れて、翌週にAPI仕様が変わった場合の影響を想像すると、GA後の安定稼働を確認してからが現実的だ。

よくある質問

まとめ｜SubQを使うべき人・待つべき人

SubQ 1M-Previewは、LLMのアーキテクチャレベルで計算効率を変えた初の商用モデルだ。12Mトークンのネイティブコンテキスト、フロンティアの1/5のコスト、MRCR v2でClaude Opus 4.7の2倍の精度。数字だけ見れば圧倒的。

自分なら、評価環境でまず試す。リポジトリ丸ごとの解析タスクをSubQに投げて、同じタスクをClaude Sonnet 4（チャンク分割）とコスト・精度で比較する。その結果次第でGA後にプロダクション導入を検討する。

subquadratic attentionが本物なら、2026年後半のLLM市場を根底から変える。「長コンテキスト税」がなくなった世界で、何が可能になるか——それを想像するだけでも、early accessを申請する価値はある。

AI技術トレンド7選とAIネイティブ開発完全ガイドは、subquadratic attentionの文脈でも参照点になる。