Solanaは、ブロック生成の基準となる目標スロット時間を300ミリ秒から250ミリ秒へ短縮しました。 これはネットワーク全体の取引処理容量を増やす変更ではなく、ブロックチェーンの状態をより短い間隔で更新するための改善です。 JupiterやRaydiumなどのDEXでは価格・残高・取引結果を早く確認しやすくなる一方、混雑時の約定やスリッページが自動的に解消されるわけではありません。
Solanaのスロット時間が250ミリ秒に短縮
CoinDeskは2026年9月18日、Solanaの目標スロット時間が300ミリ秒から250ミリ秒へ短縮されたと報じました。短縮率は約16.7％で、従来は1秒あたり約3.3スロットだったところ、理論上は4スロットを進める設計になります。
スロットとは、あらかじめ選ばれたバリデーターがブロックを生成できる短い時間枠です。一般的な利用者にとっては、ウォレットやDEXの画面に新しいオンチェーン状態が反映される最小単位の一つと考えると分かりやすいでしょう。
電車に例えるなら、列車の発車間隔を30秒から25秒へ縮めたような変更です。ただし、今回の設計では1本の列車に載せられる人数も同じ割合で減らします。そのため列車は頻繁に来るものの、1時間に運べる総人数は大きく変わりません。
Solana FoundationのSIMD-0525では、400ミリ秒から350、300、250、最終的に200ミリ秒へ段階的に短縮する構想が示されています。段階導入により、AgaveやFiredancerなど複数のバリデータークライアントが、ネットワーク運用上の問題を確認しながら移行できる設計です。
約17％高速化しても取引容量が増えない理由
今回の重要な点は、「ブロックの更新頻度」と「単位時間あたりの処理容量」が別物だということです。
SIMD-0525は、スロット時間を短縮する際、各スロットで許可する計算量やデータ量も時間比率に応じて縮小するよう定めています。スロット数が増えても、1スロットあたりに収容できる処理が減るため、1秒あたりの計算予算はおおむね維持されます。
例えば、SIMD-0525が示す100M Compute Units基準との組み合わせ例では、300ミリ秒段階の最大ブロック計算量は75M CU、250ミリ秒段階では62.5M CUです。75M CUを約3.33回処理する場合も、62.5M CUを4回処理する場合も、理論上の単位時間当たり計算量は約250M CUです。
したがって、Jupiterでスワップを送信できる件数や、Raydiumの流動性プールが処理できる取引量が、この変更だけで約17％増えるわけではありません。高需要時の競争、優先手数料、書き込みアカウントの競合、バリデーターの実装状況といった要素は引き続き約定品質を左右します。
「SolanaのTPSがそのまま約17％上がった」と解釈するのは不正確です。今回の主目的は容量拡大ではなく、より細かい時間単位でネットワーク状態を進めることにあります。
JupiterやRaydiumの利用者に期待される変化
DEX利用者が体感しやすい可能性があるのは、注文送信後の状態更新です。Jupiterで複数の流動性ソースを経由するスワップを行った場合や、Raydiumでトークン交換を行った場合、ウォレットやフロントエンドはRPCを通じて最新スロット、残高、取引ステータスを確認します。スロット間隔が短くなれば、こうした確認機会も細かくなります。
また、Pyth Networkなどのオラクル価格を参照するDeFiアプリでは、オンチェーン上の時間をより細かな粒度で扱えることが重要です。Driftのようなデリバティブプロトコルや、自動的に価格を調整するAMMでは、数百ミリ秒の差でも、参照価格と実際の市場状態のずれが取引判定に影響する場合があります。
ただし、利用者が見る待ち時間はスロット時間だけでは決まりません。RPC事業者からフロントエンドまでの通信、トランザクションの転送経路、優先手数料、混雑、ウォレット側の確認方法などが加わります。250ミリ秒化は基盤側の更新間隔を改善しますが、すべてのスワップが一律に50ミリ秒早く完了するという保証ではありません。
利用者は従来どおり、Jupiterなどで提示される最小受取額、価格影響、スリッページ設定、優先手数料を確認すべきです。高速化を理由に許容スリッページを広げる必要はありません。
バリデーターの取引順序決定時間も短くなる
Solanaでは、同じリーダーが連続する4スロットを担当します。目標スロット時間が300ミリ秒だった段階では、1人のリーダーが担当する名目上の時間枠は1.2秒でした。250ミリ秒では1秒になります。
この短縮には市場構造上の意味があります。リーダーは受け取ったトランザクションを選択し、順序を決めてブロックへ収録します。同じリーダーが継続して順序を決められる時間が短くなれば、次のリーダーへ権限が移るまでの待ち時間も短縮されます。
Jupiter経由の裁定取引、RaydiumのAMM、Driftのポジション調整など、価格変動に敏感な処理では、古い状態が長く続く時間を抑えられる可能性があります。一方で、順序決定そのものがなくなるわけではなく、MEVや優先手数料に関する課題が解消されるわけでもありません。
Solana公式の分析も、短いスロットは不利な実行方針が連続する時間を圧縮できる一方、特定のリーダー構成や実行方針を完全に排除するものではないと説明しています。
エポック短縮とオフライン署名への注意
Solanaのエポックは432,000スロットで構成されます。スロット数を変えずに1スロットを250ミリ秒へ短縮するため、SIMD-0525上の名目エポック時間は約30時間になります。300ミリ秒段階の約36時間から短くなる計算です。
この変化は、バリデーターのリーダースケジュールや運用手順だけでなく、スロット数を時間の代わりに使っているアプリにも影響します。開発者が「一定スロット後」を固定的な時間として扱っている場合、現実の経過時間が従来より短くなります。
トランザクションにはrecent blockhashが含まれ、ブロックハッシュの有効性はチェーンの進行に伴って失われます。そのため、ハードウェアウォレット、マルチシグ、組織内承認などで署名から送信まで時間がかかる運用は、通常のトランザクションが期限切れにならないか再検証が必要です。
Squadsのようなマルチシグを利用するプロジェクトや、取引所の出金処理を構築する事業者は、スロット時間を定数として埋め込まず、RPCから取得した状態に基づいて有効性を判断することが望まれます。長時間の承認が必要な処理では、通常のrecent blockhashを前提とする設計と、Solanaのdurable nonceを使う設計を区別する必要があります。
DEX・DeFi開発者が確認すべき実務項目
第一に、SDKやアプリ内で400ミリ秒、300ミリ秒といった値を固定していないか確認します。SIMD-0525は、実行中のクラスターが短いスロットを採用していても、古い既定値を表す定数が残る可能性を指摘しています。JupiterやRaydiumを組み込むアプリでも、タイムアウト、再送間隔、キャッシュ更新を固定秒数とスロット数のどちらで管理しているかを点検すべきです。
第二に、processed、confirmed、finalizedを同じ意味で扱わないことです。画面への速報表示にはprocessedを利用しても、入出金や担保管理では必要なcommitmentレベルを別途定める必要があります。スロットが短くなっても、各レベルが示す安全性の違いは残ります。
第三に、実測を重視します。送信から最初の観測までの時間、confirmed到達時間、期限切れ率、再送率、スワップ失敗率を変更前後で比較します。Pyth価格を使う場合は、価格更新のスロット差や信頼区間も監視対象です。
第四に、200ミリ秒化を既定路線として本番設定へ先取りしないことです。SIMD-0525には200ミリ秒段階も記載されていますが、CoinDeskの報道時点でメインネット導入日は示されていません。ネットワークの実際の設定と公式発表を確認しながら対応する必要があります。
まとめ
Solanaの250ミリ秒スロットは、ブロックチェーンの時計を約17％細かく進める変更です。ウォレット、Jupiter、Raydium、Driftなどは新しい状態をより早い間隔で観測でき、バリデーター1人が連続して取引順序を決める時間も短くなります。
一方、各スロットの計算量とデータ上限も比例して縮小されるため、ネットワーク全体の取引容量が同じ割合で増えるわけではありません。混雑、優先手数料、スリッページ、RPC遅延といった実務上の課題も残ります。
利用者は表示の速さと約定の安全性を分けて考え、取引条件を確認することが重要です。開発者とバリデーターは、固定されたスロット時間、署名期限、再送処理、エポック依存ロジックを点検し、将来の200ミリ秒化にも段階的に備える必要があります。
