AIへの評価コメントを改善に使う｜不満と誤りを分ける分類

AIへのフィードバック分類では、「良かった／悪かった」の二択をやめ、根拠違い・形式違い・期待用途違いのどこに問題があるかを分けます。三つを混ぜなければ、参照情報を直すのか、指示や出力検証を直すのか、そもそもの受入条件を見直すのかを判断できます。

ただし、コメントの語調だけでラベルを決めてはいけません。「使えない」という一言でも、根拠が誤っている場合、指定形式を外している場合、仕様どおりでも業務に合わない場合があります。分類を実行できる条件は、対象出力と照合対象を一緒に残し、判定から改善先までを台帳でつなぐことです。

AIフィードバックの分類は、三つの照合対象で決める

同じ回答に複数の不満が書かれていても、判定軸は分けられます。コメントの表現より、「回答を何と照合した結果なのか」を見ます。以下は、出典の一般原則を基にした実務上の提案です。原典が定める分類や義務ではありません。

この表の役割は、最初の調査先を選ぶことです。原因の確定には追加調査が要ります。たとえば形式違いに見える回答でも、参照文書から必要項目を取得できていなければ根拠側の調査が必要です。一次ラベルを付けた後、照合結果によって付け替えられる設計にします。

三つを分ける根拠は、公式資料でも評価観点が別々に扱われていることにあります。2026年9月21日時点で、Google Cloudのモデルベース評価用メトリクスのテンプレートは、groundednessを回答内容が与えられた文脈に帰属できるかという観点、instruction followingを指示の要件を満たすかという観点として分けています。要約品質でも、簡潔さ、流暢さ、参照回答との整合は別項目です。

一方、期待用途違いは同資料の所定ラベルではありません。同資料が、既存の評価条件の不足を特定し、条件や入力フィールド、評価基準を具体的なデータと評価条件に合わせて調整する手順を示していることを根拠に、業務側の不足を切り分けるために追加する運用ラベルです。

「使えない」を判定可能な記録に変える

現場コメントをそのまま件数集計しても、修正担当は動けません。対象となった出力も、期待していた用途も分からないからです。反対に、最初から詳細な原因分析を利用者へ求めれば、利用者の推測が分類へ入り込みます。利用者には観察した差分を残してもらい、実装側が照合してラベルを確定する役割分担が適しています。

改善台帳には、少なくとも次の情報をひとまとまりで残します。

• 対象出力：どの入力に対する、どの出力か
• 現場コメント：利用者が観察した問題を原文のまま保持
• 照合対象：参照情報、明示要件、業務上の受入条件のどれか
• 一次ラベル：根拠違い、形式違い、期待用途違い
• 影響・重大度：どの利用場面へ、どのような影響があるかという評価
• 対応：調査先、担当、判断、次の処置
• 修正履歴：変更理由と、テスト・配備の方法

この項目構成の目的は、コメントを調査と変更へ接続することです。満足度の集計だけで終わらせません。2026年9月21日時点で、NISTのAI RMF Playbook「Manage」は、運用後監視に利用者などからの入力を取得・評価する仕組みを含め、定期的なフィードバック、報告された問題への対応と記録を提案しています。さらにManage 4.3では、報告日、報告数、影響・重大度の評価、対応を含むデータベースと、変更理由およびテスト・配備方法を含む変更記録の維持を提案しています。

これは、すべてのコメントをインシデントとして扱う義務を意味しません。現場の不満を受け取る欄と、組織が影響を評価して対応を決める欄を分けることで、コメントの強い語調を重大度と取り違えずに済みます。

ラベル付け例：同じ出力をどこへ戻すか

例として、社内文書を参照して回答し、決められた形式で業務担当者へ提示するAIを考えます。架空の成果や数値を置く必要はありません。入力、参照文書、明示要件、利用目的という四つの記録があれば、条件付きで判定できます。

根拠違いにする条件

回答中の説明が参照文書に見当たらない、または参照文書と食い違うなら、根拠違いを一次ラベルにします。最初の確認対象には、回答文に加えて、検索された参照情報と回答までに通ったコンポーネントを含めます。

Google Cloudの生成AIアプリケーションのデプロイと運用ガイドは、2026年9月21日時点の確認で、継続評価に本番出力と利用者の直接評価を取り込み、確立したground truthとの比較を併用する考え方を説明しています。また、事実上不正確な出力の原因箇所を調べるため、実行された各コンポーネントの系譜をログに残し、入力、依存する成果物、パラメータを対応付ける必要があるとしています。

改善先を指示文に固定すると、原因を見誤ります。参照文書自体が古いのか、必要な文書を検索できなかったのか、取得後の処理で情報が欠けたのかをログから切り分けます。根拠違いというラベルは調査の入口であり、原因確定にはログの確認が必要です。

形式違いにする条件

参照情報との整合は確認できたものの、指定した項目が欠ける、指定した形式で返らない、求めた文体や長さの条件を外すなら形式違いです。改善先は、指示文の曖昧さと出力検証の不足から点検します。

ここで業務担当者の好みと明示要件を混ぜないようにします。「もっと読みやすく」という感想からは、違反した形式要件を特定できません。必要な見出し、含める項目、出力形式など、実装前に合意した条件へ照合できる場合に形式違いとします。条件が未定義なら、期待用途違いの候補として受入条件の定義へ戻します。

期待用途違いにする条件

根拠は合っており、指示された形式も満たしている。それでも後続業務の判断に必要な情報が足りないなら、期待用途違いです。実装側はこのラベルを、AIの正誤判定ではなく、実装時の要件と現場の利用目的のずれを見つけるために使います。

たとえば、要約が参照文書に忠実で、指定項目も揃っているのに、担当者が次の処理を選ぶための観点が受入条件に入っていない場合が該当します。プロンプトの言い換えに着手する前に、「誰が、どの場面で、何を判断する出力か」「判断に必要な情報は何か」を定義し直します。既存の評価基準では不足する条件を特定し、入力フィールドや基準を具体的な用途に合わせるという公式資料の一般原則を、現場運用へ移した考え方です。

迷うコメントは優先順位を決めてから複数ラベルにする

一つの出力が、根拠も誤り、形式も外すことはあります。その場合に一つへ無理に丸めると、片方の改善が台帳から消えます。主ラベルは利用上の影響を生んだ最初の差分に置き、副ラベルで別の差分を残す運用が考えられます。この主・副ラベルの扱いは、三分類を改善先へ接続するための記事独自の提案です。

判定が割れたときは、次の順に確認します。

1. 参照情報と回答内容は整合しているか
2. 合意済みの明示要件を満たしているか
3. その二つを満たした上で、業務上の受入条件に適合するか

この順序なら、根拠が誤っているのに「現場で使えないから期待用途違い」とだけ処理する事態を避けられます。三つ目で初めて不足が見つかった案件は、要件定義へ戻します。

AI導入全体の論点を整理する段階なら、AI導入の進め方と実装ポイントで課題定義から運用までの位置づけを確認できます。検証中の評価を本番運用の監視へ引き継ぐ設計は、AI PoCから本番運用へ進むための実践ガイドもあわせて参照してください。

運用開始には、ラベルごとの戻し先が要る

ラベル名だけ決めても、フィードバックは改善課題になりません。運用開始前に、各ラベルの照合対象が保存されること、一次判定を見直せること、改善先の担当領域が決まっていること、変更理由と検証方法を記録できることを確認します。

根拠違いは参照情報・検索・処理の系譜へ、形式違いは指示文・出力検証へ、期待用途違いは利用目的・受入条件へ戻す。この条件分岐が台帳上で追えるなら、「使えない」という現場コメントを、次に調べるべき改善課題へ変換できます。逆に戻し先が決まらないラベルは増やさず、照合対象か受入条件の不足として定義を見直すべきです。

自社の業務では何を参照情報とし、どこまでを明示要件にし、誰のどの判断を期待用途とするか。その境界から実装条件を整理したい場合は、FDE型支援の無料相談・AI活用診断で、課題定義から実装、定着までの進め方をご相談ください。

FDE・AI実装ガイドへ戻る