ゾンビ・スマートコントラクトとは、チームが非推奨にした、または保守を停止したものの、なおチェーン上で動作し、資金を保持したり呼び出しを受けたり、ロジックを実行できるオンチェーンのコードです。公開された非推奨の告知やフロントエンドの停止は、そのコントラクト自体を無効化しません。バイトコードはそのアドレスに存続するため、呼び出し側が有効な入力を提供する限り、相互作用は続きます。この動態は、Aztec Connectに関するRektのポストモーテムで記録されています。
DeFiでは、これにより放置された契約が長い尾を引き、オンチェーン上に経済的価値と呼び出し可能なエントリポイントが残ります。攻撃者はこれらのエンドポイントを調べ、ボットや注意を払わないユーザーがレガシーのアドレスに対して相互作用してしまう可能性があります。リスクが残り続けるのは、イーサリアムのコントラクトはデフォルトでは不変であり、挙動の変更を可能にするのは明示的なアップグレード設計のみだからです。
アップグレード経路や管理者権限が削除されたり放棄されたりすると、チームはレガシー契約を一時停止、修正、または引退できない可能性があります。この制約は、イーサリアムの不可変性モデルと、プロキシ/UUPS/ダイヤモンドのパターンが管理者ロールに依存する仕組みから生じます。これは、イーサリアム財団のスマートコントラクト・セキュリティドキュメントで説明されています。
ゾンビスマートコントラクトがオンチェーンで存続する仕組み
イーサリアムのスマートコントラクトは、一度デプロイされると変更できません。振る舞いを変えるためには、プロキシ、UUPS、ダイヤモンドなどのパターンを通じて、アップグレード可能なロジックに委譲（delegate call）するように明示的に設計する必要があります。これらのパターンは管理者キーやガバナンスロールに依存します。これらのロールが誤設定、侵害、または放棄されると、チームは、その契約を公に非推奨にしたとしても、契約を完全に修正または引退（退役）する能力を失う可能性があります。不可変性とアップグレード・パターンに関するセキュリティ上の影響については、イーサリアム財団のドキュメントをご参照ください。
製品の非推奨やWebサイトの停止は、オンチェーン上のバイトコードには影響しません。アドレスは呼び出し可能なままで、残存する状態や価値も保持されます。攻撃者は取引（トランザクション）を通じて直接やり取りでき、依然として古いアドレスを参照しているインテグレータは、知らないうちにユーザーを非推奨のロジックへ誘導してしまう可能性があります。放棄された／ゾンビ契約という現象は、学術研究や実証研究の中で長年にわたり観測されてきました。例えば、CSIRO Data61（2016年の分析）による、イーサリアム上の休眠・未保守契約の早期測定に関する報告があります。
非推奨を攻撃面に変えるものは何か
非推奨後のリスクは机上の空論ではありません。インシデントの再構築で特定された、いくつかの実務的な仕組みによって生じます：
稼働中の入口（live entry points）：プロジェクトが非推奨を告知した後でも、関数は呼び出し可能なままであり、役に立つ操作が敵対者に対して開かれた状態になります。これはAztec Connectの技術的な再構築で強調されました。
残存価値：不変な契約は、資金や流動性提供者（LP）のポジションを依然として保有している可能性があり、特殊な悪用や状態操作のためのハニーポットに変わり得ます。
管理者／オフチェーン関係者に関する誤った前提：契約がオペレータ、リレー、シーケンサが特定の方法で振る舞うことを前提としている場合、チームがウィンドダウンしたりキーが削除された後に、その前提が崩れる可能性があります。
アーキテクチャ上の境界：オフチェーンの証明とオンチェーンの決済境界の不一致は、暗号を破らずに悪用され得ます。これはAztec Connectのポストモーテムで説明されています。
業界のサマリーでは、2025〜2026年にかけて複数のチェーンで、非推奨またはレガシー契約からの流出が起きたことが指摘されており、これを「単一のバグ種別」ではなく「運用およびライフサイクルのリスク」として位置づけています。ZeroDriftを引用したPANewsの要約は、これらの観察を記録しています。
事例：Aztec Connectの非推奨RollupProcessorV3
2026年6月、Aztec Connectで使用されていた非推奨のRollupProcessorV3契約は、約$2.1〜$2.3 millionが流出しました。分析では、新たな暗号技術の破綻というより、非推奨ルートにおける決済境界（settlement-boundary）のバイパスが語られています。重要なのは、非推奨となった後でもその契約がアドレス上で生きており呼び出し可能だったことです。詳細は、ZeroDriftを引用したPANewsの要約と、Rektのポストモーテムをご覧ください。
要点は運用（operational）です。製品を非推奨にしただけでは、そのオンチェーン契約がデコミッションされるわけではありません。入口（entry points）が無効化されていない、または資金が移行されていない限り、残存する価値（residual value）と呼び出し可能なロジックが、標的型の悪用を招きます。
プロトコルが“暗く”なったとき、誰が影響を受けるか
残存残高を持つエンドユーザー：バルト、プール、エスクロー型の契約に残された資金は、孤立したり、未知の攻撃経路に晒されたりする可能性があります。
インテグレータやアグリゲータ：レガシーアドレスを参照し続けるルータやフロントエンドは、非推奨ロジックへ取引を送り続けることがあります。
プロトコルチームやDAO：管理者ロールが分散化を示すために放棄されている場合、新たなリスクが生じても、チームはレガシーコードを一時停止または修正できない可能性があります。この制約は、イーサリアム財団のセキュリティドキュメントで説明されているモデルに従います。
監査人や監視者：ツールはしばしばアクティブなデプロイに焦点を当て、価値を保持しているにもかかわらず非推奨アドレスの見落とし（ブラインドスポット）が残りがちです。
デコミッショニング（廃止）手順書（runbook）としてチームが従えるもの
ゾンビ契約はライフサイクル設計によって最もよく予防できます。OpenZeppelin Contracts & Upgradesガイダンスを含む業界の指針では、移行を計画すること、管理者にはマルチシグを使うこと、安全なモードを実装することが強調されています。実用的なrunbookは次のようになります：
すべてを棚卸しします。すべてのデプロイ済みアドレス、アップグレード用プロキシ、管理者ロール、キーパー（keepers）、権限を持つアクター、従属するサービスを列挙してください。
ウィンドダウン計画を公開します。明確なスケジュールと、対象となる正確なアドレスを伝えてください。ユーザーに対して出金の猶予（withdrawal window）を提示し、繰り返しリマインドしてください。
コードが対応しているなら、引き出しのみ（withdraw-only）または一時停止モードを有効にしてください。退出（exit）を可能にしつつ、新規の入金（deposit）、借入（borrows）、複雑なフローをブロックするような制御された状態を優先します。
プロトコルが管理する残存価値を引き出し（drain）。トレジャリーの資金を移行し、管理者が保有するコントラクト内でのLPポジションを解消（アンワインド）します。
承認（approvals）とロールを取り消します。オペレータキーを削除し、リレーを無効化し、段階的で文書化された手順に従ってアクセス制御リストを厳格化してください。
アップグレード経路を確定します。プロキシとアップグレードがまだ可能であるなら、実装（implementation）を、出金（withdrawals）以外の状態変更系の入口（entry points）をブロックする最小ロジックに向けてください。
管理を強固にします。OpenZeppelinのような実務者向けガイダンスで推奨されている通り、残っている権限を、明示的な署名者と公開されたポリシーを持つ適切にガバナンスされたマルチシグ（例：Safe）へ移してください。
オフチェーンの依存関係を引退（リタイア）します。キーパーや自動化を停止し、フロントエンドをアーカイブし、レガシーアドレスが非推奨でサポートされないことを文書化してください。
終盤（テイル）を監視し、保険も検討します。ウィンドダウン後しばらく、想定外の呼び出しや旧アドレスへの価値の流入を捕捉するために、アラートや懸賞（bounties）、あるいは補償（coverage）を維持します。
ループを閉じます。最終状態と、ユーザーやインテグレータがオンチェーン上の結果を検証できるようにするためのエクスプローラへのリンクを含む、デコミッション後のレポートを公開してください。
注意すべき制限と誤解
不可変性は両刃の剣です。管理者キーが放棄されたり、アップグレードの経路がそもそも存在しなかったりする場合、チームは後から一時停止モードや引き出し（withdrawal）モードを追加できません。これは不可変性とアップグレーダビリティ（アップグレード可能性）のモデルに従うものです。
非推奨（Deprecation）はキルスイッチ（停止スイッチ）ではありません。告知やUIの停止を行っても、契約が安全になったり、無効になったりするわけではありません。これはAztec Connectの再構築において強調されました。
監査は経年劣化します。一度はレビューを通過したコードでも、オフチェーンの関係者が消えたり、経済状況が変わったり、前提がもはや成り立たなくなったりすると、危険になり得ます。
すべてのプロキシが同じではありません。設計の不十分なアップグレード経路は、意図しない呼び出し可能なルートやストレージ競合を残し、廃止（デコミッション）を複雑にします。
残存資金は注目を集めます。非推奨アドレスに少額でも残高があると、PANews/ZeroDriftが引用するインシデント・トラッカーにも見られるように、特注の攻撃を誘発し得ます。
実際にゾンビ契約に遭遇する場所
読者がゾンビ契約に出会う可能性が高いのは、次のときです：
チュートリアルやアグリゲータを参照し、すでに移行済みのプロトコルの古いアドレスを引用している場合があります。
ブロックエクスプローラで、プール、バルト（vault）、またはルータの複数バージョンを確認し、どれが現在のものかが不明確であることがあります。
フロントエンドがオフラインになっても、フロントエンドの停止を知らずに、非推奨にされた（disabledではない）機能を呼び出せることがあります。契約アドレスに直接やり取りしてください。
ウィンドダウン（事業終了）を告知しているプロトコルで資産を保有し、出金の余地は残るが、後から危険な相互作用をブロックするオンチェーン上の強制（enforcement）がない状態にします。
レガシーアドレスに触れる前に、プロキシ・パターンと現在の実装を確認し、管理者ロールや一時停止状態を確定し、最近のアドバイザリを読み、あなたの行動がプロトコルの最新の移行パスと一致していることを検証してください。
よくある質問（FAQ）
契約が放棄されているのか、まだアクティブなのかをどう判断できますか？
最近のオンチェーン活動、ガバナンスや開発者向けの告知、プロジェクトがそのアドレスを“現在のもの”として掲載しているかどうかを確認します。契約がプロキシの背後にあるか、そして実装が最近更新されているかもチェックしてください。管理者ロールが放棄されており、アップグレード経路がない場合、イーサリアム財団のドキュメントに従ってメンテナンスの選択肢は限られます。
管理者キーの放棄は、プロトコルをより安全にしますか？
特定のガバナンスリスクを低減できる場合はありますが、一方で、欠陥のある／非推奨の契約を一時停止、修正、または引退できる能力が失われます。このトレードオフは、イーサリアム財団が説明するイーサリアムの不可変性およびアップグレーダビリティのモデルに内在しています。
契約が非推奨になっている場合、使い続けても安全ですか？
いいえ。非推奨の告知やUIの停止では、オンチェーンのコードは無効化されません。契約は呼び出し可能なままで、資金を保有し続けることもあります。RektのAztec Connectポストモーテムのような分析で見られる通りです。
ゾンビ契約はイーサリアムだけの問題なのでしょうか？
いいえ。このパターンは、不変または準不変（semi-immutable）なスマートコントラクトを備える任意のチェーンで起こり得ます。PANews/ZeroDriftが引用するトラッカーでは、2025〜2026年にかけて複数のチェーンで、非推奨またはレガシー契約からの流出が観測されたとされています。
依存関係が非推奨になったとき、インテグレータは何をすべきですか？
新しいアドレスに差し替え、非推奨ロジックへのルートを削除またはブロックし、重点的な統合（integration）レビューを行ってください。回路ブレーカ（circuit breakers）、より厳格な許可リスト（allowlists）、非推奨警告の追加も検討し、ユーザーがゾンビのエンドポイントと誤ってやり取りしないようにします。
免責事項：この記事は情報提供のみを目的としています。法的、税務、投資、金融その他の助言として提供または意図されたものではありません。