「人間の集中力」を最適化する評価自動化とは？
では、具体的にどうやって評価の仕組みを作ればいいのか。その根底にあるべき考え方は、「人間の集中力とやる気を、いかに最も重要な場所へ配分するか」だ。
初期段階において、AIの出力を人間が一つひとつ目で確認することは確かに有効である。しかし、運用フェーズに入ってからもこれを続けるのはコストがかかりすぎる。「AIを作ること・評価において、最大の戦略資源って『人』なんですよね」とアイシア氏が語る通り、人間の認知リソースは限られており、無駄遣いは厳禁だ。
そこで役立つのが、AIの出力を別のLLMに採点させる「LLM-as-a-Judge」というアプローチである。これなら人間よりも安価かつスピーディーに評価を回せる。
ただ、LLM-as-a-Judgeにも弱点がある。それは「理想の評価と、実際に書いたプロンプト表現がズレている」こと、および「プロンプト通りにLLMが読み取ってくれない」ことだ。AIに特定のキャラクター設定や繊細なルールを守らせるためのプロンプトは、まるでアニメの設定資料集を作り込むような、泥臭く難しい作業になる。
こうしたズレを乗り越えるための実践的な手法が「Evaluator-Optimizer Loop」だ。これは、システム本体のプロンプトと、評価用プロンプト（LLM-as-a-Judge）を交互に改善していくループである。
アイシア氏が「作っている本体のプロンプトと、LLM-as-a-Judgeのプロンプトの両方を交互に改善していきましょうというループでございます」と説明するこの手法では、まずLLM-as-a-Judgeの出したスコアを絶対視し、スコアが上がるように本体のプロンプトをハック的に改善する。その後、ハイスコアを出した結果だけを「人間の目」で確認し、「意図しないジェイルブレイクが起きていないか」などの評価基準の抜け漏れを探す。そして、その抜け漏れを防ぐように評価用プロンプトを修正し、再びループを回すのだ。
ここで徹底すべきは、「この評価のスコアを高めようとしている時に人の目で見ないということが本質」というルールである。人間の貴重な集中力は、スコア上げの作業ではなく、「LLM-as-a-Judgeのズレがどうなっているか」を発見するクリエイティブな工程にのみ注ぐべきなのだ。
さらに、評価を安定させるコツとして、10点満点のような曖昧な採点ではなく「指定の語尾がついているか」といった明確な基準でYes/Noを数える「Yes/No Questions」や、各段階の達成度を細かく言語化した「Rubric（ルーブリック）」を使うのがおすすめだという。これらを組み合わせることで、従来のシステム開発のような継続的インテグレーションが実現し、開発体験も大きく向上する。
最後にアイシア氏は、「時代は考えるよりも実行する時代で、AI作りもOps（運用）が本質の時代です」と力強く語った。統計学の専門家である同氏でさえ、ここ半年はLinuxやDocker、Kubernetes、AWSといったインフラやネットワークの勉強に時間を全振りしているという。
AIの技術的な壁が取り払われ、評価やCI/CDといったDevOpsのスキルが直結する今こそ、現場のITエンジニアが最も輝く時だ。「皆さんは楽しくバンバン面白いもの、自分の作りたいもの、欲しいものを作っていただければいいんじゃないかと思います」そんなエールとともに、セッションは締めくくられた。
