こんにちは！ブロックチェーンの世界へようこそ。
スマートコントラクトの開発、日々新しい発見があって面白いですよね。「自分が書いたコードがそのまま世界中で動き続ける」というのは、他のプログラミングにはない大きなロマンです。
でも、その分「一度デプロイ（公開）したら簡単に直せない」「バグが即座にお金（資産）の消失に繋がる」という、特有の緊張感もあります。
今日は、そんなスマートコントラクトの開発現場で、ベテランのエンジニアでも冷や汗をかくことがある「未初期化プロキシコントラクトの脆弱性」について、一緒に優しく紐解いていきたいと思います。
難しい専門用語が出てきても、「一歩ずつ対策を学んでいきましょう！」というスタンスで進めていくので、どうぞリラックスして読んでくださいね。
—
1. 家の鍵に例える「プロキシ」と「初期化」の仕組み
まずは、今日の主役である「プロキシコントラクト」と「初期化」について、身近な例えでイメージを掴んでおきましょう。
プロキシ＝「表札と玄関」、ロジック＝「家の中の家具や間取り」
ブロックチェーンの世界では、一度デプロイしたスマートコントラクトの中身（プログラム）を後から書き換えることができません。これはセキュリティ上、非常に重要なメリットなのですが、「あ、バグがあった！修正したい！」という時には困ってしまいますよね。
そこで考え出されたのが「プロキシ（代理）パターン」という技術です。
- プロキシコントラクト（表札・玄関）： ユーザーがアクセスする窓口です。アドレスはずっと変わりません。
- ロジックコントラクト（家の中）： 実際の処理が書かれた本体です。中身を修正したいときは、この「家」をごっそり新しいものに建て替えて、プロキシ（玄関）から繋ぎ直します。
これにより、ユーザーは同じアドレスを使い続けながら、コントラクトの機能をアップデートできるようになりました。すごく便利な仕組みですよね。
鍵の掛け忘れが招く悲劇：初期化（Initialization）とは？
さて、ここで「新築の家（ロジックコントラクト）」を建てたと想像してください。
新しい家には、当然「この家の持ち主（オーナー）」を登録する鍵が必要です。通常のプログラムなら constructor（コンストラクタ＝最初に行う初期設定）という仕組みを使って、建てた瞬間に自動で鍵をかけます。
しかし、プロキシの仕組みを使う場合、この初期設定のやり方にちょっとした「落とし穴」があります。
プロキシの構造上、ロジックコントラクト単体でデプロイされた時点では、まだ「誰のものでもない空き家」の状態です。この空き家の持ち主を登録する処理（初期化関数）を、開発者がうっかり呼び忘れてしまったらどうなるでしょうか？
そう、「誰でも自由にこの家の合鍵を作って、自分がオーナー（所有者）だと名乗れる状態」になってしまうのです。これが、未初期化プロキシコントラクトが抱える恐ろしいリスクの正体です。
—
2. 攻撃者はどうやって「所有者」を奪うのか？
泥棒は、鍵の掛け忘れを絶対に見逃しません。ブロックチェーンの世界でも、自動化されたボット（プログラム）が、世界中のネットワークを常に監視しています。
もし、開発者がデプロイ後に「初期化関数を呼び忘れた！」と気づく前に、攻撃者がその未初期化的な状態を発見したら、以下のようなステップで一瞬のうちに乗っ取りが完了します。
1. 監視の網： ボットが「新しいコントラクトがデプロイされたが、誰もオーナー登録をしていない（初期化されていない）」ことを検知します。
2. 先回り攻撃： 攻撃者は、初期化関数（例: initialize()）を自分が実行し、「自分自身をこのコントラクトのオーナーにする」というトランザクションを送信します。
3. 乗っ取り完了： ブロックチェーンに記録された瞬間、コントラクトの全権限（資産の引き出しや設定変更など）が攻撃者の手に渡ってしまいます。
「えっ、そんなうっかりミスがあるの？」と思われるかもしれませんが、プロジェクトのローンチ直前でバタバタしている現場では、意外と起こりうるヒューマンエラーなのです。
—
3. 【実例コード】危ないコードと安全なコードを見比べてみよう
百聞は一見にしかず。実際のSolidityコード（イーサリアムなどで使われる言語）を見てみましょう。どこが危なくて、どう直すべきなのか、一緒に確認していきますね。
⚠️ 危ないコード例（初期化関数が放置されている）
以下のコードは、アップグレード可能なコントラクトの「ロジック側」のイメージです。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
// 危険な状態のコントラクト
contract VulnerableVault is Initializable {
address public owner;
// ⚠️ 問題点：constructorを使っているが、プロキシパターンでは機能しない、
// あるいは初期化関数（initialize）のアクセス制御や呼び出しが漏れているケース
function initialize() public {
// ここに「owner = msg.sender;」を書く予定だったが…
// もしこの関数が誰からでも呼べる状態で放置されていると危険！
owner = msg.sender;
}
function withdrawAll() external {
require(msg.sender == owner, "Owner only");
// 資金を持ち逃げする処理など
payable(msg.sender).transfer(address(this).balance);
}
}このコードの何が問題かというと、initialize() 関数が public（誰からでも呼び出せる状態）になっているにもかかわらず、デプロイ直後に開発者が呼び出し忘れたり、あるいは別の誰かに先に呼び出されてしまう隙がある点です。
🛡️ 安全なコード例（確実に対策された実装）
では、この脆弱性を防ぐためにはどうすればよいでしょうか？ OpenZeppelinなどの信頼できるライブラリが提供している「一度しか実行できない仕組み（initializer修飾子）」を正しく使い、さらにデプロイと初期化を安全に行う仕組みを取り入れます。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
// 安全に対策されたコントラクト
contract SecureVault is Initializable, OwnableUpgradeable {
/// @custom:oz-upgrades-unsafe-allow constructor
constructor() {
// コンストラクタで初期化を無効化し、ロジックコントラクト自体が
// 直接乗っ取られるのを防ぎます（実装パターンの一つ）
_disableInitializers();
}
// 初期化関数
function initialize(address initialOwner) public initializer {
// Ownableの初期化（中で owner = initialOwner が実行される）
__Ownable_init(initialOwner);
}
function secureAction() external onlyOwner {
// オーナーだけが実行できる安全な処理
}
}ここで使われている initializer というキーワード（修飾子）は、「この関数は、コントラクトの人生で一度しか実行できない」という強力な鍵をかけてくれます。万が一、2回目以降に誰かがこの関数を呼び出そうとしても、プログラムが自動でエラー（弾く）にしてくれるため安心です。
また、ロジックコントラクト自体のコンストラクタで _disableInitializers() を呼んでおくことで、ロジックコントラクト単体が悪用されるリスクもシャットアウトできます。二重の鍵をかけておくイメージですね。
—
4. 現場のエンジニアが実践すべき「泥臭い」防衛策
コードの書き方を覚えるだけではなく、実際の開発や運用の現場では、以下のような「泥臭いチェックと習慣」が身を守ってくれます。
1. デプロイ手順書（ランブック）の自動化・チェックリスト化
「デプロイした後に、手動で初期化スクリプトを叩く」という手順は、人間が忘れるリスクがあります。HardhatやFoundryなどの開発フレームワークを使い、「デプロイと初期化をひとつのトランザクション、あるいは一連の自動スクリプト」として完結するように組み込みましょう。
2. 初期化状態のテストを書く
ユニットテスト（テストコード）の中で、デプロイ直後に正しくオーナーが設定されているか、また、未初期化の状態で不正なアクセスが弾かれるかをテストする習慣をつけましょう。テストを書くことは、未来の自分へのラブレターであり、最強の防犯カメラです。
3. アップグレードプラグインの活用
OpenZeppelin Upgrades Pluginsなどのツールを使用すると、デプロイ時に初期化関数が正しく呼ばれているか、あるいはセキュリティ上の懸念がないかを自動でチェックしてくれます。ツールに頼れる部分はどんどん頼りましょう。
—
まとめ
今回は、未初期化プロキシコントラクトの脆弱性について、お家の中の鍵や泥棒の例えを交えながら解説しました。
- プロキシコントラクトは便利だけど、初期化（鍵の登録）のし忘れ・遅れが命取りになる。
initializer修飾子を使って、初期化が一生に一度しかできないようにガードする。- デプロイと初期化はセットで自動化し、ヒューマンエラーを徹底的に排除する。
セキュリティの世界は広く、最初は覚えることが多くて大変に感じるかもしれませんが、「安全なコードの型」を一つずつ自分のものにしていけば、必ず信頼されるエンジニアになれます。
一歩ずつ、確実にスキルアップしていきましょう！次の記事でも、現場で役立つ実践的な知見をお届けしますので、お楽しみに！
コメント