青文字：解説 ・黒文字：テンプレ

前半は、資料に用意する ** 項目と、その項目を書くための解説 ** です。後半に、架空の「問い合わせ対応支援AI」を用いた記載例をまとめています。

評価設計に向けた打ち合わせ資料

前提のすり合わせ

1. 評価の工程

＜解説＞

今回の打ち合わせから、評価設計・業務側との合意・改修・評価・最終報告までの工程を並べます。各工程の時期と、評価担当・開発側・業務側の関わり方を記載します。

日程だけでなく、 ** 誰から、いつレビューが入り、その結果をどこへ反映するのか ** を確認するための項目です。参加者と最終承認者は区別します。

2. 評価担当が担う役割

頂いている依頼内容

＜解説＞

受け取った依頼を、評価担当がどう理解しているかを整理します。

「依頼事項・スコープ・評価の考え方・テストケース・期限」の観点で記載します。依頼された内容と、自分たちからの追加提案を混ぜないようにします。

最終成果物：最終評価レポート

＜解説＞

レポートに書く内容と、満たすべき品質を定めます。

内容は評価結果・原因分析・残存リスク・次の確認事項など。品質は、 ** 誰が、そのレポートを読んで何を判断できる必要があるか ** で記載します。

不合格や判定保留の場合にも、理由と次の行動が分かることを含めます。

中間成果物：評価設計書

＜解説＞

評価ケース・評価項目・正解データ・判定ルールなど、評価前に定めるものを記載します。

品質は「測れない範囲が明示される」「解釈の曖昧性がない」「実際に測れる」の3点で整理します。必要なログや再実行条件も、開発側の設計へ反映する情報として扱います。

参考：評価設計書として定めていく内容

3. 考慮すべき重要事項

＜解説＞

今回の案件の経緯や業務側の懸念から、評価レポートに特に求められることを書きます。

「こういう事情があるため、こういう判断ができるレポートを出せる評価にする必要がある」という関係を示します。確認済みの事情と、自分たちの仮説は区別します。

後のリスク整理とは異なり、ここでは ** 案件全体として、評価設計の前提に置きたい重要事項 ** を共有します。

議論1. リスクの整理

＜解説＞

評価を設計するうえで避けたい失敗を整理します。

各リスクは、「起こりうること・評価設計での対応案・確認したいこと」をセットにします。一般的なリスクを網羅するのではなく、今回の設計や進め方に影響するものを選びます。

A. プロジェクトの今後の工程として一般的に生じうるリスク

＜解説＞

合格基準の未合意、評価に必要なデータやログの不足、レビュー順序の不整合など、進行上のリスクを記載します。

いつ、誰と、何を確認しておく必要があるかにつなげます。

| リスクの記入例 | 評価設計での対応案 | 当日確認したいこと | | --- | --- | --- | | 合格基準の合意なく、正式評価に進んでしまう | 正式評価の結果を見る前に、判定ルールと承認者を確定する | 誰と、いつ、何を合意すれば評価へ進めるか | | 扱えるデータ・ログでは行えない評価設計で進んでしまう | 必要データと再実行条件を設計書に記載し、実現性を確認する | 既存の記録で足りるか。追加取得・ログ追加は可能か |

B. 対象業務の性質から生じうるリスク

＜解説＞

重大な失敗が全体集計に埋もれること、時期や状況によって性能が変わること、対象外の事象が混ざることなどを整理します。

業務上異なる損失を同じ誤りとして扱っていないか、今回のデータが必要な状況を含んでいるかを確認します。

| リスクの記入例 | 評価設計での対応案 | 当日確認したいこと | | --- | --- | --- | | 全体正解率は高くても、重大な問い合わせを見逃している | 重大な見逃しと、不要な人確認を分けて評価する | 重大とする条件は何か。どの事象を特に厳しく扱うか | | 通常期の問い合わせで合格しても、繁忙期や新サービス開始時には使えない | 評価対象期間と、含まれていない業務状況を明示する | 今回のデータは、どのような時期・状況を含むか | | 本来は自動処理対象外の問い合わせが、通常ケースに混ざる | 対象外条件と、その際に期待する処理を区別する | 対象外は除外するだけか、人へ戻ることまで確認するか |

C. 顧客の状況や性質から生じうるリスク

＜解説＞

現場の期待と数値基準のずれ、基準変更の受け取られ方、判断者の不在や変更などを整理します。

相手の状況についての仮説を、確定した事実として書かないことが重要です。開発側から見た実情や、業務側に確認する必要があることを引き出します。

| リスクの記入例 | 評価設計での対応案 | 当日確認したいこと | | --- | --- | --- | | 数値では合格しても、現場から「重要なものを落としている」と判断される | 現場が問題視する具体的な事象を確認し、評価へ対応付ける | 過去に問題になった事例はあるか。誰に聞けば分かるか | | 現行の正解率基準を見直すことが「基準を緩めた」と受け取られる | 現行基準との関係と、変更理由を明示して合意する | 現行基準は何のために、誰が決めたか | | 担当者の変更によって合意内容が引き継がれない | 判断者・合意内容・根拠を文書に残す | 今後の担当変更や、別部門による承認の予定はあるか |

D. システムのスキームや性質から生じうるリスク

＜解説＞

処理が連なることによる原因の混在、入力不備、正解データの性質、過去の状態を再現できないことなどを整理します。

評価方法を工夫すれば分けられるのか、追加の記録や改修が必要なのかを確認します。

| リスクの記入例 | 評価設計での対応案 | 当日確認したいこと | | --- | --- | --- | | 問い合わせ判定と振り分けの、どちらで誤ったか分からない | 中間判定と最終登録結果を分けて確認する | 途中の出力を同じ問い合わせIDで追えるか | | 入力の欠損がモデルの誤判定として集計される | 入力不備の有無を記録し、原因別に集計する | 判定時点の入力を復元できるか | | 過去の担当者判断を、そのまま正解としてよいか分からない | 過去の実績と、今回の業務基準で確認した正解を区別する | 正解付けに使う基準と、判断が割れた場合の扱いは何か | | 再実行時に、当時は使えなかった履歴を参照してしまう | 判定時点で利用できた情報に揃える | 履歴や顧客情報の時点を固定できるか |

その他リスク・備忘

＜解説＞

上記に収まらない例外や制約を記載します。表示の更新時差など、不具合か許容された挙動かを先に決めておく必要があるものも含めます。

議論2. 性能・実用性関連項目への評価設計

業務の定義

＜解説＞

業務全体で達成したいことと、起こしてはいけないことを定め、その中で各機能が担う役割を整理します。

生産性を何で捉えるか、各機能の外れがどの結果に表れるかも記載します。ただし、業務全体の成果と、今回の評価で直接確認できる範囲は区別します。

合格基準・比較対象の定義

＜解説＞

何との比較で、どの範囲まで有効と言えればよいかを揃えます。

現行基準の出所と意味、比較対象、揃える条件、業務側の判断者を確認します。基準を見直す場合は、既存基準では何が判断できないのかを説明し、変更を合意事項として扱います。

“［主要機能名1］”への評価設計

＜解説＞

ここからは、主要機能ごとに同じ構成を繰り返します。前段と後段の機能がある場合は、それぞれの性能を切り分ける評価と、通して動かした場合の評価の関係を示します。

評価設計の概要

＜解説＞

この機能の評価で、何を明らかにしたいかを書きます。測定手順ではなく、評価結果から答えたい問いを置きます。

評価設計の詳細

測り方

＜解説＞

評価単位、採点する出力と時点、固定する条件、比較方法、調整用データと正式評価データの区別、不足・除外の扱いを記載します。

指標

＜解説＞

何を数え、何を分母とし、どの条件でどう判定するかを書きます。しきい値が未定でも、指標の意味と決める必要があることは具体化します。

ケース分類

＜解説＞

合否や利用範囲の判断に使う主軸と、原因分析に使う参考タグを整理します。重要性だけでなく、データで判別できるか、件数があるかを確認します。

リスク

＜解説＞

その機能の評価方法に固有の落とし穴を記載します。

正解のばらつき、母数不足、評価データの偏りなど、結論の読み方を制限するものを扱います。

Appendix

基本的なシステム概要

1. システムのパイプライン

＜解説＞

処理の段階ごとに、入力・処理・中間出力・最終出力・保存される情報を整理します。評価対象の位置と、原因を追える範囲を把握するために用意します。

2. 出力品質のために行われている仕様の全体像

＜解説＞

入力検査、対象外の扱い、人への引き継ぎ、再実行、連携の整合、手動変更など、品質に関係する仕様を整理します。

検査が存在することと、不適切な出力を確実に止めることは区別して記載します。

AIモデル・判定処理の詳細

＜解説＞

モデルが使う入力、前後のルール、出力、更新条件、保存情報を整理します。名称だけでは意味が分からないスコアや状態については、評価に使う前に定義を確認します。

.

.

.

Ⅱ. 記載例

以下は、問い合わせの内容を判定し、担当チームへ振り分ける架空のシステムを対象とした、 ** 打ち合わせ前の資料 ** です。

前提のすり合わせ

1. 評価設計の工程

●：担当・参加を想定　△：必要に応じて協力　―：直接参加は想定しない

補足

問い合わせの重大度や対応要否、担当チームの定義について、業務責任者に加えて、実際の運用を把握している担当者にも確認できるか。

仕様検討会で初めて確認するのか、事前に質問を渡して回答をもらえるのかを確認したい。

2. 評価チームが担う役割

開発側から頂いている依頼内容

最終成果物

最終評価レポート（［提出時期］）

内容

改修後システムの評価結果、外れの原因分析、改修の優先度をまとめる。あわせて、ケースごとの実践テストへの移行判断に必要な根拠、残存リスク、実践テストで確認すべき事項を示す。

品質

業務責任者が、どの種類の問い合わせから、どの条件で実践テストに進めるかを判断できること。

不合格・判定保留にも理由と次の行動が書かれており、開発チームが次に確認・改修する対象を特定できること。原因を特定できない場合は、その理由と追加確認事項を示す。

中間成果物

評価設計書

内容

評価ケース・評価項目・正解データ・判定ルールを一式で定める。開発チームの方式設計書とセットで、仕様検討会において合意する。

品質

参考：評価設計書として定めていく内容

3. 考慮すべき重要事項

業務側が危惧している見逃しを、全体正解率に埋もれさせない必要がある

業務側は、対応すべき問い合わせが処理不要として扱われることを懸念している。ただし、具体的にどの問い合わせを重大とし、どのような条件を許容するかは未確認である。

そのため、全体正解率だけでなく、重大度などの区分ごとに見逃しの状況が分かるレポートを出せる評価にしたい。

また、改修前と比べて何が改善し、何が残っているかを同じ条件で比較できるようにする。

議論1. リスクの整理

以下は、評価設計で考慮したいリスクのたたき台です。対応案の妥当性と、不足している観点を確認したいです。

A. プロジェクトの今後の工程として一般的に生じうるリスク

議事録

［確認できた事実／合意したこと／未解決事項］

B. 対象業務の性質から生じうるリスク

議事録

［確認できた事実／合意したこと／未解決事項］

C. 顧客の状況や性質から生じうるリスク

※以下は仮説として、実情を確認したい事項です。

議事録

［確認できた事実／合意したこと／未解決事項］

D. システムのスキームや性質から生じうるリスク

議事録

［確認できた事実／合意したこと／未解決事項］

その他リスク・備忘

再判定直後は、一覧と詳細で異なる版の判定が表示される可能性がある。許容された更新待ちか、不整合かを判定するため、更新条件と許容時間を確認する。

議事録

［確認できた事実／合意したこと／未解決事項］

議論2. 性能・実用性関連項目への評価設計

業務の定義

業務全体の目的は「対応すべき問い合わせを見逃さず、適切な担当へ回し、必要な対応につなげる」こと

生産性として減らしたいのは、不要な確認と振り直しの工数である。一方、対応が必要な問い合わせが処理不要となったり、どの担当にも届かなくなったりすることは、別の品質として評価する。

実際の返信時間や対応完了率には、人の稼働や運用も影響する。今回はシステムの判定・登録結果を確認し、実際の運用結果は実践テストで確認する想定とする【要確認】。

議事録

［業務目的／各機能の役割／今回測る範囲］

合格基準・比較対象の定義

何との比較で、どの範囲まで十分有効だと言えればよいか

議事録

［現行基準の意味／比較条件／変更案の扱い／判断者］

“問い合わせ判定”への評価設計

評価設計の概要

ケースごとに、対応が必要な問い合わせの見逃しと、不要な問い合わせを人対応へ回す誤りを分けて確認する。

外れた件の原因を調べ、改修前や現行ルールと比べて何が改善したかを明らかにする。

評価設計の詳細

測り方

指標

見逃し0件であっても、それだけで合格とはしない。評価した条件と件数を合わせて判断する。

ケース分類

リスク

“担当チーム振り分け”への評価設計

評価設計の概要

問い合わせ判定が正しい場合に、対応可能なチームへ割り当てられるかを確認する。

あわせて、問い合わせ判定から通して実行した場合の最終結果を確認し、前段の誤りと振り分け自体の誤りを区別する。

評価設計の詳細

測り方

指標

ケース分類

リスク

Appendix

基本的なシステム概要

1. システムのパイプライン

仕様の根拠と、実際の保存有無は［資料・開発側への確認］で補完する。

2. 品質基準のために行われている仕様の全体像