AIシステムの精度向上は、AIエージェントに「慎重に考えて改善するように」と指示し、ループを何度も実行させることではない。

　自動改善を機能させるには、まず「何をもってよい出力とするのか」を具体的に定義する必要がある。AIエージェントが目指す状態と、現在の出力との差を測る基準が「Target Function」（目標関数）だ。

　評価基準が曖昧であれば、AIエージェントはどの変更によって品質が高まったのかを正確に判断できない。意味のある改善が起きていないにもかかわらず、評価とプロンプト修正を繰り返し、トークンだけを消費する恐れがある。

　重要なのは、「正確性」や「有用性」といった抽象的な指標を、原因分析や改善に使える具体的な判定基準へ分解することだ。

「正確さを5段階で評価」ではシグナルが弱い

　企業が生成AIの回答品質を測る際には、「正確性」「有用性」「親切さ」「幻覚の少なさ」といった評価項目を使うことがある。

　例えば、回答の正確性を0～1、有用性を1～5で大規模言語モデル（LLM）に採点させる方法だ。

　こうした総合スコアは、AIシステムの品質を大まかに把握する用途には役立つ場合がある。しかし、AIエージェントが自動改善の判断材料として使うには、シグナルが弱い。

　「有用性が3点」とは具体的にどのような状態なのか。2点と3点、3点と4点の違いは何か。各点数を付ける条件が定義されていなければ、評価を担当するLLMは、その都度異なる観点で点数を付ける可能性がある。

　LLMの出力には非決定性があるため、同じ回答を同じ評価用プロンプトで採点しても、実行するたびに異なる点数になる場合もある。評価結果が揺れれば、改善を担当するAIエージェントは、プロンプトの変更によって本当に品質が上がったのかを判断できない。

　曖昧な評価値のわずかな上昇や下降に反応してプロンプトを書き換え続ければ、AIシステムの品質はほとんど変わらないまま、生成AIモデルの呼び出し回数とトークン消費量だけが増える。

抽象的な品質をYesかNoに分解する

　そこでシャファー氏は、「正確性」や「有用性」といった抽象的な評価項目を、そのまま自動改善に使うのではなく、企業の業務に合わせた具体的な判定基準へ分解することを推奨する。

　ポイントは、可能な限りYesかNo、または明確なカテゴリで答えられるようにすることだ。

　例えば、社内ナレッジを検索して回答するAIシステムであれば、「回答は正確か」と総合的に評価するのではなく、「回答内の事実は、検索によって取得したナレッジに記載されているか」と判定する。

　ブランド表現を重視する企業であれば、「ブランドの雰囲気に合っているか」を5段階で採点するのではなく、「企業名と製品名が正式表記になっているか」「翻訳してはいけない固有名詞を別の言語に変換していないか」と確認する。

　既知の不具合がある場合には、生成AIモデルの出力が、あらかじめ定義した5種類の失敗パターンのどれに該当するかを分類させる方法もある。

　個々の評価項目が完全に決定論的になるとは限らない。それでも、単に「正確性は4点」と採点するより、AIエージェントがどの問題を改善すべきかを判断しやすくなる。

　自動改善で必要なのは、品質を1つの数字で表現することではない。企業にとって重要な品質要件を、原因分析と改善につなげられる小さな判定項目へ分解することである。

評価基準はAI開発者だけでは作れない

　業務に適した評価基準を作るには、その領域に詳しいドメイン専門家の知識が欠かせない。

　医療向けのAIシステムであれば医療従事者、法務文書を扱うのであれば法務担当者、顧客対応を自動化するのであればカスタマーサポート担当者が、業務上の良い回答と悪い回答を理解している。

　ただし、専門家に「正しい回答の条件を書いてください」と依頼するだけでは、十分な評価基準を作るのは困難だ。専門家の判断には、経験を通じて身に付けた暗黙知が含まれている。専門家本人にとっては当然なので、言葉で説明する必要性を感じていない場合がある。

　そこでシャファー氏は、専門家と開発担当者が実際のデータやAIシステムの出力を一緒に確認することを薦める。

　まず、代表的な入力に対して、どのような回答を出すべきかという具体例を専門家に示してもらう。次に、AIシステムを試行し、得られた回答を一緒にレビューする。その際、「この回答はなぜ良いのか」「こちらの回答はなぜ不適切なのか」「似た2つの事例で判断が異なるのはなぜか」と質問する。

　具体的な事例を比較することで、専門家が暗黙のうちに使っている判断基準を抽出し、ルールや評価項目として言語化できる。

　専門家の知識を「プロンプトに書き込む情報」としてだけ扱うのではなく、AIシステムの出力を評価する仕組みとしてコード化することが重要だ。

　評価基準として組み込めば、プロンプトや生成AIモデルを変更した後も、専門家が重視する品質を維持できているかどうかを継続的に確認できる。

本番稼働後は「よい回答」の定義も変化する

　評価データと判定基準は、一度作成すれば完成というものではない。

　AIシステムを本番環境で公開すると、開発時には想定していなかった質問や使い方が発生する。ユーザーが別の目的でAIシステムを使い始めたり、対応する業務の範囲が広がったりすることもある。

　利用方法が変われば、AIシステムに求められる品質や、発生しやすい失敗パターンも変化する。

　そのため、本番環境のデータを人間が定期的に確認することが有用だ。改善を担当するAIエージェントにログ分析からプロンプト修正まで全て任せるのではなく、AI開発者とドメイン専門家が実際の出力を読み、利用方法の変化を把握する。

　新しい失敗パターンが見つかった場合は、それを評価用データに追加する。新たに重要になった品質要件があれば、判定基準も更新する。

　本番環境におけるAIシステムの挙動を継続的に確認することで、ユーザーが問題を報告する前に典型的な不具合を捉えやすくなる。

過学習を防ぐ検証用データを分離する

　AIエージェントがプロンプトを自動改善する場合、改善に使用したデータだけで性能を評価しないようにする。

　同じデータに対して修正と評価を繰り返せば、AIエージェントはそのデータに含まれる事例だけをうまく処理するプロンプトを作る可能性があるためだ。

　例えば、特定の製品に関する問い合わせを多数含む評価データを使って改善すると、その製品への回答精度は高まっても、別の製品への回答品質が下がる恐れがある。

　こうした過学習を防ぐには、プロンプト改善に使うデータと、改善案を評価するデータを分ける必要がある。可能であれば、改善処理から完全に切り離した最終確認用のデータも確保することが望ましい。

改善ループを止める「エスケープハッチ」を設ける

　AIエージェントの改善ループには、明確な終了条件も欠かせない。精度が一定水準に達した場合、指定した回数を実行した場合、複数回試しても検証用データのスコアが向上しない場合には、処理を停止する必要がある。

　終了条件がなければ、AIエージェントは有効な改善案を見つけられないまま、何時間もエラー分析とプロンプト修正を繰り返す可能性がある。

　シャファー氏は、改善ループが壁に突き当たったときに処理を終了できる仕組みを「エスケープハッチ」と表現する。エスケープハッチが必要な理由は、費用だけではない。

　改善を繰り返すほど必ず性能が上がるわけではない。ある問題を解決するために追加したルールが、別の問題への回答品質を下げる可能性もある。プロンプトが長く複雑になり、生成AIモデルが重要な指示を捉えにくくなる恐れもある。

　AIエージェントに「改善できるまで続ける」と指示するのではなく、どの条件なら改善案を採用し、どの条件なら処理を止めて人間の判断に戻すのかを、あらかじめ定義しておくことが重要だ。

なぜAIコーディングエージェントは自動改善しやすいのか

　では、明確な評価基準は、自動改善の成果にどれほど影響するのか。AIを使った自動改善が比較的機能しやすい分野の1つが、ソフトウェア開発だ。

　ソースコードには、「コンパイルできるか」「テストを通過するか」といった比較的明確な評価基準がある。コードがコンパイルできたからといって、ユーザーが求める機能を全て備えているとは限らない。保守性や安全性、処理速度などに問題が残っている可能性もある。

　それでも、少なくともプログラムとして実行できるかどうかは、YesかNoかで判定できる。

　AIコーディングツールを使った改善ループでは、生成したコードを実行し、コンパイルエラーやテストの失敗を確認し、その結果を基にコードを修正できる。AIエージェントにとって、どこを直すべきかを示すシグナルが明確だ。

　一方、ヘルスケアやコンプライアンス、カスタマーサポートなどの領域では、「この回答は正しいか」という問いに単純なYesかNoで答えられないことがある。

　事実関係は正しくても、説明が不十分だったり、ユーザーの状況に合っていなかったり、社内規則で禁止された表現を使っていたりする可能性がある。複数の回答がいずれも妥当という場合もある。

　企業がAIエージェントに与える目標も、一般的には不完全だ。「顧客に役立つ回答を作る」「正確に書類を確認する」といった指示だけでは、何を優先し、どの状態を不合格とするのかが分からない。

　曖昧な目標を基にAIエージェントが改善を続ければ、数値上の評価は上がっても、実際の業務では使いにくいAIシステムになる恐れがある。

明確な判定基準ならプロンプトは自動改善できるのか

　シャファー氏のチームは、Target Functionの明確さが自動改善にどのような影響を与えるのかを確認するため、単一ラベルの分類タスクを使った実験を実施した。

　実験の対象は、学術論文の分類だ。生成AIモデルは、論文のタイトルと要旨を読み、あらかじめ用意された複数のラベルから1つを選択する。

　論文の著者が選んだ正解ラベルと、生成AIモデルが予測したラベルが一致すれば正解、一致しなければ不正解と判定する。一般的な文章生成と比べて、評価結果を明確に数値化しやすいタスクである。実験では、データを次の3種類に分けた。

• プロンプトの改善に使う「Fit」データ（200件）
• 改善案が未知のデータにも通用するかどうかを確認する「Validate」データ（100件）
• 最終的な性能を測る「Test」データ（300件）

　Testデータは、自動改善を担当するAIエージェントから見えないようにした。AIエージェントが改善用データだけに過剰適合し、見慣れない入力に対応できなくなる「過学習」を防ぐためだ。

　分類を実行する生成AIモデルには、小型で比較的安価なモデルを使用した。最初のプロンプトは、利用できるラベルを並べて、「この論文を分類する」と指示するだけの簡単な内容だった。

　別の高性能な生成AIモデルを使ったAIエージェントが、分類結果を分析し、プロンプトの改善案を作成した。

　改善ループは、まずFitデータに対して分類を実行し、どのラベルで誤りが多いか、どのラベルの組み合わせを混同しているかを分析する。その後、最も大きな失敗パターンに対処するプロンプト修正案を作り、Validateデータで精度を再測定する。

　Validateデータでも精度が向上した場合だけ、新しいプロンプトを採用する仕組みとした。最大15回実行するか、正解率が92％に達した時点で改善ループを終了する条件も設定した。

最初の改善だけで正解率が10ポイント上昇

　シャファー氏によると、最初のプロンプトによる正解率は68％だった。AIエージェントが1回目の分析とプロンプト修正を実行すると、正解率は78％に上昇した。わずか1回の改善で10ポイント向上したことになる。

　その後も改善を繰り返し、正解率は最大83％に達した。以降は80％前後で推移し、改善に使っていない300件のTestデータでも正解率は80.2％となった。改善用データだけでなく、未知のデータでもほぼ同じ精度を維持したことから、自動的に作成したプロンプトには一定の汎化性能があったとシャファー氏は説明する。

　特に注目すべきなのは、最初の改善で生じた大幅な精度向上だ。

　改善を担当するAIエージェントは、64件の誤分類を調べ、どのラベルの組み合わせで間違いが集中しているかを特定した。その上で、「この失敗パターンに対処すれば精度が上がる」という仮説を立てた。

　その仮説を基に、AIエージェントは単にラベルごとの意味を補足するのではなく、分類時の判断方法そのものをプロンプトに反映した。AIエージェントがプロンプトに加えたのは、単なるラベルの説明ではなかった。

　論文を分類するときの基本的な思考手順、似たラベルを区別する条件、広い意味を持つラベルより具体的なラベルを優先するルール、頻繁に間違える分類の具体例などを追加した。

　例えば、2つのラベルを頻繁に混同している場合、「どのような特徴があれば一方を選ぶか」「どのような条件なら他方を選ぶべきか」を明文化した。

　正解と不正解が明確だったため、AIエージェントは失敗を定量的に分析し、具体的な改善仮説を立てることができた。その結果、最初の1回で大きな精度向上が得られたのである。

明確に見える「正解」にも人間の判断が入る

　ただし、単一ラベルの分類タスクであっても、完全に客観的な正解が存在したわけではなかった。

　実験で使用した正解ラベルは、各論文の著者が選択したものだった。論文の内容によっては複数のラベルが妥当でも、著者がその時点で重視した観点に基づいて、1つのラベルを選んでいる場合がある。

　生成AIモデルが意味として妥当なラベルを選んでも、著者が付けたラベルと異なれば、実験上は不正解になる。つまり、正解と不正解を明確に判定できるように見えるデータにも、人間の解釈や判断、暗黙の前提が含まれる。

　企業が過去の問い合わせ履歴や審査結果、契約書の分類結果などをAIシステムの正解データとして利用する場合にも、同様の問題が起こり得る。

　過去の担当者によって判断基準が違ったり、当時の社内規則に基づく結果が現在では正しくなかったりする可能性がある。既存データをそのまま正解と見なすのではなく、なぜその判断になったのかを確認する必要がある。

自己改善の主役はAIエージェントだけではない

　Langfuseの実験は、正解と不正解を区別できる高シグナルな評価基準があれば、AIエージェントが失敗パターンを分析し、有効なプロンプト修正案を作成できることを示した。

　一方で、実験に使った分類データにも、人間の判断や暗黙の前提が含まれていた。実際の業務では、評価基準の曖昧さはさらに大きくなる。

　そのため、目指すべきなのは、AIエージェントが単独で自己改善を続けるAIシステムではない。まず、ドメイン専門家がデータを確認し、対象業務で「よい出力」とは何かを定義する。次に、抽象的な品質をYesかNo、または明確なカテゴリで判定できる評価項目へ分解する。

　AIエージェントは、その評価結果を基に失敗パターンを分析し、プロンプトなどの改善案を作成する。AI開発者は、改善用データと検証用データを分離し、未知の入力にも通用する場合だけ変更を採用する仕組みを整える。

　改善が止まった場合には、際限なく処理を続けさせず、人間がデータと評価基準を見直す。

　明確なTarget Function、専門家の知識を反映した評価項目、十分な評価データ、過学習を防ぐ検証方法、処理を打ち切る終了条件を用意して初めて、自動改善ループはトークンを燃やすだけの処理ではなく、AIシステムの品質を継続的に高める仕組みになる。

本稿は、AI Engineerが2026年7月19日に公開した動画「Stop Burning Tokens：Why self-improvement needs domain expertise first Annabell Schafer, Langfuse」を基に作成しました。