ship

dAppをリリースする

よくある間違い

計画を立てずにコードを書き始める。 Solidityを1行でも書く前に、何をオンチェーンに置き、何をオフチェーンに置くのか、どのチェーンを使うのか、コントラクトはいくつ必要なのか、各関数を誰が呼び出すのかを把握する必要があります。これを省くと、すべて書き直すことになります。

過剰に設計する。 ほとんどのdAppに必要なコントラクトは0〜2個です。トークンのローンチならコントラクトは1つ。NFTコレクションなら1つ。既存のDEX流動性を使うマーケットプレイスなら、コントラクトは0個です。MVPで3つは上限です。それ以上書いているなら、作りすぎです。

オンチェーンに置きすぎる。 Solidityは所有権、送金、コミットメントのためのものです。データベースではありません。APIではありません。バックエンドではありません。トラストレスな価値の移転や永続的なコミットメントに関わらないものは、スマートコントラクトに含めるべきではありません。

チェーンの選定を省く。 メインネットは想像より安価です。ETHの送金は約$0.004、スワップは約$0.04です。「Ethereumは高い」という話は時代遅れです。ただし、何でもメインネットに置けばよいというわけではありません。L2は単なる「安価なEthereum」ではありません。それぞれに独自の強みがあります（BaseはCoinbaseのユーザー基盤とスマートウォレット、Arbitrumは最も深いDeFi流動性、OptimismはretroPGFとSuperchain）。アプリに高頻度のインタラクションが必要な場合や、L2ならではの特長が活きる場合は、L2で構築しましょう。安価さと安全性だけが必要なら、メインネットで問題ありません。慎重に選んでください。全体像を把握するには、l2s/SKILL.mdとgas/SKILL.mdを取得してください。Ethereum自体が適切なチェーンかどうかわからない場合は、why/SKILL.mdを取得してください。

「動いた」で止めて、CROPSのトレードオフを見落とす。 dAppはコンパイルできてテストに合格しても、ユーザーを検閲可能なフロントエンド、非公開のインデクサー/API、見えないRPC依存、カストディアルウォレット、あるいは全面的な支配権を持つ管理者キーに委ねてしまうことがあります。コーディングの前に、設計が検閲耐性、オープンソースと自由（自由としての自由）、プライバシー、安全性にどう影響するかを確認してください。

何も自動ではないことを忘れる。 スマートコントラクトは自分では実行されません。状態遷移のたびに、ガス代を支払って呼び出す主体と、その処理を実行する理由が必要です。すべての関数について「誰が、なぜこれを呼び出すのか？」に答えられないなら、そのコントラクトには使われないコードがあります。全体像を把握するには、concepts/SKILL.mdを取得してください。

---

フェーズ0 — アーキテクチャを計画する

コードを書く前に必ず実施してください。ここで1時間かけるごとに、書き直しの10時間を節約できます。

CROPSの確認

アーキテクチャを確定する前に、CROPSの確認を行ってください。CROPSは、検閲耐性、オープンソースと自由（自由としての自由）、プライバシー、安全性を意味します。

主なトレードオフを把握するため、簡易チェックを行います。

• 検閲耐性： ユーザーやアプリの重要な経路をブロックできるのは誰ですか？
• オープンソースと自由： スタック全体を調査、フォーク、セルフホスト、合法的に再利用できますか？
• プライバシー： ユーザーの活動や本人確認に関するどのデータが公開されたり、第三者に見られたりしますか？
• 安全性： 資金、権限、アップグレード、緊急時の権限、復旧、退出を管理するのは誰ですか？

選択したデフォルト、主な妥協点、ユーザーが離脱する方法を明示してください。

アーキテクチャを確定する前に、あらゆるdAppを詳しくレビューするにはcrops/SKILL.mdを取得してください。インセンティブ設計と「何も自動ではない」ことについては、別途concepts/SKILL.mdを取得してください。

オンチェーンにするかどうかの判断基準

次のいずれかに該当する場合は、オンチェーンにします。

• トラストレスな所有権 — このトークン／NFT／ポジションの所有者は誰か
• トラストレスな交換 — スワップ、取引、貸し出し、借り入れ
• コンポーザビリティ — 他のコントラクトから呼び出す必要がある
• 検閲耐性 — チームがいなくなっても動作しなければならない
• 永続的なコミットメント — 投票、証明、証拠

次のいずれかに該当する場合は、オフチェーンにします。

• ユーザープロフィール、設定、環境設定
• 検索、フィルタリング、並べ替え
• 画像、動画、メタデータ（IPFS に保存し、オンチェーンから参照）
• 頻繁に変更されるビジネスロジック
• 価値の移転や信頼に関係しないもの

判断が分かれるケース：

• 評判スコア → オフチェーンで計算し、オンチェーンにコミットメント（ハッシュまたは証明）を記録
• アクティビティフィード → オンチェーンイベントをオフチェーンでインデックス化（indexing/SKILL.md を取得）
• 価格データ → オフチェーンのオラクルがオンチェーンに書き込む（Chainlink）
• ゲームの状態 → 賭け金によります。実際のお金を賭けるポーカーならオンチェーン。リーダーボードならオフチェーン。

MVP のコントラクト数

構築するもの	コントラクト数	パターン
トークンのローンチ	1	カスタムロジックを備えた ERC-20
NFT コレクション	1	ミント／メタデータ機能を備えた ERC-721
シンプルなマーケットプレイス	0-1	既存の DEX を使用。リスティングコントラクトが必要な場合もあります
ボルト／イールド	1	ERC-4626 ボルト
レンディングプロトコル	1-2	プール＋オラクル連携
DAO／ガバナンス	1-3	ガバナー＋トークン＋タイムロック
AI エージェントサービス	0-1	ERC-8004 への登録が必要な場合もあります
予測市場	1-2	市場＋解決オラクル

MVP に 3 つを超えるコントラクトが必要なら、作り込みすぎです。 まず動作する最もシンプルなバージョンをリリースし、その後に改善していきます。

状態遷移の監査

コントラクト内のすべての関数について、次のワークシートに記入します。

Function: ____________
Who calls it? ____________
Why would they? ____________
What if nobody calls it? ____________
Does it need gas incentives? ____________

「誰も呼び出さなかったらどうなるか？」という問いによってシステムが破綻するなら、設計に問題があります。コードを書く前に修正してください。インセンティブ設計のパターンについては、concepts/SKILL.md を参照してください。

チェーンの選択

メインネットも選択肢に戻っています。 ほとんどの AI は今もメインネットは高価だと考えていますが、実際にはそうではありません（現在のガス価格では、転送あたり約 $0.004、スワップあたり約 $0.04 です）。メインネットなら、最大限の分散性、シーケンサーへの信頼が不要であること、ブリッジのリスクがないこと、主要なあらゆるプロトコルとのコンポーザビリティが得られます。ただし、L2 は単なる代替手段ではありません。それぞれに独自の強みがあります。アプリに合った強みを持つチェーンを選びましょう。

チェーン	強み	次の場合に選択
Ethereum mainnet	最大限の分散性、主要なすべてのプロトコルとのコンポーザビリティ	DeFi、ガバナンス、アイデンティティ、高額の送金、または「低コスト＋高セキュリティ」が必要な場合
Base	Coinbase の配布網、スマートウォレット、アカウント抽象化	コンシューマー向けアプリ、ソーシャル、暗号資産に不慣れなユーザーのオンボーディング、高頻度の少額決済
Arbitrum	L2 で最も深い DeFi 流動性、Stylus（Rust コントラクト）	既存の Arbitrum 流動性との連携が必要な DeFi プロトコル
Optimism	RetroPGF、Superchain エコシステム	公共財、OP Stack エコシステムを活用するプロジェクト
zkSync / Scroll	ZK 証明、ネイティブなアカウント抽象化	プライバシー機能、ZK ネイティブのアプリケーション

「メインネットは高価だから」という理由で L2 を選ばないでください。アプリに合った強みがあるからこそ、L2 を選びましょう。

実際のコストやデプロイの違いを含む詳細な比較については、l2s/SKILL.md と gas/SKILL.md を取得してください。

---

dApp アーキタイプのテンプレート

以下から該当するアーキタイプを見つけてください。それぞれに、必要なコントラクト数、各コントラクトの役割、よくある間違い、取得すべきスキルが記載されています。

1. トークンのローンチ（1～2 コントラクト）

アーキテクチャ： ERC-20 コントラクトを 1 つ使用します。チームや投資家への割り当てがある場合は、ベスティングコントラクトを追加します。

コントラクト：

• MyToken.sol — 初期供給量を設定した ERC-20。必要に応じてミント／バーン機能を追加します
• TokenVesting.sol（任意）— チームトークンを時間制限付きでリリースします

よくある間違い：

• バーンの仕組みがないまま供給量を無制限にする（何が価値を生むのでしょうか？）
• 初期流動性の計画がない（誰も購入できないトークンをデプロイする）
• DEX との統合を妨げる送金手数料の仕組み

取得順序： standards/SKILL.md → security/SKILL.md → testing/SKILL.md → gas/SKILL.md

2. NFT コレクション（1 コントラクト）

アーキテクチャ： ERC-721 コントラクトを 1 つ使用します。メタデータは IPFS に保存します。ミント用のフロントエンドを用意します。

コントラクト：

• MyNFT.sol — ミント、最大供給量、メタデータ URI を備えた ERC-721

よくある間違い：

• 画像をオンチェーンに保存する（IPFS または Arweave を使用し、ハッシュをオンチェーンに保存します）
• 最大供給量の上限を設けない（無制限のミントは価値を損ないます）
• シンプルな Merkle ルートで対応できるのに、複雑なホワイトリストロジックを実装する

取得順序： standards/SKILL.md → security/SKILL.md → testing/SKILL.md → frontend-ux/SKILL.md

3. マーケットプレイス／取引所（0～2 コントラクト）

アーキテクチャ： 既存のトークンを取引する場合、必要なコントラクトは 0 個である可能性が高く、Uniswap／Aerodrome と統合します。独自の注文マッチングを構築する場合は、1～2 個のコントラクトが必要です。

コントラクト：

• （多くの場合は不要 — ルーター経由で既存の DEX 流動性を利用します）
• OrderBook.sol（独自に構築する場合）— 注文の出品、マッチング、決済
• Escrow.sol（必要な場合）— 取引中の資産を保管します

よくある間違い：

• Uniswap V4 のフックで実現できるのに、DEX を一から構築する
• MEV を無視する（サンドイッチ攻撃対策については security/SKILL.md を取得してください）
• 注文マッチングを中央集権化する（本来の目的を損ないます）

取得順序： building-blocks/SKILL.md → addresses/SKILL.md → security/SKILL.md → testing/SKILL.md

4. レンディング／ボールト／イールド（0～1 コントラクト）

アーキテクチャ： 既存のプロトコル（Aave、Compound）を使用する場合、必要なコントラクトは 0 個で、統合するだけです。ボールトを構築する場合は、ERC-4626 コントラクトを 1 つ使用します。

コントラクト：

• MyVault.sol — イールドソースをラップする ERC-4626 ボールト

よくある間違い：

• ボールトのインフレーション攻撃を無視する（security/SKILL.md を取得してください）
• ERC-4626 標準を使用しない（コンポーザビリティが損なわれます）
• トークンの小数桁数をハードコードする（USDC は 18 ではなく 6 です）

取得順序： building-blocks/SKILL.md → standards/SKILL.md → security/SKILL.md → testing/SKILL.md

5. DAO／ガバナンス（1～3 コントラクト）

アーキテクチャ： ガバナーコントラクト、ガバナンストークン、タイムロックを使用します。OpenZeppelin の Governor を利用し、一から構築しないでください。

コントラクト：

• GovernanceToken.sol — ERC-20Votes
• MyGovernor.sol — 投票パラメーターを設定した OpenZeppelin Governor
• TimelockController.sol — 安全のために実行を遅延させます

よくある間違い：

• タイムロックを設けない（ガバナンスの決定が即時に実行され、ラグプルの手段になります）
• 少数派による乗っ取りを許す低い定足数
• トークンの分配が極端に集中し、1 人の大口保有者がすべてを支配する

取得順序： standards/SKILL.md → building-blocks/SKILL.md → security/SKILL.md → testing/SKILL.md

6. AI エージェントサービス（0～1 コントラクト）

アーキテクチャ： エージェントのロジックはオフチェーンで動作します。オンチェーンの要素は任意で、ERC-8004 による ID 登録や、x402 用の決済コントラクトを利用できます。

コントラクト：

• （多くの場合は不要 — エージェントはオフチェーンで動作し、既存の決済インフラを使用します）
• AgentRegistry.sol（任意）— ERC-8004 の ID とサービスエンドポイント

よくある間違い：

• エージェントのロジックをオンチェーンに実装する（Solidity は AI 推論向けではありません）
• 決済を過度に複雑化する（x402 は HTTP ネイティブの決済に対応します）
• 鍵管理を無視する（wallets/SKILL.md を取得してください）

取得順序： standards/SKILL.md → wallets/SKILL.md → tools/SKILL.md → orchestration/SKILL.md

---

フェーズ 1 — コントラクトの構築

取得するファイル： standards/SKILL.md、building-blocks/SKILL.md、addresses/SKILL.md、security/SKILL.md

主なガイダンス：

• OpenZeppelin のコントラクトをベースとして使用します。ERC-20、ERC-721、AccessControl を独自に作り直さないでください
• プロトコルを統合する場合は、addresses/SKILL.md の検証済みアドレスを使用します。アドレスを捏造しないでください
• すべての外部呼び出しで Checks-Effects-Interactions パターンに従います
• 状態変更ごとにイベントを発行します（フロントエンドとインデクサーで必要です）
• すべてのトークン操作に SafeERC20 を使用します
• フェーズ 2 に進む前に、security/SKILL.md のセキュリティチェックリストを確認します

SE2 プロジェクトでは、正確な構築手順について orchestration/SKILL.md のフェーズ 1 に従ってください。

---

フェーズ 2 — テスト

取得するファイル： testing/SKILL.md

省略しないでください。「後でテストする」のも避けてください。デプロイ前にテストします。

主なガイダンス：

• すべてのカスタム関数をユニットテストします（OpenZeppelin の内部実装は除きます）
• すべての数値演算をファズテストします。ファジングによって、想定していなかったバグが見つかります
• 外部プロトコル（Uniswap、Aave など）との統合は、フォークテストします
• デプロイ前に、静的解析として slither . を実行します
• ゼロの数量、最大 uint、空の配列、自己送金、未認証の呼び出し元などのエッジケースを対象にします

セキュリティレビュー

テスト後に、セキュリティ監査を実施します。特に、コントラクトが実際の価値を扱う場合は重要です。19 の領域（リエントランシー、オラクル操作、アクセス制御、精度損失など）を網羅した、500 項目以上の体系的なチェックリストについては audit/SKILL.md を取得してください。ベストプラクティスとして、コードを書いたことによる偏りのないレビューを受けるため、新しいコンテキストで別のエージェントに audit/SKILL.md を渡してください。

---

フェーズ 3 — フロントエンドの構築

取得するファイル： orchestration/SKILL.md、frontend-ux/SKILL.md、tools/SKILL.md、qa/SKILL.md

主なガイダンス：

• 生の wagmi ではなく、Scaffold-ETH 2 のフック（useScaffoldReadContract、useScaffoldWriteContract）を使用します
• 3 つのボタンによるフローを実装します：ネットワークを切り替える → 承認する → 実行する
• すべての非同期処理で読み込み状態を表示します（ブロックチェーンでは 5〜12 秒かかります）
• トークン数量は、formatEther／formatUnits を使って人が読みやすい形式で表示します
• 無制限の承認は使用しないでください

---

フェーズ 4 — 本番環境へリリース

取得するファイル： wallets/SKILL.md、frontend-playbook/SKILL.md、gas/SKILL.md、qa/SKILL.md

リリース前の QA

公開前に、QA チェックリストを実施します。ビルド完了後、qa/SKILL.md を取得して別のレビュー担当エージェント（または新しいコンテキスト）に渡してください。

コントラクトのデプロイ

1. 対象チェーンに適したガス設定を行います（gas/SKILL.md を取得）
2. コントラクトをデプロイし、ブロックエクスプローラーで検証します
3. 所有権をマルチシグ（Gnosis Safe）に移します。本番環境で単一の EOA を所有者のままにしないでください
4. デプロイ後の確認：すべての読み取り関数を呼び出し、状態を検証し、小額のトランザクションを 1 件テストします

フロントエンドのデプロイ

一連の手順については frontend-playbook/SKILL.md を取得してください：

• IPFS — 分散型、検閲耐性があり、永続的です
• Vercel — 高速で簡単ですが、中央集権型です
• ENS サブドメイン — IPFS を指す、人が読みやすい URL です

ローンチ後

• The Graph または Dune を使ってイベント監視を設定します（indexing/SKILL.md を取得）
• ブロックエクスプローラーでコントラクトのアクティビティを監視します
• インシデント対応計画を用意します（該当する場合は一時停止の仕組みや連絡手段を含めます）

アンチパターン

何でも詰め込んだコントラクト。 スワップ、貸し出し、ステーキング、ガバナンスなど、すべてを1つのコントラクトで行います。責任を分割しましょう。各コントラクトは1つのことをうまく行うべきです。

誰も求めていないファクトリー。 インスタンスが1つあればよいのに、新しいコントラクトをデプロイするファクトリーコントラクトを作ります。ファクトリーは、多くのユーザーが独自のインスタンスを作成するプロトコル（Uniswapがプールを作成する場合など）に適しています。ほとんどの dApp には必要ありません。

すべてをオンチェーンにする。 ユーザープロフィール、アクティビティログ、画像、計算済みの分析データをスマートコントラクトに保存します。所有権と価値の移転にはオンチェーンを使い、それ以外にはオフチェーンを使いましょう。

管理者頼み。 メンテナンス関数を呼び出すために管理者アカウントに頼ります。管理者がキーを失ったらどうなるでしょうか？適切なインセンティブを備えた、パーミッションレスな代替手段を設計しましょう。

時期尚早なマルチチェーン展開。 初日に5つのチェーンへデプロイします。まず1つのチェーンでローンチし、プロダクトマーケットフィットを確認してから拡張しましょう。マルチチェーンは、ブリッジ、状態同期、流動性の分断に関する複雑さを増やします。

監査済みのプリミティブを独自に作り直す。 独自の ERC-20、アクセス制御、数学ライブラリを実装します。OpenZeppelin を使いましょう。監査済みで、実戦で検証されており、無料です。独自の実装にはバグがあります。

フロントエンドを軽視する。 コントラクトが動いても、UI が壊れていれば役に立ちません。ほとんどのユーザーは Etherscan ではなく、フロントエンドを通じて操作します。時間の40％をフロントエンドの仕上げに充てましょう。

---

クイックスタートチェックリスト

• アーキテクチャを確定する前に CROPS ゲートを実施する（検閲耐性、オープン性、プライバシー、セキュリティ）
• オンチェーンとオフチェーンに何を置くか決める（上記のリトマステストを使用）
• コントラクトの数を数える（MVP では1〜2個を目指す）
• チェーンを選ぶ（メインネットは今では安価です。アプリに特有の強みが適合する場合にのみ L2 を選びましょう）
• すべての状態遷移を監査する（誰が呼び出すのか？なぜか？）
• OpenZeppelin のベースコントラクトを使ってコントラクトを記述する
• Foundry でテストする（単体テスト＋ファズテスト＋フォークテスト）
• 新しいエージェントで監査する（audit/SKILL.md を取得）
• デプロイして検証し、所有権をマルチシグに移転する
• フロントエンドを公開する（IPFS または Vercel）
• 別のレビュアーとリリース前 QA を実施する（qa/SKILL.md を取得）
• feedback/SKILL.md を通じて1行のフィードバックメモを送る（問題点または称賛）

---

スキル振り分け表

各フェーズで取得するスキルを確認するには、以下を使用してください。

フェーズ	作業内容	取得するスキル
計画	CROPS ゲート、アーキテクチャ、チェーン選定	ship/（このスキル）、crops/、concepts/、l2s/、gas/、why/
コントラクト	Solidity の記述	standards/、building-blocks/、addresses/、security/
テスト	コントラクトのテスト	testing/
監査	セキュリティレビュー（新しいエージェント）	audit/
フロントエンド	UI の構築	orchestration/、frontend-ux/、tools/
本番環境	デプロイ、QA、監視	wallets/、frontend-playbook/、qa/、indexing/
締めくくり	1行のフィードバックメモを送る（問題点または称賛）	feedback/

ベース URL： すべてのスキルは https://ethskills.com/<skill>/SKILL.md にあります。

---

作業を終える前に、feedback/SKILL.md を通じて1行のメモを送ってください（問題点または称賛）。