release-gate

release-gate

AI システムのための独立したアドミッションコントローラーです。

Release-Gate は、コードレベルのエージェントリスク、外部評価、ランタイムトレース、ガバナンスの証拠、検証結果、人間による承認を統合し、監査可能な PROMOTE / HOLD / BLOCK の判定を行います。証拠を生成したツールをチームが置き換える必要はありません。

PROMOTE は、候補が宣言されたリリースポリシーを満たしており、判定に記載された証拠と不足があることを意味します。リリースが安全であるという表明では決してありません。

 code-level agent risk     SARIF from your scanner, or release-gate's own ──┐
 external evaluations      promptfoo, ProofAgent, red teams, eval harnesses ─┤
 runtime traces            OpenTelemetry, Langfuse, Arize-Phoenix ───────────┤   one candidate state,
 verification results      tests, provers, model checkers ───────────────────┼─▶ one claim graph,      ─▶ PROMOTE / HOLD / BLOCK
 governance evidence       governance.yaml, the pinned AIBOM ────────────────┤   one declared policy      + the Admission Report
 human approvals           reviews and approvals of this exact candidate ───┘

どこに位置するか

それぞれが異なる問いに答えます。Release-gate は、他のツールの結果を出所が明示された証拠として読み取り、最後の問いに答えます。

ツール	答える問い
リンター	コードは適切に書かれていますか？
SAST	コードに既知の脆弱性パターンが含まれていますか？
ガードレール	このライブインタラクションを許可すべきですか？
評価ツール	これらのテストでエージェントはどのように振る舞いましたか？
オブザーバビリティ	システムの実行時に何が起きましたか？
Release-Gate	証拠によって、この特定の候補がリリースポリシーを満たすと立証されていますか？

これらのツールを再実行したり、再評価したり、置き換えたりすることはありません。promptfoo の結果は promptfoo のものであり、スキャナーの検出結果はそのスキャナーのものです。また、Admission Report には、release-gate 自身が生成した証拠と、別のツールから読み取った証拠が示されます。エージェントコード用の独自スキャナーも証拠の生成元の一つであり、製品そのものではありません。

判定が示すこと

	意味
PROMOTE	候補は記載された証拠に基づいて宣言されたリリースポリシーを満たしており、記載された不足はポリシーが許容するものです
HOLD	人が先に解決すべき事項が明示されており、それを解決するための証拠も示されています
BLOCK	ポリシーに違反しています。チェックの失敗、有効な反例、またはポリシーがブロック対象とする矛盾が該当します

不明は決して合格ではありません。すべての判定で、評価されなかった内容が示されます。また、リリースの別の状態に関する証拠は、この状態の判定にはカウントされません。判定は、宣言されたポリシーと証拠から決定論的に導かれます。証拠を読み取るようモデルに依頼することはできますが、その読み取りが判定を左右することはありません。

仕組み

flowchart LR
  subgraph own["Release-gate's own checks"]
    direction TB
    o1["AST / taint scan"] ~~~ o2["PR diff"] ~~~ o3["governance"] ~~~ o4["trace validation"] ~~~ o5["loop sim, agent score"]
  end
  subgraph ext["Your tools"]
    direction TB
    e1["evals, red teams"] ~~~ e2["traces, SAST"] ~~~ e3["proofs, reviewers"]
  end
  sem["Semantic verifier<br/>bounded questions<br/>UNKNOWN on any failure"]
  case["AssuranceCase<br/>claims, evidence, assumptions,<br/>contradictions, counterexamples,<br/>failed branches, coverage, independence"]
  own --> case
  ext --> case
  sem -. "a reading, never a verdict" .-> case
  case --> policy{"declared<br/>policy"} --> out["PROMOTE / HOLD / BLOCK"]

不変条件。 Release-Gate は、証拠を生成、取り込み、正規化、比較し、範囲が限定された証拠を意味的に解釈し、証拠がポリシーを満たすかどうかを判断できます。ただし、単一のモデル、単一のスキャナー、単一の評価ツール、単一のスコア、または単一のテスト成功を、普遍的な真実を立証するものとして扱ってはなりません。

各クレームは一つのステータスに帰着し、宣言されたポリシーによって、どのステータスが認められるかが定められます。

flowchart LR
  ev["the evidence<br/>on one claim"] --> claim{"a claim"}
  claim -- "a valid counterexample<br/>(outranks any support)" --> c["CONTRADICTED"]
  claim -- "a bound proof, or two<br/>independent groups of checks" --> e["ESTABLISHED"]
  claim -- "support short of that" --> s["SUPPORTED or<br/>PARTIALLY_SUPPORTED"]
  claim -- "only support about<br/>another state" --> u["UNSUPPORTED"]
  claim -- "inconclusive or unreadable" --> k["UNKNOWN"]
  claim -- "nothing bears on it" --> n["NOT_ASSESSED"]

スコアは入力に含まれず、同一セッション内の同一テストのコピーは一度だけカウントされます。ARCHITECTURE では、各ボックスに対応するコードを示しています。tests/test_product_invariant.py は、不変条件のすべての条項を実行します。

試してみる

pip install release-gate
release-gate assure your-run.jsonl        # no config file, no YAML, no account

OpenTelemetry のトレース、Langfuse のエクスポート、promptfoo の結果、または release-gate 独自の記録形式で動作します。形式は宣言するのではなく、自動で判別されます。判定結果、人が確認する必要のある内容、そして解決に必要なものが表示されます。

パイプラインでは、リリースの主張とパイプラインが生成したすべてのものを合わせて判定します。

release-gate assure release.jsonl --evidence evidence/ \
  --methodology [email protected] --admission

終了コードは、PROMOTE が 0、HOLD が 10、BLOCK が 1 です。CI テンプレートは GitHub Actions、GitLab、Jenkins、CircleCI、Azure Pipelines に対応しています。

release-gate 自身のチェックも証拠になります。pr、verify、 loop-sim、agent-score の --json は、他のツールの出力と同様に読み取られます。自らの判定で昇格するリリースと、ガバナンスファイルで禁止されているツールを呼び出したトレースを見てみましょう。

# examples/evidence/first-party/verify.json was written by
#   release-gate verify governance.yaml --trace trace.json --iteration 2 --cost 0.06 --json
release-gate assure examples/agents/02-release-promoted.jsonl \
  --evidence examples/evidence/first-party/verify.json \
  --methodology [email protected] --admission

  Decision     BLOCK
               BLOCK under [email protected] and rg-resolution@1: 2 blocking condition(s) established — RG-CONTRA-002 (contradictions, on rg-trace:run-2291); RG-VERIF-002 (claim_status, on rg-trace:run-2291)

ブロックの原因は失敗したトレースチェックであり、検証器自身の ROLLBACK ではありません。その判定は記録されますが、何の決定にも影響しません。

事前のインストールは不要です。ブラウザーのデモに実行結果をドロップしてください —同じエンジンが実行され、3 つのサンプル実行は examples/assurance/内のファイルとバイト単位で一致します。

または、実例を実行してみてください。6 つのツール、1 つのリリース、1 つの決定では、 5 つのツールが好ましい結果を報告しても、表示される理由によって決定は保留になります。5 つのエージェント実行では、OpenTelemetry のトレース、promptfoo の評価、破壊的なマイグレーション、リサーチスウォーム、そして昇格する実行を取り上げます。

python examples/demo-admission/run_demo.py
cd examples/agents && ./run-all.sh

それぞれが実証する内容 →

製品の受け入れテストもあります。エンドツーエンドで見るエンタープライズリリースでは、 あらゆる種類の証拠を対象に、お金を動かすツールを使う AI 生成コードを審査します。 リリース責任者が尋ねるすべての質問に答え、スコア、モデルの判断、テスト数のいずれも、含まれている反例より優先されないことを示します。

python examples/acceptance/run_acceptance.py

---

スキャナーやスコアではできない 3 つのこと

1. 機械による作業を、人が実際に読めるリストにまとめます

200 万件の記録はレビューできません。200 万件の記録をもとにしたスコアもレビューできません。誰も下していない判断を、1 つの数値で表しているだけです。

release-gate は、実際に決定の根拠となった主張に基づき、人による確認が必要な項目を上限付きで返します。

	個別の生成元	確認した記録	証拠	主張	人に届く項目
1 つのエージェント、1 つのアクション	4	7	6	0	1 項目
10,248 のワーカー	10,254	2,287,133	10,258	2,420	13 項目、うち 7 項目は削除不可

この表の数値はすべてテストスイートで計測したもので、手作業で記載したものではありません。実装と食い違う主張があれば、テストは失敗します。

重要度は量ではなく、主張グラフ内の到達可能性から判断します。1 つのエージェントが一度出した主張も、400 のエージェントが議論した主張とまったく同じく、根拠として重要です。

**リストが短いからといって、より良い事例とは限りません。**これは、別の結果を返せないようコードで保証されている性質です。この表を読み違える危険な方法は、数値が小さいほど良いと考えることです。検出能力が低下した結果かもしれません。

2. すべての判定で、確認していないことを示します

多くのツールが省略するのはこの部分です。確認範囲を明示しない合格判定は、そもそも何も確認しなかった合格判定と区別できません。

WHAT WAS ASSESSED
  [    assessed]  input_integrity: the input file was hashed by release-gate
  [    assessed]  record_mapping: 6 of 6 record(s) mapped; 0 skipped
  [NOT_ASSESSED]  execution_reconstruction: no execution graph was reconstructed
  [NOT_ASSESSED]  replication: no verification attempt names a target
  [NOT_ASSESSED]  adversarial_review: no verifier set out to disprove this

NOT_ASSESSED は第一級の回答であり、エンジンのどこでも「確認したが何も見つからなかった」と明確に区別されます。UNKNOWN も同様です。また、反証されたチェックと未解決のチェックも区別されます。これらをひとまとめにすると、見落としが問題のない状態に見えてしまいます。

3. 保留する場合は、作業指示を返します

単に拒否するだけのゲートは、ただの小言です。各項目には、解決に必要な内容が付いています。

[BLOCK]    RG-ACT-001    'execution_reconstruction' is stated as NOT_ASSESSED
             → supply the run's trace or tool-call log

[ADVISORY] RG-PROV-002   all evidence traces to a single producer
             → add evidence from an independently-operated producer

このリストは機械可読形式（--json）でも取得できるため、次のエージェント実行で証拠を取得できます。何が不足していたかを把握するために、人が事例を読み直す必要はありません。

伝えないこと

リリースが安全であるとは伝えません。結果が必ず正しいとも伝えません。ゲートがハッキング不可能とも伝えません。エンジン自体に対して20件の攻撃を実行し、そのうち1件は、代わりに何がその範囲を制限するのかとともに NOT_DEFENDED と記録されています。ケースに異論がない、幻覚が解決済み、あるいは専門家が不要になったとも伝えません。出力は、人が対応する必要のある項目の一覧です。

拒否の一つひとつは、それ以外の値を返せないコード上の特性です。 docs/POSITIONING.md では、それぞれを強制する行とともにすべて示しています。

---

Python から

import release_gate as rg

case = rg.create_case(objective="Deploy generated migration", subject=migration)
case.add_execution(trace)                       # the steps, or a native trace
case.add_verification(test_result, method="TEST_SUITE", outcome="PASSED",
                      verifier="ci://pytest", against_subject=True)

decision = case.finalize()     # PROMOTE / HOLD / BLOCK, with its coverage attached
print(decision.required_evidence)

同じ4つの呼び出しで、1つのエージェントによる移行にも、1万人の作業者による調査にも対応します。名前だけを共有する2つの製品ではなく、1つのコードパスです。346個のエンジン関数が両方に共通しており、単一エージェントのパスが扱うすべてのうち87%を占めます。

---

設定

実行に必須のものはありません。構造を判定結果に変えるのが方法論です。方法論がなければ、release-gate は確認できる構造上の情報をすべてレポートし、保留します。「これで十分か？」はドメインに関する問いであり、答えを作り出すことは、存在しない基準を持っていると主張することになるためです。

release-gate assure --list-methodologies
release-gate assure run.jsonl --methodology [email protected]

1つの入力、4つの評価基準、4つの回答。それぞれに不足しているものが示されます。

方法論	判定	未達事項
(なし)	HOLD	METHODOLOGY_REQUIRED
[email protected]	BLOCK	実行記録なし
[email protected]	HOLD	構造上の検出事項のみ
[email protected]	BLOCK	機械検証、仮定、独立性

組織設定（--config）は、独自の基準を上乗せするもので、厳格化することしかできません。方法論、解決ポリシー（--resolution-policy：主張を確立するために必要なこと、反例をどう扱うか）、組織設定を合わせたものが、PROMOTE の判定基準となる宣言済みリリースポリシーです。それぞれの内容がケースに記録されます。

📖 詳しい手順：入力、出力、設定項目 →

---

判定を支えるもの

上記の入場判定が成果物です。以下はその証拠を生成または運ぶもので、それぞれの詳細は専用の場所に記載されています。

外部証拠	評価、レッドチーム、SAST、形式検証、レビュー、行動評価、封じ込めドリルを、それぞれ文書化された契約を通じて扱います。読み込んで出典を明記し、再実行はしません
トレースと評価データの取り込み	OpenTelemetry · Langfuse · Arize-Phoenix · promptfoo をそのまま読み込みます。専用ファイルも新たな計測も不要です
エージェントコードのスキャン	リリースゲート独自の証拠生成機能で、コードレベルのエージェントリスクを検出します。モデル出力から eval／pickle への到達、取得したテキストからプロンプトへの到達、上限のない LLM ループを AST と汚染解析で調べます。独自の93 ケースコーパスで測定しています
release-gate pr	プルリクエストが 新たに導入した ものに対する単一の判定です。新規のエージェントリスクのみを対象とし、既存の負債は表示しますが、ゲートにはしません
Release-gate のその他のチェック	PR 差分分析（pr）、トレース検証（verify --trace）、ループシミュレーション（loop-sim）、エージェントスコア（agent-score）です。それらの --json は、他の生成元と同様に assure --evidence が読み込む証拠です。それぞれの判定とスコアは記録されますが、何も決定しません
セマンティック検証	任意です。モデル、または独立した複数のモデルで構成されるパネルが、ルールでは扱えない証拠を読み取ります。その読み取り結果は記録されますが、判定は行いません。意見の相違は人に委ねられます
署名付き証拠	生成元は出力に署名します（release-gate sign、DSSE／in-toto）。assure --trusted-keys は、各署名を名前付き生成元に対して信頼された鍵と照合し、署名に失敗した証拠は読み込みません
デプロイ時チェック	release-gate deploy-check は、実行中のものと入場判定で承認された状態を比較します。一致が確認できないものは合格しません
インシデントとドリル	本番環境での障害は反例となり、それ以降のすべてのリリースで対応が必要になります。記録されたキルスイッチのドリル（containment/1）が、「停止できる」ことの証拠です
多様性厳格モード	--resolution-policy diversity-strict@1：重要な主張には、独立した2つのチェックグループが必要です。プロバイダーが共通する場合は1グループとして数え、さらに作成者以外によるチェックも必要です
証拠パック	evidence-pack は JSON、Markdown、HTML を出力します。封印されたケース（--case-output）はコンテンツアドレス指定され、検証可能です。署名しない限り、いずれにも署名は付きません
GitHub Action · MCP サーバー	Action では command: assure を使用します。pip install 'release-gate[mcp]'
ベンチマーク	スキャナー、保証レイヤー、セマンティックプロバイダーを個別に測定しています。保証コーパスでは、ケースの大半で精度を測定する意味がないため、代表的な精度の数値は公表していません

---

ドキュメント

デモとインテグレーションの手順	入力、出力、設定
位置付け	すべての主張と、それを担保する境界
アーキテクチャ	エンジンの構成
リファレンス	コマンドと機能の全リファレンス
変更履歴	リリース履歴
コントリビューション · セキュリティ

開発

git clone https://github.com/VamsiSudhakaran1/release-gate
cd release-gate && pip install -e '.[dev]'
pytest -q

ライセンス

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