opendrs

opendrs：PR の影響範囲分析と、安全な自動承認のためのリスクスコア

すべてのプルリクエストに、調整済みの 0～1 のリスクスコアを付与します。AI によるレビュー済みで影響範囲の小さい PR は自動承認してマージキューに送る一方、リスクの高い PR は人間の確認を待たせることができます。

AI エージェントは、人間が読むよりも速くコードを作成・レビューするようになり、人間によるレビューがボトルネックになっています。ほとんどのプルリクエストは低リスクですが、インシデントの大半は一部の PR が引き起こします。opendrs は、各 PR の影響範囲とリスクを測定します。変更が及ぶ対象、変更ファイルに依存するファイル数、変更対象ファイルの履歴、作成者の経験、テストの不足、重要なパスなどを確認します。これらの情報を、自分たちの git 履歴に基づくシグナルを使って 0～1 のスコアに変換します。チームはその後、ポリシーを設定します。たとえば、スコアが 0.3 未満で AI レビュー（Claude、CodeRabbit、Copilot、または任意のチェック実行）に合格した PR は承認され、マージキューまたは自動マージに送られます。リスクの高い PR は、引き続き人間の確認を待ちます。この手法は Meta の Diff Risk Score（DRS）に準拠しています。opendrs は、ホストするサービスが不要で、あらゆる git リポジトリで実行できる独立したオープンソース実装です。

目次： インストール · クイックスタート · 仕組み · 機能 · 結果 · CLI と MCP · ドキュメント · 制限事項 · 他のツールとの比較 · 先行事例

インストール

使用方法	コマンド	詳細
GitHub Action	uses: error-path/opendrs@v0 (Marketplace)	コメントとラベルを追加し、オプションで承認とマージを行います。GitHub Action のリファレンス
CLI	npx @error-path/opendrs score	CLI、MCP サーバー、Claude Code プラグイン、エージェントスキル
MCP サーバー（任意のエージェント）	npx -y @error-path/opendrs mcp	ツール：score_diff、explain_file_risk、list_hotspots、suggest_reviewers
Claude Code プラグイン（スキルと MCP サーバー）	/plugin marketplace add error-path/opendrs、続けて /plugin install opendrs@opendrs
エージェントスキル（Claude Code、Cursor、Codex など）	npx skills add error-path/opendrs	skills/opendrs/SKILL.md
Docker（stdio 経由の MCP サーバー）	docker build -t opendrs . && docker run -i --rm -v "$PWD:/repo" opendrs	スコアを計算するリポジトリを /repo にマウントします

ウェブサイトとガイド：error-path.github.io/opendrs。

クイックスタート

設定や API キーは不要です。現在のブランチをデフォルトブランチと比較してスコアを計算します。

npx @error-path/opendrs score

スコア、ティア（緑、黄、赤）、スコアに影響したシグナルとその根拠、ポリシーの判定が表示されます。--json は完全な結果を出力し、--fail-above 0.6 を指定すると、しきい値を超えた場合にコマンドは終了コード 1 で終了します。

すべてのプルリクエストのスコアを計算するには、.github/workflows/opendrs.yml を追加します（または npx @error-path/opendrs init を実行します）。

name: opendrs
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review, labeled, unlabeled]
permissions:
  contents: read
  pull-requests: write
  checks: read
jobs:
  opendrs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0   # required: the score reads past commits and authors
      - uses: error-path/opendrs@v0

この設定では、コメントとラベルの追加のみを行います。デフォルトブランチの .opendrs.yml で有効にするまで、承認はオフです。低リスク PR を自動承認する方法とGitHub Action のリファレンスを参照してください。

仕組み

flowchart LR
  diff["git diff<br/>merge-base...head"] --> signals
  hist["git history"] --> signals
  graph["import graph"] --> signals
  llm["LLM judge<br/>(optional)"] --> signals
  signals["Signals<br/>each with evidence<br/>and provenance"] --> model["Logistic model<br/>score = sigmoid(b + Σ w·x)"]
  model --> tier["Tier<br/>green / yellow / red"]
  tier --> policy["Policy<br/>blocks, size cap, unknowns,<br/>AI review, sampling"]
  policy --> decision["auto-approve<br/>deferred-review<br/>waiting-ai-review<br/>human-review"]

1. シグナル。 各シグナルプロバイダーは差分、履歴、インポートグラフを読み取り、特徴量を出力します。特徴量には、変更の規模や広がり、変更対象ファイルにおける過去の修正やリバート、そのファイルに関する作者の経験、複雑さ、影響範囲（推移的な依存先）、重要なパス、テストの不足が含まれます。各シグナルには、取得方法（observed、derived、inferred、unknown）とその根拠が記録されます。すべてのシグナル
2. モデル。 ロジスティック回帰によって特徴量を確率に変換します。各シグナルの寄与 w·x が報告されるため、PR がそのスコアになった理由を確認できます。初期状態では重みは手動で設定された事前分布ですが、opendrs calibrate を使うとリポジトリに合わせて調整できます。 キャリブレーションとバックテスト
3. ティア。 スコアは、Meta のゲートに倣った緑、黄、赤に分類されます。しきい値には、絶対スコアまたは独自の履歴におけるパーセンタイルを使用できます。
4. ポリシー。 順序付きのルールによって、スコアを判定に変換します。ポリシーと安全策

opendrs が PR のワークフローで果たす役割

現在、PR は人間が確認する前に、AI によるレビューを2回受けることがよくあります。この2回のレビューでは、誤字、null チェックの漏れ、明らかなオフバイワンなど、局所的な欠陥を検出します。人間が PR を開く頃にはそうした作業は済んでおり、残っているのは、以前より少ないコンテキストで行う設計やアーキテクチャに関する判断です。opendrs はその場面のために作られています。PR にどれだけ注意が必要かを最終確認者に伝え、アーキテクチャや履歴に関する事実を最大5つ提示します。たとえば、モジュール間に新たなインポートがあること、公開コントラクトが壊れていること、PR で変更されていないファイルと通常一緒に変更されるファイルがあることなどです。こうした情報は、エディターにも AI のレビューコメントにも示されません。キャプテン向け概要を参照してください。

機能

機能	内容	デフォルト	ドキュメント
リスクシグナル	サイズ、差分、ファイル履歴、作成者の経験、複雑さ、影響範囲、重要なパス、テスト、言語	有効	シグナル
キャリブレーションとバックテスト	過去の履歴に合わせて重みを調整し、ゲート対象を 5 / 10 / 50 % にした場合の検出率を測定します	必要に応じて実行	キャリブレーション
ハードブロックとセーフティレール	ブロック対象パス、バイナリ、サブモジュール、自己変更ガード、サンプリング、承認の古さのチェック	有効	ポリシー
自動承認	AI レビューの合格後にグリーン PR を承認し、自動マージまたはマージキューに送ります	無効	自動承認ガイド
LLM 判定	すべてのハンクを安全またはリスクのカテゴリに分類します。スコアを引き上げることしかできません	無効	LLM 判定
requireSafe ゲート	判定がすべてのハンクを十分な信頼度で安全と判断した場合に限り、自動承認します	無効	LLM 判定
ソース別ポリシー	人間、ボット、AI エージェントの PR に、それぞれ独自のより厳しいグリーン基準、日次上限、実績を適用します	無効	ポリシー
レビュー延期	グリーン基準をわずかに上回る PR を先にマージし、マージ後にレビューします	無効	ポリシー
ランディング遅延	承認対象の PR に一定の待機時間を設け、人間が却下できるようにします	無効	ポリシー
凍結期間	週末や繁忙期に自動承認を一時停止、または厳格化します	無効	ポリシー
コンテンツブロックリスト	追加行に含まれる正規表現に一致した場合、PR を人間のレビューに回します	無効	設定
レビュアーの割り当て	リスクの高い PR のレビューを、上位 3 名の専門家のうち 1 名に依頼します	Action では有効	ポリシー
ホットスポット	ファイルを平常時のリスク順に並べます	必要に応じて実行	CLI と MCP
レビューブリーフ	最初に読むべきハンク、固定の確認質問、ざっと読める箇所の一覧、ハードルールの理由を提示します。claude-code-action、Bugbot、CodeRabbit（一部対応）、Copilot、Codex（貼り付け）向けのレシピも含みます	有効	LLM レビュアー、CLI と MCP
インシデントのフィードバック	opendrs feedback でインシデントを記録し、キャリブレーションに活用します	必要に応じて実行	キャリブレーション

すべての設定は .opendrs.yml に記述されます。PR が自身のゲートを緩和できないよう、ベースブランチから読み取られます。 設定リファレンス。

結果

ベンチマーク	結果	詳細
ApacheJIT（Apache の Java プロジェクト 15 件、公式の 2017～2019 年テスト期間。正例ラベルがないため apache/hadoop は除外）	キャリブレーション済み opendrs：AUC 0.823。最もリスクの高い 30 % でバグのあるコミットの 67 % を検出。従来の JIT 指標による回帰モデル（0.821、66 %）と同等	ApacheJIT の結果
LLM 判定を使用した ApacheJIT（Claude Sonnet 5、サンプリングしたテストコミット 800 件）	信頼度 8 の場合、判定がすべて安全としたコミットにバグが含まれる割合は 5.3 %。ベースラインの 25.5 % に対して低い結果です	構造化 LLM 判定を使用した場合
パブリックリポジトリ 27 件（キャリブレーション後にバックテスト）	初回実行の 9 リポジトリすべてで、キャリブレーションにより保留したコミットに対するデフォルトの事前分布を上回りました	ベンチマーク結果

CLI と MCP

コマンド	内容
opendrs score	merge-base(base, head)..head をスコアリングします
opendrs explain <file>	ファイルの履歴、修正、作成者、依存先、パスのポリシーを表示します
opendrs hotspots	ファイルを平常時のリスク順に並べます
opendrs calibrate / opendrs backtest	モデルを過去の履歴に合わせて調整し、デフォルトモデルとキャリブレーション済みモデルを比較します
opendrs feedback	インシデントを .opendrs/incidents.jsonl に記録します
opendrs init	コメント付きの .opendrs.yml と、コメントのみのワークフローを書き込みます
opendrs mcp	MCP サーバーを実行します

フラグ、終了コード、MCP ツール、エージェントスキル：CLI、MCP サーバー、Claude Code プラグイン、エージェントスキル。

ドキュメント

ページ	読むとわかること
低リスクの PR を自動承認する	リスクに基づく承認ゲートを段階的に設定する方法
GitHub Action リファレンス	入力、出力、権限、ブランチルール、定期スイープを確認する方法
ポリシーと安全策	PR が承認されたかどうかの理由を正確に把握する方法
設定リファレンス	.opendrs.yml を変更する方法
リスクシグナル	opendrs が測定する項目とその方法を確認する方法
PR の影響範囲とは？	影響範囲を理解する方法
LLM ジャッジ	オプションの LLM ジャッジまたは requireSafe ゲートを有効にする方法
レビュー概要を LLM レビュアーに渡す	opendrs の調査結果を Claude Code、claude-code-action、Bugbot、CodeRabbit、Copilot、Codex に提示する方法
キャプテン概要	最終的な人間のレビュアーに表示される優先度、レビュアー、アーキテクチャや履歴に関する情報を確認する方法
キャリブレーションとバックテスト	モデルをリポジトリに適合させ、しきい値を選ぶ方法
ベンチマーク結果	公開リポジトリで opendrs がリスクをどのようにランク付けするかを確認する方法
実験	試したことと、うまくいかなかったことを確認する方法
CLI、MCP サーバー、Claude Code プラグイン、エージェントスキル	opendrs をローカルまたはエージェントから実行する方法
既知の制限事項	opendrs で確認できないことを把握する方法
他のツールとの比較	opendrs と他の PR リスクツールから選ぶ方法
CHANGELOG	各リリースでの変更内容

制限事項

• デフォルトの重みは、あなたのコードに合わせて調整されていません。 信頼して使う前に backtest を実行し、十分な履歴が得られたら calibrate を実行してください。
• ラベルはインシデントの代替指標であり、小規模なリポジトリでは数値が不安定になります。
• スコアはコードレビューではありません。 変更が正しいかどうかではなく、インシデントが発生する可能性を推定します。

一覧はこちらです：既知の制限事項。

他のツールとの比較

求めるもの	使用するもの
自分の履歴に基づいて測定し、ホストするサービスが不要な、低リスクの PR を承認またはマージするリスクゲート	opendrs
ゲートとして各 PR を判断する LLM	PR-Agent の自動承認、Merge Steward、MergeShield Risk Check。opendrs のオプションの LLM ジャッジはスコアを上げることのみ可能です
チームプランで Cursor のクラウド内での承認	Cursor の承認エージェント
コードへのレビューコメント	AI レビュアー（Claude Code、CodeRabbit、PR-Agent）と、その後に実行する opendrs

各ツールのスコア付け方法と実行場所を含む詳細な比較は、 error-path.github.io/opendrs/alternatives.html をご覧ください。

先行研究とクレジット

• Meta の Diff Risk Score。 Diff Risk Score: AI-driven risk-aware software development （Engineering at Meta、2025 年）および Abreu らによる Moving Faster and Reducing Risk: Using LLMs in Release Deployment（2024 年）。機能セット、段階的なゲート、X％のゲート通過時に計測する指標は、この研究に基づいています。opendrs は Meta と提携していません。
• Meta の RADAR。 Adams らによる Automating Low-Risk Code Review at Meta （2026 年）：安全カテゴリとリスクカテゴリを備えた構造化 LLM レビュアー、ソースごとのポリシー（1 日あたりの上限、実績）、レビューの延期、ランディングの遅延、コンテンツのブロックリストは、この論文に基づいています。hotspots とレビュアーの割り当てに関連する Meta の研究：Mockus ら、「Metrics Driven Reengineering and Continuous Code Improvement at Meta」（ASE 2025）；Paraspatki ら、「Code Reviewer Recommendation for High Risk Diffs at Scale」（FSE Companion 2026）；Rigby らによる Improving Code Reviewer Recommendation（TOSEM 2025）。
• ベンチマークと関連研究。 Keshavarz と Nagappan による ApacheJIT （MSR 2022）では、データセット bench/apachejit/ を採点します。Sayedsalehi、Rigby、Mockus による DRS-OSS（2025 年）は、ベンチマークが数値を引用する、オープンソース版の LLM の同等研究です。
• ジャストインタイムの欠陥予測と SZZ。 Mockus と Weiss、「Predicting risk of software changes」（2000 年）；Śliwerski、Zimmermann、Zeller、「When do changes induce fixes?」（2005 年）；Kamei ら、「A large-scale empirical study of just-in-time quality assurance」（2013 年）。変更レベルの特徴量と SZZ 方式のラベル付けは、この研究分野に基づいています。
• REA（morluto/rea）。opendrs は、エビデンスを優先する REA の手法を採用しています。すべての結論に「観測済み」「導出済み」「推論済み」「不明」のいずれかを付け、「不明」を安全とみなすことはありません。また、ドメイン型、プロバイダー、共有エンジン、薄いアダプターという REA のレイヤー構成にも従っています。

ライセンス

MIT