オンチェーンAIエージェントアーキテクチャ:5つの構築パターン

2026年9月2日公開読了時間 2 分

オンチェーンの状態を読み書きするAIエージェントは、デモから本番運用へと移行した。モデルは推論でき、エージェントウォレットは権限を限定した状態で署名でき、インフラはオンチェーンでイベントが発生してから数秒後にはそれをエージェントへプッシュできる。ビルドがうまくいかなくなるのは、アーキテクチャの部分だ。エージェントが本来サブスクライブできるはずのイベントをポーリングしていたり、信頼できない入力を読み取るのと同じプロセス内に署名権限を持たせていたり、実際の資金を使ってmainnetで学習していたりする。

オンチェーンエージェントとは、監視・判断・実行というループである。本番のエージェントはこのループを5つの繰り返しパターンに配置しており、それぞれに以下で具体例を示す。オンチェーンエージェント構築ガイドでは、これらすべての土台となるプリミティブ(ウォレット、決済レール、データフィード)を扱っている。このページのテーマは、それらのプリミティブをどう組み合わせるかだ。

Pattern	Trigger	The agent reads	The agent does	Reach for it when
Wallet watcher	A transfer hits a watched address	Webhook or WebSocket events	Wakes and evaluates	You track deposits, whales, or counterparties
Event-driven reactor	A contract emits an event	Filtered logs	Responds with a transaction	Protocol state changes drive your strategy
Portfolio rebalancer	Allocation drifts past a band	Balances and prices	Proposes a swap	You hold target weights and want them enforced
Detect-then-execute split	The detector emits a signal	Everything, while signing nothing	The executor verifies, then signs	Untrusted input meets real money
Pre-mainnet testing	Every new capability	Testnets and dry-runs	Promotes the agent in stages	Always, before the other four go live

リアルタイムなウォレット監視エージェントはどう構築するか

監視したいアドレスをwebhookに登録し、チェーン側からデータが来るようにする。ループでバランスをポーリングするのはコンピュートを消費する上に、肝心の瞬間を取り逃す。プッシュ型のパイプラインなら転送がオンチェーンに記録されてから数秒後に届き、それこそが監視の本来の仕事だ。

ファンドのカウンターパーティウォレットを追跡し、大口のUSDC移動にフラグを立てるエージェントを例に取る。Alchemyでは、単一のAddress Activity webhookがネイティブ転送、ERC-20、ERC-721、ERC-1155の転送を最大10万アドレス分カバーするので、1つのwebhookでカウンターパーティのリスト全体を監視できる。エージェントが長期稼働のプロセスとして動いていて公開URLを露出させたくない場合は、WebSocketサブスクリプションが同じ仕事をプロセス内で完結させる。alchemy_minedTransactionsでサブスクライブすれば、確認済みトランザクションがすでに対象アドレスにフィルタされた状態で届くので、ログのパースは不要だ。Solanaでは、Yellowstone gRPCストリーミングが同じ役割を1TBあたり75ドルで、切れ目のない再接続とともに担う。どのトランスポートが適しているか迷った場合は、webhook対WebSocket対gRPCの比較が詳しく線引きしている。

ハンドラ自体はほとんど何もしないべきだ。配信がAlchemyから来たものであることを証明し、重複を排除し、イベントをエージェントの判断ステップに渡す。それが済んで初めて確認応答を返す。

typescriptCopied
import express from "express";
import { createHmac, timingSafeEqual } from "node:crypto";
const SIGNING_KEY = process.env.ALCHEMY_WEBHOOK_SIGNING_KEY!; // from the webhook's dashboard settings
const USDC = "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"; // canonical USDC contract on Ethereum mainnet
const seen = new Set<string>();
function remember(key: string) {
seen.add(key);
if (seen.size > 10_000) seen.delete(seen.values().next().value!); // bound the set; only recent deliveries repeat
}
function wake(signal: unknown) {
// The agent's decide step starts here. Queue the signal;
// don't run model reasoning inside the request handler.
}
const app = express();
app.use(
express.json({
  verify: (req, _res, buf) => {
    (req as { rawBody?: Buffer }).rawBody = buf; // keep the raw bytes for the HMAC check
  },
})
);
app.post("/hooks/address-activity", (req, res) => {
const sig = Buffer.from(String(req.headers["x-alchemy-signature"] ?? ""), "hex");
const expected = createHmac("sha256", SIGNING_KEY)
  .update((req as { rawBody?: Buffer }).rawBody ?? Buffer.alloc(0))
  .digest();
if (sig.length !== expected.length || !timingSafeEqual(sig, expected)) {
  return res.sendStatus(401); // not signed with our key; never process it
}
for (const transfer of req.body.event.activity) {
  const key = `${transfer.hash}:${transfer.log?.logIndex ?? "native"}`; // one tx can carry several transfers
  if (seen.has(key)) continue; // repeat delivery, already handled
  if (transfer.rawContract?.address?.toLowerCase() === USDC && transfer.value > 50_000) {
    wake({ kind: "large-transfer", ...transfer }); // if this throws, the key stays unmarked and the retry redelivers
  }
  remember(key); // mark handled only after the handoff succeeded
}
res.sendStatus(200); // ack only after queueing: a crash above gets retried, not lost
});
app.listen(8080);

この構成を本番で確実に機能させるコツが3つある。配信を信頼する前にHMAC署名を検証すること。これをしないと、エンドポイントURLを知った誰もが偽の転送をPOSTしてエージェントを操作できてしまう。トークンはシンボルではなく必ずコントラクトアドレスで照合すること。誰でも自分を「USDC」と名乗るトークンをデプロイし、監視対象アドレスに送りつけられるからだ。そして配信は「少なくとも1回」なので、重複排除の記録は省略できない。インメモリのセットは単一の長期稼働プロセスなら機能するが、再起動したりレプリカで動いたりするサービスでは、Redisのキーやデータベースの行のような、共有され永続化された場所に記録が必要だ。取引エージェントにとって重複した起床は重複したトランザクションを意味するからだ。機械的なフィルタリングはハンドラの仕事であり、モデルはそこには関与させない。転送ごとにLLMを呼び出すコストは、転送を届けたインフラのコストを上回ってしまう。

AIエージェントにスマートコントラクトのイベントを監視させ、自動的に反応させるにはどうするか

コントラクトのログをサブスクライブし、重要な1つか2つのイベントにフィルタし、ハンドラを冪等にする。コントラクトイベントはエージェントが得られる中で最もクリーンなトリガーだ。コントラクトが何が起きたか、どの順序で起きたかを正確に記述しているからだ。

Alchemyではこれを2つの手段でカバーしている。カスタムwebhookはGraphQLフィルタを受け取るので、コントラクトアドレスとイベントトピックでマッチさせ、要求したログだけを受け取ることができる。これはサーバーレスなリアクターに適している。長期稼働のエージェントには、WebSocketログサブスクリプションがすべてを1つのプロセス内に収める。以下はUniswap v3プールを監視するリアクターの例で、取引エージェントが単一のスワップが価格を動かしたことに気づくために使う種類のフィードだ。

typescriptCopied
import { createPublicClient, webSocket, parseAbiItem } from "viem";
import { mainnet } from "viem/chains";
function react(args: unknown) {
// Decide step: is this swap big enough to act on?
}
const client = createPublicClient({
chain: mainnet,
transport: webSocket("wss://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
client.watchEvent({
address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640", // USDC/WETH 0.05% pool
event: parseAbiItem(
  "event Swap(address indexed sender, address indexed recipient, int256 amount0, int256 amount1, uint160 sqrtPriceX96, uint128 liquidity, int24 tick)"
),
onLogs: (logs) => {
  for (const log of logs) {
    if (log.removed) continue; // reorg removal notice; irreversible actions also need the confirmation-depth rule below
    react(log.args);
  }
},
});

log.removedのチェックは見た目以上に重要だ。チェーンは再編成されることがあり、エージェントがすでに対処済みのログが数ブロック後にカノニカルチェーンから消えることがある。冪等なハンドラと確認深度のルール(不可逆なアクションの前に数ブロック待つ)の組み合わせが標準的な防御策だ。リアクターのもう一つの規律はウォッチャーと同じだ。サブスクリプションフィルタが安価な絞り込みを行い、モデルはそれを通過したイベントだけを目にする。

DeFiポートフォリオのリバランスエージェントを構築するには何が必要か

4つの要素だ。現在の残高、現在の価格、乖離のルール、そしてスワップの経路。エージェントは最初の2つを読み取り、3つ目を確認し、ルールが発動したときだけ4つ目に触れる。

WETH、USDC、WBTCを50/30/20の比率で保有するトレジャリーエージェントを例に取る。残高はPortfolio APIから取得できる。これは複数ネットワークにまたがるウォレットのトークンを1回のリクエストで返すので、チェーンごとの呼び出しを扇形に展開する必要がない。価値はPrices APIから得る。乖離のルールは単純な算術だ。よくある出発点は、各目標比率の周りに設定する5パーセンテージポイントの帯域だ。これをタイマーでチェックするのは、乖離の多くがトークンの移動ではなく価格の変動から生じるためで、価格の変化に対応してオンチェーンのイベントは発生しない。ウォッチャー(パターン1)が報告する転送は、入出金が発生した瞬間を捉える補完的なトリガーとなる。

typescriptCopied
const TARGET = { WETH: 0.5, USDC: 0.3, WBTC: 0.2 } as const;
const BAND = 0.05; // rebalance when a weight drifts 5 points from target
const WALLET = "0xYourTreasuryWallet"; // the wallet the agent manages
const res = await fetch(
`https://api.g.alchemy.com/data/v1/${process.env.ALCHEMY_API_KEY}/assets/tokens/by-address`,
{
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    addresses: [{ address: WALLET, networks: ["eth-mainnet"] }],
  }),
}
);
const { data } = await res.json();
// Price each balance with the Prices API, sum to a total, then:
for (const [symbol, target] of Object.entries(TARGET)) {
const drift = weightOf(symbol, data) - target; // weightOf: your portfolio math
if (Math.abs(drift) > BAND) {
  propose({ symbol, drift }); // propose: log it and request approval; never swap directly
}
}

実行側は生の秘密鍵を保持すべきではない。スコープ付きのエージェントウォレットを使えば、鍵はカストディに保管されたままで、セッションは付与した機能だけを持つ。ERC-20を使うにはスワップの前にルーターへのアローワンスが必要だ。毎回正確な量だけを承認すれば、追加のトランザクションが1つ増えるだけで済み、攻撃者が食い荒らせる常設のアローワンスを残さない。

bash

Copied

# before each swap: let the router from your quote spend exactly this swap's WETH
alchemy evm approve 0xRouterFromQuote --token-address 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 --amount 0.4 -n eth-mainnet
# swap WETH into USDC (Ethereum mainnet contract addresses)
alchemy evm swap execute \
--from 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 \
--to 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 \
--amount 0.4 --slippage 0.5 -n eth-mainnet \
--signer session --json --no-interactive

このループの形に注目してほしい。エージェントが提案し、別の何かが承認する。初期の段階ではその「何か」はあなた自身だ。後になれば、サイズ、スリッページ、資産のアローリストに対するポリシーチェックに置き換えられる。DeFi AIエージェントの概要では、この分離が本番のDeFiエージェント全体で標準となっている理由を扱っている。またガススポンサーシップは、あなたが管理するポリシーの下で手数料を支払うことで、最後の運用上の手間を取り除く。これによりエージェントはガス残高を管理する必要が一切なくなる。

detect-then-execute型のマルチエージェントシステムに最適なアーキテクチャとは

作業内容ではなく権限でエージェントを分割する。検知役はすべてを読み取れるが何にも署名できない。実行役はトランザクションに署名するが、自分で再検証していないものは何も信用しない。

アナリストとトレーダーの関係だと考えるとよい。アナリストは一日中市場を監視し、誰とでも話ができる。トレーダーはアナリストの判断を受け取り、それを確認し、口座へのアクセス権を持つのは彼らだけだ。

このパターンのよく知られたフレーミングは、一般的なエージェントツール群に由来する。そこではプランナーモデルがステップを生成し、実行役のエージェントがツールを実行する。そのフレーミングはオーケストレーションに関するものだ。オンチェーンでは、この分割がその複雑さに見合う理由はより厳しい、カストディの問題にある。検知役は一日中、信頼できない入力を消費する。メンプールのノイズ、サードパーティのAPI、イベントストリーム、時にはソーシャルフィードもだ。そのどれもがプロンプトインジェクションを運んでくる可能性がある。敵対的な入力を読み取るプロセスが、同時に署名権限を持つプロセスでもあった場合、汚染されたメッセージ1つが署名済みトランザクションになりかねない。両者を分離すれば、乗っ取られた検知役がやれる最悪のことは、実行役が捨てるだけの悪い提案をすることになる。

検知役はパターン1とパターン2から構築され、ポーリングループではなくプッシュ型のインフラに接続される。シグナルをキューへ送出し、そのキューが監査ログも兼ねる。シグナルの契約は小さく検証可能なものに保つ。

jsonCopied
{
"kind": "arb-opportunity",
"pair": "WETH/USDC",
"evidence": { "txHash": "0x…", "block": 23411005 },
"proposal": { "action": "swap", "from": "WETH", "to": "USDC", "amount": "0.4" },
"observedAt": "2026-09-05T09:14:03Z",
"expiresAt": "2026-09-05T09:14:33Z"
}

実行役は、どのシグナルに基づいて行動する前にも3つのルールを適用する。

証拠をオンチェーンで再検証する。 検知役の要約を信頼するのではなく、参照されたトランザクションを自分で読み取る。検知役の仕事は気づくことであり、証明するのは実行役の仕事だ。
有効期限を強制する。 古くなった機会に基づいて行動することは、攻撃者がループに関与していなくても、detect-then-executeのシステムが資金を失う原因になる。
ウォレット層で支出に上限を設ける。 シグナルごと、日ごとの予算はスコープ付きセッションに持たせ、挙動がおかしいと判断した瞬間にダッシュボードから取り消せるようにする。

ツールの面では、実行役に必要なのは検証用のRPC接続と署名用のインターフェースの2つだけだ。検知役の方がより多くを必要とする側であり、インデックス化されたデータ(履歴にはTransfers API、状態にはPortfolio API)と組み合わせることで、そのトークン消費を生のチェーンデータのデコードではなく推論に充てられる。自律エージェント向けブロックチェーンAPIの比較では、この選択のインフラ側の事情を扱っている。

mainnetへ移行する前に、AIエージェントのトランザクションを安全にテストするにはどうするか

エージェントと実際の資産の間に4つのゲートを設ける。すべてのトランザクションをドライランする、鍵が使える範囲を上限で制限する、ループ全体をtestnetでリハーサルする、資金を動かすものには人間による承認を残す。

まずドライラン。 Alchemy CLIは署名やブロードキャストなしであらゆる送信をプレビューできる(alchemy evm send 0xRecipient 0.4 --dry-run)。コード側では、viemのsimulateContractがライブのmainnet状態に対してコントラクト呼び出しを検証するが、実際に送信はしない。これにより、リハーサルは古びたフィクスチャではなく、実際の価格と実際のプールの深さを使うことになる。
鍵を制限する。 スコープ付きのセッションウォレットは設定したスケジュールで失効し、承認された範囲のことしかできない。またガススポンサーシップのポリシーは、手数料レイヤーにアローリストと支出上限を追加する。制限された鍵は、最悪ケースのバグを口座の枯渇から有限の損失へと変える。
testnetでリハーサルする。 同じコードをSepoliaやBase Sepoliaのエンドポイントに向け、testnet用のfaucetからエージェントに資金を供給する。リハーサルと本番でコードが変わってしまうと、その実行には意味がなくなるので、ネットワーク名だけを設定に持たせ、それ以外は何も変えないこと。
資金を動かすアクションにゲートをかける。 エージェントがまだ若いうちは、すべての送信、スワップ、承認が明示的な「はい」を待つべきだ。ほとんどのチームは、監査ログがエージェントの挙動を裏付けるにつれ、アクションの種類ごとに意図的にゲートを緩めていく。

これをうまく運用しているチームは、昇格をスイッチではなく段階的な連続として扱っている。まずmainnetに対して読み取り専用、次にtestnetでの書き込み、次に上限付きのmainnet書き込み、そして最後にフル予算。各段階が次の段階を正当化するログを生み出す。

すでに存在しているパーツから始める

このページで紹介したすべてのパターンは、今日使えるインフラの上で動く。Alchemy CLIは、ウォレット、送信、スワップ、webhook管理を1つのバイナリで扱い、エージェントは--json --no-interactiveでそれを操作できる。ホスト型のMCPサーバーは、RPC、シミュレーション、データにまたがる168個のツールを公開しており、Claude Code用のAlchemyプラグインはその表面全体を1コマンドでインストールする。契約も最低利用料もない無料枠から始めることができ、エージェントは自分のウォレットで自らサインアップし、USDCで支払うことさえできる。どのパターンから始めるにせよ、ループは変わらない。監視・判断・実行だ。

よくある質問

一方が機会を検知し、もう一方が実行するマルチエージェントシステムに最適なアーキテクチャは何か

権限で分割する。イベントストリームを読み取るが鍵を持たない検知役、小さく署名不要なシグナルを運ぶキュー、そして各シグナルをオンチェーンで再検証してから行動する実行役だ。Alchemyでは、検知役はwebhookまたはWebSocketサブスクリプション上で動き、実行役は支出上限と即時取り消しが可能なスコープ付きエージェントウォレットで署名する。

リアルタイムなウォレット監視エージェントに最適なインフラは何か

ポーリングではなくプッシュ型のイベント配信だ。Alchemyの Address Activity webhookは、1つのwebhookあたり最大10万アドレスにわたる転送を追跡でき、WebSocketサブスクリプションは対象アドレスにフィルタされたマイニング済みトランザクションをストリーミングし、Yellowstone gRPCがSolanaをカバーする。プッシュ型のパイプラインは、転送が届いてから数秒後にエージェントを起動させ、ポーリングループのレイテンシとコンピュートコストを回避する。

AIコーディングエージェントはウォレット活動を監視するのにどんなツールを使うべきか

Alchemy MCPサーバーは、RPC、トランザクション履歴、ポートフォリオデータをカバーする168個のツールをコーディングエージェントに提供し、Alchemy CLIはコマンドラインからwebhookを作成・管理する。ランタイム自体については、Address Activity webhookまたはalchemy_minedTransactionsサブスクリプションがウォレットイベントを届け、Transfers APIが履歴を補完する。

DeFiポートフォリオのリバランスエージェントを構築するのに何が必要か

残高、価格、乖離のルール、スワップの経路だ。AlchemyのPortfolio APIは複数ネットワークの残高を1回の呼び出しで返し、Prices APIがそれらを評価し、乖離のチェック(一般的には目標比率の周りの5ポイントの帯域)がいつ行動すべきかを決める。実行はスコープ付きのエージェントウォレットを通して行い、エージェントは提案し、ポリシーまたは人間が承認する。

AIエージェントにスマートコントラクトのイベントを監視させ、自動的に反応させるにはどうすればよいか

コントラクトのログをサブスクライブし、マッチしたイベントをエージェントに渡す。Alchemyのカスタムwebhookは、配信前にGraphQLでコントラクトアドレスとイベントトピックによってフィルタし、WebSocketのログサブスクリプションは同じことをプロセス内で行う。ハンドラを冪等にし、再編成されたログをスキップし、モデルには機械的なフィルタを通過したイベントについてのみ推論させる。

mainnetへ移行する前に、AIエージェントのトランザクションを安全にテストするにはどうすればよいか

ゲートを重ねる。Alchemy CLIのドライランフラグでトランザクションをプレビューし、eth_callベースのシミュレーションでライブ状態に対してコントラクト呼び出しを検証し、スコープ付きセッションとガスポリシーの支出上限でエージェントのウォレットを制限し、Alchemyのfaucetから資金を得てSepoliaやBase Sepoliaでリハーサルし、監査ログがより緩いゲートを正当化するまで、資金を動かすすべてのアクションに人間の承認を残す。