Shannon 3.1

たいていのモデルリリースは、性能の主張をひとまず信じて、ベンチマーク表が決着をつけるのを待つよう求めてきます。今回は確かめるのがもっと簡単です。タブを2つ開き、同じプロンプトをshannon-3とshannon-3.1に入れて眺めてください。回答が届く速さの違いは微妙なものではありませんし、描画上の小細工でもありません。Shannon 3.0は意図的に絞られていました。Shannon 3.1は絞られていません。

01Shannon 3.1で実際に変わったこと

Shannon 3.0は、このファミリーを定義するものを導入しました。反復推論ループです。モデルは最初に思いついたことで答えません。思考し、下書きし、その下書きを問いに照らして見直し、改善します。Liteはこのループを1回実行し、Proは下書き前の知識収集ステップを含む完全なループを実行します。この設計はShannon 3の研究記事で詳しく説明しており、3.1ではその部分は何も変わっていません。

変わったのは、その下にある機構です。Shannon 3.0はサードパーティの推論ホスト経由で提供されていました。モデルをローンチする手段としては妥当ですが、運用する手段としては制約が多いやり方です。他社の配信設定、他社のキュー、他社のコンテキスト上限、そして毎秒何トークンまで許されるかという他社の考えを、そのまま引き受けることになります。Shannon 3.1は自社GPUクラスタ上で、自分たちが設定する配信スタックの上で動きます。この記事に出てくる主要な数字はすべて、その1つの決定から派生したものです。

	Shannon 3.0	Shannon 3.1
実行場所	サードパーティホスト	自社GPUクラスタ
コンテキストウィンドウ	32,768	196,608
出力ストリーミング	ペーシング／レート制限あり	エンジン全速
重み	ホストの既定	4ビットNVFP4
デコーディング	標準	投機的
推論ループ	思考 → 下書き → レビュー → 改善	変更なし
拒否層	なし	なし
モデルID	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Shannon 3.1が10〜15倍速く感じられる理由

速度の数字は誰もが真っ先に気にするところなので、それがどこから来ているのかを正確に述べておく価値があります。寄与は独立した2つがあり、大きいほうは地味なほうです。

速度ゲートを取り除いた

Shannon 3.0の出力はペーシング層を通っていました。トークンはエンジンを出たあと保持され、スケジュールに従って接続へ解放されていました。これは事故でもバグでもありません。共有の推論ホストがボトルネックになるとき、出力をペーシングすると負荷が均され、長い生成が枠を独占するのを防ぎ、ストリームがバースト的にではなく予測しやすく読みやすいリズムで届くようになります。エンジニアリング上は擁護できる選択でしたが、その代償として、すべてのユーザーがすべての応答で実時間を失っていました。

Shannon 3.1には速度ゲートも表示ペーシングもありません。トークンはエンジンが生成した端からストリームへ書き込まれます。エンジンが速く生成していれば、速く生成しているのが見えます。モデルとあなたのターミナル、チャットウィンドウ、SSEリーダーの間に平滑化バッファはありません。長い回答 — 2,000トークンの分析や生成されたコードのファイル — では、体感できる改善の大半はこれだけで説明できます。

正直に言っておくべき副作用があります。ストリームはバースト的になりました。投機的デコーディング（後述）は受理されたトークンを短いまとまりで出力するため、テキストは1語ずつメトロノームのような等間隔ではなく、目に見える塊で届くことがあります。3.0の滑らかなリズムを前提にUIを作っていても動作は変わりません — トークンの順序と内容は影響を受けません — が、タイプライター風の見え方を好むなら、クライアント側で独自のイージングを入れ直すとよいでしょう。私たちは、ほとんどの人は秒数を取り戻すほうを選ぶと考えています。

エンジン自体も速くなった

ゲートを外しても、その先が速くなければ意味がありません。2つめの寄与は、セクション03で説明する配信スタックです。自社クラスタ内の現行世代・FP4ネイティブなアクセラレータ上で動く4ビットNVFP4重みと投機的デコーディング。この2つが、ゲート撤廃によって露わになる天井そのものを引き上げます。

エンドツーエンドの応答レイテンシの相対値。Shannon Labの社内評価、2026年9月。幅はプロンプト長とティアを反映しています。Liteでの短いプロンプトは低いほう、Proでの長い生成は高いほうに位置します。

03投機的デコーディングが実際にやっていること

「投機的デコーディング推論」はマーケティング用語として使われがちなので、ここでは仕組みを平たく説明します。

言語モデルは通常、1回のフォワードパスで1トークンを生成します。このパスを支配しているのは演算量ではなくメモリ帯域です。何かを計算するには重みを読み出す必要があり、その読み出しには計算そのものよりはるかに長い時間がかかります。GPUは演算ユニットを遊ばせたまま、大半の時間をメモリ待ちに費やします。500トークンを生成するとは、そのレイテンシを逐次的に500回支払うということです。

投機的デコーディングは、この逐次性を攻めます。小さく安価なドラフトモデルが、次に来そうなトークンの短い並び — たとえば4個や8個 — を提案します。次にメインモデルがその並び全体を1回のバッチ化フォワードパスで評価します。高価な部分（重みの読み出し）はどちらにせよ1回だけなので、1トークンを評価する場合とコストはほとんど変わりません。メインモデルが同意した提案トークンはすべて受理され、即座に出力されます。最初に不一致が出た時点で並びは打ち切られ、そこから通常のデコーディングが再開します。

効くのは受理率です。定型文、コードの構造、議論をつなぐ言い回しといった予測しやすいテキストでは、ドラフトモデルの推測がよく当たり、長い並びが一度に確定します。本当に難しいトークンでは受理率が下がり、システムは通常の1トークンずつのデコーディングへ緩やかに退化します。この非対称性こそ望ましいものです。簡単な部分を加速し、難しい部分には手を出しません。

4ビット重みが同じ話に属する理由

ボトルネックがメモリ帯域である以上、重みを小さくすることはメモリ使用量の話にとどまらず、直接的な速度のレバーになります。NVFP4はブロック単位の細かいスケーリングを持つ4ビット浮動小数点フォーマットで、これがあるおかげで、旧来の4ビット整数量子化が精度を失っていた領域でも精度を保てます。フォワードパスごとに読み出すバイト数がおよそ4分の1になれば、メモリ待ち時間も比例して短くなり、196Kウィンドウが要求するロングコンテキストのKVキャッシュにもはるかに大きな余裕が生まれます。

この2つは単に足し算されるのではなく、掛け合わさります。パスあたりのバイト数が減り、出力トークンあたりのパス数も減るからです。だからこそ、ゲートなしの全速ストリーミングが、ペーシングで回収しなければならないコストではなく提供可能なものになります — 3.0のペーシング層がやっていたのは、まさにその回収でした。

04196,608トークン：6倍のウィンドウが可能にすること

Shannon 3.0のウィンドウは32,768トークン。作業セッション分であって、ドキュメント分ではありません。散文でおおよそ70〜80ページ、そこから推論ループが自身の思考に使う分、システムプロンプト分、ここまでの会話分を差し引いた残りです。実際の作業ではこの壁に絶えずぶつかり、その回避策 — チャンク分割、要約、自分の資料に対する検索 — はどれも、保とうとしていたものを劣化させます。196,608トークンは、問題の種類そのものが違います。

具体的には、英文で400〜500ページ程度、あるいはテストとREADMEを含む中規模のコードベース、1つのプロジェクトの1年分の議事録、付属書類をすべて含む契約書一式に相当します。それを1つの会話に保持し、1つの問いで扱え、あなたと資料の間にチャンク分割層は入りません。

• リポジトリ全体への問い。すでに疑っていた3ファイルを貼り付けるのではなく、コードを丸ごと読み込ませて、なぜそのバグが本番に届くのかを尋ねられます。モデルは、あなたが含めようと思いつかなかったファイルを見つけられます。
• 検索なしの長文分析。検索は、モデルが何を見てよいかを決める非可逆な前処理フィルタです。196Kあればそれを省いてモデルに全部読ませられることが多く、正しい箇所が一度も検索されなかったという失敗の類型がまるごと消えます。
• 一貫性を保つ会話。長い作業セッションが、自分の冒頭を黙って落とすことはもうありません。3通目のメッセージで設定した制約が、80通目でもまだ効いています。
• 推論ループのための余地。ループ自身の思考、下書き、レビューもコンテキストを消費します。3.0ではそれらのステップがあなたの資料と乏しい予算を奪い合っていました。3.1では余裕をもって収まります。品質向上とウィンドウ拡大が同時に届いたのは、これも理由の一つです。
• 大きな混在入力。画像、抽出したドキュメントのテキスト、コードを1ターンにまとめて渡せます。どれを入れる余裕があるか選り分ける必要はありません。

あらゆるロングコンテキストモデルに当てはまる、正直な注意点を1つ。私たちのモデルも例外ではありません。大きなウィンドウは容量であって、その全域に均一な注意が向く保証ではありません。構造化は依然として有効です。質問を末尾近くに置くこと、ドキュメントにラベルを付けること、何を探すべきかをモデルに伝えること。これらはいずれも150Kトークンの領域で結果を計測可能なほど改善しますが、5Kではそうではありません。

05LiteとPro：shannon-3.1とshannon-3.1-pro

2つのティアの違いは推論ループをどこまで実行するかであり、選ぶうえで意味を持つ違いはそれだけです。

	shannon-3.1（Lite）	shannon-3.1-pro（Pro）
推論	シングルパス	完全ループ＋知識収集
自己レビュー	なし	あり
コンテキストウィンドウ	196,608	196,608
ストリーミング	全速、ゲートなし	全速、ゲートなし
画像認識と文書	対応	対応
画像生成ツール	対応	対応
適した用途	大半の作業、大量処理	難問、初稿では不十分な場合

既定ではLiteを使ってください。優れた推論モデルの1パスで実際のリクエストの大半は処理できますし、3.1ではループの待ち時間を意識しない程度に速くなっています。Proに手を伸ばすのは、最初の回答がたいてい示唆に富む形で間違っているような問いのときです。アーキテクチャのトレードオフ、敵対的分析、有能な同僚に一晩考えてもらいたいような案件。Proの自己レビューは飾りではありません。あなたが気づく前に、モデルが自分の誤りを見つける工程です。

06知能32%向上という数字の読み方

Shannon Lab自身の評価では、Shannon 3.1はShannon 3.0に対して知能32%向上という結果です。それが何であり、何でないかをはっきりさせておきます。

これは私たちの数字であり、社内の評価スイートから得たもので、こうしたモデルに実際に持ち込まれる作業を代表すると私たちが考えるタスク上で測定されています。第三者ベンチマークではありませんし、単一の社内集計値を軸にリーダーボード表を組み立てたり、ベンチマーク別の内訳を公開したりはしません。内訳を出すことは、社内スイートが持ち得ない水準の外部比較可能性を示唆してしまうからです。

そのうえで申し上げられるのは、向上がどこから来ているかです。その部分は謎めいてはいません。コンテキストウィンドウが大きくなれば、モデルが推論に入る前に捨てなければならない資料が減ります。長いセッションで賢くないように見える現象の多くは、実際には健忘です。自分たちで管理する配信スタックなら、モデルはホストの既定値ではなく、意図した設定で動きます。そして設計上は変わっていない推論ループが、あなたの入力と共有する32Kの天井に押し込まれるのではなく、ウィンドウの中で実際に走るだけの余地を得ました。

07画像認識、文書、そして画像生成

Shannon 3.1は画像と文書を読みます。スクリーンショット、図表、写真、スキャンしたページ、PDF、テキスト文書を会話に投入し、他のすべてと並べて推論させられます。196Kウィンドウと組み合わせることで、文書丸ごとのワークフローが実用になります。長いレポートとそのグラフを1ターンで扱え、どのページをモデルに見せてよいかを事前に決める必要はありません。

画像の生成と編集は、チャット内でツールとして利用できます。画像を頼めばモデルが同じ会話の中でインラインにツールを呼び出し、それまでに話した文脈をすべて踏まえます。編集も同じやり方です。画像を渡し、変更内容を説明してください。切り替えるべき別モードも、覚えるべき別インターフェースもありません。

08APIからShannon 3.1を呼び出す

Shannon 3.1は3つのAPI方言すべてで利用でき、いずれもストリーミングに対応しています。同じモデルに対してリクエストの形が3種類あるので、すでに使っているSDKに合うものを選んでください。

エンドポイント	形式	ストリーミング
/v1/chat/completions	OpenAI互換	対応
/v1/messages	Anthropic互換	対応
/v1/responses	Responses	対応

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

完全な推論ループを走らせるには、"shannon-3.1"を"shannon-3.1-pro"に差し替えてください。すでにshannon-3を呼んでいるなら、移行はモデルIDの変更だけです。リクエストとレスポンスの形は変わっておらず、既存のストリーミングクライアントはそのまま動きます。想定すべき唯一の挙動差は、セクション02で述べたバースト的なストリームです。トークンも順序も同じで、より早く、より不均等な塊で届きます。

完全なパラメータリファレンス、認証、エラーの意味論、対話型プレイグラウンドはAPIドキュメントにあります。他のモデルカードや技術記事はShannon researchにまとめてあります。

09引き続き無検閲、その点は変わらない

Shannon 3.1には拒否層がなく、出力へのコンテンツフィルタリングもありません。これはShannonシリーズの他のモデルと同じ姿勢で、自社クラスタへの移行でも変わりませんでした。むしろ配信スタックを自分たちで管理するほうが保証しやすくなります。モデルとあなたの間に、独自ポリシーを持つ中間ホストが挟まらないからです。

出力経路をまるごと変えたリリースについて、当然気になる点なので、はっきり述べておきます。ペーシング層を取り除いたことは、その場所にモデレーション層を差し込むことを意味しません。ストリームを検査したり書き換えたり止めたりするものは何もありません。モデルが生成したものが、そのまま届きます。私たちが知る限り、Shannon 3.1はこの規模のコンテキストウィンドウを持つ無検閲AIモデルとして最速です。そしてこの2つの性質は関連しています。どちらも、コンプライアンスの形に整えられた計算資源を他社から借りるのではなく、自社のインフラを運用していることから来ているからです。

無検閲であることは、無責任であることと同じではありません。利用は当社の責任ある利用ポリシーに従うものとし、難しい題材にも向き合うモデルに伴う義務は、あなた自身が責任をもってそれに向き合うことです。

10比較は自分でやってみてください

ここに書いた主張はどれも2分ほどで確認できます。信じてもらうより、確かめてもらいたいと思っています。

1. 実際にやっている仕事からプロンプトを1つ選びます。長いほうが良いです。ウィンドウとストリーミングの両方を試せます。
2. shannon-3で走らせます。最初のトークンまでの時間と、回答が完了するまでの時間を記録します。
3. 同一のプロンプトをshannon-3.1で走らせます。同じ2つの数字を記録します。
4. それから時計を無視して両方の回答を読み、どちらが欲しかったものかを判断します。

速度差はすぐに、はっきり分かります。じっくり向き合う価値があるのは品質差のほうです。それが最もはっきり表れるのは長い入力で、3.0はあなたが思っていたより少ない資料で静かに作業していたのです。

11よくある質問

---

本記事の性能および知能に関する数値は、Shannon Labが2026年9月に社内評価で自ら測定したものであり、第三者ベンチマークの結果ではなく製品仕様上の数値として提示しています。コンテキストウィンドウ、モデルID、APIの提供状況は製品仕様です。Shannon AIはShannon Lab LLC（米国ニューメキシコ州）が運営しています。関連記事：Shannon 3 · Shannon research索引 · APIドキュメント。