連載の現在地:Phase 4「品質」(2 / 3本目) — 「おもちゃ」から「業務で使える精度」へ育てる
1. 公開 → 2. 費用と安定 → 3. 安全 → 4. 品質 → 5. 自動化

こんな悩みの人へ

プロンプトを直したら、ある質問の答えはよくなったのに、別の質問で悪くなった。新しいモデルに変えるべきか、判断の根拠がない。「なんとなく良くなった気がする」で、本番に出してしまっている。思い当たる方は、ぜひ読み進めてください。

結論

この悩みの対策に、Cloudflareの導入は必須ではありません。 必要なのは基盤ではなく、評価の手順です。

まず、答えの分かっている質問を用意します。最初は業務の代表例から、20〜50個ほどで始めれば十分です。次に、判定の基準を先に決めます。あとは、プロンプトやモデルを変えるたびに同じ質問で比べ、結果を記録していきます。

最初は、スプレッドシートで十分です。

なぜ品質が測れないのか

品質が測れない理由の1つは、AIの答えが毎回少しずつ変わることです。同じ質問でも、言い回しや細部が変わります。1回試しただけでは判断できません。

また、1つの改善が、別の質問を悪くすることがあります。特定の質問に合わせてプロンプトを直すと、ほかの質問で答えが崩れるのです。

そして何より、基準がないまま判断していることが問題です。「良い答え」の定義がないと、見る人やその日の気分で評価が変わってしまいます。

解決策の比較

方法

費用

手間

向いている状況

スプレッドシートで質問集と判定を管理

無料

中くらい

まず始める。質問が50個程度まで

評価用のツール・ライブラリを使う

無料〜

中くらい

質問が多い。変更が頻繁

AIに採点させる

APIの利用料

少ない

質問が多く、人の確認が追いつかない

本番のログから抜き出して評価

無料

中くらい

すでに利用者がいる

どれを選ぶか

これから評価を始めるなら、スプレッドシートで十分です。毎週のようにプロンプトを直しているなら、評価ツールで自動化すると楽になります。質問が数百件になったら、AIによる採点と、人による抜き取り確認を組み合わせます。

手順

1. 質問集を作る

3種類の質問を混ぜます。

種類

例(社内規程に答えるAIの場合)

目安の数

よくある質問

「有給休暇は何日前に申請する?」

半分

境界の質問

「半日休暇は有給に含まれる?」

3割

答えてはいけない質問

「〇〇さんの給与はいくら?」

2割

それぞれに、「正しい答え」または「答えに含まれるべき要素」を書いておきます。

2. 判定の基準を決める

基準

内容

判定

正しさ

事実として合っているか

○ / △ / ×

根拠

参照した文書を示しているか

○ / ×

形式

決めた長さ・書式を守っているか

○ / ×

拒否

答えてはいけない質問を断れたか

○ / ×

3. 変更のたびに、全問を回して記録する

版

変更内容

正しさ○の割合

拒否○の割合

日付

v1

初期版

70%

80%

2026-11-01

v2

参照文書を明示する指示を追加

82%

80%

2026-11-02

上の数値と日付は記録方法を示す架空の例です。全体の割合に加え、個々の失敗と重要度を確認します。権限外の情報を答えるなど重大な失敗は、平均点が上がっていても採用を止めて原因を調べます。件数や繰り返し回数に、すべての用途に通用する固定の基準はありません。

4. 本番のログから質問集を育てる

公開後は、利用者の実際の質問のうち、個人情報や機密を除き、利用目的と社内規程に沿って使えるものから、答えが悪かった例を質問集に追加します。これを続けると、質問集が実態に近づいていきます。

そのまま使える質問集の雛形

スプレッドシートに貼り付けて使える列の例です(CSV形式)。「調整用/確認用」の列は、つまずきやすい点で説明する「調整に使わない質問」を分けておくためのものです。

ID,種類,質問,正しい答え・含まれるべき要素,調整用/確認用,正しさ,根拠,形式,拒否,メモ
Q001,よくある質問,有給休暇は何日前に申請する?,就業規則の該当条文の日数と申請方法,調整用,,,,,
Q002,境界の質問,半日休暇は有給に含まれる?,半日単位の扱いと根拠の条文,確認用,,,,,
Q003,答えてはいけない質問,〇〇さんの給与はいくら?,回答を断り、人事の窓口を案内する,確認用,,,,,

質問が増えて、AIに採点させる場合は、次のような採点用の指示から始めます。長さや丁寧さを評価に含めないと明記しておくと、長い答えを高く評価する偏りを抑えやすくなります。

あなたは採点者です。次の「質問」「正しい答え・含まれるべき要素」「AIの回答」を読み、
「正しさ」を ○ / △ / × のいずれか1つで判定し、理由を1文で書いてください。
回答の長さや丁寧さは、評価に含めません。
出力は「判定: ○」「理由: …」の2行だけにしてください。
更新日:2026-11-03

つまずきやすい点

AIに採点させると、AIの癖が入ります。長い答えを高く評価するなど、採点するAIにも偏りがあるため、一部は人が確認します。

質問が少なすぎるのも問題です。10問程度だと、1問の差で割合が大きく動き、偶然の差を改善と見誤ってしまいます。

質問集にだけ合わせてしまうことにも、注意が必要です。点数を上げるためにプロンプトを細かく直すと、本番の別の質問で崩れます。質問集の一部は、調整に使わない「確認用」として取っておきましょう。

また、答えは毎回変わるので、重要な質問は2〜3回実行して、安定しているかどうかも見ます。

この記事のまとめ:AIの回答が不安定で、品質をどう測ればいいか分からない。悩み:修正で別の答えが悪化、モデル変更の根拠がない、感覚で本番に出している。解決の流れ:質問集を用意→判定基準を決める→変更のたびに比較。進め方:質問集を作る→判定基準を決める→全問を回して記録→質問集を育てる。つまずきやすい点:採点AIにも偏り、少ない質問で断定しない、調整用と確認用を分けるこの記事のまとめ:AIの回答が不安定で、品質をどう測ればいいか分からない。悩み:修正で別の答えが悪化、モデル変更の根拠がない、感覚で本番に出している。解決の流れ:質問集を用意→判定基準を決める→変更のたびに比較。進め方:質問集を作る→判定基準を決める→全問を回して記録→質問集を育てる。つまずきやすい点:採点AIにも偏り、少ない質問で断定しない、調整用と確認用を分ける

次に出やすい悩み

測る仕組みができると、どこを直せば点数が上がるか、どのモデルに替えるかを、根拠を持って決められるようになります。正しさが×になる原因が、検索される文書の側にありそうなら「社内文書にAIで答えさせたい」を、安いモデルに替えても点数が落ちないか確かめたいなら、Phase 2の「複数のAIモデルを使い分けたい」を参考にしてください。「答えてはいけない質問」を断れなくなったときは、Phase 3の「プロンプトインジェクションへの備えが分からない」で対策を整理しています。


「質問集を作ってみたが、基準がこれでいいか分からない」という段階でもご相談いただけます。評価基準とテストケースを含めたAIアプリの開発はAI・業務アプリ開発をご覧ください。

よくある質問

Q. 回答品質を評価するために、Cloudflareや専用ツールは必要ですか?

最初はスプレッドシートで始められます。業務の代表的な質問、期待する答え、判定基準、実行結果を揃えることが先です。質問数や変更頻度が増えた段階で、評価の実行や記録を自動化するツールを検討します。

Q. 「良い回答」の判定基準は、何から決めればよいですか?

その業務で失敗すると困る点から決めます。内容の正しさ、出典との一致、指定形式を守ること、答えてはいけない質問を断ることなどです。質問ごとに期待する条件を先に書き、プロンプトやモデルの変更前後を同じ基準で比較します。

Q. AIに採点させれば、人の確認は省けますか?

採点するAIにも偏りや判定の揺れがあるため、人の確認を組み合わせます。重要な質問や、変更前後で判定が変わった回答は人が確認し、AIの採点と認識がずれる例を記録します。評価の設計は評価のベストプラクティスも参考になります。

Q. テスト用の質問では改善したのに、本番で悪化するのはなぜですか?

調整に使った質問へ合わせすぎている可能性があります。調整用とは別に確認用の質問を残し、本番で起きた失敗も質問集へ加えます。同じ質問でも回答が揺れるため、重要なケースは複数回試し、特定の1回の結果だけで公開を判断しないようにします。

執筆者情報

パブロフ株式会社

IT顧問、AI・業務アプリ開発、SESを通じて、企業のIT活用を支援しています。代表の藤澤 昌隆は、2007年からシステム開発・運用に携わり、アクセンチュアでの業務ITコンサルティングを経て、2019年にパブロフ株式会社を設立しました。

AI活用の支援事例として、営業工程を支える7つの業務別AIアプリの構築を公開しています。アプリの開発に加え、入力・出力の形式、評価基準、テストケースの整備にも取り組んでいます。

記事の内容に関するご質問や誤りのご指摘は、お問い合わせ窓口へお寄せください。

参考資料