---
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.
# アップグレード可能なスマートコントラクト
> 教育目的のみであり、投資またはセキュリティ上の助言ではありません。アップグレード権限により特権者がコントラクトの動作を変更でき、損失が生じる可能性があります。
## 直接の答え
アップグレード可能なスマートコントラクトとは、利用者を新しい主要アドレスへ移したり保存済み状態を捨てたりせず、実効ロジックを変更できるシステムです。Ethereum 互換ネットワークでは、通常プロキシが状態を保持し、`delegatecall` で実装コントラクトへ呼び出しを転送します。認可された更新は実装だけを替え、プロキシのアドレス、ストレージ、残高を維持します。
不変なバイトコードを書き換えるのではなく、間接参照を挟む仕組みです。欠陥修正や機能追加が可能な一方、出金、手数料、権限、会計を変更できる特権経路にもなります。現在のコードと、将来のコードを決める規則の両方を評価する必要があります。
すべてのプロキシが更新可能とは限らず、可変なシステムが常にプロキシを使うわけでもありません。新規コントラクトへ状態を移す方式や、更新を永久に無効化する方式もあります。表示名より実際のオンチェーン構成と権限が重要です。
## 仕組み
プロキシは実装アドレスを読み、`delegatecall` によりプロキシのストレージ文脈で実装コードを実行します。読み書きはプロキシに作用し、元の送信者と値は保たれます。ERC-1967 は実装、Beacon、管理者のスロットを標準化します。
Transparent プロキシは管理者呼び出しと利用者呼び出しを分離します。UUPS は更新ロジックを実装側に置き ERC-1822 互換性を使うため、認可が重要です。Beacon プロキシでは一度の Beacon 更新が多数のプロキシを変え得ます。
中心的制約は状態互換性です。変数の並べ替え、削除、型変更、継承変更はデータを壊し得ます。末尾追加型レイアウト、予約領域、ERC-7201 名前空間ストレージは役立ちますが、版間検証は必要です。
コンストラクタは実装自身を初期化し、プロキシのストレージは初期化しません。そのため `initialize` などを該当版について一度だけ呼びます。実装の直接初期化をロックし、後続移行には限定された再初期化処理を使います。
堅実な手順は次のとおりです。
1. 新旧実装のソース、コンパイラ、依存関係、レイアウト、アドレス、期待バイトコードを固定します。
2. 差分、互換性、初期化または移行、認可、依存関係、ロールバック前提を確認し、フォーク上で全取引を試験します。
3. 提案と実装アドレスを公開し、隠れた回避路なしに公称のマルチシグ、ガバナンス、タイムロックを適用します。
4. 実行後、実装または Beacon スロット、イベント、バイトコード、初期状態、役割、不変条件を記録ブロックで検証します。
5. スロット、役割、パラメータを監視し、ロールバックが常に安全とは仮定せず事故対応を準備します。
## 例
融資プロトコルが新しい返済機能を必要とし、プロキシは実装 A を使用中とします。チームは実装 B を配備し、B がストレージ末尾への追加だけであることを確認して移行を準備します。ガバナンスはバイトコードを公開し、48 時間のタイムロック後に更新します。同じアドレスが B を使い、残高はプロキシに残ります。
利用者はスロットが A から B に変わり、移行が一度だけ行われ、役割と残高が適切か確認します。ガーディアンがタイムロックを迂回できる、または署名者が B を任意コードに替えられるなら、その権力も信頼モデルに含まれます。
## リスク
- **特権的な差し替え：**管理者、マルチシグ、ガバナー、漏えい鍵が悪意ある実装を導入できます。
- **ストレージ破損：**非互換レイアウトが残高、所有者、mapping、会計を誤解釈させます。
- **初期化不良：**欠落、重複、公開された初期化処理が停止や支配権移転を招きます。
- **方式固有の障害：**Transparent、UUPS、Beacon、独自方式は異なる壊れ方をし、名称は正しさを保証しません。
- **見せかけのガバナンス：**緊急迂回、短い遅延、集中投票権、弱い署名管理があり得ます。
- **危険な移行や復元：**状態変更は不可逆になり、旧コードへ戻しても旧来の意味は戻らない場合があります。
- **検証の空白：**実装ソースの検証だけでは、プロキシの参照先、管理者、初期状態を証明できません。
- **監視・連携リスク：**エクスプローラーや連携先が古い実装を追跡し、Beacon 全体の変更を見逃す場合があります。
## よくある誤解
- **「このアドレスのコントラクトは不変だ」**プロキシのバイトコードが不変でも、実装または Beacon スロットで動作は変わります。
- **「マルチシグなら更新は分散化される」**署名者の独立性、閾値、運用、交代規則が堅牢な場合に限ります。
- **「タイムロックは悪意ある更新を防ぐ」**観察と退出の時間を作るだけで、コード自体を安全にはしません。
- **「ストレージ検査合格は安全の証明だ」**対象はレイアウトであり、ロジック、認可、オラクル、移行、経済性ではありません。
- **「更新権放棄で必ず支配権が消える」**管理者、Beacon、ガバナー、UUPS 認可、代替経路をオンチェーンで確認します。
## 関連トピック
- [スマートコントラクト](/ja/crypto/smart-contract/)
- [スマートコントラクト監査の読み方](/ja/crypto/contract-audit/)
- [マルチシグウォレット](/ja/crypto/multisig-wallet/)
- [タイムロック](/ja/crypto/timelock/)
## 出典
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals（参照日: 2026-08-22）
- [ERC-1822: Universal Upgradeable Proxy Standard (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals（参照日: 2026-08-22）
- [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) - Ethereum Improvement Proposals（参照日: 2026-08-22）
- [Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin Docs（参照日: 2026-08-22）
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs（参照日: 2026-08-22）
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Docs（参照日: 2026-08-22）
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation（参照日: 2026-08-22）
Source: https://wiki.fcontext.com/ja/crypto/upgradeable-contract/index.mdx