- Bitcoin Coreを自分で管理していない：更新作業は不要です。BTCの移動や秘密鍵・復元フレーズの入力もしません。ここまで確認すれば、残りは読まなくても構いません。
- 自分で管理している：
bitcoin-cli getnetworkinfoまたはGUIの「Bitcoin Coreについて」で現行版を確認し、「29.x EOL後はどのバージョンを選ぶべきか」へ進みます。 - 非Linux、32ビット、blocksがFAT32：脆弱性の該当条件と残存リスクを先に確認します。
- 署名機器・RPC連携がある：更新手順に加え、PSBT・RPCの互換性節まで回帰試験します。
Bitcoin Core 32.1は2026年10月27日公開のノードソフトウェア更新で、チェーン分岐や「32.1対応コイン」への交換ではありません。主対象はノード運用者です。29.5、30.4、31.2、32.1には3件の修正が入りましたが、29.xはEOLのため保守対象系列への移行が必要です。
本稿は価格や売買ではなく、更新対象の判定、修正版の選択、安全な実施に絞ったガイドです。編集部検証メモ：2026年11月2日にBitcoin Core公式の32.1リリースノート、脆弱性開示、ライフサイクル、配布ページを照合しました。記載コマンドは代表例を資料上で確認したもので、特定の実機構成による動作保証ではありません。
Bitcoin Core 32.1で何が起きたのか
32.1は2026年10月27日に正式公開
Bitcoin Core 32.1は2026年10月27日に正式公開されました。Bitcoin Coreは、Bitcoinネットワークへ接続し、ブロックや取引を検証し、必要に応じてウォレット機能も提供するソフトウェアです。取引所のアプリや一般的なスマートフォンウォレットを使っているだけなら、端末内でBitcoin Coreが動いているとは限りません。
32.1は新しいメジャー系列に相当する更新です。公式リリースノートには、アップグレード方法、対応環境、P2P通信、ウォレット、RPC、索引などの変更がまとめられています。運用者は「最新版だから入れる」という判断だけでなく、自分が使う機能に影響する変更を確認してから更新します。
32.0ではなく32.1が新メジャー版になった理由
32.0は開発上のタグが付けられましたが、公開直前に問題が確認され、一般向けの正式配布には至りませんでした。そのため利用者向けに配布された新メジャー版は32.1です。「32.0を飛ばしたから、32.0を先に導入する必要がある」という意味ではありません。公式配布ページから32.1または自分が選んだ保守版を取得します。
GitHub上のタグや第三者サイトのミラーを見つけても、それだけで運用環境へ入れるべき配布物とは判断できません。公式GitHubの32.1リリースも、バイナリは公式配布先から取得するよう案内しています。リリース番号の経緯と、実際の配布経路を分けて理解することが重要です。
チェーン分岐やBTCの移行を伴う更新ではない
32.1はBitcoinのコンセンサス規則を変更して別のチェーンへ分岐させる更新ではありません。保有するBTC、秘密鍵、アドレス、残高を「32.1対応コイン」へ交換する作業もありません。ウォレットデータを新しい資産へ変換するのではなく、ノードソフトウェアを更新する作業です。
ハードフォークとソフトフォークの違いを知っている人ほど、メジャーバージョン更新をチェーン分岐と結び付けがちです。しかし、ソフトウェアのメジャー番号とコンセンサス上のフォークは別の概念です。今回の対応を理由に送金を急ぐ必要はありません。
一般保有者とノード運用者で必要な対応は異なる
一般のウォレット・取引所利用者はBTCを移動しない
自分でBitcoin Coreを運用していない一般保有者は、32.1の公開だけを理由にBTCを別アドレスへ動かす必要はありません。利用中のウォレットや取引所がバックエンドでBitcoin Coreを使っている場合、その更新は通常、サービス運営者の作業です。利用者側で秘密鍵を差し替えたり、新しいトークンを受け取ったりするものではありません。
まず確認するのは「自分がBitcoin Coreのプロセス、データディレクトリ、設定ファイルを管理しているか」です。管理していなければ、この記事の更新手順を端末で無理に実行しないでください。サービス側からメンテナンス案内があった場合は、公式アプリやブックマークした公式サイトで内容を確かめます。
フルノード運用者は稼働バージョンと環境を確認する
まなぶ「クリプ先生、BTCを持っている人は全員が32.1をインストールするんですか？」
クリプ「いや、主な対象は自分でBitcoin Coreを動かしている運用者なんだ。保有しているだけなら、資産移動ではなく利用サービスの公式案内を確認すればよいよ。」
ノード運用者は、現在のバージョン、OS、CPUアーキテクチャ、データディレクトリの保存先、外部連携を一覧にします。GUIの「Bitcoin Coreについて」や実行ファイルのバージョン表示、運用監視の記録など、実際の稼働情報を使います。古いインストーラーが残っているだけでは稼働版の証拠になりません。
次に、ノードが個人の検証用か、決済受付、取引所、ウォレットバックエンド、監視、研究用途かを確認します。停止可能時間、復旧目標、外部署名機器やRPCクライアントへの依存によって、更新前テストの深さが変わります。高可用性を求める環境では、単一ノードをその場で置き換えるより、検証環境で同じ構成を再現してから段階的に更新します。
送金や秘密鍵入力を促す偽更新案内に注意する
「脆弱性修正のため資産を退避」「32.1へ同期するため秘密鍵を入力」「サポートが代理更新」といった案内は、今回の正規手順ではありません。Bitcoin Coreのバイナリ更新に、第三者へ秘密鍵や復元フレーズを渡す工程はありません。SNSの広告、検索結果の偽サイト、個別メッセージのリンクから配布物を取らないでください。
更新の緊急性と資産移動の緊急性は別です。ノードの停止リスクを下げるため早めに修正版を検討しても、慌ててBTCを動かす必要はありません。秘密情報を求められたら作業を止め、公式ドメインと公式リリース情報を自分で開き直します。
32.1で修正された3件の脆弱性
今回の3件は秘密鍵の窃取ではなく、条件次第でノード停止を招く問題です。まず次表で自分の環境を判定し、該当する個別説明だけを読みます。
| CVE | 影響する環境・系列 | 想定結果 | 深刻度 | 修正版 | 更新後も残る条件 |
|---|---|---|---|---|---|
| CVE-2026-117349 | 外部ピアと接続する旧版ノード | 送信キュー増大によるメモリ枯渇・停止 | Medium | 29.5／30.4／31.2／32.1 | 本稿の調査資料では特記なし |
| CVE-2026-117350 | Windows、macOS、BSDなど非Linuxの旧版 | TCP緊急データによるメモリ枯渇・クラッシュ | Medium | 29.5／30.4／31.2／32.1 | 本稿の調査資料では特記なし |
| CVE-2026-117346 | 巨大なundoファイルを扱う環境 | 位置値のあふれによる停止 | Low | 64ビット版は各修正版 | 32ビット環境、blocksがFAT32 |
CVE-2026-117349：旧式ピアによる送信キューの増大
CVE-2026-117349は、古いping仕様を使うように見せかけた低速な接続ピアによって、送信キューが制限なく増え得る問題です。相手がデータを十分に受け取らない状態で、ノード側に送信待ちデータが積み上がり、時間とともにメモリを消費します。公式の深刻度はMediumです。
ポイントは、瞬時に全ノードの資産が失われる問題ではなく、悪意あるピアが接続を維持することでメモリ枯渇と停止を狙える点です。修正は29.5、30.4、31.2、32.1へ入っています。ファイアウォールだけで安全と決め付けず、外部ピアを受け入れるか、アウトバウンド接続だけか、監視でメモリ増加を検知できるかも合わせて見ます。
CVE-2026-117350：非Linux環境でのTCP緊急データによるメモリ枯渇
CVE-2026-117350は、非Linux環境で使われるselectベースの処理経路に関係します。悪意ある接続ピアがTCPの緊急データを利用すると、メモリが制限なく増え、Windows、macOS、BSD上のノードをクラッシュさせ得ました。こちらも公式の深刻度はMediumです。
Linuxではないという条件が重要です。「Bitcoin Coreの脆弱性だから全OSで同じ挙動」と単純化してはいけません。一方、Linux環境なら今回の3件すべてを無視できるという意味でもありません。CVE-2026-117349や後述のundoファイル問題は別条件だからです。OSとCVEを対応付けて管理します。
CVE-2026-117346：極端な条件下で起きるundo位置値のあふれ
CVE-2026-117346は、非常に大きなundoファイルの位置を扱う値があふれ、ノード停止につながり得る問題です。undoデータは、チェーン再編成時などにブロック適用を巻き戻すために必要な情報です。公式評価はLowで、悪用は困難とされていますが、保存環境によって残存リスクが異なります。
まなぶ「undoファイルって、ウォレットのバックアップと同じものですか？」
クリプ「別物だよ。ブロックの適用を巻き戻すためのノード内部データで、秘密鍵を保存するwalletバックアップの代わりにはならないんだ。」
64ビット環境向けの問題は修正されましたが、32ビット環境と、blocksディレクトリをFAT32へ置く構成では影響が残ります。つまり「32.1へ更新したから構成に関係なく解決」とは言えません。該当環境では、64ビット対応OSと、より大きなファイルを安全に扱えるファイルシステムへの移行を検討します。
29.x EOL後はどのバージョンを選ぶべきか
3件の修正は複数系列へバックポートされました。したがって、セキュリティ修正を得る方法は32.1だけではありません。ただし、修正を含むことと、今後も保守されることは別です。系列の保守期限、互換性、移行工数を分けて判断します。
| 現在の方針 | 候補 | 確認点 |
|---|---|---|
| 新メジャー系列へ移行 | 32.1 | PSBT v2、RPC、ウォレット、索引など32系の変更を試験 |
| 31系を当面維持 | 31.2 | 修正を取得し、32系への移行時期を別途計画 |
| 30系を当面維持 | 30.4 | 修正を取得し、保守期限を監視 |
| 29系を使用中 | 29.5は短期の修正版 | 29.xはEOL。保守対象系列への移行計画が必要 |
32.1へ上げる場合の判断基準
32.1を選ぶ利点は、新系列の修正と機能をまとめて取り込めることです。一方で、PSBTの既定版、RPCの入力検証、walletやindexの挙動など、30.xや31.xからの差分を確認する必要があります。単独の個人ノードで外部連携が少ない場合と、業務システムがRPCへ依存する場合では検証項目が大きく違います。
判断材料は「最新版か」だけではありません。公式に試験されたOS範囲へ入るか、署名機器がPSBT v2へ対応するか、停止時間を確保できるか、問題時にバックアップから復旧できるかを確認します。32.1の変更に対応できるなら有力な移行先ですが、すべての運用者へ無条件に同じ日時で導入するよう勧めるものではありません。
30.4・31.2で現行系列を維持する選択肢
30.xまたは31.xを運用し、32系との互換性検証が終わっていない場合、30.4または31.2で3件の修正を受け取る選択肢があります。これは「更新しない」のではなく、現行メジャー系列の修正版へ上げる判断です。公式配布先には各系列の成果物があります。
ただし、現行系列を維持する場合も無期限ではありません。Software Life Cycleを確認し、EOL前に次の系列へ移る日程を決めます。依存ツールの対応待ちを理由に保守期限を越えそうなら、代替ツール、設定変更、段階移行を早めに検討します。
29.5は応急対応であり29.x継続運用の根拠にはならない
29.5にも3件の修正は入っていますが、29.xは32.1公開日の2026年10月27日にEOLとなりました。EOLは、以後の脆弱性や不具合に対して同系列の修正版が継続提供されると期待できない状態です。「29.5が公開されたから29系は今後も安全更新を受けられる」と解釈してはいけません。
移行に時間がかかる環境では、29.5を短期的な危険低減に使いながら、30.x以降へ移る計画を並行して作る考え方があります。移行先の選択、検証、停止枠、ロールバック条件、担当者を具体化し、「いつか移行する」という曖昧な状態を避けます。
更新前に確認するOS・ファイルシステム・バックアップ
対応試験済みOSの範囲を確認する
32.1の公式ノートが示す試験環境は、Linux Kernel 3.17以降、macOS 14以降、Windows 10 version 1903以降です。これは、ほかの環境で絶対に動かないという宣言ではなく、公式が継続的に試験している範囲を示します。古いOSではBitcoin Coreだけでなく、OS自体のセキュリティ更新状況も問題になります。
本番更新前に、OSの版、アーキテクチャ、空き容量、メモリ、権限、サービス起動方法を記録します。コンテナやサービス管理ツールを使っている場合は、実行ファイルだけでなくイメージ、ボリューム、起動引数、環境変数の更新経路も確認します。
32ビットOSとFAT32では残るリスクを把握する
32ビットか64ビットかはOS名だけでは判断せず、実行環境と導入バイナリを確認します。また、Bitcoin Core本体の置き場所ではなく、blocksディレクトリが実際に載っているファイルシステムを見ます。外付けドライブ、NAS、別マウントへブロックデータだけを移している構成では、システムドライブと種類が異なることがあります。
FAT32は単一ファイルサイズに制約があるため、CVE-2026-117346の残存条件と関係します。該当するなら、更新作業と環境移行を同じものとして勢いで行わず、別手順に分けます。新しい保存先の容量、権限、耐障害性、バックアップ、データコピー後の検証、設定のdatadirやblocksdirを確認します。
walletと設定ファイルの検証済みバックアップを用意する
更新前には、利用中のウォレットと設定ファイルをバックアップします。ただし、ファイルをコピーしただけで安心せず、対象が正しいか、暗号化されているか、復旧に必要なパスフレーズを別途安全に管理しているか、復元手順を確認します。descriptor wallet、外部署名、watch-onlyなど、ウォレット構成により必要な情報は異なります。
ブロックチェーン全体のデータは再取得できても、秘密鍵やdescriptor、設定、ラベル、運用固有の情報は同じ扱いではありません。バックアップ先をノードと同じ物理ディスクだけに置くと、ディスク障害時に同時に失う可能性があります。業務環境では、バックアップ取得日時、対象、暗号化、復元試験結果を記録します。
Bitcoin Coreを安全に更新する手順
公式配布先から対象バージョンを取得する
対象系列を決めたら、bitcoincore.orgの公式配布ディレクトリまたは公式リリースページから、自分のOSとアーキテクチャに合う成果物を取得します。広告リンク、ファイル共有サービス、非公式ミラーから取らないでください。ファイル名が似ていても、中身が正規である保証にはなりません。
本番環境へ直接ダウンロードする運用でも、管理端末を経由する運用でも、取得元URL、ファイル名、版、ハッシュ、検証結果を残します。自動化する場合は「latest」のように版が変わる参照ではなく、承認した版を固定し、意図しない更新を防ぎます。
署名と配布物を検証する
まなぶ「公式サイトから落としたなら、ファイル名を見るだけで大丈夫ですか？」
クリプ「ファイル名だけでは不十分だよ。公式の検証手順に沿ってハッシュと署名を確かめ、誰の鍵を信頼したかまで記録すると安全性を説明しやすいんだ。」
配布ディレクトリから対象バイナリとSHA256SUMS、SHA256SUMS.ascを同じ作業用ディレクトリへ取得します。代表的なUnix系の確認例はgpg --verify SHA256SUMS.asc SHA256SUMS、続いてsha256sum --ignore-missing --check SHA256SUMSです。macOSでsha256sumがない場合は、公式リリースノートが案内する検証方法を使い、コマンド名だけを無理に置き換えません。
署名確認ではGood signatureに相当する結果と署名鍵の指紋を確認し、ハッシュ確認では取得したファイル名の行がOKになることを期待します。BAD signature、FAILED、対象ファイルの行がない、指紋を別経路で確認できない場合は、そのバイナリを実行せず中止します。「鍵が信頼済みでない」という警告と署名不一致は同じではありませんが、意味を判断できなければ公式手順へ戻ります。ハッシュ関数の基本を押さえると、署名とファイル照合の役割を区別しやすくなります。
Bitcoin Coreの完全停止を待って実行ファイルを置換する
CLI運用では更新前にbitcoin-cli getnetworkinfoのsubversionを記録し、bitcoin-cli stopを実行します。GUIではメニューから終了します。正常なら停止要求が受理され、やがてRPC接続も終了します。debug.logの終了記録やOSのプロセス一覧でbitcoind／bitcoin-qtが消えるまで待ち、停止中に電源断、強制終了、実行ファイルの上書きをしません。RPCに接続できない、ログが書き込みエラーを示す、プロセスが残り続ける場合は更新を中止して原因を確認します。
完全停止後、Linuxのアーカイブ配布なら展開したbin/内の実行ファイルを、既存のインストール方式と権限を保って置換します。Windowsは検証済みインストーラー、macOSは検証済みディスクイメージを使い、いずれも公式リリースノートのOS別手順を優先します。パッケージ管理、コンテナ、systemdなどで導入した環境は、その管理方式を混在させません。コピー先、起動ユーザー、設定・データディレクトリが特定できない場合は中止します。データ形式変更後はバイナリを戻すだけで完全復旧にならないため、旧版起動をロールバック手順にしない機能も確認します。
再起動後に同期・ウォレット・ログを確認する
従来と同じ方法で起動し、CLIならbitcoin-cli getnetworkinfoでsubversionが採用版になったこと、connectionsが回復することを確認します。続いてbitcoin-cli getblockchaininfoでinitialblockdownload、blocks、headersを確認し、同期完了時は通常initialblockdownload: falseかつblocksとheadersの差が解消へ向かう状態を期待します。ウォレット利用者はbitcoin-cli listwallets、RPC連携環境は監視・決済の読み取りテストも行います。
初回はデータ移行や再検証で時間を要する場合があります。ただし、採用版が表示されない、同じ致命的エラーが反復する、ウォレットが読み込まれない、ディスク容量が急減する、ブロック高が進まない場合は追加操作を止め、ログとバックアップを保全します。期待値を満たすまでは更新完了とせず、送金・決済など書き込み系RPCを再開しません。
PSBT・RPC・ウォレット連携の互換性を確認する
PSBT v2既定化とv0前提の署名機器を試験する
32系では、PSBT関連RPCがPSBT v2を既定で扱う変更があります。PSBTは、未署名または一部署名済みのBitcoin取引情報を複数のソフトウェアや署名機器の間で受け渡す形式です。v2は取引構成要素の表現を拡張しますが、古い機器やライブラリがv0だけを前提にしていると連携に失敗する可能性があります。
外部署名機器、マルチシグ共同署名者、ウォレット管理ソフトを、本番資金ではない環境で一巡させます。生成、エクスポート、読み込み、署名、結合、確定、ブロードキャストを確認してください。本稿の調査資料はv0を明示できる個別RPC名・引数までは裏付けていないため、推測で指定せず、利用するRPCの32.1公式ヘルプ（bitcoin-cli help <RPC名>）と機器ベンダーの対応表でv0指定方法を確認します。指定方法が確認できないv0専用機器では32.1への本番移行を止め、30.4または31.2を含む系列選択へ戻ります。
RPC連携は32.1公式ノートを基準に回帰試験する
RPC（外部ツールがCoreを操作・参照する窓口）を使っていなければ、この項は読み飛ばせます。使っている場合は、32.1公式リリースノートのRPC・REST変更一覧を基準に、実際に呼ぶRPC名、引数、戻り値を棚卸しします。本稿の調査資料だけでは変更されたHTTPヘッダー名や廃止フィールド名を特定できないため、一般論で名称を補わず、利用箇所ごとにbitcoin-cli help <RPC名>と公式ノートへ対応付けます。
検証環境で認証、正常応答、空結果、エラー、タイムアウト、再試行をテストし、レスポンス全体の文字列一致や配列順、廃止予定フィールドへ依存する実装を洗い出します。HTTP 4xx／5xx、JSON解析失敗、必須フィールド欠落が出たら本番切替を中止します。手作りクライアント、古いSDK、リバースプロキシ、監視エージェントは個別に確認し、秘密情報を含むRPCログを外部へ送らないでください。
watch-only出力に含まれる情報と秘密鍵非包含を理解する
32系のwatch-onlyウォレット出力では、公開descriptor、取引、アドレス帳などを扱えますが、秘密鍵は含まれません。残高監視や取引履歴の参照に役立つ一方、これだけでは資金を使用できません。「ウォレットをエクスポートしたから秘密鍵のバックアップも完了した」と誤解しないでください。
秘密鍵を含まないことは漏えい時の直接的な送金リスクを抑えますが、公開鍵情報、アドレス、取引履歴、ラベルはプライバシー上の機密情報です。誰のアドレスか、残高や取引関係が推測され得るため、watch-only出力にもアクセス制御、暗号化、保管期限を設定します。ウォレットの種類と鍵管理の基本も合わせて整理すると、監視用データと署名用データを区別しやすくなります。
索引・性能・private broadcastは必要に応じて見直す
ここからの項目は、3件の脆弱性を修正するために全員が同時実行すべき作業ではありません。新形式による容量削減、並列数の調整、実験的な送信機能は、必要性と運用コストを見て個別に判断します。安全更新と最適化を一度に詰め込むと、問題発生時に原因を切り分けにくくなります。
txindexの容量削減は削除・再構築した場合だけ得られる
32系のtxindexは既存索引と互換性があります。そのため更新後も従来の索引を使い続けられますが、新形式による容量削減は自動では得られません。容量を減らしたい場合は、Bitcoin Coreを停止し、対象索引を削除して再構築する必要があります。
再構築は任意の最適化であり、更新直後に必ず行う手順ではありません。再構築中の機能制限、所要時間、ディスクI/O、空き容量、監視への影響を見積もります。また、新形式へ再構築した後に旧版へ戻すと、旧版側でも再構築が必要になります。停止枠が限られる環境では、セキュリティ更新を先に完了し、索引最適化を別日程に分ける方法が安全です。
prevout並列読込の既定値と調整範囲を把握する
32系では、過去の出力であるprevoutをディスクから読む処理を並列化できます。実装上の既定値は8、最大16で、0にすると無効化できます。並列化は処理時間の改善を狙うものですが、ストレージ、CPU、同時に動く処理によって効果や負荷が変わります。
数値を大きくすれば必ず速くなるわけではありません。低速なディスクや共有ストレージでは、並列アクセスがほかの処理を圧迫する可能性があります。まず既定値でメトリクスを取り、検証環境で変更前後の処理時間、I/O待ち、CPU、メモリを比べます。根拠なく最大値へ設定するより、目的と測定結果を残します。
private broadcastは匿名性を保証しない
private broadcastは31.0で導入された実験的機能で、TorやI2Pを使った取引送信のプライバシー改善を狙います。ただし、通常のウォレット送信すべてに自動適用される機能ではなく、送信元の匿名性を保証するものでもありません。公式実装にもベストエフォートの注意があります。
修正前には、v2接続に失敗してv1へ再接続する特定条件で、指定したプロキシを外れてIPアドレスが漏れる可能性がありました。32.1では関連修正が含まれますが、設定、DNS、プロキシ、再送経路、相手ピアの観測を含む全体で考える必要があります。高い匿名性を前提に人命や法的安全を委ねる用途には、単独機能の名称だけを根拠にしないでください。
保守期限とセキュリティ助言を継続的に確認する
更新が終わっても運用は続きます。現在の系列、導入日、次のEOL、依存ツール、署名検証手順、バックアップ復元試験日を台帳に残します。Bitcoin CoreのSoftware Life Cycle、Security Advisories、リリースページを定期的に確認し、新しい修正版が出たときに影響を評価できる担当と手順を決めます。
セキュリティ情報は、修正版の公開と同時にすべての詳細が明かされるとは限りません。利用者の更新時間を確保してから技術詳細が公開される場合もあります。「詳しい悪用方法がまだ見えないから対応不要」とは判断せず、公式の深刻度、影響系列、環境条件、緩和策を確認します。一方、SNS上の断片的な投稿だけで強制終了やデータ削除を行わないことも重要です。
まとめ：環境を確認してから修正版へ更新する
Bitcoin Core 32.1は、3件の脆弱性修正を含む新メジャー系列です。一般保有者に資産移動を求める更新ではなく、自分でノードを運用する人が主な対応者です。ノード運用者は、現在の系列と保守期限を確認し、32.1、31.2、30.4のどれを採用するかを互換性と移行計画に基づいて判断します。
- 稼働バージョン、OS、32/64ビット、blocksディレクトリのファイルシステムを確認する
- 29.xなら、29.5の適用だけで終わらせず保守対象系列への移行計画を作る
- walletと設定のバックアップを取り、復元可能性を確認する
- 公式配布先から取得し、ハッシュと署名を検証する
- 完全停止を待って更新し、起動後の同期、ウォレット、RPC、ログを確認する
- PSBT v2、外部署名機器、RPCクライアントを本番前に試験する
- txindex再構築や性能調整は必須更新と分けて実施する
32ビット環境やFAT32では、32.1を入れてもCVE-2026-117346の影響が残ります。また、private broadcastは匿名性の保証ではありません。更新番号だけで安全を断定せず、環境、設定、連携、保守期限を継続して管理することが、安定したノード運用につながります。
