GitリポジトリのBitcoinタイムスタンプを検証する方法
リポジトリに .ots レシートがあります。そこへ、弁護士、監査人、技術デューデリジェンスを行う買収企業など、誰かが最重要の質問を投げかけます。これが本物だと、どうやって分かるのか?
この問いこそが、暗号学的な先行技術の核心です。独立して検証できないタイムスタンプは、データベース上の単なる主張にすぎません。誰もがBitcoinブロックチェーンに対して検証できるタイムスタンプは、証拠になります。この記事では、Timestamp GIT によってアンカーされたリポジトリの検証手順を、READMEバッジからMerkle証明に至るまで順を追って説明します。
Gitタイムスタンプにおいて検証が重要な理由
Gitの履歴は、驚くほど簡単に争われます。コミット日時はコミットを作成したマシンによって設定されるため、環境変数ひとつで過去に遡及させることができます。ホスト型の履歴は自分が管理していないサーバー上にあり、セルフホスト型の履歴は管理者権限を持つ誰かが書き換えられるデータベース上にあります。法的監査では、どちらも自己に都合のよい主張として日常的に退けられます。
暗号学的アンカリングはこのギャップを埋めます。ただし、あなたもベンダーも信頼しない第三者が証明を確認できる場合に限ります。つまり、次の2つの要件が必要です。
- 検証にTimestamp GITへの信頼を必要としないこと。 証明はBitcoinブロックで終端するSHA-256ハッシュチェーンです。誰でもオープンソースのツールでこのチェーンをたどれます。
- 検証にソースコードの開示を必要としないこと。 Timestamp GITはゼロ知識モデルで動作します。サービスが受け取るのはコミットハッシュのみで、ファイルの内容は一切受け取りません。検査対象はハッシュだけであり、これはまさに監査人が望むものです。コードベースを共有せずに証明を共有できるからです。
この設計により、検証はコードレビューではなく暗号学的な作業となります。監査人、相手方弁護士、買収企業のエンジニアリングチームのいずれもが、同じレシートを検証して同じ結論に達することができます。
Timestamp GITの証明とはどのようなものか
夜間のアンカリング実行後、監視対象の各リポジトリには3つの成果物が生成されます。
- 日次マニフェスト(
.txt) — その日にバッチ処理されたコミットハッシュのリストで、リポジトリごとに1ファイルです。 - Merkleルート — そのマニフェストから計算された単一のSHA-256ハッシュ。個々のハッシュはすべて1つの値に集約されます。
.otsレシート — Merkleルートを特定のBitcoinブロックに結び付けるOpenTimestamps証明。
これらの成果物は、専用のtimestampsブランチとしてリポジトリにプッシュバックされるか、ソースリポジトリをクリーンに保ちたい場合は別のシャドウリポジトリにプッシュされます。いずれの場合も、証明はそれが証明するコードと並んでバージョン管理されますが、独自のref内に置かれます。ワーキングブランチにコミットされることは一切ありません。
明確に述べておくべき点が2つあります。
- 証明にはソースコードは含まれません。含まれるのはコミットハッシュとその暗号学的な縮約のみです。
- 証明はプロプライエタリではありません。Bitcoinトランザクションに対する標準的なOpenTimestampsレシートであり、Timestamp GITが存在しなくなっても有効であり続けます。
レシートファイルがリポジトリにあれば、検証に必要なものはすべて揃っています。あとはツールの問題です。
Timestamp GITのツールを使ったステップバイステップの検証
ステップ1 — 証明を探す
timestampsブランチ(またはシャドウリポジトリ)を開き、該当日付のマニフェストと対応する .ots ファイルを見つけます。ブランチを探し回りたくない場合は、リポジトリのステータスページでブラウザから同じ情報を確認できます。
https://timestampgit.dev/status/{user}/{repo}
ステップ2 — 公開ステータスページを読む
ステータスページは最も手早い健全性チェックです。以下が表示されます。
- 証明の存続期間と最も早いアンカー日
- 日次の規則性(アンカーされた日のカレンダーヒートマップ)
- アンカーを担うBitcoinブロックとトランザクション
- 監査CSVとPDF証明書のダウンロードリンク
自動チェック用に、同じデータがJSONとして公開されています。
# Last anchored Bitcoin block
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service
# Total number of stamped commits
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service
# Combined summary (used by the Shields.io badges)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service
ステップ3 — ブラウザで特定の日付を検証する
日単位の証明には、暗号学的検証ページを使用します。
https://timestampgit.dev/verification/{user}/{repo}/{date}
このページは、完全な多段Merkleチェーン検証をブラウザ内でローカルに実行します。コミットハッシュ、マニフェスト、Merkleパス、Bitcoinブロックヘッダーはすべてあなたのマシン上でチェックされます。ページは検証対象をアップロードしません。この特性は、リポジトリがプライベートであるかNDAの対象である場合に重要です。監査人は、ベンダーにどの日付に関心があるかを知られることなく、証明を確認できます。
ステップ4 — 監査台帳またはPDF証明書を取得する
コンプライアンスチームは通常、提出できる成果物を必要とします。どちらも1回のリクエストで取得できます。
# Full audit ledger as CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv
# PDF certificate for one day
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf
ステップ5 — 任意で、検証バッジを埋め込む
/connected/{user}/{repo} のバッジウィジェットは、ライブプレビューとREADMEにそのまま貼り付けられるMarkdownスニペットを提供します。これを貼り付ければ、顧客、投資家、買収を検討している企業など誰でも、公開検証ビューへクリックして進むことができます。
<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[](VERIFY_LINK)
上記のすべてのステップは、マネージドGitHub Appワークフロー上で実行されます。アプリを一度インストールすれば、検証はページの読み込みかHTTPリクエストだけです。コマンドラインツールも、手動のプロトコル処理も、開発者のマシン上で保守すべきものもありません。
検証結果とエッジケースの解釈
検証の成功が教えてくれるのは、狭いが強力な事実です。コミットハッシュが、レシートが参照するBitcoinブロックのタイムスタンプ以前に存在していたこと、そしてMerkle証明がその特定のハッシュをそのブロックに結び付けていることです。Bitcoinブロックはプルーフ・オブ・ワークをやり直さなければ書き換えられないため、「以前に存在していた」という境界は絶対的です。
よく遭遇する状況がいくつかあります。
- 特定の日付の証明がない。 通常はその日にコミットがなかったことを意味します。マニフェストは保留中のハッシュから構築されるため、空の日にはアンカーするものが何も生成されません。ステータスページのヒートマップで確認してください。
- 確認待ち。 アンカリングは2段階のプロセスです。夜間のcronワーカーがハッシュをバッチ処理し、Merkleツリーを構築し、ルートを公開OpenTimestampsカレンダーに送信します。その後、Bitcoinブロックでの確認には数時間、通常は約3時間かかります。したがって、深夜直後に書き込まれた証明は、その朝の遅い時間まで確定しない可能性があります。
- プライベートリポジトリ。 プライベートリポジトリのステータスページと検証ページへのアクセスには、URLに付加された暗号化HMACが必要です。HMACはサーバーインスタンスに固有であるため、リンクを別のデプロイに対してリプレイすることはできません。
- ベンダーからの独立性。 ホスト型検証ツールをまったく使いたくない場合は、
.otsファイルをダウンロードし、オープンソースのOpenTimestampsツールを使ってBitcoinブロックチェーンに対して自分で実行してください。これは手間のかかる方法で、より遅いですが、存在します。そしてその存在こそが、マネージドな経路を信頼に足るものにしているのです。
エンタープライズおよびセルフホスト環境での検証
エンタープライズZKモード。 12行のGitHub Actionが自社インフラ上で実行され、コミットハッシュのみをTimestamp GIT APIにプッシュします。サービスがソースリポジトリへの読み取りアクセスを持つことはありません。必要なのは、証明を受け取るターゲットリポジトリへの読み書きアクセスのみです。検証は変わりません。同じ .ots ファイル、同じ公開Bitcoinデータ、同じブラウザベースのMerkleチェックです。
Dockerセルフホスト。 エアギャップ環境向けに、Timestamp GITは自分で実行するDockerイメージとして提供されています。クイックスタートのDocker Compose構成は次のようになります。
services:
timestampgit:
image: rue1401/timestampgit:prod
ports:
- "8080:8080"
volumes:
- ./data:/app/data
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の接続とデプロイの設定を案内します。検証は完全にあなたのネットワーク内で機能します。必要なのは .ots ファイル、マニフェスト、ローカル検証ツールだけです。
評価用の期間限定デモライセンスは、Dockerライセンスページのリクエストフォームに氏名、会社名、メールアドレス、任意で電話番号を記入して送信すると入手でき、ライセンスファイルはすぐにダウンロードできます。
コンプライアンスチーム向けの検証自動化
手動検証は1回の監査には十分です。継続的なコンプライアンスはパイプラインでの実行を求めます。REST APIがそれをカバーします。
#!/usr/bin/env bash
set -euo pipefail
REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"
# Merkle chain data for local verification of a specific day
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"
# Monthly audit ledger
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"
# PDF certificate per anchored day
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"
ダッシュボード用には、完全な検証ペイロードではなくステータスエンドポイントをポーリングします。
# Feed /api/statusLast and /api/statusCount into your monitoring system
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"
有用なパターンは、古い statusLast をアラート条件として扱うことです。アクティブなコミットがあるリポジトリで、最後にアンカーされたブロックが1日以上動いていなければ、パイプラインのどこかに注意が必要です。すべての検証計算はブラウザ内または自分のスクリプト内でローカルに行われ、機密ペイロードがあなたの管理下を離れることはありません。まだアンカリング側の設定をしている場合は、Automated Git Timestamping: How a GitHub App Anchors Every Commit を参照してください。この記事は、その後に何が起こるかにあえて焦点を当てています。
FAQ
Timestamp GITの証明を検証するのにコマンドラインツールを実行する必要はありますか?
いいえ。Timestamp GITは、すべての暗号学的チェックをブラウザ内でローカルに実行するWebベースの検証ページを提供しています。希望すれば .ots ファイルをダウンロードして標準のOpenTimestampsツールを使うこともできますが、マネージドサービスではCLIの使用は不要です。
Timestamp GITを信頼せずにタイムスタンプを検証できますか?
はい。証明はSHA-256ハッシュとBitcoinブロックデータのみに依存しています。オープンソースのOpenTimestampsツールを使って .ots ファイルをBitcoinブロックチェーンに対して独立に検証でき、ベンダーからの独立性が確保されます。
タイムスタンプが検証可能になるまでどのくらいかかりますか? 夜間のcronジョブがMerkleルートをBitcoinトランザクションにアンカーした後、トランザクションがBitcoinブロックで確認されるまで通常約3時間かかります。一度確認されれば、証明は不変で検証可能です。
プライベートリポジトリのタイムスタンプを検証できますか? はい。ただし、プライベートリポジトリのステータスページと検証ページへのアクセスには、URLに付加された暗号化HMACが必要です。これにより、認可されたユーザーのみが証明の詳細を閲覧できます。
結論
検証とは、タイムスタンプが約束から証拠になる場所です。チェーンは短く、確認可能です。コミットハッシュ → 日次マニフェスト → Merkleルート → Bitcoinブロック。ステータスページで確認するにせよ、ブラウザベースのMerkle検証を実行するにせよ、提出用にCSV台帳を取得するにせよ、結論は誰かの言葉ではなくBitcoinの数学に基づいています。それは私たちの言葉であっても同じです。
リポジトリにGitHub Appをインストールし、夜間の実行に任せ、誰かに求められる前に自分で日付を検証してください。数分で済み、「証明できると思う」と「これが証明です」の違いになります。
関連記事
- Automated Git Timestamping: How a GitHub App Anchors Every Commit
- Protecting Intellectual Property: A Guide for Software Developers
- Prior Art Protection for Software Startups: A Guide