Timestamp GIT Secure your prior art without exposing code

← All posts

2026-10-05

自動Gitタイムスタンプ：GitHub Appがすべてのコミットをアンカーする仕組み

自動Gitタイムスタンプ：GitHub Appがすべてのコミットをアンカーする仕組み
timestamp git blockchain proof

自動Gitタイムスタンプ: GitHub Appがすべてのコミットをどのようにアンカーするか

あなたは重要なコミットをプッシュする — 自分が最初に作ったと証明を求められる機能の中核となるコミットだ。手動アプローチでは、まさにその瞬間にワークフローが途切れる。手を止め、コンテキストを切り替え、コミットをある時点に固定するためのローカルツールと証明処理という小さな儀式を始める。そして次のコミットでも、その次でも同じことを繰り返し、いつか忘れる日が来る。

これが手動タイムスタンプの罠だ。先行技術の記録は、その密度と規則性によってのみ強度が決まるが、人手によるプロセスの記録はどちらも備えていない。開発者は繁忙期にそのステップを飛ばし、新しいマシンで誤設定し、あるいは重要だと判明するリポジトリでそもそも設定しない。チェーンの隙間こそ、相手方弁護士や監査人が探すものだ。

本記事は、GitHub Appによる自動Gitタイムスタンプを用いて、そのループから人間を完全に排除することについて述べる。一度インストールすれば、監視対象リポジトリへのすべてのコミットがフィンガープリントされ、毎晩Bitcoinにアンカーされる — マシンによって、スケジュール通りに、誰もコマンドを打つことなく。

これは自動化のウォークスルーであり、暗号技術の深掘りではない。なぜについては、知的財産の保護: ソフトウェア開発者向けガイドとソフトウェアスタートアップのための先行技術保護: ガイドを参照されたい。後で証明を確認する仕組みについては、ソースコードを共有せずにコードのタイムスタンプを検証するを参照されたい。

(参考までに: 原始的なアプローチは、コミットごとにOpenTimestampsツールを手動で実行し、自分でカレンダー提出を管理することだ。それは難しいやり方だ。以下はすべて自動化された道筋である。)

一度きりのセットアップ: GitHub Appをインストールして忘れる

Timestamp GITは、GitHub Appを中心に構築されたマネージドSaaSだ。リポジトリまたは組織全体に対して一度インストールすれば、自動化が引き継ぐ。

デプロイモードは2つあり、どの程度のアクセスを許可するかで選ぶ:

スタンダードモード(GitHub App)。 GitHub Appは監視対象リポジトリのHEADコミットハッシュのみを読み取る — すべてのプッシュで自動的に。証明は同じリポジトリの専用ブランチ、または別のシャドウリポジトリに書き込まれる。GitHubの権限モデルには「コミットハッシュのみ」というスコープがないため、このモードではソースリポジトリへの読み取り専用アクセスと、証明が格納されるターゲットリポジトリへの読み書きアクセスが必要となる。

エンタープライズZKモード(GitHub Action)。 収集ステップがあなた自身のCIに移る。12行のGitHub Actionがあなたのランナー上で実行され、HEADハッシュを抽出し、そのハッシュのみをTimestamp GIT APIにプッシュする。トレードオフは明確だ: 読み取りアクセスは自分側に保持し、Timestamp GITはターゲットリポジトリへの読み書きアクセスのみを必要とする。ソースコードもリポジトリ読み取りアクセスも、境界を越えることは決してない。

セットアップについて特筆すべき2点:

  • 開発者のマシンには何もインストールされない。 CLIも、ローカルデーモンも、ラップトップごとの設定のばらつきもない。アプリはGitHubのインフラと当社のバックエンド上で動作し、ActionはGitHubホスト型またはセルフホスト型のランナー上で動作する。
  • 継続的な設定は存在しない。 インストール後、アプリはWebhookを通じて新しいコミットを検出する。誰も何も覚えておく必要はない。

インストール後、どのリポジトリが監視されているかはあなたのリポジトリページから確認・管理できる。

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

アプリをインストールすると、git pushから不変の証明ファイルがリポジトリに現れるまでの間に、実際に何が起こるかを以下に示す。

1. コミットの検出とバッチ処理

新しいコミットでWebhookが発火する。アプリ — またはエンタープライズZKモードではあなたのAction — がコミットハッシュを抽出し、インメモリのキーバリューストアに投入する。そのストアは台帳ではなくキューであり、夜間バッチが実行されるまでハッシュを蓄積するためだけに存在する。

移動するのはハッシュのみ。差分も、ファイル内容も、ブランチ履歴も決して移動しない。

2. 深夜のcronワーカー

毎晩、ワーカーが保留中のすべてのハッシュを取得し:

  1. リポジトリごとにグループ化し、リポジトリごとにマニフェストファイル(.txt)を書き込む。
  2. バッチ上にネイティブにMerkleツリーを構築する。
  3. 公開カレンダーサーバーを使用してOpenTimestamps証明を作成する。
  4. MerkleルートをBitcoinブロックチェーンにアンカーする。

最後のステップが記録を不変にするものだ。ルートがBitcoinブロックで確認されると、Timestamp GITを含むいかなる主体も、事後にそれを改変したり偽造したりすることはできない。

3. 証明の配信

アンカー後、マニフェストと対応する.otsレシートファイルがあなたのリポジトリにプッシュバックされる — 専用のtimestampsブランチまたはシャドウリポジトリのいずれかに。

これには数時間を見込んでおくこと。Bitcoinの確認には通常約3時間かかるため、証明は通常、夜間実行の直後ではなく数時間後に到着する。

エンタープライズZKモード: ワークフローファイルを持つ唯一のモード

ここが、あなたがYAMLを目にする唯一の場所だ。セットアップウィザードがエンドポイントとシークレットを事前入力したワークフローを生成する。おおよそ次のようになる:

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Send HEAD hash to Timestamp GIT
        env:
          TSG_ENDPOINT: ${{ secrets.TIMESTAMPGIT_ENDPOINT }}
        run: curl -fsS -X POST "$TSG_ENDPOINT" --data "$(git rev-parse HEAD)"

統合はこれだけだ。このモードをさらに深く知りたい場合は、コミットタイムスタンプ用のGitHub Action: セットアップガイドに専用のウォークスルーがある。

カスタムパイプライン: ZK Commit API

標準フロー以外にタイムスタンプを組み込みたい場合、ZK Commit APIはコミットハッシュを直接受け付ける。HMACで認証され — 署名付きURLのハッシュ値がリクエストに添付されなければならない — そのため、URLが漏洩しただけではあなたの台帳に書き込むには不十分だ。

読み取り専用の自動化には、公開ステータスエンドポイントの方が簡単だ:

# Last anchored Bitcoin block for a repo
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

# Total stamped commit count
curl -s https://timestampgit.dev/api/statusCount/your-org/your-repo

# Combined summary (what the Shields.io badge consumes)
curl -s https://timestampgit.dev/api/statusSummary/your-org/your-repo

監視と障害処理

監査できない自動化は、紛争で信頼できる自動化ではない。Timestamp GITは証明チェーンの状態を3か所で公開する。

公開ステータスダッシュボード

/status/{user}/{repo}は、証明の寿命、最も早いアンカー日、毎日の規則性、そして各アンカーの背後にあるBitcoinブロックとトランザクションデータを表示する。カレンダーヒートマップがあるため、隙間は視覚的に明らかであり、さらに監査用CSVとPDF証明書のエクスポートもダウンロードできる。

注目すべき指標は規則性だ。穴のあるヒートマップは、隙間のないものよりも弱い先行技術の物語となる。

検証バッジ

Shields.ioバッジをREADMEに埋め込んで、検証ステータスを公開表示できる。/connected/{user}/{repo}のウィジェットでライブプレビューとmarkdownスニペットが得られ、/api/badgeLink/{user}/{repo}はバッジURLとスニペットをプログラムで返す。

プライベートリポジトリは、サーバーインスタンスにスコープされた暗号化HMACをバッジとステータスURLに付加する。つまり、バッジは引き続きレンダリングされつつ、基盤となるステータスデータを解決できるのは認可されたユーザーのみとなる。

夜間実行が失敗したとき

最も可能性の高い障害は、Bitcoinネットワークの混雑による確認の遅延だ。システムはバッチを破棄するのではなく再試行する。ダッシュボードで、あるいはこれを独自のアラートに組み込む場合はAPIで状態を確認せよ:

# Confirm the latest anchored block; a stale value means the last run didn't land
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo | jq .

コンプライアンスのために特定時点の証拠が必要な場合は、成果物を直接取得せよ:

# Full audit ledger as CSV
curl -sO https://timestampgit.dev/api/audit/your-org/your-repo

# PDF certificate for a specific date
curl -sO https://timestampgit.dev/api/report/your-org/your-repo/2026-10-04

誰でも/verification/{user}/{repo}/{date}を通じて、ある1日のタイムスタンプを独立に検証できる。そこでは完全なMerkleチェーン計算がブラウザ内でローカルに実行される。Timestamp GITを含め、誰もあなたが検証する内容を見ることはない。

エアギャップ環境

セキュリティポリシーがマネージドサービスを一切許可しない場合、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の接続とインスタンスの設定を案内する。評価用の期間限定デモライセンスはDocker Licenseページから入手できる。Dockerによるセルフホスト型ブロックチェーンタイムスタンプがその道筋を詳しく扱っている。

自動タイムスタンプのベストプラクティス

  • 定期的に、適度なサイズのまとまりでコミットする。 すべてのコミットが毎日のMerkleツリーに葉を追加する。密なチェーンは、四半期ごとに4つの巨大なコミットよりも強い先行技術の記録となる。
  • 意味のあるコミットメッセージを書く。 タイムスタンプが付くのはハッシュのみだが、監査時には証明を機能に紐付けることになる。良いメッセージはそのマッピングを容易にする。
  • 古いアンカーに対するアラートを設定する。 緑のバッジは最近の実行が成功したことを意味すべきであり、3月に一度実行されたことを意味すべきではない。
  • ワークフローに手を加えない。 自動タイムスタンプにおける最大のリスクは、誰かがパイプラインを「改善」することだ。デフォルトのセットアップに手動ステップがないのには理由がある。
  • ソースを読まれてはならない場合はエンタープライズZKモードに頼る。 コンプライアンスが第三者へのリポジトリ読み取りアクセス付与を禁じている場合は、Actionを自社のランナーで実行せよ。
  • チームに自動であることを伝える。 タイムスタンプが手動タスクだと思っているエンジニアは、いずれ手動でやろうとし、そうして重複したエントリや不正なエントリが生まれる。

timestampgit.devから始められる — アプリをインストールし、リポジトリを接続し、最初の夜間バッチを実行させよう。

FAQ

Q: 自動タイムスタンプを使うにはGitワークフローを変更する必要がありますか? A: いいえ。Timestamp GIT GitHub Appをインストールすれば、Webhookを通じて新しいコミットを自動的に検出し、毎晩タイムスタンプを付ける。あなたはいつも通りコミットを続ければよい — 追加のコマンドやステップはない。

Q: 複数のブランチやリポジトリを使う場合はどうなりますか? A: GitHub Appはアクセスを許可したリポジトリ内のすべてのブランチを監視する。どのリポジトリを監視するか設定することもできる。複数のリポジトリの場合、それぞれが独自のマニフェストと証明ファイルを持つ。

Q: ソースコードがTimestamp GITに公開されることはありますか? A: いいえ。スタンダードモードでは、アプリはHEADコミットハッシュのみを読み取り、ソースコードは決して読まない。エンタープライズZKモードでは、あなたのインフラ上のGitHub Actionがコミットハッシュのみを当社のAPIにプッシュするため、コードがあなたの環境を離れることはない。

Q: コミットにタイムスタンプが付くまでどのくらいかかりますか? A: コミットハッシュはバッチ処理され、一晩に一度Bitcoinにアンカーされる。夜間実行後、Bitcoinトランザクションが確認されるまで通常約3時間かかり、その後.ots証明ファイルがあなたのリポジトリにプッシュバックされる。

結論

手動タイムスタンプが失敗するのは、すべての手動コンプライアンスが失敗するのと同じ理由だ: 人間が毎回、永遠に覚えていることに依存している。GitHub Appはその依存を取り除く。一度インストールすれば、監視対象リポジトリ全体のすべてのコミットがフィンガープリントされ、バッチ処理され、Merkleルート化され、毎晩のスケジュールでBitcoinにアンカーされる — バッジ、公開ステータスダッシュボード、監査CSV、PDF証明書、そしてブラウザローカル検証がそれを支える。

チームでこれを評価するなら、まず1つのプライベートリポジトリから始め、最初の1週間でヒートマップが埋まっていくのを見守ろう。それからどこまで展開するかを決めればよい。

GitHub Appをインストールし、最初のリポジトリを接続し、あとは深夜のワーカーに任せよう。

関連記事

EU label: AI-generated content