akash

Akash — ワークロードをデプロイする

このスキルでは、Akash Networkでワークロードをデプロイして運用するために必要なすべてを扱います。SDLの記述、デプロイ方法の選択、認証、デプロイの作成、入札の受け入れ、稼働中のデプロイからログやイベントを読み取る方法について説明します。

Akashのプロバイダーを運用する場合は、akash-network:akash-providerスキルを使用してください。フルノードまたはバリデーターを運用する場合は、akash-network:akash-nodeを使用してください。

重要なルール

**:latestを使用したり、イメージタグを省略したりしないでください。**デプロイを再現可能にするため、必ず明示的なバージョンタグを指定してください。

# CORRECT
image: nginx:1.25.3
image: postgres:16

# WRONG
image: nginx:latest
image: nginx          # implies :latest

Akashには2種類のトークンがあります。混同しないでください。

• AKT（uakt、1 AKT = 1,000,000 uakt）はチェーントークンです。ガス代（--gas-prices、minimum-gas-prices、SDKのWithGasPrices）、ステーキング（自己委任、バリデータのボンド、スラッシング）、バリデーター報酬に使用します。自己管理ウォレットで保有するのはAKTです。
• ACT（uact、1 ACT = 1,000,000 uact）はデプロイの支払い用トークンです。SDLの価格設定（denom: uact）、デプロイのエスクロー、入札価格（プロバイダーが提示するレート）、リースの支払いに使用します。なお、プロバイダー側の入札デポジット（MsgCreateBidにおけるスパム防止用の担保、bidMinDeposit設定）はuactではなくuaktです。プロバイダーはチェーン上の操作にAKTのみを使用し、リースからACTを獲得します。デプロイする側がこれに直接関わることはありません。

**自己管理でデプロイする場合、デプロイに資金を充当する前に、AKTをバーンしてACTをミントする必要があります。**まずAKTを取得し（取引所／テストネットの場合はフォーセット）、その一部をバーン／ミントの仕組みでACTに変換してください。Console APIのユーザーはこの手順をすべて省略できます。USDクレジットを追加すれば、Consoleが各デプロイに自動で資金を充当します（サーバー側でStripe → USD → ACT）。

--gas-prices 0.025uaktを見かけた場合、これは正しい設定です（ガス代はAKTで支払います）。SDLでdenom: uact, amount: 1000を見かけた場合も正しい設定です（リース料金はACTです）。通常のコマンドでは、どちらのデノミネーションも使われます。

デプロイ方法の選択

これは、このスキルで最も重要な決定であり、最も間違えやすい決定でもあります。

デフォルトの動作：推奨して進め、質問攻めにしない。 ユーザーが妥当な手がかりを少しでも示した場合（下の手がかり表を参照）は、その方法を黙って選び、コードの作成を始めてください。質問が必要な場合でも、短い質問を1つだけして、推奨案を提示し、別の方法への切り替えも可能だと伝えてください。ユーザーがコマンドを見る前に、段階的な決定ツリーを作らないでください。目標はクイズに答えてもらうことではなく、すばやくコードを実行できるようにすることです。

プロンプトに何の手がかりもない場合（言語、ウォレット、CI に関する手がかりが皆無の場合）に限り、作業を止めて質問してください。その場合でも、同等の選択肢を並べるのではなく、推奨案を示し、切り替えも可能だと伝えてください。

いったん方法を選んだら、会話の残りの間はその方法を維持してください。黙って切り替えないでください。ユーザーが後から明確に切り替えを求めた場合は、適切に切り替えてください。

デプロイ方法は5つ（ワークロードをホストする方法）と、利用方法が1つ（ホストされたモデルを呼び出す方法）あります。

#	方法	ウォレットの方式	認証	利用する場面
1	Console API	マネージド（Console アカウントがウォレットを所有）	x-api-key ヘッダー	CI/CD、サーバー間通信、HTTP と API キーを使いたいバックエンド全般。秘密鍵を扱う必要はありません。
2	akt CLI	Console API キーによるマネージド方式、またはローカルのキーリングによるセルフカストディ	AKT_CONSOLE_API_KEY またはコンテキストの認証情報、もしくはローカルキー	ターミナルやエージェントのセッション：akt deploy を実行するだけで SDL から実行中のサービスまでデプロイでき、akt console でログ、ステータス、シェルを確認できます。
3	Akash CLI（provider-services）	セルフカストディ（自分で鍵を管理）	ローカルキー + 署名	既存の provider-services スクリプトや、手動でのチェーン操作。現在、公式ドキュメントでは新規 CLI ユーザーに akt を案内しています。
4	TypeScript SDK	セルフカストディ（ブラウザーウォレット、ハードウェアウォレット、またはローカルキー）	SDK がローカルで署名	dApp、Node.js サービスなど、JS/TS コードでデプロイしたい場合。
5	Go SDK	セルフカストディ	SDK がローカルで署名	Go のバックエンドサービス、カスタムツール。
6	AkashML (利用方法であり、デプロイではありません)	マネージド（AkashML アカウント、USD クレジット）	Authorization: Bearer	LLM をホストするのではなく、LLM を呼び出したい場合。OpenAI/Anthropic 互換の REST。SDL、ウォレット、ACT は不要です。

1～5 は、Akash 上で独自のワークロードをホストする方法です。6 は、ユーザーが推論を利用したい場合の方法で、別の課題であり、利用するインターフェイスも異なります。全体の区分については、@rules/deploy/akashml/overview.md を参照してください。

誰もがつまずく概念

Console アカウントはウォレットそのものです。 console.akash.network でサインアップして API キーを生成すると、その API キーは Console アカウントの認証に使われます。また、アカウントにはマネージドウォレットが紐づいています。デプロイの費用はそのウォレットから支払われます。「Console API + 自分のウォレットを持ち込む」という別の方式はありません。

セルフカストディウォレット（Keplr または Ledger）を持っていて、そのウォレットからデプロイしたい場合は、CLI またはSDKを使う必要があります。Console API は外部ウォレットで署名できません。

Console には2つの種類があります — 混同しないように区別してください

• console.akash.network の Standard Console — マネージドウォレット。このスキルの Console API が操作するのはこちらです。
• Console Air（github.com/akash-network/console-air）— Keplr またはハードウェアウォレットを使うセルフカストディ型 UI。セルフホスト可能 — console-air.akash.network に公式ホスト URL はありません。ユーザーはリポジトリをクローンし、ローカルまたは自分のインフラストラクチャ上で実行します。このスキルの対象外です（API ではなく UI のため）。セルフカストディ対応の UI を希望するユーザーにはリポジトリを案内して、そこで終了してください。プログラムによるセルフカストディを希望する場合は、CLI または SDK を案内してください。

手掛かりを見つけたら、積極的に活用する

次の手掛かりがどれか一つでもあれば、対応する方法に黙って決めて、コードの作成を始めてください。確認を求めてはいけません。手掛かりが確認そのものです。

ユーザーが次のいずれかに言及したら…	次の方法に決める…
"akt"、"akt deploy"、"akt redeploy"、"akt console"、"akt context"、AKT_CONSOLE_API_KEY、"akash-network/tap/akt"、またはユーザーがこのターミナルから実行したいと希望し、command -v akt で見つかった場合	akt CLI（コンテキストによって Console またはセルフカストディが決まります）
"I have an API key"、ac.sk. で始まるキー、"$AKASH_API_KEY"、"x-api-key"、"curl"、"CI/CD"、"GitHub Actions"、"backend"、"server-to-server"、"deploy from CI"、"automate"	Console API
"Keplr"、"Ledger"、"hardware wallet"、"my wallet"、"self-custody"、"provider-services keys add"、"my mnemonic"	CLI または SDK（言語の手掛かりもある場合を除き、確認してください）
"React app"、"Next.js"、"akashjs"（レガシー）、"@akashnetwork/chain-sdk"、"my dApp"、"in the browser"	TypeScript SDK
"Go service"、"golang"、"cosmos-sdk Go"、"my Go backend"	Go SDK
"AkashML"、"akml-..."、"managed inference"、"call an LLM"、"hosted LLM on Akash"、"OpenAI-compatible"、"Anthropic-compatible"、"playground.akashml.com"、"api.akashml.com"、AkashML を指す ANTHROPIC_BASE_URL	AkashML（利用方法）
"Console Air"、"web UI for my Keplr wallet"、"self-custody" と "GUI" の組み合わせ	Console Air（対象外。リポジトリへの案内を一行で示し、そこで終了）
"easiest"、"simplest"、"first time"、"just want to try" と、ウォレット／キーの手掛かりがない場合	Console（UI または API。単発なら UI、スクリプトなら API を推奨）

手掛かりが二つの方法を示す場合は、より具体的な方を優先します。CI ジョブまたは API キーに akt への言及が伴う場合は、akt のままです。

LLM に関する曖昧さ — 短い質問を一つだけしてください。 ユーザーが 「run an LLM on Akash」 と言い、「my own」 や 「call」 と言っていない場合、手掛かりは AkashML（ホストされたモデルを呼び出す）と GPU SDL でのセルフデプロイ（モデルを自分でホストする）のどちらとも解釈できます。一行で質問します。「ホストされた LLM を呼び出したいですか、それとも自分専用のインスタンスを実行したいですか？」 — その後、回答に応じて決めます。この二つの回答はまったく異なるファイル（AkashML と rules/sdl/examples/gpu-workload.md）につながります。

確認するのは、プロンプトに手掛かりがまったくない場合に限ります。言語、ウォレット、CI／自動化の手掛かりがない場合です。質問する場合は一行にします。「スクリプト（Console API）と UI（管理ウォレットなら Console、セルフカストディなら Console Air）のどちらを使いますか？」 — その後、回答に沿って進めます。

他に手掛かりのない「初めての小規模なデプロイ」なら、Console UI を勧めて SDL を作成してください。回答の最後の行は、選択肢を挙げて疑問符で終わる質問一つだけにします。「akt CLI または Console API を使ってスクリプトで実行する方法と、ご自身のウォレットからデプロイする方法のどちらがよいですか？」 コマンドを示す前に、方法の表からユーザーに選ばせてはいけません。

Console API の言語 — まず推測し、情報がなければ質問する

Console API を使うことになったら、手掛かりから実装言語を選びます。質問するのは最後の手段にしてください。

手掛かり	使用するもの
"curl"、"bash"、"shell"、"GitHub Actions"、"GitLab CI"、.sh の参照、アプリのスタックに言及がない	curl + Bash
"Node"、"Next.js"、"Express"、package.json、.ts／.js ファイル、"my Node app"	TypeScript / Node fetch
"Python"、requirements.txt、.py、"FastAPI"、"Django"、"Flask"	Python requests または httpx
"Go"、go.mod、.go、"my Go service"	Go net/http
"Rust"、Cargo.toml	Rust reqwest

言語が明示されておらず、かつ周辺の文脈が自動化／CI（API キーを使うユーザーで最もよくあるケース）の場合は、curl + Bash をデフォルトにします。ユーザーが特定の別のランタイムを希望していると考える確かな理由がない限り、質問しないでください。そうした理由がある場合でも、まず curl を使った例を提示し、翻訳できることを伝えます。curl は HTTP の汎用的な共通言語であり、どの言語にも簡単に置き換えられます。

以下の場合は質問を省略します：

• 上記の手掛かりがある（その言語で進めます）。
• ユーザーが特定の言語のコードをすでに貼り付けている（その言語に合わせます）。
• ユーザーが "curl"、"shell"、"CI"、またはスクリプトを示唆するものを指定している（Bash を希望しています）。

質問するのは、手掛かりがまったくない場合だけです。たとえば、他の文脈がなく 「API 経由で Akash にデプロイ」 とだけある場合です。その場合は一行で、「curl/Bash、Node、Python、Go のどれにしますか？」 と尋ね、ユーザーの回答に合わせて返します。

これはデプロイ方法を選ぶ手順とは別の確認です。両方を選んだら、会話の残りではどちらも変更しないでください。

API キーの扱い — 通常は何も言わず、必要な場合だけ対応するルール

必ず守るルールは2つです。通常は説明せずに適用します。

1. コードでは常に環境変数を介してキーを参照します：$AKASH_API_KEY（Bash）、process.env.AKASH_API_KEY（Node）、os.environ["AKASH_API_KEY"]（Python）、os.Getenv("AKASH_API_KEY")（Go）。akt は AKT_CONSOLE_API_KEY を自動で読み取るため、akt を使う場合はその名前でエクスポートし、キーを引数として渡さないでください。
2. コードやチャットでキーの実際の値を表示してはいけません。ユーザーが貼り付けた場合も同様です。ユーザーが実際のキーを貼り付けた場合は、回答内で $AKASH_API_KEY に置き換え、冒頭に一文追加します：「以下のコードでは $AKASH_API_KEY を使っています。実行前に、キーをその環境変数としてエクスポートしてください。」

追加のガイダンスが必要な場合（以下のうち該当するものを1つだけ選び、最も簡潔なものにします）：

• ユーザーが実際のキーを貼り付けた場合 → 上記の一文で案内します。説教じみた説明はせず、環境変数名だけを使います。
• ユーザーが、指定した特定のランタイム（GitHub Actions、GitLab CI、Docker など）でキーをどこに設定すべきか尋ねた場合 → そのランタイムについて一行で答えます。すべてを列挙しないでください。
• ユーザーがDockerfile を作成している場合 → キーは実行時に (-e) 渡す必要があり、ARG／ENV で埋め込んではならないことを一文で伝えます。
• ユーザーが .env ファイルに言及した場合 → .gitignore に追加するよう一行で注意を促します。チュートリアルが必要だと決めつけないでください。

以下の場合はキーの扱いについて何も言いません：

• ユーザーがキーは $AKASH_API_KEY、${{ secrets.AKASH_API_KEY }} などに設定済みだとすでに伝えている場合 — 対応できています。ルールを繰り返さないでください。
• ユーザーが呼び出し後の内容（ステータス、ログ、入札）について質問している場合 — キーの扱いは解決済みです。
• 会話でコードを作成していない場合（アーキテクチャに関する質問、既存のデプロイのトラブルシューティングなど）。

コードを含む回答の最後に置く注意点の表では、よくある実際の誤りとして「API キーに Authorization: Bearer を使わないでください」と記載してもかまいません。ただし、秘密情報の管理について長々と説明せず、一行だけにしてください。

一度決めたら、そのまま進める

• Console API の経路では、provider-services keys add を提案しないでください。mTLS 証明書を提案しないでください（Console API では非推奨です。rules/deploy/cli/mtls-legacy.md を参照）。provider-services query market bid list も提案しないでください。読み取りはすべて、ユーザーが選んだ言語で x-api-key を付けた HTTP 呼び出しです。Console は各デプロイの SDL を記録するため、実行中のデプロイは PATCH /v1/deployments/{dseq} で変更してください（非推奨の SDL 全体を指定する PUT は使用しないでください）。POST /v1/leases に manifest を送らず、どこにも deposit を指定しないでください。また、CPU、メモリ、ストレージ、GPU、レプリカの変更は新しいデプロイとして扱ってください。
• akt の経路では、curl や provider-services ではなく、akt コマンドを実行してください。まず akt version を確認してください。1.0.1 以降では Console デプロイへの入金が拒否され、0.1.x ではそこで --deposit 0.5 が必要です（できれば brew upgrade akash-network/tap/akt を実行してください）。無人実行では --bid-select と --yes を渡し、-o json または -o jsonl を読み取ってください。ターミナルがなければセットアップウィザードを使えないため、最初のコマンドの前にコンテキストを作成してください（akt context create <name> --deploy-via console）。1.0.1 では、シークレットは ac-secret://NAME 参照として指定し、値は --secrets-file に記述します（コマンドラインには絶対に記述しないでください）。akt update --patch は単一フィールドを変更し、リソースの変更には akt redeploy <dseq> --sdl-file <new> を使います。これにより、古いデプロイは実行中のままになります。セットアップとレシピについては、rules/deploy/akt/ を参照してください。
• Akash CLI（provider-services） の経路では、/v1/deployments への HTTP 呼び出しを提案しないでください。API キーも提案しないでください。provider-services tx ...／provider-services query ... を使ってください。
• SDK の経路では、curl の例や CLI コマンドに頼らないでください。ユーザーはコードを求めています。
• AkashML の経路では、SDL を記述せず、uact／uakt／リース／入札について話さないでください。ユーザーはホスト型推論 API を呼び出しており、デプロイを行っているのではありません。Authorization: Bearer $AKASHML_API_KEY と https://api.akashml.com/{v1,anthropic} の呼び出しを使ってください。ユーザーが後から「やっぱり自分でホストしたい」と言った場合は、5 つのデプロイ経路のいずれかに明確に切り替えてください。
  • カタログ／料金／機能については、必ず稼働中の API に問い合わせてください。このスキルに埋め込まれたモデル ID、料金、機能一覧を信用しないでください。 モデルの推奨、料金の提示、機能（ツールの使用、推論、ストリーミング、コンテキスト長）の説明をする前に、該当するエンドポイントを呼び出してください。
    • GET https://api.akashml.com/v1/models — 料金（100 万トークンあたり）、context_length、supported_features、supported_sampling_parameters、max_output_length、quantization
    • GET https://api.akashml.com/anthropic/v1/models — Anthropic 形式の一覧（ID は -- にエイリアスされています）
    • ドキュメントの情報が古い可能性のある内容についてユーザーから質問された場合は、その他のドキュメント化されたエンドポイントを使用してください
  • このスキルに記載されたモデル名（DeepSeek、MiniMax、Kimi、Qwen）は、変更されている可能性がある例です。最新の一覧を正としてください。ユーザーが自身の API キーを提供した場合、モデルや料金を特定して回答する前に、そのキーを使って稼働中のエンドポイントに問い合わせてください。

ユーザーが切り替えを求めた場合（「代わりに API 経由でできますか？」など）は、切り替えを確認し、その時点から新しい経路のルールを適用してください。

クイックリファレンス

SDL の構造

すべての SDL には、必須セクションが 4 つあります（IP リース用の endpoints とリソース再利用用の reclamation は省略可能です）。

version: "2.0"  # or "2.1" for IP endpoints or the reclamation block

services:       # Container definitions
profiles:       # Compute resources & placement
deployment:     # Service-to-profile mapping

最小 SDL テンプレート

version: "2.0"

services:
  web:
    image: nginx:1.25.3
    expose:
      - port: 80
        as: 80
        to:
          - global: true

profiles:
  compute:
    web:
      resources:
        cpu:
          units: 0.5
        memory:
          size: 512Mi
        storage:
          size: 1Gi
  placement:
    dcloud:
      pricing:
        web:
          denom: uact
          amount: 1000

deployment:
  web:
    dcloud:
      profile: web
      count: 1

ドキュメントの構成

コアコンセプト

• @rules/overview.md — Akash Network の概要とアーキテクチャ
• @rules/terminology.md — 主な用語（リース、入札、dseq、gseq、oseq）
• @rules/pricing.md — uact による支払い（デプロイ支払いのデノミネーション）

SDL の設定

• @rules/sdl/schema-overview.md — バージョン要件と SDL の構造
• @rules/sdl/services.md — サービスの設定（イメージ、公開ポート、http_options、環境変数、認証情報）
• @rules/sdl/compute-resources.md — CPU（ユニット、arch）、メモリ、ストレージ、GPU の仕様
• @rules/sdl/placement-pricing.md — プロバイダーの選択と料金（uact）
• @rules/sdl/deployment.md — サービスとプロファイルのマッピング
• @rules/sdl/endpoints.md — IP エンドポイントの設定（v2.1）
• @rules/sdl/reclamation.md — リソース回収の reclamation ブロック（v2.1、AEP-82）
• @rules/sdl/confidential-compute.md — コンフィデンシャルコンピューティング／TEE（params.tee、AEP-83）
• @rules/sdl/validation-rules.md — すべての制約と検証ルール

SDL の例

• @rules/sdl/examples/web-app.md — シンプルな Web デプロイ
• @rules/sdl/examples/wordpress-db.md — 永続ストレージを使用する複数サービスの構成
• @rules/sdl/examples/gpu-workload.md — NVIDIA を使用した GPU デプロイ
• @rules/sdl/examples/ip-lease.md — IP エンドポイントの設定
• @rules/sdl/examples/reclamation.md — リソース回収の猶予期間（v2.1）
• @rules/sdl/examples/confidential-compute.md — コンフィデンシャルコンピューティング（TEE）：CPU のみ、および CPU＋GPU

デプロイ方法

• @rules/deploy/overview.md — 方法の選択（ここから開始）
• @rules/deploy/console-api/ — Console API（API キーを使用）
  • overview.md — ベース URL、エンベロープ、エラーコード、非推奨および UI 内部用のエンドポイント、エンドポイント一覧
  • authentication.md — API キー（x-api-key、ac.sk.… 形式、CRUD）、公開エンドポイント、CI/CD
  • deployment-endpoints.md — 作成、一覧表示、読み取り、PATCH、クローズ；リース、入札、実行時の制限、プロバイダー、配置、入札のスクリーニング
  • secrets.md — ac-secret:// 参照、sealedSecrets、inheritSecretsFrom
  • api-key-quickstart.md — 「API キーを持っている」状態からデプロイの実行までを順に解説
  • account-and-funding.md — アカウントモデル、残高、自動入金、402 拒否（サインアップとクレジットの追加は UI からのみ）
  • operations.md — プロバイダー JWT（leases の形式、スコープ）、ログ／イベント／ステータス／シェル、TEE のアテステーション
• @rules/deploy/akt/ — akt CLI（Console API キーまたはローカルのキーリング；ターミナルおよびエージェントのセッション）
  • overview.md — インストール、0.1.x と 1.0 の違い（デポジット）、ターミナルを使わないコンテキストと認証情報の設定、JSON／JSONL 出力、MCP サーバー、akt と Console API の対応関係
  • console-workflows.md — SDL、デプロイ、ログ／イベント／ステータス／シェル、更新、入金、クローズ、キャパシティ、復旧、CI
• @rules/deploy/cli/ — Akash CLI（provider-services、セルフカストディ方式）
  • mtls-legacy.md — CLI／SDK からのプロバイダー直接呼び出しに使用する従来の mTLS 認証（Console API では非推奨）

マネージド推論（デプロイではなく利用）

• @rules/deploy/akashml/ — AkashML：Akash のコンピューティングリソース上でホストされたオープンソース LLM を呼び出す
  • overview.md — ベース URL、AkashML と GPU のセルフデプロイを使い分ける場面、課金方式の違い
  • authentication.md — akml-... キー、Authorization: Bearer、環境変数のルール
  • api-reference.md — curl と SDK の例を含む OpenAI および Anthropic のインターフェース
  • quickstart.md — サインアップから最初の推論呼び出しまでを順に解説
  • account-and-billing.md — USD クレジット（オフチェーン、uact とは別）、キーごとの RPM／TPM 制限
  • claude-code-integration.md — ANTHROPIC_BASE_URL を使って Claude Code の Anthropic クライアントを AkashML に接続

SDK ドキュメント

• @rules/sdk/overview.md — SDK の比較と選択
• @rules/sdk/typescript/ — Web および Node.js 向け TypeScript SDK
• @rules/sdk/go/ — バックエンドサービス向け Go SDK

AuthZ（委任された権限）

• @rules/authz/ — 手数料の付与とデプロイの認可

入札のマッチング（デプロイ担当者向け）

• @rules/bid-matching/overview.md — 利用する場面、マッチャーの実行方法、結果の提示方法
• @rules/bid-matching/adaptation-rules.md — SDL 変更の優先順位
• @rules/bid-matching/matching-rules.md — SDL とプロバイダーのフィールドマッピング

リファレンス

• @rules/reference/storage-classes.md — beta2、beta3、ram ストレージ
• @rules/reference/gpu-models.md — サポート対象の NVIDIA GPU
• @rules/reference/rpc-endpoints.md — 公開 RPC エンドポイント

共通パターン

環境変数

services:
  app:
    env:
      - "DATABASE_URL=postgres://..."
      - "NODE_ENV=production"

永続ストレージ

profiles:
  compute:
    app:
      resources:
        storage:
          - size: 10Gi
            attributes:
              persistent: true
              class: beta2

GPU ワークロード

profiles:
  compute:
    ml:
      resources:
        gpu:
          units: 1
          attributes:
            vendor:
              nvidia:
                - model: a100

CPU アーキテクチャ（arm64）

profiles:
  compute:
    api:
      resources:
        cpu:
          units: 2
          attributes:
            arch: arm64     # or amd64; omit to write no CPU attribute (there is no default)

ストリーミングルート（プロキシのバッファリングを無効化）

services:
  api:
    expose:
      - port: 8080
        as: 80
        to:
          - global: true
        http_options:
          proxy:
            buffering_disable: true   # chain-sdk >= 1.0.0-alpha.44; not honored by providers yet

コンフィデンシャルコンピューティング（TEE）

services:
  web:
    params:
      tee: cpu        # or: cpu-gpu (requires GPU resources)

支払いオプション

• uact — ACT（デプロイメント支払いトークン。AKT とは別）のマイクロ単位です。SDL の価格設定（amount: 1000）、デプロイメントのエスクロー、リースの支払いに使用する denom です。uakt は通常の代替手段としてではなく、まれな burn-mint（BME）フォールバックでのみ受け付けられます。
• 注：Console API のデプロイメントではデポジットは一切不要です。Console がアカウントの USD クレジット残高から資金を提供します。

追加リソース

• awesome-akash — 本番環境ですぐに使える SDL テンプレートを 100 件以上掲載
• Akash Network Docs — 公式ドキュメント
• Console（管理ウォレット） — Web UI。このスキルの Console API 経由の手順に相当する、管理ウォレットを使用する方法です
• Console Air（セルフカストディ、セルフホスト可能） — Keplr またはハードウェアウォレット用の Web UI。クローンしてローカルで実行します
• akt CLI docs — 統合 Akash CLI。専用のエージェントスキル akt-cli は、各リリースに akt_<version>_skill.zip として同梱されています
• Console API OpenAPI spec — 非推奨項目を明記した最新の契約仕様です。このスキルではデプロイメント管理に関する部分をまとめています。仕様には Stripe、アラート、ユーザー登録などの Console UI 内部機能も含まれます
• @akashnetwork/chain-sdk — TypeScript SDK（セルフカストディの JWT 署名、チェーンメッセージ）