トランザクションは、すべての必須署名者から有効な
署名を受け取った場合にのみ実行されます。ローカル開発時は通常、
Keypairとして鍵を保持し、直接署名します。本番環境では、重要な問いは異なります：秘密鍵はどこに保管され、誰がその鍵で署名を承認できるのか？
秘密鍵をクライアントサイドのコードに埋め込んだり、フロントエンドにバンドルしたり、 ソース管理にコミットしたりしないでください。鍵を入手した者は誰でも、 そのアカウントの資金を完全に制御できます。
署名のアプローチ
| アプローチ | 鍵の保管場所 | 署名者 | 最適な用途 |
|---|---|---|---|
| ローカルkeypair | マシン上のファイルまたは環境変数 | コードが直接署名 | ローカル開発、テスト、CI |
| ブラウザウォレット | エンドユーザーのウォレット（例：Phantom、Solflare） | エンドユーザーがトランザクションごとに署名 | ユーザーが自分のトランザクションに署名するフロントエンドdApp |
| クラウドKMS / HSM | ハードウェアバックの鍵サービス（AWS KMS、GCP KMS、Vault） | バックエンドがサービスに署名を要求 | バックエンドサービス、トレジャリー運用、規制環境 |
| マネージド / MPCウォレット | プロバイダーのインフラ全体で分割または管理 | プロバイダーがポリシーに従って共同署名 | 組み込みウォレット、承認ワークフロー、機関向けカストディ |
ローカルkeypairは、生の鍵マテリアルをアプリケーション内に置く唯一のアプローチです。本番環境のすべてのアプローチでは、鍵を専用インフラに保管し、そのインフラに代わりに署名を依頼します。
バックエンド署名
サーバーが署名を必要とする場合（手数料の支払い、プログラムトランザクションの送信、トレジャリーの運用など）は、生のkeypairではなく、専用の鍵管理バックエンドを使用してください。Solana Foundationは、上記のすべてのバックエンド（Memory、HashiCorp Vault、AWS KMS、GCP KMS、Fireblocks、Privy、Turnkey、CDP、Crossmint、Dfns、Para、Openfort、Utila、Fordefi）に対して単一のSolanaSignerインターフェースを提供する統合署名ライブラリ（Rust、TypeScript、Python、Go対応）Keychainをメンテナンスしています。
インターフェースはバックエンド間で共通のため、アプリケーションコードを書き直すことなく、インメモリ鍵でローカル開発を行い、設定によって本番バックエンドへ切り替えることができます（Crossmintなど、ブロードキャストを代行するバックエンドは、代わりに署名と送信を一括で行う方式で呼び出します）。Keychainは@solana/kit、
Rust SDK、solders（Python）、solana-go v2
（Go）と互換性があります。
鍵管理、RPCセキュリティ、監視に関する完全な本番環境チェックリストについては、本番環境の準備を参照してください。
Is this page helpful?