AIコーディングツールでスマートコントラクトの実装を進めているエンジニアに向けて、ガバナンス設計のレビュー漏れという落とし穴を整理します。DeFi（ブロックチェーン上の分散型金融サービス）のプロトコルに限らず、権限管理を伴うシステム全般に通じる話として読んでもらえればと思います。
あるDeFi取引所プラットフォームを対象にしたガバナンス攻撃面のレビューでは、TVL（Total Value Locked、預けられている資産の総額）約168億ドル規模のプロトコルに対して、リスクスコア7.2/10という「高リスク」判定が出されています。原因は単一の脆弱性ではなく、投票権の集中・アップグレード管理・タイムロックという複数の設計要素が組み合わさった結果でした。AIツールでスマートコントラクトを生成・修正する開発フローでは、この種の複合的な設計リスクが特に見落とされやすくなります。
何が起きるか：AI生成コードは「動く権限管理」しか作らない
CopilotやClaude Codeのようなコード生成ツールに「アップグレード可能なコントラクトを実装して」と依頼すると、多くの場合TransparentUpgradeableProxy（コントラクトのロジックだけを後から差し替えられるプロキシパターン）のような、動作するコードは出力されます。
しかし今回のレビュー対象では、そのプロキシのadmin権限が単一のEOA（Externally Owned Account、秘密鍵1本で管理される通常のウォレットアドレス）に集中していました。これは「動くコード」としては正しくても、「ガバナンス上安全なコード」としては欠陥です。
AIツールは要求された機能を実装することには長けていますが、その機能が誰にどんな権限を与えるかという設計判断までは代弁してくれません。結果として、レビューで見つかったような以下の問題がコードとして完成してしまいます。
- 単一鍵のアップグレード管理者がコアコントラクトを無検証で差し替えられる
- クオラム（可決に必要な最低投票率）がわずか4%、提案作成の閾値が1%と低すぎる
- タイムロック（提案可決後、実行までの待機時間）の遅延値がアップグレード可能なストレージに置かれ、管理者が任意に短縮できる
なぜ起きるか：プロンプトが「機能要件」しか渡していない
この落とし穴の根本原因は、AIへの指示（プロンプト）が機能要件に偏り、非機能要件である権限設計・攻撃耐性を含んでいない点にあります。段階を追って分解します。
第一に、AIコーディングツールは提示されたコンテキスト（設計方針や制約条件）の範囲でしか判断できません。「アップグレード可能にして」という指示だけでは、admin権限をマルチシグ（複数の署名者の合意を要する管理方式）にするか単一鍵にするかは選べず、実装上シンプルな単一鍵構成に倒れがちです。
第二に、フラッシュローン攻撃（同一トランザクション内で借入と返済を完結させ、瞬間的に巨額の資金・トークンを保有する手法）のような経済的攻撃パターンは、単体のコードレビューでは見えません。BYTトークンにアンチホエール機構やスナップショット・ロック（投票開始時点の残高で投票権を固定する仕組み）がない場合、借りたトークンで一時的に投票権を得て可決してしまう経路が残ります。AIはコンパイルが通り、テストが通るコードを作ることには強くても、こうした経済的な攻撃シナリオまで想定して設計を止めることは基本的にありません。
第三に、レビューフェーズでもAIの出力をそのまま承認してしまうと、複数の中リスク項目が積み重なって全体としては高リスクになるという「複合リスク」が見逃されます。今回のケースでも、トークン集中（リスクスコア8）、低クオラム（同6）、フラッシュローン投票（同7）、タイムロック不備（同7）、単一鍵admin（同9）が個別には「よくある設計」でも、組み合わさることで7.2という高スコアに達しています。
自分のプロジェクトが該当するか確認する方法
スマートコントラクトを扱っていないプロジェクトでも、権限管理・自動デプロイ・CI/CDのガバナンスという観点では同じ構造のリスクが潜んでいます。以下の観点で確認してみてください。
- コントラクトやIaC（Infrastructure as Code）のadmin/ownerロールが単一の鍵・単一のアカウントに紐づいていないか、
grepでproxy adminのアドレス数を確認する - CI/CDのデプロイ承認フローに、変更を止められる待機時間（タイムロックに相当する仕組み）があるか、GitHub Actionsのenvironment protection ruleの設定を確認する
- 「誰が何%の承認で本番反映できるか」の閾値が、ドキュメント化されずコード内の定数（クオラムやthreshold相当の値）にだけ存在していないか
- AIツールに設計を依頼したPRの差分で、権限系のコード（admin、owner、setXxx系関数）が生成された箇所をリストアップできるか
スマートコントラクト開発であれば、OpenZeppelinのTimelockControllerやGovernorのようなライブラリを使っているか、独自実装かをまず確認します。独自実装の場合、閾値やタイムロック遅延がハードコードされているか、アップグレード可能な変数として外に出ているかをコードレビューで洗い出す必要があります。
対策の手順
1. プロンプトに非機能要件を明示する
「アップグレード可能なコントラクトを実装して」ではなく、「アップグレード権限はマルチシグ（3-of-5想定）に限定し、単一鍵での実行を許可しないこと」のように、権限設計をプロンプトの必須条件として明記します。AIツールは制約を明示すれば、それに沿ったコード構造を提案してくれます。
2. 生成コードに対する権限監査チェックリストを用意する
以下の項目をレビューテンプレートとして固定化し、AI生成コードのPRごとに確認します。
- admin/ownerロールは単一EOAではなくマルチシグまたはDAOガバナンスか
- クオラム・提案閾値は経済的攻撃コストを上回る水準か
- タイムロック遅延は監視・対応に十分な時間か（目安として24時間以上）
- タイムロック遅延自体が管理者権限で変更可能になっていないか
- クロスチェーンブリッジのパラメータ変更に同様の制約がかかっているか3. フラッシュローン耐性をテストケースとして書かせる
AIコーディングツールにテストコードの生成を依頼する際、「単一ブロック内でトークンを借入・投票・返済するシナリオをFoundryのテストとして書いて」と具体的に指示します。これにより、投票権のスナップショット機構が正しく機能しているかを機械的に検証できます。
4. リスクスコアリングをレビュープロセスに組み込む
今回のレビューのように、各項目に深刻度（Critical/High/Medium/Low）と発生可能性を掛け合わせたリスクスコアを付ける運用は、非DeFiのプロジェクトでも流用できます。個別には軽微でも合算すると高リスクになる組み合わせを、チェックリストの集計値として可視化しておくと、AI生成コードのレビュー漏れに気づきやすくなります。
まとめ
AIコーディングツールは機能要件の実装には強い一方、権限設計やガバナンス上の攻撃耐性までは自律的に判断しません。
次にAIへスマートコントラクトやIaCの実装を依頼する際は、admin権限の分散・クオラムの妥当性・タイムロック遅延の3点をプロンプトに明記することから始めてみてください。
すでに存在するコードベースについては、proxy adminのアドレス数とタイムロック遅延の変更可否をgrepやコード検索で確認し、単一鍵構成が残っていないかを点検することが、まず取れる具体的な一歩になります。