請求書の下書き、取引先への通知文、問い合わせへの返信。AIに任せられる仕事が増えるほど、決まって出てくるのが「出力は人がダブルチェックしてください」という一文です。ただ、月に何十件も出てくるものを全件目で見返すなら、そもそも自動化した意味が薄くなります。かといって見ないわけにもいかない。ここで止まっている会社は多いです。
先に言うと、決めるべきは「見るか見ないか」ではありません。機械が判定できる部分と、人が判断すべき部分の線をどこに引くかです。前者は形式の検査・過去との差分・元データとの内容照合で自動的に止められます。後者は金額・宛先・外部へ出すかどうかで、ここは人の承認を残します。
1分の無料セルフ診断：自社のどの業務から線引きを始めるとよいかが分かります。
結論：チェックは「全部見る」ではなく「機械で止める所」と「人が決める所」に分ける
AIの出力で事故になるのは、たいてい「間違いに気づけなかった」ときです。そして気づけなかった理由は、注意力ではなく見る対象が多すぎたことにあります。全件を同じ密度で見ようとすると、人の注意は薄く広がり、いちばん危ない1件を見落とします。
だから、量が多くて判定基準がはっきりしているものは機械に渡します。金額の桁、宛先のドメイン、必須項目の欠落、先月との差が大きすぎないか。こういう検査は人よりも機械のほうが安定します。人には、基準を言葉にしづらいものだけを残します。
ここが肝
「人が全部見る」は運用が続きません。続くのは「基準を書ける違反は機械が止め、人は止まった分だけを見る」形です。人の仕事は"確認"から"承認"に変わります。
月50件の請求書を出す会社での試算（代表的なケースであり、特定の実在企業ではありません）
全件を1件12分で目視していた状態から、機械検査を通して止まった数件だけを人が見る状態へ移した場合の目安です。ここでは機械検査で止まるのを全体の3割と置いています（月50件なら約15件）。この割合は書類の型がどれだけそろっているかで大きく変わるので、自社の実数で置き換えて考えてください。止まる件数が増えるほど人が見る時間は増え、浮く時間は減ります（同じ条件で6割が止まるなら、浮くのは約4時間）。
向いている会社・向きにくい会社
| 向いている | 向きにくい | |
|---|---|---|
| 書類の型 | 毎回ほぼ同じ様式 | 1件ごとに構成が変わる |
| 判定基準 | 「これはNG」を言葉にできる | 都度の交渉で決まる |
| 件数 | 月10件以上ある | 月に数件で目視が苦にならない |
| 決裁 | 承認する人が決まっている | 誰が承認するか毎回変わる |
向きにくい側に多く当てはまるなら、線引きより先に「誰が承認するか」を決めるほうが早いです。承認者が定まらないまま機械検査だけ入れても、止まったものが誰の手元にも行かず滞留します。
1分の無料セルフ診断：どちらに寄っているかを、業務ごとに切り分けます。
具体的に、どう仕組みにするか
線引きを決めて、既存の自動化に組み込むまで
- 1事故の形を先に書く「起きたら困ること」を3つだけ言葉にする
- 2機械/人に振り分ける判定基準が書ける物は機械、書けない物は人へ
- 3止まる形で組み込む検査に落ちたら次の工程へ進めない配線にする
1. 事故の形を先に書く
いきなりチェック項目を並べないでください。先に書くのは「この業務で起きたら困ること」です。請求書なら、金額の桁が違う／宛先が別の取引先になっている／先月の請求が二重に出る、あたりが典型です。3つに絞ると、次の振り分けが速くなります。
2. 機械と人に振り分ける
書き出した事故ごとに、「これが起きたことを、コードで判定できるか」を問います。判定できるなら機械、できないなら人です。迷ったら人に寄せて構いません。あとから機械側へ移すのは簡単ですが、逆は事故を挟むことがあります。
| 事故の形 | 判定できるか | 置き場所 |
|---|---|---|
| 必須項目が空 | できる | 機械 |
| 先月比で金額が大きく動いた | できる | 機械（しきい値で検知） |
| 元データと合計が合わない | できる | 機械（内容照合） |
| この取引先に今月出してよいか | 書きにくい | 人 |
| 文面が今回の状況に合っているか | 書きにくい | 人 |
3. 止まる形で組み込む
いちばん大事なのはここです。検査を通知として足すと、忙しい日に見落とされて素通りします。検査に落ちたら次の工程へ進めない配線にします。送信処理の前に検査を置き、検査が異常を返したら送信関数を呼ばない。この順序だけで、見落としの余地がかなり減ります。
よくある失敗
検査を「実行したあと」に置いてしまう形です。送信してから照合しても、止められるものは何もありません。検査は必ず、取り返しがつく側に置きます。
実際に、どの道具を使うのか
すでに動いている自動化があるなら、その中に検査を挟むのがいちばん早いです。新しいツールを増やすより、いま送信している場所の1つ手前に置きます。
| いま動いている形 | 検査の置き場所 | 補足 |
|---|---|---|
| Google スプレッドシートとフォームで回している | Google Apps Script（グーグル・アップス・スクリプト・Google 製の無料スクリプト環境） | 送信関数の直前に判定を書き、異常なら送らずに担当者へ通知する形が組みやすい |
| 複数のサービスをつないで流している | n8n（エヌエイトエヌ・処理を線でつなぐ自動化ツール。自社サーバーにも置ける） や Make（メイク・同種のクラウド型） | 分岐ノードを1つ足して、条件を満たさない時は送信ノードへ流さない |
| コードで組んでいる | GitHub Actions（ギットハブ・アクションズ・コードの変更をきっかけに処理を走らせる仕組み） | 検査を独立したステップにし、落ちたら後続を実行しない |
| 文書や台帳を Notion で管理している | Notion（ノーション・文書とデータベースを1か所で扱うツール）のデータベース側で状態を持つ | 「承認済」以外は次工程に進めない、という状態管理で線を引く |
使うツール → 得られる状態
- 1Google Apps Script / n8n形式・差分・照合の検査を送信の1つ手前に置く
- 2Notion / スプレッドシート「承認済」の状態を持たせ、それ以外は進めない
- 3得られる状態人は止まった数件だけを見る。全件の目視から解放される
機密情報を含む書類を扱う場合は、どこまでを外部のAIに渡すかも同時に決めておきます。
つまずきやすい点
検査の項目を増やしすぎる。 最初から20個並べると、ほとんどの案件が何かに引っかかって止まります。止まる件数が多いと、人はまとめて承認するようになり、線引きが形だけになります。3つから始めて、事故が起きた形だけを足していくほうが続きます。
「止まった理由」が読めない。 検査に落ちたとき、画面に出るのが「エラー」だけだと、担当者は原因を調べる前に手動で進めてしまいます。どの項目が、どの値で落ちたのかまで出してください。理由が読めない検査は、そのうち迂回されます。
検査そのものが壊れていることに気づかない。 検査が例外で落ちて何も判定しなかったとき、それが「異常なし」と同じ見た目になっていると、誰も気づかないまま素通りが続きます。「判定できなかった」と「問題なかった」は、別の結果として扱ってください。
3行まとめ
①事故の形を3つ書く ②判定基準を書けるものだけ機械へ ③検査は送信の手前に置き、落ちたら進めない。この3つだけで、全件目視から抜けられます。
よくある質問
Q. ダブルチェックは、結局だれがやるべきですか。 A. 機械と人で担当を分けます。形式・差分・内容照合は機械、金額・宛先・外部へ出す判断は人です。「担当者をもう1人立てて二重に見る」形は、件数が増えると先に破綻します。
Q. 全部を人が見返すのは、やはり無理でしょうか。 A. 件数が月に数件なら目視で足ります。月10件を超えたあたりから、見る密度が落ちて見落としが出ます。無理かどうかではなく、件数と型のそろい方で決めてください。
判定に迷ったときの一言
「これが起きたらNG」を、他の人が読んでも同じ結果になる文で書けますか。書けるなら機械、書けないなら人です。
Q. 機械で検査できる部分と、できない部分の境目はどこですか。 A. 「これが起きたらNG」をコードの条件式で書けるかどうかが境目です。空欄・桁数・宛先の一致・合計の照合・前月との差は書けます。文面が今回の状況に合っているか、この取引先に今月出してよいかは書きにくいので、人に残します。
Q. AIが出した文章の内容が正しいかは、機械で判定できますか。 A. 完全には判定できません。数字が元データと合っているかの照合まではできますが、「この説明は今の状況に合っているか」は人が読む必要があります。だからこそ、人が読む対象を数件に絞る設計が要ります。
線引きが決まると、AIの出力は「全部確かめないと使えないもの」から「止まった分だけ見ればよいもの」に変わります。社員が空けた時間は、確認作業ではなく本来やるべき仕事に戻ります。
1分の無料セルフ診断：どの業務から線を引くと効果が大きいかを、1分で切り分けます。
