Ledger がプレビュー公開した Ledger Agent Stack は、AI エージェントに残高確認やポートフォリオ分析、送金・スワップの「準備」まで任せる一方、秘密鍵はエージェントに渡さず、センシティブ操作は Ledger 署名デバイス上での人の確認を必須にする OSS ツール群です。設計の一言は公式が繰り返す次の境界です。
📑目次
Agents propose / Humans approve / Hardware enforces（エージェントは提案し、人が承認し、ハードウェアが強制する）
Claude Code / Codex / Cursor などシェル可能なエージェントから使えると案内されています。エージェントにウォレット操作を任せたい開発者にとって、発表サマリー以上に次の実務論点が重要です。
- 読み取りと署名をどう分けるか
- チーム手順に何を書くか
本記事は公式ブログと developers.ledger.com の AI tools ドキュメント、および独立報道を踏まえ、次を整理します。
- 4 プリミティブの役割と、用途ごとの採用境界
- Wallet CLI の試し方（まず読み取り専用から）
- 採用判断チェック（自律実行要件の有無を先に判定）
- 制限とリスク、および署名前に取るべき次の一手
Ledger Agent Stackが解く問題 — エージェントと価値移動の境界
最終権限をどこに置くか
結論から言うと、Agent Stack が解くのは「エージェントを便利にする」ことそのものではなく、価値が動く瞬間の最終権限をどこに置くかです。
エージェントは市場調査、口座分析、トランザクションの組み立てが得意です。一方で、プロンプトインジェクションや侵害されたエージェント、指示の誤解があると、ソフトウェア画面だけで最終承認が完結する設計では、最終権限がエージェント側の影響下に残りやすくなります。
Ledger 公式ブログは、ソフトウェアのみの agent wallet が UX は滑らかでも最終境界がアプリ内に残る点を問題視し、最終ゲートをハードウェア署名デバイスの信頼画面に置くと説明しています。
独立報道が補強する同じ骨格
独立報道も同じ骨格を補強しています。
- CoinDesk: 鍵をエージェントに渡さず、センシティブ操作をハードウェア上で人が明示承認するモデルとして Agent Stack を報じ、2026 年 AI ロードマップの第一弾という位置づけを示す
- The Block: ボットが残高読み取り・提案・準備までできても実行には物理デバイスでの人の署名が必要であること、および OpenPGP 等でエージェント資格情報を保護できるという周辺機能に触れる
読者への含意
読者への含意は単純です。エージェント導入を進めるなら、「分析・準備の自動化」と「送金・スワップの最終承認」を同じ権限面に置かない設計が必要です。
4プリミティブの役割分担（DMK Skills / Wallet CLI / Enterprise / Multisig）
公式が示す 4 プリミティブ
公式ブログは Agent Stack を次の 4 つのオープンソース・プリミティブとして紹介しています。docs 側では、さらに runtime の Wallet CLI と build-time の DMK skills という二系統に整理されています。
| プリミティブ | 主な利用者 | できること | 鍵・承認 |
|---|---|---|---|
| Device Management Kit Skills | アプリ開発者 | エージェントが DMK 統合コードを書くための Markdown スキル | デバイスが最終ゲート、HITL 前提 |
| Ledger Wallet CLI | 個人 / パワーユーザー | 残高・履歴・受取・送金/スワップ準備・earn | 読み取りはデバイス不要、署名は毎回オンデバイス |
| Ledger Enterprise CLI | 機関 / ガバナンス | トランザクション準備とガバナンス支援 | 鍵非保持、Enterprise ポリシー |
| Enterprise Multisig CLI | マルチシグ運用 | 提案・照会・署名・実行 | 定足数 + ハードウェア署名 |
出典：Ledger 公式ブログ、AI tools overview（2026年7月時点）
実務上の切り分け
実務上の切り分けは次のとおりです。
- Wallet CLI: 自分のアカウントをシェルやコーディングエージェントから操作する runtime ツール。
- DMK skills: アプリへ Device Management Kit を組み込むとき、コーディングエージェントが参照する Markdown スキル（intent 語彙 / 実装 5-step / ビジネス概念）。
- Enterprise / Multisig: 個人 Wallet CLI ではなく、機関ガバナンスや定足数付き署名フロー向け。
docs は両系統とも early development であり、破壊的変更があり得ると明記しています。プレビュー段階の採用では、API 固定を前提にしない方が安全です。
Wallet CLIの実務 — 読み取りと署名を分ける
Wallet CLI の価値は、コマンド面で 読み取り（デバイス不要） と 署名（毎回デバイス確認） が分離されている点にあります。
導入の最小セット
- パッケージ:
@ledgerhq/wallet-cliを global インストール（docs 表示例:wallet-cli v2.0.1） - エージェント skill:
npx skills add LedgerHQ/agent-skills -s wallet-cli-usage - 前提: macOS / Linux / Windows（WSL 推奨）、USB 接続の Ledger、対象アプリ（例: Ethereum）
- 確認:
wallet-cli --version、必要ならgenuine-check。通ったらまず読み取り専用コマンドだけ試し、署名系は後段へ回す
出典：Wallet CLI ドキュメント（2026年7月時点）
対応チェーンと操作の差分
| 操作 | Bitcoin | Ethereum (+EVM) | Solana |
|---|---|---|---|
| 残高 / operations / 送金・受取 / swap | ○ | ○ | ○ |
| token lookup | — | ERC-20 | SPL |
| earn | — | ERC-4626 vaults | native staking |
出典：Wallet CLI ドキュメント（2026年7月時点）
読み取りフロー（まずこれだけ試す）
wallet-cli account discover ethereum（ネットワークごとに一度）balances/operations/earn yields/earn positions- エージェントには「残高と直近履歴の分析のみ」を許可するプロンプトにし、送金・スワップ指示は読み取り成功を確認するまで入れない
読み取りコマンドはデバイスを触らないため、チームでもリスクを抑えつつ「エージェント + Ledger 連携が動くか」を確認できます。次の一手は、読み取りに限定する運用から小さく始め、安定してから send --dry-run とデバイス目視を手順書に書き、本番資産では署名を試さないことです。
署名フロー（必ず dry-run と目視）
送金・スワップ・earn の deposit/withdraw など署名系は、端末が内容を示したうえでデバイス画面確認が必要です。
- 手数料プレビュー:
send --dry-run - スワップ:
swap quote→swap execute→swap status（Exchange app で clear-sign） - AI が生成した宛先・金額・経路は誤り得るため、デバイス画面の値を人が独立検証する（CLI の注意事項）
公式が示す試用の型は次です。
- 読み取り: developers.ledger.com を調査し、Wallet CLI でポートフォリオ分析（ここで止めて接続と権限を検証する）
- 取引準備: 市場に基づくリバランス案 → 最少スワップ経路 → CLI で準備。実行は dry-run とデバイス画面の独立確認後に人が承認する
Key Ring（LKRP）
ring init 後、AES-256-GCM で encrypt/decrypt できる Key Ring は、エージェントが扱う秘密（API キー等）をソフトウェア平文のまま置かない用途として案内されています。ウォレット鍵そのものの代替ではなく、エージェント資格情報の保護レイヤとして位置づけてください。
Claude Code / Cursor からの導入チェックリスト
シェル可能なコーディングエージェントから始める場合の、実務向け手順です。
- Ledger を USB 接続し、対象アプリ（例: Ethereum）を開く
npx skills add ledgerhq/agent-skills（必要に応じて-s wallet-cli-usage、または DMK の 3 スキル）- Wallet CLI を入れ、
genuine-checkとaccount discover ethereum等を実行 - 読み取り専用プロンプトで
balances/operationsのみ許可して 1 回成功させる - 送金 / スワップは
send --dry-run（または quote）→ デバイス画面の金額・宛先を人が検証 → 承認
DMK をアプリに載せる場合
DMK skills ドキュメントでは、次の 3 スキルを案内しています。
dmk-intent-vocabulary… 自然言語を DMK API にマッピングledger-dmk-implementation… Init → Session → Device State → App Management → Operation の 5-step と HITL ゲートdmk-business-logic… Clear Signing / Secure Channel / sessions / transports
インストール例:
npx skills add ledgerhq/agent-skills -s ledger-dmk-implementation dmk-intent-vocabulary dmk-business-logic
プロンプトには次を明示すると精度が上がります。
- platform（web/Node/mobile）
- transport（WebHID/Bluetooth/USB/Speculos）
- chain
- operation
WebHID は Chromium 系、localhost または HTTPS、discovery 開始にユーザージェスチャーが必要です。オンデバイス確認を実装から外すとユーザーリスクになる、と docs は開発者責任を明記しています。
チーム運用の境界
- 自律実行ポリシーを持つ bot には不適合（設計思想が「毎回人の物理確認」）
- 提案専用エージェント + 人のデバイス確認を標準手順化する
- 本番資産は少額テスト後に拡張する
ソフトウェア権限ウォレットとの違いと採用判断
差分の中心は UX 速度ではなく、最終境界の置き場です。
- ソフトウェア権限の agent wallet: 権限がアプリ内で完結し、ルール内の自律実行は滑らか
- Ledger Agent Stack: 提案・準備はエージェント、最終実行は Secure Element 上の人の確認
The Block が指摘するように、ユーザー定義ルール内でボットが自律実行できるウォレットとは姿勢が異なります。完全自律トレードや無人送金が要件なら、本スタックは意図的に噛み合いません。
業界の類似パターン
類似パターンとして、DigitalToday は MoonPay Agent が Ledger ハードウェア署名に対応し、秘密鍵をデバイス外に出さない構成を報じています。
- エージェント実行力とハードウェア承認の両立は、特定プロダクト単体ではなく業界トレンドとして見ると判断しやすい
- 資格情報のゼロ露出という別軸では、1Password for Claude など「秘密をエージェント runtime に渡さない」設計とも同じ問い（承認境界をどこに固定するか）を共有する
採用判断チェックリスト
- センシティブ操作ごとに人の物理確認を許容できるか
- 読み取り自動化（残高・履歴・分析）だけで十分な価値が出るか
- 完全自律の送金 / トレードが要件なら、本スタックは不適合と判定できるか
- early preview の破壊的変更を許容できるか
- チーム手順に dry-run とデバイス目視を文書化できるか
- Enterprise / Multisig が必要か、個人 Wallet CLI で足りるか
- 次の一手を固定できるか: 読み取り成功 → dry-run → 少額テスト → 本番拡張の順に進めるか
制限・リスク・読んでおく法的境界
採用前に、次を前提にしてください。
- プレビュー品質: early development。API / 挙動変更があり得る。採用前に現行 docs を再確認し、破壊的変更を手順の前提に書く
- 非決定的な AI 指示: 誤パラメータ・誤宛先があり得る → デバイス画面の独立検証が必須。次の一手は CLI 出力を信用せずデバイス表示を人が照合すること
- カストディしない: Ledger は資産を保持・管理せず、エージェントの経済結果に責任を負わない（技術機能であり金融サービスではない、という docs の境界）
- 脅威モデルの限界: 侵害エージェントは署名要求を出せても、人なしに署名させられない。ただし 人が誤承認するリスク は残る。急ぎの承認を禁止し、宛先・金額を別チャネルで突合する
- 本番資産: 少額テスト後。チームでは dry-run 必須化を推奨。次に進む条件を「読み取り成功 + dry-run 成功 + 少額実送金成功」に固定する
⚠️ 高額資産や本番キーで、いきなりエージェントに署名フローを試さないでください。まず読み取り専用で接続とスキルを検証し、署名は dry-run と目視を挟む運用が安全です。迷ったら本番資産では止め、読み取り専用に戻るのが妥当な次の一手です。完全自律送金が要件なら、このスタックの導入を見送る判断も残してください。
関連記事:
- Claude にパスワードを渡さずログイン — 1Password for Claude の zero-exposure
- Anthropic Academyの無料講座でClaude Code/MCPを学ぶ｜修了証付きコースの選び方
- AI Agentjacking攻撃：Sentry MCP経由でClaude Code・Cursor・Codexが乗っ取り被害
よくある質問（FAQ）
Q1. エージェントが秘密鍵を持つことはあるか？
A. 公式モデルでは No です。エージェントは分析・推奨・トランザクション準備までで、鍵は Ledger 側に残り、センシティブ操作はデバイス上の人の確認が必要です。
Q2. Claude Code だけで完結するか？
A. シェル可能エージェントから CLI / skills を使えますが、署名は必ずデバイス確認です。Cursor / Codex も同様で、「エージェント単体で自律送金まで完了」する設計ではありません。
Q3. 読み取りだけ試す最短手順は？
A. skills 追加 → Wallet CLI 導入 → account discover → balances / operations です。公式の read-only プロンプト型（ポートフォリオ分析）から始めると安全です。
Q4. Enterprise と個人 CLI の違いは？
A. Wallet CLI は個人アカウント向け。Enterprise CLI は機関ガバナンス支援、Enterprise Multisig CLI は定足数とハードウェア署名付きのマルチシグ運用向けです。
Q5. 本番で自律送金 bot を置きたい場合は？
A. 本スタックの設計思想（毎回の人の物理承認）と相反します。ポリシー内自動実行が必須なら別アーキテクチャを検討し、それでも HW 承認を残すか要件自体を見直してください。
まとめ — 次にやること
Ledger Agent Stack の要点は次の 4 点です。
- 提案と承認を分離し、最終境界をハードウェアに置く
- DMK skills / Wallet CLI / Enterprise / Multisig の 4 プリミティブで用途が分かれる
- Wallet CLI は読み取りと署名をコマンド面で分離できる
- プレビュー制約と誤承認リスクを織り込み、読み取り → dry-run → 少額テストの順で進める運用が前提
次アクション（迷ったらこの順で止める）:
- AI tools overview を開き、
npx skills add ledgerhq/agent-skillsで skills を入れる - 読み取り専用でポートフォリオ分析を 1 回成功させる
- チーム手順に「センシティブ操作は dry-run + デバイス目視」を追記する
- アプリ統合なら DMK の 5-step と WebHID 制約を設計レビューに載せる
関連して、エージェントに秘密を渡さない設計の別例として 1Password for Claude の zero-exposure 設計、Agent Skills 学習の入口として Anthropic Academy の Claude Code / MCP / Agent Skills、エージェント乗っ取り文脈として Agentjacking の注意 もあわせて読むと、承認境界の置き方を横断比較しやすくなります。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す