スマートコントラクトは、ブロックチェーン上に配置され、条件に応じて処理を実行するプログラムです。契約書そのものでも、何でも自動判断するAIでもありません。
「自動で動くなら、署名しただけで何が起きるの？」「監査済みなら安全？」と不安になりますよね。この記事では、Ethereumとの関係からガス、オラクル、トークン承認、事故時の対応まで、難しい言葉を一つずつほどいていきます。
この記事でわかること：スマートコントラクトの定義、Ethereum・EVM・Solidityとの関係、実行の流れ、主な用途、ガス代、承認や管理者権限のリスク、安全な確認手順がわかります。
1分で理解できるスマートコントラクト
| 確認項目 | まず押さえたいこと |
|---|---|
| 正体 | 特定アドレスに配置され、コードと状態を持つプログラム |
| 実行 | ユーザーのトランザクションや他コントラクトの呼び出しがきっかけ |
| Ethereumとの関係 | Ethereumは基盤、EVMは実行環境、Solidityは代表的な開発言語 |
| できること | 送金条件、トークン、DeFi、NFT、DAO、ゲームなどの処理 |
| できないこと | 外部情報を単独で取得すること、曖昧な事情を人のように判断すること |
| 費用 | 状態を変える処理では、計算量などに応じたガス代が必要 |
| 安全確認 | URL、チェーン、アドレス、関数、金額、期限、承認額、権限を確認 |
ブロックチェーン自体の仕組みがまだ曖昧なら、台帳・合意形成・秘密鍵の基礎を先に確認すると、この先がぐっと読みやすくなります。
スマートコントラクトとは？契約書との違い
この章でわかること：スマートコントラクトの正確な定義と、紙の契約・電子契約・一般的なWebプログラムとの違いがわかります。
スマートコントラクトとは、Ethereumなどのブロックチェーン上に配置され、コードで定めた条件に従って処理するプログラムです。Ethereum.orgでは、Ethereum上の特定アドレスに存在する「コード（関数）」と「データ（状態）」の集合として説明されています。
名前に「コントラクト」とありますが、すべてが法的な契約になるわけではありません。売買や利用規約の合意をコードで補助する場合はあるものの、契約成立や法的効力は、当事者の意思や適用法、サービス設計などを含めて個別に判断されます。
次の図は、利用者の操作がEthereum上の処理へ届く順序を示します。ウォレットは秘密鍵そのものを送るのではなく、利用者が内容を確認して署名します。署名済みトランザクションがネットワークへ送られ、検証後に対象関数が実行される流れです。成功すれば状態が更新され、必要に応じてイベントも記録されます。
自動販売機の比喩だけでは足りない
「お金を入れてボタンを押すと商品が出る」という自動販売機の比喩は、条件と結果を理解する入口には便利です。ただ、実際のスマートコントラクトには、呼び出す関数、保存される状態、実行権限、ガス、他コントラクトとの連携があります。誰も操作していないのに、未来の時刻を自分で察知して勝手に起動するとは限りません。
違いを見比べると、スマートコントラクトの得意分野が見えてきます。とくに「法的意味」と「コードによる処理」は別の軸としてご覧ください。
| 種類 | 実行主体 | 記録 | 変更 | 費用 | 法的意味 |
|---|---|---|---|---|---|
| 紙の契約 | 当事者・裁判所など | 紙や社内記録 | 合意等で変更 | 作成・執行費用 | 内容と法令により判断 |
| 電子契約 | 当事者・サービス運営者など | 電子署名・監査ログ | 手続に沿って変更 | サービス費用等 | 内容と法令により判断 |
| 一般Webプログラム | 運営者のサーバー | 運営者のDB | 運営者が更新可能 | 利用料・通信費等 | プログラム自体とは別 |
| スマートコントラクト | ネットワーク上のEVM | オンチェーン状態・ログ | 設計次第。プロキシ等で更新可能な場合あり | 状態変更ではガス代 | コードだけで一律に決まらない |
この章のまとめ
スマートコントラクトは、法的契約書の別名ではなく、ブロックチェーン上で動くプログラムです。まず「コードによる処理」と「法的な契約」を分けて考えましょう。
Ethereum・EVM・Solidityとの関係
この章でわかること：Ethereum、ETH、EVM、Solidity、dAppsとスマートコントラクトの役割を、混同せずに説明できるようになります。
Ethereumは、スマートコントラクトを配置・実行できるブロックチェーン基盤です。EVM（Ethereum Virtual Machine）は各ノードが同じ結果を得るための実行環境、Solidityはコントラクトを書く代表的な言語、ETHはガス代などに使われるネイティブ資産という関係になります。
Ethereumとスマートコントラクトは同じものではありません。道路網全体がEthereumなら、交通ルールに沿って動く個別の仕組みがスマートコントラクト、と考えると近いでしょう。Ethereum全体の特徴やETHとの違いを深めたい方は、基礎記事もあわせて確認してみてください。
コントラクトはアドレス・コード・状態を持つ
次の図は、一つのスマートコントラクトを構成する要素を整理したものです。アドレスはネットワーク上の宛先、コードは実行規則、状態は残高や設定値などの保存データを表します。関数は外部や内部から呼び出す処理の入口です。イベントは、フロントエンドなどが結果を追跡するためのログとして使われます。
ウォレットアドレスとコントラクトアドレスは、見た目がどちらも「0x」で始まるため紛らわしいところです。Ethereumでは、秘密鍵で管理される外部所有アカウント（EOA）と、コードで制御されるコントラクトアカウントがあります。見た目だけで送金先の種類を決めず、公式情報やブロックエクスプローラーで確認しましょう。
| 用語 | 何を指すか | 誰が制御するか | 主な注意 |
|---|---|---|---|
| EOA | 秘密鍵に対応するEthereumアカウント | 秘密鍵を管理する人・仕組み | 秘密鍵漏洩で操作権を失い得る |
| コントラクトアカウント | コードが配置されたアカウント | コードと設定された権限 | 管理者・更新権限も確認 |
| ウォレット | 鍵や署名を扱うアプリ・機器 | 利用者または保管事業者 | アドレスそのものではない |
| ウォレットアドレス | 通常はEOA等の受取先 | 対応する鍵の管理者 | チェーンと宛先を確認 |
| コントラクトアドレス | デプロイ済みコードの宛先 | コード。別途管理権限がある場合も | 偽アドレスに注意 |
dAppは複数の部品でできている
次の図は、dAppの画面からスマートコントラクトまでの接続関係です。ブラウザ上の画面が、ウォレットへ署名要求を渡します。RPCは画面やウォレットとEthereumノードをつなぐ通信窓口です。価格などの外部データが必要な処理では、別途オラクルが関わることがあります。
ここで大切なのは、dAppの画面とコントラクトは同じものではない点です。正しいコントラクトでも偽サイトから危険な署名を求められる場合があり、反対に公式らしい画面でも接続先が偽物かもしれません。MetaMaskの作成・接続・署名の基本は、専用記事で落ち着いて確認できます。
この章のまとめ
Ethereumは基盤、EVMは実行環境、Solidityは言語、dAppは画面やウォレットを含むアプリ全体です。似た用語も、役割で分けると迷いにくくなります。
実行の仕組みとガス・オラクル
この章でわかること：誰がスマートコントラクトを呼び出すのか、ガス代が必要な理由、失敗時の扱い、外部データにオラクルが必要な理由がわかります。
スマートコントラクトは、一般にEOAから送られたトランザクションや、別のコントラクトからの呼び出しをきっかけに実行されます。「条件を満たせば自動実行」という説明は一部を表していますが、誰かや何かが関数を呼ぶ仕組みまで確認しなければなりません。
状態を変えない読み取りは、画面側からガス代なしで照会できる場合があります。一方、送金、トークン発行、交換、承認など状態を変えるトランザクションでは、ネットワーク上の計算資源を使うためガス代が必要です。
次の図は、単純なETH送金とコントラクト呼び出しで必要な処理が異なることを示します。ETH送金もトランザクションですが、複数の関数やストレージ更新を伴う処理は計算量が増えやすくなります。実際の手数料は使用ガス量とガス単価などで決まり、混雑や処理内容で変動します。画面の見積額と上限を確認してから署名しましょう。
処理が途中で失敗し、状態変更が元に戻っても、そこまでの計算や検証はすでに行われています。そのためガス代が発生し得ます。ガスの計算や高騰時の考え方を詳しく知りたい方は、専用記事へ進むと整理しやすいですよ。
| 操作 | 署名する主な内容 | 権限・結果 | ガス | 注意 |
|---|---|---|---|---|
| ETH送金 | 宛先・金額・手数料条件 | ETH残高を移す | 送信者が支払う | 宛先とチェーン |
| トークン送金 | 宛先・数量・関数 | トークン残高を移す | 通常必要 | トークンアドレス |
| Approve | 利用者・対象・承認額 | 第三者へ引き出し権限を与える | 通常必要 | 無制限承認を避ける検討 |
| Permit | 署名データ・対象・額・期限等 | 対応トークンの承認を署名で設定 | 署名者が直接払わない設計も | 「ガスなし＝無害」ではない |
| コントラクト実行 | 関数・引数・送付額 | コードに従い複数処理 | 通常必要 | シミュレーションも保証ではない |
外部価格や天気にはオラクルが必要
次の図は、ブロックチェーン外の価格データがコントラクトへ届く流れです。Ethereum上のコントラクトは、標準状態ではWeb APIへ直接アクセスできません。そこでオラクルが外部データを取得・検証し、オンチェーンで利用できる形にします。データ源、更新頻度、停止、操作耐性に問題があれば、正しいコードでも誤った結果になる可能性があります。
この章のまとめ
実行には呼び出しが必要で、状態変更には通常ガス代がかかります。外部データを使うなら、コードだけでなくオラクルの仕組みも確認しましょう。
スマートコントラクトでできること・限界
この章でわかること：DeFi、NFT、DAO、ステーブルコイン、ゲーム、エスクローでの処理例と、コードだけでは解決できない限界がわかります。
スマートコントラクトは、共通ルールに沿って資産や権限を扱う処理に向いています。ERC-20は代替可能トークン、ERC-721は個別性のあるNFT、ERC-1155は複数種類のトークンを扱うための代表的な規格です。これらは商品名ではなく、互換性を高めるためのインターフェース規格になります。
次の図は、同じスマートコントラクト技術が複数の用途を支える様子を示します。DeFiでは交換・貸借・担保管理、NFTでは発行・移転、DAOでは提案・投票・実行などに使われます。ステーブルコインでは発行や償還、ゲームではアイテム管理、エスクローでは条件付き受渡しが例です。もっとも、各サービスは複数コントラクトや外部運営を組み合わせるため、用途名だけで安全性は判断できません。
| 用途 | 処理例 | 必要になり得るデータ | 主なリスク |
|---|---|---|---|
| DeFi | 交換・貸借・清算 | 価格・担保率 | コード、オラクル、流動性、清算 |
| NFT | 発行・所有権移転 | メタデータ・権限 | 偽コレクション、外部保存、管理者権限 |
| DAO | 提案・投票・資金実行 | 投票権・可決条件 | 投票集中、鍵管理、実行遅延 |
| ステーブルコイン | 発行・償還・移転 | 準備資産・価格 | 発行体、デペッグ、凍結権限 |
| ゲーム | アイテム発行・交換 | ゲーム状態・乱数 | 運営停止、外部サーバー、経済設計 |
| エスクロー | 条件付き預かり・受渡し | 履行確認 | 判定データ、紛争処理、法的関係 |
コードが正しくても市場リスクは残る
価格操作、流動性不足、担保価値の急落、運営者の鍵流出、規制変更は、コントラクトのバグとは別の問題です。複数のコントラクトを組み合わせるDeFiやブリッジでは、一か所の不具合が連鎖する場合もあります。「オンチェーンだから安全」と一括りにしないことが大切です。
| リスク分類 | 具体例 | 確認するもの |
|---|---|---|
| コード | 再入可能性、計算・権限ミス | 監査、テスト、更新履歴 |
| オラクル | 誤価格、遅延、停止 | データ源、集約方式、非常時対応 |
| 鍵・運営 | 管理鍵流出、不正な権限行使 | マルチシグ、タイムロック、権限 |
| 市場 | 流動性不足、価格操作、清算 | 取引量、担保条件、市場構造 |
| ガバナンス | 投票集中、悪意ある提案 | 投票配分、実行猶予、拒否権 |
| 規制・税務 | 制度変更、記録不足 | 金融庁・国税庁の最新情報 |
この章のまとめ
スマートコントラクトは多様な処理を共通ルールで動かせます。ただし、価格・流動性・運営・法律までコードだけで解決できるわけではありません。
変更・監査・管理者権限のリスク
この章でわかること：デプロイ後の変更可能性、プロキシ、管理者権限、監査・検証済み表示の限界、署名と承認の違いがわかります。
「ブロックチェーンのコードは絶対に変えられない」という理解は正確ではありません。配置済みコード自体が変わらない設計もありますが、参照先を差し替えるプロキシ、設定変更、緊急停止、発行・凍結などの管理者権限を持つ仕組みもあります。
次の図は、不変型・管理者型・プロキシ型の違いを示します。不変型は変更しにくい反面、欠陥への対処も難しくなります。管理者型は設定や停止ができる一方、鍵と権限の集中が新たなリスクです。プロキシ型はロジックを更新できますが、実装先や管理者の変更履歴まで追う必要があります。
| 設計 | 変更可能性 | 主な権限 | 透明性の確認 | 緊急停止 |
|---|---|---|---|---|
| 不変型 | 原則としてコード差替えなし | 設計により設定権限あり | コード・依存先を確認 | 実装がなければ不可 |
| 管理者型 | 設定値等を変更可能 | 停止・凍結・発行など | 権限者と履歴を確認 | 可能な場合あり |
| プロキシ型 | 実装先を更新可能 | アップグレード管理者 | プロキシ・実装・管理者を確認 | 設計次第 |
監査済み・検証済みは安全保証ではない
監査は専門家が一定の範囲と時点で問題を探す手続、ソース検証は公開ソースとオンチェーンのバイトコードの対応を確認しやすくする仕組みです。どちらも役立ちますが、無脆弱性や将来の安全を保証しません。監査後の更新、対象外のコントラクト、オラクルや画面側の欠陥もあり得ます。
| 確認方法 | 主な目的 | 分かること | 限界 |
|---|---|---|---|
| 監査 | 設計・コードの問題発見 | 対象範囲での指摘と対応 | 見落とし、対象外、更新後の差分 |
| 形式検証 | 数理的性質の検証 | 定義した性質への適合 | 仕様自体の誤り、全条件の網羅 |
| テスト | 想定ケースの動作確認 | 実装の振る舞い | 未想定ケースは残る |
| バグ報奨金 | 外部研究者からの報告促進 | 運用中の発見窓口 | 問題がない証明ではない |
| ソース検証 | 公開ソースとの対応確認 | 読めるコードとの一致確認 | 安全性そのものは証明しない |
署名・承認前の8項目を確認する
次の図は、ウォレットで署名・承認する前の確認順序です。公式URLか、意図したチェーンか、コントラクトアドレスが一致するかを最初に見ます。次に呼び出す関数、送る金額、署名の期限、トークン承認額を確認してください。最後に管理者権限やアップグレード可能性も見れば、画面だけでは見えないリスクを減らせます。
保存版・利用前8項目チェック：①公式URL、②チェーン、③コントラクトアドレス、④関数名、⑤金額、⑥期限、⑦承認額、⑧管理者・アップグレード権限を確認し、理解できない要求には署名しないようにしましょう。
承認や署名の意味が分からないまま進むのは避けたいところです。ウォレットの種類、秘密鍵の管理、取引所保管との違いを整理したい場合は、基礎記事へ戻って確認できます。
この章のまとめ
変更可能性にも不変性にも、それぞれ利点と弱点があります。「監査済み」の一言で決めず、権限・更新履歴・署名内容まで確かめましょう。
事故時の対応と初心者の安全な使い方
この章でわかること：誤った承認、偽サイト、未知のコントラクト、ハッキング疑いに気づいた直後の対応と、今後の安全な使い方がわかります。
危険な署名や承認をした疑いがあるなら、追加操作を止めることが先です。検索広告やDMの「復旧サポート」へ秘密鍵・シードフレーズを渡してはいけません。別の署名を重ねるほど被害が広がる可能性があります。
次の図は、事故の疑いに気づいたときの優先順位です。まず追加署名・送金を止め、ブックマークや公式発表から状況を確認します。対象チェーン、コントラクト、トランザクションID、承認状況を記録してください。必要なら承認取消や安全な新規ウォレットへの移行を検討しますが、事故の種類によって有効な対策は異なります。
承認取消だけで十分とは限らない
トークン承認だけが問題なら、正しいチェーンで承認を取り消すことが対策になる場合があります。しかし、秘密鍵やシードが漏れたなら、同じウォレット内で承認を消しても攻撃者が再操作できる可能性があります。新しい秘密情報で作ったウォレットへの移行を検討し、急ぐ場面でも送金先とガスを確認しましょう。
確定済みトランザクションは、一般に後から取り消せません。未確定取引の差し替え機能が使える場合もありますが、成立を保証するものではなく、チェーンやウォレットで条件が異なります。事故対応では、取り戻せると断定する相手を信用しないでください。
税務と日本法もオンチェーンの外に残る
DeFiやNFTをスマートコントラクトで取引しても、日本の税務や法令が自動的に対象外になるわけではありません。国税庁の「暗号資産等に関する税務上の取扱いについて（FAQ）」は、暗号資産の売却・使用・交換などの取扱いを示しています。取引日時、数量、円換算額、手数料、トランザクションIDを継続して保存しましょう。
金融庁は、暗号資産交換業者が登録業者であっても、信用性や取扱暗号資産の安全性が保証されるわけではないと案内しています。dAppや分散型サービスの法的位置づけは仕組みにより異なるため、個別の法律・税務判断は弁護士や税理士などへ確認してください。
暗号資産の税金について、売却・交換・決済の基本から記録方法まで整理したい方は、税務の専用記事へ進めます。
まとめ：理解できない署名は止めて確認しよう
スマートコントラクトは、ブロックチェーン上の特定アドレスに配置され、コードと状態を持ち、呼び出しをきっかけに処理するプログラムです。Ethereum、EVM、Solidity、dAppの役割を分けると、画面の裏で何が起きるのか見えやすくなります。
便利さと安全性は別問題です。初回は少額にし、URL、チェーン、アドレス、関数、金額、期限、承認額、管理者権限を確認しましょう。分からない項目が一つでもあれば、署名せず公式情報へ戻る。そのひと手間が、大切な資産を守る助けになります。
この章のまとめ
事故の疑いがあれば、追加操作停止と公式確認が先です。普段から少額・最小権限・記録保存を続け、理解できない署名は見送りましょう。
本記事は2026年7月24日時点の一般的な情報提供を目的とし、特定の暗号資産、dApp、取引、投資判断を推奨するものではありません。スマートコントラクト、ウォレット、手数料、税制、法令、サービス仕様は変更される場合があります。操作前に必ず各プロジェクト、Ethereum、金融庁、国税庁などの最新公式情報をご確認ください。暗号資産には価格変動、コードの欠陥、詐欺、誤送信、鍵の漏洩、資産を回収できないリスクがあります。将来の価格・利益・安全性・返金を保証するものではなく、法律・税務上の個別判断は弁護士、税理士等の専門家へご相談ください。
FAQ
スマートコントラクトとは何ですか。
ブロックチェーン上の特定アドレスに配置され、コードと状態を持ち、トランザクションなどの呼び出しをきっかけに処理するプログラムです。法的な契約書そのものでも、自由に判断するAIでもありません。
スマートコントラクトとEthereumは同じですか。
同じではありません。Ethereumはスマートコントラクトを配置・実行するブロックチェーン基盤です。EVMがコードを実行し、Solidityなどの言語でコントラクトを開発します。ETHはガス代などに使われます。
スマートコントラクトは本当に自動で実行されますか。
一般に、EOAからのトランザクションや別コントラクトからの呼び出しが必要です。時刻や外部条件で動かす場合も、呼び出す仕組みやオラクル等が関わります。「何もしなくても勝手に起動する」とは限りません。
処理に失敗してもガス代はかかりますか。
かかる場合があります。状態変更が元に戻っても、検証や途中までの計算にはネットワーク資源が使われるためです。署名前に見積額、ガス上限、関数、送付額を確認してください。
スマートコントラクトは変更・削除できますか。
設計によります。配置済みコードを差し替えない不変型もあれば、管理者設定やプロキシを通じて実装を更新できる仕組みもあります。実装アドレス、管理者、停止・更新権限を確認しましょう。
オラクルとは何ですか。
価格や天気など、ブロックチェーン外のデータをスマートコントラクトで使えるようにする仕組みです。データ源の誤り、更新遅延、停止、集中化がコントラクトの結果へ影響する可能性があります。
無制限承認やPermitは危険ですか。
承認先に広い権限を与えるため、内容を理解せず使うのは危険です。Permitもガスを直接払わない署名だから無害とは限りません。対象、金額、期限、チェーン、コントラクトを確認し、必要最小限を検討してください。
監査済みなら安全ですか。
安全保証ではありません。監査は一定範囲・時点で問題を探す手続で、見落としや更新後の差分、画面・オラクル・管理鍵・市場のリスクは残ります。監査範囲、指摘、対応、更新履歴も確認しましょう。
参考情報
この記事は、以下の一次情報・公式情報を参考に、2026年7月24日時点で整理しています。仕様、制度、税務は変更される場合があるため、利用前には必ず最新情報をご確認ください。
- Ethereum.org「Introduction to smart contracts」：スマートコントラクトの定義、アカウント、呼び出し、制約を確認できます。
- Ethereum.org「Anatomy of smart contracts」：状態、関数、イベントなどコントラクトの構成要素を確認できます。
- Ethereum.org「Transactions」：トランザクションの構造、ライフサイクル、コントラクトとのやり取りを確認できます。
- Ethereum.org「Gas and fees」：ガスの役割、計算量、失敗時にも手数料が発生し得る理由を確認できます。
- Ethereum.org「Oracles」：外部データが必要な理由、オラクルの構成と依存リスクを確認できます。
- Solidity公式「Security Considerations」：再入可能性、権限、公開情報、フェイルセーフなどの注意点を確認できます。
- EIP-20、EIP-721、EIP-1155、ERC-2612：トークン規格とPermit承認の原仕様を確認できます。
- 金融庁「暗号資産に関する相談事例等及びアドバイス等」：登録業者の確認と、登録が信用性・無リスクを保証しない点を確認できます。
- 国税庁「暗号資産等に関する税務上の取扱いについて（FAQ）」：令和7年12月最終改訂の暗号資産・電子決済手段に関する税務上の取扱いを確認できます。
