9 月 17 日に公開された cardano-node 11.1.2 について、翌 18 日の時点で「バージョンを報告しているノードの 20% が更新を終えた」という観測を、Rick McCracken 氏が X で共有しました。日本時間 19 日には、フルノードを内蔵するウォレット Daedalus も 11.4.0 で中身のノードを 11.1.2 へ入れ替えています。
Cardano には、新しいノードを全台へ一斉に配る仕組みがありません。運用者がそれぞれ自分のサーバーでバージョンを上げ、再起動して、はじめて新しいリリースがネットワークの一部になります。分散の度合いを示す数字はプール数や委任の集中度で語られがちですが、この「何割が上げたか」も同じ実体の別の断面です。本記事では、11.1.2 の中身、20% という数字の読み方、そして更新時に見落としやすい監視まわりの変更を、公開されたリリースノートにもとづいて整理します。
11.1.2 は、11.1.1 の上に載るメモリ修正
cardano-node 11.1.2 のリリースノートが挙げる変更は、タイムロックスクリプトのメモリ使用の最適化です。タイムロックスクリプトは「この時刻より前は使えない」といった時間条件をかける仕組みで、ネイティブスクリプトの一種です。ベンチマークとシステムテストについては「11.1.1 の結果がそのまま当てはまる」と書かれており、11.1.2 は 9 月 8 日に出た 11.1.1 に小さな修正を重ねた版という位置づけです。
既知の課題も 11.1.1 から引き継がれています。同期中のメモリ使用は 11.0.1 と比べてわずかに増えますが、11.1.0 で出ていた退行よりは大幅に少ないとされています。チェーンの先端に追いついた状態でも小幅に増え、これは台帳スナップショットの取得と相関すると説明されています。最小要件は、InMemory バックエンドで RAM 24GB、OnDisk バックエンドで 8GB（こちらは「確認中」と注記）、ストレージ 300GB（将来の伸びを見込むなら 350GB）です。
同じ週には、配布されているメインネット設定で Ouroboros Genesis が既定になる動きもありましたが、これは設定ファイル側の変更で、ノードの実行ファイルとは出どころが別です。両者の違いは Ouroboros Genesis、メインネット設定で既定に で詳しく扱っています。
「報告ノードの 20%」をどう読むか
McCracken 氏の投稿は「報告しているノード（reporting nodes）」のうち 20% と書いています。バージョンを外部に報告していないノードは母数に入らないため、ネットワーク全体の正確な比率ではありません。それでも、公開から 1 日あまりで 5 台に 1 台が入れ替わったという速度は、方向を読むには十分な材料です。
更新のペースが運用者ごとにばらつくのには理由があります。11.1.2 のリリースノートにハードフォークの期日は書かれておらず、いつ上げるかは各運用者の判断に委ねられています。ブロックを生成するノードは、止めている間に自分の担当スロットが来ればそのブロックを作れません。リレーから順に入れ替えて様子を見る、担当スロットと重ならない時間帯を選ぶ、といった段取りを、それぞれの運用者が自分の構成に合わせて組むことになります。
一斉に切り替わらないことは、弱点に見えて安全装置でもあります。新しい版に想定外の不具合があっても、影響はまず更新を済ませた一部に限られ、残りのノードが旧版のまま動き続けます。20% から 50%、80% へと数字が上がっていく過程そのものが、ネットワーク全体での段階的な検証になっています。
11.1.1 以降、旧トレーシングは使えません
11.0 系から 11.1.2 へ直接上げる運用者が見落としやすいのが、11.1.1 で入った変更です。11.1.1 のリリースノートは、旧来のトレーシング（iohk-monitoring-framework）の削除が完了し、新しいトレーシングシステムだけが残ったと明記しています。旧設定キーを使い続けている構成は移行が必要で、削除されたキーの一覧は PR 6580 にまとめられています。
9 月 19 日には、プール運用者の HephyPool が「11.1.1 と 11.1.2 より前に監視環境を移行していなかった人は、新トレーシングシステムのクイックスタートを見てほしい」と呼びかけ、開発者ポータルの手引きを案内しています。ノード自体が正常に同期していても、ダッシュボードやアラートが旧方式のメトリクスに頼っていると、更新した途端に監視だけが静かに止まる、ということが起こりえます。
11.1.1 ではほかにも、V1 LedgerDB と LMDB ストレージバックエンドが削除されています。LMDB を使っている場合はバックエンドの切り替えが必要です。台帳スナップショットは取得間隔が予測可能になり、Mithril と互換になりました。x86_64-linux 向けの配布物には Mithril の署名プログラムも同梱されるようになっています。
Daedalus 11.4.0 で、デスクトップ側もノードごと更新
Daedalus は、ウォレットの中で cardano-node を動かし、チェーン全体を自分の手元で検証するフルノード型のウォレットです。9 月 18 日（UTC、日本時間 19 日早朝）に公開された 11.4.0 は、依存コンポーネントとして cardano-node を 11.1.2、cardano-wallet を v2026-09-16 へ上げています。Daedalus を更新した利用者は、それだけで手元のノードも 11.1.2 になります。
アプリ側の修正は、CSV 書き出しで期限切れの取引が「承認済み」ではなく正しく「失敗」と表示されるようになった点と、投票権の委任フローでステップを移動しても選んだウォレットが保持されるようになった点などです。DRep（委任代表者）の表示まわりも整えられています。リリースノートは、すべての Daedalus 利用者に本バージョンへの更新を推奨しています。
取引履歴を CSV で書き出して記録や申告に使っている場合、11.4.0 より前に書き出したファイルでは、期限切れの取引が承認済みとして並んでいた可能性があります。更新後に書き出し直して見比べておくと安心です。
次に見るもの
エポック 657 は日本時間 9 月 22 日 6 時 45 分ごろに始まり、27 日 6 時 45 分ごろまで続きます。このエポックの間に、報告ノードの比率が 20% からどこまで伸びるかが、次の確認点です。McCracken 氏の続報と、cardano-node のリリースページに 11.1 系の次の版や更新推奨の追記が出るかを、あわせて見ておきます。自分でノードを動かしている方は、更新の前に、監視設定が新トレーシングシステムの形になっているかを一度開いて確かめておくと、更新後の空白を避けられます。
ことば
- タイムロックスクリプト — 「この時刻より前は使えない」「この時刻を過ぎたら使えない」といった時間条件を資金の支出やトークン発行にかける、ネイティブスクリプトの仕組み。11.1.2 はこの処理のメモリ使用を最適化しました。
- トレーシング — ノードが自分の動作状況をログやメトリクスとして外へ出す仕組み。11.1.1 で旧方式が削除され、監視ツールは新方式への対応が前提になりました。
- Daedalus — Cardano のフルノード型デスクトップウォレット。内部で cardano-node を動かすため、ウォレットの更新がそのまま手元のノードの更新になります。
一次ソース / 関連リンク
- cardano-node 11.1.2 リリースノート（GitHub）
https://github.com/IntersectMBO/cardano-node/releases/tag/11.1.2 - cardano-node 11.1.1 リリースノート（GitHub）
https://github.com/IntersectMBO/cardano-node/releases/tag/11.1.1 - Daedalus 11.4.0 リリースノート（GitHub）
https://github.com/input-output-hk/daedalus/releases/tag/11.4.0 - 新トレーシングシステム クイックスタート（Cardano 開発者ポータル）
https://developers.cardano.org/docs/operators/monitoring/new-tracing-system/new-tracing-system - Rick McCracken 氏の投稿（報告ノードの 20% が 11.1.2 へ更新）
https://x.com/RickMcCracken/status/2100914963158098087 - HephyPool の投稿（監視環境の移行の呼びかけ）
https://x.com/HephyPool/status/2101263066830655721 - 関連: 📋 Daily Intel 9/21｜ノード 11.1.2 への更新が回り始めた
https://sipo.tokyo/daily-intel-20260921/
