---
title: "Gelato Networkとは？自動実行とリレーの終了、移行先と依存の洗い出し方【2026年11月】"
url: "https://www.issoh.co.jp/tech/details/9715/"
published: 2025-11-10
updated: 2026-11-08
categories: ["ブロックチェーン"]
publisher: "株式会社一創"
---

# Gelato Networkとは？自動実行とリレーの終了、移行先と依存の洗い出し方【2026年11月】

Gelato Network（ゲラート・ネットワーク）は、EVM系チェーン向けに、スマートコントラクトの自動実行と、ガス代を利用者に払わせない送信（リレー）を提供してきたインフラ事業者です。DeFiのbotや定期処理の受け皿として使われてきましたが、その2つの事業は2026年に相次いで止まりました。自動実行のWeb3 Functionsは3月31日、リレーは9月1日に停止したと、移行支援企業や利用企業の公式文書が記しています。この記事では、停止を裏づける記録を示したうえで、旧サービスの仕組み、自分のコントラクトに残るGelato依存の調べ方、移行先の選び方を一次情報で整理します。

## まとめ：Gelato Networkの現状と今やること

- Web3 Functionsは2026年3月31日に、リレーは2026年9月1日に停止しました。Ethereum上のAutomateコントラクトの実行イベントも、2026年4月1日07:00（UTC）を最後に途絶えています。
- Gelato自身の停止告知は確認できていません。公式ドキュメントはTLS証明書が切れて開けず、GitHubの主要リポジトリも404です。根拠はSafe・GMXの公式文書とチェーン上の記録です。
- 後継SDKの`@gelatocloud/gasless`もnpmで「deprecated and no longer maintained」と表示されています。新規の組み込みには使わないでください。
- 公式サイトにはPaymaster & BundlerとRollupsの製品ページが残っていますが、稼働中かどうかは外部から確認できません。
- リレーの移行先はERC-4337のPaymasterかOSSのRelayer、自動実行の移行先はChainlink CREか、自社運用のOpenZeppelin Relayerとcronの組み合わせです。
- `AutomateReady`や`GelatoRelayContext`を継承したコントラクトは、実行者のアドレスが`immutable`で固定されています。最初にやることは依存箇所の洗い出しです。

## Gelato Networkのサービスと2026年11月時点の状態

日本語の解説の多くは、Gelatoを「スマートコントラクトを自動実行する分散型botネットワーク」と説明しています。2020年前後の説明としては正しいものの、現状とは一致しません。主要サービスの状態を2026年11月8日に確認した結果が次の表です。

| サービス                    | 役割                        | 状態                 |
| ----------------------- | ------------------------- | ------------------ |
| Legacy Automate         | 初代の自動実行                   | 停止（2024年6月）        |
| Web3 Functions          | TypeScript・Solidityの自動実行  | 停止（2026年3月31日）     |
| Relay・Turbo Relayer     | ガスレス送信                    | 停止（2026年9月1日）      |
| Paymaster & Bundler     | ERC-4337・EIP-7702のガス代肩代わり | 製品ページあり・稼働は未確認     |
| Rollups・Turbo Sequencer | 独自チェーンの構築と運用              | 製品ページあり・稼働は未確認     |
| @gelatocloud/gasless    | 現行SDK                     | npmで非推奨（0.0.12が最終） |
| GEL                     | ガバナンストークン                 | 取引は継続              |

### Web3 Functionsの停止案内とEthereum上の実行記録

Web3 Functionsの停止日を明記しているのは、移行先を提供するKeeperHubの[移行ガイド](https://docs.keeperhub.com/guides/gelato-migration)です（「Gelato Web3 Functions shuts down on March 31, 2026.」）。競合事業者の案内なので、チェーン上の記録と突き合わせました。対象は、Gelatoのドキュメントの[保存版](https://web.archive.org/web/20250621073234/https://docs.gelato.cloud/web3-services/web3-functions/supported-networks)に載っているAutomateのアドレス`0x2A6C106ae13B558BB9E2Ec64Bd2f1f7BEFF3A5E0`です。

2026年11月8日にBlockscoutのAPIで[Ethereum上の直近50件のログ](https://eth.blockscout.com/address/0x2A6C106ae13B558BB9E2Ec64Bd2f1f7BEFF3A5E0?tab=logs)を取得すると、内訳は次のとおりでした。実行イベント`ExecBypassModuleSuccess`が47件で、これは3月21日から4月1日までに集中し、**最後は4月1日07:00:35（UTC）**です。残りはタスクの取り消しが1件（3月31日）、新規作成が1件（6月3日）、所有者の変更が1件（9月8日）でした。6月3日に作られたタスクに実行イベントは続いていません。

9月8日の`OwnershipTransferred`（[該当トランザクション](https://eth.blockscout.com/tx/0xa1dfe16bcb28473867d008ff2454bf1a42d4a4c6734e5c0a81b0f729a4d3ad32)）では、所有者がゼロアドレスへ移されています。同日にOptimismでも同じ操作があり、`owner()`を呼ぶと両チェーンともゼロアドレスが返ります。どちらの記録も、案内された停止日と矛盾しません。

### リレー停止を明記しているSafeとGMXの公式情報

リレーの停止は、Gelatoを組み込んでいた側の公式文書に記載があります。[SafeのRelay Kitの解説](https://docs.safe.global/sdk/relay-kit/guides/gelato-relay)は「From September 1, 2026, transactions can’t be relayed through Gelato using the Relay Kit.」と書き、1BalanceとSyncFeeの両方式が対象だと説明しています。

分散型取引所GMXの[SDK変更履歴](https://docs.gmx.io/docs/sdk/changelog/)はさらに直接的です。2.0.0（2026年9月18日）に「Gelato shut its relay services down on September 1, 2026」とあり、Gelato関連のAPIを削除して自社のGMX Relayへ置き換えました。GMXは、2026年3月11日に発表された[Turbo Relayer](https://gelato.cloud/blog/turbo-relayer)の採用先として名前が挙がっていた企業です。発表から約半年でリレー全体が終わったことになります。

### 公式サイト・SDK・ドキュメントに残る状況

Gelato自身の告知にはたどり着けませんでした。`docs.gelato.cloud`はTLS証明書の期限切れで接続できず（10月3日の時点ではVercelの404）、`api.gelato.cloud`は接続がリセットされます。GitHubの`gelatodigital`配下では、automate、relay-sdk、gasless、web3-functions-sdkなど確認した7リポジトリがすべて404でした。

npmの表示も同じ方向を指しています。`@gelatocloud/gasless` 0.0.12と`@gelatonetwork/automate-sdk` 3.1.0は「deprecated and no longer maintained」です。旧`@gelatonetwork/relay-sdk`の非推奨メッセージは後継として`@gelatocloud/gasless`を案内しており、案内先も非推奨という行き止まりになっています。

一方、[gelato.cloud](https://gelato.cloud/)にはPaymaster & BundlerとRollupsの製品ページが残り、Rollupsは独自チェーンの構築をうたっています。ただ、Paymaster & Bundlerの`createGelatoBundlerClient`を収録するSDKは上記の非推奨パッケージです。掲載が続いていることは稼働の証拠になりません。新規の案件にGelatoの製品を組み込むのは避け、Rollupsを契約中のチームは継続可否を書面で確認してください。ロールアップの方式そのものは[ロールアップの仕組みと手数料の解説](/tech/details/8797/)で整理しています。

### GELトークンの現状

GELはGelatoのガバナンストークンです。Ethereum上のコントラクト（0x15b7c0c907e4C6b9AdaAaabC300C08991D6CEA05）の`totalSupply()`は、2026年11月8日時点で420,690,000枚を返しました。CoinGeckoのAPIの値（2026年11月6日更新）では、価格は約0.00091ドル、時価総額は約26万ドルです。ERC-20トークンはサービスが止まってもチェーン上に残るため、取引できることは事業の継続を意味しません。

## 旧Gelato Automate・Web3 Functionsの仕組み

サービスは止まっても、Gelato前提で書かれたコントラクトはチェーン上に残ります。移行では「どう呼ばれていたか」が要点です。以下は、公開されていた2026年10月3日の時点で公式リポジトリのソースから確認した内容です。

### タスクの4種類のトリガーと実行条件の判定

自動実行の単位は「タスク」で、`LibDataTypes.sol`はトリガーを`TIME`（一定間隔）、`CRON`、`EVENT`（オンチェーンのログ）、`BLOCK`（毎ブロック）の4種類と定義していました。実行するかどうかはリゾルバーと呼ばれる判定関数が決めます。Solidityでは`(bool canExec, bytes memory execPayload)`を返すview関数を用意し、監視ノードが定期的に呼び出して、`canExec`がtrueなら`execPayload`で本番の関数を実行する流れです。TypeScript版のWeb3 Functionsも`canExec`と`callData`を返す同じ形でした。

### dedicated msg.senderとリレーの固定アドレス

Gelatoはタスク作成者ごとに専用の送信元（dedicated msg.sender）を割り当て、統合用の`AutomateReady`は`address public immutable dedicatedMsgSender;`を持っていました。リレー側も同じ構造です。npmの`@gelatonetwork/relay-context` 4.1.1では、`GelatoRelayContractsUtils`がチェーンIDから決めたリレーのアドレスを`_gelatoRelay`などの`immutable`変数へ入れ、`onlyGelatoRelay`修飾子がこれと`msg.sender`を比較します。`immutable`はデプロイ時に焼き込まれるので、対象関数をこの修飾子で守っていて別の呼び出し経路やアップグレード手段がないコントラクトは、再デプロイが必要です。

### ダイヤモンドプロキシ（EIP-2535）との関係

Gelatoを「ダイヤモンドプロキシを採用した自動化基盤」と紹介する記事がありますが、利用者が触れる部分には当てはまりません。`Automate.sol`はhardhat-deployのプロキシの裏に置かれ、当時のソースにdiamondの文字列はありませんでした。Relayのコントラクトのコメントには「without passing through the diamond」という記述があり、Gelatoの内部経路にダイヤモンド構成があったとみられますが、利用者が実装する必要はありませんでした。

## 自分のコントラクトに残るGelato依存の洗い出し

最も避けたいのは、止まったことに気づかないケースです。報酬の回収や手数料の引き出しは、呼ばれなくなってもエラーを出しません。Gelatoを使っていた心当たりがあるなら、ソースとチェーンの両方を調べてください。

### ソース内の継承・修飾子・SDK依存の検索

リポジトリのルートで次を実行します。ヒットした継承元によって、必要な作業が変わります。

```
grep -rnE 'AutomateReady|AutomateTaskCreator|onlyDedicatedMsgSender|GelatoRelayContext|GelatoRelayFeeCollector|onlyGelatoRelay|@gelatonetwork|@gelatocloud' contracts src package.json
```

| ヒットした箇所                     | 固定されるもの            | 必要な対応             |
| --------------------------- | ------------------ | ----------------- |
| AutomateReady               | dedicatedMsgSender | 再デプロイかアップグレード     |
| GelatoRelayContext          | リレーのアドレス           | 再デプロイかアップグレード     |
| GelatoRelayFeeCollector     | リレー認証用アドレス         | 認可と手数料受取先の取得処理を確認 |
| @gelatonetwork・@gelatocloud | なし（オフチェーン）         | SDKの呼び出しを置換       |

別の認可経路（`onlyOwner`で呼べる関数や`AccessControl`のロール）があり、対象の処理を別経路から実行できるか、その処理の実行者を変更できる場合は、再デプロイを回避できます。修飾子が1種類だけで経路が閉じているときだけ、作り直しの工数を見積もってください。

### チェーン上の最終呼び出しと実行元の確認

Gelato経由の実行は、外部アカウントからの直接の送信ではなく内部呼び出しとして届きます。実際、Automate宛ての通常トランザクションには`createTask`や`cancelTask`しか現れません。調べるときは`internal-transactions`を見ます。

```
# AutomateReady を継承していれば固定された実行者が返る
cast call "$CONTRACT" 'dedicatedMsgSender()(address)' --rpc-url "$RPC_URL"

# 最後の内部呼び出しの時刻と呼び出し元（Ethereum の例）
curl -s "https://eth.blockscout.com/api/v2/addresses/$CONTRACT/internal-transactions" \
  | jq '.items[0] | {timestamp, type, from: .from.hash}'
```

2つ目のコマンドをAutomate自身のアドレスに対して実行すると、`timestamp`は2026年9月8日09:17:47（UTC）を返しました。上で触れた所有者変更の時刻です。自分のコントラクトで最終呼び出しが2026年3月末や8月末なら、停止時期と重なる手掛かりになります。呼び出し元、対象関数、成功状態、業務イベントを照合して、Gelato経由の最終実行を特定してください。

## Gelatoリレーからの移行先

リレーの移行先は、旧方式とウォレット構成によって選びます。Safeの解説はSafe向けの対応関係を示しており、ERC-2771については2026年3月時点のGelato公式の移行ガイドが、自前のフォワーダーを配備するよう案内していました。

| 旧方式                  | 移行先                  | 運用の負担           |
| -------------------- | -------------------- | --------------- |
| 1Balance（開発者がガス代を負担） | Verifying Paymaster  | Paymaster事業者と契約 |
| SyncFee（利用者側の資金で支払い） | ERC-20 Paymaster     | 対応トークンの確認       |
| ERC-2771（署名者の復元）     | 自前のフォワーダー            | 配備と鍵の管理         |
| バックエンドからの送信          | OpenZeppelin Relayer | Dockerで自社運用     |

Safeを使っている場合は、公式が案内する[ERC-4337のSafe SDKガイド](https://docs.safe.global/sdk/relay-kit/guides/4337-safe-sdk)（`Safe4337Pack`）に移します。対象はSafe v1.4.1以上です。ウォレット側を変えられない既存のEOA利用者に署名だけで送金してもらいたいなら、USDCなど対応トークンに限られますが[EIP-3009のtransferWithAuthorization](/tech/details/9717/)という手段もあります。取引量が大きくリレー自体が事業の中核であれば、GMXのように自社運用へ切り替える判断もあり得ます。

## Chainlink Automation・Gelato Web3 Functions終了後の移行先

2026年は、スマートコントラクトの自動実行を担ってきたホスト型サービスがそろって止まった年です。Gelato Web3 Functions（3月31日）に続き、[OpenZeppelin Defender](https://www.openzeppelin.com/news/defender-sunset-faq)が7月1日にホスト終了、[Chainlink Automation](https://docs.chain.link/chainlink-automation)もv1.xが6月30日、v2.1が7月31日に廃止されました。移行先によってコントラクトの呼ばれ方が変わるので、そこで改修の量が決まります。

| 移行先                          | 運用主体          | 呼ばれ方                 | 条件・費用               |
| ---------------------------- | ------------- | -------------------- | ------------------- |
| Chainlink CRE                | Chainlink DON | Forwarderが`onReport` | デプロイに承認が必要          |
| OpenZeppelin Relayer・Monitor | 自社（Docker）    | 自前アドレスから直接           | OSS・鍵は自社管理          |
| KeeperHub                    | ホスト型          | 専用ウォレットから直接          | 月5,000回無料・Pro月49ドル  |
| 自前のcronとbot                  | 自社            | 自前アドレスから直接           | サーバー費・ガス代・必要に応じRPC費 |

### CRE・OSS Relayer・KeeperHubの選び方

価格オラクルやData Streamsと組み合わせる清算・リバランスのように、Chainlinkの基盤にすでに依存しているbotは[Chainlink CRE](https://docs.chain.link/cre/overview)へ移します。トリガーはCron、HTTP、EVM Log、Solana Logで、Gelatoの`BLOCK`に当たるものはありません。SDKはGoとTypeScriptです。公式の概要に「Deploying workflows requires approval.」とあるとおり、本番デプロイには承認が要ります。すぐに切り替えたい案件では、この待ち時間を工程に入れてください。

[OpenZeppelin Relayer](https://docs.openzeppelin.com/relayer)（v1.9.0・2026年10月22日）とMonitor（v1.7.0）はAGPL v3のOSSで、EVMとSolanaに対応します。呼ばれ方は「特定アドレスから関数を直接呼ぶ」ままなので、許可アドレスを変更できるコントラクトなら改修はほぼ不要です。報酬の回収のような単純な定期処理は、cronからRelayerへ送信を依頼する構成で足ります。代わりに鍵の保管、監視、再送は自社の仕事になります。

運用を抱えたくなければ[KeeperHub](https://keeperhub.com/pricing)のようなホスト型が候補です。ただし2026年は大手3サービスが同じ年に止まったばかりです。ホスト型を選ぶなら、実行者を差し替えられる設計を前提にしてください。停止したGelatoの実行基盤を前提に、`AutomateReady`を継承する新規コントラクトは採用しないでください。実行者が固定されたまま、呼び出す主体だけが消えています。

### AccessControlによる実行者変更とCRE受信口の設計

次の`AutoHarvester`は、実行者から直接呼ぶ入口とCRE型（Forwarderから`onReport`）の入口を持ちます。実行者は`immutable`でなくOpenZeppelinの`AccessControl`のロールで管理します。Foundry 1.8.4（Solc 0.8.38）とOpenZeppelin Contracts 5.6.1で、実行者からの実行、間隔内の二重実行の拒否、実行者の差し替え、Forwarder経由の実行とERC-165の応答の4件のテストが通ることを確認しました。

```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
import {IERC165} from "@openzeppelin/contracts/utils/introspection/IERC165.sol";

interface IReceiver is IERC165 {
    function onReport(bytes calldata metadata, bytes calldata report) external;
}

contract AutoHarvester is AccessControl, IReceiver {
    bytes32 public constant EXECUTOR_ROLE = keccak256("EXECUTOR_ROLE");

    uint256 public immutable interval;
    uint256 public lastRun;
    address public forwarder;

    error TooEarly(uint256 nextRun);
    error InvalidSender(address sender);

    event Harvested(address indexed caller, uint256 timestamp);

    constructor(address admin, uint256 interval_) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        interval = interval_;
    }

    // Gelato の resolver と同じ形の判定関数（外部の監視側が eth_call で読む）
    function checker() external view returns (bool canExec, bytes memory execPayload) {
        canExec = block.timestamp >= lastRun + interval;
        execPayload = abi.encodeCall(this.harvest, ());
    }

    // 経路1: 実行者アドレスから直接呼ぶ（OpenZeppelin Relayer・自前のbot）
    function harvest() external onlyRole(EXECUTOR_ROLE) {
        _harvest();
    }

    // 経路2: Chainlink CRE の KeystoneForwarder から届くレポート
    function onReport(bytes calldata, bytes calldata) external {
        if (msg.sender != forwarder) revert InvalidSender(msg.sender);
        _harvest();
    }

    function setForwarder(address forwarder_) external onlyRole(DEFAULT_ADMIN_ROLE) {
        forwarder = forwarder_;
    }

    function _harvest() internal {
        // 実行間隔内の再実行だけを拒否する。レポートの新旧は判定しない
        if (block.timestamp < lastRun + interval) revert TooEarly(lastRun + interval);
        lastRun = block.timestamp;
        emit Harvested(msg.sender, block.timestamp);
    }

    function supportsInterface(bytes4 interfaceId)
        public view override(AccessControl, IERC165) returns (bool)
    {
        return interfaceId == type(IReceiver).interfaceId || super.supportsInterface(interfaceId);
    }
}
```

実行者の交代は、管理者が`revokeRole`で旧アドレスを外し、`grantRole`で新しいアドレスを加えるだけです。この例のCRE経路は呼び出し形式の説明用で、Forwarderの登録だけでは本番に使えません。本番では[公式のReceiverTemplate](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts)を継承し、ワークフローIDや所有者まで検証してください。公式の解説によれば本番の`KeystoneForwarder`が渡す`metadata`は64バイトで、長さを62に決め打ちした検証はrevertします。Solidityの環境づくりから始める場合は[Solidity入門](/tech/details/8629/)が参考になります。

## よくある質問

### Gelato Networkは何をするサービスですか？

EVM系チェーンでスマートコントラクトの自動実行とガスレス送信を提供してきたインフラ事業者です。2026年に自動実行（3月31日）とリレー（9月1日）が停止しました。公式サイトにはPaymaster & BundlerとRollupsが掲載されていますが、稼働は外部から確認できません。

### Gelatoの自動実行やリレーは今も使えますか？

使えません。Web3 Functionsは2026年3月31日に、リレーは2026年9月1日に停止しています。Ethereum上のAutomateの実行イベントも4月1日を最後に途絶え、SafeとGMXは公式文書でGelatoリレーの停止を明記しています。

### GelatoとChainlink Automationの違いは何でしたか？

どちらも条件判定と定期実行を外部ノードに任せる「キーパー」でした。Gelatoは専用アドレスから関数を直接呼び、Chainlinkは事前にLINKを入金したUpkeepで実行しました。両方とも2026年に終わったので、今比べる相手はChainlink CREとOSSのRelayerです。

### DeFiのbot（清算・リバランス）の自動化には何を使えばよいですか？

価格オラクルに依存する清算・リバランスならChainlink CREが向きます。価格に依存しない定期処理は、自前のcronやbotで条件を判定し、送信をOpenZeppelin Relayerなどに任せる構成で足ります。どちらでも実行者のアドレスは差し替えられる設計にしてください。

### GELトークンは今どうなっていますか？

Ethereum上に420,690,000枚が存在し、CoinGeckoの値（2026年11月6日更新）で価格は約0.00091ドルです。リレーと自動実行が止まった現在、GELの保有がサービス利用につながる場面は確認できていません。

## 関連記事

- [EIP-3009（ERC-3009）とは？transferWithAuthorizationの仕組みと署名実装・チェーン別対応表【2026年11月】](/tech/details/9717/)
- [ブロックチェーンのロールアップとは？レイヤー2の仕組み・種類と手数料・出金日数の比較【2026年版】](/tech/details/8797/)
- [MetaMask（メタマスク）とは？ウォレットの作り方・使い方と安全対策【2026年10月】](/tech/details/1495/)
- [Solidity入門｜開発環境の作り方・基本構文・Sepoliaデプロイ手順【2026年10月】](/tech/details/8629/)
- [Hardhatとは？Hardhat 3の使い方：導入・テスト・デプロイとFoundryとの違い【2026年10月】](/tech/details/12466/)

---

出典: [Gelato Networkとは？自動実行とリレーの終了、移行先と依存の洗い出し方【2026年11月】](<https://www.issoh.co.jp/tech/details/9715/>)（株式会社一創）