非エンジニアのための評価：AIワークフローが改善しているか悪化しているかを把握する

私たちが何度も目にするパターンがあります。チームが、コンテンツの下書き、カスタマーサポートの分類、セールスメールの生成など、何らかのAIワークフローを構築します。第1週には順調に機能し、チームは喜び、本番に展開します。

3か月後、何かがおかしいと感じ始めます。出力の品質が悪化したように見え、顧客から苦情が入り、営業担当者は使わなくなります。いつ、なぜ変わったのかは誰にも分かりません。

原因はほぼ常に同じです。誰も測定していなかったのです。第1週に機能したワークフローが徐々に劣化したのかもしれません。基盤モデルが変わった、プロンプトがドリフトした、入力の分布が変化した可能性もあります。測定しなければ、ユーザーから苦情が出るまで気付けません。その時点では、すでに信頼を失っています。

解決策は、AI出力の品質を体系的に測定する評価です。評価は通常、エンジニアリング上の課題として扱われますが、AIワークフローを運用するすべてのチームに必要です。そして、その基本はコードなしでも実践できます。

この記事では、評価とは何か、なぜ重要なのか、エンジニアでなくてもあらゆるAIワークフローに評価を設定する方法を解説します。

評価は、報告のためだけの見せかけではありません。有用な評価は、リリース、保留、ロールバック、調査という意思決定につながります。スコアによってチームの行動が変わらないなら、変えられるようになるまで評価を簡素化してください。

評価とは何か、何ではないか

評価とは、自分たちが管理する例に照らして、AIの出力がどの程度優れているかを体系的に測定する方法です。

構成要素：

• データセット。 AIが処理する入力の集合です。
• 期待される動作。 その入力に対してAIに何をしてほしいかを定めます。
• 採点方法。 AIが正しく処理したかをどのように測定するかを定めます。
• 実行／レポート。 データセットを処理し、各出力を採点し、結果を要約します。

目的は、「AIは期待する品質で、望んだことを行っているか」を繰り返し確認し、その答えが変わったときに見つけられるようにすることです。

評価は、次のものではありません。

• 初期構築時に一度だけ行うテスト。
• 何かがおかしいと感じたときの抜き取り確認。
• ユーザーからのフィードバック（有用ですが、事後的で遅く、偏りがあります）。
• 感覚的な判断（「出力は良さそうだ」）。

本物の評価は、定義済みの入力セットに対して、一貫した採点方法で、スケジュールに従って実行します。誰からも苦情がなくても、シグナルを得られます。

「エンジニア向けツール」が大半のチームに適さない理由

「LLM evals」をGoogleで検索すると、Promptfoo、LangSmith、Braintrust、Heliconeなどのツールに関する記事が見つかります。いずれも優れたツールですが、LLM搭載製品を大規模に提供するエンジニア向けに設計されています。

マーケティング、営業、オペレーション、サポートなど、AIワークフローを運用する大半のチームにとって、これらのツールは過剰です。ツール群の使い方を一から学ぶことなく、自分たちのワークフローを測定できる、よりシンプルな方法が必要です。

幸い、スプレッドシートとLLMがあれば実現できます。LangSmithほど高度ではありませんが、大半の品質問題を検出するには十分です。

4つの評価パターン

一般的な評価パターンは4つあります。それぞれ異なる種類のワークフローに適しています。

パターン1：完全一致

正解が1つだけの場合に使います。

ワークフローの例：カスタマーサポートのチケットを8つのカテゴリに分類する。

データセット：正しいカテゴリが付いた50件のチケット。 採点：AIの回答が正しいカテゴリと一致すれば1点、一致しなければ0点。 出力：正解率（%）。

これは、分類、抽出、単純な構造化出力に適しています。

パターン2：参照との比較

比較対象となる既知の優れた回答がある場合に使います。

ワークフローの例：製品説明の下書きを作成する。

データセット：自分たちで書いた「参照用」の説明がある30製品。 採点：正確さ、トーン、完全性などの観点で、AIの説明が参照用の説明にどの程度近いかを評価する。

人間が両方を読んで1～5で採点することも、LLMの審査役（次のパターン）を使うこともできます。参照との比較は、コンテンツワークフローの最も信頼できる基準です。

パターン3：LLM-as-a-Judge

有効な出力が多数あり、その品質を判定できる場合に使います。

ワークフローの例：パーソナライズされたセールスメールを生成する。

データセット：30人分の見込み客プロフィール。 採点：LLMが審査役となり、入力と出力を基に、具体性、プロ意識、長さ、ボイスとの一致などの観点で採点する。

LLM-as-a-Judgeは強力ですが、慎重なプロンプト設計が必要です。一般的なパターン：

セールスメールの品質を評価してください。次の観点で採点します。

1. 具体性（1～5）：ありきたりなお世辞ではなく、見込み客に関する具体的な事実に言及しているか。
2. プロ意識（1～5）：スパムではなく、対等な相手のように聞こえるか。
3. 長さの適切さ（1～5）：簡潔か（40～80語）。
4. ボイスとの一致（1～5）：当社のボイス（直接的で、バズワードを使わない）に合っているか。

各観点について、スコアと1文の理由を示してください。

JSONで出力：{"specificity": {"score": N, "reason": "..."}, ...}

見込み客のプロフィール：[input]
評価するメール：[output]

審査役のLLMを1つ、プロンプトを1つに固定し、一律に適用するため、人間のレビュアーでは実現できない一貫性を得られます。しかし、一度も検証していない審査役は、品質が不明な別の意見にすぎません。最初に一度、適切にキャリブレーションしてください。

1. チームがすでにラベル付けした50件の例を用意します（合格／不合格、または採点尺度）。レビューキューにある実際の事例を再利用し、架空の例は作らないでください。
2. 同じ50件を審査役に評価させ、一致率を数えます。 おおむね85%を超えれば、定型的なスクリーニングには信頼して使い、人間によるサンプル確認を継続します。約70～85%なら、不一致をすべて確認してください。ほぼ常に、審査役が愚かなのではなく、ルーブリックが曖昧であることが原因です。ルーブリックの文言を明確にし、再実行します。約70%未満なら、審査役は人間とは異なるものを測定しています。自動化に使ってはいけません。
3. エラー率だけでなく、エラーの方向を確認します。 悪い出力を合格させる審査役は危険ですが、良い出力を問題ありと判断する審査役は煩わしいだけです。それに応じてしきい値を設定します。
4. 審査モデル、審査プロンプト、ルーブリックのいずれかを変更するたびに、新しい20～30件の例で再調整します。 この3つはどれも、一致率を気付かないうちに変化させます。

これらの範囲は、私たちが推奨する開始時の手順であり、絶対的な法則ではありません。譲れないのは、審査役のスコアを何らかの判定ゲートに使う前に、キャリブレーションを行うことです。

パターン4：プロパティチェック

「良い」の意味を、具体的でテスト可能なプロパティとして表せる場合に使います。

ワークフローの例：ECストアの商品タイトルを生成する。

データセット：50製品。 各出力で確認するプロパティ：

• 長さが30～70文字である。
• ブランド名を含む。
• 製品の主要な属性を少なくとも1つ含む。
• 禁止されているマーケティング用語（「驚異的」「最高」「革新的」）を使っていない。

各プロパティを「はい」または「いいえ」で判定します。スコアは、全出力で合格したプロパティの割合です。

プロパティチェックは、常に守るべき構造上の制約に適しています。短時間で実行でき、特定のドリフトを検出します。

最初の評価を設定する方法

非エンジニアにも実践しやすい設定方法：

ステップ1：ワークフローを選ぶ

ワークフローを1つ選びます。一度にすべてを評価しようとしてはいけません。品質が最も心配なもの、または結果の影響が最も大きいものを選びます。

例：「受信したカスタマーサポートのチケットをトピック別に分類するAI」。

ステップ2：データセットを構築する

代表的な例を20～50件集めたリストを作成します。次を含めてください。

• 簡単なケース（明らかにカテゴリA）。
• 難しいケース（AともBとも考えられる）。
• エッジケース（どのカテゴリにも明確には当てはまらない）。
• よくある表現の違い（同じ意図を異なる言い方で表したもの）。

スプレッドシートまたはGoogleスプレッドシートに記録します。

これが評価セットです。安定した参照基準として使うことが目的なので、頻繁に変更すべきではありません。

ステップ3：採点方法を定義する

各例について、何を正解とするかを決めます。正確に定義してください。

分類の場合：カテゴリとの完全一致。 コンテンツの場合：名前を付けた2～4個の観点を、それぞれ1～5で採点。 抽出の場合：各フィールドが正しいか、誤っているか。

採点用のルーブリックを書き、継続して使います。

ステップ4：データセットに対してワークフローを実行する

データセット内の各例に対してAIワークフローを実行します。出力を新しい列に記録します。

分類なら、GoogleスプレッドシートのGPT連携のような関数を使うか、手作業で貼り付けとコピーを行えます。

より複雑なワークフローでは、入力をPromptfooのようなツールに投入するか、週1回バッチジョブを実行します。

ステップ5：採点する

完全一致の場合：「期待値＝実際の値」なら1、そうでなければ0を入れる「一致」列を追加します。合計すると、正解率が分かります。

LLM-as-a-Judgeの場合：各出力に対して審査用プロンプトを実行し、スコアを記録します。

プロパティチェックの場合：各プロパティを個別のテストとして実行し、集計します。

最小限のスコアカード

最初の評価では、観点を絞る一方、それぞれが具体的な行動につながるようにします。

スコアカードには、責任者とリリースルールを明記する必要があります。「正確性を追跡する」よりも、「正確性が90%未満ならプロダクトオーナーがレビューする」の方が強力です。

ステップ6：要約する

次のような要約表を作ります。

時間の経過とともに、品質の推移が分かります。スコアが下がったら、調査を開始します。

ステップ7：スケジュールを設定する

定期的なスケジュールで評価を実行します。大半のワークフローでは週1回で十分です。プロンプトやモデルを変更した場合は、デプロイ前に実行します。

週30分の習慣です。定期的なカレンダー枠を設定し、省略しないでください。

この記事からリンクされている付属のスコアカードは、この最初の週次実行用に設計されています。

リリースゲートを追加する

評価は、変更の前に置くと最も効果を発揮します。顧客、業務記録、チームの意思決定に関わるAIワークフローには、小規模なリリースゲートを設けてください。

1. ベースライン。 現在の本番ワークフローのスコアを記録します。
2. 候補。 新しいプロンプト、モデル、ツール、ワークフローのステップを、同じ評価セットに対して実行します。
3. 比較。 候補は、安全性と回帰のスコアを維持し、主要な品質スコアを合意済みの許容範囲を超えて低下させないことが必要です。
4. 意思決定。 リリース、保留、修正、ロールバックのいずれかを選び、理由を記録します。
5. リリース後の確認。 リリース後、実際の事例の小規模なサンプルに対して再実行します。

初日から自動化する必要はありません。担当する承認者を明記したスプレッドシートでも、測定していない変更が本番に反映されるのを一貫して防げれば十分です。

スコアが下がったときの対応

評価の目的は、品質の劣化を検出することです。劣化を検出したら、調査します。

シンプルな調査方法：

ステップ1：失敗したケースを特定する。 具体的に何が間違っていたのでしょうか。

ステップ2：パターンを探す。 失敗は類似した入力に集中していますか。それとも異なる種類の入力に分散していますか。

ステップ3：診断する。

• 集中的なパターン → 特定の弱点（プロンプトの問題、知識の不足）である可能性が高い。
• 分散 → 全般的な品質低下（モデルの変更、ドリフト）である可能性が高い。

ステップ4：原因の仮説を立てる。

• 基盤モデルが最近変更されましたか。プロバイダーの変更履歴を確認します。
• プロンプトが最近変更されましたか。元に戻してテストします。
• 入力の分布が変わりましたか。最近の実データを確認します。
• データセットが古くなりましたか。例を更新します。

ステップ5：修正をテストする。 変更は1つだけ加えます。評価を再実行します。スコアは回復しましたか。

この体系的なアプローチは、慌てて推測するより優れています。

時間をかけてデータセットを構築する

最初のデータセットは出発点です。時間をかけて、次の方法で改善します。

実際の失敗例を追加する。 実際の顧客またはユーザーのケースで悪い出力が生じたら、評価セットに追加します。これで回帰テストになり、その特定の問題が再発すれば検出できます。

古いケースを整理する。 ワークフローが進化すると、一部のテストケースは無関係になります。削除してください。

対象範囲を広げる。 評価セットに「account-access」のチケットが20件あり、「billing」が1件しかない場合、評価には偏りがあります。バランスを調整してください。

見つけたエッジケースを追加する。 顧客から寄せられる新しい苦情のパターン、新しい製品機能、新しいカテゴリなどを追加します。

優れた評価データセットは生きています。過去の現実ではなく、現在の現実を反映します。

よくある間違い

評価プログラムを失敗させるパターンをいくつか紹介します。

間違い1：開始前に完璧な評価を構築する。 精巧な採点方法を備えた50件のデータセットは、構築するのが大変に感じられます。シンプルな採点方法を備えた10件のデータセットなら、今日から取り組めます。小さく始めて、改善してください。

間違い2：正常系だけを評価する。 簡単な例ばかりでは、実際の失敗を検出できません。難しいケース、エッジケース、過去に失敗した既知のケースを含めてください。

間違い3：評価セットのドリフト。 ワークフローを変更するたびに評価セットを更新すると、スコアが意味を失います。評価セットの変更はまれにとどめ、ワークフローはより頻繁に変更できます。目的はワークフローを測定することであり、評価を測定することではありません。

間違い4：LLMの審査役を盲信する。 LLMの審査役には偏りがあります。長さや形式など、表面的な特徴を過度に重視します。人間の判断と照らして、審査役を定期的に調整してください。審査役の判断に同意できない場合、審査用プロンプトを改善する必要があります。

間違い5：採点しても行動しない。 評価を毎週実行しても、データに基づいて何も行動しないなら、見せかけにすぎません。目的は問題を検出して修正することです。スコアが下がっても調査を始めないなら、時間を無駄にしています。

間違い6：1つの観点だけを評価する。 「評価では正解率95%です」といっても、回答の品質が悪化している、応答時間が遅くなっている、ハルシネーション率が高くなっている可能性があります。重要な場合は、複数の観点を追跡してください。

役立つツール（ただし必須ではない）

スプレッドシートから先へ進みたい場合、利用しやすい選択肢がいくつかあります。

Promptfoo。 オープンソースで、YAMLを使って設定し、ノートPCまたはCIで実行できます。プロンプトのテストと比較に最適です。

Braintrust。 使いやすいUIを備えた、評価用のホスティング型プラットフォームです。より高価ですが、強力です。

LangSmith。 LangChainのワークフローに特化しています。このエコシステムを使っている場合に適しています。

Helicone。 LLM呼び出しのログ記録と分析を行い、評価機能も備えています。

OpenAI Evals。 オープンソースのフレームワークで、より開発者向けです。

非エンジニア中心の大半のチームには、スプレッドシートとChatGPT／Claudeで十分です。次の段階へ進む場合、Promptfooが最も導入しやすい「本格的なツール」です。

4週間の評価プログラム

ゼロから始めるチーム向けの現実的な計画：

第1週：選択して定義する。

• ワークフローを1つ選ぶ。
• 20件の例を含むデータセットを構築する。
• 採点方法（完全一致、LLMの審査役、プロパティ）を定義する。

第2週：最初のベースライン。

• 評価を実行し、ベースラインのスコアを記録する。
• 明らかな失敗を特定する。
• まだ何も変更せず、観察する。

第3週：改善する。

• 品質が向上すると思う変更を1つ加える。
• 評価を再実行する。
• スコアは上がったか、下がったか、変わらないか。その理由を調査する。

第4週：スケジュールを設定する。

• 週次実行をスケジュールする。
• 評価プロセスを文書化する。
• スコアが何を意味し、何がアクションの契機になるかをチームに説明する。

4週間後には、機能する評価が完成しています。その後は、評価プログラムにワークフローを追加し、データセットを充実させ、採点方法を改善して、対象を広げます。

文化の転換

評価には、技術的な転換以上に、文化的な転換が必要です。「機能しているように見えるから」という理由でAIワークフローをリリースしてきたチームは、測定を受け入れる必要があります。

この転換には、次のことが伴います。

数値の低下を受け入れる。 期待していた変更が、品質を損なうこともあります。評価はその事実を示します。ロールバックを受け入れなければなりません。

キャリブレーションに投資する。 新しい評価の最初の1か月は、データセット、採点方法、プロンプトの調整に時間がかかると想定してください。これは投資です。

「変更前／変更後」の習慣を構築する。 AIワークフローへの重要な変更はすべて、本番に反映する前に評価を通します。やがて、これが当たり前になります。

品質基準を守る。 スコアが下がったら、修正するか元に戻します。期限があるという理由だけで、品質が低下したままリリースしてはいけません。

この文化の転換が、最も難しい部分です。一度定着すれば、ツールの導入は簡単です。

1つのワークフロー、20件の例、週30分

評価の有無が、長期間信頼できるAIワークフローと、気付かないうちに徐々に平凡な品質へ陥るAIワークフローを分けます。

始めるために、エンジニア、機械学習の専門知識、高機能なツールは必要ありません。測定する価値のあるワークフロー、小規模なデータセット、採点方法、週30分が必要です。

今週、ワークフローを1つ選んでください。20件の例を含む評価を構築し、実行し、結果を確認します。翌週にもう一度実行してください。この取り組みがどのような規律を生むかを実感してください。

6か月後、評価を行っているチームのAIワークフローは、実際に改善しています。評価を行っていないチームのワークフローは、6か月前と同じように見えても、実際には悪化しています。