Solana Microscopeとは？プログラムとSquadsマルチシグを自己運用で監視する方法

オンチェーンでは管理操作が続いているのに、古いIDLで復号できず、さらに通知経路も止まっていた――画面に異常が見えないことは、異常がない証明にはなりません。Solana Microscopeは、SolanaプログラムとSquadsマルチシグの活動を取得・復号し、Grafanaで可視化・通知する自己運用型のオープンソースソフトウェア（OSS）です。こうした「活動を見られない状態」を減らせますが、不正操作を止める制御機能ではなく、導入だけで監視が完成するわけでもありません。

この記事は、監視担当者とSolanaプログラム運用者が、監視範囲を見極め、Docker Composeの最小構成を起動し、既知の取引とテスト通知で成功を判定できるところまでを扱います。導入前に決めるのは、①対象のプログラムIDとIDL、②取得から通知までの全経路、③切断後の復旧と保存方針、④標準機能で拾えない事象の補完策です。SOLの価格や投資成果を予測する記事ではありません。前提から確認したい人はSolanaの基礎も参照してください。

Solana Microscopeとは何か

Solana Foundationが公開した監視・アラート用OSS

MicroscopeはSolana FoundationがMITライセンスで公開したOSSです。確定済みトランザクションを取り込み、対象プログラムのIDLに沿って命令とイベントを構造化し、ダッシュボードとアラートへ渡します。必要なときに人が検索するブロックエクスプローラーとは異なり、あらかじめ決めた対象を継続取得し、確認すべき事象を絞る運用に向きます。

プログラムとSquadsマルチシグを監視する目的

Solanaのトランザクションには複数命令を含められます。どのプログラムを呼び、どの引数を渡したかを解釈できれば、管理操作や設定変更などを区別できます。Squadsは複数主体の承認と実行を構成するSmart Account基盤です。提案作成、承認、実行を追うことで、承認待ちなのか実行済みなのかを切り分けやすくなります。

自己運用であることの意味

MicroscopeはSolana Foundationへデータを送るホスト型サービスではありません。自組織の環境へ配置し、接続先、保存領域、認証、通知を管理します。置き場所を選べる一方、可用性、更新、バックアップ、アクセス制御も利用者の責任です。OSSが無料であることと運用費がゼロであることは別で、RPC、ストリーム、クラウド資源、保存容量、保守作業を見積もります。

トランザクション取得から可視化・通知までの仕組み

処理は「取得→復号→保存・集計→表示→通知」と進みます。一箇所でも止まれば、オンチェーンで活動が続いていても画面や通知に現れません。

Yellowstone gRPCとJSON-RPCによるデータ取得

Geyserはバリデーターの取引・アカウント更新を外部へ流す仕組みです。Yellowstone gRPCは、そのGeyser由来データをフィルター付きストリームで受け取れ、低遅延のライブ監視に使えます。接続認証と再送範囲を確認し、切断を前提にします。JSON-RPCモードは確定済みデータをポーリングします。履歴補完ではgetSignaturesForAddressで対象アドレスの署名をたどり、getTransactionで詳細を取得します。高活動プログラムでは要求量と費用が増え、プロバイダーの履歴保持がギャップ回復を左右します。

IDLとCarbon生成デコーダーによる命令・イベントの構造化

IDLは命令やイベントの名前、引数、構造を解釈する手掛かりです。MicroscopeはプログラムIDとIDLをビルド入力にし、Solanaデータを型付きレコードへ変換するCarbonの生成デコーダーで構造化します。不一致なら起動を拒否しますが、将来も正しい保証ではありません。プログラム更新時はIDL、デコーダー、イメージを同期し、既知の取引で値まで検証します。

Loki・Prometheus・Grafanaの役割分担

構造化ログはLoki、数値メトリクスはPrometheusへ送られます。Lokiはラベルなどのメタデータを索引化し、個別活動の検索に使います。Prometheusは回数や状態を時系列で保存します。Grafanaが両方を画面へまとめ、ルールを評価します。詳細ログと集計値の分担であり、同じ内容を二重保存する仕組みではありません。

Slack・Telegram・PagerDutyへの通知経路

Grafanaのcontact point（アラートの送信先設定）を通じてSlack、Telegram、PagerDutyへ通知できます。ルール評価と外部送信は別工程なので、通知統合がなければルールが正常でも外部メッセージは届きません。本番前に意図的なテスト事象を作り、取得から通知受信まで全経路を確認します。担当、再通知、解消通知、連絡不能時の代替経路も決めます。

Microscopeで監視できる対象とできない対象

復号済み命令とオンチェーンイベント

監視対象はIDLで復号した命令、通常のlogまたはevent-CPI由来のイベントです。event-CPIは、別プログラム呼び出し（CPI）のデータとしてイベントを記録する方式です。event、instruction、multisigごとにフィールド条件、重要度、通知先を指定できます。重要な管理操作は即時通知、日常処理は画面だけという分け方が可能です。条件が狭すぎれば形式変更を見落とし、広すぎれば通知疲れを招くため、少数の重要事象から始めます。

Squads v3・v4・v5のマルチシグ活動

対応するSquads v3・v4・v5活動を共通形式へ正規化します。ただしSquadsに関係する全活動を意味しません。利用版とstate address（マルチシグ設定を保持する内部アカウントのアドレス）を確認し、提案作成・承認・実行のどの段階で誰へ知らせるか決めます。提案作成だけで設定が変わるとは限りませんが、早期確認には役立ちます。

イベント復号失敗の検知

復号失敗は、IDL更新漏れ、想定外データ、デコーダー非互換の入口になります。失敗した内容を正常イベントとして読めなくても、失敗自体を検知すれば静かに見落とし続ける状態を避けられます。

生ログ検索や一部Squads活動などの対象外

任意の生ログ文字列へ一致させる汎用監視ではありません。生ログだけの情報には別の収集・検索を組み合わせます。v4設定変更やv5非同期設定変更は実行時に細目が出ない場合があり、作成イベントの監視が重要です。v5でSettingsではなくpolicyアカウント（権限ルールを保持するアカウント）だけを参照する命令は対象外です。マルチシグの失敗命令は画面とメトリクスに残ってもページ通知を発火しないため、要件次第で補完します。

導入方式と必要な構成を選ぶ

1デプロイにつき1プログラムと任意の1マルチシグ

公式構成は1デプロイにつき1プログラムと、必要に応じて任意の1 Squadsマルチシグです。複数プログラムは分けます。台帳にはデプロイ名、プログラムID、IDL版、Squads版とstate address、データソース、通知先、担当を残します。deploymentラベルは識別用で、権限境界ではありません。

Docker Composeで始めるローカル構成

Docker Composeならindexer、Loki、Prometheus、Grafanaなどを一つのYAMLで管理でき、検証の入口になります。しかしローカルで動くことと高可用な本番運用は別です。再起動、ボリューム、秘密情報、ホスト障害、容量を確認します。docker compose down --volumesは履歴とチェックポイントを失い得るため、通常停止と削除を手順で分けます。

Terraformを使うAWS・GCP構成

AWS・GCP向け展開はTerraformを使います。適用前にplanで置換・削除をレビューし、stateを保護します。クラウド化だけで高可用にはなりません。標準は単一ノードで、外部保存、自動バックアップ、履歴移行は別途必要です。VM交換やdestroyで消える対象を確かめます。

既存Kubernetes・Grafana Cloudへ接続する構成

既存の観測基盤へ組み込むKubernetes資料は完成済み配布物ではなく参照マニフェストです。namespace、永続化、NetworkPolicy、Secret、更新方法へ合わせます。Grafana Cloudでは書き込み資格情報を環境間で共有しないことが重要です。同じ資格情報が漏れると、別デプロイを名乗るデータやアラートを送られる可能性があるため、信頼境界ごとに分離します。

機能検証ならDocker Compose、クラウド統制へ載せるならTerraform、すでに観測基盤と当番運用があるならKubernetesまたはGrafana Cloudが候補です。本番向けかは方式名ではなく、許容停止時間、復元試験、保存先、担当体制で判断します。

プログラム・IDL・アラートを設定する

プログラムIDとIDLをビルド入力に指定する

監視対象IDと対応IDLを確定し、取得元とコミットを記録します。似た別環境のIDや古いIDLを混ぜません。これらは表示設定ではなくデコーダーのビルド入力です。正常系の既知トランザクションを用意し、命令名、主要フィールド、イベント、成功・失敗を検証します。

イベント・命令・マルチシグの条件を定義する

資産移動や権限変更など見逃した場合の影響が大きい事象から定義します。日常的な大量処理と、まれでも即応する処理を分けます。条件名だけでなく、正常理由、確認画面、連絡先を手順へ結び、設定変更後は発火と非発火を試します。

重要度とGrafanaの通知先を設定する

重要度は珍しさではなく緊急度と影響で決めます。全件を最高にすると重要通知が埋もれます。contact pointへ実際の統合を設定し、Slackは共有確認、PagerDutyは当番呼び出しなど用途を分けます。通知へ秘密鍵やトークンを含めません。安全管理は秘密鍵を守る基本も参照してください。

実在プログラムのサンプルを教材として参照する

Jupiter Lendの例は、実在プログラムのID、IDL、Squads、アラートを組み合わせる教材です。本番監視サービスではなく、その値を自分の対象と要件へ置き換える必要があります。

Docker Composeの最小構成で監視を試す

最小構成には、Docker EngineとCompose v2、Yellowstone gRPCまたはSolana JSON-RPCのエンドポイント、対象プログラムID、対応IDLが必要です。Squadsを監視する場合だけ、default vault、内部state address、v3・v4・v5の版も用意します。最初は読み取り専用の検証環境で試します。

リポジトリを取得して設定を作る

git clone https://github.com/solana-foundation/solana-microscope.git
cd solana-microscope
cp microscope.toml.example microscope.toml

microscope.tomlのprogram_idを対象へ、idl_pathを対応IDLのパスへ置き換えます。IDLは表示設定ではなくデコーダーのビルド入力です。取得元、コミット、ハッシュ、更新責任者を記録します。Squadsを使わないなら[multisig]は省き、使うならvault、state address、versionの3値を一組で設定します。

program_id = "<PROGRAM_ID>"
idl_path = "idl/your-program.json"

[datasource]
mode = "rpc"
poll_interval_seconds = 5
replay_window_slots = 300

上は低遅延より導入しやすさを優先したRPC例です。RPC_URLを設定し、GEYSER_URLは空にします。Yellowstoneならmodeをyellowstoneにし、GEYSER_URLと必要なトークンを指定します。秘密情報はGit管理対象外の.envへ置きます。

RPC_URL=https://your-solana-rpc-endpoint
GRAFANA_ADMIN_PASSWORD=replace-with-a-strong-password
SLACK_WEBHOOK_URL=

生成・起動して正常性を確認する

プログラムIDまたはIDLを変えたらデコーダーを再生成し、その後にスタックを起動します。設定とビルド済みデコーダーが一致しなければindexerは起動を拒否します。

just generate
just up
docker compose ps
docker compose logs --follow indexer

合格条件はコンテナ起動だけではありません。http://localhost:9091/healthzでプロセス稼働、http://localhost:9091/readyzで起動完了とデータソース到達、http://localhost:3000でGrafana表示を確認します。さらに既知の署名を一つ選び、期待する命令名・イベント名・主要フィールド・成功または失敗の値がLokiと画面に現れることを照合します。活動が偶然ない状態と取得停止を区別するため、最終取得時刻と処理遅延も見ます。

確認結果を入口から出口まで追跡する

動作確認では、同じ署名を入口から出口まで追います。まずRPCまたはYellowstoneが対象取引を返した時刻を記録し、indexerログで処理されたことを確かめます。次にLokiの構造化レコードで、プログラムID、署名、slot、命令またはイベント、主要フィールドが期待値と一致するか確認します。Prometheusでは最終成功時刻、処理件数、失敗数などの数値が更新され、Grafanaのパネルが同じデータソースを参照していることを見ます。この連鎖が途中で切れた場合は、画面全体を「動いている」と判定しません。

成功だけでなく、意図的に誤ったIDLや到達不能なエンドポイントを検証環境へ与え、起動拒否やreadyzの失敗を確認すると、静かな見落としを防ぐ仕組みも評価できます。本番の秘密情報や通知先を使って破壊的な試験はせず、専用の資格情報とテスト用contact pointを使います。試験後は設定を戻し、再起動後にも同じ既知署名を検索できるか、チェックポイントが維持されるかを確認します。

テスト通知まで通して成功を判定する

[[alerts]]にはIDLが宣言するeventまたはinstructionの名前、条件、重要度、送信先を指定します。存在しない名前は起動時に拒否されます。結果を予測できる既知事象で一致・不一致を各1回試します。Grafanaのcontact pointにもSlackなど実際の統合が必要で、channelsだけでは外部通知は届きません。

設定版、起動時刻、テスト署名、Lokiのレコード、Grafanaのルール評価、受信時刻を証拠として保存します。通知へ秘密鍵やトークンを含めません。通常停止はdocker compose downで行い、データを消す--volumesを付けないよう手順を分けます。ここまでで最小構成の確認は完了ですが、本番化にはギャップ復旧、保持、自己監視が必要です。

履歴バックフィルと監視ギャップに備える

ライブ監視は起動後の活動を対象にする

ライブ監視は基本的に起動後の活動を扱い、過去履歴は自動では入りません。本番開始時刻、最初のslotや署名、チェックポイントを記録し、活動がないのか取得できないのかを区別します。

RPCバックフィルで過去トランザクションを補完する

過去分はRPCで署名一覧と取引詳細を取得して復号します。データは過去時刻へ格納され、通知対象にはなりません。範囲、RPC、想定件数を決め、履歴保持、レート制限、費用を確認します。完了後は先頭・末尾、件数、復号失敗を記録します。

重複行とPrometheus非対応を確認する

既存データと範囲が重なるとイベント表に重複行が生じ得ます。またPrometheusメトリクスはバックフィルされません。イベントが入っても過去の時系列グラフが同じように埋まるわけではないため、ライブ分と補完分を明記します。

Yellowstone切断時はRPC復旧を組み合わせる

切断が再送窓を超えたり再起動をまたいだりするとギャップが残り得ます。最後の正常地点と再開地点から欠損候補を定め、必要区間だけRPCで補います。広すぎる補完は重複と要求量を増やします。チェックポイント（最後に安全に処理した位置の記録）を保護し、復旧訓練で確かめます。

誤検知・監視断・データ消失を防ぐ運用チェック

プログラム更新時にIDLとデコーダーを同期する

更新承認にIDL差分、デコーダー再生成、イメージ版、検証取引、ロールバックを含めます。新形式が先に本番へ出て古いデコーダーが読む時間を短くし、更新後の最初の活動を確認します。エラーがないだけでなくフィールド値まで見ます。

データソース・チェックポイント・Loki配信を自己監視する

組み込みアラートはデータソース停止、RPCポール停滞、チェックポイント破損、Loki配信断などを扱います。これは活動の異常ではなく、活動を見られない状態の警告です。最終成功時刻、処理遅延、エラー、保存先到達を組み合わせます。通常通知と同じ経路だけに依存しない工夫も必要です。

30日保持と削除操作による履歴消失に備える

ローカルのLokiとPrometheusは既定30日保持で、永久保管ではありません。長期調査が必要なら容量、費用、削除、復元を設計します。保持延長だけではディスク故障対策になりません。VM交換、Terraform destroy、ボリューム削除で履歴とチェックポイントを失い得ます。設定をGitへ置くことと観測データを復元できることは別です。

単一障害点とGrafana Cloud資格情報の共有を避ける

単一ノードや保存領域は単一障害点になり得ます。許容停止時間から外部保存、バックアップ、別経路の死活監視、再構築手順を決めます。書き込み資格情報は環境ごとに発行・保管・ローテーション・失効し、漏えい時の範囲を限定します。

Squadsの設定変更・対象外命令・失敗試行を補完監視する

作成イベント、実行結果、対応版、state addressを一組で点検します。失敗試行を即時対応したいなら、画面・メトリクスから別ルールを作ります。失敗は状態を変えなくても誤設定や侵害試行を示す場合がありますが、日常ミスまで即時通知すると負担が増えるため対象を絞ります。

変更履歴の確認と脆弱性の非公開報告を運用に組み込む

更新前にCHANGELOGを読み、設定、生成物、対応範囲への影響を評価します。検証環境で取引、通知、再起動、バックフィルを試します。脆弱性を見つけた場合は公開Issueへ詳細を書かず、SECURITY.mdが案内するGitHubのPrivate Vulnerability Reportingで再現方法、影響、対象版を伝えます。

導入判断は、対象とIDLを確定し、検知範囲が要件を満たすか確認し、配置とデータソースを選び、通知まで試す順で進めます。その後、ギャップ、保持、復元、自己監視、対象外事象の補完策を運用手順へ残します。Microscopeは監視であり制御ではなく、全活動を網羅するものでもありません。プログラム更新と監視定義を同期し、監視基盤自身も観測することが見落としを減らす基本です。

導入時に確認する一次資料

まず読む3件：公式紹介で目的と全体像、GitHub READMEで最新の要件・Quick start・制約、Operations Guideでエンドポイント選定と障害復旧を確認します。実装時は本文の出典カードとsourcesのURLから最新版を開き、最終確認日も記録します。

必要時の参照：設定値はExample Configuration、実在例はJupiter Lend Example、既存基盤への統合はKubernetes Guide、更新影響はCHANGELOG、脆弱性の連絡はSECURITY.mdを使います。一般技術の資料は、該当機能を変更・診断するときに各公式資料へ進みます。

本番導入前の確認手順

既出事項を再説明せず、次の確認表をリリース判定へ使います。「必須」は監視成立に不可欠、「推奨」は事故耐性を高める項目、「要件次第」は必要な組織だけが補完する項目です。

対象追加、IDL変更、データソース変更、通知先変更は再テストの契機です。未解決の制約、責任者、判断日、再評価条件も残します。 最終承認では、担当者以外が証拠を読み、同じ署名から同じ結論へ到達できるかも確認します。確認不能な項目は合格扱いにせず、期限と代替策を付けて未解決として残します。稼働後の最初の実取引でも取得、復号、表示、通知を再確認し、検証時だけ成立していた状態を見逃さないようにします。

まとめ

Microscope導入は、対象とIDLを確定し、方式を選び、最小構成を起動し、既知取引とテスト通知で全経路を証明する順で進めます。本番ではギャップ復旧、保持と復元、監視基盤自身の異常、標準機能の対象外を別々に扱います。Microscopeは監視であって制御ではなく、全活動を自動で網羅するものでもありません。プログラム更新と監視定義を同期し、「通知がない」だけで正常と判断しない運用が見落としを減らします。