deploy-to-cloud-engine

Name: deploy-to-cloud-engine
Author: dfinity

github.com/dfinityクラウド・DevOps39178 回インストール今日更新

deploy-to-cloud-engine について

ビルド可能なプロジェクトを、ユーザー所有のInternet Computerクラウドエンジンへデプロイするコーディングエージェント向けスキルです。CLIのIDをエンジンのコンソールに結び付け、指定サブネットへデプロイする手順と、ローカル・リモート・オフライン環境への対応を扱います。

主な機能

01CLIのIDをエンジンコンソールに連携
02指定サブネットへのデプロイ
03ローカル・リモートでのログイン対応
04オフライン環境向けの引き継ぎ
05プロキシcanisterの要否確認

活用シーン

01ビルド済みアプリをクラウドエンジンへデプロイ
02CLIをエンジン管理者のIDに連携
03ネットワークのない環境からデプロイを準備
04アプリにプロキシcanisterが必要か確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dfinity/icskills --skill deploy-to-cloud-engine

インストール後、Claude Code で/deploy-to-cloud-engineを入力して読み込まれたか確認します。

詳細

Cloud Engine へのデプロイ

これは何か

cloud engine は、ウェブコンソール（デフォルトでは https://opencloud.org）から管理する、ユーザー所有の Internet Computer 容量の一部です。各エンジンは単一の subnet 上で実行されます。このスキルでは、すでにビルドできるプロジェクトを、コーディングエージェントからそのエンジンにデプロイします。

このスキルで扱うのは、クラウドエンジン固有の手順、つまり CLI をエンジンのコンソール ID にリンクすることと、サブネットを指定してデプロイすることだけです。CLI のその他すべて（icp.yaml、レシピ、環境、バインディング、ID）については、icp-cli スキルを読み込んでください。

コードを書く前に、実行環境を確認してください。 通常のサインインである icp identity link web は、icp がユーザーのブラウザーと同じマシン上で実行されている場合にのみ完了します（ステップ 1.0 を参照）。リモート環境やクラウドサンドボックスで実行している場合は、何かをビルドする前にユーザーに伝え、代わりにローカルセッションを開始するよう依頼してください。たとえば、Claude デスクトップアプリでセッションを開始したときのローカル環境や、ユーザー自身のコンピューター上のコーディングエージェント（Claude Code、Codex CLI、Cursor）です。クラウドセッションを後からユーザーのコンピューターに移すことはできないため、ビルド後ではなく、ビルド前に依頼して返答を待ってください。ローカルでの選択肢がない場合に限り、サンドボックスで続行します。その場合は、まずステップ 1.0 の委任引き継ぎを行い、サンドボックスの CLI がユーザーとしてサインインしてからビルドしてください。サインインをデプロイ時まで先送りしてはいけません。

使い方に確信のない icp コマンドを実行する前に、icp <subcommand> --help（例：icp identity link --help、icp deploy --help）を実行し、コマンドとフラグが存在することを確認してください。フラグを推測してはいけません。正式なリファレンス：https://cli.internetcomputer.org/llms.txt

必要な情報

必要な値は 2 つ、一部のアプリでは 3 つです。まず icp.yaml または会話の前の部分を確認してください。1 つにはデフォルトがありますが、残りはユーザーに尋ねる必要があります。

コンソールのオリジン — ユーザーがクラウドエンジンのコンソールにサインインする URL です。デフォルトは https://opencloud.org（OpenCloud のメインコンソール）です。ステップ 1 で --auth オリジンとして使用し、リンクされた CLI ID が エンジンを管理するプリンシパルと同じものを導出するようにします。デフォルトを使用しますが、リンクする前にその旨を伝え、変更を希望するか確認してください。
- 伝える内容：「デフォルトのコンソールである https://opencloud.org を使って CLI をリンクします。エンジンのコンソールに別の URL からサインインする場合は、今お知らせください。」
- 別のオリジンを使用するのは、ユーザーがその URL を指定した場合だけです。独自の判断で別の URL に置き換えてはいけません。--auth オリジンによって導出されるプリンシパルが決まります（落とし穴 2 を参照）。
サブネット ID：エンジンのデプロイ先のサブネットです。icp deploy --subnet で必須です。デフォルトはありません。 絶対に推測してはいけません。ユーザーはコンソールのエンジンの Settings ページ（エンジンの識別情報の下）で確認するか、コンソールのコマンドパレットからコピーできます。情報がない場合は、必ず尋ね、回答を得るまで先に進まないでください。
- 尋ねる内容：「エンジンのサブネット ID を教えてください。コンソールのエンジンの Settings ページにあります。」
プロキシーキャニスター ID：アプリが threshold ECDSA/Schnorr、vetKD、為替レートキャニスター、Bitcoin API、または EVM/SOL RPC キャニスターを呼び出す場合にのみ必要です（PROXY_CANISTER_ID 変数、または proxy メソッドの呼び出しを探してください）。デフォルトはありません。 コンソールのプロキシーを自分で作成することはできず、自分でデプロイしたものでは代用できません（ステップ 5）。情報がない場合は、デプロイ前に必ず尋ねてください。
- 尋ねる内容：「このアプリでは、エンジンのプロキシーキャニスターが必要です。エンジンにある場合は、その ID を送ってください（engine → Canisters → Proxy canisters）。ない場合は、エンジンの所有者が Deploy a proxy からデプロイできます。費用はエンジンの残高から支払われ、カードは不要です。その後、ID を送ってください。」

これらの情報を記録し、セッション中に再度尋ねないようにしてください。

前提条件

$PATH 上に icp があること — インストール方法については icp-cli スキルを参照してください。icp --version で確認できます（このスキルのコマンドは 0.3.0 および 1.0.2 で検証済みです）。インストールされているバージョンが異なる場合は、実行前に icp <cmd> --help でフラグを確認してください。フラグはメジャーバージョン間で変更されています。
すでにビルドできるプロジェクトがあること。まだビルドまたはパッケージ化できない場合は、先に設定してください（icp-cli スキルを参照）。その後、ここに戻ってください。
まだプロジェクトがなく、その説明もありませんか？ コードを書いたりファイルを作成したりする前に、ユーザーに何を構築するか尋ねてください：「どんなアプリを作りたいですか？」独自にサンプルアプリ（ゲストブック、カウンター、ToDo リストなど）を選んではいけません。「アプリを構築してデプロイして」というだけのプロンプトは、選択する依頼ではなく、質問する依頼です。
macOS：icp はデータを ~/Library/Application Support/org.dfinity.icp-cli/ に保存します。シェルからそこに書き込めない場合（macOS TCC による Operation not permitted など。たとえばコマンドがブリッジ経由で実行される場合）、セッション中は保護されていないパスにデータをリダイレクトしてください — HOME=/tmp/icp-home icp … — 以降のすべての icp コマンドでも同じ HOME を使用してください。そうしないと、後続のコマンドからリンク済みの ID を参照できません。

ステップ 1 — CLI をエンジンの ID にリンクする（一台につき一度）

CLI はエンジンを管理するものと同じ IDで署名する必要があります。つまり、コンソールへのログインに使うプリンシパルです。

ステップ 1.0 — まず、ブラウザーに対する CLI の実行場所を確認する

icp identity link web は、CLI が実行されているマシン上の http://127.0.0.1:<port> へのリダイレクトを介してサインインを完了します。ユーザーが Internet Identity のサインインを完了するブラウザーから、そのループバックアドレスにアクセスできる必要があります。リンクする前に、環境を確認してください。

CLI とブラウザーがネットワーク接続のある同じマシン上にある場合（ローカル開発、またはユーザー自身のマシン上で動作するターミナル統合型エージェント）→ 以下の通常のリンクフローを使用してください。
CLI がネットワーク接続のあるリモートまたは隔離されたサンドボックス内にある場合（エージェントはクラウドで動作し、ユーザーのブラウザーは別のマシン上にある）→ 通常のフローは機能しません。サインイン URL の callback=http://127.0.0.1:<port> はサンドボックスに紐づいていますが、ユーザーのブラウザーでは 127.0.0.1 がユーザー自身のマシンを指すため、委任情報は CLI に届きません。その後のコマンドは認可エラーで失敗します。まずローカルセッションに切り替えるようユーザーに依頼してください（「これは何か」を参照）。切り替えられない場合に限り、以下の委任情報の受け渡しを使用してください。
ネットワークにまったく接続できない CLI シェル（例：ユーザー自身のマシン上にあるサンドボックス化されたデバイスブリッジ。DNS がブロックされている、HTTPS リクエストが失敗する、書き込み先が /tmp に制限されている場合）→ ここでは icp deploy も含め、ネットワークを使う icp コマンドは実行できません。リンクだけでなく、icp deploy も同様です。委任情報の受け渡しも役に立ちません。移行できるのは署名権限だけであり、ネットワークアクセスは移行できないためです。再試行、トンネル、プロキシは行わないでください。プロジェクトを準備し、ユーザーが実際のターミナルで実行するスクリプトを 1 つ渡してください。以下の「ネットワークに接続できない CLI ホスト」を参照してください。

判断に迷う場合は、リンクする前に確認してください。CLI シェルから curl -sI https://<console-origin> が失敗する（または DNS が解決されない）場合は、ネットワークに接続できないケースです。

サンドボックスの 127.0.0.1 URL を、ユーザーがブラウザーで開けるものとして決して提示しないでください。ユーザーのマシンからはアクセスできません。また、icp identity link web にヘッドレスフラグがあると決して作り上げないでください。icp-cli 1.0.2 にはありません（icp identity link web --help で確認してください）。

委任の引き継ぎ（CLI ホストとブラウザーが異なるマシンにある場合）

icp identity delegation は、ユーザーのマシンでリンクされた ID から CLI ホストのセッションキーへ署名権限を移します。ブラウザーが CLI ホストに接続する必要はありません。ユーザーのマシンにも icp がインストールされている必要があり、icp-cli 1.0.x で利用できます。両方のマシンで icp identity delegation --help を実行して確認してください。ユーザーのマシンに icp があり、そこでコマンドを実行できる場合は、代わりにそこでこのスキル全体を実行するのが最も簡単です。それ以外の場合は、次の手順を行います。

CLI ホスト（サンドボックス）で — 新しいセッションキーを使って、保留中の ID を作成します。
```
icp identity delegation request <your-identity-name>
```
セッションの公開鍵が PEM 形式で標準出力に表示されます。この PEM ブロックをユーザーに渡してください。デフォルトの --storage keyring がヘッドレスのサンドボックスで失敗する場合は、--storage plaintext で再試行してください。
ユーザーのマシンで — まだリンクされていない場合はユーザーがそこでリンクします（icp identity link web <local-name> --auth <console-origin> — 通常のフローはローカルで動作します）。PEM をファイルに保存し、それを使って委任に署名します。
```
icp identity delegation sign --identity <local-name> --key-pem session-key.pem --duration 8h > delegation.json
```
--duration には、たとえば 30m、8h、1d を指定します。必要に応じて --canisters <ids> で委任先を制限できます。ユーザーから delegation.json を返してもらってください。sign が delegation for identity <name> has expired or will expire within 5 minutes で失敗する場合、ローカルの Web セッションが期限切れです。icp identity reauth <local-name> を実行し（通常のブラウザーフローで、ローカルで動作します）、再試行してください。

CLI ホストで — 保留中の ID を完成させて有効化します。

icp identity delegation use <your-identity-name> --from-json delegation.json
icp identity default <your-identity-name>
icp identity principal   # must print the user's console principal

delegation.json は有効期限付きの認証情報として扱ってください。サンドボックスのセッションキーを持つ人は誰でも、期限が切れるまでユーザーのコンソールプリンシパルとして署名できます。有効期間は短く設定し、期限が切れたら引き継ぎを再実行してください。

ネットワークに接続できない CLI ホスト — ユーザーにスクリプトを 1 つ渡す

CLI シェルからネットワークに接続できない場合、デプロイマシンとなるのはユーザーの実際のターミナルです。ユーザーのターミナルとブラウザーはループバックを共有するため、通常のリンクフローが動作し、委任の引き継ぎは不要です。作業は事前準備に切り替わります。

ビルド済みのプロジェクトを、ユーザーのターミナルからアクセスできるディレクトリに配置します。
プロジェクトのルートに、ネットワークが必要な一連の手順をすべて実行するスクリプトを 1 つ作成します。このテンプレートを適宜変更してください（実際の ID 名、コンソールのオリジン、サブネット ID を入力し、プレースホルダーを残さないでください）。
```
#!/usr/bin/env bash
set -euo pipefail
icp --version
icp identity list | grep -E '^\*? *<your-identity-name> ' >/dev/null || icp identity link web <your-identity-name> --auth <console-origin>
icp identity default <your-identity-name>
icp deploy -e ic --subnet <subnet-id>
```
ユーザーにターミナルで実行してもらい、ブラウザーが開いたら Internet Identity へのサインインを完了し、出力を貼り付けてもらいます。
貼り付けられた出力（キャニスター ID、フロントエンド URL）を確認して続行します。ステップ 2 の __META_* 変数を設定する再デプロイも、同じスクリプトで実行します。

通常のリンク手順（CLI とブラウザーでループバックを共有）

まず、すでに存在するものを確認します。

icp identity list      # names + principals; * marks the active identity

一覧には、ID がどのコンソール（ある場合）に対してリンクされたかは表示されません。CLI からは確認できません。次のように判断してください。

anonymous（または通常のローカル ID）のみが一覧にある — Web にリンクされた ID は存在しません。以下のリンクコマンドを実行します。
ユーザーが自分のエンジン ID と認識している ID（名前またはプリンシパルで判断） — それをアクティブに設定し（以下を参照）、ステップ 2 に進みます。
不明な場合 — ユーザーに確認するか、新しい名前で再リンクします。再リンクは簡単で安全です。

リンクするには、ユーザーが選んだ名前に置き換えて次を実行します。<your-identity-name> は任意のローカルラベルであり、固定値ではありません（my-engine-admin のような名前をハードコードしないでください）。以下のすべてのコマンドで同じ名前を使います。

icp identity link web <your-identity-name> --auth <console-origin>

ユーザーが別のコンソールを指定していない限り、<console-origin> には https://opencloud.org を使用します。--auth は省略しないでください。このフラグには組み込みのデフォルト値（https://id.ai）がありますが、これは使用するコンソールではなく、誤ったプリンシパルが気付かれないまま導出されます。
コマンドは、処理を開始する前に 「Press Enter to log in」 プロンプトで待機します。可能であれば対話形式で実行してください。非対話型シェル（バックグラウンドプロセスなど）では、実際の改行をパイプで渡します。
```
printf '\n' | icp identity link web <your-identity-name> --auth <console-origin>
```
stdin を /dev/null にリダイレクトしないでください。単なる EOF ではプロンプトを通過できず、ブラウザーも開かないまま、コマンドは「Press Enter to log in」で無期限に停止します。
Enter キーを押すと、ブラウザーのタブが開きます。ユーザーがそこで Internet Identity のサインインを完了します。ユーザーが完了したと確認するまで待ってから続行してください。代わりにサインインを完了することはできません。
--auth にはコンソールのオリジン（スキーム + ホスト）を正確に指定する必要があります（例：https://opencloud.org）。オリジンが一致しないと、異なるプリンシパルが導出され、エンジンはデプロイを未承認として拒否します。
これはマシンごとに一度だけ行う手順です。

次に、これをアクティブな ID に設定して確認します。

icp identity default <your-identity-name>
icp identity default     # prints the active identity name
icp identity principal   # prints the principal the deploy will sign as

ステップ 2 — コンソールでアプリ名を設定する（アイコンも設定できます）（推奨）

デフォルトでは、CLI でデプロイしたキャニスターは、エンジンコンソールの「アプリケーション」ページに、プリンシパル ID だけが表示された行として並びます。キャニスター環境変数を設定すると、コンソールでキャニスターが名前付きの単一アプリケーションにグループ化され、キャニスターごとのラベル、「開く」ボタン、アイコンが表示されます。プロジェクト設定で一度設定してください。

__META_PROJECT — アプリケーション名です。同じ値を共有するキャニスターは、名前付きの単一アプリにグループ化されます。そのため、アプリに属するすべてのキャニスターに同じ値を設定してください。
__META_NAME — キャニスターごとの表示ラベルです（例：Backend、Frontend）。
__META_MAIN_CANISTER — ちょうど 1 つのキャニスター（エントリーポイント。通常はフロントエンド／アセットキャニスター）に設定する文字列リテラル "true" です。これにより、アプリのメインキャニスターが指定されます。コンソールはこのキャニスターからのみ __META_BASE_URL と __META_ICON_PATH を読み取り、「開く」ボタンもこのキャニスターを対象にします。
__META_BASE_URL — メインキャニスターに設定する絶対 https:// URLです（例：フロントエンドキャニスターの URL https://<frontend-canister-id>.icp.net、またはカスタムドメイン）。この値が存在し、有効な場合、「開く」ボタンを押すとその URL が開きます。値がない場合、または https でない場合、「開く」ボタンはメインキャニスターのゲートウェイ URL にフォールバックします。また、__META_ICON_PATH の解決にもこの URL がベースとして使われます。
__META_ICON_PATH — アプリのアイコンへのパスです。__META_BASE_URL をベースに解決され、コンソールに表示されるアイコンの URL になります（例：/favicon.svg → https://<base>/favicon.svg）。__META_BASE_URL と併せて、メインキャニスターに設定してください。

アイコンと「開く」リンクは、__META_MAIN_CANISTER: "true" として指定されたメインキャニスターからのみ読み取られます。他のキャニスターに設定された __META_BASE_URL／__META_ICON_PATH は無視されます。

各キャニスターの settings.environment_variables に設定してください。これはレシピと併用できます。キャニスターごとの canister.yaml ファイルを使う場合：

# frontend/canister.yaml
name: frontend
recipe:
  type: "@dfinity/[email protected]"
  configuration:
    build:
      - npm install
      - npm run build
    dir: dist
settings:
  environment_variables:
    __META_PROJECT: "My App"
    __META_NAME: "Frontend"
    __META_MAIN_CANISTER: "true"
    __META_BASE_URL: "https://<frontend-canister-id>.icp.net"
    __META_ICON_PATH: "/favicon.svg"

# backend/canister.yaml
name: backend
recipe:
  type: "@dfinity/[email protected]"   # v5 reads main/candid from mops.toml ([canisters.backend]) — see the icp-cli skill
settings:
  environment_variables:
    __META_PROJECT: "My App"
    __META_NAME: "Backend"

単一のインライン icp.yaml（キャニスターをその中に直接定義する場合）では、各キャニスターのエントリーの下に同じ settings.environment_variables ブロックを記述してください。インライン形式では、canisters はキャニスター名をキーとするマップではなく、{name, recipe, settings} 項目の配列であることに注意してください。

# icp.yaml — canisters defined inline
canisters:
  - name: frontend
    recipe: # … as in the canister.yaml example above
    settings:
      environment_variables:
        __META_PROJECT: "My App"
        __META_NAME: "Frontend"
        __META_MAIN_CANISTER: "true"
        __META_BASE_URL: "https://<frontend-canister-id>.icp.net"
        __META_ICON_PATH: "/favicon.svg"
  - name: backend
    recipe: # … as in the canister.yaml example above
    settings:
      environment_variables:
        __META_PROJECT: "My App"
        __META_NAME: "Backend"

注：

icp-cli は、デプロイ時に自動で注入する PUBLIC_CANISTER_ID:<name> 変数と、これらの値をマージします。アセットキャニスターは引き続きコンテンツを配信し、アプリも引き続き動作します。（icp-cli 0.3.0 で検証済みです。）
すべての値は文字列です。__META_MAIN_CANISTER には文字列 "true" を正確に設定する必要があります。
これらは icp deploy の実行中（「環境変数を設定」ステップ）に適用されます。デプロイ後、icp canister settings show <name> -e ic で確認してください。

アイコンに関する詳細（コンソールは __META_BASE_URL + __META_ICON_PATH でアイコンを構成します）：

アイコンを表示するには、両方の値が存在し、メインキャニスターに設定されている必要があります。フォールバックはありません。__META_ICON_PATH だけを設定しても何も起こりません。
__META_BASE_URL は絶対 https:// URL として解析できる必要があります。ホスト名だけの値、http:// URL、data:／javascript: の値は拒否されます。その場合、アイコンは表示されず、「開く」ボタンはメインキャニスターのゲートウェイ URL にフォールバックします（ボタンが消えるわけではありません）。（コンソールは使用前にスキームを検証します。）
__META_ICON_PATH は、フロントエンドが実際に配信するアセットへのパス（例：/favicon.svg）であり、インライン画像ではありません。解決後の URL は <img> の src として表示されるため、画像を返す必要があります。ここに data: URI を設定しないでください。エンジン環境変数の値には長さ制限があり（確認できた上限は ≤128 文字）、収まらないうえ、このフィールドはパスとして設計されています。
フロントエンドキャニスターの ID は、初回デプロイ後に判明します。一般的な手順は、まずデプロイし、出力からフロントエンドキャニスターの ID を確認してから、__META_BASE_URL に https://<that-id>.icp.net を設定し（__META_ICON_PATH も設定します）、再デプロイして適用することです。アプリのカスタムドメインを管理している場合は、最初からそのドメインを設定できます。

アプリでユーザーのサインインを行う場合は、Internet Identity の導出元を固定してください

Internet Identity は、オリジンごとにプリンシパルを導出します。カナスタアドレスとカスタムドメインの両方からアクセスできるアプリでは、同じ人がサインインしても、別々のユーザーとして扱われます。

エンジンコンソールでは、導出元としてアプリのカナスタアドレスが表示されます。このアドレスは変更も削除もできないため、カスタムドメインの追加、変更、削除後もそのまま使えます。これは、フロントエンドを配信するカナスタ（ブラウザーがアプリを読み込むアセット／静的サイトカナスタ）のアドレスで、次のようにそのカナスタの ID から作成されます。

https://<frontend-canister-id>.icp.net

通常は __META_MAIN_CANISTER: "true" に設定したカナスタですが、このフラグはコンソール上の表示設定であり、保証ではありません。バックエンドカナスタを指定した場合でも、フロントエンドカナスタから導出してください。バックエンドカナスタを導出元にすることはできません。ブラウザーがそのカナスタ上にいることはなく、Internet Identity が導出元から取得して申告内容を検証する .well-known/ii-alternative-origins ファイルを配信できないためです。

値は __META_BASE_URL ではなく、カナスタ ID から作成してください。2 つの値が一致するのは、__META_BASE_URL がカナスタアドレスを指している間だけです。カスタムドメインを指すように設定することは一般的で、サポートされています（上記のアイコンに関する注記を参照）。その場合、2 つの値は異なります。カスタムドメインだけは、導出元にしてはいけません。

アプリにユーザーがいる状態になってからではなく、その前に設定してください。 すでにサインインに使われているドメインでは、導出元を変更すると、そのドメインで作成されたすべてのアカウントが孤立してしまいます。アプリで将来カスタムドメインを使う可能性がある場合は、カナスタアドレスだけがオリジンである初回デプロイ時に derivationOrigin を設定してください。その時点ではコストがかからず、アカウントを失わずに後から適用することはできないためです。

設定方法（derivationOrigin オプションと .well-known/ii-alternative-origins ファイル、および @dfinity/static-site のレシピで必要な _headers のエントリー）については、internet-identity スキルを読み込んでください。

Caffeine アプリは例外です。アドレスは Caffeine が所有しているため、アプリの導出元にはできません。コンソールでは、これらのアプリのカナスタアドレス行は表示されません。

バージョンメタデータ（推奨）

各カニスターの wasm にビルドの出自情報を埋め込み、ツールやコンソールで実行中のバージョンを表示できるようにします（コンソールでの対応は順次展開中ですが、メタデータはすでに読み取り可能です。以下の確認に関する注記を参照してください）。すべてのデプロイでデフォルトで追加してください。ユーザーからの依頼を待たないでください。すべての公式レシピ（motoko、rust、static-site、asset-canister、prebuilt）は、レシピの configuration の下に metadata リストを受け付けます。各エントリはカスタムセクションとして wasm に組み込まれます。値はビルド時にシェルコマンドへ展開されるため、$(…) によるコマンド置換が機能します。（icp-cli 1.0.2 上で @dfinity/motoko v4.1.0 および v5.0.0 を使ったライブビルドで確認済みです。）

Git プロジェクト（最初に確認してください：git rev-parse HEAD が成功すること）：

recipe:
  type: "@dfinity/[email protected]"
  configuration:
    metadata:
      - name: service:git:sha
        value: $(git rev-parse HEAD)$(git diff --quiet HEAD 2>/dev/null || echo +dirty)
      - name: service:git:origin
        value: $(git remote get-url origin)
      - name: service:git:updated_at
        value: $(git log -1 --format=%cI)
      - name: service:version
        value: $(node -p "require('./package.json').version" 2>/dev/null || echo 1.0.0)

非 Git プロジェクト — 上記の Git 置換でビルドが失敗することはありませんが、不正な値がそのまま組み込まれます（service:git:sha は文字列 +dirty になり、service:git:origin は空になります）。明示的なバージョンのみを使い、その後のデプロイごとに更新してください：

metadata:
  - name: service:version
    value: "1.0.0"

注：

これらの正確な名前（service:git:sha、service:git:origin、service:git:updated_at、service:version）を使用してください。これらはコンソールが読み取る合意済みの規約です。異なる名前のエントリは検出されません。
可能な場合はリテラルよりもコマンドの実行結果を優先してください。sha の +dirty は未コミットの変更を示すため、デプロイをソースの正確な状態まで追跡できます。
値は、同じソースツリーに対して決定的でなければなりません。sha、origin、最後のコミットの日付、バージョン文字列を使用してください。ビルド時刻（$(date)）や、ビルドのたびに変わるその他の値を埋め込まないでください。コミット日付（%cI）はビルドではなくコミットの属性なので使用できます。ただし、これは「最後にコードが変更された日時」を意味し、「最後にデプロイされた日時」ではない点に注意してください。古いコミットをデプロイすると、古い日付が表示されます。デプロイ時刻自体は、ネットワークが自動的に記録するカニスターの履歴から取得できます。
プロジェクトに package.json がない場合（またはバージョンフィールドがない場合）は、フォールバックとして 1.0.0 が適用されます。プロジェクトの実際のバージョン管理方式がある場合は、それに置き換えてください。
セクションは icp:private として挿入されます。カニスターのコントローラー（あなた、およびあなたの代わりに動作するコンソール）は、カニスターを呼び出さずに read_state 経由で読み取れます。デプロイ後、リンクされた ID を有効にして、icp canister metadata <canister-name> service:git:sha -e ic で確認してください。

ステップ 3 — エンジンのサブネットにデプロイする

プロジェクトのルートから実行します：

icp deploy -e ic --subnet <subnet-id>

-e ic はメインネット（エンジンは IC サブネット上で動作します）を対象にします。--subnet <subnet-id> を指定すると、エンジンのサブネットにデプロイが固定されます。確信がない場合は、実行前に icp deploy --help で正確なフラグを確認してください。
デプロイするとエンジンの容量を消費します。エンジンに空きがあることを確認してください。

代替手段：パッケージをアップロードする。 プロジェクトがビルド済みの .icp パッケージとして配布されており、直接 icp deploy を実行できない場合、ユーザーは代わりにバンドルをアップロードできます。エンジン → アプリケーション → アプリをビルドしてデプロイの順に選択すると、エンジンの選択と .icp バンドルのアップロードが案内されます。同じメニューの「デプロイのその他の方法」には、既製アプリ向けの App Store と、このスキルが自動化する CLI の手順もあります。

ステップ 4 — 確認する

icp deploy の出力に、デプロイされたカニスター ID が表示されます。
カニスターはコンソールのエンジンのアプリケーションページに表示されます。各カニスターの詳細画面には「ブラウザーで開く」リンクがあります。
ステップ 2 でメタデータを設定した場合、カニスターは __META_PROJECT の名前の下に、__META_NAME のラベルとともにグループ化されます。また、メインカニスターには「開く」ボタンが表示され、プリンシパルの行だけが並ぶ状態ではなくなります。__META_BASE_URL と __META_ICON_PATH を設定すると、アプリのアイコンも表示されます（コンソールのキャッシュが更新されるまで少し時間がかかる場合があります）。
フロントエンド（アセット）カニスターは https://<frontend-canister-id>.icp.net で提供されます。

デプロイされたカニスター ID（および該当する場合はフロントエンド URL）をユーザーに報告してください。

ステップ 5：プロキシカナスターをデプロイする（アプリがチェーンキーサービスを必要とする場合のみ）

アプリがしきい値 ECDSA または Schnorr（Bitcoin、Ethereum）、vetKD / VetKeys、為替レートカナスター（XRC）、Bitcoin API、または EVM / SOL RPC カナスターを呼び出す場合を除き、このステップはスキップしてください。コンソールプロキシは、エンジンのカナスターに対してそれ以外のものは中継しません（正確な一覧は cloud-engine-canisters にあります）。それ以外のすべて（アプリ独自の実行、ストレージ、メッセージング、HTTPS アウトコール）はエンジン上で無料で、プロキシは一切不要です。

これらのサービスは別のサブネット上にあり、呼び出しごとにサイクルを消費します。また、エンジンカナスターはサイクルを保持できず、サイクルを含むメッセージをエンジンの境界を越えて送信することもできません。通常のアプリケーションサブネット上にあるプロキシカナスターが、エンジンに代わって呼び出しを行い、自身の残高から支払います。

このようなアプリを作成またはデプロイする予定で、まだプロキシ ID がない場合は、プレースホルダーのままデプロイするのではなく、今のうちに依頼してください（「必要なもの」の項目 3）。最初のプロキシ経由の呼び出しが失敗します。

プロキシの選択

この役割を担えるカナスターは 2 種類あり、誤った方を選ぶと、一見正常に見える設定でも最初の呼び出しで失敗します。

	コンソールプロキシ	自分でデプロイするプロキシ
デプロイする人	コンソールからエンジンの所有者	`icp` を使って、あなたがデプロイ
呼び出しを許可される主体	エンジンのカナスター ID 範囲とコントローラー	コントローラーのみ
エンジンカナスターからの呼び出し	はい、自動的に可能	各カナスターをコントローラーに追加した後にのみ可能
中継するサービス	チェーンキー、Bitcoin、為替レート / RPC サービスのみ（一覧は `cloud-engine-canisters`）	あらゆるサービス
CLI ID からの呼び出し	不可（`UnauthorizedUser` として拒否）	はい：あなたはコントローラーです
しきい値鍵の導出	呼び出し元のカナスターごとに分離	分離なし
資金の拠出元	エンジンの残高から自動的に拠出（カード不要）	あなたが保有するサイクル（`icp cycles mint`）

アプリのコードからチェーンキーサービスを呼び出す場合 → コンソールプロキシ。 個別のカナスターごとの設定なしで、エンジンのカナスターを許可するのはこちらです。
CLI から何かを呼び出す場合（icp canister call --proxy、icp deploy --proxy、canister_info や raw_rand などのカナスター専用管理メソッド）→ 自分のプロキシ。 コンソールプロキシでは対応できません。コントローラーではないプリンシパルからの ingress は拒否され、CLI ID はその一つではないためです。

両者は互換ではなく、異なる鍵を導出します。一方からもう一方にアプリを切り替える前に、cloud-engine-canisters の鍵導出に関する注意を確認してください。

コンソールプロキシ：エンジンの所有者がデプロイします（CLI ではなく、コンソールでの操作です）

デプロイできるのはエンジンの所有者だけで、コンソールからのみです。icp コマンドはなく、エージェントが呼び出して作成できるものもありません。ボタンの背後にあるコンソールのエンドポイントは、Internet Identity へのログインで発行されるブラウザーのセッション Cookie で認証されます。ユーザーに以下の手順を案内し、プロキシの Canister ID が届くまで待ちます。

コンソールでエンジンを開き、エンジンのサイドバーにある Canisters を選択します（デプロイ済みアプリが表示される Applications ではありません）。次に、Proxy canisters セクションを開きます。
Deploy a proxy を選択し、ダイアログで Deploy proxy を選択します。金額を選ぶ必要はなく、カードへの請求もありません。プロキシは通常の Application サブネット上に作成され、エンジンの残高から数ドル相当のサイクルを受け取って稼働を開始します。
テーブルからプロキシの Canister ID をコピーします。その行には Engine balance バッジが表示されます。この ID をアプリから呼び出します。

エンジンが稼働中でない場合、またはエンジンの残高にプロキシの初期サイクルを賄うための余裕がない場合、デプロイは拒否されます。その場合、所有者がエンジンに資金を追加してから再試行します。

資金の補充方法。 残高が低いしきい値を下回っている間、プロキシは数分ごとにトップアップを要求し、エンジンの残高から送金されます。1 時間あたりの上限があり、エンジンがノードに支払うべき金額は使われません。Top up ボタンも自動トップアップの設定もありません。行には残高と、これまでに引き出したサイクル数が表示されます。それでも残高が尽きた場合は、エンジンに資金を追加します（下記の「エンジンへの支払い」を参照してください）。

このテーブルには、Refresh balance（表示される数値はキャッシュされているため、最新の残高を読み込みます）と Delete proxy（Canister を停止して削除します。未使用のサイクルは、Canister の稼働用に確保される少額の予備分を差し引いて、エンジンの残高に戻されます）もあります。

エンジン負担のプロキシが導入される前にデプロイされたプロキシはカード払いです。その場合は代わりに Top up（今すぐカードに請求）と Automatic top-up（残高が少なくなったときにカードに請求）が表示され、削除すると残高が支払い方法に返金されます。

エンジンには、複数のプロキシを持たせることができます（「Deploy another proxy」）。それぞれ独自の残高（すべて同じエンジン残高から補充）を持ち、署名アプリの場合は独自のキー名前空間を持ちます。

アプリにプロキシ ID を設定する

アプリは実行時に ID を必要とします。ソースコードにハードコードするのではなく、Canister の環境変数として渡してください。こうすれば、同じコードをローカルのモックとエンジンの両方に対して実行できます。

settings:
  environment_variables:
    PROXY_CANISTER_ID: "<proxy-canister-id>"

他の環境変数と同じ方法で Canister 内から読み込み、永続的な設定として扱ってください。しきい値キーを導出するアプリでは、この値を変更すると、アプリが所有するすべてのアドレスが変わります。

自分でデプロイするプロキシ：CLI を使う方法

自分自身の呼び出しをプロキシする場合に使います。これは上流の dfinity/proxy-canister で、テンプレートからデプロイします。

icp new my-proxy --subfolder proxy       # pre-built wasm, no init args
cd my-proxy
icp deploy -e ic                         # NOT --subnet <engine-subnet>: see below
export PROXY_ID=$(icp canister status -e ic --id-only proxy)

サイクル台帳を使って資金を補充し、状態を確認します。

icp cycles balance -e ic                 # what you hold
icp cycles mint --icp 1 -e ic            # ICP -> cycles, if you need more
icp canister top-up "$PROXY_ID" --amount 5t -e ic
icp canister status "$PROXY_ID" -e ic    # the proxy's own balance

次に、サイクルまたは Canister 専用の管理メソッドが必要なコマンドに渡します。

icp canister call my-canister charge_me '()' -e ic --proxy "$PROXY_ID" --cycles 1_000_000_000_000
icp deploy -e ic --proxy "$PROXY_ID"

正しく設定するためのポイントは 3 つあります。

エンジンのサブネットにはデプロイしないでください。 CloudEngine サブネット上のプロキシは役に立ちません。サイクルを 0 しか持たず、サイクルを伴うメッセージも送信できません。--subnet を省略してください（手順 3 のエンジンのサブネットを指定するフラグは、アプリ用であり、この用途には使いません）。そうすれば通常の Application サブネットにデプロイされます。
コントローラーのみを認可します。 エンジン Canister から呼び出すには、その Canister のプリンシパルをコントローラーとして追加する必要があります（icp canister settings update "$PROXY_ID" --add-controller <canister-id> -e ic）。Canister ごとに 1 回実行し、Canister を追加するたびに繰り返します。これが、コンソールプロキシによって解消される保守作業です。
キー導出は分離されません。 認可された呼び出し元は、任意の導出パスを要求でき、生成されるキーはコンソールプロキシのものとは異なります。署名アプリの接続先として、安易に指定しないでください。

エンジンの料金を支払う：どちらの残高か

残高は2種類あり、補充方法も異なります。また、アプリ独自のキャニスターにはどちらの残高もありません。どちらの残高を指すのか確認せずに、エンジン上で「キャニスターにチャージ」しないでください。

残高	支払い対象	補充方法	残高がなくなった場合
エンジン残高	エンジン自体（ノードの日々の料金）と、コンソールプロキシへのチャージ	エンジンのBillingページにあるAdd funds（登録済みカードに請求）と、残高がなくなる約1週間前にカードへ請求する自動チャージ	エンジン上のすべてのものとともに、エンジンが削除されます。元に戻せないため、残高の残り期間が少ないという警告は緊急のものとして扱ってください。自動チャージに繰り返し失敗するエンジンは停止され、支払いが完了すると再び動作します
プロキシのサイクル残高	プロキシが中継する呼び出しのみ（署名、vetKD、XRC、Bitcoin API、EVM/SOL RPC）	コンソールプロキシはエンジン残高から自動で補充します（ステップ5）。以前のカード払いのものにはTop upとAutomatic top-upがあります。自分でデプロイしたものは`icp canister top-up`を実行します	中継された呼び出しは`InsufficientCycles`で失敗します。プロキシは削除されずにフリーズし、後でチャージすると復旧します

コンソールプロキシへのチャージはエンジン残高から差し引かれるため、プロキシの利用が多いとエンジンの稼働可能期間が短くなります。ただし、エンジンのノード料金には影響しません。

アプリ独自のキャニスターには、これらの残高はどちらもありません。設計上、サイクルを0個保持し、チャージすることもできません。エンジンのキャニスターで「0 cycles」と表示されるのは正常です（cloud-engine-canistersの落とし穴5を参照）。

エンジン上で実行されるコード

クラウドエンジンは**CloudEngineサブネット上で実行されます。このサブネットには、通常のApplicationサブネットとは異なるプロトコルレベルの呼び出しルールがあります。エンジンのキャニスターが保持するサイクルは0であり、呼び出しにサイクルを絶対に付与してはいけません**。サブネットをまたぐ呼び出しには、バウンド付き待機を使用する必要があります。HTTPSアウトコールは直接実行され、無料です。また、サイクルを必要とするサブネット間の呼び出し先（為替レートのXRC、しきい値ECDSA/Schnorr、vetKD）には、資金が補充されたエンジンのコンソールプロキシキャニスターを経由してアクセスします。エンジン上で実行するキャニスターコードを作成またはデバッグする前に、**cloud-engine-canisters**スキルを読み込んでください。ルール、プロキシのインターフェース、落とし穴が記載されています。

よくある落とし穴

サインインが完了していない。 icp identity link web … を実行しても、ブラウザーで Internet Identity のサインインを完了しないと、CLI はリンクされず、後続のコマンドは認証エラーで失敗します。もう一度実行し、ブラウザーフローが完了したことをユーザーが確認するまで待ってください。ブラウザーが一度も開かなかった場合、コマンドは「Press Enter to log in」プロンプトで停止しています。改行をパイプで渡して再実行してください。printf '\n' | icp identity link web … のようにします。< /dev/null は使わないでください（ステップ 1 を参照）。CLI がリモートサンドボックスで実行されている場合、再実行しても完了できません。落とし穴 10 とステップ 1.0 の委任の引き継ぎを参照してください。
--auth のオリジンが間違っている。 ユーザーがサインインするコンソールのオリジン以外の URL を使うと、別のプリンシパルが導出され、エンジンはデプロイを未認証として拒否します。正確なコンソール URL で再リンクしてください。デフォルトの https://opencloud.org に対してリンクした後、デプロイが未認証として拒否された場合は、ユーザーに実際にサインインする正確な URL を確認して再リンクしてください。
サブネット ID を推測する。 決してでっち上げないでください。デプロイに失敗するか、間違ったサブネットが対象になります。コンソールのエンジンの Settings ページにあるため、ユーザーに確認してください。
匿名 ID でデプロイする。 デフォルトのローカル ID は匿名であり、エンジン管理者ではありません。まずリンクし、icp identity default <your-identity-name> を実行する必要があります。
dfx を使う。 このエコシステムで使うのは icp であり、dfx ではありません。正しい順序は、icp identity link web <name> --auth <console-origin>（ステップ 1）、続いて icp deploy -e ic --subnet <subnet-id>（ステップ 3）です。icp-cli スキルを参照してください。
アプリのメタデータを省略する。 __META_PROJECT（ステップ 2）がない場合もカニスターはデプロイされ、動作しますが、コンソールでは名前のないプリンシパルの行として表示されます。名前付きアプリと、ラベル付きカニスター、「Open」ボタンを表示するには、__META_* を設定します。
__META_MAIN_CANISTER の値が間違っている。 値は文字列 "true" と完全一致する必要があります。ブール値や "True" を指定した場合、または複数のカニスターに設定した場合、「Open」ボタンが表示されないか、間違ったボタンが表示されます。エントリーポイントとなるカニスターを正確に 1 つ指定してください。
アイコン用の変数をでっち上げる。 アイコンの変数は __META_ICON_PATH です（__META_BASE_URL を基準に解決されるパスです）。__META_ICON、__META_LOGO、__META_ICON_LINK を推測して使わないでください。これらは無視されるため、アイコンは何も表示されません。
アイコンを間違ったカニスターに設定する、またはベース URL を指定しない。 アイコンはメインカニスターからのみ読み込まれ、__META_BASE_URL（有効な絶対 https:// URL）と __META_ICON_PATH の両方が必要です。サイドカニスターにアイコンパスを設定する、ベース URL を省略する、または https 以外や data: のベース URL を指定すると、アイコンは表示されません（「Open」ボタンは引き続き機能します。不適切なベース URL の場合、メインカニスターのゲートウェイ URL が使用されるため、失われるのはアイコンとカスタムの Open URL であり、ボタンではありません）。
ブラウザーと CLI が localhost を共有していると思い込む。 icp identity link web は、CLI ホスト上の 127.0.0.1:<port> に委任を返します。CLI がリモートサンドボックスで実行され、ユーザーのブラウザーが別のマシンにある場合、サインインは完了せず、後続のコマンドは認証エラーで失敗します。リンクを何度再実行しても解決しません。ステップ 1.0 を参照してください。ブラウザーと CLI がループバックを共有するローカルセッションを優先し、ユーザーにローカルで実行する選択肢がない場合に限り、委任の引き継ぎ（icp identity delegation request / sign / use）を使ってください。サンドボックスで作業を始める前にユーザーへ確認してください。始めた後ではいけません。
委任の引き継ぎでネットワーク接続の欠如が解消されると思い込む。 引き継がれるのは署名権限であり、接続性ではありません。icp deploy には、実行するシェルからネットワークに接続できる必要があります。CLI シェルがネットワークにまったく接続できない（DNS がブロックされ、HTTPS に失敗するサンドボックス化されたデバイスブリッジ）場合、リンクもデプロイも含め、そこで icp のネットワークコマンドは実行できません。そのシェルから「残りをこちらで実行する」と申し出たり、トンネルを使ったりしないでください。ユーザーの実際のターミナルで実行するスクリプトを 1 つ渡してください（ステップ 1.0 の「ネットワークに接続できない CLI ホスト」を参照）。通常のリンクフローが機能するのは、ターミナルとブラウザーがループバックを共有しているためです。
wasm メタデータにビルド時刻を含める。 メタデータは wasm に埋め込まれるため、決定的でなければなりません。ビルド時刻（$(date)）を使うと、ソースが同じでもビルドのたびに値が変わり、再現性が損なわれ、デプロイごとにモジュールハッシュが変わります。決定的な代替方法は、最後のコミットの日付 service:git:updated_at = $(git log -1 --format=%cI) です。これはビルドではなく、ソースツリーの属性です。デプロイ時刻そのものは、メタデータではなく、ネットワークが記録するカニスター履歴から取得されます。
Git リポジトリ以外のプロジェクトで Git メタデータの置換を行う。 Git リポジトリの外では、$(git rev-parse HEAD) はビルドを失敗させず、誤った値を何も通知せずに埋め込みます。service:git:sha は文字列 +dirty になり、service:git:origin は空になります。最初に Git リポジトリかどうかを確認してください（git rev-parse HEAD が成功すること）。リポジトリがない場合は、service:version のみを明示的な値で設定してください（バージョン管理も必要であれば、デプロイ前に git init してコミットしてください）。
派生オリジンを固定する前に、エンジンアプリでサインインを受け付ける。 Internet Identity のプリンシパルはオリジンごとに異なるため、後からカスタムドメインを追加すると、新しいアドレスでは既存ユーザー全員が見知らぬユーザーになります。すでに古いオリジンで作られたアカウントを孤立させずに、この問題を遡って修正することはできません。II を使うアプリを最初にデプロイするときは、現時点でアプリのオリジンがそれだけの場合でも、フロントエンドを提供するカニスターのアドレスを derivationOrigin に設定してください。カニスター ID から、https://<frontend-canister-id>.icp.net のように組み立てます。__META_BASE_URL をコピーしないでください。これはカスタムドメインを指定できますが、カスタムドメインを派生オリジンにしてはいけません。.well-known/ii-alternative-origins 側の設定については、internet-identity スキルを参照してください。
CLI や API からコンソールプロキシをデプロイしたり、資金を追加したりしようとする。 これを行う icp コマンドはありません。また、ボタンの背後にあるコンソールのエンドポイントは、Internet Identity のログイン時に使われるブラウザーセッション Cookie で認証され、トークン認証には対応していないため、エージェントから操作することはできません。デプロイできるのはエンジンの所有者だけです。コンソールでの手順（エンジン → Canisters → Proxy canisters → Deploy a proxy）をユーザーに伝え、プロキシのカニスター ID が届くまで待ってください。エンジンの残高から支払われるため、資金の追加は不要です。エージェントがセルフデプロイプロキシの手順全体を無人で実行することはできますが、これは認証方法が異なる別のカニスターです（ステップ 5）。
セルフデプロイプロキシをエンジンのサブネットにデプロイする。 ステップ 3 の --subnet <engine-subnet-id> を再利用すると、プロキシは CloudEngine サブネットに配置されます。このサブネットではサイクルが 0 であり、サイクルを含むメッセージを送信できない場合もあるため、プロキシとしての唯一の役割を果たせません。--subnet を省略し、通常の Application サブネットに配置してください。
セルフデプロイプロキシがエンジンのカニスターからの呼び出しを受け付けると思い込む。 認証対象はコントローラーのみです。エンジンのカニスターから呼び出すと、そのカニスターのプリンシパルを icp canister settings update <proxy> --add-controller <canister-id> -e ic で追加するまで UnauthorizedUser になります。また、後から追加するカニスターごとにこの操作が必要です。コンソールプロキシはエンジンのカニスター ID 範囲全体を認証するため、アプリコードに適しています。
署名アプリが鍵の導出に使っているプロキシを削除する。 削除ボタンを押すと、未使用のサイクルがエンジンの残高に戻るため、整理に見えるかもしれません。しかし、そうではありません。しきい値鍵はプロキシ自身のプリンシパルから導出されるため、プロキシを削除する（またはアプリの接続先を別のプロキシに変更する）と、アプリが所有する Bitcoin/Ethereum のアドレスがすべて変わり、古いアドレスにある資金が取り残されます。アプリがすでに署名に使っているプロキシを変更する前に、導出ルールについて cloud-engine-canisters を参照してください。
残高を混同する。 「カニスターのサイクルが不足している」という状態は、それぞれで意味が異なります。エンジンのカニスターは設計上サイクルを 0 個保持し、追加できません。エンジンの残高が少なくなった場合は、Billing ページの Add funds で解決します。中継された呼び出しの InsufficientCycles は、プロキシの残高不足を意味します（エンジンの残高から補充されるコンソールプロキシの場合、これもエンジンへの資金追加を意味します）。何かに資金を追加する前に、どの残高かを特定してください。また、エンジンの残高が尽きるとエンジンは削除されます。
プロキシ ID がないまま、プロキシに依存するアプリをデプロイする。 署名、vetKeys の導出、為替レートの読み取り、Bitcoin API や EVM/SOL RPC の呼び出しを行うアプリは、プレースホルダー、推測した ID、または別のエンジンの ID を使ってもデプロイ自体は成功しますが、プロキシ経由の最初の呼び出しで失敗します（UnauthorizedUser が発生するか、他人のプロキシに属する鍵やアドレスが生成されます）。デプロイ前に ID を確認してください（「必要なもの」の項目 3）。エンジンにプロキシがない場合は、所有者がコンソールからデプロイします（ステップ 5）。代わりにセルフデプロイプロキシを使わないでください。

追加の参考情報

エンジン上で実行されるコードの呼び出しルールについては、cloud-engine-canisters を読み込んでください。サイクルを付加しないこと、サブネット間の呼び出しでは上限付き待機を使用すること、HTTPS アウトコールを直接行うこと、サイクルを伴うサブネット間の宛先（XRC、しきい値署名、vetKD）にはコンソールプロキシを使用することが記載されています。エンジンのカニスターコードを作成またはデバッグする前に読み込んでください。
icp.yaml、レシピ、環境、バインディング、ID など、icp CLI の一般的な使い方については、icp-cli を読み込んでください。このクラウドエンジンのデプロイフロー以外の内容を扱う場合、特にプロジェクトがまだビルドまたはパッケージ化できない場合に読み込んでください。
ステップ 1 でブラウザーから開始される Internet Identity のサインインについて詳しくは、internet-identity を読み込んでください。
vetKD の概要と、プロキシの準備後に VetKeys を使用する方法については、vetkeys を読み込んでください。呼び出しコードの宛先は通常のサブネットなので、エンジンで必要なプロキシ経由の形式については cloud-engine-canisters を参照してください。
通常の（エンジンではない）カニスターのサイクルについては、cycles-management を読み込んでください。残高、凍結しきい値、CMC 経由の ICP からサイクルへの変換が記載されています。

Markdown 対応

ログインしてコメント

基本情報

作者: dfinity
リポジトリ: dfinity/icskills
カテゴリ: クラウド・DevOps
インストール数: 178
GitHub スター: 39

問題を報告