Hyperliquid AI取引エージェントを本番で動かすには｜LLMに発注させない構成

目次（タップで折りたたみ）

あるチームが、LLMを使った自動売買エージェントをHyperliquidで試作しました。LLMが相場の要約を読み、注文APIを直接呼び出す作りです。検証環境では、これでちゃんと動きました。

ところが、本番に出す前に考えると不安が残ります。LLMの出力は確率的で、やり直せば同じ入力から別の判断が出ます。一方、取引の発注は、一度でも余分に通れば資金が動きます。そのため、LLMが注文APIを直接呼ぶ作りでは、次の3つを保証できません。

同じ判断を二度実行しない
上限を超えない
送信の結果が分からないときに、正しくふるまう

そこで本番では、LLMが作るのは注文の案までにします。案は、決まったルールで機械的に検証してから執行します。署名、上限の管理、再送の判断、約定の突き合わせ、停止は、それぞれ別の担当にします。モデルの出力だけでは資金が動かない構成です。

以下では、このチームのエンジニアとプロダクト責任者が本番の構成を決める順に、公式Docsで確かめられる仕様をもとに見ていきます。前半は構成の考え方、後半の「実装する人向けの詳細」はコードや数字です。Hyperliquid自体の仕組みの基礎はHyperliquidとは？オンチェーンPerps DEXの仕組みと事業者向け論点で扱っています。

この記事で使う言葉

建玉：いま持っている先物のポジション
API Wallet：発注などの操作を代わりに署名する専用の鍵。資金は持たない
cloid：自分で付ける注文ID（client order id）。応答が途切れたときの照会に使う
nonce：署名の使い回しを防ぐための番号
マーク価格：取引所が証拠金や清算の計算に使う価格
reduceOnly：建玉を減らす方向にしか働かない注文の指定

LLMに注文を出させず、4つの層に分ける

判断を作ることと、発注を実行することを、別の層に置きます。誰が何をするかを先に決めておくと、あとの実装の判断がぶれません。

層	担当すること	担当してはいけないこと
LLM（意図の生成）	売買の方針と、その根拠	発注、上限、再送の判断
ポリシーゲート（決定的コード）	上限の検査と却下	市況の解釈、戦略の変更
実行層（決定的コード）	署名・送信・照合	戦略判断、上限の緩和
取引所（HyperCore）	正となる状態の保持	—（こちらの状態を推測しない）

決定的コードとは、同じ入力にはいつも同じ結果を返すプログラムです。HyperCoreは、Hyperliquidの板と清算を担う中核の部分です。各層の中身をもう少し詳しく書くと、次のとおりです。

LLM：市況の要約からの売買方針、対象銘柄、希望のサイズと価格帯、根拠の言語化を担う。発注APIの呼び出し、上限の判断、注文識別子の採番、再送するかの決定はしない。
ポリシーゲート：サイズ・建玉・損失・銘柄・レバレッジの上限の検査、却下と丸め、監査ログを担う。
実行層：注文識別子の採番、署名、送信、タイムアウトの処理、再送、取消、約定の照合を担う。
取引所：板・約定・証拠金・清算を確定させ、正となる状態を持つ。

こう分けておくと、事故のときに調べる範囲がはっきりします。想定外の建玉が出たとき、原因はLLMの判断か、ポリシーゲートのしきい値の設定か、実行層の再送かを切り分けられます。価格データや口座の状態の食い違い、取引所側の挙動も調べます。LLMが発注まで担う作りでは、この切り分けができません。

LLMの出力は決まった形式で受け取り、上限はコードで検査する

LLMから意図を受け取る形式は、自由な文章にせず、スキーマで固定します。Claude APIには、出力をJSON Schemaの形にしばる構造化出力があります（Anthropic「Structured outputs」）。

ただし、スキーマに合っていることが保証するのは「形式が正しい」ことだけです。値が妥当かは、コードの側で判定します。ポリシーゲートは、LLMの応答を受け取り、発注できる注文か却下かを返す関数として書けます。スキーマとゲートの例は後半に載せました。

プロンプトに「1回の注文は1万ドル以内」と書いても、それは強制できる制約ではありません。ですから上限値は、LLMのプロンプトではなくコードとして持ち、ゲートで機械的に検査します。

LLMから判断が得られないこともあります。スキーマに合わない応答、API呼び出しの失敗、安全上の理由による応答の拒否（stop_reason が refusal）です。これらはすべて「判断が得られなかった」として、何もしない（hold）のと同じに扱います。既存の建玉を勝手に動かさないのが、安全な既定の動きです。

API Walletは「発注できて出金できない」鍵にする

HyperliquidのAPI Walletは、発注などの操作を代わりに署名する鍵です。Docsではagent walletとも書かれます。署名専用で資金を持たず、親アカウント（master account）とそのサブアカウントの代わりに署名します（Hyperliquid Docs「Nonces and API wallets」）。

権限の区別は、署名の種類で決まっています。発注やレバレッジの変更は、API Walletが署名できます。一方、USDCの送金、L1への出金、別のAPI Walletの承認は、利用者本人の署名が要る操作で、API Walletでは署名できません。

ここから言えることは2つです。

鍵が漏れても、被害は「取引はされうるが、資金は引き出されない」に限られる。ただし、被害がゼロという意味ではありません。悪意のある発注で不利な建玉を作られれば、値動きを通じて損失は出ます。
鍵の入れ替え（ローテーション）には、親アカウントの署名が要る。API Walletは別のAPI Walletを承認できないからです。無人で運用している間に鍵を差し替える手順を、親アカウントの鍵を扱える担当者も含めて、前もって決めておきます。

もう1つ、鍵の使い方の決まりがあります。nonceは署名者ごとに管理されます。そのため、1つのAPI Walletを複数のプロセスで共有すると、互いの番号がぶつかり、署名がはじかれます。1つのAPI Walletは、複数のプロセスで共有しません。増やしたいときは、鍵を増やして、担当の銘柄や口座で分けます。nonceの細かな規則は後半に載せました。

鍵の保管、権限の分け方、失効の手順はHyperliquidのAPI Walletと署名処理と、より一般的な署名鍵の運用としてHSM・MPCを使った署名鍵の本番運用で詳しく扱っています。

応答が途切れた注文は「失敗」ではなく「不明」として扱う

発注のリクエストがタイムアウトしても、注文が通ったかどうかは、送った側には分かりません。ここで素直に送り直すと、建玉が二重になります。この再送による二重発注は、本番で確かめておくべき重要な障害です。

Hyperliquidの発注APIは、cloid（発注側が付ける128ビットの16進文字列の注文ID）を任意で受け取ります。cancelByCloid で、このIDを使った取消もできます（Hyperliquid Docs「Exchange endpoint」）。

判断が確定した時点でcloidを振り、送る前に自分のDBに記録しておきます。そうすれば、タイムアウトの後に「このIDの注文はあるか」を取引所に問い合わせて、事実を確かめられます。送信の結果ごとの動き方は次のとおりです。

送信結果	注文の状態	取るべき動作
成功応答	確定（受理または即時拒否）	応答内容を記録し、以降は約定通知で追跡する
明示的なエラー応答	未成立と確定	原因を分類し、必要なら新しいcloidで作り直す
タイムアウト・接続断	不明	再送しない。cloidで照会し、存在すれば追跡、なければ再作成
照会自体が失敗	不明のまま	不明のまま新規発注しない。解消まで当該銘柄を停止

要は、「不明」を「失敗」にまとめないことです。事実を確かめられるまで、不明は不明のまま持ちます。cloidを持たない作りでは、この照会ができません。結局、建玉を突き合わせて後から気づくことになります。

起動と再接続のたびに、取引所の状態から作り直す

プロセスの再起動、本番への反映、WebSocketの切断、清算。どれも、エージェントが手元で持っている建玉を古くします。つまり手元の建玉は、いつでも実際とずれる可能性があります。そこで、取引所の状態を正とし、起動のときと再接続のときに必ず作り直します。

WebSocketの userFills を購読すると、最初のメッセージは isSnapshot: true のまとめで、その後が差分です。orderUpdates で注文の状態、userEvents で約定・資金調達・清算などの通知を受け取れます（Hyperliquid Docs「Subscriptions」）。

公式Docsは、自動化システムに次のことを示しています。サーバー側から切断されることを前提に、きちんと再接続すること。再接続のときのスナップショットには、切断中のデータが含まれること。必要なら、対応する情報取得（info）のリクエストで欠けた分を取れること（Hyperliquid Docs「Websocket」）。

作り直しは、次の順番に固定すると再現しやすくなります。

建玉と証拠金を取る：口座アドレスで、いまの建玉、余力、レバレッジの設定を取る。
未約定の注文を取る：板に残っている注文を並べ、自分が出した記録と突き合わせる。
宙に浮いた注文を片付ける：取引所にあるのに自分の記録にない注文と、記録にあるのに取引所にない注文を分ける。前者は取消の候補、後者は約定済みか届いていないかをcloidで確かめる。
差がなくなるまで発注しない：突き合わせが終わるまで、新しい判断を実行しない。

この「発注の前に必ず突き合わせる」手順を省くと、再起動のたびに建玉が積み上がるという、よくある不具合になります。WebSocketでの注文同期と照合の実装はHyperliquidのWebSocket注文同期、監視としきい値の作り込みはDeFiポジション監視と清算リスク対策で扱っています。

レート制限は、使える予算として設計に組み込む

Hyperliquidには、アドレスごとの制限があります。取引高1 USDCにつき1リクエストまでで、始めは1万（10000）リクエストの余裕があるだけです。まとめて送った注文も、アドレス側では件数分として数えられます。設計に大きく効くのは、この制限です。

取引高がまだ小さいうちに、数秒ごとに発注と取消をくり返すとどうなるか。取引高が積み上がる前に、予算を使い切ります。IP単位の制限や、取消の別枠などの数字は、後半にまとめました。

この制限は、エージェントの作りを次のように左右します。

設計上の問い	効いてくる制限	取れる方針
LLMをどの頻度で呼ぶか	LLMの費用と応答時間（取引所側の制限ではない）	相場イベント駆動にし、定期実行の間隔を長めに取る
板情報をどう取るか	情報取得系（info）の重み、WebSocketの購読上限	ポーリングではなく購読に寄せる
注文をどう出し直すか	アドレス単位の1 USDC=1リクエスト、初期10000	細かい建て直しを減らし、取消の別枠を活かす
複数口座へどう広げるか	サブアカウントは別ユーザーとして計上	口座ごとに予算を持ち、鍵も分ける

LLMを呼ぶ頻度は、取引所の制限とは別に、費用として効きます。相場のスナップショットを毎秒送る作りは、取引所の制限に触れる前に、費用の面で成り立たなくなります。判断が要る出来事が起きたときだけ呼ぶのが現実的です。

目安として、2026年9月24日時点で推奨モデルのClaude Opus 5.5は、100万トークンあたり入力4ドル・出力20ドル、コンテキスト窓は100万トークンです（Anthropic「Models overview」）。モデル名と料金は変わるので、採用する時点の値で計算し直します。

清算と利確・損切りは、取引所のマーク価格で決まる

公式Docsは、マーク価格が次のことに使われると明記しています。証拠金の計算、清算、利確・損切り注文（TP/SL）の発動、未実現損益の計算です。つまり、エージェントが自分で計算した価格と、取引所が損益や清算に使う価格は、別物です。ですから、エージェントが板の仲値だけを見て「まだ余裕がある」と判断しても、マーク価格が先にしきい値に届けば、清算やTP/SLは発動します。マーク価格の組み立て方は後半に載せました。

清算のラインは、維持証拠金（maintenance margin）で決まります。最大レバレッジで建てたときの当初証拠金（initial margin）の半分です。最大レバレッジは3倍から40倍の範囲なので、それに応じて維持証拠金率はおよそ1.25%から16.7%になります（Hyperliquid Docs「Liquidations」）。

したがって、リスクの計算には自分の推定価格ではなく、取引所が公開するマーク価格を使います。あわせて、価格の出どころが壊れたときに止める条件も持たせます。外部の価格に頼る仕組みの停止・復旧の設計はオラクル障害時のフォールバックとサーキットブレーカー設計で、資金調達料の扱いはPerps funding rate とはで扱っています。

市場の側の異常が、取引所のルールで処理された実例もあります。2025年3月26日のJELLY銘柄をめぐる事案です。自己清算を誘う取引によって、HLP（Hyperliquid Liquidity Provider。利用者の資金をまとめて運用する流動性提供の仕組み）が建玉を引き継ぎ、含み損が膨らみました。

最終的に、バリデーターの投票でこの銘柄は上場廃止となり、建玉は0.0095ドルで決済されています（CoinDesk（2025年3月26日））。ここから言えるのは、流動性の薄い銘柄では、値動きだけでなく、取引できること自体が失われうるということです。扱う銘柄を許可リストで絞る判断の材料になります。

止め方と戻し方を、先に決めておく

自動売買では、プロセスが落ちても、出した注文は板に残り続けます。止め方は、先に決めておく必要があります。

Hyperliquidには、schedule cancel（いわゆるdead man's switch。指定した時刻に全注文を自動で取り消す機能）があります。指定する時刻は、今より最低5秒後でなければなりません。発動は1日あたり最大10回で、回数は00:00 UTCに戻ります（Hyperliquid Docs「Exchange endpoint」）。

この機能は、エージェントのプロセスが落ちたまま、板に注文が残り続けるのを防ぐのに使えます。動いている間は、取消の予定時刻を定期的に先に延ばします。プロセスが止まれば、予定時刻が来て注文が自動で消える、という作りです。

1日10回の上限は、取消が実際に発動した回数に対するもので、予定時刻を更新した回数ではありません。APIのレート制限の範囲で、期限を延ばす「心拍」として使えます。ただし、更新の失敗を見張り、残りの発動回数と復旧の手順を管理します。

止める条件は、性質で分けて考えます。

技術的な停止：取引所につながらない、価格が取れない、状態の突き合わせが合わない、時計がずれている。どれも新しい発注を止め、既存の注文の扱いは別に決める。
リスク上の停止：日次損失の上限に届いた、建玉の総額の上限、想定外の銘柄での約定。
判断層の停止：LLMの応答がスキーマに合わない・拒否される状態が続く、根拠が空になる。

止めることと、止めた後にどう戻すかは、分けて考えます。止めるより戻す方が難しく、戻すときは前に書いた状態の作り直しを必ず通します。緊急停止と復帰の手順の詳細はHyperliquid AIエージェントのリスク制御で扱っています。

本番に移す前に確かめること

ここまでの設計が本当に成り立っているかは、次の観点で確かめられます。どれもテストネットで再現できる項目です。

二重発注：発注のリクエストをわざとタイムアウトさせ、送り直さないこと、cloidの照会で事実が確定することを確かめる。
再起動：建玉と未約定の注文がある状態でプロセスを落とし、再起動の後、突き合わせが終わるまで新しい発注をしないことを確かめる。
切断：WebSocketを強制的に切り、再接続の後のスナップショットで、抜けた約定を取り戻せることを確かめる。
上限：ポリシーゲートの各上限をわざと超える判断を入れ、却下されることと、監査ログに残ることを確かめる。
判断層の異常：スキーマに合わない応答や拒否の応答を入れ、建玉が動かないことを確かめる。
停止：各停止条件を起こし、想定どおり新しい発注が止まること、復帰の手順で状態が一致することを確かめる。
鍵：API Walletで出金の操作ができないこと、鍵を失効させたときに発注が止まることを確かめる。

テストネットから本番へ移すときの検証手順そのものはHyperliquid AI Botの本番移行にまとめています。なお、テストネットと本番では板の厚みが大きく違います。価格への影響と約定率は、テストネットの結果をそのまま当てはめられません。この点は価格インパクトとスリッページで扱っています。

よくある質問

API Walletの秘密鍵が漏洩したら、資金は引き出されますか？

API Walletからの出金はできません。Hyperliquidの公式Docsでは、API Walletは署名専用で資金を持たず、口座の代わりに操作を署名する鍵と説明されています（2026年9月24日確認）。一方で、漏れた鍵で発注はできるため、不利な建玉を作られて損失が出る可能性は残ります。被害は「資金の直接の持ち出し」ではなく「取引による損失」の形になる、と考えてください。鍵の失効手順と建玉の上限を用意しておく必要があります。

1つのAPI Walletで複数のサブアカウントを動かせますか？

技術的にはできますが、勧められません。Hyperliquidのnonceは署名者（秘密鍵）ごとに管理されるため、同じAPI Walletで署名する複数のサブアカウントは、nonceの追跡を共有します。公式Docsは、取引プロセスごと、サブアカウントごとにAPI Walletを分けることを勧めています。分けないと、一方の口座の発注がもう一方のnonceの窓を押し出し、原因の分かりにくい署名エラーが起きます。

LLMの判断を毎秒実行する必要はありますか？

多くの構成では必要ありません。理由は2つあります。

1つめは、Hyperliquidのアドレス単位のレート制限です。累積取引高1 USDCあたり1リクエストで、初期バッファ（始めに与えられる余裕）は10000リクエストです。高い頻度の発注・取消を前提にすると、取引高が積み上がる前に予算を使い切ります。2つめは、LLMの呼び出しが費用として直接効くことです。

価格のしきい値への到達や建玉の変化といった出来事を、決定的なコードで検知します。判断が要るときだけLLMを呼ぶのが現実的です。約定の速さが本質的に必要な戦略なら、判断層にLLMを置く設計自体が合っていない可能性があります。

実装する人向けの詳細

ここからは、さきほどのチームでエージェントを実装するエンジニア向けに、コードの例と仕様の数字をまとめます。

構造化出力のスキーマ

output_config.format にスキーマを渡すと、応答がその形に従うよう制約されます。tifは注文の有効期間の指定で、Alo（板に載る場合だけ受け付け）、Ioc（すぐ約定しない分は取消）、Gtc（取り消すまで有効）から選びます。

DECISION_SCHEMA = {
    "type": "object",
    "properties": {
        "action":   {
            "type": "string",
            "enum": ["open_long", "open_short", "reduce", "hold"],
        },
        "coin":     {"type": "string"},
        "size_usd": {"type": "number"},
        "limit_px": {"type": "number"},
        "tif":      {"type": "string", "enum": ["Alo", "Ioc", "Gtc"]},
        "reason":   {"type": "string"},
    },
    "required": ["action", "coin", "size_usd", "limit_px", "tif", "reason"],
    "additionalProperties": False,
}

resp = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=2048,
    output_config={
        "format": {"type": "json_schema", "schema": DECISION_SCHEMA},
    },
    messages=[{"role": "user", "content": market_snapshot}],
)

ポリシーゲートの概念例

from decimal import Decimal, InvalidOperation


def admit(decision, state, policy):
    # 概念例。stateとpolicyは型・有限性・鮮度を検証済みとする。
    action = decision.get("action")
    if action == "hold":
        return {"status": "HOLD"}
    # reduceは別経路で建玉・方向・reduceOnlyを検証する。
    if action not in {"open_long", "open_short"}:
        return {"status": "REJECT", "reason": "unsupported action"}
    try:
        size = Decimal(str(decision["size_usd"]))
        price = Decimal(str(decision["limit_px"]))
    except (KeyError, InvalidOperation, ValueError):
        return {"status": "REJECT", "reason": "invalid number"}
    if not (size.is_finite() and price.is_finite()):
        return {"status": "REJECT", "reason": "non-finite number"}
    if size <= 0 or price <= 0:
        return {"status": "REJECT", "reason": "non-positive number"}
    if size > policy.max_order_usd:
        return {"status": "REJECT", "reason": "order size cap"}
    exposure = state.gross_exposure_usd + state.pending_exposure_usd
    if exposure + size > policy.max_gross_usd:
        return {"status": "REJECT", "reason": "gross exposure cap"}
    # 日次PnLは未実現損益・手数料・資金調達料を含む定義を固定する。
    if state.day_pnl_usd <= -policy.max_daily_loss_usd:
        return {"status": "REJECT", "reason": "daily loss stop"}
    if decision.get("coin") not in policy.allowed_coins:
        return {"status": "REJECT", "reason": "coin not allowlisted"}
    return {"status": "PASS_TO_NEXT_CHECKS"}

これは新規注文の条件の一部を示す概念例です。通っても、発注の許可が確定するわけではありません。続けて、価格の乖離・丸め・注文条件・レバレッジ・入力の鮮度を検査します。

実行層では、intent_idに対してcloidを一度だけ振り、保存します。予算の予約と送信権の獲得は、分けられない1つの処理として行います。評価し直すたびに新しいcloidを作らないでください。縮小の注文は、建玉と方向を照合した専用の経路でreduceOnlyを必ず付けます。

API Walletの設定と署名の区別

口座データを問い合わせるときは、API Walletのアドレスではなく、実際の口座アドレスを渡します。

公式Python SDKでも、API Walletを使う場合の設定が明記されています。secret_key にはAPI Walletの秘密鍵を、account_address には親アカウントのウォレット（master wallet）の公開アドレスを設定します（hyperliquid-python-sdk）。ここを取り違えると、署名は通るのに残高や建玉が空に見える、という分かりにくい不具合になります。

署名の種類は2つです。発注やレバレッジの変更はL1 action（取引所内部の操作）で、API Walletが署名できます。USDCの送金、L1への出金、別のAPI Walletの承認はuser-signed action（利用者本人の署名が要る操作）に分類され、API Walletでは署名できません（Chainstack「Hyperliquid: User-signed actions with Python SDK」）。

nonceの規則

nonceの扱いは、Ethereumの一般的な動きとHyperliquidとで違います。Hyperliquidは、署名者のアドレスごとに大きい方から100件のnonceを持っています。新しい取引のnonceは、その集合の最小値より大きく、まだ使われていないものでなければなりません。

さらにnonceは、取引が入るブロックのunixミリ秒の時刻 T に対して、(T - 2日, T + 1日) の範囲に収まる必要があります（Hyperliquid Docs「Nonces and API wallets」）。

nonceは署名者（秘密鍵）ごとに管理されるため、同じAPI Walletで複数のサブアカウントに署名すると、nonceの追跡を共有します。公式Docsは、取引プロセスごとに別のAPI Walletを使うこと、サブアカウントごとにAPI Walletを分けることを勧めています。ここから、構成上の制約がはっきり導かれます。

1つのAPI Walletを、複数のプロセス・複数のコンテナで共有しない。並行して、単調に増えるnonceを振れません。100件の窓を互いに押し出し合って、署名がはじかれます。
プロセスの中では、1つの分けられないカウンタから番号を振る。公式Docsは、注文と取消を0.1秒ごとにまとめ、不可分に加算するカウンタ（atomic counter）で番号を振る運用を勧めています。
時計のずれを見張る。nonceが時刻の窓から外れると、署名が通りません。NTP（時刻合わせの仕組み）の同期のずれは、原因の分かりにくい発注の失敗として現れます。

もう1つ、見落としやすい注意があります。公式Docsは、API Walletの登録を解除すると、使用済みのnonceの状態が消え、過去に署名した操作を再送（リプレイ）されるおそれがあると明記しています。一度登録を解除したAPI Walletのアドレスは使い回さず、ローテーションのときは新しい鍵を作ります。この失効の手順も設計に含めます。

レート制限の数字

Hyperliquidのレート制限は、IP単位とアドレス単位の2段です（Hyperliquid Docs「Rate limits and user limits」）。

IP単位：REST全体で毎分1200の重みを共有する。発注などの発注系（exchange）リクエストの重みは 1 + floor(batch_length / 40)。情報取得系（info）は、種類により重み2、20、60
WebSocket：同時接続10、購読1000、毎分2000メッセージ、同時に処理中のpostメッセージ100件などの上限
アドレス単位：累積取引高1 USDCあたり1リクエスト、初期バッファとして10000リクエスト。取消には min(limit + 100000, limit * 2) の別枠がある
バッチ：IP単位では1リクエストとして扱われる一方、アドレス単位ではn件として数えられる

マーク価格の組み立て方

Hyperliquidのオラクル価格（oracle price）は、バリデーターが約3秒ごとに更新する、中央集権取引所の価格の加重中央値です。Hyperliquid自身の板からは独立しています。マーク価格は、次の3つの中央値として組み立てられます（Hyperliquid Docs「Robust price indices」）。

オラクル価格に、Hyperliquidの仲値（mid）とオラクル価格の差の150秒指数移動平均を加えたもの
Hyperliquidの最良買い気配、最良売り気配、直近約定値の中央値
Binance、OKX、Bybit、Gate.io、MEXCの無期限先物の仲値を3:2:2:1:1で加重した値

XTELAができること

私たちは、LLMの判断層・ポリシーゲート・実行層を分けたエージェントの骨格を貴社の戦略に合わせて組み立て、cloidの永続化、再接続時の状態再構築、停止と復帰の手順まで実装します。二重発注や強制切断をテストネットで実際に起こし、本番移行前の確認項目を一つずつ通すところまで一緒に担います。戦略の妥当性や規制上の位置付けは貴社側の判断領域として分け、法的な判断が必要な点は弁護士と連携して進めます。ご相談はお問い合わせからどうぞ。

資料の確認日と注意

仕様の確認日は2026年9月24日です。ここで述べたのは、2026年9月24日時点の公開資料にもとづく技術設計上の整理で、投資助言ではありません。Hyperliquidの仕様、レート制限、価格指数の構成、各種上限値、LLMの料金は更新されるため、実装時は使用時点の公式Docsと自社環境での測定で確認してください。

記事一覧