約13分で読めます
自分専用の Label 309 ゲートウェイを運用する
可能です。企業や開発者は自分専用の Label 309 ゲートウェイを運用し、その Cardano とストレージのウォレットに資金を入れ、ホスト型オペレーターとしての CardanoWall を使わずに標準的な存在証明を公開できます。それに何が必要かを解説します。

可能です。自分専用のゲートウェイを運用できます。Label 309 ゲートウェイとは、存在証明(Proof of Existence)レコードの見積もり・アップロード・公開・確認・インデックス化を担うオープンソースのサービスです。これを自分で運用すれば、ご自分の組織がオペレーターになります。つまり、Cardano とストレージのウォレットに資金を入れ、アカウントと API キーを管理し、CardanoWall のホスト型サービスに依存することなく標準レコードを公開できます。チェーン上に記録するレコードは他の誰のものとも同一です。フォーマットを定めるのはオペレーターではなく標準だからです。
セルフホスティングは楽な道ではありません。コントロールのための道です。本記事では、このトレードオフが見合うのはどんなときか、ゲートウェイが実際に何を動かしているのか、そして自分で運用することで何を引き受けるのかを解説します。
ゲートウェイを自分で運用すべきなのはどんなときか
運用上のコントロールが利便性より重要なときに、自分専用のゲートウェイを運用してください。
ほとんどのユーザーにとっては、ホスト型の CardanoWall ゲートウェイが正解です。始めるのが簡単で、資金を入れるのも容易、インフラ作業も丸ごと不要になります。たまにしか公開せず、鍵を自分で保有すべきポリシー上の理由がないなら、ここで読み終えて構いません。ホスト型の道はそうした方のために作られています。
ただし、一部のチームには別のモデルが必要です。
- 厳格なベンダーおよびデータ所在地のポリシー
- 規制対象または監査対象のワークフロー
- 大量公開
- 社内のコンプライアンスアーカイブと法的証拠システム
- AI 来歴インフラと CI/CD の証明パイプライン
- 自社ブランドで Label 309 上に構築された製品
- 鍵・アカウント・資金・価格に対する直接的なコントロール
こうしたチームにとってセルフホスティングは、パイプライン全体をサードパーティ経由で回すのではなく、組織自身が所有することを可能にします。
ゲートウェイは実際に何を動かしているのか
ゲートウェイは公開パイプライン全体と、その背後にある資金・チェーン・ストレージの状態を所有します。単一の Rust バイナリと PostgreSQL から成り、次を担います。
- 見積もりの作成と価格設定
- コンテンツまたは暗号文のストレージへのアップロード
- ストレージの資金管理と会計
- Cardano トランザクションの構築・送信・確認の追跡
- リオーグ処理と、公開が恒久的に失敗したときの自動返金
- 公開されたオンチェーンのレコードインデックス
- アカウント残高と残高台帳
- API キー、アカウントトークン、オペレーター用コントロールプレーン
- Webhook と監査証跡
これは信頼できる公開サービスを支える仕組みです。ユーザー向けの意図と秘密鍵は依然としてクライアントが所有し、チェーン・ストレージ・価格・アカウントのインフラはゲートウェイが所有します。この分担は意図的なものです。CardanoWall がゲートウェイを運用する場合でも、ご自分で運用する場合でも、境界は同じです。
セルフホストには何が必要か
最低限、次の 5 つを運用面で所有することが必要です。
ゲートウェイのデプロイ環境。 バイナリ、その設定、Postgres データベース、ネットワークアクセス、ログ、モニタリング、そしてアップグレードの経路です。バイナリは起動時に自身のスキーマのマイグレーションを適用し、すべてのバックグラウンドループを 1 つのスーパーバイザー下で動かします。そのため、いずれかのループが失敗すると、気づかぬうちに動作が劣化するのではなくプロセス自体が停止します。
Cardano への資金投入。 ゲートウェイはトランザクション手数料を支払うために、資金が入ったウォレットを必要とします。個々のトランザクション出力をご自分で管理する必要はありません。ウォレットは使用可能な出力の小さなプールを整えて保持し、すべての公開が見積もりではなく正確な手数料を支払えるようにします。そのウォレットへの補充だけ続ければ、残りはゲートウェイが行います。
ストレージへの資金投入。 ゲートウェイがファイルや暗号文のアップロードを受け付けるなら、ストレージバックエンドと、バイト列を保存するための資金が必要です。本番環境ではこれは Turbo バンドラー経由の Arweave で、Arweave ウォレットから補充するプリペイドのストレージクレジットで支払います。ストレージをまったく持たないハッシュのみのデプロイを運用することもできます。その場合、レコードはコンテンツハッシュ(および外部ホストの URI があればそれ)だけを保持し、インスタンスは何も保存しません。
オペレーター認証情報。 コントロールプレーンは、インスタンスのプロビジョニング時にちょうど 1 度だけ表示されるオペレーターのルートシークレットで保護されます。日々の管理は、そこから発行される短命のオペレータートークンで行います。これらのシークレットは、ブラウザ、クライアントバンドル、モバイルアプリ、CI ログのいずれにも決して到達させてはなりません。
アカウントと課金のポリシー。 たとえご自分が唯一のユーザーであっても、ゲートウェイは誰が公開してよいか、残高をどのように加算するかを判断する必要があります。残高はゲートウェイ自身が権限を持ちます。ご自分が運用するどの課金レールからでも、コントロールプレーン経由で加算します。
セルフホスティングは本物のインフラです。そのように扱えば信頼できますが、軽く扱えば負債になります。
セルフホスティングで標準は変わるのか
変わりません。セルフホスト型のゲートウェイは、他のどのオペレーターとも同じ Label 309 レコードを公開し、レコードは標準のまま保たれます。
検証ツールが必要とするのは、Cardano のトランザクションメタデータ、必要に応じてコンテンツのバイト列、そして公開された Cardano エクスプローラーだけです。レコードがホスト型の CardanoWall ゲートウェイから来たのか、ご自分の会社のゲートウェイから来たのか、開発者のノートパソコンから来たのかを、検証ツールは知る必要もなく、見分けることもできません。オープンな標準とホスト型の製品を分離する意義はまさにそこにあります。耐久する成果物は Label 309 であり、あらゆるゲートウェイはその下流の実装にすぎません。
セルフホスティングですべてのコストがなくなるのか
なくなりません。ホスト型オペレーターのマージンはなくなりますが、その下にあるコストは依然としてご自分の負担です。
引き続き次の費用が発生します。
- Cardano のトランザクション手数料と、アップロードしたバイト列のストレージコスト
- インフラ、データベース、バックアップのコスト
- モニタリング、ロギング、セキュリティ運用
- 人員の稼働時間、トレジャリー管理、障害復旧
- アップグレードと継続的な保守
公開量が少ない場合、インフラ運用の人的コストまで勘定に入れると、実際にはホスト型ゲートウェイの方が安いことがよくあります。(そもそもなぜ公開にお金がかかるのか、その仕組みについては公開に価格がある理由をご覧ください。)公開量が多い場合や、ポリシー上ご自分で鍵を保有する必要がある場合は、セルフホスティングが見合い始めます。
セルフホストすべきでないのは誰か
価格のことを考えずに済ませたいというだけの理由でセルフホストしてはいけません。
たまにしか公開せず、運用の余力がなく、資金の入ったウォレットを管理したくなく、独自のポリシー制御も必要ないなら、ホスト型ゲートウェイの方がほぼ間違いなく良い選択です。セルフホスティングは、可用性・セキュリティ・資金・モニタリング・アップグレードの責任をご自分に負わせます。それが利点になるのは、その責任を本当に引き受けたい場合だけです。
ほとんどの個人と多くの小規模チームにとって、ホスト型の CardanoWall が現実的な道です。
セルフホスティングに向いているのは誰か
すでに本格的なインフラを運用しており、パイプラインを自分で保有する具体的な理由があるチームです。良い候補には次が挙げられます。
- 大量の証明を公開する企業
- 日次または時間単位で証拠をチェーン上に記録するコンプライアンスチーム。理想的には単一のレコードにまとめて記録します
- データセットと出力のマニフェストをコミットする AI チーム
- 証明をリリースパイプラインに組み込む DevSecOps チーム
- 機微な証拠を扱う法務プラットフォーム
- 自社ブランドで Label 309 を提供したい製品
- 機微なワークフローをサードパーティのホスト型サービス経由で流せない組織
こうしたケースでは、ゲートウェイの運用は新たに世話を焼く対象ではなく、組織の既存のセキュリティおよびインフラ態勢の一部になります。
製品はゲートウェイの上にどう構築するのか
製品はゲートウェイを基盤レイヤーとして扱えます。ゲートウェイがチェーン・ストレージ・価格・残高・レコード・公開ステータスを担い、ご自分の製品がユーザー・セッション・課金の見せ方・通知・ワークフロー・UI・ドメイン固有の意味づけを担います。
たとえば次のとおりです。
- コンプライアンス製品は日次のコントロールスナップショットを公開します
- メディア製品は Content Credentials(C2PA)マニフェストのハッシュをチェーン上に記録します
- 法務製品は特定の受信者に向けて証拠を封印します
- 開発者ツールはリリースの証明を公開します
- AI 製品は生成出力のバッチにタイムスタンプを付与します
製品が Cardano の送信やストレージの会計を作り直すことは決してありません。ゲートウェイを呼び出すだけです。CardanoWall はまさにこのように作られています。Web アプリとワーカーは、サードパーティが利用するのと同じ公開ゲートウェイプレーンを包むラッパーであり、専用の裏口はありません。統合パターンを深く知りたい場合は、Label 309 ゲートウェイの上に構築するをご覧ください。
クライアントはゲートウェイにどう接続するのか
ゲートウェイの HTTP API を通じて接続します。これは 2 つのプレーンに分かれています。
Web アプリ、デスクトップアプリ、CLI、SDK 統合、バックエンドサービスは、アカウントトークンまたは API キーを使ってデータプレーンを呼び出します。見積もり、アップロード、公開、残高の読み取り、レコードの読み取りです。アカウントの作成、残高の加算、マージンの設定、認証情報の発行といったオペレーター操作はコントロールプレーンを通じて、しかも必ず信頼できるバックエンドからのみ行います。
通常の分担は次のとおりです。
- クライアントは、スコープが限定された短命のアカウント認証情報で動作します
- ご自分のバックエンドがオペレーター認証情報を保持し、決して外部に晒しません
- 秘密のアイデンティティ鍵はユーザーのデバイス上、またはご自分の鍵ポリシーの下にとどまります
- ゲートウェイが封印付きコンテンツを復号することはありません
実用的なパターンはトークン発行プロキシです。クライアントはご自分のセッションシステムに対して認証し、バックエンドがそのセッションを、ページに必要な範囲ちょうどにスコープした短命のアカウントトークンに交換し、クライアントが目にするのはそのトークンだけになります。こうすればトークンが漏えいしても、それはインシデントではなく 1 時間で消える問題になります。レコードの読み取り面はさらに単純です。匿名の呼び出し元にも応答するため、公開の検証ページやエクスプローラーには認証情報がまったく要りません。
オペレーターは何を守るべきか
いくつかあります。おおよそ深刻度の高い順に挙げます。
鍵と認証情報。 ゲートウェイは単一の暗号化されたキーリングで署名します。Cardano・ストレージ・Webhook の各鍵が、1 つのパスフレーズの下で 1 つのファイルにまとまっています。これをオフラインで作成し、ファイルとパスフレーズの両方のオフラインバックアップを保管し、オペレーターのルートシークレットを本番データベースのパスワードのように守ってください。鍵のエクスポートやスイープの経路はありません。キーリングを失えば、そのアドレスに乗っている資金は何であれ取り出せなくなります。
資金と権限。 誰がアカウントを作成し、API キーを発行し、残高を調整し、マージンを変更できるかを管理してください。すべてのコントロールプレーン操作は監査ログに記録され、残高の調整は影響範囲の上限として 1 回の呼び出しごとに上限が設けられています。そのため、入力ミスやトークンの侵害があっても、一度に動かせる額には限りがあります。
運用。 ログと監査証跡、バックアップとリストアの計画、そしてウォレット残高の低下・ストレージの枯渇・滞留したアップロード・失敗した公開・古くなったチェーン先端を監視する体制を維持してください。バイナリはログアグリゲーター向けに構造化された JSON をログ出力し、ヘルスプローブを公開します。
最小権限。 ブラウザがオペレーター認証情報を受け取ることは決してあってはなりません。CI ジョブが必要以上の権限を受け取ることもあってはなりません。アカウントトークンは狭くスコープし、短命に保ってください。
セルフホスト型ゲートウェイに対して検証はどう機能するのか
どのゲートウェイに対するのとも、まったく同じです。検証はゲートウェイをまったく信頼しません。
検証ツールは、Cardano トランザクション、Label 309 メタデータ、ハッシュ、任意の署名、あらゆる Merkle 証明、封印されたペイロードを、標準のルールに従って検査します。発行者のサーバーは介在しません。ゲートウェイが助けるのは公開とインデックス化であり、無効な証明を有効にすることはできません。
これが最も重要になるのは社内システムです。自分専用のゲートウェイを運用する企業であっても、自社のレコードを独立して検証すべきです。「うちのゲートウェイが公開したと言っている」というのは証明ではありません。オンチェーンのレコードと独立した検査こそが証明です。その検査は、オープンソースの cardanowall コマンドラインツールで実行することも、レコードを手作業で検証することもできます。どちらもご自分のゲートウェイの稼働を必要としません。
これは CardanoWall とどう関係するのか
CardanoWall は、ホスト型で洗練された製品であり、標準のリファレンスオペレーターです。セルフホスティングは独立への道です。この 2 つは対立しません。
ユーザーは CardanoWall で始め、後でセルフホスト型ゲートウェイに移ることも、ワークフローごとに両方を使い分けることもできます。開発者はゲートウェイモデルの上に製品を構築できます。企業は、シンプルなチーム向けにはホスト型の CardanoWall を使い続けつつ、規制対象の自動化には自分専用のゲートウェイを運用できます。そのすべての下にある共有レイヤーが Label 309 です。オープンで、ベンダー中立で、誰が公開してもチェーン上では同じものになります。
要点
公開サービスを自分で運用したいときに、自分専用のゲートウェイを運用してください。資金・アカウント・マージン・API キー・インフラ・ポリシーに対するコントロールを得る一方で、可用性・セキュリティ・ウォレット・ストレージ・モニタリング・アップグレードの責任を引き受けることになります。
ホスト型の CardanoWall は利便性です。セルフホスティングはコントロールです。どちらにしても、証明レコードは標準のまま保たれます。
さらに読む
- オープンな標準: label309.org
- ゲートウェイ、SDK、CLI はすべてオープンソース(Apache-2.0): github.com/cardanowall
- このメタデータ標準は Cardano の CIP プロセスに提出され、レビュー中です: 提案のプルリクエスト
- Label 309 ゲートウェイとは何か
- Label 309 はオープンソースです