AIコーディングが普及した昨今、AIが生成したプルリクエストのレビュー中に「なんでAIはこの設計にしたのだろう？」と首をかしげることも多くなっているのではないでしょうか。
あるセッションではリポジトリパターンで丁寧に書いてくれたのに、次のセッションでは直接SQLを叩きはじめる。昨日は合意したはずのエラーハンドリング方針を、今日はまるで知らなかったかのように無視する。AIが生成するコードの一貫性のなさは、レビューコストを押し上げ、結果的に開発速度を落とす要因になっています。
なぜこうなるのか。根本的な原因は、AIがプロジェクトの設計判断とその背景を「知らない」ことにあります。
「指示」だけでは一貫性は保てない
この課題への一般的なアプローチは、CLAUDE.mdに「リポジトリパターンを使うこと」「エラーは集約ハンドラで処理すること」と指示を書くことです。しかし、LLMのInstruction Following研究が示すように、指示の遵守率はモデルや状況で大きくばらつきます。推論が長くなるほど指示が無視される傾向があり、セッションが進むにつれてAIが当初の方針から逸脱していく現象は、多くの開発者が体感しているはずです。
指示は「何をすべきか」を伝えますが、「なぜそうすべきか」は伝えません。理由を知らないまま従うルールは、状況が変わった瞬間に簡単に破られます。
「理由」を渡すという発想
ソフトウェアエンジニアリングにはADR（Architecture Decision Record）という手法があります。設計判断を「背景」「決定事項」「結果」の3要素で記録するドキュメントで、AWSのPrescriptive Guidance（2022年）でもプロジェクトの意思決定を効率化する手法として紹介されています。
同ガイドが強調するのは、ADRの焦点が「実装方法」ではなく「判断の理由」にあるという点です。なぜその判断に至ったかが明確であれば、判断が安易に覆されることを防げると述べています。
この考え方は、AIに対しても同様に機能します。「リポジトリパターンを使え」という命令の代わりに、「データアクセス層の差し替え可能性を担保するためにリポジトリパターンを採用した」という根拠を渡す。AIは指示に「従う」のではなく、設計意図を「理解」したうえでコードを書けるようになります。
命令で制御するのではなく、理由で導く。このアプローチは、AIが生成するコードの一貫性を高めるうえで本質的な違いを生みます。
sqlewが目指すもの
sqlewは、開発中の設計判断をADRの構造で蓄積し、AIエージェントがMCP経由で必要な根拠をJust-in-Timeで参照できるようにするツールです。RAGやエンベディングは不要で、導入後すぐに稼働します。
AIに「何をすべきか」だけでなく「なぜそうすべきか」を渡す。AWSが人間のチーム向けに提唱した発想を、AIとの協働に拡張する——私たちはその発想をsqlewに活かしています。
参考文献
- "Using architectural decision records to streamline technical decision-making for a software development project" — AWS Prescriptive Guidance (2022) — https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html
