AIコーディングのおかげでコードを書くスピードは上がりましたが、開かれるPRの数も比例して増え、レビューできる人の数は変わりません。その結果、コードを書くことではなく「レビュー」こそが新しいボトルネックになっています。
そこで生まれたのがOpen-PRです。Pull Requestのレビューに特化したオープンソースのAIエージェントで、SaaSサービスや専用のbotアカウントではなく、Claude Code、Cursor、Codex、Gemini CLI、Antigravityといった使い慣れたCLIエージェント上でそのまま動作します。
開発者がPRを開く → AIが一次レビューを行う → 最終判断はレビュアーが下す → マージ
コードレビューを行うAIエージェントはすでに数多く存在します。ではOpen-PRは何が違うのでしょうか。
ありがちな「汎用レビュープロンプト」ではない
多くのレビュー系skill/agentは、「注意深くレビューして」とAIに指示するだけの説明ファイル(SKILL.md)にすぎません。問題は、実行するたびに厳しさがバラバラで、しかもそのプロジェクト固有の規約についてほとんど何も知らないことです。
Open-PRが違うのは、あるリポジトリで初めて実行された時点で、README、CLAUDE.md、AGENTS.md、ドキュメント、wikiを読み込み、そのプロジェクトの本当の規約を理解する点です。そして、チーム固有のルールは常に一般的なルールより優先されます。さらにリポジトリ単位の記憶も持っており、チームが過去に指摘したことや合意した内容はすべて記録され、次回以降のレビューで同じことを繰り返し言う必要がありません。そのおかげで、いつ実行しても一貫した「トーン」——そのプロジェクトならではのトーン——を保ち続けられます。
フレンドリーかつ丁寧なやり取り——まるで二人でコードについて話しているように
Open-PRの一番の特徴は、見つけたバグの数ではなく、PR上での「会話」をどう継続させるかにあります。
従来型のAIレビューは、コメントの塊を投げつけて終わりというケースがほとんどで、再実行すればまたゼロからレビューし直し、同じ指摘を繰り返すことも珍しくありません。Open-PRはそこが違います。同じPRに対して2回目の/open-pr:reviewを実行すると、過去のスレッドを一つひとつ読み直し、すでに指摘した内容が対応済みかどうかを確認します。修正されていればそのスレッド上でその場で確認し(設定を有効にしていれば自動でresolveすることも可能)、未対応ならあえて繰り返さず沈黙を保ちます。新しいレビューは、直前に変更された部分についてのみ言及します。
さらに興味深いのが/open-pr:fixです。コメントが来たらとりあえず従う——たとえそのコメントが間違っていて、正しいコードを壊してしまう場合でも——という動きはせず、Open-PRはまずそのfindingが妥当かどうかを自分で判断します。妥当であればリポジトリの規約と記憶に沿って修正し、そうでなければ根拠を添えて同じスレッドに返信します。レビュアーの言いなりになるのではなく、レビュアーに反論するエンジニアのように振る舞うわけです。pushした後は必ず該当スレッドに戻り、どう直したか、あるいはなぜ直さなかったかを説明します。そして自らスレッドをresolveすることは決してなく、クローズする権限は常に人間側にあります。こうして会話は問題が指摘されたその場所にとどまり続け、実行のたびに「リセット」されることがありません。
コメントは指摘するだけでなく、根拠を示して説明する
各レビューは互いに連動する3つの要素で構成されます。
- Overview: diff全体を俯瞰し、findingを重要度別にグルーピング。特定の行に紐づけられないファイルレベルの問題もここに含まれます
- line comment: 該当する行に直接紐づくfindingで、PRの画面からそのままコミットできるsuggestionブロック付き。書き直す手間がありません
-
reply:
/open-pr:fixでpushした後、該当スレッドに直接返信し、やり取りを締めくくります
AIと人間がお互いを正確に理解できるように、Open-PRはレビュアーとauthorの間の「契約」とも言える、明確な重要度システムを採用しています。
| 記号 | レベル |
/open-pr:fixでの扱い |
|---|---|---|
| 🔴 | MUST FIX | 自動で対応 |
| 🟠 | SHOULD FIX | 自動で対応 |
| 🔵 | SUGGESTION | 必ずコードに触る前に確認を取る |
| 📝 | NOTE | 必ずコードに触る前に確認を取る |
diffに特に指摘すべき点がなければ、LGTM 🌟 の一行だけを投稿し、無駄なノイズを出しません。検討対象となるのは、バグ・ロジック、セキュリティ、パフォーマンス、コード品質、保守性・可読性、そしてフレームワークや言語ごとの固有ルール(Rails、Vue、React、Python、Node.js、Laravel、WordPressなど)の6分野で、衝突した場合は常にチーム固有のルールが優先されます。
PRにコメントする際のデフォルト言語を選べる
Open-PRは、CLI上でエージェントと会話する言語(chat_language)と、PR上に公開でコメントする言語(output_language)を分けて扱います。この設定はユーザー単位ではなく、リポジトリ単位で紐づきます。
あるリポジトリで初めて実行されたとき、Open-PRは短いやり取りでPRへの投稿言語を確認し、以降はそれを記憶します。そのため、チームの誰がレビューコマンドを実行しても、そのリポジトリは常にベトナム語(あるいは英語、日本語、中国語)で一貫してレビューされるようになります。
Claude Codeでのセットアプ
まず、GitHub CLIをインストールし、ログイン済みであることを確認してください。
gh auth login
マーケットプレイスを追加してプラグインをインストールします。
/plugin marketplace add TOMOSIA-VIETNAM/open-pr
/plugin install open-pr@open-pr
その後、対象のPRに対して直接レビューを実行します。
/open-pr:review <PR_URL>
例:
/open-pr:review https://github.com/your-org/your-repo/pull/123
Claude CodeがPRを解析し、マージ前に確認すべきfindingを返してくれます。合意済みの内容をすぐに反映したい場合は、続けて/open-pr:fix <PR_URL>を実行してください。コミットは必ず1つにまとまり、force-pushは行わず、push後は各スレッドに必ず返信します。