LLMに「この文章を直して」と頼むと、自信たっぷりの書き換えが返ってきます。読み心地は良くなったように見えても、本当に品質が上がったかは人間が読み比べないと分かりません。セキュリティ研究者のMarco Ramilli氏が紹介した auto-improve は、この「スロップ（slop）」問題を、GAN（敵対的生成ネットワーク）風のループとGitの検証で解きます。
この記事では、auto-improveの仕組みと使い方、類似プロジェクトとの違いまでを整理します。
この記事でわかること
- auto-improveが文章改善で採用する「変異→採点→判定→コミット」の流れ
- 別モデルのjudgeとペアワイズ判定がスロップを防ぐ理由
- ルーブリックの書き方と、実際のスコア改善例
- Karpathy氏のautoresearchなど、設計の系譜
https://github.com/crimeacs/auto-improve
auto-improveとは
auto-improveは、crimeacs氏が公開したオープンソースのPythonツールです。メール、ランディングページ、プロンプト、README、API設計、設定ファイル、ブログ記事など、テキストファイルを対象に、自動で品質を引き上げます。2026年6月1日に v0.1.0 が公開され、MITライセンスで配布されています。
設計の核は「1つのLLMが変異させ、別のLLMが採点する」という分離です。改善が認められた変更だけをGitにコミットし、却下された候補は元に戻します。improve/<tag> ブランチの履歴が、そのまま改善ログになります。
なぜ「LLMに直して」だけでは足りないのか
LLMに改善を任せると、次の2点が起きやすくなります。
1つ目は、自己採点の偏りです。同じモデルが書き換えと評価の両方を担うと、見た目は整ったが中身が薄い文章を高く評価しがちです。
2つ目は、検証不能な書き換えです。全文を差し替える方式だと、どの部分が本当に良くなったのか追いにくく、悪化した変更を見逃しやすくなります。
auto-improveは、変異役（mutator）と採点役（evaluator）を分け、さらにペアワイズ判定で「現行版より良いか」を厳しく確認することで、この穴を塞ぎます。
1イテレーションの流れ
各ラウンドは、READMEに示されている次の4段階で進みます。
MUTATE（変異） — mutatorモデルが、対象ファイルへの候補編集を複数（デフォルト3件）生成します。全文の書き換えではなく、外科的な差分（surgical diff）として適用します。適用は exact → unicode正規化 → fuzzy の順に試し、壊れたパッチはスキップしてファイルを汚しません。
SCORE（採点） — evaluatorモデルが、ルーブリックに沿って各候補を並列採点します。mutatorは採点に関与しません。
DECIDE（判定） — 最良候補と現行のチャンピオンを、judgeがペアワイズで対戦させます。LLMが先に提示された選択肢を favor する位置バイアスを避けるため、[候補, チャンピオン] と [チャンピオン, 候補] の2通りで評価し、両方で候補が勝った場合だけ採用（2-0 sweep）します。
COMMIT（コミット） — 採用された変更だけをGitにコミットし、却下分は差し戻します。
このループを --max-iterations（デフォルト10回）まで繰り返し、スコアが --threshold（デフォルト90点）に達するか、上限に達するまで続けます。
ルーブリックと使い方
auto-improveは、採点基準となるルーブリック（Markdown形式、各次元の重み合計100点）を --criteria で渡せます。ルーブリックを省略すると、対象ファイルと --goal（任意の一行指示）から自動生成し、results/<tag>.rubric.md に保存します。
対象ファイルは Gitリポジトリ内 に置く必要があります。改善の採否をコミットで記録するためです。
git clone https://github.com/crimeacs/auto-improve && cd auto-improve
pip install requests
export GEMINI_API_KEY=...
python3 improve.py --artifact examples/cold-email.txt \
--criteria criteria/cold-email-quality.md --tag email
同梱のコールドメール例では、ベースライン48点から56点まで上がります。冒頭の「製品がチームの役に立つと思いまして…」のような抽象的な書き出しが、具体的な課題と数値（「デプロイ速度の拡大でQAが逼迫」「回帰テストを12時間から15分未満に短縮」）へ置き換わる、という改善がREADMEで示されています。
ルーブリックなしで始める場合は次のように実行します。
python3 improve.py --artifact path/to/your/file.md --tag v1 \
--goal "開発者が試したくなるランディングのヒーロー文にする"
主な機能と周辺ツール
Best-of-N — 1ラウンドで複数候補を出すため、1回の不運な生成で停滞しにくくなります。
メタ改善 — ルーブリック自体もテキストファイルなので、auto-improveでルーブリックを磨き、再度アーティファクトを回す、という二段階の運用がREADMEで推奨されています。生成器（プロンプトテンプレートや設定）を直接改善すれば、以降の出力品質も底上げできます。
ライブ可視化 — plot/ 配下のRust製アプリ（macroquad）が、実行中のスコア推移をリアルタイム表示します。緑が採用、赤がリセット、金がリトライを表します。
Voice notes — 同じループを音声配信向けに拡張したバリアントもあります。ElevenLabsで音声を生成し、音声モデルが採点します（voice/ 参照）。
動作環境とコスト
- Python 3.9以上
- 依存パッケージは
requestsのみ - デフォルトのmutator・evaluatorは Google Gemini（
gemini-flash-latest）。GEMINI_API_KEYまたはGOOGLE_API_KEYが必要です - 無料枠のAPIキーは Google AI Studio から取得できます
ツール本体はMITライセンスで無料です。API利用料はGeminiの料金体系に従います。
類似プロジェクトとの違い
Karpathy氏の autoresearch が、LLMによる提案と評価のループという発想の直接の源流です。auto-improveはこれをテキストアーティファクト向けに特化し、Gitコミットを改善の証跡にしました。
anthonylatona氏の autorefine や autoloop-2 も、文書改善ループ＋Gitコミットという構造を持ちます。auto-improveの特徴は、位置バイアスを除いたペアワイズ判定の2-0 sweep と、差分適用の安全装置 に重点を置いている点です。v0.1.0のリリースノートでも「mutatorは採点しない」「不正な編集はファイルを壊さない」と明記されています。
設計思想としては、2014年のGAN論文（generatorとdiscriminatorの緊張関係）と、2023年のRLAIF（AIフィードバックによる強化学習）の文脈もREADMEのLineageで言及されています。学習対象がニューラルネットではなくGitブランチ上のテキスト、という点が現代的な解釈です。
向いている用途と限界
メール文面の磨き込み、READMEの読みやすさ向上、プロンプトの精度改善、APIインターフェースの設計見直しなど、「ルーブリックで良し悪しを言語化できるテキスト」に向いています。
一方、READMEでも「弱いアイデアを一気に傑作にする魔法ではない」と述べられています。明らかなスロップや明確に劣る選択肢を機械的に削るツールであり、最終判断は人間が行う前提です。Git管理とAPIキーの準備が必要な点も、手軽なチャット改善とはトレードオフになります。
自動リファクタリングや自己改善エージェントの文脈で注目が集まる今、auto-improveは「改善の証拠をGitに残す」という実装が、再現性と監査性の両面で示唆に富んでいます。対象ファイルとルーブリックを用意し、python3 improve.py を走らせれば、ターミナル上でスコアの推移を追いながら、検証済みの改善だけが積み上がっていく様子を確認できます。