rework-proof

REWORK Proof Check

プルリクエスト内のコミットを実際に書いた人について、署名の状態、 作成者の帰属、申告された AI の支援内容をジョブの概要として報告します。

デフォルトでは、どこにも何も送信しません。ワークフローがすでに持っているトークンを使ってプルリクエストのコミットを読み取り、概要を書き出します。アカウントも API キーも、リポジトリへのサードパーティーアクセスも必要ありません。

name: Proof
on: pull_request

jobs:
  proof:
    runs-on: ubuntu-latest
    steps:
      - uses: reworkio/REWORK-Proof@v1

設定はこれだけです。

初めての方へ。 GETTING-STARTED.md では、新しいリポジトリでこのアクションと GitHub App の両方を使う方法を紹介しています。どちらを選ぶべきか、それぞれにどのような権限を与えるのか、さらに、すべてのケースを試せる一連のコミットも掲載しています。レポートの内容を確認してから安心して使えます。

ワンクリック設定

OWNER/REPO をご自身のものに置き換えて開くと、ワークフローがすでに記述された状態で GitHub のエディターが開きます。あとは Commit を押すだけです。

https://github.com/OWNER/REPO/new/main?filename=.github/workflows/proof.yml&value=name%3A%20Proof%0Aon%3A%20pull_request%0A%0Ajobs%3A%0A%20%20proof%3A%0A%20%20%20%20runs-on%3A%20ubuntu-latest%0A%20%20%20%20steps%3A%0A%20%20%20%20%20%20-%20uses%3A%20reworkio%2FREWORK-Proof%40v1%0A

デフォルトブランチが main でない場合は、/new/main の部分を該当するブランチ名に変更してください。

報告内容

プルリクエスト内のすべてのコミットについて、次の情報を報告します。

• 署名の状態 — GitHub が暗号学的に検証できたかどうか。
• 作成者の帰属 — GitHub がコミットの作成者として特定したアカウントが、プルリクエストの作成者かどうか。メールアドレスが GitHub アカウントと一度も一致しなかったコミットには、フラグを付けません。これは一般的なことであり、フラグを付けると不要な通知が増えるためです。ボットアカウント（[bot] という接尾辞が付くアカウント。dependabot、github-actions）は自動化として分類し、人間の共同作成者とは分けて記載します。
• 申告された AI の支援 — コミットメッセージにコーディングアシスタントの名前が含まれているかどうか。たとえば、Co-Authored-By: Claude（または Copilot、Codex、Gemini、Cursor、Devin、aider、…）というトレーラー、Claude-Session: または Amp-Thread-ID: というトレーラー、あるいは Generated with <tool> という行です。すべての名前は src/ai-trailers.json に記載されています。GitHub App のチェックも同じファイルを読み込むため、どちらを使ってもコミットの判定は変わりません。

AI の支援を申告しても、結果が低くなることはありません。作成者が申告を選んだのは良い習慣です。トレーラーをペナルティの対象にすれば、人々は削除するようになるだけです。それでは、その支援を必要とした人にとって重要な情報が失われてしまいます。

「申告なし」は、申告がないという意味です。 このアクションはコミットメッセージを読み取ります。トレーラーのないメッセージは、ツールがコードを書いたかどうかにかかわらず同じように見えるため、件数がゼロでも、申告がなかったことだけを示します。ツールが使われなかったという意味ではありません。

署名のないコミットも、問題として扱いません。ほとんどのリポジトリでは、署名を有効にしていません。このチェックでは、証明できることを報告し、証明できないことは明確に伝えます。

マージ後にアプリが記録する内容

アクションは1件のプルリクエストを評価し、処理を終了します。プルリクエストのクローズイベントを受け取るGitHubアプリも、結果を記録します。

• マージ。 GitHubがチェック済みのプルリクエストをマージ済みと報告すると、アプリは実行済みのチェックにその結果を記録し、プルリクエストの最終コミットに対するリポジトリのほかのチェックの結論も合わせて記録します。アプリがチェックしていない作業のマージが、結果として追加されることはありません。
• リポジトリのバッジには、「N PRs verified · S% signed · M merged」と表示されます。チェック済みの異なるプルリクエスト数、調査対象となった全コミットのうちGitHubが署名済みと報告した割合、そしてそのうちマージされたプルリクエストの数を示します。判定に応じて色が変わることはありません。マージはメンテナーが達成した結果であり、成績ではありません。
• スカッシュマージの注記。 プルリクエストでAIの支援を申告していた場合、または作成者以外の人がコミットしていた場合に、スカッシュ後のマージコミットにトレーラーが引き継がれなければ、アプリはマージコミットに「プルリクエストから開示情報を引き継ぎました」というタイトルの、中立的な2回目のチェック実行結果を投稿します。プルリクエストのコミットで申告された内容を再掲するため、デフォルトブランチにもその内容が残ります。通常のマージコミットやリベースでは情報が失われないため、注記は追加されません。
• 再検証。 GitHubが検証した署名でも、後になって検証できなくなる場合があるため、アプリは最近の結果に紐づくコミットを毎晩再取得します（1晩あたり最大200件、いずれも90日未満の結果が対象です）。すべてのコミットが署名済みだったために「success」だった結果は、それが成立しなくなった場合、「neutral」に変わります。読み取りが完了できなかった場合、変更はありません。

これらの件数がREWORKメンバー自身のスコアやバッジにどのように反映されるかは、 reworkdigital.io/docs/proofをご覧ください。

署名付き証明書（任意）

attest: trueを設定すると、アクションはREWORKに実行結果の署名付きタイムスタンプ証明書をリクエストします。

jobs:
  proof:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write        # required for attestation
    steps:
      - uses: reworkio/REWORK-Proof@v1
        with:
          attest: true

APIキーは引き続き不要です。 ワークフローは短期間有効なOIDCトークンを発行し、GitHubの権限に基づいて、実行元のリポジトリとワークフローを証明します。リポジトリ設定に長期間有効な情報を保存しないため、漏洩やローテーションが必要になるものはありません。

送信されるのは件数のみです。コードやコミットメッセージが送信されることはありません。

結果は、コンパクトなJWT形式のW3C Verifiable Credentialです。REWORKの公開鍵https://api.reworkdigital.io/api/v1/proofs/credentials/jwks.jsonを使って、誰でもオフラインで検証できます。REWORKへのコールバックは不要なため、REWORKを知らない読者でも引き続き検証できます。

証明書の発行に失敗しても、ビルドが失敗することはありません。ローカルの結果はそのまま有効です。

アテステーションが保証すること、保証しないこと

クレデンシャルの assurance フィールドには、以下のいずれかのレベルが記載されます。本文は mcp/src/assurance.json から生成されます。このファイルは、MCP サーバーが explain_rework_assurance への応答に使用し、reworkdigital.io/github ページも表示に使うため、 どの画面でも同じ上限が示されます。

ワークフローの識別情報（workflow-identity）、中程度：識別情報の証明は強力ですが、品質については示しません

証明すること：GitHub が、特定のワークフロー実行が特定のリポジトリとコミットに属することを暗号学的に保証し、REWORK がその実行で確認された作成者に関するシグナルを記録したことです。シグナルには、コミットの署名状態、各コミットがプルリクエストの作成者に紐付くかどうか、AI の支援を申告したコミットメッセージの数が含まれます。

証明しないこと：コードをレビューした人がいたか、実行したか、品質を評価したかは証明しません。成果物の良し悪しではなく、Git の履歴上で誰が作成したとされているかだけを示します。AI の件数は、作成者がコミットメッセージで申告した数です。0 であっても、何も申告されていないという意味であり、ツールが使われなかったことを示すものではありません。

レビュー済み参照（reviewed-reference）、中程度：人間が確認していますが、成果物そのものではなくデモを確認しています

証明すること：REWORK のレビュー担当者がデモ動画を視聴し、申告された作業に対応することを確認したこと、また動画にはフィンガープリントが付与されており、再利用を検出できることです。

証明しないこと：レビュー担当者がソースコードを監査したこと、結果を再現したこと、動画内で口頭説明された内容を検証したことは証明しません。

プラットフォーム間の紐付け（cross-platform-join）、中程度：どのバイト列がどこに配置されたか、両端を誰が管理しているかの証明は強力ですが、どのように作成されたかは示しません

証明すること：マニフェストのダイジェストで指定された正確なバイト列が、指定された GitHub Actions の実行直後に、指定された Hugging Face リポジトリの指定されたコミットに存在していたことを、REWORK 自身による独立した Hub の読み取りで確認したことです。また、1 つの REWORK アカウントが、GitHub リポジトリの所有者に対する App のインストールと、Hugging Face リポジトリに対する検証済みの書き込み管理権限の両方を持っていることです。

証明しないこと：ワークフローがコンテンツを生成、トレーニング、評価したことは証明しません。他人のファイルをダウンロードしてアップロードする実行でも、バイト列は運ばれます。実際にその実行で何が行われたかを判断するには、ワークフローの参照情報を確認してください。

クレデンシャルには、免責事項としてこの内容が記載されています。

入力

入力	デフォルト	説明
github-token	${{ github.token }}	PR のコミットを読み取るために使用します。追加の権限は必要ありません。
attest	false	署名付きアテステーションを要求します。id-token: write が必要です。
api-url	https://api.reworkdigital.io/api/v1	セルフホスト版の REWORK を使用する場合のみ、値を上書きします。
require-signed	false	署名されていないコミットがある場合に失敗させます。オフのままにすることをおすすめします。ブロッキングを有効にするを参照してください。
require-ai-disclosure	false	AI 支援を使用したかどうかを明記したコミットがない場合に失敗させます。ブロッキングを有効にするを参照してください。
fail-on-unsigned	false	require-signed の旧表記です。引き続き使用できます。

ブロックする設定

デフォルトでは、ここにある設定によってビルドが失敗することはありません。ほとんどのリポジトリでは、これが適切な設定です。レポートでビルドをブロックするリポジトリは、2 つのキーでオプトインし、Action と App の両方に対して一度だけ指定します。

# .github/rework-proof.yml
require_signed: true
require_ai_disclosure: true

• require_signed: true を設定すると、GitHub が検証できる署名のないコミットが 1 つでもある場合、チェックは失敗します。
• require_ai_disclosure: true を設定すると、プルリクエスト内に AI による支援を使用したかどうかを示すコミットが 1 つもない場合、チェックは失敗します。アシスタント名を示す Co-Authored-By: トレーラーがあれば条件を満たします。また、コミットメッセージに AI-Assisted: none の行がある場合も条件を満たすため、AI を使わずに作成されたプルリクエストでも、失敗するのではなく、そのことを示す方法があります。

ポリシーを有効にするのは文字どおりの true だけです。引用符で囲まれた "true" では有効になりません。App はデフォルトブランチからファイルを読み取るため、プルリクエストが自分自身に対してポリシーを有効または無効にすることはできません。ワークフローにチェックアウトがある場合、Action はチェックアウトしたファイルから同じ内容を読み取ります。チェックアウトのステップがないワークフローでは、代わりに同じ 2 つの設定を入力として渡せます。

jobs:
  proof:
    runs-on: ubuntu-latest
    steps:
      - uses: reworkio/REWORK-Proof@v1
        with:
          require-signed: true
          require-ai-disclosure: true

ファイルが存在し、いずれかのキーを設定している場合、そのファイルが設定のすべてとなり、入力は参照されません。ブロックするかどうかにかかわらず、指摘は同じ方法で報告されます。ポリシーによって変わるのは結論だけで、失敗メッセージには、その設定を求めたファイルまたは入力が記載されます。

出力

出力	説明
commits-total	調査したコミット数です。
commits-signed	検証可能な署名が付いているコミット数です。
commits-foreign	PR 作成者以外の人間のアカウントに帰属するコミット数です。
commits-automation	ボットアカウント（[bot] サフィックス）が作成したコミット数です。
ai-disclosed	メッセージで AI による支援を明示しているコミット数です。0 は明示がないことを意味し、使用されていないことを意味するわけではありません。
credential	attest が有効な場合の、署名済み VC-JWT です。

制限

コミットの読み取りは300 件で停止します。それを超えるプルリクエストは、問題なしではなく判定不能として報告されます。「すべて検証済み」とする不完全な読み取りは、誤解を積極的に招く唯一の失敗モードだからです。

ここを参照する証明は、それだけでは検証済みの状態を保てません

Action は 1 つのプルリクエストについて報告し、そこで終了します。GitHub リポジトリを参照する REWORK の証明は異なります。再度観測され、リポジトリが後から削除、非公開化、移管、またはブロックされると、証明は失効します。誰も開けなくなった証拠に対して「検証済み」と表示し続けることはありません。

広く適用するより、細かなルールが重要です。

• 同じオーナーによる名前変更は追跡されます。作業内容は変わらないため、ペナルティはありません
• 障害、タイムアウト、レート制限では何も失効しません。これらは私たちの問題です
• 何かを取り消すには、確定的な失敗が 2 回連続することが必要です

再チェックでは、意図的に匿名でリポジトリを読み取ります。検証は作成者自身のトークンで行われました。その後に問われるのは、購入者が今も証拠を開けるかどうかです。

チェックの「詳細」リンクの遷移先

App のみが対象で、意図的に制限されています。チェック実行は公開され、他人のプルリクエスト上に表示されるため、REWORK プロフィールへのリンクは、その人の同僚の前で行う身元の主張になります。このリンクが作成されるのは、両端が検証済みの場合のみです。つまり、GitHub が App をインストールしたアカウントを通知し、そのアカウントがセットアップリンクから REWORK にサインインしている必要があります。それに満たない場合は、公開証明ページにリンクし、概要に案内を表示します。これなら何の主張にもなりません。

自分で入力したプロフィール欄は参照されません。それを信頼すれば、誰でも他人のプルリクエスト上で自分を宣伝できてしまいます。

実装

依存関係のない Node ファイルが 1 つあります：src/main.js。dist/ のバンドルも、node_modules も、ビルド手順もありません。読んでいるものが、そのまま実行されます。

関連情報

ワークフローを追加せずにすべてのプルリクエストで自動検証するには、 REWORK Proof GitHub App を使用すると、チェック実行と同じ結果が投稿されます。

• GETTING-STARTED.md — Action、App、そして Hugging Face での公開物を、それを生成したビルドに結び付ける方法
• reworkdigital.io/github — GitHub 側でチェックする内容と、意図的に主張しない内容
• reworkdigital.io/huggingface — Hub 側：制御の手順と、ダウンロード数を鵜呑みにせず REWORK 自身が実行する再現可能な評価
• mcp/ — AI エージェント向けの、MCP を介した同じチェック

ライセンス

MIT — LICENSE を参照してください。