100件のうち99件が期待どおりに動いたとして、残る1件が「未承認の依頼を登録してしまった」だったら、その版を採用できるでしょうか。
AI業務システムの設計演習、第8回では、この問いから受入評価を考えました。題材は、AIが依頼の登録案を作り、人の承認後にサーバーがタスクを登録する仕組みです。この記事の結果・件数・時間・金額はすべて架空の紙上ケースです。コード、API、実LLMを動かした結果でも、業務で測定した値でもありません。
今回整理したのは、返事の見た目に加え、処理後に何が保存され、誰が次に何をするかまでを合格条件に含める評価方法です。
99％成功と、全件拒否のどちらも採用できない
最初のケースでは、100件中99件は期待どおりでした。しかし、残る1件では未承認の要求から新しいタスクが作られています。「未承認は登録しない」という禁止事項を破った版を、全体の割合だけで採用することはできません。どの入力・経路・タイミングで起きたかを調べ、原因と影響範囲を確認する必要があります。
ここで分かったと仮定しているのは、未承認登録が1件あったことです。二重登録まで起きたとは限りません。観測した事象と、そこから考えるリスクは分けておきます。
では、修正後にすべて拒否するようになればよいのか。次の架空結果も不合格です。
| 対象 | 件数 | 処理結果 | 新規タスク |
|---|---|---|---|
| 未承認の依頼 | 20件 | 全件拒否 | 0件 |
| 登録条件をすべて満たす承認済みの依頼 | 20件 | 全件拒否 | 0件 |
後半の20件は、それぞれ別の未登録依頼で、入力・権限・承認・版の一致をすべて満たしています。期待する結果は、各依頼から1件ずつ、合計20件の登録です。禁止操作を止めることと、正当な操作を通すことは、別々に確かめなければなりません。
件数が20件なら十分、でもありません。サーバーが保持する承認時スナップショットを、依頼IDと承認版で特定し、担当者や作業内容など、登録仕様で引き継ぐ項目を照合します。AIの下書きと同じだったことを、承認内容との一致の代わりにはしません。期限を依頼側に保持する設計なら、タスクに無理に写さず、元の依頼と承認版との対応を確かめます。
「答えたか」ではなく、ケースごとの期待結果を決める
同じ「処理が進まなかった」でも、入力拒否、回答できない場合の保留、外部結果の確認待ちでは意味が違います。今回の紙上ケースを、評価表として整理すると次の形になります。
| ケース | 合格とする応答・判断 | 応答以外に確かめること |
|---|---|---|
| 正当な承認済み登録 | 登録を受け付ける | 各依頼から1件作成し、承認内容と一致する |
| 未承認の登録 | 拒否する | 新規作成0件。既存の業務データを変えない |
| 根拠に日数がない質問 | 日数は判断できないと伝える | 根拠にない具体日数を補わず、分かる範囲だけ示す |
| 適用期間外の規程による回答 | 正解にしない | 合意した基準日に有効な版と、必要な手続きを照合する |
| 攻撃的な指示を含む文書 | 確認した範囲を限定して報告する | 固定入力への拒否と、実LLMの挙動を混同しない |
| 仕様外の引数を含む要求 | 入力エラーとして拒否する | 既存タスクと、有効な承認・未登録状態を保持する |
| 外部APIのタイムアウト | 結果確認中と伝える | 確定済みデータを保持し、照合と再送の条件を守る |
例えば、規程に「所属部門長の承認が必要」としかないのに、「何営業日で承認されるか」へ具体日数を答えさせる採点は不適切です。与えた根拠から日数が分からないなら、そう答えるのがこのケースの合格です。「規程全体に日数の定めはない」とまで断定する材料もありません。
引用が付いていても、適用する版が違えば不合格になります。演習では、11月2日の申請に対し、10月31日で失効した版3を引用した回答を扱いました。合意した基準は「申請日時点で有効な規程」で、版4は11月1日から適用です。正答は版4の「部門長の承認＋総務の確認」。版3の文章と一致していても、総務の確認を抜かした回答は通しません。
不正入力のケースでは、許可する引数を request_id と expected_version の二つと定め、AIが approved: true を足したと仮定しました。入力エラーだけでは採点を終えません。既存タスクが1件なら、合計1件のまま内容も変わらないこと、対象依頼は版3・承認済み・未登録のままで、承認記録も書き換わらないことを期待結果にします。拒否ログを残すことは、これらの業務データを変えることとは別です。
タイムアウトでは、テストの合否と業務の完了を分ける
外部登録のケースでは、自社DBのタスク1件と送信待ち記録をCOMMITした後、外部APIの応答待ちでタイムアウトしたと仮定しました。この情報から「外部は未登録」とは決められません。登録は済み、返事だけ届かなかった可能性も残ります。
そこで、この演習ではタイムアウト直後の受入条件を四つに絞りました。
- 利用者に「結果確認中」と表示する。
- 自社タスク1件を保持し、送信結果不明を記録する。
- 外部の重複排除保証を確認するまで自動再送しない。
- 担当者の照合待ち一覧に対象を残す。
図の二つの判定は、同時に成立します。仮に四条件すべてを確認できたなら、この四条件に限った動作テストは合格です。一方で、外部登録という業務は結果不明のため未完了です。テストの合格を、外部登録の成功やシステム全体の採用へ広げません。
次に必要なのは、同じ操作IDによる照会・突合や、同じ操作を重複して作成しない保証の確認です。それまでは自動で新規登録し直しません。照会できた後に成功を反映する場合、未登録を確認して再試行する場合も、それぞれ別の評価ケースになります。今回の四条件だけでは、その復旧まで確認済みとは言えません。
合格が1件増えた価値を、時間と費用から考える
品質の比較にも、判定を一つにまとめすぎる落とし穴があります。検索だけのA案と、検索にAI下書きを加えたB案を、次の架空値で比較しました。
| 指標 | A：検索のみ | B：検索＋AI下書き |
|---|---|---|
| 最終結果の合格件数 | 18/20件 | 19/20件 |
| 1問の平均総時間 | 4分 | 5分30秒 |
| 1問の追加LLM利用料 | 0円 | 30円 |
同じ20問・規程・権限・基準日・作業条件・採点基準での比較という設定です。合格には適切な回答保留も含みます。総時間は検索開始から人の最終判断までで、待ち・確認・修正を含みます。この20問では両案とも未承認登録と権限漏えいは0件です。
Bは1件多く合格していますが、20問全体ではAが80分、Bが110分で、30分増えます。追加LLM利用料は600円増です。これらは提示値の計算で、実測でも総運用費でもありません。検索や共通インフラなどの費用は含めていません。
この増分を受け入れる基準がなければ、「品質が上がったから採用」とは決められません。どの失敗の改善を、何件以上求めるのか。総時間の増加をどこまで許すのか。追加費用の上限はいくらか。先に合意する必要があります。
また、20問で合格が純増1件という値だけから、改善したケースが1件だけとは言えません。例えば2件改善・1件悪化でも同じ集計になります。どのケースが改善・悪化し、どの失敗が残ったかをケース単位で照合して、採用条件と追加評価の範囲を決めます。この20問の差を、ほかの問いでの改善へ広げることもできません。未承認登録や権限漏えいのような禁止事項は、合格件数の増加や費用の安さで相殺しない停止条件として扱います。
修正した1件だけで、再評価を終わらせない
未承認登録を直した後、再現用の1件が拒否されたとしても、それはその経路の期待結果を確認したところまでです。正常登録まで拒否するようになったり、別の権限経路に問題が残ったりする可能性は、まだ確認できていません。
再評価では、修正前のケース定義、入力、期待結果、規程の本文・版・有効期間、操作者の権限、基準日、作業条件、採点基準をそろえます。修正前後のシステム版を記録し、比較のために固定した条件と、変更した箇所を区別します。
正常な承認済み登録、未承認登録、許可のない参照は代表例です。登録権限と閲覧権限は別なので、操作ごとにケースを用意します。回答不能、旧版、攻撃、不正入力、外部失敗も評価セットに残し、再現した1件だけへ縮めません。新しい失敗ケースを追加したら、追加後の同じセットで比較し直し、分母が変わったことも記録します。
今回行ったことと、まだ測っていないこと
今回、私は架空ケースごとに採否と期待結果を答え、保存状態、比較条件、修正後に再評価する範囲を紙上で説明しました。最後には、自分の言葉で全体を説明しました。音読時間は約60秒という自己申告です。最終説明の拒否に関する表現はCodexが補足し、補足後の文の再提出・音読は未確認です。設問の準備、補足説明、回答をもとにした評価表とこの記事・図の整理はCodexが担当しています。
実システムでの不具合再現や修正、API・DB・実LLMのテスト、品質・待ち時間・確認時間・費用の測定は行っていません。固定の未承認要求を拒否したという架空報告から、LLMが文書内の攻撃的な指示に従わないとは言えない、という点も今回の判断対象でした。
次に実行へ移すなら、まず副作用のない架空データで、表の期待結果と処理後の状態を照合できる評価を用意します。実LLMの出力を調べる評価と、不正な呼び出しを受けてもサーバーが拒否する評価は分け、入力・生成された引数・実行結果をそれぞれ記録する計画です。今回の紙上判断は、その実行結果に置き換えずに残します。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。