「練習問題」はどこまで自動で作れるか — 評価データ生成のツールと論文から、普通のエンジニアにできる範囲を見極める

前回の記事 では、GEPA などがプロンプトをどう直すかを見ました。そこで繰り返し出てきたのが、ツールが自動でやるのは「添削係」だけで、練習問題と採点は人が用意するという点です。

では、その練習問題を AI に作らせることはできないのか。本稿はこの問いに答えます。

このブログでは以前にも、評価用テストペアを生成する手法のサーベイ と コード付きの実装ガイド を書きました。今回はそれらと視点を変えて、次の 3 点に絞ります。

• 2026 年 11 月時点のツールで、何がコマンド 1 つでできて、何ができないか（各ツールの公式文書と GitHub で確認しました）
• 論文から分かる、生成した練習問題の落とし穴（数値は各論文の要旨で確認しました）
• EC の問い合わせ、法務チェック、社内規程の問い合わせで、どこまで自動化するのが現実的か

先に結論を書きます。

• 入力（問い合わせ文など）を増やすのは簡単です。 コマンド 1 つ、または画面のボタン 1 つでできます。
• 文書がある業務なら、問題と参照回答まで自動で作れます（社内規程の問い合わせなど）。
• 採点基準は「案」までは自動で作れますが、人が出力を見て直す工程は省けません。 出力を見る前に基準を決めきれないことが、研究でも示されています。
• 会話の模擬は作れますが、模擬の利用者は本物より素直で、評価が甘くなります。 それでも、版同士の比較には使えます。
• 正解を機械で確かめられる課題を自動で作るのが、いま一番進んでいる領域です（コードのバグ修正など）。ただし一般の業務では、正解の確かめ方を自分で設計する必要があります。
• 生成した問題は、本物より易しくなりがちです。 本番の記録から拾った問題と、人が作った難しい問題を必ず混ぜます。

1. 練習問題は何でできているか

練習問題 1 問は、次の 4 つでできています。

プロンプトの最適化に使うなら、さらに 2 つの条件が加わります。

• 学習用・検証用・試験用の 3 つに分ける（サーベイ記事 を参照）
• プロンプトの良し悪しで点に差が出る問題を含める。 p1（2026 年 4 月）は、どのプロンプトでも同じ点になる問題が多いと最適化が効かないことを示し、差が出る問題だけを選ぶ方法を提案しています。

2. 自動化の 5 段階

練習問題の自動生成は、難しさの順に 5 段階に分けると見通しが良くなります。

以下、段階ごとにツールの使い方と、論文から分かる注意点を見ていきます。

3. 段階 1：入力を増やす

一番簡単で、効果も分かりやすい段階です。

promptfoo：設定ファイルから人物像ごとに増やす

promptfoo は、プロンプトの変数（{{inquiry}} など）を埋める入力を自動で作れます（この機能は文書でベータ版と明記されています）。

promptfoo generate dataset --config promptfooconfig.yaml --output tests.yaml \
  --numPersonas 5 --numTestCasesPerPersona 3 \
  --instructions "配送遅延、返品、支払いの問い合わせを含め、怒っている客も混ぜる"

まず人物像を作り、人物像ごとに入力を作ります。生成に使うモデル（--provider）は、評価されるモデルとは別に指定できます。なお promptfoo は 2026 年 3 月に OpenAI による買収が発表されましたが、README には「オープンソースで MIT ライセンスのまま」と書かれ、開発も続いています。

NeMo Data Designer：分布を設計して作る

NVIDIA の NeMo Data Designer（オープンソース、Apache-2.0）は、列ごとに作り方を指定する方式です。「問い合わせの種類」は決まった割合で抽選し、「問い合わせ文」は LLM に書かせる、といった組み合わせができます。

import data_designer.config as dd
from data_designer.interface import DataDesigner

data_designer = DataDesigner()
config_builder = dd.DataDesignerConfigBuilder()
config_builder.add_column(dd.SamplerColumnConfig(
    name="category", sampler_type=dd.SamplerType.CATEGORY,
    params=dd.CategorySamplerParams(values=["配送遅延", "返品", "支払い", "在庫"])))
config_builder.add_column(dd.SamplerColumnConfig(
    name="mood", sampler_type=dd.SamplerType.CATEGORY,
    params=dd.CategorySamplerParams(values=["落ち着いている", "急いでいる", "怒っている"])))
config_builder.add_column(dd.LLMTextColumnConfig(
    name="inquiry", model_alias="nvidia-text",
    prompt="{{ mood }} お客様が、{{ category }} について EC サイトに送る問い合わせを 1 通書いて"))
preview = data_designer.preview(config_builder=config_builder)

（README の例を、EC の問い合わせ向けに書き換えたものです。model_alias は使うモデルの設定に合わせます）

ほかに、LLM に判定させる列、Python で検証する列、既存のデータを種にする列などがあります。「本番の問い合わせの種類の割合に合わせて作る」ことができるのが強みです。

DeepEval：何もないところからも作れる

DeepEval の Synthesizer は、文書・文脈・既存の例のどれからでも、何もないところからでも（generate_goldens_from_scratch）入力を作れます。次の章で使う文書からの生成と同じ道具でそろえられるのが利点です。

画面で増やす：Opik と LangSmith

• Opik（オープンソース）: データセットの画面で「Expand with AI」を押すと、既存の例をもとに 1〜100 件の候補を作り、確認してから新しい版として保存できます。文書は「質の高い例が 5〜10 件以上あると良い」「まず 10〜20 件で試し、必ず中身を確認する」としています。
• LangSmith（商用）: データセットに型（スキーマ）が定義されていれば、「Add AI-Generated Examples」で例を作れます。作った例には合成データの印が付きます。

なお、Anthropic Console にあった「テストケースを生成する」機能の専用ページは、現在の文書からは消えていました。代わりに、「基準になる例を数件用意し、Claude に増やさせる」という助言が載っています。

段階 1 の注意：多様性は、指定しないと出ない

DataMorgana（2025 年 1 月）は、文書から 1 問ずつ作る従来の方法では、1 問ずつは良くても全体として現実の利用者の多様さを覆えないと指摘しています。そこで「利用者の種類」と「質問の種類」とその割合を設定で指定して生成し、既存のツールより語彙・構文・意味のすべてで多様な問題集を作れたと報告しています（DataMorgana 自体は、研究コンペの参加チーム向けの限定公開でした）。

実務では、promptfoo の人物像、Data Designer の抽選列、後述する Ragas の人物像と質問の割合の指定が、同じ役割を果たします。「何を何割」を自分で決めて指定するのが、段階 1 の一番大事な作業です。

4. 段階 2：文書から、問題と参照回答を作る

社内規程や FAQ のような文書がある業務では、問題と一緒に参照回答（模範解答）と根拠の箇所まで自動で作れます。

DeepEval

from deepeval.synthesizer import Synthesizer

synthesizer = Synthesizer()
goldens = synthesizer.generate_goldens_from_docs(
    document_paths=["就業規則.pdf", "経費精算規程.docx"])

出力は「入力・期待する出力・文脈」の組です。難しくする仕掛けとして、推論を要する問いにする、複数の箇所を組み合わせる、条件を付ける、比較させる、仮定の状況にする、といった「進化」の種類を割合で指定できます。文書によると、このうち複数箇所の組み合わせ・具体化・条件付け・比較の 4 つは、問いが元の文書から離れにくいものです。質の低い問いを別のモデルに判定させて落とす設定もあります。

Ragas

from ragas.testset import TestsetGenerator

generator = TestsetGenerator(llm=generator_llm, embedding_model=generator_embeddings)
dataset = generator.generate_with_langchain_docs(docs, testset_size=10)

文書から知識のつながり（知識グラフ）を作り、そこから問題を作ります。既定では、1 か所で答えられる具体的な問いが半分、複数の箇所をまたぐ問いが残り半分です。人物像を指定することもできます。ただし、リポジトリは別の組織に移り、最後のリリースは 2026 年 1 月で、開発のペースは落ちています。

Giskard

Giskard は 2026 年に v3 として作り直されました。以前の RAGET（generate_testset で 6 種類の質問を作る機能）は v2 側に残り、README には「v2 は使えるが、積極的には保守していない」とあります。v3 では quality_scan という名前になり、知識ベースを渡して点検する形に変わりました。古いブログ記事のコードは v2 向けのことが多いので注意が必要です。

段階 2 の注意：作った問題は易しくなる

What Has Been Lost with Synthetic Evaluation?（EMNLP 2025 Findings）は、人が丁寧に作った読解の問題集 2 つを LLM に作り直させ、比べました。生成した問題は、作成の指針に照らして妥当なものが多く、費用も元の何分の一かで済みました。しかし、LLM にとって、人が作った元の問題より易しかったのです。

STELLAR-E（2026 年 4 月）も、自動生成した問題集は既存の問題集とおおむね同等の質だったものの、本物の問題集のほうが少し難しく、特に小さいモデルで差が出たと報告しています。

対策は 2 つです。

• 難しくする仕掛けを使う。 AutoBencher（ICLR 2025）は、「難しい」「話題として重要」といった条件を宣言し、問題集の説明文自体を LLM に改良させることで、既存の問題集より 22% 多くモデルの誤りを引き出しました。DeepEval の「進化」も同じ方向の仕掛けです。
• 本番の記録と、人が作った難問を混ぜる。 生成した問題だけで作った問題集は、合格の判定には使わないようにします。

5. 段階 3：採点基準を作る

ここから、人の関与が欠かせなくなります。

ツールでできること

• promptfoo の generate assertions: プロンプトを読んで、採点の項目を自動で提案します。既定で 5 個、互いに重ならない独立した項目だけを足します。
• LangSmith の Align Evaluator: LLM による採点が、人の判定とどれだけ一致するかを測る機能です。人が 20 件以上に判定を付け、採点役のプロンプトを直しながら一致度を上げていきます。

論文：採点基準は、出力を見ないと決まらない

Who Validates the Validators?（UIST 2024）は、LLM が採点項目と採点用の関数やプロンプトを提案し、人が一部の出力に判定を付けて、人の判定に合うものを選ぶ道具（EvalGen）を作りました。この研究の一番の発見は、利用者の側で起きたことです。

• 基準のずれ: 出力を採点するには基準が要る。ところが、出力を採点していくうちに基準そのものが定まっていく。
• 一部の基準は、実際の出力を見て初めて出てくる。

つまり、採点基準を最初に全部決めてから問題を作る、という順序は成り立ちません。基準の案を自動で作り、出力を見て直し、また作る、を回すしかありません。

同じグループの SPADE は、別の角度から基準を作ります。開発者はプロンプトを直すたびに「〜しないこと」といった指示を足していく。その変更履歴こそが採点項目の宝庫だ、という発想で、履歴から確認用の関数の候補を作り、最小限の組を選びます。実在の 9 つの処理で、単純な方法より項目数を 14% 減らし、誤った不合格を 21% 減らしました。LangSmith に組み込まれ、2000 を超える処理で使われたと報告されています。

採点項目（ルーブリック）の自動生成は 2026 年に研究が急増しました（サーベイ）。ただし、ルーブリックの仕組みを整理した Autorubric（COLM 2026）は、ルーブリックを使っても採点役の偏り（位置の偏り、毎回のぶれ、基準の混同など）は消えないこと、どの環境でも効く対策の組み合わせは無いことを示しています。採点の偏りについては 以前の記事 でも扱いました。

6. 段階 4：会話や、道具を使う作業を模擬する

問い合わせ対応のように何往復も続く会話は、1 問 1 答の問題集では測れません。そこで、利用者役の AI に会話させます。

ツールでできること

• DeepEval: まず「状況と、期待される結末」を生成し（generate_conversational_goldens_from_*）、次に ConversationSimulator が自分のアプリと会話させて、実際のやりとりを作ります。
• Opik（オープンソース）: 利用者役の人物像を文章で書き、自分のアプリと会話させます。

from opik.simulation import SimulatedUser, run_simulation

user_simulator = SimulatedUser(
    persona="注文した商品が届かず、返金してほしいと怒っている客", model="openai/gpt-4.1")
simulation = run_simulation(app=run_agent, user_simulator=user_simulator, max_turns=5)

（run_agent は、利用者の発言を受け取って返事を返す自分のアプリの関数です）

• IntellAgent（オープンソース）: システムプロンプトに書かれた方針を「方針のつながり（グラフ）」に分解し、方針の組み合わせを試す会話の状況を自動で作ります。データベースの例と道具の定義を渡せば、それを使う状況も作ります。会話のあとで、試したかった方針を守れたかを判定します。ただ、リリースは最初の 1 回だけで、開発は落ち着いています。
• tau2-bench: 道具を使うエージェントの評価の定番です。課題には利用者役への指示、データベースの初期状態、期待される道具の呼び出し、最終的なデータベースの状態の確認が含まれます。ただし、自分の業務の課題を自動で作る道具はなく、課題は手で書きます。

論文：模擬の利用者は、本物より素直

Synthetic Users, Real Differences（2026 年 5 月）は、実際の利用者と AI のチャット 1000 件と模擬の会話を比べました。模擬の利用者は、本物の利用者が持ち込む話の行き違いや手間を再現できず、評価が楽観的になること、その程度は業務の分野によって違うことを報告しています。

一方で、使い道を絞れば役に立つという報告もあります。ブラジルの銀行 Nubank の事例（Screen Before You Serve、2026 年 9 月）では、模擬の顧客と模擬の道具を使って、本番に出す前に候補のエージェントを選別しました。リリースした 4 つの版で、模擬での版ごとの評価は本番での評価と強く相関し、模擬を使った改善は実際の比較実験で顧客満足度を大きく上げました。

合成データでの評価の偏りを調べた Towards Understanding Bias in Synthetic Data for Evaluation（CIKM 2025）も、同じ方向の結論です。合成データでの評価は、点数の絶対値は偏り得るが、システム同士の相対的な比較への影響は比較的小さいとしています。

ここから言えるのは、模擬や合成データは**「どちらの版が良いか」の比較には使えるが、「この版は本番で通用するか」の判定には甘い**ということです。

7. 段階 5：正解を機械で確かめられる課題を作る

採点の悩みがなくなる理想の形は、正解かどうかを機械で確かめられる課題です。これを自動で大量に作る研究が一番進んでいるのが、コードの領域です。

• SWE-smith（NeurIPS 2025）: Python のリポジトリにバグを仕込み、既存のテストが落ちるようになったものだけを課題として残します。落ちるテストが通るように直せば正解、という確かめ方です。自分のリポジトリで使うには、Docker、テストが通る環境を作るスクリプト、LLM の API キーが要ります。手順はコマンドが 7 段ほどで、手軽とは言えませんが、エンジニアなら回せる水準です。
• gskill: 前回の記事 で紹介した、gepa に同梱のスキル学習の仕組みです。SWE-smith の課題でエージェントを走らせ、その結果からスキルを育てます。最適化したスキルを Claude Code の SKILL.md として入れて評価する手順も用意されています。
• TaskCraft: ウェブページや PDF から、道具を使う多段の課題を作ります。コードは公開されていますが、更新は 2025 年 7 月で止まっています。

コード以外の業務でも、この発想は使えます。次の章の法務チェックの例がそれです。

8. 業務ごとの現実的な線引き

法務チェックの「埋め込み」は、SWE-smith がバグを仕込むのと同じ考え方です。正解（どこに問題があるか）を先に決めてから問題を作れば、採点は機械でできます。 自動生成で一番効くのは、この形に持ち込めるかどうかです。

なお、どの業務でも、問題を作る AI が答えを作る場合は、その AI に解けない難しさの問題には正解を付けられません。この「作り手の天井」については 以前の記事 で論文をもとに詳しく扱いました。

9. 普通のエンジニアの 1 週間

以上を踏まえて、EC の問い合わせ対応を例に、エンジニア 1 人で回せる手順をまとめます。

ここまでは、特別な機械学習の知識がなくても、Python と各ツールの文書を読める人なら進められます。逆に、自動化しても残る人の仕事は 3 つです。

1. 何を何割作るかを決める（本番の分布を知っているのは人だけ）
2. 出力を読んで採点基準を直す（基準は出力を見ないと決まらない）
3. 生成した問題と参照回答を抜き取りで確かめる（生成した問題は易しく、参照回答は間違い得る）

まとめ

• 入力を増やすのはコマンド 1 つ、文書からの問題と参照回答も自動で作れます。ここはもう「普通に使える」段階です。
• 採点基準は案まで自動で作れますが、出力を見ながら人が直す工程は省けません。
• 会話の模擬は、版同士の比較には使えますが、本番で通用するかの判定には甘くなります。
• 生成した問題は易しくなりがちなので、本番の記録と人の難問を必ず混ぜます。
• 一番効くのは、正解を先に決めてから問題を作る形（バグの埋め込み、問題条項の埋め込み）に持ち込むことです。そうすれば採点が機械でできます。

参考資料

ツールの公式文書（2026 年 11 月 6 日に確認）

• promptfoo: Datasets、Command line
• DeepEval: Synthesizer、Conversation Simulator
• Ragas: Testset Generation for RAG
• Giskard（giskard-oss）、Giskard v2 の RAGET（旧文書）
• NeMo Data Designer
• Opik: Manage datasets、Evaluate multi-turn agents
• LangSmith: Manage datasets、Improve judge evaluator
• Anthropic: Define success and build evaluations
• IntellAgent、tau2-bench
• SWE-smith、gepa の gskill、TaskCraft

論文

• Filice ほか, Generating Diverse Q&A Benchmarks for RAG Evaluation with DataMorgana
• Gill ほか, What Has Been Lost with Synthetic Evaluation?（EMNLP 2025 Findings）
• Sordo ほか, STELLAR-E: a Synthetic, Tailored, End-to-end LLM Application Rigorous Evaluator
• Li ほか, AutoBencher: Towards Declarative Benchmark Construction（ICLR 2025）
• Shankar ほか, Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences（EvalGen）
• Shankar ほか, SPADE: Synthesizing Data Quality Assertions for Large Language Model Pipelines
• Chen ほか, From Holistic Evaluation to Structured Criteria: Rubrics Across the Evolving LLM Landscape
• Rao ほか, Autorubric: A Unifying Framework for Rubric-Based LLM Evaluation on Non-Verifiable Tasks（COLM 2026）
• Liu ほか, Synthetic Users, Real Differences: an Evaluation Framework for User Simulation in Multi-Turn Conversations
• Alcoba ほか, Screen Before You Serve: Simulation for Production Customer Experience AI Agents at 140M Scale
• Rahmani ほか, Towards Understanding Bias in Synthetic Data for Evaluation（CIKM 2025）
• Levi ほか, IntellAgent: A Multi-Agent Framework for Evaluating Conversational AI Systems
• Yang ほか, SWE-smith: Scaling Data for Software Engineering Agents
• Shi ほか, TaskCraft: Automated Generation of Agentic Tasks
• Gao ほか, p1: Better Prompt Optimization with Fewer Prompts

関連記事

• プロンプトを自動で直すとき、中で何が起きているのか
• AI で評価用テストペアを生成する手法サーベイ
• AI で評価用テストペアを生成する実装ガイド
• AI は答え合わせはできても問題集は作れない — LLM 評価とモデル選択の論文を読む

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。