第11章 デプロイと運用#
11.0 本章の位置づけ#
本章は、リファレンス実装を mainnet に公開し、運用を定常化するまでの手順を扱います。ここで最も重要なのは、実施済みの手順と未実施の手順を明確に書き分けることです。
本書のリファレンス実装で実施済みなのは、次の三つです。devnet でのエンドツーエンド検証(第9章 T-40)、LiteSVM による全 26 テスト、CI の実機グリーン(第9章 9.7)です。一方、未実施なのは、mainnet へのデプロイ、upgrade authority のマルチシグ移管、プログラムの immutable 化です。
したがって本章では、mainnet デプロイ手順(11.2)とマルチシグ移管(11.3)は「未実施であり、手順は公式一次情報に基づく一般的な流れ」として提示します。これらを実施済みと誤読しないでください。対して、運用ランブック(11.4)は、本リポジトリのテストで実証済みの操作を標準作業手順書(SOP)の形にまとめたものです。各手順に、それを裏づけるテスト ID を付します。
11.1 デプロイ前チェックリスト#
mainnet デプロイの前に確認すべき項目と、本リファレンス実装での現状を対応させます。
| チェック項目 | 内容 | 本リファレンスでの状態 |
|---|---|---|
| 監査完了 | 第三者監査を受け、指摘を解消したか | 未委託(第10章 10.4。手順は提示済み) |
| テスト・CI | 全テストが通り、CI ゲートが緑か | 完了(26 テスト成功、CI 実機グリーン。第9章 9.7) |
| devnet リハーサル | 実クラスタでの動作を確認したか | 完了(devnet E2E。第9章 T-40。ミント作成 TX を finalized で確認) |
| 権限移管 | authority をマルチシグへ移管したか | 未実施(11.3。手順は一次情報に基づき提示) |
| Verifiable Build | 検証可能ビルドを実施・公開したか | 未実施(第10章 10.5。mainnet 未デプロイのため対象なし) |
| 法務確認 | 免責・規制関連記述の法務レビューを終えたか | 公開前に必須(第1・2章、設計書 3.7 の人間レビュー) |
このチェックリストは、すべての項目が「完了」になってから mainnet デプロイに進むことを想定しています。本リファレンス実装は、教材としての完成度(テスト・CI・devnet 実証)には達していますが、mainnet 公開に必要な監査・権限移管・法務確認は未完了です。
11.2 mainnet デプロイ手順(本書リポジトリは未実施)#
本書のリファレンス実装は mainnet へデプロイしていません。 本節のコマンドは、公式ドキュメント(solana.com/docs)に基づく一般的な流れであり、本リポジトリで実行検証したものではありません。実施時は、公式ドキュメントで現行の手順・フラグを一次情報として再確認してください。
なお、本リポジトリで実施済みの実クラスタ操作は devnet です。第9章 T-40 で create-mint.ts を devnet で実行しました。4 拡張と Metadata 本体を持つミントの作成 TX が finalized になることを確認しています。以下の mainnet 手順は、この devnet 実績の延長線上にある未実施の工程です。
11.2.1 デプロイコストの見積り#
プログラムのデプロイには、プログラムサイズに応じたレント免除相当の SOL が必要です。デプロイ前に、ビルド成果物(.so)のサイズからおおよそのコストを見積もります。アップグレード可能な形でデプロイする場合、buffer account の確保分も考慮します。具体的なレント額は変動するため、公式ドキュメントとネットワークの現況で確認してください。
11.2.2 priority fee#
mainnet は混雑時に priority fee(優先手数料)の付与が有効です。デプロイのような大きなトランザクションでは、取り込みの確実性を上げるために priority fee を設定することを検討します。額はネットワークの混雑度に依存するため固定値を置きません。
11.2.3 失敗時のリカバリ#
プログラムデプロイは複数のトランザクションに分割して実行されるため、途中で失敗することがあります。その場合、確保済みの buffer account を用いてデプロイを再開できます。失敗したデプロイの buffer account を放置すると SOL がロックされたままになるため、再開または閉鎖(回収)の手順を運用に含めます。詳細な再開コマンドは公式ドキュメントを参照してください。
11.3 upgrade authority のマルチシグ移管と immutable 化(未実施)#
本書のリファレンス実装では、upgrade authority のマルチシグ移管および immutable 化を実施していません。 本節は、その考え方と一般的な手順を示すものです。
11.3.1 なぜマルチシグへ移管するか#
デプロイ直後、upgrade authority は単一の鍵(デプロイ者)が保持します。この状態は単一障害点であり、鍵の漏洩がプログラムの改竄に直結します。金融資産を扱うプログラムでは、upgrade authority をマルチシグへ移管し、アップグレードに複数者の承認を要する体制にすることを推奨します。これは第10章 10.2 で棚卸しした権限分離の一部です。
11.3.2 マルチシグの代表例(Squads)#
Solana で upgrade authority のマルチシグ管理に用いられる代表例に Squads があります。配布元は Squads-Protocol/v4(org: Squads-Protocol、非フォーク、ライセンス AGPL-3.0)で、Solana 公式 org ではなく第三者(Squads Protocol)製です(確認日 2026-07-27)。v4 プログラムは mainnet-beta の SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf にデプロイされています。
特定ベンダーの推奨ではなく、選定は自社の運用体制に合わせて判断してください。選定基準としては、監査実績・利用実績・upgrade authority 管理への対応・時限ロックやロール分離などの機能有無が挙げられます。導入時は、第5章 5.6 のサードパーティ資産の審査観点(公式性・実績・内容確認)に照らして評価してください。
11.3.3 移管の考え方#
upgrade authority の移管自体は、Solana の標準機能(solana program set-upgrade-authority 相当)で行います。マルチシグを使う場合は、移管先をマルチシグの権限アカウント(PDA)にします。以降のアップグレードは、そのマルチシグでの承認を経て実行します。具体的なコマンド・アカウント指定は、Solana 公式ドキュメントと、採用するマルチシグ(例:Squads のドキュメント docs.squads.so)を一次情報として実施時に確認してください。
11.3.4 immutable 化の判断基準#
アップグレードを恒久的に不可能にする(immutable 化)と、改竄リスクは最小化されますが、脆弱性が見つかっても修正できなくなります。immutable 化は、次のような条件が揃ってから判断することを推奨します。
- 十分な監査・実運用期間を経て、重大な変更の必要性が低いと判断できること。
- スキーマ変更・機能追加の予定がないこと。
- 万一の不具合に対して、プログラムのアップグレード以外の対処(発行の停止、別ミントへの移行など)で対応可能な体制があること。
immutable 化は不可逆であるため、慎重に判断してください。
11.4 運用ランブック(標準作業手順書)#
本節は、本リファレンス実装で実証済みの運用操作を、標準作業手順書(SOP)の形にまとめたものです。各 SOP は「前提 / 権限保持者 / 手順 / 検証 / 監査証跡 / 実証テスト」の定型で記述します。ここに示す操作は、第9章のテストで動作を確認済みです。
注意: オンチェーン残高が法的権利の唯一の根拠になるとは限りません(法的ストラクチャに依存します。第2章・第8章)。以下の操作は技術的手順であり、その発動の是非や法的当否は専門家に確認してください。
11.4.1 SOP-1:投資家の追加(オンボーディング)#
- 前提: 対象投資家の KYC が完了していること(第8章 8.2)。ミントは作成済みで、口座は Default Account State により既定で Frozen であること(第6章)。
- 権限保持者: registry admin(登録)、freeze authority(thaw)、mint authority(発行)。
- 手順:
register_investorで対象投資家を registry にApprovedとして登録する。- 対象の Associated Token Account を作成する(既定で Frozen)。
- freeze authority で当該口座を thaw する。
- mint authority で発行(
mint_to)し、配布する。 - 検証: thaw 後に発行・受領・移転が成立すること。thaw 前は受領・移転できないこと。
- 監査証跡:
register_investor/ 状態変更のmsg!ログ(第7章 7.6)、発行・thaw の各 TX。 - 実証テスト: 第9章 T-11(KYC 登録 → thaw → mint_to → 移転までの一連が成立)。thaw 前の受領不可は T-10。
11.4.2 SOP-2:凍結(サスペンド)#
- 前提: 対象投資家がすでに登録済みであること。
- 権限保持者: registry admin(状態変更)、freeze authority(口座 freeze)。
- 手順:
set_investor_statusで対象投資家をSuspendedに変更する(以降、その投資家が関与する移転は Hook が拒否する)。- 必要に応じて、freeze authority で対象口座を freeze し、移転を口座レベルでも停止する。
- 検証:
Suspended化後、その投資家を送信者・受信者とする通常移転が失敗すること。再 freeze した口座からの移転が失敗すること。 - 監査証跡:
set_investor_statusのmsg!(対象投資家と新状態を記録)、freeze の TX。 - 実証テスト: 第9章 T-02 / T-03(Suspended を含む移転の失敗)、T-12(再 freeze で移転停止)。
11.4.3 SOP-3:強制回収(thaw → 回収 → 再 freeze)#
- 前提: 発行体が permanent delegate を保持していること。回収先のトレジャリー口座が registry に Approved 登録されていること。発動が社内規程・法務判断で承認されていること(第10章 10.7)。
- 権限保持者: permanent delegate(強制移転)、freeze authority(thaw / 再 freeze)、registry admin(トレジャリー登録)。
- 手順:
- 対象口座が Frozen の場合、freeze authority で thaw する(凍結中は Token-2022 が移転自体を拒否するため)。
- permanent delegate の署名で、対象残高を回収先トレジャリーへ強制移転する。
- 回収後、対象口座を 再 freeze する。
- 検証: 回収が成立すること。回収先が未登録だと失敗すること(回収先も Approved 必須)。第三者(delegate 以外)の強制移転が失敗すること。
- 監査証跡: 強制移転経路は
FORCE_TRANSFER via permanent delegateの program log に明示的に記録される(第7章 7.5.3 / 7.6)。thaw / 再 freeze の各 TX。 - 実証テスト: 第9章 T-20(強制回収の成立)、T-22(未登録トレジャリーへは失敗)、T-21(第三者は失敗)、T-23(凍結中は失敗 → thaw 後成功。thaw → 回収 → 再 freeze の順序を実証)。
設計上の要点: 強制回収も Token-2022 の移転経路であり、Transfer Hook は同様に走ります。したがって回収先トレジャリーも Approved でなければなりません。Hook を迂回する例外経路は設けていません(コンプライアンス保証を崩さないため。第7章 7.5)。
11.5 モニタリングとアラート#
運用中に監視すべきメトリクス・イベントを整理します。本実装は監査証跡を program log(msg!)で残すため、これを監視・突合の起点にします。監視基盤(RPC・Webhook・Geyser 系)の選定は第8章 8.5 で扱っており、本節では「何を監視するか」に絞ります。
| 監視対象 | 何を検知するか | 対応する実装・出典 |
|---|---|---|
FORCE_TRANSFER ログ |
強制回収の発動 | Hook の program log(第7章 7.5.3 / 7.6) |
| freeze / thaw の発生 | 口座凍結・解除の操作 | Token-2022 の口座状態変化 |
register_investor / set_investor_status |
投資家の登録・状態変更 | registry の msg!(第7章 7.6) |
| upgrade の実行 | プログラムのアップグレード | upgrade authority による操作(移管後はマルチシグの承認記録と突合) |
| 移転の失敗率・異常な試行 | 未許可移転の試行の増加 | Hook の失敗(監視は台帳突合と併用。第8章 8.5.3) |
これらのイベントは、投資家台帳・社内記録と突合し(第8章 8.5.3)、想定外の操作をアラートします。特に強制回収・凍結・アップグレードは影響が大きいため、リアルタイムのアラートを設定することを推奨します。
11.6 アップグレード手順(スキーマ変更)#
プログラムのアップグレードは、11.3 で移管したマルチシグの承認を経て実行します。ここでは、状態(アカウント)のスキーマ変更を伴う場合の考え方を示します。
- 後方互換な追加: 既存アカウントのレイアウトを壊さない追加(末尾フィールドの追加など)は、移行(migration)が比較的容易です。既存アカウントの読み取り互換性を必ずテストで確認します。
- 破壊的変更: フィールドの型変更・順序変更・削除は、既存アカウントの再解釈を壊します。この場合は、移行命令(旧レイアウトを読み、新レイアウトへ書き換える)を用意するか、新旧を並存させる設計を検討します。Anchor v1 系のスキーマ・移行に関する機構を用いる場合は、その仕様を一次情報(anchor-lang.com)で確認してから設計してください。
- アップグレード後の検証: アップグレード後は、Verifiable Build(第10章 10.5)でオンチェーンバイナリとソースの一致を再確認し、主要な運用フロー(SOP-1〜3)がリグレッションしていないことをテストで確認します。
本リポジトリではアップグレードの実機実行は行っていないため、上記は設計上の指針です。実施時は Anchor・Solana の公式ドキュメントを一次情報として手順を確定してください。
11.7 本章の自己チェック表#
| 観点 | 結果 |
|---|---|
| 実施済み/未実施の書き分け | mainnet デプロイ(11.2)・マルチシグ移管(11.3)・immutable 化(11.3.4)・アップグレード実機(11.6)は「未実施・手順は一次情報に基づく」と各節冒頭で明記。実施済み(devnet E2E=T-40 / テスト26件 / CI 緑)と区別した |
| 運用ランブックの実証 | SOP-1〜3 は本リポジトリのテストで実証済みの操作に限定し、各 SOP に実証テスト ID(T-10/11, T-02/03/12, T-20〜23)を付した |
| スタイル規則違反 | なし。です・ます調で統一。相互参照は番号(第2/5/6/7/8/9/10章、7.5/7.6/8.5/9.7/10.2/10.5/10.7)。マーケティング語彙・価格/投資リターン言及なし。法的当否は「専門家に確認」で統一(11.4 冒頭) |
[要検証] の残数 |
0件。未実施の手順は本文で「未実施」と明記し、コマンドは一次情報に基づく一般的な流れとして提示(実行検証していない旨を地の文で書き分け。タグは残さない方針) |
| 一次情報の帰属確認 | Squads=Squads-Protocol/v4(第三者・非公式 org・AGPL-3.0・mainnet program ID を明記。特定ベンダー推奨にならないよう選定基準+代表例で記述)。mainnet・アップグレード手順は公式ドキュメントを根拠と明記 |
| バージョン表との不一致 | なし(本章はバージョン依存の固定コマンドを本文で断定していない。デプロイ・移管コマンドは版・現況により変わり得る旨を明記) |
| 特定ベンダー非推奨の徹底 | マルチシグ(11.3.2)・監視基盤(11.5)は選定基準+代表例に留め、推奨をしていない。第8章・第5章の審査観点へ接続 |