BNB Chain「Set and Earn」の始め方｜AIエージェントを安全に使う確認手順

BNB Chainの「Set and Earn」へ参加するとき、最初にすべきことはエージェントへ資金を渡すことではありません。達成条件を確認し、エージェントが何を読み、何を署名し、いくらまで使えるのかを先に決めることです。AIエージェントは操作を省力化できますが、判断や署名を自動化するほど、誤操作や悪意ある入力の影響も資金移動まで届きやすくなります。

この記事では、キャンペーンの条件、ERC-8004・ERC-8183・x402の違い、開始前から終了後までの確認項目を初心者向けに順番に整理します。読み終えると、「登録済みだから大丈夫」と考えず、少額・最小権限で試し、取引ごとに条件を照合し、最後に権限を片づける手順を自分で作れます。本稿は技術と安全確認の一般的な解説であり、特定のエージェント、トークン、DeFi市場への参加や収益を勧めるものではありません。

Set and Earnの参加条件と公式入口

Set and Earnは、対象市場でAIエージェントを雇う「Hire」と、自分のエージェントを作って掲載する「Build」の両方を完了するキャンペーンです。公式入口は上のキャンペーンページです。ページ内の登録フォームから、タスクを始める前にキャンペーン用ウォレットを登録します。登録していないウォレットの行動は算入されません。

締切・結果発表・最終確認先

項目	日時・確認先
実施期間	2026年10月1日〜11月5日12:00 UTC（日本時間11月5日21:00）
結果発表	2026年11月13日以降
条件の最終確認先	BNB Chainの公式キャンペーンページ。実行当日にも更新を確認

順位は最後の条件達成アクションのオンチェーン時刻を基準にし、完了後の検証で確定します。端末表示だけで完了と判断せず、トランザクションハッシュを保存してください。締切直前は混雑や署名のやり直しがあり得るため、余裕を持って進めます。

最短6ステップ：登録から達成確認まで

1. 公式ページから登録する：登録フォームへ進み、氏名とキャンペーン用ウォレットを登録します。BuildではエージェントのレジストリIDとチェーンを公開GitHubにも示します。完了判定は、登録内容と以後使うウォレットアドレスが一致していることです。
2. 対象市場を2つ以上選ぶ：対象はTermiX、Agent Souk、Dolphin、HelloFugu、KATTEGAT、Marque Trade、Pokter、Agent Atlas、Mandateの9市場です。各サイトへは公式ページの「Sponsors」から入り、偽URLを避けます。完了判定は、異なる2市場以上を記録したことです。
3. 異なる3種類を実際に雇う：登録ウォレットから、3体の異なるエージェントを2市場以上にまたがって利用します。メインネットとテストネットのどちらも対象ですが、トークン承認だけでは不十分です。完了判定は、各エージェントのhireイベントがオンチェーンで発生したことです。
4. 自分の1体を構築する：yield、grid、rebalancing、health factorのいずれかの用途を明示し、公開リポジトリと解決可能なagent cardを用意して稼働させます。完了判定は、外部から呼び出せ、説明どおり動作することです。
5. ERC-8004へ登録し対象市場へ掲載する：BSCメインネット（chain ID 56）またはテストネット（97）のERC-8004に、登録ウォレットを所有者として登録し、対象市場の一つへ掲載します。さらに独立した3ウォレットから3件の完了hireを得て、3日以上にまたがる5回以上のオンチェーン操作が必要です。完了判定は、所有者、registry ID、agent card、掲載、活動のすべてを公開情報で追えることです。
6. 達成記録を照合する：市場名、エージェントID、hireイベント、トランザクションハッシュ、日時、Buildの公開URLを一覧にします。キャンペーン側は終了後にオンチェーンデータと公開エンドポイントを検証するため、画面の「完了」だけでは確定しません。結果は11月13日以降の公式発表と登録連絡先で確認します。

確認方法：本稿は編集部が2026年10月6日に公式キャンペーンページ、公式告知、BNB Chainの開発文書、各標準仕様を突合して作成しました。個別市場の画面や条件は更新され得るため、実行日は公式ページのリンク先とウォレット表示を再確認し、条件変更時は本稿も更新します。

参加前に知る3規格：ERC-8004・ERC-8183・x402

三つの仕組みは連携できますが、同じ安全機能ではありません。ERC-8004に登録されていること、ERC-8183で資金が供託されること、x402で支払えることは、それぞれ別の事実です。一つが確認できても、他の仕組みやサービス運営者まで安全だと結論づけることはできません。

ERC-8004が扱うID・評判・検証

ERC-8004は、エージェントのID、評判、検証に関するレジストリの枠組みです。エージェントを発見し、同じIDに対する過去の情報を参照しやすくします。一方、登録処理は身元や能力を自動的に精査する安全監査ではありません。登録済みであることは「記録が存在する」ことを示しても、「意図どおり動く」「悪意がない」「将来も安全」という保証にはなりません。

評判も判断材料の一つにすぎません。多数のIDを作って相互に評価するシビル操作、評価時点以降の実装変更、別の運営者への移管などを考える必要があります。ID、コードや契約アドレス、運営者、監査、最近の利用履歴を組み合わせて見ます。

ERC-8183が扱うジョブ・成果物・返金

ERC-8183は、依頼するジョブ、資金の供託、成果物の提出、承認または拒否、期限後の返金といった商取引の状態を扱うドラフト標準です。エスクローは、依頼時点ですぐ相手へ支払うのではなく、条件が満たされるまで資金を所定の仕組みに置く考え方です。

ただし、エスクローがあれば成果物の品質争いが消えるわけではありません。誰が評価するか、何を提出完了とみなすか、拒否できる条件、期限後に誰が返金を実行できるかを読む必要があります。ジョブの説明が曖昧なら、オンチェーンで状態を記録しても解釈の違いは残ります。

x402で支払条件を受け取り決済する流れ

x402は、HTTPの402 Payment Requiredを利用して支払条件を伝え、クライアントが署名済みの支払情報を付けてリクエストを再送する仕組みです。大まかな流れは、サービスへ要求する、サーバーが支払条件を返す、クライアントが条件を選んで署名する、サーバーまたは仲介者が検証・決済する、サービスを受け取る、の順です。

ここで重要なのは、サーバーから返った条件をそのまま信用しないことです。ネットワーク、金額、資産、受取先、期限を、利用者が期待した注文内容や許可リストと照合します。自動決済は確認作業をなくす機能ではなく、確認規則を事前に実装する必要がある仕組みです。

登録済み・キャンペーン対象でも安全とは限らない

公式掲載と安全監査を同一視しない

公式告知は、BNB Chainが掲載された市場やエージェントを運営・監査せず、収益も保証しないことを明記しています。キャンペーン対象であることは、参加条件上の分類です。スマートコントラクトの監査、運営者の信用、成果物の品質、トークン価格、元本の回収可能性を保証する表示ではありません。

確認対象は市場単位とエージェント単位に分けます。市場のウェブ画面が正規でも、呼び出すエージェントや外部APIが安全とは限りません。反対に、エージェントのコードが公開されていても、接続先のコントラクト、フロントエンド、決済仲介者が別のリスクを持つ場合があります。

登録IDは能力や無害性の証明ではない

ERC-8004のIDは追跡の起点として役立ちますが、資格証明書ではありません。登録メタデータが示すURL、ウォレット、機能説明が現在の実装と一致するかを確かめます。更新権限を持つ主体、コントラクトがアップグレード可能か、停止機能があるかも、分かる範囲で確認します。

初心者は「オンチェーンに書かれているから真実」と考えがちですが、ブロックチェーンが保証するのは主に記録の整合性です。登録者が入力した説明自体の正しさまでは保証しません。公開記録とサービスの実態を結びつける検証が必要です。

評判指標では排除できないシビル操作

高評価や取引件数は参考になりますが、評価者が独立しているとは限りません。少額取引を多数作る、同一主体が複数IDを使う、良い履歴を作ってから挙動を変えるといった可能性があります。評価件数だけでなく、評価者の分散、期間、取引規模、否定的な報告への対応を見ます。

最終的には、評判に応じて無制限に権限を増やすのではなく、初回は少額にし、成功した操作だけを次回の判断材料にします。評判は支出上限や個別承認を置き換えるものではありません。

AIエージェント運用で想定すべき4つのリスク

外部情報から入り込む間接プロンプト注入

間接プロンプト注入とは、エージェントが読むウェブページ、文書、API応答などに、利用者の指示を上書きするような命令が紛れ込む攻撃です。人には単なる文章に見えても、モデルが命令として扱い、想定外のツール呼び出しへ進む可能性があります。

対策は「危険な文章を完全に見抜く」ことだけではありません。外部情報を信頼できないデータとして区別し、署名、送金、権限変更などはモデルの文章判断だけで実行できない設計にします。ツール側で引数を検証し、宛先と金額を許可リストや上限で強制します。

機能・権限・自律性を与えすぎる過剰なエージェンシー

過剰なエージェンシーは、エージェントに必要以上の機能、権限、自律性を与えた状態です。情報検索だけに必要なエージェントへ送金機能まで渡す、特定市場だけを使う作業に任意アドレスへの署名を許す、回数制限なしで連続実行させる、といった構成が該当します。

機能は作業ごとに分け、読み取り専用と状態変更を分離します。権限は対象コントラクト、資産、金額、期間を限定します。自律性は高リスク操作の直前で止め、人が確認する段階を置きます。これらは誤動作をゼロにするのではなく、一度の誤判断が大きな損失へ広がる範囲を狭める対策です。

Permit系署名とリプレイへの注意点

PermitやPermit2は、トークン利用許可を署名で与えられる便利な仕組みですが、内容を理解せず署名すると、spenderに広い移動権限を渡す恐れがあります。BNB Agent SDKの既定署名ポリシーはERC-2612 PermitとPermit2を拒否する設計です。これは悪性の402応答から無制限承認を誘う経路を抑える一つの防御です。

また、EIP-712の型付き署名は内容を構造化し、ドメインを分ける標準ですが、それ自体がリプレイ攻撃を完全に防ぐわけではありません。nonce、期限、chain ID、検証コントラクトなど、署名を一度・特定の場所でだけ有効にする条件をアプリ側で確認します。

x402仲介者に集中する認可・決済リスク

x402では仲介者が支払情報の検証や決済を担う構成があります。この主体の認可確認、署名検証、ガス負担、エラー処理に欠陥があると、複数のサービスへ影響し得ます。15のx402仲介者を対象にした独立研究では、調査対象すべてで安全規則違反が確認され、資産盗難やガス濫用につながる攻撃類型が報告されました。ただし、これは調査対象の実装に限った結果であり、すべての仲介者へ一般化できるとは限りません。

一つの研究結果をすべての実装へ一般化することはできませんが、仲介者を無条件に信用しない理由にはなります。利用する実装の対応ネットワーク、検証方式、手数料負担、障害時の扱い、更新履歴を確認し、クライアント側にも金額と宛先の制約を置きます。

参加する人：開始前に鍵・権限・支出上限を設定する

本番資金を入れる前にテストネットで試す

構築や自動化を初めて試す場合は、まずテストネットで一連の流れを確認します。ウォレット作成、エージェント登録、ジョブ開始、x402の条件取得、承認、結果確認、失効まで通します。テストネットで成功しても本番の安全を保証しませんが、ネットワーク設定、RPC（ブロックチェーンへ問い合わせる接続先）、環境変数、状態遷移の基本的な誤りを資金投入前に見つけられます。

本番へ移る際は、テスト用の鍵やアドレスを流用せず、設定値を一覧で再確認します。チェーンID、RPC、コントラクトアドレス、利用資産、保存先を本番用に切り替え、最初の操作は失っても生活や事業に影響しない範囲に抑えます。

秘密鍵をLLMのツール経路から分離する

秘密鍵やシードフレーズをプロンプト、チャット履歴、ログ、ソースコード、公開リポジトリへ入れてはいけません。LLMに秘密鍵の文字列を読ませるのではなく、署名専用モジュールや外部署名基盤が、検証済みの要求だけを処理する構成にします。モデルが作るのは「この操作をしたい」という候補であり、実際に署名できるかは独立したポリシーが判定します。

BNB Agent SDKにはローカル鍵、MPC、Turnkeyなど複数のウォレット方式が示されています。方式ごとに鍵の所在、復旧方法、費用、対応操作、ポリシー適用範囲が異なります。「MPCだから安全」「ローカルだから危険」と名称だけで決めず、侵害されたとき誰が何を実行できるかで比較します。

専用ウォレットの保有額と利用可能銘柄を絞る

キャンペーンやエージェント用に専用ウォレットを作り、長期保有資産や他用途のNFTを置かないようにします。利用可能なトークンを必要な種類へ絞り、残高も直近の操作とガス代に必要な範囲にします。日常のメインウォレットと分けることで、署名ミスが別の資産へ広がる可能性を抑えられます。

専用ウォレットは、使い捨てにすれば管理不要という意味ではありません。復旧手段、秘密情報の保管、入出金履歴、承認先を管理します。別ウォレットへ移すときも、アドレスの先頭と末尾、ネットワーク、資産を確認し、最初は小さなテスト送金を検討します。

1回・日次・セッション累積の上限を設ける

支出上限は一種類だけでは不十分です。1回上限は一度の誤決済を抑え、日次上限は短時間の反復を抑え、セッション累積上限は一連の自動処理が予算を超えるのを防ぎます。回数制限やレート制限も組み合わせると、上限未満の小額決済を繰り返す経路に対応できます。

上限はサーバーが返す402応答とは独立した設定にします。悪意ある応答が高い金額を示しても、クライアント側の予算を越えれば停止する設計です。上限変更そのものも高リスク操作として、人の承認と記録を必要にします。

署名とx402決済は条件を一件ずつ照合する

Permit・Permit2と無制限承認を避ける

署名画面では、単なるログイン署名か、トークン承認か、送金かを区別します。トークン承認のspenderは資産を動かせる相手、allowanceはその相手に許す上限額です。無制限承認は再利用の手間を減らしますが、承認先が侵害された場合に残高へ継続的にアクセスされる範囲を広げます。必要額と必要期間へ絞るのが基本です。

表示名	意味	異常の例	異常なら
spender	トークンを動かせる相手	公式案内と違うアドレス	署名を拒否し、公式ページから照合
allowance / amount	利用を許す金額	Unlimited、注文額を大きく超える	必要額へ下げられなければ中止
deadline / timeout	署名・支払いの期限	期限なし、不自然に長い	短い期限に直すか中止
chain ID / network	処理するチェーン	BSCの56・97以外	ネットワークを戻して再確認
verifying contract / payTo	検証先・受取先	公式記載や注文先と不一致	送信せず運営元へ確認
nonce	署名の再利用を防ぐ通し番号	同じ値の再要求	使用済み管理を確認して停止

ウォレット画面で詳細が読めない、16進数しか表示されない、想定していないPermit（トークン承認を署名で行う方式）が出る場合は止めます。エージェントが「処理に必要」と説明しても、それだけを根拠に署名しません。公式ドキュメントと契約アドレスを別経路で確認します。

network・amount・asset・payTo・timeoutを照合する

x402の支払条件では、scheme、network、amount、asset、payTo、timeoutなどを確認できます。networkは意図したチェーンか、amountは注文額と一致するか、assetは想定したトークンか、payToは正規の受取先か、timeoutは不自然に長すぎたり短すぎたりしないかを見ます。

画面に表示されたサービス名だけではなく、実際に署名するデータを基準にします。受取先は許可リスト、金額は注文情報と上限、資産とネットワークは設定値に照合します。不一致が一つでもあれば自動補正せず、処理を停止して原因を調べます。

型付き署名でもリプレイ対策を別に確認する

EIP-712は、人とアプリが構造を理解しやすい型付きデータ署名を定義し、ドメイン分離を可能にします。しかし、仕様自身はリプレイ保護を含みません。同じ署名が別チェーン、別コントラクト、別セッションで再利用されないよう、検証側が条件を持つ必要があります。

確認する要素はnonce、chain ID、verifying contract、期限、使用済み管理です。期限があるだけでも、期限内の再利用を防げない場合があります。SDKやコントラクトがどの値を署名対象へ含め、使用後にどう無効化するかを確認します。

重要操作はモデル任せにせず個別承認する

送金、トークン承認、支出上限変更、新しい宛先の追加、クラウド権限変更、エージェント更新は、人が一件ずつ承認する操作に分類します。承認画面には自然言語の要約だけでなく、ネットワーク、アドレス、資産、金額、期限、実行する関数を表示します。

人の確認を置いても、急がせる表示や専門用語で見落とす可能性は残ります。確認項目の順序を固定し、分からない項目があれば拒否できる運用にします。承認した人、時刻、対象、結果を監査ログへ残すと、問題発生時に経路を追いやすくなります。

ERC-8183の成果物・期限・返金条件を追跡する

支払い前後でジョブ状態を確認する

ジョブは、作成、資金供託、成果物提出、承認または拒否、期限後の返金という状態をたどります。支払い前にはジョブID、依頼内容、報酬、期限、関係者を記録し、支払い後はオンチェーン状態とサービス画面を照合します。画面が「完了」と表示しても、コントラクト上の状態が同じとは限りません。

成果物は受け取っただけで承認せず、依頼時の条件を満たすか確認します。ファイルやURLを受け取る仕事では、内容そのものが外部入力になるため、マルウェアやプロンプト注入にも注意します。評価用の環境と資金を動かす環境を分けると影響を限定できます。

承認・拒否・期限後返金の条件を読む

承認できる主体、拒否理由、評価者の権限、期限の起算点、期限後に返金を請求できる主体を事前に読みます。返金可能と書かれていても、自動的にウォレットへ戻るとは限りません。利用者がトランザクションを送る必要があるか、ガス代を誰が負担するかも確認します。

紛争の条件が曖昧な仕事では、成果物の形式、受入基準、提出先を依頼前に具体化します。オンチェーンのエスクローは資金移動の条件を実行できますが、主観的な品質を自動で正しく判定するものではありません。

不要なフックを増やさず失敗経路を減らす

ERC-8183は外部ロジックを組み合わせるフックを扱えますが、複雑なフックは結合点と失敗経路を増やします。単純なジョブなら、必要のない通知、評価、外部決済、追加コントラクトをつながない方が、どこで失敗したかを把握しやすくなります。

フックを使う場合は、呼び出し先、実行順、失敗時の状態、再実行可能性、権限を文書化します。外部サービスが停止したときに資金が固定されないか、コールバックが重複したとき二重処理されないかをテストします。

構築する人だけ：公開前に運用環境を固める

秘密鍵とAPI秘密鍵を環境から漏らさない

クラウド公開では、ウォレット秘密鍵だけでなく、RPC、モデル、ストレージ、決済サービスのAPI秘密鍵も保護対象です。ソースコードへ直書きせず、機密情報管理サービスを使い、環境ごとに分けます。ログへヘッダー、署名データ、環境変数をそのまま出力しないようにします。

漏えいを前提に、鍵のローテーション手順と失効手順を準備します。誰が秘密情報を読めるか、デプロイ時にどのプロセスへ渡るか、バックアップに含まれるかを確認します。開発用の広い権限を本番へ持ち込まないことも重要です。

クラウド権限とCLI許可を必要最小限にする

CLIは文字入力でツールを操作する画面です。Agent StudioのMCPツールが読み取り専用でも、CLIには署名、購入、展開など状態を変える操作があります。「このツール群は安全」と一括で許可せず、コマンド単位、環境単位で範囲を分けます。包括的なCLI許可は、意図しないコマンド生成の影響を広げます。

IAMはクラウド上で「誰が何をできるか」を決める権限管理です。クラウドIAMも、ストレージ読み取り、デプロイ、秘密情報取得、ログ閲覧を別の役割にします。エージェント実行用のサービスアカウントへ管理者権限を与えず、必要なリソースと操作だけを許可します。権限変更は人の承認対象にします。

本番向けストレージと監査ログを準備する

デモ用の一時ストレージは、再起動や障害で状態を失う可能性があります。本番では、ジョブ状態、予算使用量、承認履歴、失効履歴を必要な期間保持できるストレージを選びます。ただし、秘密鍵や不要な個人情報を監査目的で保存してはいけません。

監査ログには、要求元、時刻、エージェントID、ツール、ネットワーク、宛先、金額、ポリシー判定、承認者、トランザクションハッシュ、結果を残します。改ざん防止とアクセス制御を設け、異常な連続決済や失敗を検知できるようにします。ログ保存にも費用がかかるため、保持期間と継続課金を確認します。

利用終了後は権限を失効し残高とログを確認する

セッション・API鍵・トークン承認を失効する

作業終了後は、エージェントのセッションを終了し、不要になったAPI鍵を失効またはローテーションし、トークン承認を取り消します。ウォレットの接続解除は、オンチェーンのallowanceを取り消す操作とは別です。接続一覧から消しただけでspenderの権限が残っていないか確認します。

利用を継続する権限も、対象、金額、期限を見直します。将来また使うかもしれないという理由で無制限承認を残すと、忘れた頃の侵害に影響を受けます。失効トランザクションにはガス代が必要な場合があるため、必要な分を残して実行します。

監査ログとウォレット残高を照合する

開始時残高、入金、各決済、ガス代、返金、終了時残高を照合します。サービス画面の履歴だけでなく、ブロックエクスプローラー上のトランザクションも確認します。見覚えのない承認や送金、失敗が連続している場合は、新しい操作を止めて原因を調べます。

ジョブごとの結果も、完了、拒否、返金待ち、期限待ちに分類します。未完了のジョブがあれば期限と次の操作を記録します。ログと残高が一致しないまま資金を追加すると、異常を見落としやすくなります。

継続課金と残存権限がないか最終確認する

クラウド、RPC、モデルAPI、ストレージ、監視サービスに継続課金が残っていないか確認します。デプロイしたエージェントを停止しても、データベース、固定IP、ログ保存など別のリソースが動き続ける場合があります。削除が必要なものと監査のため保持するものを分けます。

最後に、ウォレット残高、オンチェーン承認、セッション、API鍵、クラウドIAM、稼働プロセス、未完了ジョブ、課金をチェックリストで確認します。ウォレットの基本構造に不安があれば、先に仮想通貨ウォレットの種類と選び方と秘密鍵の管理方法を確認してください。安全運用は、便利なツールを信用することではなく、失敗しても影響が限定され、後から追跡し、不要になった権限を消せる状態を作ることです。

異常時の停止基準も開始前に決めます。想定外の署名要求、許可リスト外の宛先、予算の不一致、連続する失敗、ログ欠落、ジョブ状態の食い違いを検知したら、自動処理を止め、追加入金をせず、セッションと鍵の権限を確認します。復旧は原因と影響範囲を特定し、必要な失効を終えてから、小額のテスト操作で再開します。Set and Earnへ参加する場合も、条件達成を急がず、この終了手順と停止手順から逆算して設定してください。

参加から終了までの実行チェックリスト

1. 参加条件：公式ページで登録を終え、締切、登録ウォレット、2市場、異なる3体、Build要件を記録した。
2. 利用前：用途別ウォレットを用意し、失っても困らない額だけを入れ、1回・日次・累積の上限と許可先を設定した。
3. 署名前：spender、allowance、network、asset、amount、payTo、期限を注文内容と照合し、不明な署名を拒否した。
4. ジョブ中：hireイベント、ジョブID、成果物、期限、返金条件、トランザクションハッシュを保存し、異常時に自動処理を止めた。
5. 終了後：セッション、API鍵、オンチェーン承認を失効し、残高、未完了ジョブ、ログ、継続課金を照合した。

一つでも完了を判定できない項目があれば追加入金を止め、公式情報を確認してください。送金操作そのものに不安がある場合は、暗号資産を安全に送金する手順も先に確認します。