HederaのMirror Nodeを自社運用しているなら、Block Streamへの切替前に準備が必要です。2026年10月27日時点の最新版公式ガイドでは、テストネットは11月25日、メインネットは12月9日に切り替わる予定で、Mirror Nodeの最低対応版はv0.164.0です。Record Fileを直接取得する仕組みも確認対象になります。一方、HAPIやSDK、Explorer、REST API、JSON-RPC Relayを利用するだけの一般的なアプリは、原則としてこの切替だけを理由にコードを変える必要はありません。
この記事では、対応要否を判定した後、バージョン、IAM、取得元、事前検証、切替後の鮮度を作業順に確認します。日付やバージョンは変更され得るため、実施時は公式Cutover GuideとRelease Notesを再確認してください。
編集・検証情報：最終確認日は2026年10月27日です。一次資料と設定例は机上確認済みですが、読者固有のクラウド資格情報、ネットワーク、実機構成では未検証です。変更管理者とMirror Node運用担当が採用版の公式文書に照らして実行してください。
HederaのBlock Stream切替で押さえるべき結論
最初に判断基準をまとめると、対応対象は主にMirror Node運用者とRecord Fileの直接利用者です。Mirror Nodeはv0.164.0以上を最低条件として準備し、3ネットワークの新しいバケットを読めること、Block NodeとFILEの取得経路が意図どおり動くこと、切替後に最新ブロックが更新され続けることを確認します。プロセスが起動しているだけでは十分ではなく、データの時刻まで見るのが要点です。
テストネットは11月25日、メインネットは12月9日に切り替わる
最新版の公式Cutover Guideが示す予定日は、テストネットが2026年11月25日、メインネットが同年12月9日です。先にテストネットで切替を経験できるため、本番と同じ構成を用意し、取り込み、再起動、障害時フォールバック、監視アラートを試す期間として使えます。日付を「その日まで待てばよい期限」と考えず、本番前の検証から逆算して更新日程を決めてください。
古いブログや二次記事には「11月に切替」とだけ書かれたものがあります。公開当時の説明としては意味がありますが、作業日の根拠には最新版ガイドを使います。コードが公開された日、Mirror Nodeの対応版が出た日、Consensus Nodeへ機能が適用される日は別です。カレンダーへ登録する際も、テストネットとメインネットを別の作業として扱うと混同を防げます。
最低対応版はv0.164.0、旧案内のv0.163.0ではない
必須：まず実行中の版を確認します。Kubernetesなら kubectl -n <namespace> get pod -l app=mirror-importer -o jsonpath='{.items[*].spec.containers[*].image}' で実イメージを取得し、デプロイ定義と起動ログの版を照合します。
最低対応版はhiero-mirror-node v0.164.0です。旧案内に残るv0.163.0を基準にすると、切替後の新規データを取り込めないおそれがあります。「現在のAPIが応答する」「コンテナが正常終了していない」という確認だけでは、切替後も追従できる証拠になりません。デプロイ定義、実行中イメージ、起動ログの3点から実際の版を照合します。
v0.164.0は推奨版を永久に固定する指定ではなく、切替対応の最低線です。10月27日時点ではv0.165.1まで公開されています。後続版の修正内容、依存関係、移行上の注意を評価し、自社の検証を通った版を選びます。「最低版以上」と「自社で採用すべき版」は同じ問いではありません。
日程と最低版は公開直前にも公式ガイドで再確認する
公式ガイド自身が日程や最低版を調整し得る前提で書かれています。したがって、記事の値を設定ファイルへそのまま転記して終わりにせず、変更管理の承認時、テストネット実施前、メインネット実施前に公式ガイドを確認します。確認日、参照したコミットまたはリリース、判断者を作業記録へ残すと、後から根拠を追えます。
情報源の優先順位は、最新版Cutover Guide、Mirror NodeのRelease Notes、公式Status、設計文書の順に置くと整理しやすくなります。ブログや報道は背景理解には役立ちますが、古い値が更新されず残る場合があります。検索結果の抜粋だけで判断せず、一次資料の本文と公開日を開いて確認してください。
対応が必要な利用者とコード変更が原則不要な利用者
まなぶ「クリプ先生、Hederaを使うアプリなら全部改修しないといけないんですか？」
クリプ「全部ではないよ。データを取り込むMirror Node側と、そのAPIを使うアプリ側を分けて考えるのがポイントなんだ。」
Block Streamは基盤のデータ形式と取得経路を変えるため、Hederaを利用するすべての人に同じ作業が発生するわけではありません。まず自社がMirror Nodeそのものを運用しているか、クラウド上のRecord Fileを直接読んでいるか、第三者が運用するAPIを呼んでいるだけかを確認します。担当チーム名ではなく、実際のデータ経路で分類してください。
対応の中心はMirror Node運用者とRecord File直接利用者
自社でMirror Node importerを動かし、PostgreSQLなどへデータを取り込んでいる運用者は直接の対象です。デプロイ版、ストレージへの権限、取り込み方式、監視を更新します。また、Mirror Nodeを経由せずRecord Fileや署名、sidecarをオブジェクトストレージから直接取得し、独自処理しているサービスも対象です。旧Record Streamへ新規追記が止まるため、旧パスを見続ける実装はデータが進まなくなります。
資産管理、会計、インデックス、分析、監査などのバッチがRecord Fileを暗黙に読んでいる場合もあります。コード検索だけでなく、クラウドアクセスログ、IAMポリシー、ジョブ定義、データカタログから利用箇所を洗い出してください。別部署のETLや一時的な検証ジョブが残っていると、主要APIが正常でも一部の帳票だけ止まることがあります。
HAPI・SDK・Explorer・REST API・JSON-RPC Relayは原則変更不要
HAPI、公式SDK、Explorer、REST API、JSON-RPC Relayを通常どおり利用するアプリは、原則としてBlock Stream切替だけを理由にコードを変更する必要はありません。アプリは既存インターフェースを利用し、その背後のMirror Nodeが新形式を既存のデータモデルへ変換する設計だからです。ただし、自社が利用する提供者のメンテナンス案内やSLAは別途確認します。
「原則不要」は無検証でよいという意味ではありません。入出金履歴、残高、トークン転送、コントラクト結果など、自社の重要な読み取りをテストネット切替後に回帰確認します。非公開フィールド、実装依存の順序、更新遅延へ依存しているアプリでは、基盤変更が間接的に見える場合があります。公開APIの契約と自社の期待値を分けて検証してください。
API互換性はMirror Nodeの取り込み層で維持される
Mirror NodeはBlock Streamを受け取り、従来のレコード相当へ変換してデータベースへ格納する設計です。この変換層が既存REST APIなどとの互換性を支えます。つまり、新形式が増えたからといって、すべての下流利用者が生のBlock Streamを解釈する必要はありません。運用責任は、基盤側の変換と下流側の回帰試験に分かれます。
一方、独自のパーサーでRecord、Event、sidecar、署名ファイルを結合していたシステムは、互換層の外側にいます。その場合は公式Mirror Nodeへ寄せるか、新しいBlock Streamを直接扱うかを決めなければなりません。保守範囲、検証責任、遅延、保存要件を比較し、単に形式変換の工数だけで判断しないことが重要です。
Record StreamからBlock Streamへ何が変わるのか
データ経路はConsensus Node → Block NodeまたはFILE → Mirror Node importer → DB → REST API利用者です。Consensus Nodeは合意結果を生成し、Block NodeはBlock Streamを保存・検証・配信し、FILEはオブジェクトストレージから読む代替経路、Importerは受信データをDBへ反映します。基礎から確認したい場合はブロックチェーンの仕組みも参照してください。
従来はRecord、Event、署名、sidecarなどが分かれ、利用側が複数のファイルや証明を扱う場面がありました。Block Streamは、合意処理の履歴と状態変化をより統合された連番ブロックとして表現し、証明と一緒に配信する方向へ移します。運用上は「ファイル名が変わる」だけでなく、正規の新規データ源と検証単位が変わる移行です。
複数のデータと署名を単一のBlock Streamへ統合する
Block StreamはRecord、Event、署名、sidecarを統合し、ブロックを連番で扱います。下流処理は、複数のクラウドオブジェクトを列挙し、対応する署名ファイルを集めて関係付ける作業を減らせます。状態変更も含むため、履歴から状態を再構築したり、特定の処理を証明したりする用途にもつながります。
「統合」は情報が一枚の巨大ファイルになるという意味ではありません。順序付けられたブロックと、その内容を検証する証明を共通の流れとして扱う考え方です。利用者は開始ブロックを指定して連続取得し、欠落がないかをブロック番号で追えます。再処理時には対象範囲を明確にしやすくなりますが、保存容量や保持期間の設計は引き続き必要です。
Mirror NodeはBlock Nodeから確定ブロックを購読する
Block NodeはBlock Streamの保存、証明検証、配信を担い、Mirror NodeはgRPCの長寿命ストリームで確定ブロックを購読できます。途中で接続が切れた場合、クライアントは最後に処理した位置から再接続しなければなりません。公式Mirror Node importerにはその運用を支える処理が組み込まれますが、接続性や追従遅延の監視は運用者の役割です。
複数のBlock Nodeを利用できれば、単一接続先の障害に備えられます。接続先の自動発見、証明検証、履歴リプレイが組み合わさることで、リアルタイム追従と復旧を同じ経路で考えられます。ただし、手動で特定ノードだけを固定すると自動発見の利点を失う場合があるため、設定の意図を明文化してください。
旧Record Fileは残るが切替後の新規追記は止まる
旧バケットの過去Record Fileは直ちに消去されるわけではなく、履歴参照のため残ります。しかし切替後の新しい履歴はBlock Streamへ移り、旧Record Streamには追記されません。この違いが重要です。過去ファイルを読めることを「移行不要」と誤解すると、ジョブは成功扱いのまま古い最終地点で止まる可能性があります。
移行には旧Record FileをWrapped Record Blockとして扱う段階も含まれ、過去と新形式の境界をつなぎます。単純な一斉置換ではありません。履歴を最初から再構築する処理、境界をまたぐ照会、差分バックフィルをテストし、重複と欠落の両方を確認します。最終レコード時刻を監視すれば「読めるが更新されない」障害を発見しやすくなります。
切替前にMirror Nodeをどのバージョンへ更新するか
更新判断では、最低互換性、既知の修正、セキュリティ、依存コンポーネント、自社の検証結果を分けて考えます。v0.164.0へ上げれば最低条件は満たしますが、それだけで10月27日時点の判断が完了するわけではありません。v0.164.1、v0.164.2、v0.165.0、v0.165.1のRelease Notesを連続して確認します。
v0.164.0未満では切替後の新規データを取り込めない
v0.164.0未満のMirror Nodeは、切替後の正規データ源へ対応できません。旧Record Streamの追記も止まるため、未対応版が自動的に従来方式で動き続けるとは考えられません。最も危険なのは、プロセスとAPIが稼働したままデータだけが停滞する状態です。ヘルスチェックがHTTP応答しか見ていないなら、最新ブロック時刻も追加します。
アップグレード前にはデータベース移行、設定キー、リソース使用量、ロールバック条件を整理します。ロールバックしても旧データ源に新規データが来ないため、切替後の単純な旧版復帰は復旧策にならない可能性があります。問題が起きた際に、対応版の別パッチへ進むのか、FILE経路へ退避するのかを先に決めてください。
最低版で固定せずv0.165.1までの修正内容を評価する
v0.165.1は2026年10月23日に公開され、node2shell脆弱性の修正を含む緊急セキュリティリリースです。この事実から、v0.164.0以上ならどれでも同等とは言えません。自社環境への影響、露出範囲、緩和策を確認し、セキュリティ担当と採用版を判断します。記事は特定版への無条件な更新を推奨するのではなく、最新版まで評価範囲へ含めることを求めます。
バージョン番号だけを比較するのではなく、コンテナイメージのダイジェスト、SBOM、依存ライブラリ、設定差分も記録します。検証済みイメージと本番に配ったイメージが同じであることを確認してください。切替までに追加版が出た場合は、変更内容に応じて再試験の範囲を決めます。
Block ProofとTSSの変更をステージングで検証する
v0.165.0ではNova/TSS 3.22.0、SHA-256系Block Proof、移行互換に関わる大きな変更が含まれます。Block Proofは取り込んだブロックが正規の履歴であることを確かめる核で、TSSはネットワークの集約署名に関係します。仕組みの変更は、正常系だけでなく不正な証明の拒否、再接続、古い履歴との境界も試す必要があります。
互換期間を使い、Consensus Nodeの切替より前に対応Mirror Nodeを展開できます。ステージングでは初回同期、追従、再起動、Block Node切断、FILEフォールバック、境界をまたぐ照会を実行します。ログに未知の証明方式、連番の欠落、繰り返し再試行がないか確認し、本番のアラート条件へ反映してください。
recent-block-streamsバケットのIAMを準備する
Block Nodeが主経路でも、FILEへのフォールバックを成立させるにはrecent-block-streamsバケットを読めなければなりません。IAMは「付与したつもり」ではなく、Mirror Nodeが実際に使う実行主体とネットワーク経路から試験します。環境ごとのアカウント、ロール、リージョン制約、プロキシも確認対象です。
3ネットワークのバケットへ読取権限を付与する
mainnet、testnet、previewnetのrecent-block-streamsバケットに対し、必要な読取権限を用意します。本番だけを許可すると、テストネットで本番同等の切替試験ができません。逆に全環境へ過剰な権限を与える必要もないため、利用する実行主体と対象バケットを明示し、最小権限で構成します。
開発端末の個人資格情報で成功しても、KubernetesのServiceAccountや本番VMのロールが同じとは限りません。Podやジョブなど実運用と同じ場所から検査します。資格情報の期限、ロール引受け条件、VPCエンドポイントのポリシーも、オブジェクト取得を拒否する要因になり得ます。
LIST・GETとRequester Paysの条件を確認する
必要なのはオブジェクトの一覧取得に関わるLISTと、内容取得に関わるGETです。GETだけ許可しても、どのブロックが存在するかを探索できず、復旧経路が機能しない場合があります。またRequester Paysの条件に対応する設定や請求先権限が不足すれば、IAM上は読取許可があってもリクエストが失敗します。
権限エラーをネットワーク障害やファイル欠落と誤認しないよう、HTTPまたはSDKのエラーコードを分類して監視します。アクセスキーをログへ出す必要はありません。バケット名、要求種別、応答コード、実行主体を安全な範囲で記録し、誰が権限を修正するかをランブックへ明記します。
公式スクリプトの終了コード0と成功表示で検証する
必須：公式リポジトリのルートで、AWS testnetなら tools/blockstream/verify-block-streams-bucket-access.sh -p aws -n testnet --access-key '$ACCESS_KEY' --secret-key '$SECRET_KEY' を実行します。キーをシェル履歴やCIログへ残さず、mainnet・testnet・previewnetを実運用主体から個別に検査してください。
公式ランブックにはrecent-block-streamsバケットへのアクセスを検査する手順があります。実行したという記録だけでなく、終了コードが0であることと、成功を示す出力を確認します。標準出力だけを眺めてエラー行を見落とさないよう、CIや変更管理の証跡へ結果を保存してください。
検査は権限付与直後に一度行うだけでなく、テストネット切替前とメインネット切替前にも繰り返します。IAMやネットワークポリシーは別の変更で変わる可能性があるからです。定期確認では実データを大量取得せず、ランブックが定める範囲でLISTとGETの成立を確かめます。
Block NodeとFILEの取得元設定を確認する
まなぶ「クリプ先生、AUTOなら設定を何も確認しなくても自動で直るんですか？」
クリプ「AUTOにも前提があるよ。自動発見を邪魔する上書きがないか、FILEへ退避できる権限があるかを先に試そう。」
Mirror Nodeの取得元にはBLOCK_NODE、FILE、AUTOという考え方があります。通常運用と障害時の経路を別々に確認し、AUTOという文字列だけで冗長性が保証されたと判断しないでください。Block Nodeの発見、接続、証明検証、FILEアクセスの全体がそろって初めて切替が働きます。
sourceType=AUTOはBlock Nodeを優先する
sourceType=AUTOではBlock Nodeを優先してデータを取得します。Block Nodeは確定ブロックをストリーム配信するため、クラウドバケットを繰り返し列挙する方式とは運用特性が異なります。長寿命接続の状態、最終受信時刻、再接続回数、処理待ちを監視し、単なるTCP接続の有無だけに依存しないでください。
接続先はオンチェーン登録情報から自動発見でき、通常はblock.nodes[]を手動固定する必要がありません。自動発見は接続先の更新へ追随しやすい利点があります。DNS、TLS、gRPC、プロキシの制約がある環境では、テストネット上で実際に発見から購読まで通ることを確かめます。
障害時はFILE取得へフォールバックする
AUTOはBlock Nodeが不調なとき、FILE取得へ退避できる設計です。これにより一時的なBlock Node障害が直ちに取り込み停止へ直結する可能性を下げられます。ただし、前節のIAM、Requester Pays、ネットワーク経路が整っていなければ、フォールバックを開始してもファイルを読めません。
ステージングではBlock Nodeへの接続を意図的に失敗させ、FILEへ移行すること、データが重複・欠落せず進むこと、Block Node復旧後の動作が設計どおりであることを確認します。障害試験が難しい場合でも、少なくとも両経路の単独接続を検証し、切替を示すログとメトリクスを把握してください。
自動発見を妨げる手動設定と排他条件を点検する
過去の障害対応や検証でblock.nodes[]を固定した設定が残っていると、自動発見を妨げ、単一接続先へ依存する場合があります。環境変数、Helm values、ConfigMap、Secret、コマンドライン引数など、設定の優先順位をすべて確認します。リポジトリの既定値だけ見ても、実行時の上書きは分かりません。
Mirror Node Configurationには取得元やImporterの設定キーがまとめられています。排他となる指定、既定値、廃止されたキーを採用版の文書で確認してください。本番設定をエクスポートし、ステージングとの差分をレビューすると、意図しない上書きを見つけやすくなります。
切替当日にBlock Stream取り込みを有効化する
事前準備が完了していても、切替当日にImporterがBlock Stream取り込みを有効化していなければデータは進みません。設定値は一時的な操作ではなく、再デプロイや再起動後にも維持される管理方法で反映します。当日は変更担当、監視担当、判断責任者を分け、観測値に基づいて進行します。
block.enabled=trueを永続設定する
設定ファイルの最小例は hiero:
mirror:
importer:
block:
enabled: true です。環境変数を使う場合の正確な名前と変換規則は採用版のConfigurationで照合してください。
hiero.mirror.importer.block.enabled=trueを永続設定します。シェル内で一時的に環境変数を設定するだけでは、Podの再作成やホスト再起動で失われます。Git管理されたデプロイ定義、承認済みの構成管理、Secret管理など、自社の通常の方法で反映し、実行中プロセスが読み込んだ値をログまたは設定表示で確認します。
キー名は階層表現と環境変数表現で変換規則が異なる場合があります。綴りが正しくてもバインドされず既定値のままになる事故を防ぐため、採用版のConfigurationを参照します。設定ファイルへ書いた値と、アプリケーションが解釈した値を同一視しないことが大切です。
再起動後もBlock Stream取り込みが続くことを確認する
有効化後に計画的な再起動を行い、最新の処理位置から取り込みが再開することを確認します。再起動前後の最終ブロック番号、時刻、エラー、再処理件数を比較します。高可用構成では、複数Importerの役割交代やリーダー選出も対象です。一台だけの成功でクラスタ全体を正常としないでください。
再接続時に短い遅延が生じても追いつけば直ちに障害とは限りません。問題は遅延が縮まらず拡大すること、同じブロックで再試行し続けること、欠落を飛ばしてAPIだけ応答することです。通常時の追従速度を基準に、警告と重大アラートの条件を決めます。
旧Record Streamへの依存が残っていないか点検する
Importer以外にも、監査バッチ、バックアップ、監視、分析、通知が旧Record Streamを参照していないか確認します。旧バケットへのリクエストが切替後も続いているなら、意図した履歴参照なのか、移行漏れなのかを分類します。アクセスが成功することは、新規データを得られている証拠ではありません。
依存調査には最終処理時刻を持たせるのが有効です。入力オブジェクトの最終更新、データベースの最新合意時刻、下流成果物の生成時刻をつなげて見れば、どこで停滞したかを切り分けられます。旧経路の廃止は、必要な履歴保持と復旧手順を確認してから計画的に行います。
切替後のデータ鮮度と運用状態を検証する
切替完了の判定は、デプロイ成功や200応答ではなく、データが現在時刻へ追従していることです。公式ガイドは最新ブロックAPIを使った確認方法を示しています。API応答、最新時刻、連続性、エラーログ、取得元を組み合わせ、表面的な正常に惑わされないようにします。
/api/v1/blocks?order=desc&limit=1で最新時刻を確認する
必須：curl -fsS 'https://<mirror-host>/api/v1/blocks?order=desc&limit=1' | jq '.blocks[0] | {number,timestamp}' を数回実行し、numberとtimestampを確認します。合格条件は番号が欠落なく単調に進み、最新時刻との差が概ね5秒以内へ収束することです。
/api/v1/blocks?order=desc&limit=1を呼び、最新ブロックの時刻を取得します。降順で1件に絞ることで、Mirror Nodeが保持する最も新しいデータを確認できます。認証やロードバランサーを含め、利用者が実際に通る経路から実行すると、バックエンド単体だけでは見えないキャッシュやルーティングの問題も検出できます。
複数リージョンや複数レプリカがある場合は、それぞれの経路を確認します。一部だけ古いDBを参照していると、呼び出すたびに新旧の応答が混ざることがあります。最新ブロック番号と時刻を時系列で保存し、単調に進むことも確認してください。
実時刻との差が概ね5秒以内かを判定する
公式ガイドの目安は、最新ブロックの時刻が実時刻から概ね5秒以内であることです。これは保証値ではなく、取り込みが現在へ追従しているかを見る運用上の判定材料です。比較するホストの時計がずれていると誤判定するため、時刻同期も確認します。
5秒を超えた瞬間だけでページングするのではなく、継続時間、増加傾向、取得元切替の状況を合わせて評価します。一時的な遅延が回復するか、差が広がり続けるかで意味が変わります。ダッシュボードには現在値だけでなく推移を表示し、切替前の基準値とも比較してください。
公式StatusとRelease Notesで切替後も変更を追う
Hedera StatusではネットワークとMirror Nodeの稼働状況を確認できます。2026年10月27日時点の現在地と、将来の切替予定を混同しないためにも、実ネットワークの版とメンテナンス情報を継続して追います。自社だけの障害か、ネットワーク側の事象かを切り分ける材料になります。
Release Notesでは切替後も修正やセキュリティ更新が公開されます。最低版へ一度上げて終わりではなく、更新を評価する担当と周期を決めてください。公式Statusが正常でも、自社のIAM、接続先、DB、Importerが原因で停滞することはあります。外部ステータスと自社の鮮度監視は代替関係ではありません。
Mirror Node運用者向け最終チェックリスト
実施順を短くまとめます。まず公式ガイドで日程と最低版を再確認し、実行中Mirror Nodeの版を棚卸しします。次にv0.165.1までの修正を評価して採用版を決め、テストネットで初回同期、追従、再起動、証明検証を試します。その後、3ネットワークのrecent-block-streamsバケットにLIST・GETを付与し、公式ランブックで終了コード0を確認します。
- Mirror Node運用またはRecord File直接利用の有無を判定する
- v0.164.0以上を満たし、後続版とセキュリティ修正を評価する
- mainnet・testnet・previewnetのバケット権限を実行環境から検査する
- AUTO、自動発見、FILEフォールバック、手動上書きを点検する
block.enabled=trueを永続設定し、再起動試験を行う- 最新ブロックAPIで時刻差と連続性を監視する
- Status、Release Notes、Cutover Guideの変更を切替後も追う
一般のAPI利用者は大規模改修を急ぐ必要はありませんが、提供者の告知を確認し、重要機能の回帰試験を行うと安心です。運用者は「起動しているか」から「新しいデータを検証しながら取り込み続けているか」へ監視の焦点を移してください。この切替はHederaのデータ配信基盤に関するものであり、HBARの将来価格を直接示す材料ではありません。
