暗号資産決済における鍵管理と運用セキュリティ

2025年から2026年にかけての主要インシデントのほとんどは、最終的には鍵または署名に起因しています——署名ツールの侵害、管理者鍵の漏洩、あるいはオペレーターへのフィッシングです。（これらのケースは、最近の暗号資産決済ハックの考察で個別に分析しています。）共通する問題は、鍵がどのように認可され、保管され、署名に使用されるか、というどこかに潜んでいる傾向があります。

問題は、マルチシグ、MPC、ホット/コールドウォレット、HSMが同じレベルの選択肢であるかのように議論されており、それらを混同することで選択が混乱してしまうことです。実際には、これらは独立した3つの次元であり、実際の鍵管理の構成はこれら3つすべての組み合わせです。本稿では、それぞれを順に検討し、次にそれを支えるハイブリッドアーキテクチャ、署名インフラとオペレーション標準、さらにその周辺のより広いオペレーション領域——APIおよびインフラの分離、人とベンダー、ドメインとアイデンティティ、そして最も新しく最も理解が進んでいないリスクである、資金へのアクセスを持つAIエージェント——を取り上げます。

秘密鍵、シードフレーズ、そして「自分のデバイスにある」がセキュリティではない理由

これらすべての核心にあるのが秘密鍵です：暗号学的なランダム数列です。それを持つ者は、トランザクションに署名し、対応するアドレスの資金を移動できます。これはアドレスの資金に対する究極のコントロール——そして究極の単一リスクポイントです。

シードフレーズ（通常は12または24ワード、BIP-39標準）は、その秘密鍵を人間が読める形式にエンコードしたものです。「階層的決定性」（HD）ルールは、1つのシードフレーズから数千の秘密鍵とアドレスを導出します。つまりシードフレーズは、単一の秘密鍵と少なくとも同等、場合によってはそれ以上に機密性が高いです：秘密鍵1つが漏洩すれば1つのアドレスを失い、シードフレーズが漏洩すればウォレット全体を失います。

直接指摘する価値のある一般的な誤解があります：署名デバイスとウォレットが自分の手元にあり、鍵がオフラインである限り、何も問題が起きないと思い込む人がいます。問題は、通常のソフトウェアおよびハードウェアウォレットの秘密鍵とシードフレーズはエクスポートできるということです。デバイスへの内部アクセスやバックアップを持つ者は誰でも秘密鍵をエクスポートしてコピーし、その「自分の」デバイスに触れることなく、どこからでも資金をコントロールできます。

つまり「鍵が自分のデバイスにある」は「誰も取れない」と同義ではありません。実際に重要なのは、秘密鍵がエクスポートできるかどうかです。以下で説明するように、ハードウェアレベルでエクスポートをブロックできる唯一の選択肢はHSMです。

一つのスペクトラムではなく、三つの独立した次元

構成を選ぶ前に、実際に答えるべき3つの問いを分けて考えることが助けになります。

認可モデル：シングルシグ、マルチシグ、またはMPC/TSS

シングルシグは、1つの秘密鍵がすべてをコントロールする——最もシンプルな構成であり、最大の単一障害点です。

マルチシグは、M-of-Nの独立した秘密鍵が一緒に署名することを要求します（例：3-of-5）、各署名者は完全で独立した秘密鍵を保有します。スマートコントラクトをサポートするチェーンでは、コントラクトマルチシグ（Safeが事実上の標準）がコントラクト内でこのロジックを実装し、署名と閾値ルールはオンチェーンで公に検証可能です——トランザクションあたりのガス代が高くなるコストと、署名者を変更するたびにコントラクト設定を編集する必要があるというトレードオフがあります。見落とされがちな弱点もあります：コントラクトマルチシグの署名インフラはまだ未成熟です。SafeのexecTransaction呼び出しはハードウェアウォレットに長いcalldataの文字列として表示されることが多く、署名者は実際に何を承認しているかを理解しにくく、クリア署名とトランザクション解析のエコシステムサポートはまだ限定的です。これはBybitインシデントで悪用された攻撃面そのものであり、コントラクトマルチシグを採用する企業がギャップを埋めるためにサードパーティのトランザクション解析とクロス検証を導入しなければならない理由です。対照的に、Bitcoinなどのチェーンはスクリプトレイヤーでネイティブにマルチシグをサポートしており、コントラクトの依存関係はありません。

**MPC（閾値署名、TSS）**は「完全な秘密鍵を一つに切り分けたもの」ではありません。実際のMPCは分散鍵生成（DKG）を使用します：鍵は作成された瞬間から分散されており、各当事者は独立した鍵シェアを保有し、完全な秘密鍵はどの時点でも存在しません。各当事者は自分のシェアから部分署名を計算し、それらの部分署名は暗号プロトコルによって1つの標準的な署名に結合されます——バイト文字列の連結ではなく計算であるため、結果はオンチェーンで通常のシングル署名と区別がつきません。ガスコストは通常であり、クロスチェーンの互換性は良好で、署名者または閾値の変更にコントラクトへのアクセスは不要です。

MPC/TSSを区別する価値があるのは、より古い、混同されやすい方法：**Shamir秘密分散（SSS）**との違いです。SSSは既存の完全な秘密鍵をn個のピースに切り分け、署名するためには十分なピースが集められ、署名前にメモリ内で完全な秘密鍵が再構成されます——そしてその再構成の瞬間が単一障害点となります。TSSは再構成しません；完全な秘密鍵は現れることがありません。それがSSSより安全な理由です。

マルチシグとMPCはどちらも単一障害点リスクを排除しますが、異なるメカニズムによってそうします。マルチシグは複数の完全な鍵とオンチェーン検証です：透明ですが、署名者のローテーションにコストがかかり煩雑です。MPCは複数の鍵シェアと部分署名のオフチェーン結合です：柔軟で安価ですが、調整はインフラに依存します。

ハードウェア保護：ソフトウェア、ハードウェアウォレット、TEE、またはHSM

ソフトウェアストレージは秘密鍵をサーバーまたはソフトウェアに保管します——最も便利な選択肢であり、最も脆弱です。ハードウェアウォレット（Ledger、Trezorなど）は鍵をセキュアチップに保管し、デバイス内で署名し、鍵がデバイスから出ることを決して許しません。

TEE（トラステッド実行環境）——Intel SGX、AWS Nitro、Apple Secure Enclaveなど——は、汎用CPUに分離された暗号化メモリ領域を確保し、鍵と署名計算をOSルートを持つ攻撃者からも届かない場所に保持します。ソフトウェアとHSMの中間に位置します：強力な論理的分離、良好なパフォーマンス、MPCプロトコルを含む任意のコードを実行できますが、物理的な改ざん耐性とコンプライアンス認証はHSMには及びません。これはMPC鍵シェアを保管する最も一般的な方法でもあります——DKGによってエンクレーブ内で生成され、そこから取り出されることはありません。Fireblocks は例えば、複数のクラウドのSGXエンクレーブにMPC鍵シェアを分散させています。

**HSM（ハードウェアセキュリティモジュール）**は、FIPS 140-2/3などの認証を満たすエンタープライズグレードの改ざん耐性ハードウェアで、物理的な改ざん耐性と侵入時の自動消去機能を持ちます。最強の保証：秘密鍵はハードウェア内で生成され、エクスポート不可としてマークされ、物理的に外に出ることができません。それがソフトウェアやハードウェアウォレットとの根本的な違いであり、高価値の完全な秘密鍵の保管にHSMが適している理由です。

この次元は上記の認可モデルとは直交しています：マルチシグの各完全な鍵はハードウェアウォレットまたはHSMに置くことができ、各MPC鍵シェアは通常TEEエンクレーブに置きます。

資金の温度：ホット、ウォーム、またはコールド

この次元は鍵の保管方法には関心がありません——秘密鍵がインターネットにどれほど露出しているか、つまり資金がどれだけ速く、どれだけ自動的に移動できるかだけを問います。

ホットウォレットは常時オンラインで、即時支払いと自動ペイアウトに使用されます——最速で最高リスクであり、通常は総資金の一桁台のパーセントのみを保有します。ウォームウォレットはオンラインですが、秘密鍵は保護された環境（専用署名サービスまたはHSM）に分離されており、署名ループに人間が必要です；これらは日常的な業務決済を処理します。コールドウォレットは完全にオフラインでエアギャップされており、大規模な準備金の長期保管に使用されます——最高のセキュリティ、最も使用が遅く、通常は資金の大部分を保有します。

明確にしておくと、温度は基本的に秘密鍵のオンライン露出と資金がどれだけ容易に移動できるかについてのものです；送金頻度と資金シェアはその結果であり、定義ではありません。この次元も最初の2つと同様に直交しています：コールドウォレットはマルチシグとHSMを使用でき、ホットウォレットはMPCを使用できます。

3つを組み合わせると全体像が見えます：認可モデル、ハードウェア保護、資金の温度は独立しており、実際の鍵管理の構成はこれら3つすべてを組み合わせます。

一般的な鍵管理の構成

業界が3つの次元を一般的にどのように組み合わせるかを示します：

選択のポイントは、資金の温度でティア分けし、各ティアで最良の組み合わせを使用することです。ホットウォレットはスピードが必要なのでMPCを優先します。コールドウォレットは安定性と監査可能性が必要なのでマルチシグとHSMを優先します。ガバナンスとコントラクト権限は透明性と説明責任が必要なのでコントラクトマルチシグとタイムロックを優先します。

BlockSecが推奨するハイブリッドアーキテクチャ

BlockSecは、温度でティア分けしたハイブリッドアーキテクチャを推奨します。

ホット/ウォームウォレット：MPC署名。 秘密鍵の単一障害点を排除し、署名のレイテンシを低く保ち、高頻度決済に適しています。シェアは異なる物理的な場所とセキュリティドメインに分散させる必要があります。

コールドウォレット：マルチパーティコントロールとオンチェーン監査可能性、大規模準備金に適しています。どの実装を使用するかは、チームのオンチェーンオペレーション能力によります——2つのパスがあります：

• 最大の透明性のために、成熟したオンチェーンオペレーションを持つ場合： コントラクトマルチシグ（例：Safeの3-of-5）を使用し、閾値ルールとすべての署名はオンチェーンで公に検証可能です。Bitcoinではスクリプトレイヤーのネイティブマルチシグを使用し、各署名者は自分の鍵をHSMまたはハードウェアウォレットで保護します。コントラクトマルチシグの署名解析ツールはまだ未成熟なため、チームはクロス検証を自分で追加する必要があります——ここでのオペレーションは軽くありません。
• オンチェーン実行に習熟していないチームでオペレーションの複雑さを減らしたい場合： TEE内のシェアを使用したMPC閾値署名を使用し、独立したサードパーティを各署名前のトランザクション安全チェックを実行する共同署名者として導入します。これにより、コントラクトマルチシグのツールギャップを回避し、独立したサードパーティの検証を署名閾値に直接組み込みます。

コントラクトのアップグレードとポリシー変更：マルチシグとタイムロック。 権限変更操作はすべて複数人の承認と時間遅延が必要です。

どのパスを取るかに関わらず、いくつかのパラメータが重要です。少なくとも3人の署名者を使用し、閾値は少なくとも50%ですが総数未満にします——N-of-Nは避けてください。1人の署名者に連絡が取れなくなるだけで署名がブロックされ資金がロックされ、すべての署名者が不可欠であれば、各々が強制や誘拐の重要なターゲットになります。総数未満の閾値は冗長性を残し、特定の署名者を狙う価値を下げます。各署名者はまた、各マルチシグで新しい専用アドレスを使用すべきです。他のマルチシグや個人ウォレットと共有せず、署名者は地理、組織的役割、法的実体において多様であるべきです——ウォレットのリスクレベルが上がるにつれ分散を高めます。

そのリスクレベルは正式なグレーディングから来るべきです：各ウォレットをビジネスへの財務的影響、プロトコル依存性、評判リスクで評価し、各グレードを異なる閾値、承認フロー、監視密度にマッピングします。グレーディングを6ヶ月ごと、および大規模なTVL変更、コントラクトアップグレード、セキュリティインシデントの直後に見直します。

ブラインド署名と署名環境の分離

ブラインド署名とは、署名ツールがトランザクションが実際に何をするかではなく、calldataハッシュを表示することを意味します。これは仮定のリスクではありません：署名時に署名者はインターフェースからトランザクションの実際の意味を理解できず、そのギャップがBybitインシデントの直接的な原因の一つでした。署名に使用されたフロントエンドまたはバックエンドが侵害され、コントラクト自体にはバグがなかったにもかかわらず、署名者が悪意のあるトランザクションを承認してしまいました。

上記の3つの次元をロックダウンすることは、周囲の署名プロセスが同様に強化されている場合にのみ有効です。構成に関わらずいくつかの標準が適用されます：

• 署名ハードウェアの必須化。 すべての本番マルチシグ操作は、完全なトランザクションサマリーを表示するのに十分な大きさの画面を持ち、クリア署名をサポートし、PINプロテクションとファームウェア整合性検証を備え、メーカーまたは認定再販業者に限定されたサプライチェーンを持つハードウェアウォレットを使用すべきです——受領時に真正性を確認してください。
• 物理的に分離された署名環境。 署名は日常のオフィスネットワークを共有しないエアギャップデバイスで実行すべきです；高価値のオペレーションには専用署名デバイスが必要です。署名サービスを、ビジネスロジックとフロントエンドから物理的に分離した独立したセキュリティドメインに展開してください。署名ノードは公開インターネットに直接露出すべきではありません——VPNまたは専用線経由でのみ接続してください。署名オペレーションのログはビジネスシステムが変更できない別の場所に保存すべきです。
• 独立したトランザクション検証。 署名前に独立したチャネル——専用端末、ハードウェアデバイス、またはサードパーティのトランザクションシミュレーション/リスクサービス——を通じてトランザクション内容を確認してください。このチェックは独立したサードパーティが行うのが最善であり、自社のフロントエンドやバックエンドだけに頼るべきではありません——内部システムのみを信頼することそのものが単一障害点です。Bybitの場合のように内部フロントエンドやバックエンドが侵害されると、署名者が画面で見るものは改ざんされた偽の情報となり、自分自身に対して検証しても検証にはなりません。ペイアウトパスは特にこの独立した防衛ラインが必要です。
• クリア署名とクロス検証。 トランザクションのセマンティクスを解析するツールを使用し、署名者がcalldataの文字列ではなく「0x1234...に1,000 USDCを送金」と表示できるようにし、チェーンID、ターゲットアドレス、calldata、値、ノンス、オペレーションタイプなどの主要パラメータを少なくとも2つの独立したツールまたはインターフェースで同一であることをクロス検証してください。
• 人間と自動化のデュアルチェック。 自動化されたルールエンジンが最初のスクリーニングを処理し、人間が送信前に大規模なトランザクションを確認します。
• ゼロトラストとバックアップ。 署名サービス、ビジネスロジック、フロントエンドインターフェースを異なるセキュリティドメインに展開し、プライマリ署名UI、RPC、ブロックエクスプローラーのフォールバックを維持し、単一のベンダーまたはサービス障害が緊急署名をブロックできないようにします。

マルチシグのオペレーション標準

鍵と閾値の選択だけでは限界があります。いくつかのオペレーション標準も同様に重要です。

マルチシグレジストリ。 すべてのマルチシグの単一レコードを維持し、各エントリには少なくとも：アドレス、チェーン、署名閾値、リスクグレード、目的、署名者アドレス、コントロールされるコントラクト、オンチェーンロール、最終レビュー日を含めます。セキュリティに敏感な変更は24時間以内にレジストリを更新すべきであり、通常の変更は3日以内に行います。

署名者ライフサイクル管理。 オンボーディング前に、候補アドレスに特定のメッセージに署名させ、独立したツールで確認することでアドレスを検証します。リスクグレードに応じて離脱または削除された署名者の権限を削除するSLAを設定します——緊急は48〜72時間以内、重要は7日以内、それ以外は14日以内。各署名者がまだ自分の鍵をコントロールしていることを確認する四半期アクセスレビューを実施し、署名者トレーニングを少なくとも年1回更新します——トランザクション確認、緊急手順、ソーシャルエンジニアリング/フィッシング防御を網羅し、終了後に実地評価を行います。

シードフレーズとバックアップの保護。 いかなる形のデジタルストレージも禁止します——クラウドドライブ、写真アルバム、ドキュメントも含めて。バックアップは異なる地理的な場所に分散して保管し、自然災害、盗難、オペレーターの失踪に対して回復可能にします。完全な回復情報を保持する単一ポイントを設けないでください。

安全なコミュニケーション。 異なるプラットフォームのプライマリチャネルとバックアップチャネルを使用して署名者間で調整し、それぞれMFA、エンドツーエンド暗号化、招待制メンバーシップを強制します。署名前に、ハイジャックされたIMアカウントが署名者になりすますのを防ぐために、独立したチャネル——ビデオ通話、パスフレーズ、認証された第2チャネル——を通じて署名者のアイデンティティを確認します。

緊急対応SLA。 インシデントの重大度ごとに署名者の応答時間を設定します。例えば、緊急は2時間未満、時間的制約がある場合は2〜12時間、通常は24〜48時間。署名者の到達可能性を紙の上だけでなく四半期ごとにテストし、漏洩した鍵、到達不能な署名者、侵害されたコミュニケーションチャネル、緊急プロトコルオペレーションなどのシナリオをカバーするエンドツーエンドの緊急ドリルを年1回以上実施します。

マルチシグのオンチェーン監視。 署名者/閾値の変更、閾値超えの送金、ノンスのギャップ、未知のアドレスとのインタラクション、失敗したトランザクション、モジュール/ガードの変更、異常な提案者ウォレット残高を監視します。監視インフラ自体が改ざん耐性を持つ必要があります。

APIセキュリティ

APIセキュリティは決済バックエンドの最初の防衛ラインです。つまり、APIキーとHMAC署名またはFIDO2/WebAuthnによる認証、ブルートフォースと悪用を防ぐためのレートリミット、CDN/WAFサービスによるDDoS保護、インジェクションを防ぐためのすべての入力パラメータの厳格な検証、そして各API呼び出しが完全な監査証跡を残すためのログ監査が必要です。

署名環境はこれらすべてから分離する必要があります——単に保護されるだけでなく——それが署名サービスが上記のように独自のセキュリティドメインに属する理由です。

オペレーションセキュリティ：人、ベンダー、独立監査

2026年のいくつかの主要インシデントにはソーシャルエンジニアリングが関与していました——偽の採用、ITサポートのなりすまし、AIフェイススワップなどがその例です。それに対抗するには、3つのレベルが協調して機能する必要があります。

まずトレーニングと評価：署名システム、本番資格情報、または機密オペレーションへのアクセスを持つすべての人がオンボーディング時にセキュリティトレーニングを完了し、年次で更新し、プロセス変更から30日以内にコンテンツを更新します。

職務の分離も同様に重要です：開始、承認、実行を同一人物が行えないようにし、管理者アカウントが直接ペイアウトできないようにします。署名などの高感度オペレーションには専用デバイスを使用します——フルディスク暗号化、自動ロック——ハードウェアウォレットは未使用時に金庫に保管し、すべてのリモートアクセスをVPN経由でルーティングします。

サードパーティも同じ規律が必要です。ベンダーを選択する前にデューデリジェンスを実施し、主要ベンダーのコンプライアンスとセキュリティ状態を年1回再レビューし、サードパーティアクセスには明確なスコープ、目的、有効期限を設定します——期限が切れるかプロジェクトが終了したら即座に取り消します。アクセスを付与する前にサードパーティの担当者のアイデンティティを独立して確認します。

これらのいずれも、内部の自己チェックだけに依存すべきではありません。ペネトレーションテスト、レッドチーム演習、コードおよびスマートコントラクト監査を少なくともカバーする独立したサードパーティセキュリティ評価を定期的に実施します。調査結果を一つ一つ修正し、次の評価ラウンドでクローズを確認します。

開発およびインフラセキュリティ

近年のいくつかの主要な決済および暗号資産インシデントは、侵害された開発プロセスに起因しており——コントラクトと署名ロジック自体はまったく問題ありませんでした。つまり、開発とインフラのレイヤーは署名レイヤーと同じ注意が必要であり、4つの領域にわたります。

開発環境の分離は、開発アカウントを特権アカウント（署名、クラウド管理）から分離し、本番資格情報を開発環境から遠ざけ、開発ツールと拡張機能を承認リストに載せます。

コードリポジトリとサプライチェーンには、ブランチ保護、署名付きコミット、メインブランチへの複数人によるレビューが必要です。公式リポジトリからのみ固定バージョンとタイポスクワッティングチェックで依存関係を取得し、公開された鍵を即座に取り消しローテーションする自動シークレットスキャンを実行します。

CI/CDでは、パイプライン設定変更には複数人の承認とバージョン管理が必要であり、再現可能なビルドを維持します。シークレットはVaultまたはクラウドKMSなどの専用マネージャーを通じて管理します——本番シークレットは人間が直接アクセスできないようにします——SASTと依存関係スキャンはオプションではなく展開の前提条件とします。

インフラとクラウドでは、特権アクセスをジャストインタイムプロビジョニング、複数人による承認、時間制限を通じて付与します。緊急時のためにブレークグラスアカウントを維持しますが、すべての使用に対してアラートを出します。完全な監査ログ、管理者オペレーションへのリアルタイムアラート、定期的に訓練されたバックアップと災害復旧を維持します。

ドメイン、DNS、アイデンティティ：過小評価されている攻撃面

ドメインとDNSは暗号資産における非常に過小評価された攻撃面です——多くのフィッシングインシデントと盗難は、侵害されたレジストラアカウントまたはハイジャックされたDNSに起因しています。ユーザーが資金オペレーションを開始するドメインを保護することは、署名環境を保護することと同様に重要です。

レジストラアカウントを高特権アカウントとして管理します：ハードウェアキーMFAを強制し、転送、削除、ネームサーバー変更などの重要な変更にはアウトオブバンドの第2確認を要求します。DNSとメール側では、重要なドメインでDNSSECを有効にし、CAAを使用して証明書を発行できるCAを制限し、すべての送信ドメインでSPF/DKIM/DMARC（p=reject）を設定します——非送信ドメインもなりすましを防ぐために明示的にメールを拒否するよう設定します。

DNSレコードの変更、ネームサーバーの委任、異常な証明書透明性ログ発行を継続的に監視し、監視対象のドメインに依存しない監視インフラを使用します。ドメインハイジャックと不正転送の処理プロセスを文書化し、年1回訓練し、失効したドメインが侵入口にならないよう段階的な期限切れ警告と自動更新を設定します。

アイデンティティとアカウントは、ほぼすべての横移動の侵入口です。組織アカウントの完全な一覧と、厳格なMFA標準は、どんな単一点防衛よりも重要です。

アカウント一覧から始めます：すべての組織アカウント——ソーシャルメディア、メール、SSO/IdP、レジストラ、カストディプラットフォーム、コードリポジトリ、クラウドルート、主要SaaS——を明確なオーナーと共に登録し、定期的にレビューします。高特権アカウントにFIDO2/WebAuthnハードウェアキーによるフィッシング耐性MFAを強制し、SMSや音声を主要要素として絶対に使用しません——SIMスワップ、SS7、音声フィッシングはすべてそれらを迂回できます。これはアカウント乗っ取りに対する最も効果的な単一の防御策です。

一意の強力なパスワードを持つパスワードマネージャーを強制し、共有ログインを禁止し、回復メールと電話を組織ドメインに制限します——回復コードは個人メールやクラウドではなく安全なストレージに保管します。誰かが離職した場合、24時間以内にすべてのアクセスを取り消し、彼らが触れた共有資格情報をローテーションし、高特権アカウントがアクティブな間は行動と資格情報漏洩の監視を継続します。

AIエージェントのアーキテクチャが設計上安全でない理由

決済企業は開発とオペレーション効率を高めるためにAIツールとエージェントをますます使用していますが、これにより、適切に対処しなければ資金を直接脅かす新たな攻撃面が開かれます。

見落とされやすい点はここです：AIエージェントは質問に答えるモデルではありません。外部コンテンツを読み取り、ツールを呼び出し、資格情報を保持し、アクションを実行できるマシンです。リスクの根本は、信頼できないコンテンツから読み取ったテキストを実行すべき指示として扱うことにあります。

つまり攻撃者には脆弱性も盗まれたアカウントも不要です。ドキュメント、ウェブページ、コードコメント、またはPRの説明に1文を隠すだけで、エージェントの動作をハイジャックしてデータを漏洩させたり、不正なアクションを実行させたりできます。これはプロンプトインジェクションと呼ばれ、2026年までにリモートコード実行に直接エスカレートすることが示されています——Microsoftはエージェントを実行しているマシンで単一のプロンプトがプログラムを起動することを実証し、GitHub Copilot、Cursor、MCPインフラはそれぞれCVSS 9.6以上と評価されたRCE脆弱性を開示しています。

特権アクセスを持つものにとってはさらに深刻です。開発またはオペレーションエージェントは、デフォルトでオペレーターのファイルアクセス、シェル権限、データベースキーを継承します。2026年の主要なコーディングエージェントを対象にした研究では、すべてのエージェントがプロンプトインジェクションによって破られ、適応的な攻撃成功率は85%以上でした。信頼できない入力を処理するエージェントは、あなたの資格情報を保持する潜在的なインサイダーとして扱うべきです——サプライチェーンも高リスクのリンクです：2026年3月、毒入りのAIゲートウェイ依存関係が3時間公開リポジトリに置かれ、約47,000回ダウンロードされました。

資金のコントロールを失わずにAIエージェントの効率を得る方法

アプローチは、エージェントを信頼できないコードに適用するのと同じ制約のもとに置くことです。5つのコントロールにわたります：

• 分離された実行 — エージェントのツール実行をサンドボックスで実行し、プロンプトインジェクションが実際のシェル、本番鍵、または署名環境に到達できないようにします。
• 最小権限 — エージェントのツール、データベースキー、MCPサービスに1つのオペレーションに必要な最小限のみを付与し、「フルアクセス」の資格情報は決して付与しません。
• 資金オペレーションへの人間のゲート — 送金、署名、または権限変更に関わるものについては、エージェントは提案のみ可能であり、自動実行はできません。独立した人間の承認がここでも適用されます——上記の署名検証の背後にある原則と同じです。
• 信頼できる指示と信頼できないデータを分離する — アーキテクチャレベルでこれを行い、モデルが「自分で区別する」ことを期待しません。
• サプライチェーンのロック — 通常のコードリポジトリに適用するバージョン固定と出所チェックを、AI関連の依存関係にも適用します。

これらの制約は理論に留まる必要はありません。BlockSecのオープンソースWeb3 Companionはセキュアなエージェンティックウォレットのリファレンス実装です（MITライセンス、研究プレビュー）。AIエージェントがオンチェーントランザクションの準備をユーザーに支援しながら、秘密鍵と最終承認をエージェントの手の届かない場所に完全に保持できます。その脅威モデルはエージェント自体を信頼できないものとして扱います——完全に侵害されたエージェントでさえユーザーの資金を移動できないことをシステム全体で保証する必要があります。

アーキテクチャは3つのポイントに基づいています。鍵の分離は、1つの独立した署名モジュール（別のGoプロセス）のみが秘密鍵に触れることができることを意味します——エージェントはトランザクションインテントIDを受け取り、署名を要求できますが、鍵を見ることはありません。鍵はエンベロープ暗号化（AWS KMSまたはローカルAES-256）で保存され、平文は署名の瞬間のみメモリに存在し、その後ゼロ化されます。

ブロードキャスト前に、トランザクションは4つのレイヤーを順番に通過し、それぞれが前のレイヤーが失敗したと仮定します：トランザクションシミュレーション（calldataのデコード、リバートの予測）、カウンターパーティリスクスコアリング、純粋なGoハードポリシー制限（トランザクションごとの上限、日次予算、ホワイトリスト——エージェントはこれらを変更できません）、最後にパスキー人間確認——WebAuthnの指紋または顔スキャンでソフトウェアのみの攻撃では偽造できません。鍵、ポリシー、パスキーは3つの独立した信頼境界を形成し、1つを侵害しても他の2つはそのまま残ります。

AIエージェントは確かに効率を高めることができますが、資金と署名の唯一のコントロールを持ってはなりません。最小権限サンドボックスにアシスタントとして置き、資金と署名の最終決定は人間に任せます。

まとめ

鍵管理は1つの決定ではありません——3つの決定であり、独立して行われた後に組み合わされます：誰が署名しなければならないか、鍵またはシェアが物理的にどこに存在するか、そしてインターネットにどれだけ露出しているか。各資金ティアで正しい組み合わせを選び、強化された署名インフラでそれを支援し、上記のオペレーション標準でそれを維持することが、2025〜2026年の鍵および署名関連インシデントの背後にあるほとんどのギャップを解消するためのBlockSecのアプローチです。そして、その領域が現在鍵を超えて拡張しているため——API、人、ベンダー、コードパイプライン、ドメイン、アイデンティティ、AIエージェントへ——それぞれが同じ扱いを必要とします：前のレイヤーが失敗したと仮定し、資金が移動できるすべての場所に人間をループに入れます。

決済システムのコンプライアンスプログラムの残りと並んで鍵管理とオペレーションセキュリティがどこに位置するかの全体像については、暗号資産決済セキュリティとコンプライアンスプレイブック（PDF）をダウンロードしてください。

FAQ

MPCとマルチシグの実際の違いは何ですか？ マルチシグは複数の完全な秘密鍵であり、それぞれがオンチェーンで別々に検証されます——透明ですが、署名者のローテーションにコストがかかり煩雑です。MPC（閾値署名）は完全な秘密鍵が存在しないように生成された複数の鍵シェアであり、部分署名はオフチェーンで1つの署名に結合されます——柔軟で安価ですが、調整インフラに依存します。

Shamir秘密分散（SSS）はMPCと同じですか？ いいえ。SSSは既存の完全な秘密鍵をピースに分割し、署名するためにメモリ内で完全な鍵を再構成します。これにより再構成の瞬間が単一障害点となります。実際のMPC（TSS）は完全な秘密鍵を再構成することはありません——各当事者は自分のシェアから部分署名のみを計算します。

TEEとHSMの違いは何ですか？ TEE（Intel SGX、AWS Nitro、Apple Secure Enclaveなど）は、MPCプロトコルを含む任意のコードを実行できる汎用CPU上の分離された暗号化領域です——強力な論理的分離ですが、HSMよりも物理的な改ざん耐性と認証は弱いです。HSMは専用の改ざん耐性ハードウェアであり、秘密鍵は内部で生成され、エクスポート不可としてマークされ、物理的に外に出ることができません。

ウォームウォレットとは何ですか？ホットまたはコールドとどう違いますか？ ウォームウォレットはオンラインですが、秘密鍵を保護された環境（専用署名サービスまたはHSM）に分離し、署名ループに人間が必要であり、日常的な決済に使用されます——常時オンラインで自動化されたホットウォレットと完全にオフラインでエアギャップされたコールドウォレットの中間に位置します。

コールドストレージについてBlockSecが具体的に推奨することは何ですか？ チームのオンチェーンオペレーション能力によって異なります：成熟したオンチェーンオペレーションを持つチームは、各署名者の鍵をHSMまたはハードウェアウォレットに保管したコントラクトマルチシグ（例：Safeの3-of-5）を使用できます；オペレーションの複雑さを減らしたいチームは、TEE内のシェアを使用したMPC閾値署名と、トランザクション安全チェックのための独立したサードパーティの共同署名者を使用できます。

ブラインド署名とは何ですか？なぜ危険ですか？ ブラインド署名とは、署名インターフェースがトランザクションが実際に何をするかではなくcalldataハッシュのみを表示する場合です。署名者は承認しているものの実際の意味を確認できず、それがBybitインシデントの直接的な原因の一つでした。

AIエージェントは暗号資産決済オペレーションで信頼できますか？ 単独のコントロールには信頼できません。AIエージェントは資金オペレーションを提案するのみ許可され、自動実行は決してできません——送金、署名、権限変更はすべて独立した人間の承認が必要であり、エージェントは最小権限サンドボックスで実行します。

プロンプトインジェクションとは何ですか？どれほど深刻ですか？ プロンプトインジェクションは、ドキュメント、ウェブページ、コードコメント、またはPRの説明などの信頼できないコンテンツに指示を隠し、AIエージェントの動作をハイジャックします。2026年までに、CVSS 9.6以上と評価された主流のコーディングツールに影響する開示された脆弱性でリモートコード実行にエスカレートすることが示されています。

アカウント乗っ取りに対する最も効果的な単一の防御策は何ですか？ フィッシング耐性MFA——高特権アカウントにFIDO2/WebAuthnハードウェアキーを強制し、SMSや音声を主要要素として決して使用しないこと。SIMスワップ、SS7、音声フィッシングはすべてそれらのチャネルを迂回できます。