トークン規格（ERC-20・721・1155）

トークン規格とは「インタフェースの約束」である

ERC（Ethereum Request for Comments）で定められるトークン規格の正体は、新しい貨幣でも特別なオンチェーン機能でもありません。あるコントラクトが「この名前・この引数・この戻り値の関数を必ず備える」というインタフェースの取り決め、ただそれだけです。ERC-20 なら balanceOf(address)、transfer(address,uint256)、approve、transferFrom といった関数群のシグネチャが規定され、これらを実装したコントラクトは「ERC-20 トークン」を名乗れます。

なぜ約束だけで価値が生まれるのか。ウォレット・取引所・DeFi プロトコルといった呼び出す側が、同じ関数名で残高照会や送金を発行できるからです。中身の実装が違っても、外から見えるインタフェースが同一なら、1つのウォレットが数万種のトークンを同じコードパスで扱えます。これが相互運用（composability） の土台で、トークン規格の価値のほぼ全てはここに集約されます。トークン自体はスマートコントラクトであり、その挙動は EVM 上で全ノードが決定的に再現します。

ERC-20：代替可能トークンと残高モデル

ERC-20 は代替可能（fungible） トークンの規格です。代替可能とは、同種のトークンが1単位1単位で完全に等価で、区別する必要がないこと——1円玉が誰の持つ1円玉とも等価なのと同じです。したがって所有権は「誰がいくつ持つか」という数量の写像だけで表現できます。

中核の状態は次の2つです。balances は {所有者アドレス: 残高}。allowances は {所有者: {委任先: 上限額}} の二重写像で、後述の委任送金に使います。移転は所有者自身が呼ぶ transfer と、事前承認を受けた第三者が呼ぶ transferFrom の2系統があり、いずれも Transfer イベントを発行して外部（インデクサやウォレット）へ変化を知らせます。イベントはログに記録されるだけで残高そのものではない点に注意が必要です。

// ERC-20 の中核インタフェース（抜粋・擬似）
function totalSupply() external view returns (uint256);
function balanceOf(address owner) external view returns (uint256);
function transfer(address to, uint256 amount) external returns (bool);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(address from, address to, uint256 amount) external returns (bool);
event  Transfer(address indexed from, address indexed to, uint256 value);
event  Approval(address indexed owner, address indexed spender, uint256 value);

実装上の落とし穴が2つあります。第一に、ERC-20 には小数点がなく、全て整数です。decimals()（多くは18）は表示上の桁を示すだけで、内部は最小単位の整数量で保持します。第二に、transfer が失敗時に false を返す実装と revert する実装が混在し、さらに戻り値を返さない旧式トークンも存在します。戻り値を検査しない呼び出し側は「送れていないのに成功扱い」する事故を起こすため、SafeERC20 のようなラッパで戻り値の有無を吸収するのが定石です。

ERC-721：非代替トークン（NFT）

ERC-721 は非代替（non-fungible） トークン、いわゆる NFT の規格です。各トークンが tokenId（一意な整数）で識別され、1つ1つが固有で交換不能です。所有権の写像も ERC-20 とは形が違い、{tokenId: 所有者アドレス} というIDから所有者への写像が中核になります。「数量」ではなく「どのIDを誰が持つか」で所有を表す点が本質的な差です。

代替可能・非代替の違いは、所有権をどう台帳に写すかの違いに帰着します。次の表が要点です。

ここで重要なのは、画像や属性そのものはチェーン上にないのが通例という点です。tokenURI(tokenId) が返すのは外部（IPFS や HTTP）のメタデータの在り処を示す URL であり、オンチェーンに確定しているのは「そのIDの所有者は誰か」だけです。所有権の記録は分散台帳が保証しますが、URL 先の実体が差し替えられたり消えたりする可能性は規格の外にあります。「NFTを買う」とは実体データの所有ではなく、台帳上のID所有権の取得である、と正確に理解する必要があります。

ERC-1155：マルチトークン規格

ERC-1155 は、1つのコントラクトで多数のトークン種別を同時に扱うマルチトークン規格です。各 id ごとに数量を持つ {id: {所有者: 残高}} という二重写像を中核にし、id を代替可能トークンにも（同一idを大量発行）非代替トークンにも（そのidを1つだけ発行）割り当てられます。ERC-20 と ERC-721 の表現力を1規格に統合したものと捉えると分かりやすいです。

最大の利点はバッチ処理と共有デプロイです。balanceOfBatch や safeBatchTransferFrom で複数種別を1トランザクションでまとめて照会・移転でき、ガス（トークンインセンティブ設計で述べる資源計量）を大きく節約します。ゲームのように何千種のアイテムを扱う用途では、種別ごとにコントラクトを個別デプロイする ERC-721/20 に比べ、デプロイコストも運用も劇的に軽くなります。

ERC-1155 も安全受領を重視し、受取コントラクトに onERC1155Received / onERC1155BatchReceived の実装を要求します。単一と複数で別コールバックを用意するのは、バッチ移転を1つの原子的操作として扱い、途中で一部だけ成功する半端な状態を避けるためです。

approveパターンと相互運用の安全性

複数のトークン規格が共通して抱える急所が approve/transferFrom の委任モデルです。分散型取引所（DEX）のようなコントラクトにトークンを預けて動かしてもらうには、所有者が自分でいちいち送るのではなく、第三者に移転権限を前もって渡す必要があります。その2段階が approve と transferFrom です。

委任送金の2段階（ERC-20 の例）
  1. 所有者 → token.approve(DEX, 上限額)
       # allowances[所有者][DEX] = 上限額 を記録（権限だけ委任、送金はまだ）
  2. DEX   → token.transferFrom(所有者, 受取先, 数量)
       # allowances を検査・減算し balances を書き換える（実際の移転）

この設計は柔軟ですが、事故と攻撃の温床でもあります。原因はすべて「委任した権限がストレージに残り続ける」ことに由来します。

もう一つ規格横断で重要なのが ERC-165（インタフェース検出） です。相手コントラクトが supportsInterface(bytes4) に応じ、「自分は ERC-721 に対応する」と機械的に申告できます。呼び出す側は送金前に対応可否を確認でき、非対応先への送信で資産を失う事故を減らせます。インタフェースの約束を実行時に問い合わせられるようにしたのが ERC-165 で、静的な規格合意を動的な相互運用へつなぐ役割を持ちます。

まとめ

• トークン規格の本質はインタフェースの約束であり、残高・所有者は各コントラクトのストレージにある写像として保持される。共通シグネチャがウォレット・DEX による相互運用を生む。
• ERC-20 は代替可能で {所有者: 残高}、ERC-721 は非代替で {tokenId: 所有者}、ERC-1155 は {id: {所有者: 残高}} で代替も非代替も1コントラクトに統合する。差は所有権の写像方法に帰着する。
• NFT がチェーンに確定するのはID所有権のみで、画像・属性は tokenURI 先の外部データにすぎない。
• approve/transferFrom は権限委任の2段階方式。無制限承認の残存・承認レース・誤送金が事故源で、必要額承認・Permit署名・safeTransfer と受領コールバックで守る。
• ERC-165 で対応インタフェースを実行時に検出でき、静的な規格合意を動的な相互運用へつなぐ。