スマートコントラクトとは｜企業担当者向けに「止められない・直せない」前提を整理

ステーブルコインの検討資料には「スマートコントラクト」という言葉がよく出てきますが、稟議の場で「それは何か」と聞かれて一言で答えられる担当者は多くありません。結論から言うと、スマートコントラクトはブロックチェーン上で動くプログラムです。そして、ステーブルコインを受け取る企業は、自社で一行もコードを書かなくても、その時点で他社が書いたスマートコントラクトを使っています。本記事は、企業の担当者がこの言葉を正しく扱い、「止められない・直せない」という前提を社内でどう確認するかを整理します。

なお、本記事で引用するethereum.org（イーサリアムの開発者向け公式ドキュメント）の記述は、日本語版で2026年9月25日に確認したものです。

スマートコントラクトとは——「契約書」ではなく「プログラム」です

ethereum.orgの開発者向けドキュメントは、スマートコントラクトを「単にイーサリアム・ブロックチェーン上で実行されるプログラム」と説明しています。ブロックチェーン上の特定のアドレス（台帳上の宛先を表す文字列）に置かれた、処理の手順とデータのまとまりだというのが同ドキュメントの整理です。

同ドキュメントは、たとえとして自動販売機を挙げています。お金を入れて商品を選べば、決められた商品が出てくる。人が間に入らず、決められた条件がそろえば決められた処理が実行される、という点が共通しています。

ここで押さえておきたいのは、名前に「契約」と付いていても、法的な契約書ではないという点です。取引先との権利義務は、これまでどおり契約書や注文書で決まります。プログラムは書かれたとおりに動くだけなので、止まったときや想定外の動きをしたときの扱いは、契約書の側で決めておく必要があります。

プログラムをブロックチェーン上に配置することを「デプロイ」と呼びます。デプロイされたプログラムは、ブロックチェーンに参加する多数のコンピュータで同じように実行されます。どこか一社のサーバーで動いているわけではない、というのが通常の業務システムとの大きな違いです。

図: ステーブルコインを受け取る企業と、その裏で動くスマートコントラクトの関係（当サイト作成）

ステーブルコインを受け取った時点で、他社のコントラクトを使っています

日本では、ステーブルコインは資金決済法上の「電子決済手段」として整理されています。制度上の位置づけとは別に、技術の側から見ると、多くのステーブルコインは「トークン」（ブロックチェーン上で発行される価値の単位）として、スマートコントラクトで作られています。

その代表的な規格がERC-20です。ethereum.orgによれば、ERC-20は2015年11月に提案されたトークンの標準規格で、あるアカウントから別のアカウントへの送金、残高の取得、総供給量の取得といった機能を、スマートコントラクトの中に実装するためのものです。つまり、「A社のアドレスに1万単位ある」という残高は、トークンのコントラクトの中の記録であり、送付はそのコントラクトの処理として実行されます。

同じ規格でも、送り先を誤ると取り返せない場面があります。ERC-20のページは既知の問題として、ERC-20トークンを扱うように作られていないコントラクトに送ると、トークンが「永久に失われる可能性があります」と注意を促しています。取引先から指定された受取先がどのような種類のアドレスなのかを確認する理由の一つです。オンチェーンの送付が取り消せない点はオンチェーンの送付に「組戻し」はないで扱っています。

さらに、同じ名前のトークンが別のブロックチェーンや別のアドレスに存在することもあります。銘柄は名前ではなく、どのチェーンのどのコントラクトアドレスかで特定します。この点は同じ銘柄でもチェーンが違えば届かないで詳しく整理しています。

「止められない・直せない」が原則、ただし例外は設計で決まります

ethereum.orgは、スマートコントラクトは「デフォルトでは削除できず、それらとの対話は不可逆的です」と説明しています。アップグレードに関するページでも、コントラクトは設計上イミュータブル（変更できない）であり、デプロイ後は処理の中身を更新できないと整理されています。改ざんされにくいという長所は、裏を返せば、不具合が見つかっても通常のシステムのようにすぐには直せないということです。

一方で、同じページは、処理の中身を別のコントラクトに置いて差し替える「アップグレードパターン」が考案されてきたことも紹介しています。代表例は、入口のコントラクトはそのままに、実際の処理を担うコントラクトを切り替える「プロキシ」という方式です。セキュリティのページでは、特定のアカウントにアップグレードやコントラクトの一時停止の権限を持たせる設計や、複数人の署名がそろわないと管理操作ができない「マルチシグ」の活用も説明されています。

どちらが優れているという話ではありません。ethereum.orgのアップグレードのページも、アップグレードできる設計ではユーザーが「恣意的に変更しないことを信頼する必要があります」と、その裏面を指摘しています。企業にとっての要点は、「誰が止められるか・誰が直せるか」はコントラクトの設計と運営者で決まるということです。ステーブルコインの中には、発行体が特定のアドレスの送付を停止・凍結できる機能を持つ設計のものもありますが、機能の有無や発動の条件は銘柄ごとに異なるため、必ず発行体の公式ドキュメントで確認します。凍結機能の仕組みと受け取る企業側の確認点は、ステーブルコインの凍結機能とはで整理しています。

また、「止める」はコントラクトの中だけで起きるわけではありません。金融庁の事務ガイドライン（17 電子決済手段等取引業者関係）Ⅱ－２－１－２－２⑹は、登録業者に対し、犯罪行為に利用された疑いのある取引を速やかに停止するための態勢の整備を求めています。企業から見ると、止まりうる層は少なくとも二つあり、それぞれ確認先が違います。

事案：海外の出版社から翻訳料を受け取る翻訳会社

以下は公表資料をもとに構成した想定事案です。実在の企業・案件ではありません。

①既存事業と既存ユーザー——産業技術文書と書籍の翻訳を手がける、従業員40人規模の翻訳会社です。取引先は国内の製造業と出版社が中心で、売上の2割ほどを海外の出版社数社が占めています。海外分は銀行送金で受け取っており、着金までの日数と受取手数料が経理の悩みになっています。

②やろうとしていること——海外の出版社1社から、次回の翻訳料について「このコントラクトアドレスのトークンで払いたい」とメールでアドレスが届きました。営業担当は前向きですが、社内にはブロックチェーンに詳しい人がいません。会社として決めたのは、受け取る前に「何を確認すれば受け取ってよいと言えるか」を整理することです。

③登録業者との役割分担——受け取りは、登録を受けた事業者の法人口座を通じて行う前提にします。口座の開設、本人確認、取り扱うトークンの選定、利用者からの問い合わせ対応は登録業者が担います。自社が担うのは、取引先から指定されたトークンが口座を持つ登録業者で取り扱われているかを確認すること、そして自社の受取アドレスを取引先に正しく伝えることです。取り扱われていないトークンであれば、その時点で受け取りは見送り、銀行送金に戻します。

④社内外への説明の具体像——取引先には、「当社は登録業者が取り扱う銘柄に限って受け取る」「コントラクトアドレスは発行体の公式サイトで照合する」「受け取りが確認できるまでは請求を消し込まない」の3点を回答文書で伝えます。社内では、営業には取引先に即答しないこと、経理には受け取ったトークンが停止・凍結された場合の記帳の扱いを事前に決めておくことを、1枚の社内連絡で周知します。請求書には、従来の銀行口座と並べて受取方法の選択肢を記載し、どちらで受け取ったかを経理が月次で照合できる形にします。

確認の観点を、社内と社外に割り振る

事案の翻訳会社が受け取りの可否を判断するために確認するのは、次の5つです。自社でコードを書かない企業にとっては、確認の多くが「外部の資料を読むこと」と「外部に書面で聞くこと」になります。

この表の「法務」の行が見落とされやすい部分です。スマートコントラクトの停止や凍結は技術の話に見えますが、実務上は「取引先が送付した時点で支払が済んだのか」「受け取ったトークンが凍結されたら売掛金はどうなるのか」という契約と会計の問題になります。自社の受取アドレスの管理を誰がどう担うかは法人のウォレットとカストディの基礎で整理しています。用語に迷ったら用語集もあわせてご覧ください。

スマートコントラクトを理解する目的は、コードを読めるようになることではありません。自社が使っているプログラムを誰が書き、誰が止められ、止まったら誰に連絡するのかを、稟議書に一行ずつ書けるようにすることです。そこまで書ければ、取引先から届いた一本のアドレスは、判断できる材料に変わります。