AIが「完了」と言ったあと、業務の成果をどう確かめるか

A&Aの考え方

この記事の読者は、AIによる文書生成や送信の連携を組む担当者です。A&Aが提案する出発点は、完了の意味を作業者の行動ではなく、利用者の状態で書くことです。例えば「月次レポートを生成した」から、「責任者が承認した対象月のレポートを、予定した閲覧先で対象者が開ける」へ具体化します。この一文から、生成、承認、配置、閲覧権限という異なる確認が必要だと分かる設計にします。

A&Aの考え方

試行前に、対象月、対象組織、成果物の版、承認者、受け取り先を固定したテスト用の依頼を用意します。成果物の識別子があれば、生成から確認まで同じ識別子で追います。名前が似たファイルが存在するだけでは合格にせず、内容と版まで照合する方針です。実データを使う必要がない確認は、架空の入力と自社で管理する受け取り先で実施します。

A&Aの考え方

モデルが述べたツール名や処理内容も、そのまま実行証拠にはしません。実際の呼び出し結果、対象、実行時刻を照合します。別環境の成功や前回の結果を今回の完了として扱わないため、対象と版を確認記録に含めます。ログは失敗箇所を探す材料として残しつつ、最終判定は目的地から読み直した内容と承認条件へ結びつけるのが提案です。

A&Aの考え方

月次レポートの例では、まず計算結果と承認用ファイルを照合します。次に承認がその版に対して行われたかを確認し、予定の共有場所へ配置します。最後に、その場所から利用者に近い権限で読み直して、対象月と主要な数値、版が一致するかを確かめます。公開や送信を含む場合は、実行が許可された範囲を守り、確認のために無関係な相手へ連絡しません。

A&Aの考え方

受け取り先を読めない場合は、その制約を結果に残します。「送信要求受理、到達未確認」のように状態を分け、成功率の分母と分子に何を数えたかを明記します。確認できない状態を失敗と同一にする必要はありませんが、到達済みとして数えない設計を勧めます。取得可能な証拠の範囲を、運用開始前に業務責任者とそろえておきます。

A&Aの考え方

レポートに条件や説明を組み込む処理を変えるときは、必要項目の含有、競合条件の優先、変更対象外の保存を別々に試す案です。含有の例は、対象店舗と注記がすべて出力されるか。優先の例は、旧定義が残っていても今月承認された定義で計算するか。保存の例は、新しい説明を追加しても承認済み数値や前月の履歴を書き換えないかです。三つは異なる壊れ方を見つけるために置きます。

A&Aの考え方

期待値は生成処理の出力をそのまま写して作らず、業務責任者が決めた小さな例から独立して置きます。わざと店舗を欠かした入力、古い定義と新しい定義が共存する入力、変更してはいけない履歴を含む入力で試します。文章の読みやすさは別の評価にします。数値が正しくても誤解を招く説明なら修正し、説明が自然でも誤った版なら不合格にします。

A&Aの考え方

本設計では、まず単純な状態記録を置きます。生成済み、承認待ち、配置済み、到達確認済みを区別し、途中で確認が止まったら現在の目的地を読んでから再実行します。すでに正しい版が届いていれば追加配布は不要です。違う版なら、誰が承認し直すかを定めたうえで修正します。再試行の上限と、人が対応する条件も決め、成功の文言だけを出すまで繰り返す実装にしません。

A&Aの考え方

利益への接続として見るのは、確認作業そのものの時間だけではなく、誤配布の訂正や二重対応にかかった時間です。試行では再実行を含む一連の作業時間と、未確認で残る案件数を測ります。これは障害をゼロにする保証ではありません。どこまでできたかを証拠で区切り、残作業を正確に引き継ぐことで、運用の負担を判断できるようにする設計です。

A&Aの考え方

確認記録は、対象と版、実行した処理、目的地で読めた内容、まだ確認できない点、次の担当を残す形を勧めます。大量のログを添えるだけで、何を見ればよいか分からない状態にしません。例えば「承認版は配置済み、閲覧権限の確認待ち」と書けば、次の担当者は生成をやり直す必要があるかを判断できます。証拠に機密情報が含まれる場合は、運用担当が必要な範囲で参照できる場所へ保存し、公開の報告には状態だけを示します。保存量を増やすこと自体を目的にせず、誤った完了判定を後で説明できるかを基準にします。確認方法を変えたときも、以前の成功記録が何を意味したかは書き換えずに残します。