Kodus（Kody）入門｜AIコードレビューのチーム標準を.kody/rules/でgit管理するOSS

AIがコードを書く速度が上がった2026年、ボトルネックはレビューに移った。Pull Requestを開いた瞬間にAIが差分を読み、バグ候補や規約違反を指摘する——その体験はもう珍しくない。

だが本当に効くのは、単発の指摘ではない。「このチームではこう書く」という暗黙知を、レビューのたびに蓄積し、次のPRで自動的に効かせる仕組みだ。Zennやはてなで何度もバズった「AIにレビュー指摘を抽出させ、人間が承認し、チーム標準として定着させる」というアイデアが、まさにそれにあたる。

本記事で扱う Kodus（レビューAIの愛称が Kody） は、そのアイデアをAGPLのOSSとして製品化している。.kody/rules/ のmarkdownでチーム標準をgit管理し、レビュー履歴から自動でルール候補を生成し、人間が承認したものだけを定着させる。一次情報（公式リポジトリとドキュメント）をもとに、構造・書き方・モデル選択・セルフホスト、そしてLEGACY化したPR-Agentとの違いまで整理する。

30秒で理解する Kodus（Kody）

まず結論から。Kodusは「AIにPRをレビューさせる」だけのツールではなく、チームのコーディング標準を時間とともに育てる基盤だ。中身は次の3層で理解するとよい。

・AST層：@kodus/kodus-graph がリポジトリを構文解析し、関数・クラス・ファイル・import・呼び出し関係をJSONグラフ化する。差分の外にある依存まで踏まえる
・LLM層（Kody）：そのグラフを文脈にして、BYOKで選んだモデル（Claude・Gemini・GPT-5系・ローカルOllama等）がPRにコメントする
・ルール層：.kody/rules/ のmarkdownがチーム標準を定義し、git管理される。レビュー履歴からの自動ルール生成で、この層が時間とともに厚くなる

ライセンスはAGPL-3.0、主要言語はTypeScript、★は1.2k（2026年6月時点の公式リポジトリ実測）。GitHub・GitLab・Bitbucket・Azure Reposに対応し、PRネイティブに加えCLI/CI-CDでも動く。

これがなぜ刺さるのか。「レビュー指摘をAIで抽出し、人間が承認し、チーム標準に定着させる」という運用アイデアは、Zennや技術ブログで何度も話題になった。Kodusはそれを自前で組まなくても、OSSとしてそのまま動かせる。サイトのニッチど真ん中——「バズったあのアイデア、実はOSSで動く」を地で行く題材だ。

AIコードレビューの全体地図（商用含む7ツールの比較）は、ピラー記事のAIコードレビューツール比較2026｜CodeRabbit・Greptile・Qodo・Bito・Sourcery・Codacyを使い分け解説にまとめてある。本記事はそのなかで「OSS・セルフホスト・学習ループ」に振り切った1本を深掘りする位置づけだ。

Kodus（Kody）とは — OSSのAIコードレビュー基盤

Kodusの公式タグラインは「AI Code Review with Full Control Over Model Choice and Costs」だ。鍵は Full Control——モデル選択とコストを自分の手に残す、という設計思想にある。

多くの商用AIレビューはベンダーのクラウドにコードを送り、モデルもベンダー指定、料金はシート単価＋従量クレジットで膨らむ。Kodusは逆を行く。モデルは自分のAPIキー（BYOK）で選び、Kodus側のマークアップはゼロ。インフラもセルフホストできるため、機密コードを外に出さない構成が取れる。

・リポジトリ：kodustech/kodus-ai（GitHub）
・ライセンス：AGPL-3.0
・主要言語：TypeScript（94.1%）
・★数：1.2k（公式リポジトリ実測）
・最新リリース：Self-Hosted 2.1.17（2026年6月10日）
・連携先：GitHub / GitLab / Bitbucket / Azure Repos、PRネイティブ＋CLI/CI-CD

そして名前の使い分けに注意したい。KodusはプロダクトとOSSプロジェクトの名前、Kodyはレビューを実行するAIエージェントの愛称だ。チーム標準を記述するルールも「Kody Rules」と呼ばれ、.kody/ ディレクトリに格納される。本記事でも、システム全体を指すときはKodus、レビュー主体を指すときはKodyと書き分ける。

なぜ今このOSSか — 「抽出→承認→定着」がほぼ製品化されている

ここが本記事のいちばん伝えたい点だ。

技術ブログで繰り返しバズってきた運用パターンがある。「Claude（やGPT）にレビューコメントを読ませて、チームの暗黙ルールを抽出させる。人間がそれを承認し、CONVENTIONS.md のような形でリポジトリに定着させ、次のレビューで参照させる」というものだ。手作業のスクリプトとプロンプトで組んだ人も多いだろう。

Kodusは、この抽出→人間承認→定着のループそのものを製品仕様として実装している。

・抽出：Kodyがチームの過去のレビュー履歴を分析し、繰り返し指摘されるパターンからルール候補を生成する
・承認：候補は「提案」状態にとどまる。公式ドキュメントは「生成されたルールは手動でインポートするまで有効にならない」と明記する
・定着：人間が選んでインポートしたルールだけが .kody/rules/ のmarkdownになり、git管理され、以降のレビューで強制される

自前で組んだ場合に苦労する「承認ゲートをどこに置くか」「定着先をどう永続化・バージョン管理するか」が、最初から設計に織り込まれている。プロンプトの継ぎはぎではなく、AST解析・ルールスキーマ・同期パイプラインまで含めて動く。だからこそ「バズったあのアイデア、実はOSSで完成品が動いている」と言える。

エージェント設計の観点では、これは「人間をループに残したまま自律性を上げる」典型例だ。AIエージェントの型を体系的に押さえたい人はAIエージェント設計パターンを横断比較した記事も併読すると、Kodyの位置づけが立体的に見える。

アーキテクチャ：AST + LLM推論のハイブリッド

Kodusの強みは、LLMに差分テキストを丸投げしない点にある。構文解析（AST）でコードの構造をグラフ化し、それを文脈としてLLMに渡すハイブリッド構成だ。

中核は @kodus/kodus-graph というCLIツールである。リポジトリをツリーウォークし、関数・クラス・ファイル・import・呼び出し関係を含むJSONグラフを生成する。このグラフのライフサイクルは3段階だ。

・初回インデックス：リポジトリ登録時に AstGraphBuild ジョブが走り、デフォルトブランチを解析してPostgresに永続化する
・増分更新：PRがデフォルトブランチにマージされると、Webhookが変更ファイルだけ再解析し、差分をキャッシュ済みグラフにマージする
・レビュー時：各レビューでキャッシュ済みグラフを読み込み、変更ファイルのみ解析して、エージェントにフォーカスしたサブグラフを渡す

解析は SANDBOX_PROVIDER 設定で隔離実行される。デフォルトの local はworkerコンテナ内でBun＋CLIを動かし、強い隔離が必要なら e2b でリモートサンドボックスを立てる。auto は構成に応じてフォールバック、none でグラフ生成自体を止められる。

差分だけを見るレビューは、無関係な箇所への誤検知やコンテキスト不足の指摘を生みやすい。Kodusはグラフ由来の構造情報を渡すことで、「この関数はどこから呼ばれているか」「この変更は他のどのファイルに波及するか」を踏まえた指摘を狙う。AST層が事実を、LLM層が判断を担う役割分担だ。

.kody/rules/ の書き方 — markdownでチーム標準をgit管理

Kody Rulesの実体は、リポジトリに置くただのmarkdownファイルだ。場所は .kody/rules/**/*.md（または rules/**/*.md）。コードと同じリポジトリに同居するので、レビュー基準そのものがPullRequestのレビュー対象になり、変更履歴がgitに残る。これが監査証跡として効く。

ファイルはYAMLフロントマター＋本文の構成だ。公式ドキュメントの実例に沿うと、こう書ける。

---
title: "Avoid console.log in production code"
scope: "file"
path: ["src/**/*.ts", "src/**/*.tsx"]
severity_min: "medium"
languages: ["jsts"]
buckets: ["style-conventions"]
enabled: true
---

## Instructions
Check for console.log statements in production TypeScript files.
- Console logs should not appear in production code
- Use proper logging libraries instead
- Allow console.log only in development utilities

## Examples

### Bad example
\`\`\`typescript
function processUser(user: User) {
  console.log('Processing user:', user.id);
  return user.process();
}
\`\`\`

### Good example
\`\`\`typescript
import { logger } from './logger';

function processUser(user: User) {
  logger.info('Processing user:', user.id);
  return user.process();
}
\`\`\`

フロントマターの主なフィールドは次のとおり。

・title：ルール名（必須）
・scope：file（ファイル単位）か pull-request（PR全体）
・path：適用対象のglobパターン配列
・severity_min：low / medium / high / critical の最小重大度
・languages・buckets・uuid・enabled：対象言語・分類・識別子・有効フラグ（任意）

本文の ## Instructions に何をチェックするかを自然言語で書き、## Examples に良い例／悪い例を添える。LLMはこの良し悪しの対比を強く参照するため、悪い例と良い例をペアで書くほど精度が上がる。

ルールはグローバル→リポジトリ→ディレクトリの順でカスケード（継承）する。共通の全社ルールを上位に、特定リポジトリやサブディレクトリ固有のルールを下位に置ける。同期はPullRequestがクローズされたタイミングで自動的に走り、@kody-sync マーカーで特定ファイルだけ手動同期することもできる。

学習ループ — レビュー履歴から自動生成→人間承認→定着

Kody Rulesは手で書くだけのものではない。Kodyは過去のレビュー履歴を分析して、ルール候補を自動生成する。公式ドキュメントが示すフローはこうだ。

・Step 1 分析：レビュー履歴をスキャンし、繰り返されるパターンを特定し、標準を抽出し、提案を生成する
・Step 2 確認：「Check Out New Rules」ボタンから提案ルールと説明を閲覧できる。ただし「この時点でルールはまだ有効ではなく、あくまで提案」
・Step 3 手動インポート：チームが必要なルールを選び、必要なら編集して適用する。「生成されたルールは手動でインポートするまで有効にならない」
・Step 4 強制：インポートされたルールだけがレビューで強制される

ここに「draft（下書き）」「pending（承認待ち）」という明示的なステータス名は使われない。だが実態は ドラフト提示→人間レビュー→定着 そのものだ。AIが勝手にチーム標準を書き換えることはなく、必ず人間の手動インポートというゲートを通る。

さらにKodusには「Kody Learnings / Memory」や、CLIの「Decision Memory（AIエージェントの判断を構造化ファイルとして永続化）」もある。ルール（明示的な強制基準）とメモリ（学習した好み）を使い分け、チームの作法を多面的に蓄積していく設計だ。ループが一周するたびに .kody/rules/ が厚くなり、レビュー品質が底上げされていく。

セルフホストとモデル選択（OpenAI / Anthropic / Gemini / Ollama）

Kodusはセルフホストを前提に設計されている。導入経路は複数用意されており、規模と運用方針で選べる。

・Railwayテンプレート：最短でクラウドに立てる
・Docker：自前インフラにコンテナで展開
・汎用VM：任意のLinux VMにインストール
・ローカルquickstart：手元のマシンで動作確認

モデル選択はBYOK（Bring Your Own Key）方式だ。Kodus側はモデル費用にマークアップを乗せず、自分のAPIキーに対する実費だけで済む。プリセットされた主要プロバイダに加え、手動設定でほぼ何でも繋がる。

・プリセット：Anthropic（Claude）・Google（Gemini）・OpenAI（GPT-5系）・Moonshot（Kimi）・Z.ai（GLM）
・手動設定：OpenAI・Anthropic・Google・OpenRouter・Novita、その他の任意のOpenAI互換エンドポイント
・ローカル/自前：自前のOllama・vLLM・TGIインスタンスを「OpenAI Compatible」プロバイダ経由で利用可能

この「Ollama・vLLM・TGIまで繋がる」点が、機密コードを扱うチームには大きい。レビュー対象のコードを外部APIに一切送らず、社内GPUのローカルモデルで完結できる。クラウド送信が許されない環境でAIレビューを導入したい、というニーズに正面から応える構成だ。ローカルLLM環境の選択肢はLM Studio入門の記事でGUI/CLI両面から整理しているので、推論基盤側の判断はそちらが参考になる。

PR-Agent（qodo-ai）との比較 — OSS版はLEGACY、auto best practicesは商用側

AIコードレビューのOSSというと、まず名前が挙がるのが PR-Agent（qodo-ai/pr-agent） だ。Apache-2.0、11.6k★という草分けで、Kodusより知名度も★も上だ。ではなぜ「今から選ぶならKodus」と言えるのか。一次情報で確認すると、PR-Agentの立ち位置が変わっている。

PR-Agentの公式READMEは、自らを「The Original Open-Source PR Reviewer」と名乗りつつ、「a community-maintained legacy project of Qodo（Qodoのコミュニティ維持のレガシープロジェクト）」 と明記している。長年の開発の末にOSSコミュニティへ寄贈され、後継は商用のQodo（旧Qodo Merge、Qodo 2.0）へと進化した、という構図だ。つまりOSS版はメンテナンスモードに入っている。

決定的なのが「best practices」周りの機能差だ。

・OSS版：リポジトリ直下に手書きの best_practices.md を置ける。AIがそれを参照し、違反に「Organization best practice」ラベル付きの指摘を出す。あくまで静的・手書き
・商用Qodo Merge（💎）：採用された提案を自動追跡し、.pr_agent_accepted_suggestions に集約、そこから .pr_agent_auto_best_practices を自動生成する「auto best practices」。これは💎マーク付きの商用限定機能

Qodoのドキュメントでは 💎が「Qodo Merge限定・OSS版にない機能」 を示す。つまり「レビューの蓄積からチーム標準を自動で育てる」という、いちばんおいしい学習ループは、PR-Agentでは商用側にしかない。一方Kodusは、まさにその学習ループ（自動ルール生成）をAGPLのOSSとして提供している。ここが「今から選ぶならKodus」の核心だ。

ポジショニングを図にするとこうなる。横軸を「OSS↔商用」、縦軸を「単発レビュー↔学習ループ」で取ると、Kodusだけが「OSS×学習ループ」の象限に入る。

念のため補足すると、★数だけ見ればPR-Agentが圧倒的に多い。これは草分けとして積み上げた歴史の差であり、現在の活発さや学習ループの有無とは別の指標だ。「LEGACY表記」「auto best practicesは💎商用限定」は、いずれも筆者の推測ではなく公式の記述で確認した事実である。

「複数リポジトリ横断の中央ナレッジベース」の不足を埋める

Kodusにも弱点はある。ルールはあくまでリポジトリ単位（.kody/rules/）で管理される。10も20もリポジトリを持つ組織で、「全社共通のコーディング標準を1か所で管理し、全リポジトリに効かせる」中央ナレッジベースを、Kodus単体では完結できない。

ここは自作レイヤーで埋めるのが現実的だ。発想はシンプルで、共通ルールを1つの中央リポジトリに集約し、各リポジトリへ配布する。配布手段は主に2つある。

・git submodule方式：中央リポ（例 org/kody-rules）を各リポジトリの .kody/rules/shared にsubmoduleとして取り込む。git submodule update --remote で最新を引く
・同期Action方式：GitHub Actionsで定期的（または中央リポへのpush時）に共通ルールを各リポへコピーしPRを作る。レビューを挟めるぶん、こちらのほうが統制が効く

ポイントは、中央リポを単一の真実の源（single source of truth）にし、配布だけを自動化することだ。各リポジトリは「共通ルール（submodule/同期）＋そのリポ固有ルール」の2層を持つ。Kodyのルール継承（グローバル→リポジトリ→ディレクトリ）と組み合わせれば、全社標準とチーム裁量を両立できる。商用ツールの「組織レベルのナレッジベース」に相当する層を、git運用で自前構築する形だ。

導入してみる：最小構成の手順

最小構成での立ち上げイメージを示す。詳細は必ず公式の how_to_deploy を参照してほしいが、流れはこうだ。

まずローカルで動かす場合、Dockerでオーケストレータを起動し、Git連携とモデルキーを設定する。

# 1. リポジトリを取得
git clone https://github.com/kodustech/kodus-ai.git
cd kodus-ai

# 2. 環境変数を用意（モデルキー・DB・Git連携）
cp .env.example .env
#   .env で BYOK のキーを設定（例）
#   ANTHROPIC_API_KEY=sk-ant-...
#   または OpenAI互換（自前Ollama）
#   OPENAI_COMPATIBLE_BASE_URL=http://localhost:11434/v1

# 3. Docker で起動（Web App / API / Worker / Webhooks）
docker compose up -d

起動後、WebアプリからGitプロバイダ（GitHub等）を接続し、対象リポジトリを選ぶと AstGraphBuild が走ってグラフが構築される。あとは対象リポジトリに最初のルールを置く。

# 4. 最初の Kody Rule を作る
mkdir -p .kody/rules
cat > .kody/rules/no-any.md <<'EOF'
---
title: "Avoid the any type"
scope: "file"
path: ["src/**/*.ts"]
severity_min: "high"
languages: ["jsts"]
enabled: true
---

## Instructions
Flag uses of the `any` type in TypeScript source.
- Prefer explicit types or `unknown` with narrowing.

## Examples

### Bad example
\`\`\`typescript
function parse(input: any) { return input.value; }
\`\`\`

### Good example
\`\`\`typescript
function parse(input: unknown) {
  if (typeof input === "object" && input) return (input as { value: string }).value;
}
\`\`\`
EOF

git add .kody/rules/no-any.md
git commit -m "chore: add first Kody rule"

このルールをpushしてPRを開けば、KodyがASTグラフと .kody/rules/ を文脈にレビューを返す。慣れてきたら自動ルール生成で履歴からの候補を眺め、良いものだけインポートしていけばよい。CI/CDに組み込むなら、PRイベントをWebhookで受ける構成に切り替える。

サンドボックスは既定の local（worker内でBun＋CLI）で十分動く。隔離を強めたいときだけ SANDBOX_PROVIDER=e2b に変える、という運用順序がトラブルが少ない。

想定ユースケース（個人〜中規模開発チーム）

Kodusが効く場面を整理する。

・機密コードでAIレビューを使いたいチーム：自前Ollama/vLLMでローカル完結。コードを外部APIに送らずにAIレビューを導入できる
・規約が暗黙知化しているチーム：レビューでの口頭指摘を自動ルール化し、.kody/rules/ に形式知として定着。新メンバーのオンボーディングが速くなる
・モデルコストを自分で握りたいチーム：BYOKでマークアップゼロ。安いモデルで広く回し、重要PRだけ高性能モデルに切り替える運用が自由にできる
・個人開発〜OSSメンテナ：Community版（ルール最大10件）で小さく始め、規約をgit管理しながら一貫性を保つ
・「バズったアイデアを自前で実装しかけた」人：抽出→承認→定着のスクリプトを自作する前に、完成品としてのKodusを試す価値がある

逆に向かないのは、「とにかく手間なくマネージドで使いたい」ケースだ。セルフホストの運用（Docker/VM、DB、Webhook）を背負いたくないなら、商用のマネージドサービスのほうが合う。Kodusの価値はFull Control——制御を手元に残すことと表裏一体で、運用コストを引き受ける覚悟が前提になる。

まとめ

Kodus（Kody）は、「AIにPRをレビューさせる」段階を一つ越えて、チームのコーディング標準をAST＋LLMで育て続ける学習基盤だ。要点を振り返る。

・正体：kodustech/kodus-ai、AGPL-3.0、TypeScript、1.2k★、Self-Hosted 2.1.17（2026-06-10）
・中身：AST解析（@kodus/kodus-graph）でグラフ化し、BYOKのLLM（Claude/Gemini/GPT/Ollama等）が文脈レビュー
・チーム標準：.kody/rules/ のmarkdownでgit管理。レビュー履歴から自動生成→手動承認→定着の学習ループが製品仕様
・PR-Agent比較：PR-Agentは公式が「legacy project of Qodo」と自称、auto best practicesは💎商用限定。学習ループをOSSで回せるのはKodus
・弱点：中央ナレッジベースはリポジトリ単位ゆえ、submodule/同期Actionの自作レイヤーで補う

「レビュー指摘をAIで抽出し、人間が承認し、チーム標準に定着させる」——技術ブログでバズり続けたこの運用アイデアは、もう自前で組まなくていい。AGPLのOSSとして、AST解析からルールスキーマ、承認ゲートまで含めて動く完成品がある。まずはローカルquickstartで立ち上げ、最初の .kody/rules/ を1つ書いてみるところから始めるのがいい。AIコードレビュー全体の選定軸は比較ピラー記事を、AIが書いたコードをレビューする前段の動的ワークフロー設計はClaude Codeの動的ワークフロー解説を併読してほしい。

2026-10-11 に実測で確かめ直した

本記事の対象リポジトリを 2026-10-11 に clone して、ライセンスの実体・更新状況・規模を測り直した。 紹介文やバッジではなく、リポジトリの中身を直接読んだ値だ。

# ① 浅く clone する
git clone --depth 1 https://github.com/kodustech/kodus-ai /tmp/kodus-ai

# ② 直近のコミット日を見る → 2026-10-07
git -C /tmp/kodus-ai log -1 --format=%ad --date=short

# ③ ライセンスの実体と規模を見る → LICENSE ファイルなし / 6,125 ファイル
head -3 /tmp/kodus-ai/LICENSE* 2>/dev/null; git -C /tmp/kodus-ai ls-files | wc -l

③が肝心で、OSI 準拠のオープンソースではない（LICENSE ファイルが存在しない）だった。バッジや README の記述ではなく LICENSE ファイルの中身を読んでいる。

参照ソース

・kodustech/kodus-ai（GitHub） — 本記事が 2026-10-11 に測り直した対象
・LICENSE — ライセンスの実体（手順③で読んだファイル）
・docs.kodus.io — repository_rules
・docs.kodus.io — kody_rules_generation
・docs.kodus.io — can I use my own LLM provider
・docs.kodus.io — sandbox
・github.com/qodo-ai/pr-agent
・qodo-merge-docs.qodo.ai — auto_best_practices