AIに改善を頼むときは、採点表を途中で動かさない

AIに「このプロンプトをもっとよくして」「この手順を改善して」と頼む場面が増えました。返ってきた改善案を見て、目の前の例が通ると、たしかによくなった気がします。

ここで起きやすいのは、改善案ではなく採点表のほうが少しずつ動くことです。最初は「必須項目を落とさない」だったのに、途中から「この例で自然に見えればよい」に変わってしまうような状態です。

過去の記事では、AIに任せる前に外したくない端や確かめ方を残す話を書いてきました。今回はそこから一歩だけ絞って、同じ改善ループ中に採点表と未提示例を動かさない、という話にします。

HarnessOpt-Bench は、LLMにエージェントの harness を改善させる評価です。harness には、プロンプト、ツール、制御フロー、メモリ、周辺コードが含まれます。研究では、開発中に見える評価と、最後まで隠しておく test partition を分けて、改善が外へ持ち出せるかを見ています。

本文で特に使いやすい見方は、見えている validation score が楽観的になりやすいという点です。目の前の点数が上がっても、最後に隠していた条件では下がることがある。これは日常のAI活用にも近い感覚があります。

たとえば、AIに議事録テンプレ、レビュー観点、調査メモの型を改善してもらうときも、途中で採点表を変えると、良くなったのか、見方を変えただけなのかが混ざります。先に採点表と未提示例を固定しておくと、AIの改善案を受け取るときの足場が残ります。

今日できるのは、AIに改善を頼む前に、採点表をロックすることです。

一行目に「変えてよい部分」を書きます。言い回し、順番、例の出し方などです。二行目に「途中で変えない採点表」を書きます。必須項目が落ちていない、出力形式が守られている、知らない前提を足していない、のような確認です。三行目に「最後までAIに見せない例」を置きます。

たとえばレビュー依頼文を改善するなら、「変えてよい: 説明順と文量」「途中で変えない: 変更範囲、懸念、確認してほしい観点を必ず残す」「最後に見る未提示例: 今日とは別のPRで同じ型が使えるか」と書いてからAIに渡します。改善案を見て採点表を直したくなったら、その場では変えず、次の改善ループ用のメモに分けます。

この研究は、日常の採点表ロックの効果を直接検証したものではありません。扱っているのは、LLMがエージェントの harness を改善するベンチマークです。ここで借りるのは「改善中に見える点数」と「最後に見る条件」を分ける考え方です。

何度もAIに改善してもらう作業では、採点表を途中で変えたくなることがあります。そのときは、同じ改善ループの中でこっそり変えず、別の版として残すほうがよさそうです。変えた理由が残れば、未来の自分もチームの人も、なぜその型になったのかを追いやすくなります。

AIで速く直せる時代ほど、人間側に残る仕事は、何を改善と呼ぶかを先に決めることなのだと思います。まずは今日使う小さなプロンプトやテンプレで、変えない採点表を一つだけ横に置いてみます。