Timestamp GIT Secure your prior art without exposing code

← All posts

2026-10-08

ブロックチェーンの証明でエージェンシーのコード納品物を保護する

ブロックチェーンの証明でエージェンシーのコード納品物を保護する
timestamp git blockchain proof

ブロックチェーン証明でエージェンシーのコード納品物を保護する

Elenaは5人規模の開発会社を経営している。11か月前、彼女はカスタマーポータルの案件でクライアントと契約を結んだ。3つのマイルストーン、固定価格、納品時請求。マイルストーン1と2は順調に進んだ。マイルストーン3は9月の金曜日に納品された——機能は完成し、テスト済みで、クライアントのステージング環境にデプロイ済み。そして請求書が届くと、クライアントは黙り込んだ。

2週間後の返信:「レポートモジュールは実際には納品されていません。最終請求書は支払いませんし、遅延に対する補償も求めます。」

Elenaには証拠がある。一応は。クライアント自身のプロダクトマネージャーが「良さそうですね、来週テストします」と書いたメールスレッドがある。エクスポートされた仕様書が入った共有Google Driveフォルダがある。そしてGitHubリポジトリ——400以上のコミットが、彼女が主張する通りに終わっており、レポートモジュールは請求書の6週間前に出荷されている。

どれも中立ではない。メールスレッドはスクリーンショット合戦だ。Driveフォルダには、クライアントが疑問視できる(そして実際に疑問視した)更新日時のファイルがある。Git履歴はクライアントが共同所有する組織にあり、コミット日時はgit rebaseとforce pushひとつで書き換えられる。支払い紛争において、「内部ログがあります」はほぼ無価値だ——それは自分が管理するシステム上で、自分自身について作成した証拠にすぎない。

この記事は、正反対のものを求めるエージェンシー向けの実践的なプレイブックだ。どちらの当事者も管理せず、検証にクライアントの善意を必要とせず、クライアントがリポジトリやホスティングプロバイダー、あるいは主張を変えても生き残る記録。

存在の暗号学的証明は、まさにこの問題を解決する。そして2026年以降、それを使うために暗号技術を理解する必要はない——マネージドレイヤーがその作業を担ってくれる。

なぜブロックチェーン証明がエージェンシーにとって重要なのか(特許トロールだけの話ではない)

ブロックチェーンによるタイムスタンプは「特許防衛」のカテゴリに分類される。だからこそほとんどのエージェンシーは、必要になるまでそれを無視する。しかし開発会社にとって日々のリスクは特許トロールではない。キャッシュフローに問題を抱えたクライアントだ。

Bitcoinにアンカーされたコミット記録が元を取れる、4つの具体的な場面:

  • 支払い紛争。 マイルストーンがコミットされた正確な日付を証明できる——請求書が送られた時点でも、誰かがSlackで「完了」と言った時点でもない。その日付はBitcoinブロックから導出され、あなたのサーバークロックやクライアントのものからではない。
  • 責任の盾。 スコープクリープの議論は通常、何かが合意された時点と、それが作られた時点の比較に帰着する。プロジェクトの各時点で何が存在していたかの不変の日次記録があれば、誰かのカレンダーについて言い争うことなく、変更要求が納品後に来たことを示せる。
  • ポートフォリオと再利用の保護。 ほとんどのエージェンシーはコンポーネントライブラリ——認証モジュール、請求アダプター、CMS統合——を持っており、それが十数件のクライアントプロジェクトに登場する。あなたがそれを、そしていつ制作したかを証明することは、元クライアントがあなたが彼らのコードを盗んだと主張した場合にあなたを守る。
  • 機能としてのクライアントの信頼。 検証可能な著作証明書を含む納品パッケージは、自分で生成したPDFを含むものとは、調達交渉の場で全く異なる印象を与える。

これは主に特許の話ではない。先行技術の観点——広範な特許の無効化、出願前の営業秘密の保護——を求めるなら、ソフトウェアスタートアップのための先行技術保護に関する姉妹記事で扱っている。ここでは商業関係にとどめる。

実践的なプレイブック:エージェンシーのリポジトリにブロックチェーン証明を設定する

設定全体は5ステップで、そのうち4つは一度きりだ。ここにあるものはどれも、開発者に新しいツールを学ばせたり、コマンドを1つ変えさせたりすることを要求しない。

ステップ1 — Timestamp GIT GitHub Appをインストールする

クライアントワークに使用するリポジトリにアプリをインストールする。Standard Modeでは、GitHub Appが監視対象の各リポジトリのHEADコミットハッシュを自動的に読み取り、証明を専用ブランチに書き込む(同じリポジトリ内か、別のシャドウリポジトリかは選択できる)。ソースリポジトリへの読み取り専用アクセスと、証明が格納されるターゲットリポジトリへの読み書きアクセスが必要だ。

これはエンゲージメントの開始時に一度だけ行う。紛争が始まってからではない。意見の相違の最中に作成されたタイムスタンプは、通常の納品中に作成されたものの何分の一の価値しかない。

ステップ2 — 夜間アンカリングを実行させる

コミットごとのステップはない。コミットハッシュはWebhook経由で検出され、メモリ内のキューに入れられる。毎晩、ワーカーが保留中のすべてをバッチ処理し、リポジトリごとにマニフェストファイルを構築し、Merkleツリーを構築し、公開カレンダーを使用してOpenTimestampsプロトコル経由でMerkleルートをBitcoinブロックチェーンにアンカーする。

Bitcoinの確認には通常約3時間かかるため、証明はバッチ実行の数時間後に書き戻される。あなたの側から見れば:コードをプッシュすれば、翌朝までに前日の作業がアンカーされている。

ステップ3 — 検証バッジをクライアントの目の前に(丁寧に)置く

READMEと納品レポート用に埋め込み可能なバッジが利用できる。リンクを持つ人は誰でも、公開ステータスページ経由でタイムスタンプを検証できる——アカウントもログインも不要。

# Get ready-made badge markdown for your delivery report or README
curl -s https://timestampgit.dev/api/badgeLink/your-agency/client-portal

バッジはShields.io互換のスニペットなので、README、Notionページ、または請求書に添付するPDFにそのまま貼り付けられる。プライベートリポジトリでは、ステータスURLに暗号化されたHMACが含まれるため、認可された人だけがステータスを読める——証明自体は公開・検証可能なままで、メタデータは漏れない。

ステップ4 — マイルストーンで証明書と監査台帳をエクスポートする

各マイルストーンで、書類を取得して請求書に添付する。

# Full audit ledger as CSV — every anchored commit, every date
curl -s -o audit-client-portal.csv \
  "https://timestampgit.dev/api/audit/your-agency/client-portal"

# Per-day PDF certificate — include with the handover pack
curl -s -o certificate-2026-09-30.pdf \
  "https://timestampgit.dev/api/report/your-agency/client-portal/2026-09-30"

リポジトリのステータスページでは同じデータを視覚的に確認できる:証明の寿命、最も早いアンカー日、日次の規則性、各アンカーの背後にあるBitcoinブロックとトランザクション、カレンダーヒートマップ、ダウンロード可能なCSVとPDF。内部ダッシュボードに取り込みたい場合は、/api/statusSummary/{user}/{repo}エンドポイントが統合サマリーを返す。

ステップ5 —(任意)機密クライアント向けのEnterprise ZKモード

一部のクライアント契約——防衛、フィンテック、厳格なIP条項を含むあらゆるもの——は、第三者によるソースコードへのアクセスを禁じている。Enterprise ZKモードはこれに対処する:12行のGitHub Actionがあなたのインフラ内で実行され、コミットハッシュのみをTimestamp GIT APIにプッシュする。ソースはあなたの環境から一切出ず、書き込みアクセスが必要なのはターゲットリポジトリだけだ。

任意:セルフホストDocker

クライアントがエアギャップ運用や自社ハードウェア上でのデータレジデンシーを要求する場合、Timestamp GITは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ライセンスページから申請できる。

クライアントワークでブロックチェーン証明を使う際に避けるべきこと

エージェンシーがここで犯す5つの間違いを、ほぼ頻度の高い順に:

  • 内部Gitログだけに頼る。 それらは編集可能で、あなたかクライアントが管理するインフラに保存されており、監査では自己奉仕的として退けられる。GitHubのコミット日時は主張であり、Bitcoinブロック内のコミットハッシュは証拠だ。
  • プロトコルを手作業でやろうとする。 CLIツールと自前のカレンダー提出で、基盤となるOpenTimestampsの仕組みを自分で動かすことはできる——それは困難な方法で、開発者が忘れてしまうコミットごとのワークフローが必要で、望む結果をちょうど得られるがメンテナンスは約100倍になる。マネージドレイヤーは、チームの誰もそれについて考えなくて済むように存在する。
  • プロジェクト終了時のみのタイムスタンプ。 単一のプロジェクト終了時の証明は「これは日付Xに存在した」と言う。夜間のチェーンは「このコミットはこの日に、あのコミットはあの日に、ずっと通して存在した」と言う。クライアントが納品物ではなくタイムラインを争う場合、粒度が訴訟のすべてだ。
  • 証明を自分だけのものにする。 相手が確認できない証明は、相手が争う証明だ。バッジをREADMEに入れ、ステータスリンクを送り、PDF証明書を添付する。
  • クライアントのプライバシー要件を無視する。 契約が第三者によるコードアクセスを禁じているなら、Enterprise ZKモードかセルフホストを使う。「第三者なし」と書かれた条項を「ハッシュだけ」が満たすと、黙って思い込まないこと。

Timestamp GITがエージェンシーのワークフローにどう収まるか

設計目標は、必要になるまでタイムスタンプが目に見えないことだ:

  • 開発者にとってゼロセットアップ。 GitHub Appを一度インストールする。監視対象リポジトリへのすべてのコミットは自動的にキューに入り、バッチは夜間に実行される。新しいコマンドもなく、開発者のマシンにインストールするものもない。
  • ゼロ知識アーキテクチャ。 Timestamp GITはあなたのソースコードを見たり、コピーしたり、保存したりしない。コミットハッシュを刻印する。ステップ1のフィンガープリントはリポジトリ状態の一方向ハッシュだ——そこからあなたの実装について何も復元できない。
  • ベンダー非依存の検証。 証明はBitcoinにアンカーされた.otsレシートだ。検証はSHA-256とBitcoinブロックデータに依存し、独自形式ではない。誰でもレシートをダウンロードし、標準のOpenTimestampsツールでブロックチェーンに対して確認できる——たとえTimestamp GITが明日消えても。GitリポジトリのBitcoinタイムスタンプを検証する方法にステップバイステップの手順がある。
  • エージェンシーの書類に合う統合ポイント。 ステータス、監査CSV、PDF証明書用のREST API。READMEと納品ドキュメント用の埋め込み可能なバッジ。クライアントがブックマークできる公開ステータスページ。
  • エージェンシーの規模に合った価格設定。 公開リポジトリ向けのOpen Source(無料)、プライベートリポジトリ向けのPro Agency月額$49、契約が分離を要求する場合のEnterprise ZK月額$199。詳細は価格ページに。

プレイブックではなく仕組みを求めるチーム向けの技術的な姉妹記事は、自動Gitタイムスタンプ:GitHub Appがすべてのコミットをアンカーする仕組みだ。

FAQ

開発者のコードコミット方法を変える必要はありますか?

いいえ。Timestamp GIT GitHub Appがリポジトリにインストールされれば、すべてのコミットが自動的に検出され、そのハッシュが夜間のBitcoinアンカリングのためにキューに入ります。開発者は通常のGitワークフローを、追加のコマンドやツールなしで使い続けられます。

クライアントは自分で証明を検証できますか?

はい。READMEや納品レポートに検証バッジを埋め込み、公開ステータスページにリンクできます。クライアントは.otsレシートファイルをダウンロードし、標準のOpenTimestampsツールを使ってBitcoinブロックチェーンに対して独立に検証することもできます。

クライアントが第三者がコードを見ることを一切禁じたらどうしますか?

Enterprise ZKモードを使います。12行のGitHub Actionがあなたのインフラ上で実行され、コミットハッシュのみをTimestamp GIT APIにプッシュします。ソースコードはあなたの環境から一切出ません。あるいは、提供されているDockerイメージを使ってTimestamp GITをセルフホストし、完全な制御を得ることもできます。

コミットがBitcoinにアンカーされるまでどのくらいかかりますか?

コミットハッシュは毎日バッチ処理され、OpenTimestampsプロトコル経由でBitcoinブロックにアンカーされます。Bitcoinの確認には通常約3時間かかり、その後証明は不変で検証可能になります。

これは契約の代わりになりますか?

いいえ。契約紛争の最も弱い部分——いつ何が存在したかの事実記録——を置き換えるものです。誰が何を負うかは契約が決め、特定の日付に何が真実だったかはタイムスタンプが決めます。

結論

Elenaの紛争は、こうしたケースで通常そうなるように決着した——一部支払いと、クライアントの喪失。腹立たしかったのは金銭ではなかった。彼女が正しかったのに、第三者が受け入れる形でそれを示す方法がなかったことだ。

それがブロックチェーン証明がエージェンシーのために埋めるギャップだ。特許戦争でも、抽象的な未来でもない——クライアントが請求書を任意だと決めつけ、あなたの唯一の防御がどちらも編集できない記録である、ありふれた火曜日だ。

クライアントのリポジトリにTimestamp GIT GitHub Appをインストールし、夜間アンカリングを実行させ、次の請求書に証明書を添付しよう。一度だけ約10分かかり、それ以降のあらゆる納品の会話のトーンが変わる。

関連記事

EU label: AI-generated content