ERC-20とは？仕組みと基本を解説｜トークン発行前に押さえる規格選定の視点

独自トークンの発行を検討し始めると、多くの場合まず候補に挙がるのがERC-20という規格です。ERC-20は、イーサリアム上でトークンを発行するための標準規格(インターフェース)であり、名称・残高・送金の仕組みが統一されているからこそ、主要なウォレットや取引所がそのまま対応できます。

ただし、規格を選ぶだけでは発行の検討は終わりません。ERC-20が定めているのは「窓口」の部分だけで、どのチェーンで発行するか、トークンをどう経済設計するかは別途詰める必要があります。

この記事では、ERC-20の基本的な仕組みから、ERC-721・ERC-1155との違い、発行を検討する際に押さえておくべき論点までを順を追って解説します。

ERC-20とは何か：イーサリアム上でトークンを作るための共通規格

ERC-20とは、イーサリアム上でトークンを発行するための標準規格(インターフェース)です。

名称や残高照会、送金といった基本機能の仕様が統一されているため、どのウォレット・取引所でも同じように扱えます。

この章では、ERC-20が「共通規格」として機能する理由と、混同されやすいETH(ネイティブコイン)との違いを整理します。

ERCとは何か：EIP（技術提案）として提案・採択された経緯

ERC-20の「ERC」は、Ethereum Requests for Comment(イーサリアムへの技術提案)の略称です。

イーサリアムには、プロトコルやアプリケーション層の仕様を変更・追加する際の正式な提案プロセスとしてEIP(Ethereum Improvement Proposal)があり、ERCはそのうちアプリケーション層の標準を扱うカテゴリにあたります。

ERC-20は、2015年11月19日にFabian Vogelsteller氏がVitalik Buterin氏と共にGitHub上で提案した内容がもとになっています。

その後コミュニティでの議論を経て、正式にEIP-20として採択されました。ステータスは最終決定を意味する「Final」です。

つまりERC-20は、一部の開発者が独自に使い始めた慣習ではなく、コミュニティによるレビューを経て正式に採択された規格です。長期にわたって仕様が変わらないという前提で、事業として安心して採用できる規格だといえます。

ERC-20は「インターフェースの定義」であり中身の挙動は自由

ERC-20が定めているのは、トークンが実装すべき関数やイベントの「窓口(インターフェース)」だけです。窓口の内側、つまりトークンをどう発行し、どう流通させるかという挙動の設計は開発者の自由に委ねられています。

この「中身は自由」という性質は、ERC-20の柔軟性の源であると同時に、後述するトークノミクス設計の重要性に直結します。

規格を選ぶことと、そのトークンで何を実現したいかを設計することは、まったく別の作業です。

共通規格だからこそウォレット・取引所がそのまま対応できる

ERC-20は、名称・シンボル・総供給量・残高照会・送金・送金承認といった関数セットが統一されています。

そのため、開発者がこの仕様に沿ってスマートコントラクトを実装するだけで、既存のウォレットや取引所、DEX(分散型取引所)がそのままトークンに対応できます。

代表的な例が、USDT(テザー)やUSDCといったステーブルコインです。

いずれもERC-20規格で発行されており、主要な取引所やウォレットが個別対応を必要とせずに扱えています。これは「共通規格」がもたらす相互運用性の分かりやすい実例です。

ETH（コイン）とERC-20トークンの違い

ETHは、イーサリアムというブロックチェーンそのものが発行するネイティブコインです。プロトコルのレベルでアカウントごとの残高が管理されており、ガス代(取引手数料)の支払いにも使われます。

一方、ERC-20トークンはイーサリアムのプロトコル自体には組み込まれていません。

個々のスマートコントラクトが内部に持つ台帳(ストレージ)上で、誰がいくら保有しているかが管理される仕組みです。

この違いには、実務上見落とされやすい注意点があります。

ERC-20トークンを送金する際にも、手数料としてETHが必要です。トークンだけを大量に保有していても、ウォレットにガス代分のETHがなければ送金できません。自社トークンを発行する場合、この「ガス代は別建てで必要」という前提をユーザーに周知しておく必要があります。

ERC-20の仕組み：トークンの発行・送金・残高管理はどう行われるか

ERC-20は、残高照会や送金、第三者への送金権限の付与などに共通のインターフェースを定めています。これにより、ウォレットやDEX、DeFiなどのアプリケーションは、個々のトークンごとに異なる仕組みを用意しなくてもERC-20トークンを扱えます。

この章では、ERC-20で定められた関数とイベントの役割から、トークンの残高管理や送金、DeFi・DEXとの連携がどのように行われるのかを解説します。

必須で実装される主な関数とイベント

ERC-20では、以下の6つの基本関数が定められています。加えて、トークンの表示に使われるname・symbol・decimalsの3つが任意のメタデータ関数として定義されています。

出典：ERC-20：Token Standard

このうち、totalSupplyとbalanceOfはトークンの供給量や残高を照会するための関数です。transferは保有者自身による送金、approve・allowance・transferFromは第三者にトークンの利用権限を与える仕組みに使われます。

なお、ERC-20自体にはトークンを新規発行するmint関数は定められていません。トークンをどのような条件で発行・追加発行するかは、各コントラクトの実装によって決まります。

あわせてERC-20では、トークンが移動した際に発生する「Transfer」と、approveによって利用権限が設定された際に発生する「Approval」という2つのイベントが定められています。

ウォレットやブロックチェーンエクスプローラーなどは、こうしたイベントログからトークンの移動や権限変更を検知し、取引履歴などに反映できます。一方、あるアドレスが現在保有している残高はbalanceOfを呼び出すことで確認できます。

送金の承認を第三者に委任できるapprove/transferFromの仕組み

approveとtransferFromの組み合わせは、ERC-20の相互運用性を支える核となる仕組みです。

トークン保有者がapproveで「このコントラクトに、最大〇〇トークンまでの送金を許可する」と設定しておくと、DEXやDeFiプロトコルはtransferFromを使って、保有者の代わりにトークンを動かせます。

この仕組みがあるからこそ、利用者は取引のたびに秘密鍵で個別の送金操作をせずに、DEXでのトークン交換やDeFiでの運用預け入れを自動化できます。

ERC-20が「発行するだけの規格」ではなく「エコシステムに組み込める規格」である理由は、このapprove/transferFromの設計にあります。

ERC-721・ERC-1155との違い：何を基準に使い分けるか

3つの規格を分けるのは「トークン1つ1つを区別する必要があるかどうか」です。同じ価値のトークンを大量に流通させたいならERC-20、個体ごとに識別・所有権管理したいならNFT系（ERC-721・ERC-1155）が候補になります。

この章では、ERC-721・ERC-1155それぞれの特徴を確認したうえで、実務での使い分けの目安を整理します。 

ERC-721は「1つ1つが違う」NFTの規格

ERC-721は、トークン1つ1つに固有のIDを持たせることで、代替不可能（ノンファンジブル）なトークンを発行できる規格です。同じコレクション内でもトークンを個別に識別でき、それぞれ異なる属性や価値を持たせられます。

デジタルアート作品や会員権など、個体ごとの識別や所有権の管理が必要な用途に向いています。

関連記事：NFTの開発プロセスや技術選定については「NFTマーケットプレイス開発」で詳しく解説しています。

ERC-1155は複数種類のトークンを1つのコントラクトで扱える規格

ERC-1155は、1つのスマートコントラクトの中で、代替可能なトークンと代替不可能なトークンの両方を発行・管理できる規格です。ゲーム内アイテムのように、同じ種類のアイテムを大量発行する場面と、レアアイテムのように1点物として扱いたい場面が混在するケースに向いています。

また、複数種類のトークンを1回のトランザクションでまとめて送金できます。種類ごとにコントラクトを分ける必要がなく、バッチ処理にも対応しているため、多数のトークンを扱う場合にはガス代を抑えやすい点も特徴です。

実務での使い分けの目安

3つの規格は、トークンの代替性や管理したい資産の種類から整理すると選びやすくなります。

規格の選び方には、法規制との関係も影響します。トークン発行(ERC-20)は資金決済法上の規制対象になりやすい一方、NFTであれば該当しない場合もあります。

用途に応じた判断軸としては、以下のような整理が実務者の視点から示されています。

• 換金・売却益を狙う設計にしたい場合は、NFTを販売するという選択肢もある
• 投票権のような限定的な権利を付与したい場合は、NFTを会員権として使う手もある
• 複数種類のトークンを扱いたい場合は、ERC-1155が適している

ERC-20での発行を検討する前に：規格選定で最初に押さえるべき視点

ここまでの章で規格そのものの違いを解説してきましたが、実際にトークン発行を検討する際は、規格選定よりも先に決めるべきことがあります。それが「どのチェーンで発行するか」です。

規格より先に「どのチェーンで発行するか」がUXを左右する

企画の内容をどうするかという話より前に、どのチェーンを選ぶかが重要だという指摘があります。

ガス代が高いチェーンでトークンを発行すると、利用者が負担の重さから離れてしまうためです。

イーサリアムでは、1回の送金に30ドルほどかかっていた時期がありました。

これでは国際送金と変わらないコスト感になり、銀行の手数料より高くつく場合もあります。チェーン選定は、規格選定と同じかそれ以上に、事業としての使い勝手を左右する要素です。

チェーンによっては、そもそもERC-20という選択肢が存在しない

ERC-20は、Ethereumおよびイーサリアム互換の技術基盤(EVM)を採用したPolygon・Arbitrumなどの「EVM互換チェーン」でのみ使える規格です。

一方、Solanaのような非EVMチェーンでは、ERC-20という選択肢自体が存在しません。Solana上でトークンを発行する場合は、SPL Tokenという別の規格を使うことになります。

ERC-20ではトークンごとに個別のスマートコントラクトをデプロイしますが、SPL Tokenでは共通のプログラムのもとで「トークンミントアカウント」を作成する仕組みになっており、設計の考え方自体が異なります。

つまり、チェーンを決めないことには、規格の選択肢すら定まりません。「ERC-20で作るべきか」を検討する前に、「そもそもEVM系のチェーンで発行するのか」を決めておく必要があります。

「交換価値」を重視するか「権利証明」を重視するかで規格が変わる

チェーンを決めたうえで規格を選ぶ際は、「何を重視したいか」に立ち返ると判断しやすくなります。決済や交換価値としての利用を重視するならERC-20、発行体の証明や限定的な権利の付与を重視するならNFT系(ERC-721・ERC-1155)、という軸です。

この判断軸は、次章で扱うトークノミクス設計とも密接に関わります。

トークノミクス設計：規格を決めるだけでは終わらない理由

ERC-20は「インターフェースの定義だけ」の規格であり、中身の挙動は自由に設計できます。裏を返せば、規格を選んだだけではトークンの価値は決まりません。この章では、発行前に固めておくべきトークノミクス(経済設計)について解説します。

発行後に変更できない要素（総発行量・発行スケジュール）

トークノミクスは、設計しないと話が始まらない領域です。しかも、一度発行した後から変えるのが難しいという性質があります。

代表的なのが、総発行量や発行スケジュールです。

これらはトークンの希少性や価格形成に直結するため、発行後に変更しようとすると、保有者の信頼を損なうリスクが大きくなります。発行前の設計段階で、慎重に決めておく必要があります。

実装時に機能として組み込まないとできないこと（リベースの実例）

ERC-20はインターフェースだけを定義しているため、中の挙動は自由に設計できます。

一方で、機能としてあらかじめ組み込んでおかなければ、後から追加できない挙動もあります。

実例として、あるトークンプロジェクトでは「別のトークンを購入した資金をDeFiで運用し、その運用による総資産額の増減に応じて、保有者が持つトークンの量そのものが増減する」という機能を求められたケースがありました。

これは、係数を変えることで保有量をコントロールする「リベース」と呼ばれる仕組みです。

リベースのような機能は、最初の設計に組み込んでおかないと後付けできません。

トークンを使って何を実現したいかというエコノミクスの全体像の中に、こうした機能要件が含まれてくるため、規格を決める前にエコノミクス自体をきちんと描いておく必要があります。

「技術半分・運用半分」という実装者の視点

世間の解説では、トークンの技術面(実装の話)が語られることが多く、運用面(トークノミクス)はあまり語られません。しかし実際に重要なのは、運用の側だといえます。

トークン発行は、インターフェースの実装というシンプルな技術タスクに見えますが、そこで終わらせてはいけません。

トークノミクスは、半分が技術の話であり、半分は「どう使われるか」という運用デザインの話です。この両輪をそろえて初めて、価値のあるトークンになります。

関連記事：トークノミクスの設計手法については「トークノミクス設計」で詳しく解説しています。

発行を検討する場合に次に整理すべきこと

ここまでの章で、チェーン選定・規格選定・トークノミクス設計という3つの論点を解説してきました。実際に発行を検討する段階では、これらを個別にではなく、同時並行で詰めていく必要があります。

規格・チェーン・トークノミクスを同時に検討する

3つの論点は互いに影響し合うため、どれか1つを先に確定させてから残りを考える、という進め方には向きません。検討時のチェックリストとして整理すると、以下のようになります。

発行までの一般的な流れ（設計→実装→テストネット検証→監査→デプロイ）

チェーン・規格・トークノミクスの方針が固まったら、実際の開発は以下の流れで進むのが一般的です。

1. 設計: チェーン・規格・トークノミクスを踏まえ、スマートコントラクトの仕様を固める
2. 実装: Solidityなどの言語でスマートコントラクトを開発する
3. テストネット検証: Sepoliaなどのテスト用ネットワークにデプロイし、想定どおりに動作するか確認する
4. 監査: 自動ツールによる脆弱性チェックと、専門家による手動レビューの両方でセキュリティを確認する
5. デプロイ: 本番のネットワークにスマートコントラクトを展開する

関連記事：スマートコントラクトの脆弱性対策については「バグバウンティとスマートコントラクトセキュリティ」も参考になります。

スマートコントラクトは、一度本番ネットワークにデプロイすると、あとから直接書き換えることができません。バグや脆弱性があった場合の影響が大きいため、テストネットでの検証と監査の工程を省略しないことが重要です。

規制（法律）との関係を早い段階で確認する

トークン発行に踏み切る際は、法律関係が思いのほか厳しく問われるという声もあります。

実際、現時点(2026年9月)では、暗号資産(トークン)の発行・交換は主に資金決済法の規律を受けており、内容によっては金融商品取引法上の有価証券とみなされるケースもあります。

さらに、2026年7月に成立した金融商品取引法及び資金決済に関する法律の一部を改正する法律の改正法により、暗号資産取引に関する規制は、資金決済法から金融商品取引法へ移管されることになりました。主要な改正部分の施行日は、公布の日から1年以内の範囲で政令により定められる予定です。

今まさにトークンの発行を検討している場合は、施行前後で適用されるルールが変わる可能性があるため、最新の法令や経過措置を早い段階で確認しておく必要があります。

専門家や開発ベンダーに相談する際は、以下の情報を準備しておくと話がスムーズに進みます。

• トークンの想定用途(決済・会員権・ガバナンスなど)
• 発行量・発行スケジュールの方針
• 将来的な機能変更(リベースのような特殊な挙動)の有無

まとめ

ERC-20は、技術的にはシンプルな共通規格です。名称・残高・送金・承認といった関数セットが統一されているからこそ、ウォレットや取引所が個別対応をせずに扱えるという強みがあります。

しかし、規格を選ぶだけでは、価値のあるトークンにはなりません。ERC-20が定めているのはインターフェースだけであり、中身の挙動やトークンの経済設計は、発行する側の判断に委ねられています。

チェーン選定・規格選定・トークノミクス設計は、いずれも発行後に変更しづらい要素を含んでいます。独自トークンの発行を検討する際は、規格の技術的な理解と同じくらいの比重で、運用設計と法規制の確認を初期段階から進めることが重要です。