ウェブサイトを使わずに CardanoWall を活用する方法

CardanoWall は、ウェブサイトを一度も開かずに使えます。同じ存在証明（Proof of Existence）レコードを、コマンドラインツール、アプリケーションコードに組み込んだ SDK、ゲートウェイ API、デスクトップアプリ、あるいはご自身で運用するサービスから作成・公開・検証できます。ウェブサイトはオープンな標準である Label 309 への一つのフロントエンドにすぎず、本当に重要なのはその標準のほうです。

この区別こそが本質です。存在証明は、人間が一度きりで行う操作とは限りません。ビルドパイプラインの中、コンプライアンスの定常運用、AI の来歴システム、法的証拠のワークフロー、あるいは誰かが作る製品の内側にも組み込まれます。そのいずれにおいても、人が一つのウェブ UI を順番にクリックしていく必要などないはずです。

ウェブサイトは実際に何をしているのか

ウェブサイトは、存在証明を扱いやすくします。視覚的なコンポーザー、アカウントと残高の表示、レコードページ、アイデンティティ管理、アップロードのフロー、ガイド付きの公開手順を提供します。多くの方にとっては、ここから始めるのが正解です。

しかし、それが標準を使う「唯一」の方法であってはなりません。一つのインターフェースを人がクリックしたときにしか機能しない証明では、インフラにはなり得ないのです。企業には自動化が必要です。開発者には API と SDK が必要です。運用チームやセキュリティチームには、繰り返し実行でき、スクリプト化できるワークフローが必要です。レコードやファイルを自分のマシンに置きたいユーザーもいます。パイプライン全体を自分で運用したい事業者もいます。

ウェブアプリは正面玄関です。建物そのものではありません。

ほかにどんな使い方があるのか

いくつもの方法があり、それらはすべて同じ成果物に収束します。Cardano 上に記録され、誰もが独立して検証できる標準的な Label 309 レコードです。

CardanoWall ウェブアプリ
オープンソースの cardanowall コマンドラインツール
アプリケーションコード向けの公式 SDK（TypeScript、Python、Rust）
アカウントごとのトークンでアクセスする Label 309 ゲートウェイ API
オープンソースのローカルファースト・クライアント CardanoWall Desktop
ご自身でセルフホストするゲートウェイ
ゲートウェイの上に構築するご自身の製品

インターフェースは変えられます。証明のフォーマットは変わりません。これらのコードはすべて github.com/cardanowall でオープンソースとして公開され、Apache-2.0 でライセンスされています。仕様書のテキストは CC-BY-4.0 です。

ゲートウェイ API はどんなときに使うべきか

証明の公開や読み取りを、手作業の一手順ではなくシステムの一部にする必要があるとき、API を使います。たとえば次のような場合です。

SaaS 製品が顧客の文書ごとに証明を作成する
ビルドパイプラインがビルドのたびにリリースの証拠を公開する
AI プラットフォームが生成出力のバッチをまとめてチェーン上に記録する
コンプライアンスシステムが日次のコントロールスナップショットを公開する
ワークフローが特定の受信者に向けて証拠を封印する
社内ダッシュボードが公開ステータスとアカウント残高を読み取る
パートナー連携が CardanoWall の UI に触れずにレコードを送信する

API という経路を使えば、ご自身のユーザー体験を保ったまま、ソフトウェアからゲートウェイを直接呼び出せます。CardanoWall 自身のウェブアプリとワーカーも、まさにこれらの公開エンドポイントを通じてゲートウェイに到達しています。専用の裏口は存在しないため、リファレンス製品にできることは、あなたにも同じようにできるのです。ここをさらに深く知りたい場合は、CardanoWall API の上に構築するをご覧ください。

API トークンとスコープはどう機能するのか

ゲートウェイは 2 種類のクレデンシャルを区別します。この 2 つをきちんと分けておくことが、何よりも正しく押さえるべき点です。

アカウントトークンは、「あなたのユーザーの 1 人として」振る舞います。バックエンドが特定のアカウント向けに短命のトークンを発行し、呼び出しはそのトークンのもとで進みます。見積もりの要求、コンテンツのアップロード、公開、そのアカウントの残高の読み取りです。スクリプト、CI ジョブ、各種連携に置くべきなのは、このトークン、そして同じモデルの上に作られた API キーです。これらは意図的に範囲が狭く設計されています。現在のスコープ群は小さく、目的に特化しています。

poe:create：見積もりの要求、コンテンツのアップロード、レコードの公開
poe:read：レコードと公開ステータスの読み取り
inbox:read：暗号化された受信トレイの同期ブックマークの読み取り
account:read：アカウント残高の読み取り

これがプログラムから扱える領域のすべてであり、意図的にスコープが切られています。読み取り専用のダッシュボードウィジェットに必要なのは account:read だけです。公開ジョブに必要なのは poe:create です。どちらも、もう一方を必要としません。サーバー側で復号するスコープは、意図的に存在しません。封印と開封はクライアント側の操作であり、受信者の秘密鍵がゲートウェイに届くことはなく、どんな API キーであっても、サーバーがあなたに代わって封印された内容を読み取る権限を持つことはあり得ないからです。同様に CI ジョブも、ローカル署名がご自身の設計の中で意図的に組み込まれた要素であり、ご自身の管理下にある場合を除いて、ユーザーの Identity Seed を保持すべきではありません。シードと秘密鍵は、設計上クライアントに留まり、ゲートウェイが目にすることはありません。

オペレータークレデンシャルは 2 つ目の種類で、これは API キーではありません。これはコントロールプレーンを認可します。アカウントのプロビジョニング、課金で集金したときの残高調整の適用、マージンの設定、そして上述のアカウントトークンの発行です。これらは信頼されたバックエンドだけに置くべきで、ブラウザ、モバイルアプリ、スクリプトに置いてはなりません。アカウントトークンの漏えいは短命の厄介事で済むべきものですが、オペレータークレデンシャルの漏えいは本物のインシデントになります。

経験則はこうです。クライアントには必要な範囲だけに絞ったアカウントスコープのトークンを渡し、オペレーター権限はご自身のバックエンドの後ろに置いておくことです。

CLI はどんなときに使うべきか

証明がスクリプトの中に収まるべきとき、コマンドラインツールを使います。cardanowall バイナリはゲートウェイ非依存で、生のシードを第一に扱う設計のため、次のような用途に自然に適合します。

ウェブサイトを一切開かずに、ローカルでレコードを検証する
多数のファイルにまたがる Merkle 証明を構築・検証する
レコードに署名する
自動化からレコードを送信する
ターミナルから受信トレイの同期と試行復号（trial-decrypt）を行う

CLI が最も価値を発揮するのは、成果物を生み出すシステムのすぐ近くに存在証明を置けるからです。ビルドパイプラインは自らの出力をハッシュ化し、リリースの一部としてレコードを公開できます。コンプライアンスのジョブは日次のマニフェストをコミットできます。ローカルのユーザーはオフラインでレコードを検証できます。ウェブサイトは人にとって優れていますが、CLI は繰り返し行う運用にとって優れています。パターンと具体例については、CLI を自動化で使うをご覧ください。

SDK はどんなときに使うべきか

Label 309 をご自身のアプリケーションの一部にすべきとき、SDK を使います。TypeScript、Python、Rust の各 SDK は、レコードの構築、コンテンツのハッシュ化、トランザクションの検証、ホスト外での署名、ペイロードの封印と復号、シードからのアイデンティティの導出、そして任意のゲートウェイとの通信を支援します。

3 つの SDK を用意する目的は、利便性ではありません。相互運用性です。これらは同じ正規のテストベクターに対して検証されたバイト単位で同一の双子であり、一つで公開または署名されたレコードは、ほかのものでも同一に検証されます。これこそが、オープンな標準がオープンな標準であり続け、互いに非互換な「互換」フォーマットに分裂しないための仕組みです。一つ、強調しておきたい有用な性質があります。スタンドアロンの検証ツールに必要なのは、トランザクションメタデータ、必要に応じてコンテンツのバイト列、そして公開された Cardano エクスプローラーだけです。信頼の経路に発行者のサーバーは介在しません。

ウェブサイトの代わりに Desktop を使うべきなのはどんなときか

ローカルでの所有が重要なとき、デスクトップアプリを使います。CardanoWall Desktop は、Rust と Tauri で構築されたオープンソースのクロスプラットフォーム・オフラインファーストのクライアントで、Rust SDK の上に作られており、メールクライアントのように動作します。次のものを提供します。

ローカルで暗号化されたアイデンティティ保管庫
すでに同期済みのすべてへのオフラインアクセス
封印された受信トレイの探索と、ご自身のマシン上にキャッシュされた暗号文
公開レコードインデックスにまたがるローカル検索
複数のアイデンティティと、お選びいただいたゲートウェイプロバイダー

ウェブサイトは引き続き高速で便利ですが、レコード・アイデンティティ・キャッシュされたファイルをローカルに置き、ネットワークなしでも動き続けてほしい場合には、デスクトップアプリのほうがふさわしい住み処になります。多くの方にとって、答えは「両方」になるでしょう。設計に関する詳しい解説は、CardanoWall Desktopとオフラインの証明にあります。

ゲートウェイをセルフホストすべきなのはどんなときか

公開パイプラインを自分で運用したいとき、セルフホストします。理由はコンプライアンス、コスト構造、取扱量、データ取り扱いポリシー、インフラの統制、あるいは製品戦略などさまざまです。

セルフホストしたゲートウェイも、依然として標準的な Label 309 レコードを公開します。違いは、見積もり、アップロード、送信、確認、インデックス作成、公開の会計処理を行うサービスを、あなた自身が運用する点です。ゲートウェイはオープンソースの Rust 単一バイナリと Postgres から成り、独自の Cardano トランザクションビルダーを備えています。このビルダーは、トランザクションの構築・送信・確認を行い、チェーンの再編成を処理し、恒久的な失敗時には自動で返金します。

セルフホストは「無料」ではありません。基盤となる Cardano と Arweave のコストは依然として支払いますし、運用する責任も引き受けることになります。取り除けるのは、公開のためにホスト型 CardanoWall ゲートウェイに依存しなくて済むという点です。詳しくはご自身のゲートウェイを運用するとLabel 309 ゲートウェイとは何かをご覧ください。

ゲートウェイの上に独自の製品を構築できるか

できます。そして、まさにその分離があるからこそ、ゲートウェイはウェブアプリとは別の独立したレイヤーになっています。Label 309 ゲートウェイの上に、公証製品、証拠ポータル、コンプライアンスアーカイブ、公開ツール、AI の来歴サービス、社内ダッシュボードなどを構築できます。

ゲートウェイは基盤プレーンを担います。チェーン、ストレージ、価格設定、共有されたオンチェーンのレコードインデックス、残高、公開ステータスです。あなたの製品はベンダープレーンを担います。ユーザー、課金、UI、ワークフロー、通知、サポート、そしてレコードの上に載せる製品固有の意味づけです。これにより、すべてのチームが Cardano のトランザクションとストレージの運用者にならなくても、はるかに多くの製品が一つの証明標準を共有できます。手順の解説はLabel 309 ゲートウェイの上に構築するにあります。

CardanoWall をまったく使わずに検証できるか

それこそが目標であり、ほかのすべてが存在する最も強い理由です。検証が CardanoWall のウェブサイトに依存してはなりません。誰もが、トランザクションメタデータを読み取り、Label 309 レコードを再構築し、その構造を検証し、あらゆるレコード署名を検証し、コンテンツのハッシュを再計算でき、そして適切な鍵があれば封印付きレコードをローカルで復号できるべきです。

一つのウェブサイトでしか検証できない証明は、弱い証明です。Label 309 の証明を誰にでも検証可能にしているのは、オープンな SDK、オープンな CLI、そしてオープンな仕様です。CardanoWall に一度も触れない第三者であっても検証できます。これを自分で試したい場合は、Label 309 レコードを検証するから始めてください。

価格についてはどうか

インターフェースを変えても、その下にあるコストはなくなりません。ウェブサイト、デスクトップアプリ、CLI、API、ご自身の製品のいずれから公開しても、現実の Cardano トランザクション手数料に加えて、ファイルや暗号文に使われたストレージ分を、依然として誰かが支払います。ホスト型ゲートウェイは、運用・資金・インフラ・サポートをまかなうためにその上へマージンを上乗せします。したがって価格は、コストの実費転嫁にそのマージンを加えたものになります。

CardanoWall のホスト型ゲートウェイを使う場合は、その前払い残高モデルと価格モデルを利用します。セルフホストする場合は、ご自身のゲートウェイを直接運用し、資金を投入します。いずれにせよ、標準が可搬にするのは「レコード」です。ブロックチェーンやストレージを無料にするわけではありません。その理屈は公開に価格がある理由で詳しく説明しています。

重要な限界が一つ

Label 309 の証明は、特定のバイト列が特定の公開時刻までに存在していたこと、そしてそれ以降変更されていないことを示します。コンテンツを誰が著したか、誰が所有しているか、それが真実かどうか、誰かにそれを扱う権利があるかどうかは証明しません。封印付きレコードは、その平文を本来の鍵保有者だけが読める状態に保ちますが、匿名性を保証することはできず、また受信者がいったん復号した後に平文を漏えいさせるのを止めることもできません。どのインターフェースから公開する場合でも、この境界を念頭に置いてください。

短くまとめると

CardanoWall はウェブサイトだけではありません。ウェブサイトは最も手軽な人間向けのインターフェースで、ゲートウェイは公開のレイヤー、CLI と SDK は開発者向けの面、デスクトップアプリはローカルでオフラインファーストのクライアント、そしてセルフホストは運用者向けの経路です。これらはすべて同じものを生み出します。それを作ったインターフェースの外側でも検証できる、標準的な Label 309 レコードです。

作業に合ったインターフェースを選んでください。人にはウェブサイトを、スクリプトには CLI を、製品には SDK を、システムには API を、そしてベンダーからの独立性や運用上の統制が必要なときにはセルフホストのゲートウェイを使うのです。

さらに読む

CardanoWall API の上に構築する
CLI を自動化で使う
Label 309 ゲートウェイの上に構築する
ご自身のゲートウェイを運用する
Label 309 レコードを検証する
公開に価格がある理由
オープンソースのコードと SDK: github.com/cardanowall
Label 309 標準: label309.org。Label 309 は Cardano の CIP プロセスにも提出されており、現在 CIP 編集者によるレビュー中です。公開中の提案はプルリクエスト #1205で追えます。