AIにリントルールを一つだけ直してほしいと頼んだんです。
ところがコードを開いてみたら、頼んでもいない精巧なフィルタリングシステムがまるごと入っていたんです。広い範囲を検知していたものを、AIが勝手に狭めていたんですよね。
テストも通ったし、コードレビューも通りました。でも、これって本当に自分たちが望んでいた製品なんでしょうか。
みんな、バグさえ捕まえれば終わりだと思ってますよね
AIコードレビューツール市場はすでに活況です。CodeRabbit、Greptile、Qodo、Cursor BugBotまで ── みんなやっていることは似ています。PRのdiffをざっと見て、バグ、セキュリティの脆弱性、コードスタイルの問題を見つけ出すことなんです。
実際、これらのツール同士の性能競争も激しいんです。50件のオープンソースPRを対象にしたベンチマークでは、Greptileが実際のバグの82%をキャッチし、CodeRabbitより50%多くバグを見つけました。代わりに誤検知(false positive)も多く(11件 vs 2件)でした。
| ツール | フォーカス | 価格 |
|---|---|---|
| Greptile | コードベース全体のインデックス化、ファイル間バグ | $30/ユーザー/月（50件以降課金） |
| CodeRabbit | diff要約、素早いセットアップ | $24〜48/ユーザー/月 |
| Qodo | Jiraチケットの規定準拠検証 | 無料〜$30/ユーザー/月 |
どれも良いツールです。でも、これらのツールが共通して見ているのは「このコードが技術的に正しいか」なんです。バグがなく、スタイルガイドに従っていて、テストを通過していれば合格ということですね。
でも、バグのないコードのほうが危険なこともあるんです
Prelintを作ったチームの問題意識はここから始まります。Prelint創業のきっかけ自体が、あるコード変更事件だったんです ── AIエージェントがチームのイベント駆動アーキテクチャを完全に無視して、それを迂回して機能を実装してしまったんですよね。コードは動いていました。でも、それはチームが望んでいたやり方ではなかったんです。
この現象をproduct driftと呼びます。技術レビューもCIも通過するのに、トランザクショナルアウトボックスパターンを飛ばしたり、承認されていない依存関係を入れたり、権限ルールを変えたり、存在しないビジネス要件をでっち上げたりするようなことです。
Stack Overflowのブログはこれを「ブラックボックスAIドリフト」と表現しています。「プロンプトが入って結果物が出てくるけれど、その間に下された決定は見えない」ということですね。上で触れたリントルールの事例も、まさにこのブログから出てきたものです。
数字でも確認できます。GitClearが2023〜2026年のコードベースを分析したところ、ブロックの重複が81%増加(40.3 → 73.0)し、コピー&ペーストコードの割合が9.4%から15.7%に増えました。一方で、コードを移動させながら整理するリファクタリングの割合は21%から3.8%へと急落したんです。AIがコードを速く書く代わりに、その分整理は追いついていないということです。
注意
AIエージェントは午後だけで50個のファイルを作り出すことができます。個々のファイルはどれも正しく見えるのに、まとめてみるとアーキテクチャ決定の半分に違反しているケースがあるんです。ファイル単位のレビューでは、これを見つけられません。
そこで出てきたのが「decision ledger（決定台帳）」なんです
Prelintのポジショニングは明確です。「コードレビュアーではなく decision ledger」。リポジトリにあるADR(アーキテクチャ決定記録)、ドキュメント、過去の決定を集めて一つの「決定台帳」を構成し、すべてのPRをこれと照合するんです。
仕組みは3段階です。(1)リポジトリにMarkdown/YAMLで製品仕様を保存 (2)AIエージェントがいつも通りPRを生成 (3)Prelintが数秒以内に仕様違反をフラグし、修正案を提案します。
実際、331のオープンソースリポジトリのPR56,706件を分析した自社リサーチで興味深い結果が出ました。同じPRをドキュメントあり/なしで2回ずつレビューしたところ、ドキュメントがある場合のフラグ率は36.6%、ない場合は13.3%でした。Prelintチームの言葉を借りれば、「ドキュメントがバグをより多く見つけてくれるのではなく、違うバグを見つけてくれる」ということでした。
| 従来のAIコードレビュー | decision ledger方式 | |
|---|---|---|
| 基準 | バグ・スタイル・セキュリティ | ADR・製品仕様・過去の決定 |
| 合格条件 | 技術的に正しければOK | 製品の意図と一致してこそOK |
| レビュー単位 | diff一つずつ | リポジトリ全体の決定履歴と照合 |
| 併用効果 | - | 他のレビュアーが見逃したイシューの約40%を追加でキャッチ |
これは他のツールを置き換えるものではなく、レイヤーを一つ追加するものに近いです。GreptileやCodeRabbitが「このコードは安全か」を見るとすれば、Prelintは「このコードは自分たちが決めた製品と一致しているか」を見るわけですね。
すぐに実践する方法
- まずは核心的な決定から文書化する
すべてをADRとして書く必要はありません。直近3ヶ月で議論になったアーキテクチャ・権限・データフローの決定を5〜10個だけMarkdownにまとめましょう。 - リポジトリに接続する
GitHub/GitLabアプリで連携すれば、既存のPRワークフローに自動的に組み込まれます。 - 既存のレビュアーと併用する
CodeRabbit・Greptileはそのままにして、Prelintを追加しましょう。それぞれ見ているものが違うので重複しません。 - 最初の違反ケースを確認する
Prelintが最初にフラグしたPRを見ながら、チームの決定台帳が実際どれくらい正確なのか感触をつかみましょう。 - 決定台帳を「生きたドキュメント」として管理する
四半期ごとに古い決定を見直し、もう有効でないルールは取り除きましょう。台帳が古くなると誤検知が増えるだけです。
「コードレビュー」から「意図レビュー」へ
韓国の開発ブログFlowkaterは、AI時代のコードレビューの方向性をこうまとめています。「diffではなく仕様をレビューし、受け入れ基準をあらかじめ定義すべきだ」ということです。Prelintのdecision ledgerは、このアイデアを製品として実装した事例に近いと言えます。
もっと深掘りしたいなら
Prelint公式サイト 仕組み、価格、実際のPRレビューのデモを確認できます。 prelint.com
Prelint AI Code Pulseリサーチ 331のリポジトリ・56,706件のPRを分析した元データと方法論です。 prelint.com
Black box AI drift (Stack Overflow Blog) AIが頼まれてもいない設計決定をこっそり下してしまう問題を扱った原文です。 stackoverflow.blog
Best AI Code Review Tools 2026 (Greptile) CodeRabbit・Greptile・Qodoなど8つのツールをベンチマークで比較した記事です。 greptile.com
AI Architecture Drift (TechDebt Guru) AIエージェントがアーキテクチャを蝕む5つのパターンとGitClearの統計をまとめています。 techdebt.guru
ADR 2.0 ── 人間とエージェントのための共通契約書 ADRがエージェント時代にどう進化していくかを扱った韓国の開発ブログ記事です。 juhyungson.com
