L2のシーケンサーが止まったときのサービス継続｜機能ごとの対応と復旧判断

2026年7月7日、Optimismで障害が起きました。ブロックは作られていたのに、ネットワークへ通常どおり配られなかったのです。外部のノードとRPC事業者は、約22分間（17:59〜18:22 UTC）、古い状態を返し続けました。

公式の障害報告によると、原因は定例のインフラ更新でした。Sequencer（L2で取引を並べてブロックを作る役）が頼る通信経路が、エラーを出さずに切れていたのです。その経路の事業者に送られた取引は、取り込まれませんでした（Optimism Status: Blocks produced not being distributed）。

この間、外部のノードやRPC事業者を通して状態を見ていた利用者は、古い状態を見ていたことになります。ブロック自体は作られていました。それでも、利用者から見れば復旧していなかったのです。

L2（Layer 2）を本番サービスに組み込むなら、こうした停止のときに、どこまで動かしてどこで止めるかを先に決めておく必要があります。短く言えば、次の2つです。

• 信頼できる確定済みの状態を基準にして、残高の表示などの読み取りは続け、送金や注文のような状態を変える操作は止める。
• L1から取引を直接押し込む「強制経路」は、使えるチェーンと操作に限って用意し、待ち時間と資産を引き出すまでの条件を別に確かめる。

以下では、事業責任者・設計者・運用担当が決めることを、止まった場所の見分け方から、復旧の判断まで順に見ていきます。L2の種類と選び方の全体像はL2（Layer 2）完全マップ2026で扱っています。

止まったのはどこか、どのブロックを正とするか

「画面から取引を送れない」という症状は、1つのRPC、ウォレットの接続、フロントエンドが落ちたときにも起きます。そのため、この症状だけでは、Sequencerの停止とは限りません。

逆に、Sequencerがブロックを作り続けていても、L1へのデータ投稿が止まることがあります。このとき、仮の最新（unsafe head）は進みますが、L1に記録済み（safe head）と確定済み（finalized head）は進みません。

OP Stackの公式の障害資料も、この2つを別の障害として定義しています。Sequencer自体の停止と、受け付けた取引をL1へ投稿できない停止です（Optimism Documentation: Sequencer outages）。

見えている症状から、疑う場所とすぐにすることは次のとおりです。

それぞれの症状で、サービスがどのブロックを参照するかは、後半の「実装する人向けの詳細」にまとめました。

冒頭のOptimismの例が示すのは、「Sequencerのプロセスが起動した」だけで復旧と判断してはいけない、ということです。利用者が参照するRPCやインデクサー（チェーンのデータを集めて検索できるようにする仕組み）の遅れを見落とします。

機能ごとに、止めるか続けるかを決める

「動いているか」の目標は、チェーン全体ではなく、利用者の操作ごとに置きます。残高の表示、注文の受付、送金、出金、通知、サポートでは、どこまで古くてよいかも、誤ったときの影響も違うからです。

停止中も書き込みを受け付け続ける作りは、止まらないように見えます。ところが、順序・nonce・価格・残高の前提が変わっていると、復旧後に二重実行や、取り消せない誤処理を生みます。

たとえば、残高は見せ続け、送金は止めます。機能ごとには次のように決めます。

画面には、利用者が誤解しないための表示を出します。たとえば、残高なら基準のブロックと更新が止まった時刻を出します。新規の注文なら、まだ送っておらず残高も確保していないことを伝えます。機能ごとの表示の中身は後半にまとめました。

サービスレベル目標（SLO）は、たとえば次のように決めます。

• 残高閲覧は、15分以内のsafeブロックで続ける
• 状態変更は、unsafe headが3ブロック止まった時点で止める
• L1の強制経路は、資産の退避に必要な操作だけ

具体的な時間やブロック数は、対象のL2のブロック間隔、sequencing window（取引を取り込む期限）、運用の契約から決めます。ほかのチェーンの値をそのまま使ってはいけません。

停止中の動きを、5つの段階で決める

段階ごとに、何を止め、何を突き合わせるかを決めておきます。

1. 通常（normal）：unsafe、safe、finalizedの差を監視します。送信時に使ったRPC、chain ID、nonce、tx hash（取引の識別子）を記録します。
2. 異常の疑い（suspected）：1つのRPCだけの誤検知を除くため、突き合わせます。独立したRPC、Sequencerの接続先、L1へのバッチ投稿、公式のステータスページです。自動の再送はしません。
3. 縮退（degraded）：読み取りの基準をsafeブロックに固定し、状態変更を止めます。受け付けた業務の要求は保留します。保留には、オンチェーンの取引とは別の冪等性キー（同じ要求を二重に処理しないための識別子）を使います。
4. 復旧中（recovery）：Sequencerが再開しても、すぐに通常運転へ戻しません。unsafeとsafeが追いつくこと、保留中の取引、nonce、インデクサーの欠け、外部連携を確かめます。
5. 通常への復帰：再開の条件を満たした時刻、判断した人、基準のブロックを記録します。機能ごとに段階的に戻します。

停止している間に、nonceや価格の条件が変わることがあります。そこへ、停止前に署名された取引を後から流すと、利用者の意図に反することがあります。そのため、保留の待ち行列には、署名済みの生の取引（raw transaction）をそのまま保存しない方が安全です。

そこで、業務の要求、署名の状態、送信（broadcast）の状態を分けて持ちます。再開時に条件を評価し直し、必要なら署名し直してもらいます。

L1からの強制経路は、どこまで頼れるか

強制経路が実際にどう動くかを、OP StackとArbitrumで見てみます。

OP Stackの場合

OP Stackでは、利用者がL1のOptimismPortalへdeposit transactionを送ると、Sequencerを迂回できます。

ただし公式資料によると、停止が30分から12時間のとき、送った取引はすぐにはL2へ取り込まれません。Sequencerが再開するか、12時間のsequencing windowが満了するまで待ちます。窓が満了すると、ノードはL1の入力からブロックを決定的に導き出し（derivation）、強制取引を取り込みます（Optimism Documentation: Forced Transaction、OP Stack Specification: Derivation）。

つまり、L1へ送れた時点を、業務の完了にしてはいけません。手順書には、次のことを書き込みます。

• 対象チェーン固有のsequencer_window
• L1のfinality（確定）
• 出金の証明と異議申立期間

Arbitrumの場合

Arbitrum Nitroでは、L1のDelayed Inboxへメッセージを入れます。決まった遅延の後は、誰でも強制的に取り込ませる（force inclusion）ことができます。Nitro whitepaperは、長時間の停止や検閲のときに、この経路がチェーンの進行と取引の取り込みを支えると説明しています（Arbitrum Nitro whitepaper, §3.2）。

公式ドキュメントでは、この遅延は既定で24時間（delayBlocks）です。遅延バッファ（Censorship Timeout）を有効にしたチェーンでは、Sequencerの遅れの実績に応じて、もっと短くなり得るとされています（Arbitrum Docs: Sequencer）。

どちらも、何時間も待つことがあります。強制経路は、限られた場面で使う非常口であり、通常の即時のSequencer経路と同じ使い勝手ではありません。また、L2からL1への資産の退出は、outboxの証明や異議申立期間を含む別の段階です。「Delayed Inboxへ送れた」だけで完了扱いにはしません。

この経路を案内する相手は、次のことを扱える利用者と操作に限ります。L1のガス、待ち時間、コントラクトアドレス、calldata（コントラクトへ渡す入力データ）、再試行、L2での実行の成否です。

強制経路を用意するなら

次のものがそろっている必要があります。

• フロントエンドが落ちていても使える、独立した手順書
• 公式のコントラクトアドレスの確認と、チェーンの取り違えの防止
• L1の取引hashと、L2での実行結果の対応表

「分散型だから止まらない」と説明して済ませてはいけません。誰が、どの画面またはスクリプトを使い、費用を払い、完了を確かめるのか。そこまでテストします。

データ可用性の障害で、最新の状態そのものを作り直せない場合もあります。StarkExのように、凍結後の退出（escape）に最新状態のMerkle証明が必要な方式もあります。これらはロールアップのデータ可用性障害｜状態復元と資産退出の設計で扱っています。OP StackとArbitrumの仕組みそのものはOP Stack徹底解説とArbitrum徹底解説を参照してください。

予備の経路は、同じ理由で一緒に止まらないものを選ぶ

RPCのURLを2本並べても、同時に止まることがあります。同じ事業者、同じクラウド、同じL1の接続先、同じSequencerの配信を使っている場合です。

読み取りの経路は、事業者とリージョンを分けます。少なくとも1系統は、自社で動かすか、独立して運用するノードで確かめます。書き込みは、複数の接続先へ同時に送りません。取引のhashとnonceを確かめてから切り替えます。

• 観測：unsafe/safe/finalized head、ブロック間隔、L1へのバッチ投稿、Sequencerの接続先、RPCのエラー率を、別々に監視します。
• 業務の状態：要求、署名、送信、取り込み、safe、finalizedを、1つの「完了」にまとめてしまいません。
• 読み取り：インデクサーが最後に処理したブロックを、APIの応答に含めます。チェーンの先頭との差を監視し、欠けた区間を取り直せるよう、処理済みのブロックと再同期の手順を持っておきます。
• 緊急権限：状態変更の停止、L1経路の有効化、通常への復帰を、別々の権限にします。1人の判断で全操作を再開できないようにします。

復旧の直後にも注意が要ります。2023年12月15日のArbitrum Oneでは、inscription（データを書き込むだけの取引）の急増をきっかけに、Sequencerが取引を正常に中継できなくなりました。復旧後も、積み上がった未処理分でガス価格の上昇が続きました（Arbitrum Status: Sequencer & Feed Issues）。復旧直後の滞留と料金の上昇も、障害の場面に含めておく必要があります。

通常に戻してよいかを、どう判断するか

判断の目安は「起動した」ではありません。次の5つがそろったかです。

障害訓練では、Sequencerの接続先を遮断するだけでは足りません。次の5つを別々に再現します。

1. RPCだけ停止
2. unsafe headの停止
3. unsafeは進むがsafeが停止
4. 再開後に未処理が積み上がる
5. 強制取引がL2でrevert（失敗して取り消し）

合格の条件は次の4つです。誤った完了通知が0件。二重送信が0件。保留した要求をすべて説明できる。復帰を判断した記録が残っている。

採用前に確かめる10項目

強制経路がないL2や、業務が数分の停止も許せない場合は、アプリ側の工夫だけでは要件を満たせません。

別のチェーンへのリアルタイム切り替えを足したくなりますが、複数のチェーンに二重に書き込むと、正しい状態の元が増え、復旧が難しくなります。そのため安易には足しません。見直すのは、L2の選び方、業務の確定をどの時点に置くか、オフチェーンで受け付けられるかです。

停止中や障害時の出金を利用者にどう見せるかはL2出金の待ち時間とUX設計で扱っています。L1からL2へ移す前にこうした障害を演習する計画はL1からL2へのアプリ移行をご覧ください。

実装する人向けの詳細

症状ごとに参照するブロック

• 自社RPCだけ応答しない：独立した複数RPCで同一ブロックを突き合わせる
• unsafe headが進まない：最後のsafeまたはfinalizedのブロック
• unsafeだけ進みsafeが止まる：safe headを会計・引き渡しの基準にする
• Sequencerの応答と配信が食い違う：複数ノードのsafe head

機能ごとに必要な表示

• 残高・履歴閲覧：基準ブロックと更新が止まった時刻
• 新規注文・送金：未送信であり残高を確保しないこと
• 送信済みで未確定の取引：tx hash、送信経路、確定の度合い
• 出金・緊急解除：L1費用、待機時間、対象操作
• 通知・会計連携：遅延中であること

業務の状態名

requested、signed、broadcast、included、safe、finalizedを別々の状態として持ち、1つの「完了」へまとめません。

XTELAができること

XTELAは、L2を組み込むときの信頼の境界と状態の移り変わり、RPC・インデクサーの構成、停止時の機能別の縮退、監視と復旧の手順書を設計し、強制経路を実際に通すPoCまで行います。貴社のサービスが「どこまで動き、どこで止まるか」を障害の前に決めておくのが私たちの仕事です。L2の障害対策について相談する

主要参考資料

• Optimism Documentation: Sequencer outages
• Optimism Documentation: Forced Transaction（2026年9月24日確認）
• OP Stack Specification: Derivation
• Optimism Documentation: Triggering OP Stack transactions from Ethereum
• Arbitrum Nitro: A Second-Generation Optimistic Rollup
• Arbitrum Docs: Sequencer（2026年9月24日確認）
• Optimism incident: Blocks produced not being distributed to the network（2026年7月7日の障害、2026年9月24日確認）
• Arbitrum incident: Sequencer & Feed Issues（2023年12月15日）

資料の確認日

強制取引の待機条件（OP Stack・Arbitrum）と2026年7月7日のOptimismの障害報告は、2026年9月24日に確認し直しました。そのほかの資料は2026年8月13日に確認しています。待機時間、コントラクトアドレス、Sequencerの構成は、チェーンとアップグレードで変わります。導入・訓練のときに、対象ネットワークの公式仕様と実際の値を確かめてください。