TL;DR
- river-reviewer は「暗黙知を再現可能な Agent Skills に変える」ことを掲げる、Context Engineering ベースの実験的 AI コードレビューフレームワーク（公式 README、確認日: 2026-05-17）。
- 出発点は「プロンプトを磨けば勝てる、をやめた」という思想。壁は プロンプト精度ではなくレビュー指摘の再現性と運用コスト だと公式が明言している。
- 中核は Skill Registry（レビュー知のバージョン管理）/ 自由度の設計（崖・丘・原っぱ）/ HITL ワークフロー の 3 本柱。最新リリースは v0.43.0（公式リリース、確認日: 2026-05-17）。
はじめに
こんにちは、みねです。
AI にコードレビューをやらせると、最初は「それっぽい指摘」が返ってきて感動します。しかし運用に乗せた瞬間、二つの壁にぶつかります——同じ観点が毎回出るとは限らない（再現性）、そして指摘が増えるほど確認コストが膨らむ（運用コスト）。
この記事は river-reviewer を初めて知る人 に向けて、「何のための道具か」「どこから触ればよいか」を、公式リポジトリと公式ドキュメントの一次情報だけを根拠に整理する入門記事です。Skill Registry の作り込みや中級トピックは別記事に譲り、ここでは概念と入口に絞ります。
この記事のゴール:
- river-reviewer が「プロンプト改善ツール」ではなく「レビュー知の資産化フレームワーク」だと説明できるようになる
- 自分のチームが最初にどこから試せばよいか判断できるようになる
river-reviewer とは何か
river-reviewer は、公式 README の言葉を借りれば "Turn Implicit Knowledge into Reproducible Agent Skills"——暗黙知を再現可能な Agent Skills に変える、AI コードレビューの 実験的フレームワーク です（公式 GitHub、確認日: 2026-05-17）。
公式 README は本質を次のように述べています。「River Reviewer は Context Engineering に基づく Skill Registry 中心のコードレビューフレームワーク。チーム固有のレビュー知識を『スキル』として明示化・バージョン管理し、GitHub Actions / CLI / Node API などあらゆる環境で再利用できる。スキルはテスト可能で、継続的に改善できる資産」（公式 README、確認日: 2026-05-17）。
つまり狙いは「AI にコードを読ませる」ことそのものではなく、チームの判断基準と手順を、テスト可能でバージョン管理されたスキルとして組織資産にする ことです。
なぜ作られたか（The Philosophy）
公式 README の Philosophy セクションは強い一文から始まります。「We stopped believing "polish the prompt and you win."（プロンプトを磨けば勝てる、をやめた）」。AI レビュー実用化の最大の壁は プロンプトの精度ではなく、レビュー指摘の再現性と運用コスト だった、と明言されています（公式 README、確認日: 2026-05-17）。
公式が掲げる要点は 3 つです（公式 README）。
- Agent Skills: 暗黙知をレビュー資産として明示化し、継続的に改善できる状態にする。
- 自由度の設計: 「崖・丘・原っぱ」のリスク設計で、AI の裁量と検証コストを制御する。
- HITL ワークフロー: 実行前に計画を人が検証し、レビュー結果は検証可能にする。
Skill Registry の具体的な作り方（versioned Agent Skills の設計・運用）は、姉妹記事「river-reviewer の Skill Registry：レビュー知を versioned skill にする」で扱います。本記事は概念入口に徹し、実装記事と役割を分けています。
アーキテクチャの位置づけ：artifact-driven review agent
river-reviewer は公式 README で artifact-driven review agent と位置づけられています。外部から渡されるアーティファクト（plan / diff / test-cases / junit ほか）を入力に読み取り、findings を含むレビュー結果を出力する設計です（公式 README、確認日: 2026-05-17）。
主な統合例として PlanGate との連携が挙げられており、PlanGate が生成した plan / pbi-input アーティファクトを受け取って設計整合性・実装適合性を専用スキルで検査する、と README に記載されています（公式 README、確認日: 2026-05-17）。AI 開発ワークフロー（PlanGate のようなゲート型）と組み合わせると、計画と実装の整合をレビュー側からも担保できます。
公式が示す 4 つのユースケースは次のとおりです（公式 README）。
- 設計レビュー:
pbi-input/planを入力に計画の整合性・網羅性を上流 skill で検査。 - 実装レビュー:
planとdiffで実装差分が計画と一致しているか検査。 - QA レビュー:
test-cases/junit/coverageでカバレッジや失敗パスの抜けを下流 skill で検出。 - W チェック（二重レビュー）: 既存の AI / 人間レビュー結果を再点検。
なお river review plan / exec / verify の CLI は公式 README 上「Issue #509 で開発中（実装完了までワークフロー内はプレースホルダ動作）」と明記されています。記事ではこれを将来仕様として扱い、確定機能と区別します（捏造回避）。
最初の一歩（GitHub Actions で 5 分）
公式が示す最小構成のクイックスタートは GitHub Actions です（公式 README、確認日: 2026-05-17。タグは記事執筆時点の公式表記）。
name: River Reviewer
on:
pull_request:
branches: [main]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
issues: write
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0 # merge-base を安定取得
- name: Run River Reviewer
uses: s977043/river-reviewer/runners/[email protected]
with:
phase: midstream # upstream|midstream|downstream|all
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
公式は「タグはリリースタグにピン留め」を推奨しています。phase は SDLC のフェーズ（上流/中流/下流）でスキルを振り分ける将来拡張向けの任意入力です。v0.1.x からは Action のパスが runners/github-action に変わっている点も移行注意として README に記載されています（公式 README）。
バージョンについての注意
river-reviewer は更新が速いプロジェクトです。本記事執筆時点（確認日: 2026-05-17）の公式リポジトリ最新リリースは v0.43.0（2026-05-17 公開、公式リリースページ）で、README のクイックスタート例では @v0.42.0 がピン留め例として示されています。本記事の数値・機能は 執筆時点の公式リポジトリ を一次情報として確定しており、導入時は必ず最新リリースを確認してください（実験的フレームワークのため変更が入りやすい）。
まとめ：次のアクション
- river-reviewer は「プロンプト改善」ではなく「レビュー知を versioned Agent Skills として資産化する」フレームワーク（公式 README）。
- 入口は GitHub Actions の最小構成。リリースタグにピン留めして PR で動かす。
- 次に読むなら、Skill Registry の設計・運用を扱う中級記事へ。PlanGate と組み合わせる場合は PlanGate 入門 も参照。
FAQ
Q1. river-reviewer はプロンプトを改善するツールですか？
いいえ。公式 README は「プロンプトを磨けば勝てる、をやめた」と明言しています。狙いはプロンプト精度ではなく、レビュー知を再現可能な Agent Skills として資産化し、再現性と運用コストを制御することです。
Q2. Context Engineering とは何を指しますか？
公式 README では river-reviewer を「Context Engineering に基づく Skill Registry 中心のコードレビューフレームワーク」と定義しています。チーム固有の判断基準・手順をバージョン管理されたスキルとして明示化し、環境を問わず再利用する設計思想です。
Q3. PlanGate と一緒に使えますか？
公式 README は主な統合例として PlanGate との連携を挙げ、PlanGate 生成の plan / pbi-input アーティファクトを受け取り設計整合性・実装適合性を検査すると記載しています。
Q4. CLI（river review plan など）はすぐ使えますか？
公式 README によれば river review plan/exec/verify CLI は Issue #509 で開発中で、実装完了までワークフロー内はプレースホルダ動作です。確定機能ではない点に注意してください。
Q5. 記事の版は最新ですか？
執筆時点（確認日: 2026-05-17）の公式リポジトリ最新リリース v0.43.0 を一次情報としています。実験的フレームワークで更新が速いため、導入時は公式リリースページで最新版を確認してください。
References
- river-reviewer 公式リポジトリ: https://github.com/s977043/river-reviewer （確認日: 2026-05-17）
- river-reviewer 公式ドキュメント: https://river-reviewer.vercel.app/explanation/intro/ （確認日: 2026-05-17）
- river-reviewer ドキュメント（the3396 ミラー）: https://river-reviewer.the3396.com （確認日: 2026-05-17）
- river-reviewer リリース v0.43.0: https://github.com/s977043/river-reviewer/releases/tag/v0.43.0 （確認日: 2026-05-17）
- river-reviewer リリース一覧: https://github.com/s977043/river-reviewer/releases （確認日: 2026-05-17）
- 関連記事（PlanGate 入門）: /notionnext-blog/plangate-intro-gate-driven-dev/
