---
title: "プロキシコントラクトのアップグレードを監視する方法"
description: "アップグレード可能なプロキシの実装、ビーコン、制御権の変更を監視し、実行後にコード、ストレージ互換性、初期化、権限、重要な動作を検証します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# プロキシコントラクトのアップグレードを監視する方法
> 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 直接の回答
アップグレード可能なシステムでは、プロキシアドレスだけでなく制御経路も監視します。アラートには、アップグレードを承認・実行できる主体、必要な遅延、旧実装と新実装、初期化 calldata を含めます。実行後はオンチェーン設定を独立して読み取り、重要な動作をテストします。
プロキシアドレスと残高が変わらなくても、委譲先コードによって権限、手数料、会計、停止動作、出金ロジックが変わり得ます。以前の監査が新しい実装やその初期化を自動的に対象とするわけではありません。
## 仕組み
まずプロキシ方式を特定します。ERC-1967 は `eip1967.proxy.implementation`、`eip1967.proxy.beacon`、任意の `eip1967.proxy.admin` に別々のストレージスロットを定義します。実装の直接変更では `Upgraded`、ビーコンアドレスの変更では `BeaconUpgraded`、管理者スロットの変更では `AdminChanged` を発行することが推奨されます。ビーコンプロキシでは、プロキシのビーコンスロットを変えずにビーコン側の実装を変更できるため、ビーコンの `implementation()` も呼び出します。
管理者スロットだけから完全な権限モデルを推測してはいけません。Transparent プロキシは `ProxyAdmin` 経由で制御される場合があり、UUPS のアップグレード承認は現在のロジックコントラクトの `_authorizeUpgrade` に実装されます。所有者、ロール、マルチシグのしきい値、タイムロック、ガバナー、緊急経路、それらの制御を変更できる権限を追跡します。
イベント購読と定期的な状態読み取りを併用します。ERC-1967 はイベントを推奨しますが、すべての実装に発行を義務付けてはいません。独立した RPC エンドポイントから、チェーン、ブロック、トランザクション、プロキシ、実装またはビーコン、ランタイムコードハッシュ、実行者、関連する制御状態を記録します。予定、取消、実行の各操作を通知し、そのチェーンで定めた承認数またはファイナリティ方針を満たしてから状態を確定扱いにします。
## 例
あるレンディングプロキシは、24-hour のタイムロックを介した 3-of-5 マルチシグで制御されています。アップグレードが予定されると、監視システムは提案 ID、対象、calldata、最短実行時刻、現在の実装、提案された実装、ソースコードの検証状況を記録します。レビュー担当者はコードとストレージレイアウトを比較し、初期化呼び出しを調べ、ロール、外部呼び出し、手数料、停止規則、出金経路の変更を確認します。
実行後、監視システムは該当する ERC-1967 スロットを再読込し、デプロイ済みランタイムコードを検証し、実装バージョン、管理者またはロール保有者、停止状態、資産会計、読み取り専用の出金プレビューなどの事後条件を確認します。観測したアドレスやコードハッシュが審査済み提案と異なる場合、または定期ポーリングがイベントにない変更を発見した場合は、再度アラートを出します。
## リスク
- **制御リスク:** 表面上のマルチシグが、別の所有者、ロール、モジュール、ガバナー、緊急鍵、変更可能なタイムロックによって迂回される場合があります。すべての経路を最終署名者と遅延まで追跡します。
- **コードとストレージのリスク:** 未検証コード、非互換なストレージレイアウト、安全でない初期化、依存関係の変更は、状態を破壊したり意図しない権限を与えたりします。リポジトリのブランチや監査名だけでなく、実際にデプロイされた成果物を検証します。
- **監視リスク:** 単一の RPC、イベントのみのインデクサー、フロントエンド、ブロックエクスプローラーは遅延または誤る可能性があります。独立したデータソース間でイベント、ストレージ、バイトコード、トランザクションレシート、プロトコル状態を照合します。
- **対応リスク:** 担当者と訓練済み手順のないアラートでは間に合わないことがあります。遅延中に誰がレビュー、統合停止、連絡、退出を行うかを定め、性急な承認や非公式な復旧リンクにも追加リスクがあると認識します。
最低限の運用手順:
1. 各チェーン上のすべてのプロキシ、ビーコン、実装、管理者、ロール、アップグレード入口を棚卸しします。
2. スロット、コードハッシュ、制御状態、重要な読み取り専用結果の正常な基準値を保存します。
3. ガバナンスやタイムロックが可能にする場合は実行前に通知し、実行時または取消時にも通知します。
4. 実行された対象、calldata、実装、バイトコード、ストレージレイアウト、アップグレード後の状態を審査済み提案と比較します。
5. 予期しない変更、事後条件の失敗、ソース未検証、遅延の短縮または迂回をエスカレーションし、プロキシアドレスが不変であることを安全性の証明にしません。
## よくある誤解
- **誤解 1:「`Upgraded` を監視すれば十分だ。」** ビーコン実装の変更や非標準プロキシでは、別コントラクトの監視や状態ポーリングが必要です。イベントを直接読み取った状態と照合します。
- **誤解 2:「管理者スロットを見れば、すべてのアップグレードの制御者が分かる。」** このスロットは任意であり、Transparent、UUPS、ビーコン、ガバナンス、独自設計では権限を置くコントラクトや関数が異なります。
- **誤解 3:「ソース検証済み、または過去の監査があれば安全だ。」** 正確なリリースについて、デプロイ済みバイトコード、コンパイラとコンストラクタの前提、ストレージ互換性、初期化、設定、動作を検証します。
## 関連トピック
- [マルチシグモジュールのリスク](/ja/crypto/multisig-module-risk/)
- [プロキシコントラクト](/ja/crypto/proxy-contract/)
- [プロキシのストレージ衝突](/ja/crypto/proxy-storage-collision/)
- [プロトコルの緊急停止](/ja/crypto/protocol-emergency-pause/)
- [アップグレード可能なコントラクト](/ja/crypto/upgradeable-contract/)
## 出典
- [ERC-1967: プロキシストレージスロット](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (参照日: 2026-08-21)
- [プロキシ](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (参照日: 2026-08-21)
- [アップグレード可能なコントラクトの記述](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (参照日: 2026-08-21)
- [アクセス制御](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (参照日: 2026-08-21)
Source: https://wiki.fcontext.com/ja/crypto/proxy-upgrade-monitoring/index.mdx