問い合わせ分類が毎日動いていても、担当者が分類を直してから利用していれば、その負担は完了件数へ現れません。1つの問い合わせに何回処理したか、確認で直したか、担当者へ戻したかを記録します。

処理できた状態の定義もそろえます。分類候補を作っただけなのか、担当者が確認済みなのかで意味が違います。社内で決めた終点を記録表へ書き、AIの処理終了を業務の完了と混同しないようにします。

導入時に扱わないとした問い合わせが増えていないかも見ます。新しい相談種類や資料の形式が入った場合、従来の試験条件から外れるかもしれません。対象外の件数と理由を残し、運用範囲を広げる判断とは分けます。

この章の根拠：出典1

仕組みが止まったという報告だけでは、問い合わせの取得、分類、結果の表示のどこで失敗したか分かりません。可能な範囲で工程を分け、問い合わせ番号、時刻、失敗した工程、次に行った対応を記録します。

再実行する場合も、結果が重複していないかを確認します。同じ依頼を繰り返すと、件数が増えたり、利用料が積み上がったりすることがあります。技術担当は自動再試行の条件を把握し、業務担当は人が引き取る条件を確認します。

ログへ顧客情報や秘密をそのまま残す必要があるとは限りません。調査に必要な番号や状態を使い、記録の閲覧範囲と保存方法を会社で確認します。詳細な内容が必要な場合は、許可された原資料へ戻る手順にします。

この章の根拠：出典1

月の費用が増えても、問い合わせ件数が増えたなら1件あたりの負担は変わっていない場合があります。対象件数と利用額を並べ、再実行が増えたかを確認します。料金体系と請求条件は、使うサービスの実際の資料で確認します。

長い資料を扱った月や、処理を何段階も繰り返す設定へ変えた月は、以前と同じ条件ではありません。変更日と対象を記録し、増加の理由を調べます。本文では特定製品の単価や標準予算を示さず、自社の運用記録で判断する形にします。

上限に近づいた時に誰へ知らせるかを決めます。費用の通知だけでなく、必要な業務を従来手順へ戻す方法を確認します。経営者は、単価を下げる設定変更によって品質が変わらないかも評価担当へ確かめてもらいます。

この章の根拠：出典1

導入時から人が確認する条件を決めているなら、その介入は通常の運用です。一方、本来分類できる依頼で担当者が一からやり直した場合は、改善の手掛かりになります。介入件数を一律に悪いものと扱うと、必要な確認を減らす方向へ働きます。

理由は「曖昧な問い合わせ」「資料不足」「誤分類」「仕組み停止」など、業務で意味のある少数の分類にします。担当者が書きやすい欄へして、詳細が必要な時だけ番号から原資料へ戻ります。記録負担が大きいなら項目を絞ります。

介入が多い種類を見つけたら、対象範囲と説明資料を確かめます。想定していない相談が増えているなら、人へ戻す方法を保ちながら追加試験を行います。介入をゼロにすることより、誰がどの条件で引き取るかが分かることを重視します。

この章の根拠：出典1

未処理の依頼が残る、対象外の資料を使った疑いがあるなど、会社が決めた重要な条件に触れる問題は、週次報告まで待たず責任者へ連絡します。どの種類を急いで知らせるかは、業務の影響から事前に決めます。

週次では、同じ工程の失敗が続く、確認時間が増える、費用が変わるといった傾向を見ます。単発の失敗も原因が分からないものは残します。処理件数だけで問題を薄めず、重要な項目の件数と具体例を確認します。

対応を決めたら、担当、期限、再確認する材料を記録します。設定を変えた場合は新旧の試験質問を確認し、資料や業務範囲を変えた場合は現場への説明も行います。監視は表を作るだけで終わらず、問題を受け取る人へ結び付けます。

この章の根拠：出典1出典2

始める時は、1つの仕組みに少数の欄を設けます。記録できない項目を大量に用意するより、担当者が同じ意味で残せる状態を作ります。問い合わせ番号と工程があれば、詳細を調べる時の入口になります。

経営者は、何件処理したかと同時に、どの仕事が人へ戻り、何がまだ未処理かを確認します。利用額の増減も、仕事量と変更条件と合わせて見ます。これにより、監視の数字が運用範囲の判断へつながります。

見直した内容は、運用担当へ短く伝えて記録表へ反映します。導入時の条件と現在の条件が違う場合は、対象範囲を改めて確認します。AIエージェントを任せたままにせず、会社が調べて直せる運用として扱います。

この章の根拠：出典1