AIコードレビューをチームに定着させるOSS、Kodus（Kody）の学習ループ

こんにちは。

もるふぉです。

AIコードレビューをチームで運用しようとして、結局「個人の便利ツール」で止まっていないでしょうか。

GitHub Copilot ReviewもCursor上でのClaudeレビューも、個人の手元では十分に機能します。

ところがチーム全体で同じ基準を効かせる段になると、急にツールが頼りなくなる。

今日はそこに正面から取り組んでいるKodus（Kody）というOSSの話をします。

個人のAIレビューからチーム全体の運用へ

毎PR、自分が同じ指摘を書いていることに気づいたことはないでしょうか。

「N+1クエリになっています」「ここはトランザクションで囲んでください」「nullチェックが抜けています」。

同じ言葉を別のメンバーのPRにもコピペしている。

新しく入った人には1から説明し直している。

レビュー基準は確かに存在するのに、ドキュメント化が追いつかず、チームの誰かの頭の中にだけある——この状態が続いているチームは多いはずです。

個人用のAIレビューを各自にあてがっても問題は解けません。

Aさんの環境では指摘されるルールが、Bさんの環境では指摘されない。

プロンプトの個人差がそのままレビューの揺れになります。

チームでAIコードレビューを機能させるには、「どのルールを誰のPRにも同じ温度で当てるか」を一元化する仕組みが要ります。

Kodusはここを真ん中に据えて設計されたAIコードレビューOSSです。

Git連携した時点でリポジトリ全体を解析し、PR単位で増分レビューを走らせる。

そして決定的に重要なのが、「指摘の積み重ねからルール候補を自動で抜き出して、人間が承認したものだけをチーム共通のルールに育てる」点です。

つまり、「N+1クエリ禁止」を毎PRのコメントに手で書いていた時間が、ルール1個に置き換わっていく。

レビュアーの頭の中にある暗黙知が、誰かが書き下ろさなくてもじわじわと資産化されていく設計です。

このループがどう動くかは、後のセクションで具体的に見ていきます。

Kodus（Kody）とは何か、PR-Agentとの違い

Kodusは三層構成のAIコードレビューOSSです。

リポジトリをAST解析する層（kodus-service-ast）、レビュー本体を担うLLM層（Kody）、.kody/rules/配下のMarkdownでチーム固有の基準を持つルール層——この3層が組み合わさって動きます。

ライセンスはAGPL-3.0、Self-Hosted版は2026-06-10時点で2.1.17。

GitHubに加えてGitLab・Bitbucket・Azure Reposにも対応します。

BYOKは Claude・Gemini・GPT-5系・Llama・GLM・Kimiの主要モデル、OpenRouter経由の任意モデル、さらにOpenAI Compatible API経由でローカルのOllamaやvLLMまで挿せます。

Kodus側がトークン料金にマークアップを乗せない設計なので、コストはモデル提供元に対して透過です。

「SaaSにコードを送りたくない」チームにとって、外部送信ゼロのままチーム統一のAIコードレビューが動かせる構成になっています。

詳しくはBYOKとセルフホストのセクションで扱います。

PR-Agentが「community-maintained legacy」になった経緯

PR-Agent経験者向けに事実関係を整理します。

PR-Agent（codium-ai→qodo-ai系譜、2026年4月にコミュニティへ正式移譲済み）はREADME冒頭で「community-maintained legacy project of Qodo」と自称する段階に入りました。

Qodoの開発主力はSaaS版のQodo Mergeに移っており、auto best practices（レビュー履歴からのルール自動生成）などPR-Agentの目玉だった機能は、OSS版での開発は縮小し、現在はQodo Merge側で進化が続いています。

OSS版PR-Agentが動かなくなったわけではありません。

ただ「PR-AgentのOSSを今から本格採用する」判断は、もはやコミュニティの継続性を前提にできない。

PR-Agentユーザーは、Qodo Mergeに課金して移行するか、別の現役OSSに乗り換えるかの判断を迫られている状況です。

学習ループをOSSで提供する立ち位置

ここが興味深いところです。

「auto best practices」に相当する学習ループ自体をAGPLのOSSとして提供しているOSSは、現時点でKodusくらいしかない。

Qodo Mergeが商用に閉じた領域を、Kodusは別実装でOSS側に持ってきた、という構図です。

スター数は2026-06時点で1.2k、PR-Agentの11.6kと比べれば1/10の規模ですが、機能の方向性そのものが「PR-Agentがlegacyになって失われた席」を取りにいくものになっています。

この学習ループが実際にどう動くのか、次のセクションで見ていきます。

Kodusのルール自動抽出と「抽出→承認→定着」のループ

ここがKodusで一番面白いところです。

Kodyはチームが過去のPRで書いた人間のレビューコメントと、Kody自身が出した指摘の履歴を解析し続けます。

「これは個別の指摘ではなく、このチームの共通基準になり得る」と判断したものをルール候補として抽出する。

抽出されたルール候補は自動では有効になりません。

Kodyが「こういうルール、見つけたんですけど登録しますか？」とチームに問いを投げる形になっていて、人間が中身を読み、編集し、承認したものだけが.kody/rules/にインポートされ、以降のPRで自動適用されます。

同期はPRがクローズされたタイミングで動きます。

これが何を意味するか。

テックリードが頭の中で持っていた「N+1禁止」「nullableは型で表現」「外部API呼び出しはタイムアウト必須」みたいな暗黙知が、誰かが書き下ろさなくてもレビュー履歴から滲み出してくる設計です。

ルールを書く時間が省けるというより、「ルールを書くために棚卸しをする会議」が要らなくなる、と言ったほうが近い。

.kody/rules/ の書き方とgit管理

ルールはMarkdownファイルで、YAMLフロントマターと指示文・良い例・悪い例で構成されます。

最小構成はこんな形です。

---
title: N+1クエリを禁止する
scope: pull-request
path: app/**/*.rb
severity_min: high
languages: [ruby]
buckets: [performance]
enabled: true
---

ActiveRecordのアソシエーション呼び出しがループ内にある場合、
includes / preload / eager_load による事前読み込みを提案してください。

scopeはfileかpull-request、pathはglob、severity_minはlow/medium/high/critical、bucketsでカテゴリ分け、enabledで個別オンオフ。

ルールはグローバル→リポジトリ→ディレクトリの順にカスケードされるので、共通基準をモノレポ全体に効かせつつ、特定パッケージだけ厳しくすることもできます。

Markdownでgit管理できるのが地味に効きます。

ルール変更がPRレビューの対象になり、誰がいつ何を変えたかが履歴に残る。

Slackでの「あれ、今日からこのルール変わりました？」が消え、ルール自体がコードと同じ温度で扱えます。

ルール設計の自由度がここまで効くと、次に気になるのはどのモデルでどこに置くかになります。

KodusのBYOK・セルフホストでAIコードレビューはどう変わるか

「自社コードをクラウドAPIに送れない」というセキュリティポリシーは、AIコードレビュー導入の壁として挙がることが多いです。

いざAIコードレビューを入れようとして、情シスとの会話で止まったチームは少なくないはずです。

BYOKとセルフホストはセットで効きます。

Ollama接続で外部送信ゼロ・APIコスト固定ゼロのレビュー環境が組めます。

つまり、情シス稟議の「外部へのコード送信禁止」という条件をクリアしつつ、チーム全員に同じAIコードレビューを行き渡らせられる。

コード本体は外に出さずにレビュー機能だけ手元に置く——というクローズド構成がそのまま現実解になります。

クラウドAPIを使う場合でも、Kodus側がトークン料金にマークアップを乗せないため、コスト構造はモデル提供元のAPIダッシュボードで完結します。

CodeRabbitのようなSaaS型のサブスク（人数課金＋裏側の推論コスト不透明）と比べると、「月のAIレビュー費用はいくらか」を数字で出しやすくなる。

チーム稟議でコストの根拠を求められたとき、この透明性は効いてきます。

Community版（10ルール上限）で何ができるか

セルフホストのCommunity版にはKody Rulesが10件までという制約があります。

一見シビアに見えますが、運用してみるとこの上限は強制的な優先順位付けの装置として機能します。

「すべてのコーディング規約をルール化する」ではなく、「指摘頻度が高くインパクトの大きい上位10件だけを自動化する」スコープに収まる。

具体的には、N+1・トランザクション境界・nullable・外部呼び出しのタイムアウト・例外握り潰し禁止のような「ヒットしたら確実に止めたい」系を10枠に詰める運用が現実的です。

それ以上のルールが本当に欲しくなったらTeams以上の有料プランで無制限化を検討すればよく、評価フェーズはCommunity版で十分回せます。

ここまで整理できたら、次は実際に導入するかどうかの判断です。

KodusをチームへAIコードレビューとして導入する判断ポイント

導入経路は4つです。

RailwayのQuickstartが一番速く、AWS等の自社IaaSに置きたいならDocker、より統制を効かせたいなら専用VM、開発者個人での検証ならローカルquickstart。

チームの統制要件で素直に選べます。

判断軸として効くのが対応VCSの広さです。

GitHub Copilot ReviewはGitHubのみ。

チームのリポジトリがGitLab・Bitbucket・Azure Reposにある場合、選択肢が一気に絞られます。

Kodusはここに対応しているので、「GitHubじゃないからAIコードレビューを諦めていた」チームが選択肢に入れられる稀なOSSです。

逆に向かないケースもはっきりしています。

GitHub完結・SaaS課金OK・ルール自動学習はQodo Merge課金で十分、という会社にはKodusを自前運用する旨味は薄い。

Kodusが効くのは「セルフホストしたい」「VCSがGitHub以外」「ルール学習ループは欲しいが商用SaaSは選びにくい」のどれかが当てはまるチームです。

AIコードレビューOSSを自前運用する現実

正直なところを書きます。

スター数1.2kは新興規模で、PR-Agentが背負っていたコミュニティ規模にはまだ遠い。

AGPL-3.0なので、社内SaaSとして外部に提供する形態を取るなら派生著作物の扱いに法務確認が要ります。

セルフホストする以上、コンテナ・LLM API鍵・モデルバージョンのメンテナンスは自前で負う。

ここは美化せず書いておきます。

それでも、「チームのレビュー履歴がそのままルール資産になっていく」という体験は他のSaaS型レビューでは得にくいものです。

導入初日からCopilot Reviewほどスムーズではないし、最初の数週間はルールがまだ薄い。

それでも数ヶ月運用していくと、レビューコメントを書いた回数だけ.kody/rules/が育ち、新人の最初のPRから同じ基準で指摘が返るようになる。

この資産化が効くかどうかが、Kodusに賭ける価値があるかの判断軸になります。

まずはRailway Quickstartで小さく立ち上げて、1リポジトリで2〜3週間動かしてみるのが現実的なファーストステップです。

.kody/rules/に最初の3つのルールを置いて、Kodyの抽出提案を待ってみる。

「これは育つ」と感じたら本格導入、感じなければ撤収。

判断材料はその試運転で揃います。