2026-08-26 timestamp git blockchain proof

Docker を使ったセルフホスト型 Git タイムスタンプ: ガイド

ここで排除する反復的な手作業とは、次のようなものだ。Git コミットが特定の日付に存在したことを暗号的に防御可能な形で証明したい場合、手動でタイムスタンプコマンドを実行するか、完全には制御できないサービスにメタデータをプッシュするかのどちらかになる。スタートアップ、開発会社、コンプライアンスを重視するチームにとって、これはギャップを生む。手動ステップは省略される。外部依存はデータ主権の問題を引き起こす。規制対象やエアギャップ環境では、マネージド SaaS をそもそも使えないことが多い。

難しい方法は、OpenTimestamps を自分で運用し、各レシートを逐一管理することだ。現実的な方法は、Timestamp GIT をセルフホスト型 Docker アプリケーションとしてデプロイすることだ。同じ GitHub App ベースの自動化、毎晩のビットコインアンカリング、検証バッジが、自分が所有するインフラ上で動作する。

続行する前に、ソフトウェアにおいて存在証明がなぜ重要なのかを復習したい場合は、ソフトウェアにおける存在証明: 初心者ガイドを参照してほしい。

なぜ Git タイムスタンプをセルフホストするのか?

Timestamp GIT のセルフホストは、マネージドサービスを避けることが目的ではない。同じ自動化を自分のファイアウォールの内側で、自分のデータボリューム、自分のライセンス、自分のネットワークルールで実行することが目的だ。それが重要になるのは、次のような場合だ。

データ主権が必要で、ビットコインアンカリングのステップ以外でコミットメタデータを環境の外に出したくない場合。
サードパーティ SaaS 接続が制限されている規制対象またはエアギャップ環境で運用している場合。
GitHub App の認証情報、保存場所、ログアクセスを完全に制御したい場合。
チームの運用管理下に置かれる監査対応のデプロイが必要な場合。

Docker セルフホストオプションは、同じ自動化パイプラインを提供する。GitHub App を一度インストールし、リポジトリを接続すれば、インスタンスが毎晩コミットハッシュをグループ化し、Merkle 証明を構築し、ビットコインにアンカリングする。一度のセットアップ後は、手動のタイムスタンプステップは存在しない。

一度きりのセットアップ: Docker で Timestamp GIT をデプロイする

デプロイは、2 つのサービスからなる単一の Docker Compose スタックだ。Timestamp GIT アプリケーションと、ハッシュキューとして使用される Valkey インスタンスである。

製品ドキュメントの正確な設定で docker-compose.yml ファイルを作成する。

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
      - ./license.lic:/app/license.lic:ro
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

次に以下を実行する。

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

起動後、アプリケーションは http://localhost:8080 で利用可能になる。初回起動時には、セットアップウィザードが GitHub App の接続とインスタンスの設定を案内する。ここで一度きりの統合を完了する。開発者のマシンには何もインストールせず、後で手動のタイムスタンプステップを繰り返すこともない。

./license.lic にマウントされたライセンスファイルが必要だ。Docker ライセンスページのリクエストフォームに名前、会社、メールアドレス、任意の電話番号を記入すると、期間限定のデモライセンスを入手できる。本番利用では、商用ライセンスを使用すること。

ウィザードが完了すると、継続的なタイムスタンププロセスは完全に自動化される。

自動化パイプライン: コミットからビットコインアンカーまで

デプロイ後、セルフホストインスタンスはマネージド Timestamp GIT サービスと同じゼロセットアップのワークフローを実行する。

コミット検出

検出モードは 2 つある。

標準モード (GitHub App): GitHub App が webhook 経由で新しいコミットを検出する。監視対象の各リポジトリの HEAD コミットハッシュのみを読み取り、そのハッシュをセルフホストインスタンスに送信する。
Enterprise ZK モード: 12 行の GitHub Action が自分のインフラ上で実行され、コミットハッシュのみを Timestamp GIT API にプッシュする。このモードでは、ソースコードが環境の外に出ることはなく、Timestamp GIT インスタンスはソースリポジトリへの読み取りアクセスを必要としない。

ハッシュキューと毎晩のバッチ処理

受信したコミットハッシュは Valkey ベースのキューに保存される。毎晩、Timestamp GIT コンテナ内の cron ワーカーが次の処理を行う。

各リポジトリの保留中のハッシュをすべてグループ化する。
各リポジトリの日次マニフェストファイル (.txt) を作成する。
Merkle ツリーをネイティブに構築する。
公開 OTS カレンダーを使用して OpenTimestamps 証明を作成する。
Merkle ルートをビットコインブロックチェーンにアンカリングする。

証明の配信

マニフェストと .ots レシートファイルは、GitHub App の設定方法に応じて、専用の timestamps ブランチまたはシャドウリポジトリにプッシュバックされる。これはビットコインアンカーが確認された後に自動的に行われる。

ビットコインの確認には通常数時間かかるため、証明は深夜直後に即座に表示されるわけではない。15:00 にコミットした場合、そのハッシュは次の夜間実行で取得され、通常は数時間後にアンカリングされて配信される。

監視と障害処理

アンカリングステータスは、セルフホストインスタンスが公開する API エンドポイントを通じて直接監視できる。

ステータスエンドポイント

公開リポジトリの場合、次のようにクエリできる。

curl https://timestampgit.example.com/api/statusLast/acme/checkout-service

これは、最後にアンカリングされたビットコインブロック情報を含む JSON を返す。

curl https://timestampgit.example.com/api/statusCount/acme/checkout-service

これは、コミット総数とタイムスタンプ済みコミット数を返す。

curl https://timestampgit.example.com/api/statusSummary/acme/checkout-service

これは、Shields.io バッジに適した複合サマリーを返す。

プライベートリポジトリは、暗号化された HMAC を URL に付加するため、許可されたユーザーのみがステータスを表示できる。HMAC はセルフホストサーバーインスタンスに固有のものだ。

公開ダッシュボード

各リポジトリには、次の場所に公開ステータスダッシュボードもある。

https://timestampgit.example.com/status/{user}/{repo}

このページには、証明の有効期間、最古のアンカー日、日次の規則性、ビットコインブロックとトランザクションデータ、カレンダーヒートマップ、ダウンロード可能な監査 CSV、PDF 証明書が表示される。

障害シナリオ

cron ワーカーが失敗した場合は、コンテナログを確認する。

docker compose logs -f timestampgit

ビットコインネットワークが確認を遅延させた場合、ステータスエンドポイントにはまだ新しいアンカーが表示されない。これは通常一時的なものだ。
セルフホストインスタンスはデータを ./data ボリュームに保存する。コンテナを再起動または再作成しても、キューに入ったハッシュや設定は失われない。
ステータス API またはログ出力に基づいてアラートを設定する。ほとんどのチームには /api/statusLast の毎日のチェックで十分だ。最後のアンカー日が進まなくなった場合は、コンテナとアウトバウンドネットワークアクセスを調査する。

セルフホスト型 Git タイムスタンプのベストプラクティス

Docker ホストへのネットワークアクセスを制限する。 ファイアウォールルールとリバースプロキシを使用する。GitHub webhook または内部ネットワークから到達可能である必要があるポートのみを公開する。
./data ボリュームと license.lic ファイルをバックアップする。 ボリュームにはキューに入ったハッシュとインスタンス設定が保持される。ライセンスファイルはコンテナから読み取り可能でなければならない。
最小限の権限を持つ専用の GitHub App を使用する。 標準モードでは、アプリはソースリポジトリへの読み取り専用アクセスと、証明が保存されるターゲットリポジトリへの読み書きアクセスが必要だ。Enterprise ZK モードでは、ターゲットリポジトリへの読み書きアクセスのみが必要となる。
証明にはシャドウリポジトリを優先する。 これにより、メインリポジトリがクリーンに保たれ、ソース履歴とタイムスタンプレシートが分離される。
タイムスタンプを定期的に検証する。 公開検証ページまたは API を使用して、.ots レシートがビットコインブロックデータに対して依然として検証可能であることを確認する。これは法的またはコンプライアンスイベントの前に特に重要だ。
コンテナイメージは計画的に更新する。 メンテナンスウィンドウで docker compose pull を使用し、本番にロールする前にステージングインスタンスで新バージョンを検証する。

FAQ

Q: 完全にエアギャップされた環境で Timestamp GIT を実行できますか?

A: はい。Docker セルフホスト版は最大限のセキュリティを考慮して設計されており、エアギャップ環境で実行できます。ただし、ビットコインブロックチェーンへのアンカリングは依然として必要であるため、インスタンスはビットコインノードまたは OpenTimestamps カレンダーに到達するためのアウトバウンドインターネットアクセスが必要です。完全なエアギャップが必要な場合は、アンカリングステップにプロキシまたはリレーが必要になる場合があります。

Q: Docker セルフホスト版のライセンスはどうやって取得しますか?

A: Docker ライセンスページのフォームに名前、会社、メールアドレス、任意の電話番号を記入すると、期間限定のデモライセンスをリクエストできます。評価用にライセンスファイルが提供されます。本番利用では、ベンダーに問い合わせて商用ライセンスを取得してください。

Q: セルフホスト版には GitHub App が必要ですか?

A: はい。セルフホストの Timestamp GIT インスタンスは、コミットを検出して証明をリポジトリにプッシュバックするために、依然として GitHub App を使用します。セットアップウィザード中に、GitHub App の認証情報を接続します。アプリはソースリポジトリへの読み取り専用アクセスと、証明が保存されるターゲットリポジトリへの読み書きアクセスを必要とします。

Q: Docker で Timestamp GIT を実行するためのリソース要件は何ですか?

A: 製品情報には正確なリソース要件は明記されていませんが、Docker Compose には 2 つのサービスが含まれます。Timestamp GIT アプリケーションと、ハッシュキュー用の Valkey (Redis 互換) インスタンスです。小規模から中規模のチームでは、1〜2 GB の RAM を備えた控えめな VPS で十分です。リソース使用量を監視し、必要に応じてスケールしてください。

まとめ

Docker を使ったセルフホスト型 Git タイムスタンプは、先行技術保護から手作業の雑務を取り除く。スタックを一度デプロイし、GitHub App を接続すれば、監視対象リポジトリへのすべてのコミットが自動化パイプラインを流れる。ハッシュ検出、毎晩のバッチ処理、Merkle 証明の作成、ビットコインアンカリング、そしてリポジトリへの証明の配信だ。

これが、実際に使われる法的保護手段と、雑務になってしまうものとの違いだ。デプロイする準備ができたら、上記の Docker Compose スタックから始め、Docker ライセンスページからデモライセンスをリクエストしてほしい。独自のインスタンスを運用したくないチームには、マネージド Timestamp GIT サービスがセルフホストなしで同じ自動化を提供する。

Dockerでセルフホスト型Gitタイムスタンプ：ガイド