最近Claude Codeのスラッシュコマンドなど、AIによるコード生成をさせる時、ドキュメントを参照するだけより、ドキュメントを参照した後に類似を自動検索させた方が生成の精度が上がると感じた。今回はその方法を紹介する。
ドキュメントだけで生成すると細かいニュアンスで気になることが多い
コード生成をさせる時、何も無しでいきなり生成するよりも、コーディング規約やデータベース設計ガイドラインなど、チームで決めたルールを読み込ませてから生成する方が精度が上がると言われている。LLMの特性上、何もルールがないよりチームルールを明示することで、それに近いものが生成されるのは自明だ。
一方それだけだと「だいたい合ってるんだけど、細かいところで気になるなあ」と感じることが多かった。たとえば書き方がプロジェクト内の他の場所と少し違うなど。
ドキュメントを参照した後に類似を自動検索させる
「だいたい合ってるけど違う」となる理由は、ドキュメントではプロジェクトのルールのサマリーをしたものになっていて、細かいニュアンスまで含められていないからと考えた。確かに自分たちで実装する時も、ルールのドキュメントを参考にした後に、周辺の類似部分をコードリーディングしてから、この書き方と合わせようなどとその都度柔軟に意思決定をしていることが多い。
では同じような流れで、ドキュメントを参照した後に、これから生成しようとしているコードに似たものを自動検索させて、その後にコード生成をさせたら精度上がるのでは?と思ったので試してみた。このようにすることで、体感値ではあるが、かなり精度が上がった。
たとえば以下はデータベースのALTER TABLE文を生成するためのスラッシュコマンド。ポイントは、自分で類似ファイルを渡すのではなく、これから作ろうとしている内容の類似ファイルを自動で検索させること(手順の3の部分)。
---
allowed-tools: Read, WebFetch, TodoWrite, Grep, WebSearch, Search
description: データベースマイグレーションファイルを作成
---
あなたはMySQLの専門家としてデータベースマイグレーション作成を行います。
## 手順
1. $ARGUMENTS に書かれた要件を理解する
2. DBの設計ガイドラインである @docs/db-guideline.md を読み込む
3. 既存のマイグレーションファイルから似ているマイグレーションを5件読み込む
- `migrations/` ディレクトリで似たような変更をしているファイルを5件ほど調べ、書き方のルールを確認
- 以下のことなどを特に確認:
- インデント
- どのようなALTER TABLE形式が好まれるか
- 命名規則
- 型の扱い
- NULL許可の扱い
- DEFAULTの書き方
- COMMENTの書き方
4. ガイドラインと類似実装を参考にマイグレーションファイルを作成
- MySQL 8の構文に従って正確なSQLを記述
## 重要な注意点
- **規約の遵守**: ドキュメントに書かれた規約を必ず守る
- **一貫性**: 既存コードとの一貫性を保つ
- **確認**: 生成したコードがプロジェクトのスタイルに合っているか確認
それでは $ARGUMENTS に従ってマイグレーションファイルの生成を始めましょう。
いろんなケースで同じ考え方が使える
この「ドキュメントを参照した後に類似を自動検索させる」という考え方は、いろんなケースで使えると思う。たとえばブログ記事で自分と似た文章を書かせるところで応用すると、こういう形になる。
CLAUDE.md
記事を書くときは必ず @WRITING.md を参照してください。
また書こうとしている記事の内容から、それに似た最近の記事をランダムに数記事ピックアップし、
- 構成を参考にしてください
- 文体をできる限り模倣してください
記事は shibayu36.hatenablog.com/ ディレクトリ配下に入っています。
まとめ
今回は、ドキュメントを参照した後に類似を自動検索させることで、コード生成や文章生成の精度を上げる方法を紹介した。体感値ではあるが、かなり細かい部分が気にならなくなったので、一度試してみて欲しい。