Rigour

Rigour

どのエージェントがコードを書いても、あなたのチームの働き方を知っているレビュアー。

エンジニアがどのエージェントを使っていても、その仕事はあなたのチームがソフトウェアをどのように作っているかに沿った形で届き、週を追うごとにあなたの基準に近づいていきます。

かつてチームは、その判断を人を介して受け継いできました。始める前にあなたに説明してくれた先輩、あなたが見落とした点を指摘してくれたレビュアー、前回の試みがなぜ失敗したのかを覚えていたエンジニア。コーディングエージェントは、人が説明し、レビューし、記憶できるよりも速くコードを書きます。知識は今もあなたのチームの中にあります。Rigour は、それがエージェントの働く速度で、すべてのエージェントに届くようにする仕組みです。

Claude Code、Cursor、Codex、Cline、Windsurf で動作します。無料のオープンソースで、あなたのマシン上で実行されます。

どのように実現するか

1. 書く前にブリーフィング。 エージェントがファイルを編集する前に、そのファイルに対してチームが何を求めているかを伝えます。あなたのリポジトリがそのファイルのために書いたルール、チームがそのファイルについて学んだ教訓、チームが結論を出した争点です。1 ファイルにつき最大 3 項目で、それぞれに出典が示されます。rigour setup でインストールされ（除外するには --no-brief）、MCP を備えた任意のエージェントでは rigour_brief を使います。詳しくはブリーフィングをご覧ください。
2. 書きながら、そしてプッシュ前に検証。 チームのチェックとルールが、あらゆるエージェントの作業をゲートします。すべての編集時、エージェントが「完了」と言う前、そして git push の前で、そこではフォーマッター、リンター、型チェック、さらにその変更に触れるテストも実行されます。オプトインで、その変更はプルリクエストが宣言したゴールに対してもチェックされます。スコープ外のファイル、「done when」の項目で未実施のものなどです。詳しくはゴールチェックをご覧ください。
3. チームのコンテキストで、チームの重大度でレビュー。 直近の人間によるレビューのすべての指摘を読み、その変更が触れる、あなたのリポジトリが書いた各ルールをチェックし、レビュアー自身の「Blocking / Should fix / Nits」を自身の読みよりも優先するレビュアーです。チームがブロックするものと見逃すものは、単一のグローバルな意見ではなく、あなたのリポジトリの設定です。詳しくはレビュアーをご覧ください。
4. 結果から学ぶ。 レビューの指摘が教訓になるのは、証拠があるときだけです。人がエージェントの作業を修正した、チームの誰かが判断を下した、あるいは複数の作者にまたがって再発した、といった場合です。マージ後に何が起きたか（その行に対する後日の修正、リバート）は、単独で昇格させるのではなく、判断するために人に提示され、チームが何度もクリーンにマージし続けている教訓は取り下げられます。学んだことは次のブリーフィングと次のレビューに流れ込みます。

1 つの作業は、どのエージェントと人が触れたとしても 1 つの タスク であり、rigour thread はそれに起こったすべてを表示します。コードが書かれている間に検出されプッシュ前に修正されたもの、何がブロックしたか、各レビューが何を見つけたかです。詳しくはタスクスレッドをご覧ください。

これは何であり、何ではないか

• 証拠からのみ学びます: ルールファイル、実際に対応されたレビューポイント、人による修正、そしてマージ後に何が起きたか。推測がルールになることはありません。
• エージェントを形作り、チェックしますが、モデルを変えることは決してありません。 トレーニングもファインチューニングもありません。どのエージェントでも、どのモデルでも。
• 具体的な好みはうまく捉えます（「ウィンドウは両端で境界を定める」、「スキーマを変更したらコードジェネレーターを再実行する」など）。設計上の好みはあなたの人々に委ねられます。Rigour がコードで示せないものは、せいぜい should-fix であり、決してブロックにはなりません。
• 1 台のマシン、複数の会社、何も交差しません。 プロファイルは、雇用主やクライアントごとのメモリ、レッスン、チームを分離し、作業中のリポジトリによって選択されます。プロファイルを参照してください。
• すでに書き留めているものから始まります。 初日には、ブリーフィングとレビュアーがあなたのリポジトリ自身のルール（AGENTS.md、CLAUDE.md、Cursor ルール、Copilot 指示）を引き継ぎます。レビューが証拠を与えるにつれてレッスンが加わるため、レビュー履歴が少ないチームはブリーフィングする内容も少なく始まり、ブリーフィングは有効にするまでオフです。

デフォルトで実行されるものと、そのコスト

	デフォルト	コスト
すべての編集時、および「完了」前、プッシュ前のチェック	rigour setup 後にオン	ローカル。編集後チェックは編集ごとに CLI を 1 回起動します
プッシュ前のチームのツール	オン	あなた自身のフォーマッター、リンター、型チェック、テスト
レビュアー	Studio または rigour.yml で有効にするまでオフ	あなたのエージェント自身のモデルとログイン。レビューごとに 1 回の長い読み取り。各レビューの記録にコストが表示されます
審査員のパネル	オフ。mode: full または panel: on	審査員ごとに 1 人の審査員のコスト、および意見が一致しない点についての短い尋問
OpenAI 互換 API 経由の審査員	オフ。reviewers: [api]	あなたのキーに対するプロバイダーの価格
ブリーフィング	rigour setup でオン（--no-brief、brief.enabled: false、または RIGOUR_BRIEF=0 でオフ）	モデルなし。資格情報スキャンがオンの場合、編集ごとに +22 ms、ファイルの初回編集時に +121 ms（Rigour 自身のリポジトリで測定）
タスクスレッド	フックが実行される場所ではどこでもオン	git フォルダ内のイベントごとに 1 行

仕組み

タイミング	Rigour が行うこと	何か問題がある場合
すべての編集時	ファイルに対する高速チェック：シークレット、存在しないインポート、証明済みのバグ	エージェントはすぐにそれを認識します
「完了」前	main に対するブランチ全体：修正すべき指摘、どこからも使われていないコード、危険なパターン、マージコンフリクト	エージェントは作業を続けます（最大 3 回）
git push 前	同じ内容に加えて、あなたのフォーマッター、リンター、型チェック、関連テスト、および記憶するレビュアー	プッシュがブロックされ、問題ごとに 1 行
プルリクエスト時	静かな安全網：最大 2 件のコメント、まだチェックされていないものに対してのみ	—

ブリーフィングがオンの場合、これらすべての前に 1 行が来ます。各ファイルの初回編集の前に、そのファイルに対してチームが何を求めているかです。

はじめに

まずは何が見つかるか確認しましょう。何も変更しません（作業中のブランチ上で）：

npx @rigour-labs/cli review --base origin/main

価値はありそうですか？ セットアップしましょう：

brew install rigour-labs/tap/rigour    # or: npm install -g @rigour-labs/cli
rigour setup                           # in your repository

rigour setup は Rigour をあなたのエージェントに接続し、3 つのモーメントをインストールし、すべてが動作することを確認します。デフォルトでは個人向けです：あなたの作業ツリーには何も書き込みません。エージェントフックはマシンごとに一度インストールされ、有効化していないリポジトリでは沈黙を保ち、このリポジトリを有効化しても .git/ の中にしか書き込みません。チームがクローンする全員に対して有効にしたい場合は、rigour setup --team を使うと代わりにリポジトリにコミットされます。どちらの場合も、既存のエージェント設定を置き換えるのではなく、それらにマージされます。気が変わったら？ rigour uninstall は、Rigour が入れたものだけを正確に取り出します。はじめにで手順を説明しています。

Rigour はバージョンごとに約 70 MB です。セマンティック検索（Linux で約 250 MB、macOS で 280 MB）は rigour setup によってマシンごとに一度インストールされ、すべてのバージョンで共有されます。--no-semantic でスキップできます。

Claude Code をお使いですか？ プラグインがすべてをやってくれます：

/plugin marketplace add rigour-labs/rigour-plugin
/plugin install rigour@rigour-labs

レビュー担当者も欲しいですか？ 誰かが有効にするまでオフであり、どこまで導入するかはあなたが選べます：Studio の Setup ページで自分用に、または rigour.yml でチーム全体用に：

review:
  reviewer:
    enabled: true
    mode: full          # one judge per vendor, up to `judges`; single (the default) is one judge
    panel: on           # only what most judges confirm blocks; required: no one may turn it off
    judges: 3           # 2 or 3, one per vendor installed
    escalate: risk      # add judges only for risky changes; measure it with rigour backtest first

チェックが通ればすぐにプッシュは完了します。その後、レビュー担当者はバックグラウンドでプッシュされたコミットを読み取ります（オープンでドラフトではないプルリクエストがある場合のみなので、誰かがプッシュを読むときにだけモデルのコストを支払います）。rigour review --status はその判定と実行された内容を表示します。rigour review --reviewer --full は、人にレビューを依頼する前の最終チェックです。チームが下限を設定している場合を除き、あなた自身の選択があなたの実行では優先され、Rigour はどの判定者が実際に実行されたか、そしてその理由を常に示します。

次に Studio を開いて、動作を確認しましょう：

rigour studio

使用するコマンド

コマンド	実行内容
rigour setup	リポジトリを準備し、動作することを確認します
rigour brief	このタスクの前にチームがエージェントに伝える内容：ルール、教訓、確定事項を、それぞれ引用付きで示します
rigour thread	タスクに何が起きたかを、エージェント、チェック、プッシュ、レビューをまたいで示します
rigour review	現在の変更、または PR を開く前のブランチをレビューします（--reviewer は記憶するレビュー担当者を追加します。--scope は、レビューが要求していないのに修正ラウンドで変更されたものを一覧表示します）
rigour studio	Rigour が何を止め、学び、あなたのエージェントに与えたかを表示します
rigour doctor	何が動作していて、何が動作していないか、そしてその修正方法を伝えます
rigour uninstall	Rigour が入れたものだけを正確に取り出します。あなた自身の設定と編集したファイルはそのまま残ります

それ以外はすべて rigour help --all にあります。

信頼できるように設計されています

• 根拠を示せる場合にのみブロックします。 決定論的チェックは、実際にマージされたプルリクエストを対象に実行した後にのみブロックします。モデルレビュアーの指摘は、誤った結果やコストを具体的に示す場合にのみブロックし、パネルを使う場合は、ほとんどの判定者が同意した場合に限ります。スタイルや規模に関する推測でブロックすることはなく、PR に表示されることもありません。
• 「バグではない」と一度伝えれば十分です。 その指摘が再び表示されることはなく、チームが繰り返し覆すチェックは自動的に静かになります。
• チェックできないときは、そのことを伝えます。 レビュアーから回答がない、レビュー対象がない、ツールがインストールされていない場合は、それぞれ明確に報告され、問題なしとして扱われることはありません。
• コードはお使いのマシンにとどまります。 チェックはローカルで実行されます。コードが外部に送信されるのは、選択したモデルに対してのみです。レビュアーにはエージェント自身の CLI を使い、モデルレビューをキーで実行する場合はプロバイダーを使います。チーム同期で送信されるのは、チーム自身のリポジトリから得た教訓だけです。Rigour が実行するすべてのネットワーク呼び出しと、それぞれを無効にする方法については、セキュリティをご覧ください。
• コストを確認できます。 モデルを使用すると、Rigour は実行ごとの実際のコストを記録します。
• 各判定者が把握していた情報を確認できます。 判定者はリポジトリと Rigour が提供する情報を読み取ります。Claude 判定者は個人の指示を読み込みません。判定者が個人の設定（Codex、Cursor）から隔離できない場合、レビュー記録にほかに読み取った情報が記載されます。
• 公開環境で測定します。 Rigour が検出する内容に関する主張は、公開されているdriftbench arenaで実際のプルリクエストを使って検証されています。
• お使いのレビュアーと比較して測定します。 rigour backtest は、チームがレビューしたコミットを使ってレビューを再実行します。レビュー内容を隠して採点し、レビュアーの指摘をどれだけ先に検出できたか、また、レビュアーが問題なしとした内容をブロックしたかどうかを確認します。バックテストをご覧ください。
• ブロックする条件は共通です。 レビュー、停止フック、プッシュゲートは同じルールに基づいて判断するため、指摘への対応が食い違うことはありません。

費用

Rigour は無料です。エージェントを使う場合、ほかに必要なものはありません。チェックはローカルで実行され、レビュアーとリスクの高い変更のレビューには、エージェント自身のモデルとログイン情報を使います。モデルキーが必要なのは、エージェントを使わずに書かれたコードのレビューと、プルリクエストボットを使う場合のみです。

チーム向け

プルリクエスト。 ワークフローファイルを 1 つ追加するだけで、Rigour がすべての PR を目立たない形でレビューします。必須チェックに設定すれば、PR 自身で指摘を無視したり、設定を緩めたりできなくなります。プルリクエストと CIをご覧ください。

全員に共通のセットアップ。 rigour setup --team で設定をコミットし、各チームメンバーはクローン後に一度 rigour setup を実行します。チームのセットアップをご覧ください。

共有ナレッジ。 Rigour を PostgreSQL データベースに接続すると、ある人のエージェントが学んだ教訓を、誰かの承認後にチーム全体で共有できます。送信されるのはチーム自身のリポジトリから得た教訓だけです。チームデータベースをご覧ください。

すでに教訓を共有しているチームに参加しますか？ まず、チームの Rigour 管理者に自分用のログインを依頼してください。設計上、自分でアカウントを追加することはできません。その後は、マシンごとに 1 つのコマンド、クローンごとに 3 つのコマンドを実行するだけです。既存のチームに参加をご覧ください。

一人ひとりに届くメリット。 シニアメンバーが書いたレビューコメントが、そのプルリクエストから次の変更時にチームメンバー全員のエージェントへと引き継がれます：チームのナレッジを、1 つのレビューからすべてのエージェントへ。

複数の会社で働いていますか？ プロファイルを使うと、作業中のリポジトリに応じて、各社のメモリー、教訓、チームを分けて管理できます。プロファイルをご覧ください。

詳細を見る

次のことをしたい場合は…	こちらをお読みください
Rigour を手順に沿ってインストールして実行する	はじめに
このリリースでの変更点とアップグレード方法を確認する	リリースノート
作業中に指摘事項へどう対処するかを知る	開発中の対応
チーム全体で使えるように設定する	チームのセットアップ
CI ですべてのプルリクエストをレビューする	プルリクエストと CI
対応しているエージェントと MCP ツールを確認する	コーディングエージェントと MCP
1 人のジャッジからパネルまで、レビュアーを実行する	レビュアー
独自のモデルキーまたはローカルモデルを使う	モデルレビュー
Rigour のチェック内容を調整する	設定 · すべての設定項目
すべてのチェック内容と、精度を誠実に保つ方法を確認する	Rigour のチェック内容
組織で利用するために承認する	セキュリティとネットワークの利用 · テレメトリ：オプトイン、匿名、コードは送信されません
1 台のマシンで複数の企業にまたがって作業する	プロファイル
すべての情報を見る	ドキュメントの索引

ソースからビルドする

pnpm install
pnpm build
pnpm test

貢献方法をご覧ください。

---

ドキュメント · ディスカッション · 課題

MIT © Rigour Labs · Ashutosh によって開発