機械検査・別担当のレビュー・公開承認を分ける——変更した成果へ古い承認を流用しない

確認を減らす前に、何を決めているかを見直す

AIを業務へ組み込むと、確認画面をできるだけ減らしたくなります。毎回人が見ているなら自動化の効果がない、と感じる場面もあるでしょう。しかし確認の数を数えるだけでは、何を人が判断しているのかが分かりません。値がそろったかを見る確認と、相手へ送ってよいかを決める判断では、役割も間違えた際の影響も違います。

例えば取引先へ案内文を送る業務を考えます。宛先が入力されているか、対象の商品が文章と一致するか、今回の相手へ送る理由があるかは、別々の問いです。最初の二つは決まった条件で検査できる部分があります。最後の問いには、取引の経緯や今回の目的という判断材料が必要です。まとめて一つの確認にすると、人は何を見ればよいか迷います。

自動化の設計で重要なのは、確認を残すこと自体ではなく、判断が必要な箇所に情報と権限を集めることです。形式だけを眺める確認が多い一方で、重要な送信や変更が流れ作業になっているなら、確認数が多くても安全とは言えません。人の作業量と、判断が適切に行われるかを分けて評価する必要があります。

案内文の作成から送信までを、下書き、機械検査、内容の受入、送信の判断、結果照合へ分ける設計が考えられます。分類、修正、起票を機械で進め、取り消せない操作は人が行う業務代行の分担も参考になります。各工程へ何を渡すかを定めれば、人に残す確認も具体的になります。候補ができたことを送信の許可へ変えず、今回の相手と目的に合うかを判断できる情報を用意します。

機械で確かめられる条件は、判断から切り離す

人へ渡す前に確かめられることを整理すると、確認の中身が変わります。入力が空でないか、必要な対象がそろっているか、計算した合計が合うか、といった条件は機械で検査できます。これらの確認結果を残せば、人は同じ点を最初から見直すのではなく、今回判断しなければならない点へ集中できます。

ただし、値があることと、その値が業務に使えることは別です。申請理由の欄に文章が入っていても、今回の申請を認める根拠になるとは限りません。宛先の形式が正しくても、意図した相手かは別に確認します。機械の合格を、業務上の判断まで済んだ印として見せると、確認を減らす代わりに責任の範囲が曖昧になります。

確認画面には、機械が確かめた条件と、人へ渡した判断を分けて表示します。案内文なら「商品名の照合は完了」「公開できる資料だけを参照」「送信対象と理由は確認待ち」といった形です。すべてを緑色の成功表示にせず、どこまでの確認なのかを言葉で示す方が、担当者は判断の範囲を把握しやすくなります。

機械検査が増えすぎることにも注意が必要です。目的と関係の薄い条件まで必須にすると、担当者は形式的な値を入れて先へ進もうとすることがあります。次の判断が成立するために必要な条件から選び、実際に何が欠けると困るのかを例で確認します。多く検査したことを、重要なことを検査したことの代わりにしません。

取り消しにくい操作の前に、判断の区切りを置く

下書きを作ることと、外部へ送ることでは、間違えた後にできる対応が違います。下書きなら文章を直せますが、相手に届いた情報を完全に回収できるとは限りません。人の判断をどこへ置くかを考えるときは、操作がどれだけ戻しやすいかを先に調べると、確認の優先順位を決めやすくなります。

記事制作なら、本文の生成、内容の検査、掲載を認める判断を別の仕事にします。文章が生成されたことを、そのまま公開してよい理由にしません。掲載先、参照した資料、説明用の例、未確認の数値を見てから判断できる形にします。公開を保留しても、下書きと検査結果を残せれば、それまでの作業が失われるわけではありません。

業務の更新でも同じです。修正候補を作る工程と、実際の対象を変更する工程を分けます。担当者は、何が変わるか、元へ戻す方法があるか、変更後にどう照合するかを見ます。操作の前に人を置くだけでは十分ではなく、判断に必要な比較情報がなければ、確認画面は実行を促すボタンに過ぎなくなってしまいます。

一方、すべての操作を人の判断待ちにすると、仕事が止まりやすくなります。取り消しやすい下書き作成、限定した読取り、検査済みの定型処理は、許可した範囲で進める方法があります。確認を置く区切りは、操作の影響と、結果を確かめられる条件から決めます。単にAIを使う工程だから毎回止める、という一律の設計にはしません。

確認する人へ、結論と根拠を一緒に渡す

担当者へ候補の結論だけを見せると、正しさを確かめるために元資料を探し直す必要が生じます。これではAIが前処理をしても、人の調査が減らないことがあります。候補値、その値を選んだ理由、参照した情報、判断できなかった項目を一緒に示すことで、確認の仕事を最初からの調査ではなく、根拠の評価へ変えられます。

例えば経費の分類候補を示すなら、「この区分です」だけでなく、取引の内容、利用日、参照した分類条件、条件に合わない部分を示します。判断の結果に自信があるという表示より、どの情報からその結論へ進んだのかが分かる方が役に立ちます。必要な根拠がない候補は、文章を自然に整えても、受け入れられる情報にはなりません。

根拠を大量に並べるだけでも負担は残ります。担当者が今回見たいのは、判断に影響する差分と、例外になった理由です。通常と同じ条件で機械が確認した箇所は短くまとめ、判断が分かれる箇所は元の情報へ戻れるようにします。説明の長さではなく、判断を確かめる順序を支える配置を考えます。

ここで例示する確認情報は、特定の制度に対する実務判断を自動化できると保証するものではありません。適用する条件や権限は業務ごとに定めます。資料を扱う人が、その条件に照らして候補を採用・修正・保留できることが必要です。根拠の表示は人の判断を不要にするためではなく、人が必要なところで判断しやすくするために用います。

例外を優先する画面は、正常な結果も隠さない

通常の処理が多数あり、少数だけ判断が必要な業務では、例外を先に見せる画面が役立ちます。月次の事務なら、情報が不足した対象、条件が合わない対象、前回と大きく変わった対象をまとめます。すべてを同じ深さで確認する方法より、どの対象に注意を向けるべきかを把握しやすくなります。

しかし例外だけを見せると、正常と判断された対象にどんな検査が行われたかが分からなくなることがあります。担当者は、対象全体の数、検査が終わった数、保留の理由の内訳を確かめられる必要があります。画面から項目を減らすことと、必要な情報へ到達できなくすることは別です。要約から詳細へ戻れる経路を残します。

正常な結果にも、少数の見直しを行う方法があります。例外だけを確認していると、誤った分類が通常の処理として通り続ける可能性があるからです。どれを見直すかは、変更された条件、新しい種類の入力、過去の誤りの傾向などから選びます。ここでの選択は設計上の提案であり、一定割合を見れば正確性を保証できるという数値は示しません。

人の修正があった場合は、その対象だけでなく、似た条件の処理を確認するかも決めます。個別の入力の問題なら一件の修正で済むことがありますが、分類の条件が違っていたなら、同じ条件を使った対象へ影響が広がります。例外を集める画面は、少数を速く処理するためだけでなく、原因と影響範囲を見直す入口として設計します。

判断が遅れたときの状態を、先に決める

人の判断を待つ仕事では、待っている間に何が起きるかを決めておきます。入力が変わる、期限が過ぎる、別の担当者が修正する、といった変化があると、最初に作った候補をそのまま使えるとは限りません。待機中の状態を説明できれば、担当者はどの版の情報について判断しているかを把握できます。

例えば公開前の案内文を保留した後で、商品の説明が更新された場合を考えます。以前の文章に対する承認を、更新後の文章へ自動で引き継ぐべきではありません。変わった内容と、前の確認が影響を受ける範囲を示し、必要な箇所を再確認します。承認済みという表示があるだけで、現在の内容を認めたことにはなりません。

期限が近づいた際の扱いも必要です。担当者が判断しないからといって、システムが勝手に取り消せない操作へ進むようにすると、確認を置いた意味が失われます。別の担当へ引き継ぐ、対象を保留する、今回の実行を中止するなど、許可された選択を決めます。誰にどの情報を渡すかまで定めることで、止まった仕事を説明できます。

判断が必要な箇所を減らす検討は、こうした待機の記録から始めると具体的になります。毎回同じ理由で保留されるなら、入力の集め方や条件の説明を改善できる可能性があります。判断の結果が状況で大きく変わるなら、その部分を人に残す方がよいかもしれません。確認回数の少なさだけでなく、保留の原因と判断の価値を見ます。

LangGraphで作業、機械検証、別担当レビュー、受入への遷移を制御し、SQLiteへ待機状態を保存する構成が考えられます。レビュー後にも成果物を再照合し、検査した版と現在の成果を区別します。内容の受入と公開・外部送信の許可は別の条件です。案内文では、受け入れた本文の版と送信対象を承認へ結び付け、変更があれば影響する確認へ戻します。保留中に宛先だけ変わった場合も、本文が合格済みだから送ってよいとはせず、変更後の対象と理由を確かめます。

検査する人と、作った人を分ける意味

成果物を作った人は、作業の意図や難しかった事情を知っています。その知識は修正に役立つ一方で、完成物だけを見た読者の疑問に気づきにくくなることがあります。別の担当による検査では、作り手の期待する結論を先に渡さず、目的と必要な根拠を示して、実際の成果物が条件を満たすかを確認します。

別担当であれば常に独立した検査になるわけではありません。先に「今回は成功です」と伝えたり、不都合な情報を外した資料だけを渡したりすると、判定は誘導されます。評価基準を成果物を見る前に決め、肯定、修正、判断保留を可能にすることが必要です。案内文では分かりやすさと対象の正しさを分け、作成者の期待する結論より、実際の本文と根拠に基づいて判断します。

独立した検査にも対象範囲があります。本文と出典を照合したことは、現在の本番システムを動かして確かめたことと同じではありません。画面を見たことも、音声を聴いたことや利用者へ届いたことの確認にはなりません。検査担当が何を見たか、見ていないことは何かを残し、判定を別の品質保証へ広げないようにします。

指摘が返ったら、書き手や実装者が具体的な箇所を修正し、影響する範囲を確認し直します。別担当の意見を採用するだけでなく、どの根拠と条件に基づく指摘かを見ます。独立性は役職や人数の飾りではありません。成果物の受け入れに必要な疑問を、作成者の事情から切り離して検査できるかが重要です。

残した判断が役に立つかを、運用で確かめる

確認の設計を評価するときは、画面を何回開いたかだけでなく、どんな判断が行われたかを見ます。情報不足を発見した、候補を修正した、操作を保留した、条件の説明を改善した、といった内容が分かれば、その確認が何に役立ったかを考えられます。ただ承認した回数だけでは、必要な判断があったかは分かりません。

まず一つの業務を選び、機械が確かめる条件と人が決める条件を分けて書いてください。次に、通常の入力だけでなく、不足、矛盾、変更、応答が得られない場合を用意します。人へ返す情報を読んで、採用、修正、保留のどれを選ぶべきか分かるかを試します。取り消しにくい操作へ進めることだけを成功条件にしません。

試した結果、人が毎回同じ修正をしているなら、入力や前処理を改善できる余地があります。逆に、目的や相手の状況によって判断が変わるなら、その違いを機械へ無理に吸収させるより、判断材料を見やすくする方が役立つ場合があります。自動化する範囲と、支援する範囲を分けて考えることで、人の時間を必要なところへ使えます。

人の確認を残すことは、自動化を諦めることではありません。決まった条件の検査や候補づくりを機械へ任せ、目的、影響、利用条件を人が判断する構成もあります。どの確認を減らし、どの判断を残すかを、実際に役立った情報と修正の記録から選ぶことが大切です。確認の数ではなく、業務の判断が適切に進むかを確かめてください。