コーディングエージェントを導入すれば、開発は速くなる。それ自体は間違いではありません。実装速度だけを見れば、手書きの10倍以上というケースも珍しくないでしょう。
しかし現場では、奇妙な現象が報告されるようになっています。AIを導入したのに、エンジニアの労働時間が減るどころか増えている、というのです。
実装は速くなった、けれど
METR（Model Evaluation & Threat Research）が2025年に公表した調査では、経験豊富なオープンソース開発者がAIコーディングツールを使用した場合、タスク完了時間がむしろ19%増加したという結果が報告されています。開発者自身は「速くなった」と感じていたにもかかわらず、です。
この直感と実測のギャップには、いくつかの要因が絡んでいます。しかし最も大きな要因のひとつが、レビューコストの増大です。
AIが生成するコードの量は圧倒的です。人間が1時間かけて書くコードを、エージェントは数分で出力します。しかし、そのコードが正しいかどうかを確認するのは人間の仕事です。実装速度が10倍になっても、レビュー速度は10倍にはなりません。結果として、開発プロセス全体のボトルネックが「書く」から「読む」に移動しただけ、という状況が生まれています。
AI生成コードのレビューが大変な理由
手書きコードのレビューとAI生成コードのレビューは、質的に異なる作業です。同僚のコードをレビューするとき、書いた人の意図や設計思想がある程度推測できます。しかしAI生成コードにはその前提がありません。
依頼どおりに作られているか怪しい。 AIは指示を「解釈」して実装します。その解釈が依頼者の意図と一致している保証はありません。API設計を頼んだらUIコンポーネントまで作っていた、というケースは日常茶飯事です。要件を満たしているように見えても、微妙にスコープが異なっていることがあり、レビュアーは「何が依頼で、何がAIの独自判断か」を切り分ける作業を強いられます。
関係ないコードを編集している。 エージェント型のAIは、タスクを完遂するために必要だと判断すれば、指示されていないファイルも変更します。依頼した機能の実装差分を確認しているつもりが、関連する設定ファイルやテストコード、ときにはまったく無関係なモジュールまで変更されていることがあります。差分の量が膨らむほど、「どこを重点的に見ればいいのか」の判断コストが上がります。
そもそもルールを無視することがしばしばある。 プロジェクトのコーディング規約、命名規則、アーキテクチャの方針。これらをAIに伝えているはずなのに、守られていないことが少なくありません。LLMのInstruction Following（指示遵守）には構造的な限界があり、指示の数が増えるほど、また指示がコンテキストの深い位置にあるほど、無視される確率が高くなります。結果として、レビュアーは「ルール違反がないか」を毎回一から確認する必要があります。
レビューしやすいコードを書かせるための手法
こうした問題に対処するため、AI生成コードの品質を制御するさまざまな手法が生まれてきました。それぞれにメリットがありますが、同時に構造的な限界も抱えています。
CLAUDE.md・AGENTS.mdにルールを書く
最もシンプルなアプローチは、プロジェクトルートに置くコンテキストファイルにルールを集約する方法です。CLAUDE.mdやAGENTS.mdにコーディング規約、アーキテクチャ方針、禁止事項をまとめて記述します。
手軽に始められる一方で、運用を続けるうちにファイルが肥大化していくのが典型的な課題です。数百行を超えるCLAUDE.mdは珍しくありませんが、長くなるほどLLMの注意力は分散し、後半に書かれたルールほど無視されやすくなります。また、コンテキストウィンドウの中で大きな面積を占めるため、肝心のタスク指示や実装コードに使える余地が圧迫されるコンテキスト汚染の問題も発生します。
rulesディレクトリに小分けにルールを書く
Cursor Rulesや.claude/rules/のように、ルールファイルを分割して管理する方法もあります。カテゴリごとにファイルを分ければ見通しは良くなります。
しかし多くの実装では、これらのルールファイルはシステムプロンプトと同様に毎回すべてが読み込まれます。つまり、ファイルを分けたとしても、LLMに投入されるコンテキスト量の総量は変わりません。ルールが増えれば増えるほど、結局はCLAUDE.mdと同じ問題に行き着きます。分割したことで人間にとっての管理性は上がりますが、LLM側の認知負荷は軽減されていないのです。
docs/rules/*.md に個別記入し、必要に応じて読み込ませる
より洗練されたアプローチとして、ルールをドキュメントディレクトリに個別ファイルとして配置し、AIに必要な場面で読み込ませる方法があります。必要な情報だけを必要なタイミングで渡す、いわゆるjust-in-timeなコンテキスト提供です。
理想的に聞こえますが、実運用のハードルが高いのが実情です。「どのルールをいつ読み込ませるか」の判断を手動で行う必要があり、これはタスクの種類やコードの文脈に依存するため、事前にパターン化しきれません。AIに自動的に必要なルールを探させる方法もありますが、ルールの存在を知らないAIが適切なファイルを見つけてくれる保証はありません。結局、人間がルールの取捨選択に工数を使うことになり、レビューコストの削減が管理コストに転嫁されるだけ、という結果になりがちです。
そんなわけで、sqlewを作りました
ここまで見てきた手法には共通の課題があります。「LLMに渡す情報の量と質をどうコントロールするか」という問題に対して、いずれもファイルベースのアプローチで対処しようとしている点です。
sqlewはこの問題を、データベース駆動のMCPツールとして解決します。
プロジェクトの設計方針、コーディング規約、制約条件をsqlewに登録しておけば、AIエージェントはMCP経由で必要な情報だけを選択的に参照できます。すべてのルールを毎回読み込ませる必要はありません。いま取り組んでいるタスクに関連する方針だけが、必要なタイミングで提供されます。
これにより、コンテキスト汚染を防ぎながら、ルール遵守率を高めることができます。レビュアーが「また同じルール違反をチェックしなければ」と感じるストレスを、構造的に減らせるのです。
さらに、sqlewのバックエンドをMySQLに設定すれば、チーム内での情報共有がシームレスになります。メンバーが登録した方針や誓約は、チーム全員のAIエージェントが参照できます。git worktreeを使ったマルチブランチ開発でも、ルールファイルのマージコンフリクトに悩まされることがありません。設計方針はコードと同じリポジトリではなく、構造化されたデータベースに格納されているからです。
AIコーディングのボトルネックが「書く」から「読む」に移ったのなら、「読みやすいコードをAIに書かせる」ための仕組みに投資する価値があります。sqlewは、その仕組みのひとつです。
