﻿---
title: "公開鍵と秘密鍵"
description: "公開鍵暗号により、ウォレットは秘密鍵でブロックチェーン取引に署名し、ネットワークは対応する公開鍵で署名を検証できます。鍵、アドレス、リカバリーフレーズの違いと署名リスクを解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 公開鍵と秘密鍵

> 教育目的の情報であり、セキュリティまたは投資の助言ではありません。ブロックチェーン取引は取り消せない場合があります。秘密鍵やリカバリーフレーズは決して開示せず、署名前にすべての取引を確認してください。

<a id="answer"></a>

## 直接の答え

公開鍵と秘密鍵のペアは、ブロックチェーン上の操作を承認、検証するための非対称暗号の関係です。秘密鍵はデジタル署名を作る秘密データです。対応する公開鍵は共有でき、秘密鍵を明かさずに他者が署名を検証できます。

ブロックチェーンアドレスは通常、公開鍵、スクリプト、またはアカウント規則から導出され、すべてのネットワークで公開鍵そのものと同一ではありません。導出方法とアドレス形式はネットワークごとに異なります。アドレスは宛先やアカウントを示し、支配権は通常、そのネットワークの支出または承認規則を満たせるかで決まります。

秘密鍵を持つことは、コインがウォレット内に保管されていることを意味しません。資産や使用可能なアウトプットは台帳に記録され、鍵は有効な状態変更を承認するために使われます。鍵を入手した者は保有者として署名できる可能性があり、唯一使える鍵を失うと自己管理資産へ永久にアクセスできなくなる場合があります。

<a id="mechanism"></a>

## 仕組み

基本的な署名の流れは次のとおりです。

1. ウォレットソフトウェアは暗号学的に安全な乱数から秘密鍵を生成するか、定められた方式でウォレットシードから導出します。
2. 一方向の数学演算により対応する公開鍵を導出します。アルゴリズムと実装が安全なら、公開鍵から秘密鍵を求めることは計算上困難であるべきです。
3. ネットワーク規則により、公開鍵からアドレス、スクリプト、アカウントを導出するか、公開鍵と関連付けます。ネットワークごとに曲線、ハッシュ関数、エンコード、アカウントモデルが異なる場合があります。
4. ウォレットは秘密鍵で特定の取引やメッセージに署名します。署名は正確にエンコードされたデータにだけ適用され、データを変えると無効になります。
5. ネットワーク参加者は、承認された操作を受け入れる前に公開鍵とプロトコル規則で署名を検証します。検証によって秘密鍵が明らかになることはありません。

リカバリーフレーズと秘密鍵は同じものではありません。多くの階層的決定性ウォレットでは、フレーズはシードを再作成するためのエントロピーを表し、そのシードから複数の鍵とアドレスを導出します。そのため、フレーズを知った者はすべての派生アカウントを支配できる可能性があります。ウォレットのパスワードは通常、ローカルのウォレットファイルを暗号化または解除するもので、基礎となる鍵の代わりにはならず、それだけで鍵を復元できません。

公開鍵と秘密鍵による支配ですべてのブロックチェーンアカウントを説明できるわけでもありません。たとえば、Ethereum の外部所有アカウントは鍵ペアで管理されますが、コントラクトアカウントはデプロイ済みコードで管理され、マルチシグ、時間遅延、復旧規則を実装できます。

<a id="example"></a>

## 例

Alice が Bob に受取アドレスを渡します。Bob のウォレットはネットワークとアドレス形式を確認して支払いを構築し、受取人、金額、手数料の確認を求めます。ウォレットは Bob の秘密鍵でその取引だけにローカル署名し、署名済み取引を送信します。秘密鍵自体が Alice やネットワークへ送られることはありません。

ノードは署名と関連する支出規則を検証します。有効な署名は必要な鍵が取引を承認したことを示しますが、Bob の法的身元、Alice の信頼性、取引の経済的妥当性を証明しません。Bob が誤ったネットワーク、受取人、コントラクト操作のデータに署名すれば、暗号が正しくても誤った結果を承認し得ます。

<a id="risks"></a>

## リスク

- **漏えい：** フィッシング、マルウェア、クラウドバックアップ、スクリーンショット、ブラウザー拡張機能、偽サポートにより秘密鍵やリカバリーフレーズが漏れる可能性があります。どちらも完全な支配権を与える情報として扱います。
- **紛失：** 端末の破損、パスフレーズ忘れ、不完全なバックアップ、互換性のない導出設定により復元できなくなる場合があります。秘密をさらさず、文書化された復元手順をテストしてください。
- **不良な乱数やソフトウェア：** 予測可能な鍵生成、欠陥のある署名コード、サプライチェーン侵害、悪意あるウォレットは、健全な暗号を無効にします。保守されているソフトウェアと信頼できる署名機器を使います。
- **署名内容の曖昧さ：** 署名は送金、トークン承認、注文、ログイン、その他のメッセージを承認し得ます。人が読める意図を読み、エンコードされた詳細、ネットワーク、アドレス、金額を独立して確認します。
- **運用の集中：** 一つの鍵ですべての資産を管理すると単一障害点になります。必要に応じて残高と役割を分け、オンライン露出を減らし、高額用途ではハードウェア署名、マルチシグ、ポリシー管理型アカウントを検討します。

秘密鍵やリカバリーフレーズが漏れた可能性があれば、侵害済みとみなします。クリーンな端末で独立生成した新しいウォレットを作り、バックアップを確認し、安全に実行できる時点で残る資産と必要な権限を移します。ウォレットを検査、修復できると称するウェブサイトに古い秘密を入力しないでください。

<a id="misconceptions"></a>

## よくある誤解

### 誤解 1：秘密鍵は単なるウォレットのパスワードである

パスワードはローカルアプリや暗号化キーストアを保護できます。秘密鍵は署名を承認するものであり、アプリのパスワードをリセットしても失った鍵やリカバリーフレーズは再作成されません。

### 誤解 2：アドレスと公開鍵は常に同じである

アドレスの構築方法はプロトコル固有です。多くのアドレスは生の公開鍵ではなくハッシュ、スクリプト、アカウント規則をエンコードし、一部のコントラクトアドレスには秘密鍵自体がありません。

### 誤解 3：公開鍵を共有すると秘密鍵を計算される

安全な公開鍵システムは公開鍵と署名を共有できるよう設計されています。現実的な脅威は弱い乱数、実装の欠陥、秘密の漏えい、将来の暗号解読であり、通常の検証ではありません。

### 誤解 4：有効な署名は署名者の身元を証明する

プロトコル規則の下で必要な鍵が署名対象データを承認したことだけを証明します。その鍵を実在する個人や組織と結び付けるには別の身元証拠が必要です。

<a id="related"></a>

## 関連トピック

- [秘密鍵の管理](/ja/crypto/private-key-management/)
- [リカバリーフレーズ](/ja/crypto/seed-phrase/)
- [暗号資産ウォレット](/ja/crypto/wallet/)
- [ハードウェアウォレット](/ja/crypto/hardware-wallet/)
- [暗号学的ハッシュ](/ja/crypto/cryptographic-hash/)

<a id="sources"></a>

## 情報源

- [ブロックチェーン技術の概要](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-21）
- [公開鍵](https://csrc.nist.gov/glossary/term/public_key) - NIST Computer Security Resource Center（参照日：2026-08-21）
- [ウォレット](https://developer.bitcoin.org/devguide/wallets.html) - Bitcoin Developer Documentation（参照日：2026-08-21）
- [Ethereum アカウント](https://ethereum.org/developers/docs/accounts/) - Ethereum.org（参照日：2026-08-21）

Source: https://wiki.fcontext.com/ja/crypto/public-private-key/index.mdx
