AIコーディングの無限レビュワー地獄から解放するツール、sqlew

AIコーディングツールを導入してから、チームの開発速度は確かに上がったと思います。でも、その裏でレビュワーの負荷が静かに膨らんでいることに気づいていますか。

AIが書いたプルリク、意味がわからない問題

Latent.Spaceで2026年3月に公開された記事「How to Kill the Code Review」は、AI時代のコードレビューが直面する構造的な課題を正面から論じています。

How to Kill the Code Review

Human-written code died in 2025. Code reviews will die in 2026.

www.latent.space

同記事が引用するFaros.aiの調査データによれば、AI導入チームではタスク完了数が21%増加し、マージされるPR数は98%増加する一方で、PRレビュー時間は91%も増加しています。

つまり、AIがコードを大量に生成するようになった結果、レビュワーはかつてないペースでdiffを読み続けなければならなくなっています。

しかし本当の問題は量だけではありません。AIが生成したPRには、しばしば変更の意図が記載されていないのです。

実際のPRで比較する

ここで、実際のPRを見比べてみましょう。

Skill無しのPR（Claude Codeポン出し）

Summary
- Extend validatePriority() to accept string | number,
  auto-converting numeric 1-4 to string equivalents
- Fix TOML help document: change priority from
  type = "number" to type = "string"
- Fix false positive in filter-test-output.js
  when test names contain "Error"

一見、整理されているように見えます。でも「なぜstring | numberにする必要があったのか」が一切わかりません。外部APIとの互換性のためなのか、ユーザーからの不具合報告への対応なのか、将来の拡張を見据えた設計変更なのか。レビュワーはコードのdiffだけを手がかりに、推測するしかありません。

sqlew Skill適用後のPR

Decision: PR ADR enforcement via PreToolUse Hook
  (SKILL.md auto-discovery lacks enforcement power)

- src/cli/hooks/pr-adr.ts: New hook — reads stdin JSON,
  checks for gh pr create, validates ADR markers
  (## Decision: / ## Constraint: / ## Other Changes),
  blocks with template if missing
- src/cli.ts: Add pr-adr command dispatch and help entry

Other Changes
- No files in this PR unrelated to the decision above

違いは明確です。「なぜこの変更をしたのか」という方針（Decision）がPRの冒頭に構造化されています。さらに、各ファイルの変更がその方針にどう紐づくのかが明記されており、方針と無関係な変更がないことも「Other Changes」セクションで明示されています。

レビュワーが読むべきは「コード」ではなく「意図」

先述のLatent.Spaceの記事でも、コードレビューの重心を「コードの行を読むこと」から「意図を検証すること」へ移すべきだと論じられています。人間が判断すべきは「正しい問題を、正しい制約のもとで解いているか」であり、500行のdiffを1行ずつ追うことではないと主張しています。

sqlewの新しいSkill「sqlew-pr-adr」は、まさにこの考え方をツールとして実装したものです。Claude CodeのPreToolUse Hookとして動作し、gh pr createの実行時にPR本文にDecision（方針）セクションが含まれているかを自動で検証します。含まれていなければ、構造化されたテンプレートを提示してPRの作成をブロックします。

なお、OpenAI Codexでも同じsqlew-pr-adr Skillを利用できます。Codex環境にはHooks機構がないため、PRを作成する際にAIがSkillの手順に従って自動的に方針を記述する仕組みです。

仕組み

この機能の中核はsqlewのSkill「sqlew-pr-adr」です。diffの内容からキーワードを抽出し、sqlewに蓄積された方針（Decision）を逆引き検索して、PRの説明文を方針ごとにグルーピングします。

• 差分解析: git diffから変更ファイル・関数名・モジュール名を抽出
• 方針の逆引き: 抽出したキーワードでsqlewのsuggestを呼び出し、関連する方針を取得
• 構造化テンプレート: 方針ごとにファイル変更をグルーピングしたPR説明文を生成
• ステートレス設計: 状態管理は不要。PR本文のみを検証するシンプルな設計

導入方法

Claude Codeの場合: sqlew本体がインストール済みなら、sqlewプラグインをインストールするだけで完了します。PreToolUse Hookが自動で設定され、gh pr create時に方針の記載を強制します。

claude plugin marketplace add sqlew-io/sqlew-plugin
claude plugin install sqlew

OpenAI Codexの場合: GitHubからsqlew-codex-skillsリポジトリをクローンし、Codexのディレクトリに上書き保存します。

git clone https://github.com/sqlew-io/sqlew-codex-skills
cp sqlew-codex-skills/copy_to_codex_dir/* ~/.codex

Skillだけでは足りない：ナレッジベースが本質

sqlew-pr-adr Skillを導入するだけでは、この効果は十分に発揮されません。

Skillが行うのは「sqlewに蓄積された方針を逆引きして、PRの説明文に構造化する」ことです。つまり、逆引きの元になる方針と誓約のナレッジベースが育っていなければ、Skillが参照できる情報がなく、結果として「Other Changes」だけのPRになってしまいます。

sqlewを日常の開発フローに組み込み、Plan Modeでの設計議論を方針として記録し、コーディング規約を誓約として蓄積していく。このナレッジベースの積み重ねがあってこそ、PRの説明文に「なぜこの変更をしたのか」が自然に現れるようになります。

PRに変更意図が構造化されていれば、レビュワーは「この方針は妥当か」「変更範囲は方針と一致しているか」という本質的な判断に集中できます。AIが量産するdiffを1行ずつ読むのではなく、意図と実装の整合性を確認するレビューへと転換できるのです。

sqlew-pr-adr Skillは、AIコーディング時代のレビュー体験を「苦行」から「判断」に変えるための第一歩です。

参考文献

• Jain, A. (2026). "How to Kill the Code Review" — Latent.Space — https://www.latent.space/p/reviews-dead

sqlewのインストール方法

AIコーディングアシスタント向けMCPサーバー「sqlew」のOSS版インストール手順を解説。npm一発で導入でき、外部への情報送信は一切なし。MySQL・PostgreSQLにも対応し、チーム開発やgit worktreeでの並行開発もカ...

blog.sqlew.io