【入門編】コントラクトのアップグレード可能性に伴うリスク管理 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

こんにちは！ブロックチェーンの世界やIoT・スマートコントラクトの開発に足を踏み入れたばかりの頃って、専門用語が多くて圧倒されてしまいますよね。「コードは法律（Code is Law）」なんて言われるけれど、作った後にバグが見つかったらどう修正するの？って疑問に思ったことはありませんか？

今回は、そんなスマートコントラクトの「アップグレード可能性（後から中身を書き換えられる仕組み）」に潜む危うさと、それをどうやって安全に守っていくのかについて、身近な防犯のたとえを交えながら、一歩ずつ優しく紐解いていきたいと思います。

—

1. 家の鍵に例える「アップグレード」のジレンマ

ブロックチェーン上のスマートコントラクトは、基本的には一度デプロイ（公開）してしまうと、後から書き換えることができません。これは「誰も勝手にルールを変えられない」という大きなメリットであると同時に、「もしプログラムにバグがあっても直せない」という諸刃の剣です。

ここで想像してみてください。あなたが新築のマイホームを建てたとします。
玄関のドアには、絶対にピッキングされない最強の電子ロックを設置しました。完璧ですよね？

ところが、住み始めてから数日後、設計ミスが発覚しました。「あれ、勝手口の窓の近くに、外から簡単に手を突っ込める隙間があるぞ……！」と気づいたのです。

もしその家が完全に「修正不可能（イミュータブル）」な構造だったらどうでしょう？泥棒が入ってくるかもしれない恐怖に怯えながら、家ごと建て替えるか、諦めて住み続けるしかありません。

そこで開発者たちは考えました。
「そうだ、遠隔操作で中身を新しいプログラムにすり替えられる『アップグレード可能な仕組み』を作ろう！」と。

これなら、不具合が見つかっても、まるでスマホのアプリをアップデートするように、スマートコントラクトの心臓部をパパッと最新の安全なものに書き換えられます。とっても便利で安心……に思えますよね？

—

2. 便利さの裏に潜む「最強のマスターキー」というリスク

ここで、セキュリティリサーチャーとして少し怖い現実のお話をしなければなりません。

アップグレードの仕組みを導入するということは、あなたの家の玄関に「この世のすべての部屋の鍵を開けられ、さらに壁の位置すら自由に変えられる、恐ろしく強力なマスターキー」を置くようなものなのです。

このマスターキー（管理者権限）を、もし「たった1人の開発者のポケット」に入れておいたらどうなるでしょうか？

ある日、その開発者のパソコンがウイルスに感染してしまったら？
もしかしたら、その開発者が魔が差して、夜中にこっそりマスターキーを悪用し、金庫の中身を持ち去ってしまうかもしれない（インサイダーリスク）？

実際に、DeFi（分散型金融）の現場では、この管理者権限が1つのアカウント（単一の秘密鍵：EOA）に集中していたために、ハッカーにその鍵を奪われて一瞬で全財産が抜き取られるインシデントが何度も起きています。便利さの代償として、「誰がその強大な権限を握るのか」という大きなガバナンスの課題が生まれるのです。

—

3. 泥棒を防ぐ知恵：「マルチシグウォレット」という合鍵の仕組み

「じゃあ、アップグレードなんて危なくて使えないの？」いいえ、そんなことはありません。ここで登場するのが、今回のテーマのもう一つの主役である「マルチシグ（Multi-signature：複数署名）ウォレット」です。

先ほどの「最強のマスターキー」の例えに戻りましょう。
重大なリフォーム（スマートコントラクトのアップグレード）をする際、1人の独断で勝手に壁を壊されたら困りますよね。

そこで、金庫を開けたり家の構造を変えたりするには、「信頼できる3人の家族のうち、最低2人が自分の鍵を持ち寄って同時に回さなければならない」というルールを作ります。これがマルチシグの考え方です。

3-of-5マルチシグの例：5人のメンバー（開発者、法律家、コミュニティ代表など）のうち、3人が賛成のサイン（署名）をしないと、コントラクトをアップグレードできないようにロックをかける。

これなら、仮に1人の開発者のパソコンがハッキングされて秘密鍵が盗まれても、攻撃者は残りの鍵を持っていなすいため、勝手にコントラクトを書き換えることはできません。権力が分散され、セキュリティが劇的に向上するのです。

—

4. 実践！安全なアップグレード管理の実装コード例

それでは、実際にOpenZeppelinなどの標準的なライブラリを使って、アップグレード可能なコントラクト（Proxyパターン）と、それを安全に管理するための設定イメージを見てみましょう。

今回は、Solidityを用いたスマートコントラクトのイメージと、それをデプロイ・管理する際の設定ファイルの雰囲気をコードブロックで紹介しますね。難しそうに見えますが、コメントを丁寧に書いたので一緒に見ていきましょう！

コントラクトのアップグレード構造（Solidity）

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

/**
 * @dev アップグレード可能なコントラクトのベースとなるサンプルです。
 * 通常のコンストラクタの代わりに `initialize` 関数を使用します。
 */
DappVaultV1 is Initializable {
    uint256 public totalFunds;

    // 初期化関数（コンストラクタの代わり）
    function initialize() public initializer {
        totalFunds = 0;
    }

    // 資金を預かるロジック
    function deposit() public payable {
        totalFunds += msg.value;
    }
}

管理権限をマルチシグ（Gnosis Safe等）に渡すデプロイ設定（JavaScript / Hardhat）

実際にブロックチェーンへコントラクトをデプロイし、その「管理者の権限（ProxyAdmin）」を、先ほど説明した安全なマルチシグウォレットに移行するスクリプトの例です。

const { ethers, upgrades } = require("hardhat");

async function main() {
  console.log("アップグレード可能なコントラクトをデプロイ中...");

  // 1. V1コントラクトのデプロイ
  const DappVaultV1 = await ethers.getContractFactory("DappVaultV1");
  const vault = await upgrades.deployProxy(DappVaultV1, [], { initializer: 'initialize' });
  await vault.waitForDeployment();

  console.log(`Vault deployed to: ${vault.target}`);

  // 2. 【重要】コントラクトのアップグレード権限を持つ管理者アドレス（ProxyAdmin）を取得
  const adminAddress = await upgrades.erc1967.getAdminAddress(vault.target);
  console.log(`現在のプロキシ管理者アドレス: ${adminAddress}`);

  // 3. 実際の運用環境では、ここで管理権限を「マルチシグウォレット（例: Gnosis Safe）」に移譲します
  // const MULTISIG_WALLET_ADDRESS = "0xYourMultiSigWalletAddressHere...";
  // 
  // const proxyAdmin = await ethers.getContractAt("ProxyAdmin", adminAddress);
  // await proxyAdmin.transferOwnership(MULTISIG_WALLET_ADDRESS);
  // console.log("管理者権限をマルチシグウォレットへ安全に移譲しました！");
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

このように、デプロイした後に「管理者権限（オーナー権限）を個人のウォレットから、複数人で管理するマルチシグのアドレスへ書き換える」というひと手間を挟むことが、現場でエンジニアが必ず行うべき実務的な防衛策になります。

—

5. まとめ：一歩ずつ、堅牢なシステムを作ろう

今回は、スマートコントラクトのアップグレード可能性に潜む「管理者権限の集中リスク」と、それを防ぐ「マルチシグによるガバナンス分散」について解説しました。

アップグレード機能はバグ修正の強い味方だけど、一歩間違えると「全ての鍵を握る最強のマスターキー」になってしまう。
そのリスクを抑えるために、マルチシグウォレットを使って複数人で権限を分散させることが不可欠。
開発の現場では、デプロイした後の管理者権限の移譲まで気を抜かずに設計する。

セキュリティの世界は覚えることが多くて最初は大変に感じるかもしれませんが、こうした「もしも」を想像する視点（脅威モデリング）を少しずつ持てるようになると、コードを書くのがもっと楽しく、そして誇らしいものになりますよ。

一歩ずつ、安全で信頼されるシステムを一緒に作っていきましょう！