AIの自動判断を増やす前に、追加の効果を測る検査を用意する
AIに判断を追加する前に、過去の仕事を使って追加前後を比べられる検査を用意します。
この記事の要点
- 失敗した問い合わせを検査にする
- 同じ問い合わせで追加前後を比べる
- 改善と人の確認負担でAIの追加を決める
全体像図を準備中
目次
失敗した問い合わせを検査にする

A&Aの考え方
ここでいう検査とは、過去の仕事をAIに渡し、期待した結果になったかを確かめることです。自動判断を追加する前に、今の処理と追加案を比べられるようにします。比べられない場合は、追加より検査の準備を先にします。
仮想例
たとえば、制作会社で問い合わせの要約をAIに任せているとします。担当者は要約と原文を読み、見積もりに足りない情報を顧客に尋ねています。この「何を聞き返すか」もAIに判断させたい、という仮の例です。
出典に基づく事実
AIの開発元であるAnthropicは、成果が明らかに良くなる場合に限って、仕組みを複雑にするよう勧めています。単純な解決策から始め、必要な場合だけ複雑さを増す方針です。
A&Aの考え方
この記事を書いているAutomate & Augment(A&A)は、この方針を、社内で使うAIへの機能追加の依頼に当てはめます。追加したい機能の一覧より先に、今の仕事で困った例と、どうなれば改善といえるかを並べる方法です。
仮想例
制作会社の例なら、納期の記載がないのに見積もり作成へ進めた問い合わせを選びます。検査で期待する結果は「納期を確認する質問案が出る」です。AIがもっともらしい納期を補った場合は、不合格として扱います。
A&Aの考え方
このとき保存するのは、受付時に届いていた本文と添付資料です。後日聞き出した納期まで入力に混ぜると、受付時には分からなかった情報を使って判定できてしまいます。担当者が、当時見られた資料と後から得た答えを分けます。
出典に基づく事実
Anthropicは評価についての解説で、最初の検査材料を実際の失敗から集める方法を紹介しています。同時に、正しく対応すべき場面と、対応すべきでない場面の両方を検査に含めるよう勧めています。
A&Aの考え方
情報が不足している問い合わせだけを並べると、AIが毎回質問を出すだけでも検査を通ってしまいます。必要な情報が揃い、担当者が聞き返さずに済んだ例も加えます。「追加の質問は不要」という結果も正解にして、余計なやり取りが生じていないかを確かめます。
同じ問い合わせで追加前後を比べる

A&Aの考え方
追加の効果を測るには、同じ問い合わせを今の処理と追加案に渡して比べます。担当者には、どちらも同じ資料で確認してもらいます。難しい案件を追加案だけに渡したり、片方だけ新しい料金表を使ったりすると、差が出た理由が分かりません。
仮想例
制作会社の今の処理では、AIが要約し、人が不足情報を判断します。追加案では、AIが要約に加えて不足情報と質問案を出し、人が原文と照らし合わせます。比較中の質問案は顧客へ送らず、保存した問い合わせを使って社内で確かめます。
A&Aの考え方
比較用の表には、問い合わせごとに一行を設けます。必要だった確認、今の処理の結果、追加案の結果、人が直した内容と時間を残します。必要な確認を拾えたかだけでなく、すでに書かれた情報を聞き直す質問が出ていないかも見ます。
仮想例
たとえば、添付資料に納期があり、本文には「添付の条件で」とだけ書かれた問い合わせです。追加案が添付を読めず、納期を尋ね直すなら改善とはいえません。AIが読む資料の範囲を確かめる材料になります。これは検査を考えるための仮想例です。
出典に基づく事実
AIの出力は、同じ課題でも実行ごとに変わるとAnthropicは説明しています。一度通った課題が次の実行で失敗することもあるため、複数回試して結果を確かめる方法を示しています。
A&Aの考え方
A&Aは、試した回数と成功した回数をセットで残すことを勧めます。都合のよい結果だけを選ばず、見逃しと余計な質問も記録します。必要な回数は仕事への影響と結果のばらつきで変わり、少数の検査を通ったことを本番の保証にはしません。
A&Aの考え方
判断基準は担当者が先に書きます。納期が不要な相談もあるなら、その条件を検査に入れます。担当者同士で正解が割れる問い合わせは、AIの性能を採点する前に扱いを決めます。正解が曖昧なままでは、処理を追加すべきかも決まりません。
A&Aの考え方
人の確認時間は、どちらの案も、原文を読み始めてから質問案を確定するまでを測ります。AIの生成時間や利用料は別に残します。モデルや資料も同時に変えた場合は、その変更を記録します。その場合、改善した分を判断処理の追加だけの効果とは扱いません。
| 見る項目 | 今の処理 | 判断を追加した案 |
|---|---|---|
| 必要な確認 | 今の処理で確認後に残った見逃し | 追加案で確認後に残った見逃し |
| 余計な質問 | 確認時に除いた質問と、確定後に残った不要な質問 | AI案から除いた質問と、確定後に残った不要な質問 |
| 人の負担 | 原文の確認から質問確定までの時間 | 原文の確認から質問確定までの時間(AI案の修正を含む) |
| 維持する費用 | 今の利用料と保守 | 追加の利用料と検査の作成・更新費 |
改善と人の確認負担で追加を決める

A&Aの考え方
追加するかは、必要な確認を拾えた件数、新たに生じた誤り、人の確認負担を並べて決めます。検査に使った例で改善していても、読む資料や直す箇所が増えすぎれば、現場で続けられるかを検討する必要があります。
仮想例
制作会社の例なら、納期の見逃しが減り、不要な質問も増えず、確認時間が短くなった結果は、追加を進める材料になります。一方、質問案を毎回書き直すなら、追加を見送り、今の要約だけを使い続ける選択もあります。効果を測った実例ではありません。
A&Aの考え方
追加を見送る場合にも、検査は残せます。「添付資料を読めない問い合わせがある」「納期を聞く条件が決まっていない」など、追加前に直す仕事が具体的になります。実装を頼む相手には、機能の追加と、その前提となる問題を直す作業を分けて伝えます。
A&Aの考え方
A&Aの提案では、社員や外注先に頼むとき、最初に検査を作る費用と、業務が変わるたびに更新する費用を分けます。問い合わせの条件が変わった際に、誰が正解を直すかも決めます。空いた時間は使える余力であり、そのまま利益が増えるわけではありません。
A&Aの考え方
追加を採用しても、顧客へ送る権限は別に決めます。この例では送信前の確認を人に残します。検査では拾えなかった失敗を本番の記録から検査に追加し、従来の処理へ戻す条件と担当も決めます。比較に合格したことだけで、自動送信まで認める形にはしません。
A&Aの考え方
実行を上限で止める設定と、経営者が追加を見送る判断は別です。前者はAIを動かす範囲を定めるもので、後者は費用と効果による選択です。出典の設計方針は参考になりますが、自社で追加が割に合うかは、自社の比較結果と保守負担を使って判断します。
検査を先に用意すると追加の理由を説明できる
A&Aの考え方
過去に失敗した問い合わせと、問題なく処理できた例を検査にします。
A&Aの考え方
同じ資料で追加前後を比べ、見逃しと余計な質問、人の修正時間を残します。
A&Aの考え方
改善と人の確認負担、検査の保守まで含めて、追加するか今の処理を続けるかを決めます。
過去に失敗した問い合わせと、問題なく処理できた例を検査にします。 同じ資料で追加前後を比べ、見逃しと余計な質問、人の修正時間を残します。 改善と人の確認負担、検査の保守まで含めて、追加するか今の処理を続けるかを決めます。
よくある質問
検査は何件あれば十分ですか?
一律の件数では決まりません。Anthropicが示す20〜50件は、初期の評価を始める目安です。稼働中の業務で十分だという基準ではありません。少数の失敗例から準備を始め、通常例や例外を加え、仕事への影響に応じて検査の範囲を広げます。
専用の評価ツールが必要ですか?
最初の比較は表計算でも整理できます。入力資料、期待する結果、両案の出力、人の修正内容を対応させることが先です。件数や更新頻度が増え、手で比較する負担が大きくなったときに、自動で検査を回す仕組みを検討します。
検査を作る前に試すこともできますか?
取り消せる社内の下書きで、人が確認する形なら、試してみることも選択肢です。ただし、試した結果を本番採用の根拠にするには、今の処理との違いを記録する必要があります。単発の感想だけなら、追加の効果はまだ未確認として扱います。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Building effective agents
Anthropic · 2024-12-19
確認日 2026-10-31 - Demystifying evals for AI agents
Anthropic · 2026-01-09
確認日 2026-10-31