企業のDeFi取引承認フロー｜承認した内容と署名する中身を一致させるには

ある企業の財務チームが、手元のUSDCをAaveに預けて運用することにしました。運用担当が申請し、リスク担当が承認して、ウォレットで署名する流れです。承認画面には「100,000 USDCをAaveへ供給」と表示されています。

ところが、実際に署名される中身が別物だったらどうでしょう。別のチェーン、別のトークン、アップグレードできる別のコントラクト宛てだったら。承認者が画面で読んだ内容と違うなら、その承認には意味がありません。

DeFiでは、もう1つ落とし穴があります。スワップ、貸し借り、流動性提供、トークンの利用許可（approval）は、それぞれ動く資産も、後に残る権限も違います。送金と同じように「宛先と金額」だけを承認しても足りません。

では、承認フローとウォレットの権限をどう作ればよいか。答えは2つです。

• 承認者が見た内容と、実際に署名されるデータを、項目ごとに固定して突き合わせる
• ウォレットごとに、実行できる操作を分けておく

以下では、この財務チームの承認フローを設計する担当者の立場で考えます。固定する項目、操作の種類ごとの承認内容、ウォレット権限の分け方を決め、失敗したときの動きと本番前の試験まで見ていきます。

承認・署名・オンチェーンの制約は、それぞれ何を受け持つか

機関のウォレット運用では、3つの層を分けます。

• 業務上の承認：目的・相手先・上限を審査する
• 鍵による署名：承認済みの内容と、署名するものが一致しているかを確かめる
• オンチェーンの制約：署名者が間違えても越えられない上限や許可リスト

たとえば、申請した人が自分で承認できる作りだとします。あるいは、同じ管理者が、承認のルールも監査ログも書き換えられるとします。こうした作りでは、ブロックチェーンを使っていても、職務分離にはなりません。

確かめるべきは、人、端末、IdP（ログインを受け持つ認証基盤）、鍵、管理権限がどこに頼っているかまでです。NIST SP 800-53 Rev. 5のAC-5も、分けるべき職務を特定して文書にし、それを支えるアクセス権限を定めるよう求めています（NIST SP 800-53 Rev. 5）。

3層の分け方と職務分離の表、HSM・MPC・マルチシグの比較は「機関投資家向け暗号資産カストディ設計」で扱っています。署名サービス側の検証は「HSM・MPCを使った署名鍵の本番運用」、損失の許容額や停止・資金回収の方針は「企業財務のDeFi運用ポリシー」をご覧ください。ここで扱うのは、3つの層が「同じ中身」を見ていることを、どう保証するかです。

承認した内容と署名する中身を、1つのIDとハッシュで結ぶ

冒頭の「100,000 USDCをAaveへ供給」に戻ります。画面に出ている表示と、実際に署名される中身が一致しているとは限りません。そのため、画面の表示を承認するだけでは、ずれを防げません。そこで申請の時点で、何を・どこへ・いくら・いつまでに、を1つの記録（取引意図、intent）にまとめます。そして、その記録の変えられないハッシュと、署名するものを突き合わせます。

固定する値と、変わったら承認し直す変化は次のとおりです。

署名の前には、フォーク環境（本番のチェーンを写した試験環境）などで試しに実行します（シミュレーション）。見るのは、成功するかどうかだけではありません。次の差分を、期待した値と比べます。

• ウォレットの残高と利用許可額（allowance）
• プロトコル上のポジションと、受け取るトークン
• イベントと内部呼び出し

シミュレーションの後で、ブロック、Oracle価格、プロキシの実装先、nonce、calldataが変わることがあります。どこまでの変化なら承認を保てるかを、先に決めておきます。

承認の後でガス代だけを調整できる作りにするのは構いません。ただし、送信先やcalldataまで自由に差し替えられる状態にはしません。

操作の種類ごとに、何を承認するか

単純な送金の「宛先と金額」を流用すると、DeFiの取引の影響をとらえられません。少なくとも次の操作は別の種類として分け、承認する項目を決めます。

• スワップ：入力額、受け取るトークン、最低受取額、経路、実行期限、許可したルーターを確かめる。
• 貸し借り（レンディング）：預け入れ・借り入れ・返済・引き出しを分ける。実行後の担保率と、清算までの余裕を承認する。
• 流動性提供：価格レンジ、片側への偏り、LPトークンの受取先、ポジションを管理できる権限を確かめる。
• ステーキング／ボールト：預け先、持ち分（シェア）の計算、引き出しの待機期間、報酬の受取先、アップグレードの権限を確かめる。
• 利用許可（approval／permit）：引き出しを許す相手（spender）、トークン、上限、期限、nonceを確かめる。これは独立した「資産を動かす権限」として扱う。

MetaMaskの公式解説のとおり、トークンの利用許可は、DEXなどのコントラクトにウォレット内のトークンを動かす権限を与えます（MetaMask「How to revoke smart contract allowances」）。

取引額が小さくても、上限なしの利用許可を出せば、将来の影響額はウォレットの残高全体まで広がります。そこで、次のようにします。

• 許可額は、必要な額か、理にかなった上限に限る
• 使い終わったら取り消す（revoke）
• 許可先のアップグレードと、長く使われていない許可を監視する

製品のポリシー機能を使う場合は、何を強制できるかを仕様で確かめます。

FireblocksのPolicyは、取引の種類、送金元／送金先、1回の額と期間累計の額、操作者、承認グループなどを条件にできます。コントラクト呼び出し、approve、署名メッセージ（typed message）も区別できます（Fireblocks「Configure Policies」）。

Rippleのウォレット製品も、取引のほかに、宛先の登録、ポリシーの変更、API用の認証情報の追加に承認の流れを設定できます（Ripple「Configure approval flows」）。

設定画面に「承認」があるかでは判断しません。対象の操作と例外が、自社の権限表をすべて覆っているか。それを受け入れの条件にします。

ウォレットの権限表に、「統制を変える操作」も載せる

DeFiで資産の移動につながるのは、スワップや預け入れだけではありません。利用許可、署名メッセージ、ウォレットの所有者（owner）の変更、モジュールの追加もそうです。

そのため権限表には、通常の取引の承認条件に加えて、その条件を緩められる人も載せます。そして、定常取引用・新規プロトコル用・管理用で、ウォレットや経路を分けます。

Safe Smart Accountには、注意すべき点があります。有効にしたモジュールは、所有者と閾値による署名の確認を迂回して、取引を実行できます（Safe「Smart Account Concepts」）。

そのため、所有者の一覧を監査するだけでは足りません。次のものを、同じ時点で取得して確かめます。

• 有効なモジュールとGuard
• fallback handler（Safe本体に無い関数への呼び出しを受け持つ仕組み）とプロキシの実装先
• 所有者と閾値

権限の抜け道の洗い出しは「マルチシグ・タイムロックによる本番権限管理」で詳しく扱っています。Safeのモジュール構成は「Safeのモジュラーアカウント設計」をご覧ください。

署名者が間違えても越えられない上限だけを、コントラクトに書く

業務の理由、見積書、顧客情報、承認者のコメントは、通常はオフチェーンの承認システムに置きます。訂正、アクセス制御、機密保持が必要だからです。

ブロックチェーンに置くのは、公開されてもよい最小限の制約です。複数の組織が、同じ実行条件を確かめる必要があるものに限ります。

Safe Guardは、取引の前後に検査を加えられます。ただ、Guardが壊れると、すべての取引が止まり得ます。Safeの公式ドキュメントも、実装を十分に確かめることと、復旧の仕組みを求めています（Safe「Safe Guards」）。

Guardを増やすほど安全になるわけではありません。次のことを一組で設計します。

• 制約の検証と、アップグレードの権限
• 無効にする手順
• Guardの障害中に、資産を安全に回収する方法

結果が分からないとき、送り直してよいか

RPCが時間切れになっても、取引は実際には送られ、実行されていることがあります。そこで送り直すと、同じ取引が二重に実行されるおそれがあります。そのため、nonce、トランザクションハッシュ、ウォレットとプロトコルの実際の状態を突き合わせるまで、再実行しません。

取引意図は、作成、ポリシー検査、承認（ハッシュと期限の確定）、署名、送信、確定、突き合わせの順に進みます。途中で却下、期限切れ、巻き戻り、取り下げ、チェーンの再編成（直近のブロックの置き換わり）、結果不明に分かれることもあります。状態名の一覧は後半の「実装する人向けの詳細」に置きました。

DeFiならではの点は2つです。

• 完了の突き合わせに、残高だけでなく、利用許可額・ポジション・手数料も含める。
• 承認期限や価格の条件を過ぎたら、古い署名を使い回さない。新しい取引意図として承認し直す。

状態ごとの証拠と、時間切れのときの扱いは「カストディ設計の記事」の8状態の表にあります。署名要求の側は「署名鍵の本番運用」の10状態の表を参照してください。

障害のとき、「止める」「確かめる」「戻す」を誰が受け持つか

緊急用の権限は、事後承認でもよいなど、通常より軽い手順で使えるようにしておくものです。そこに任意の送金まで与えると、通常の承認より強い裏口になってしまいます。そのため、緊急用の権限にできることは絞ります。

停止専用の権限者ができるのは、被害を広げにくい操作だけにします。新規申請の停止、ポリシーを損失の出にくい側へ縮めること、モジュールの停止などです。再開、資産の回収、所有者の変更は、別の閾値と、記録された手順を通します。

インデクサーは、チェーンのデータを集めて検索しやすくする仕組みです。障害ごとに確かめる記録は、後半にまとめました。

秘密鍵の断片を分散するMPC（Multi-Party Computation、複数者で行う署名計算）と、業務承認を複数人にすることは、別の統制です。同じ管理者が、複数の承認アカウントと署名端末を復旧できるとします。それでは、形のうえで人数が増えても、独立性は増えません。

署名者がいなくなる場面も、定期的に演習します。休暇・退職・死亡・地域の障害です。侵害されたときに、すぐ失効させる手順も一緒に試します。

承認の方式は、最大損失・頻度・複雑さで選ぶ

方式ごとに、向く条件と、採用しない条件は次のとおりです。

どの方式にも残るリスクは、後半にまとめました。

最小の構成とは、人数やコントラクトが最も少ない構成ではありません。求める最大損失と復旧時間を満たす、いちばん単純な構成です。

頻度の低い検証の段階なら、次の組み合わせから始められます。独立したマルチシグ、宛先の許可リスト、少額の上限、手作業の突き合わせです。

頻度と資産額が増えたら、定常の操作は権限を絞った役割に任せます。非定型の操作と統制の変更は、高い閾値の側に残します。

本番前に、承認が無効になる場面を試す

うまくいく流れより、承認から外れた変更がきちんと拒否されるかを試します。

1. 申請者と承認者を同じ人にすると、拒否されること。
2. チェーンID、呼び出し先、関数、引数、実行期限のうち1項目だけを変えると、署名・ポリシーが拒否すること。
3. 許可済みのプロキシをアップグレードすると、再審査なしでは実行できないこと。
4. トークンの利用許可を、必要額の超過、別の許可先、期限切れで試すと、拒否か承認し直しになること。
5. シミュレーションの後に価格、nonce、ブロック、実装を変えると、再シミュレーション・承認し直しになること。
6. RPCの時間切れ、取り下げられたトランザクション、チェーンの再編成を起こしても、実際の状態を確かめる前に二重送信しないこと。
7. 所有者、閾値、モジュール、Guard、許可リスト、ポリシーの変更が、通常の取引より強い承認で守られていること。
8. 署名者の不在、IdPの停止、ポリシー判定の仕組みの停止から、決めた目標復旧時間（RTO）内に安全に復旧すること。
9. 実行後に、残高だけでなく、利用許可額、債務、担保率、LP／ボールトのポジション、手数料を突き合わせること。

合格の条件は、取引を送れたことではありません。承認された内容だけが実行され、承認から外れた変更は拒否され、結果が分からないときに二重実行せず、実行後の資産と権限の状態まで追えることです。

実装する人向けの詳細

取引意図の状態名

通常の流れ（作成→ポリシー検査→承認→署名→送信→確定→突き合わせ）とは別に、次の状態を持たせます。

• 却下（REJECTED）、期限切れ（EXPIRED）
• 巻き戻り（REVERTED）、取り下げ（DROPPED）
• チェーン再編成（REORGED）、結果不明（UNKNOWN）

障害ごとに確かめる記録

• 署名者の端末・IdPの侵害：失効時刻、影響した署名、所有者の実際の値
• ポリシー判定の仕組みの停止：停止中の申請・署名・例外
• RPC・インデクサーの不整合（UNKNOWN）：nonce、受領記録、ブロックハッシュ、ポジション
• プロトコルが攻撃された疑い：ウォレットごとの影響額、停止のトランザクション
• Guard／モジュールの不具合：有効なモジュール、Guard、復旧のシミュレーション

方式ごとに残る主なリスク

• マルチシグのみ：署名者の見落とし、呼び出し先に制限がないこと、運用の滞り
• カストディ製品／MPCのポリシー：提供事業者・ポリシー判定の仕組み・管理者への依存
• スマートアカウント＋Guard／モジュール：コントラクトの不具合、モジュールによる迂回、復旧できなくなること
• 専用の実行コントラクト：実装・アップグレード・Oracleのリスク

関連して読む

• 機関投資家向け暗号資産カストディ設計 — 承認と署名の分離、HSM・MPC・マルチシグの比較、送金の状態管理
• HSM・MPCを使った署名鍵の本番運用 — 署名サービス側の検証と障害試験
• 企業財務のDeFi運用ポリシー — 利用上限・停止条件・資金回収の方針
• マルチシグ・タイムロックによる本番権限管理 — 権限の迂回路と緊急権限の限定
• DeFiプロトコルのデューデリジェンス — 新しいプロトコルを許可リストへ入れる前の審査
• ブロックチェーンウォレットとは — ウォレットの基本構造と秘密鍵管理
• DAO開発の解説 — 複数主体によるオンチェーンの意思決定との違い

XTELAができること

私たちXTELAは、DeFi操作ごとの取引意図の設計、ウォレットとスマートアカウントの権限表、ポリシー、シミュレーション、監視と復旧の仕組みを設計・開発しています。承認画面の表示と署名対象を突き合わせる検証部品のPoCから、本番の運用設計まで一緒に進めます。貴社のDeFi運用の承認フローを整理したい場合は、お問い合わせからご連絡ください。

主要参考資料

• NIST SP 800-53 Rev. 5（AC-5 Separation of Duties）
• Safe「Smart Account Concepts」（所有者、閾値、モジュール。2026年9月24日確認）
• Safe「Safe Guards」（取引前後の検査と復旧上の注意。2026年9月24日確認）
• Fireblocks「Configure Policies」（取引の種類、上限、操作者、承認グループ。2026年9月24日確認）
• Ripple「Configure approval flows」（取引・宛先・ポリシー・認証情報の変更の承認。2026年9月24日確認）
• MetaMask「How to revoke smart contract allowances/token approvals」（2026年9月24日確認）

資料の確認日と注意：一次資料は2026年9月24日時点の内容を確認しました。一般的な技術・運用設計の解説です。カストディへの該当性や金融規制、会計・税務、個別の投資判断は、対象の法域と業務に応じて弁護士・会計士等の専門家にご確認ください。