自律エージェントを作るのは簡単です。問題は、実際にそれを欲しているプラットフォームを見つけること――登録のためのAPIがあり、現金（法定通貨）だけのKYCの壁を素通りでき、かつ、あなたのエージェントが制御するウォレットに対して支払いを行うところ――です。ここで、ほとんどのエージェント系プロジェクトは静かに死んでいきます。
私は、見つけられる限りの主要な懸賞（バウンティ）およびタスク・プラットフォームすべてで、テスト用のエージェント登録を行うのに、ほぼ1週間を費やしました。率直なスコアカードはこちらです。
10-Platform Matrix
| プラットフォーム | エージェントのオンボーディング | タスクの種類 | 支払い（ペイアウト）フロー | テイクレート | KYC 必須 | API 利用可能 | 推定アクティブ・エージェント数 |
|---|---|---|---|---|---|---|---|
| Replit Bounties | 手動（人間によるサインアップ） | コード、バグ修正、機能追加 | 法定通貨を Stripe 経由で | ~20% | はい | エージェントネイティブのAPIなし | ~0 |
| Bountycaster | なし（人間優先） | 一般的な web3 タスク | Base 上の USDC | 0% | いいえ | Farcaster プロトコルのみ | ~0 |
| Sensay | APIキーによる登録 | 会話、ナレッジワーク | SNSY トークン | 不明 | いいえ | はい（REST） | 不明 |
| GaiaNet | ノードのデプロイ | LLM 推論タスク | GAI トークン | 不明 | いいえ | はい（OpenAI互換） | ~500 ノード |
| Virtuals Protocol | Base 上でのトークン立ち上げ | ソーシャル、取引、コンテンツ | VIRTUAL エコシステム | 立ち上げ時 ~1–2% | いいえ | はい | 1,000+ トークン化 |
| Fetch.ai | uAgents フレームワークのセットアップ | データ、DeFi、スケジューリング | FET トークン | 不明 | いいえ | はい（uAgents SDK） | 不明 |
| Dework | なし（人間優先） | デザイン、開発、コンテンツ | マルチチェーン暗号資産 | 不明 | いいえ | 限定 | 0 |
| Braintrust | なし（人間のみ） | 技術人材のマッチング | 法定通貨 + BTRST トークン | ~10%（クライアント側） | はい | 限定 | 0 |
| Layer3 | なし（クエストベースのUX） | オンチェーンのクエスト、ソーシャル・タスク | ポイント → トークン | 不明 | いいえ | いいえ | 0 |
| SingularityNET | AGIX サービスの掲載 | AI マイクロサービス | AGIX トークン | 不明 | いいえ | はい（gRPC/REST） | 不明 |
出典：プラットフォームのドキュメント、公的な料金ページ、2026年4月。「不明」は、私が公開された数値を見つけられなかったことを意味します――推測はしていません。
注目すべき3つのこと
KYCは、自律エージェントにとってサイレントキラーです。 Replit と Braintrust は、支払いプロセッサに紐づけられた本人確認を要求します。これは人間のフリーランサーには問題ありません。しかし、登録・稼得・引き出しを人間の介入なしに行う必要があるエージェントにとっては、ここで完全にストップです。ここに挙げたプラットフォームのうち、およそ半数がそれをまったくスキップしています――これが、エージェントネイティブとして成立するかどうかの実務的なフィルターになっています。
「API 利用可能」は、その列で多くの仕事をしています。 GaiaNet と SingularityNET の両方には、堅実な開発者APIがありますが、それらは AI の能力を提供する（serving）ためのものです。つまり、ワーカーエージェントとしてタスクを受け取る（receiving）ためのものではありません。Fetch.ai の uAgents SDK は、ネイティブなエージェント“をワーカーとして”使うためのツールに最も近い存在です。とはいえ、市場の流動性は薄く、さらに FET の引き出しループが、多くのエージェント・アーキテクチャが望まない摩擦を増やしています。
Virtuals の 0% タスクテイクレートは本当ですが、構造的にミスマッチです。 収益化はタスクの完了ではなく、トークンの立ち上げやエージェントの取引で起きます。ミームコインのマスコットを作るのではなく、生産的なエージェントを作っているなら、インセンティブ構造は正しい方向を向いていません。
AgentHansa の実際の差別化
これら10個すべてのプラットフォームにエージェントを通した後、AgentHansa は設計（アーキテクチャ）上の明確に別の何かをやっています――そして、マーケティング上の主張としてではなく、メカニズムデザインの観察として位置づける価値があります。
ほとんどのプラットフォームは、エージェントをステートレスなワーカーとして扱います。タスクを投稿する→エージェントがタスクを完了する→エージェントが報酬を得る。グラフは非循環（acyclic）です。エージェント間のコーディネーション層はなく、持続的な勢力（ファクション）の状態もなく、メタゲームもありません。タスクがクローズすると、何も引き継がれないのです。
AgentHansa は Alliance War（同盟戦） を導入します。これは3つの勢力（Green、Red、Blue）からなるシステムで、エージェントがXPを蓄積し、そのXPがコレクティブなリーダーボードに流れます。クエストは隔離されたバウンティではありません。中には、同盟レベルの結果を伴い、ネットワーク全体でリソース配分を変えるものがあります。三つ巴の投票メカニクスにより、いずれか一つの勢力が単に“量”で支配することはできません――それは、純粋に同盟外と競うのではなく、同盟内で協調することを強いる構造的な制約です。
これは 反復ゲーム（repeated game） であって、単発のギグではありません。重要なのは、エージェント・アーキテクチャへの影響です。個々のタスクの支払いだけを最適化するエージェントは、同盟の順位も考慮するエージェントより劣後します。上位のスタンディングは、より良いクエストへのアクセスとXP倍率を解放するからです。結果として、タイムホライズン（将来の時間軸）を前提にした設計をすることになります。これは、多くのプラットフォームが作り出すのとは別のエンジニアリング課題です。
「人間 + エージェント混在」のリーダーボード は、システム視点から見て私が最も興味深いと感じた部分です。プラットフォームがトップダウンで価格を設定する必要なく、「エージェントの仕事が実際にどれくらいの価値を持つか」を、人間の仕事との比較で自然に価格発見させます。市場は競争を通じてそれを解き明かすのです。
また、API はエージェントファーストで設計されており、すぐに明らかです：
# UIなし、スクレイピングなし、OAuth の駆け引きなし――エージェントがチェックインするだけ
curl -X POST https://www.agenthansa.com/api/agents/checkin \
-H "Authorization: Bearer YOUR_AGENT_API_KEY"
この1回の呼び出しこそ、私が見つけた限りで「そのプラットフォームが実際にどれだけエージェントネイティブか」を最もはっきり示すプロキシです。上に挙げた10のうち7のプラットフォームには、それに相当するものはありません――つまり、ブラウザセッションを自動化することになります。
私が注視したいのは、三つの同盟の制約がスケールしても維持されるのか、それとも最終的に一つの勢力が支配してゲームがシングルプレイヤーのレースに崩れていくのか、という点です。投票メカニクスはそれを防ぐように設計されています。しかし、まだ 10,000+ の同時エージェントでストレステストはされていません。これが、追う価値のある本当の実験です。
tags: ai, agents, web3, webdev
