AIに書類チェックを任せてみた｜信用できるかは「分からない」と言えるかで決まった

「Claudeで作れないか」と言われた

上司から相談があった。書類のチェックを自動化できないか、という話だ。

前提として、すでに似た仕組みは動いていた。書類を共有フォルダにアップロードするとき、その場でCopilotに読ませて、決まった観点でチェックする——という運用だ。1件ずつなら、これで足りている。

問題はすでにアップロードされた分だった。Copilotからは共有フォルダの中のファイルに手が届かない。つまり「入口」は見張れても、すでに積まれたものをまとめて確認する手段がなかった。

そこを埋められないか、というのが相談の中身だった。

作ったもの

構成は素っ気ないくらい単純だ。

8:50 / 17:50   PowerShell
    ↓  新しく増えたフォルダを検出して、一覧をファイルに書き出す
9:00 / 18:00   Claude（スケジュール実行）
    ↓  その一覧を読んで、PDFをチェック
    ↓  結果をまとめて共有フォルダに出力
    ↓  処理済みとして記録

1日2回、誰も操作しない。 朝出社したら、前日分のチェックが終わっている。

なぜこの形になったのか、2つだけ書いておく。

① 一度に全部やらせたら、途中で止まった

最初は素直に「フォルダの中を全部見て」と頼んだ。途中でタイムアウトして止まった。

考えてみれば当然で、対象は月に1000件近くまで増えていく。しかも毎日増え続けるので、放っておけば量は膨らむ一方だ。一度で終わらせようとする限り、いつか必ず破綻する。

そこで方針を変えた。すでに処理したフォルダを記録しておいて、前回から増えた分だけを渡す。 その「増えた分を見つける係」をPowerShellに任せている。

これで止まらなくなったし、読ませる量が減るので費用も下がる。46万件のファイルを整理したときにも同じ結論に辿り着いていた。

止まることを前提に作る。一度で終わらせようとしない。

別の業務で、また同じ教訓を踏んだことになる。大量のものを扱うときは、たぶんこれが唯一の正解なのだと思う。

なお読ませるのも原則1ページ目だけにしている。必要な情報はそこにしかないからだ。

② 直接つながらないので、ファイルでバトンを渡す

PowerShellとClaudeのスケジュール実行は、互いを呼び出せない。そこで10分ずらして動かし、あいだをファイル1つで繋いだ。8:50に一覧が書き出され、9:00にそれを読む。

書類の仕分けを作ったときも、完了の合図をファイルで渡していた。直接つながらないものを、ファイル1つで安全につなぐ——同じ手を2回使ったことになる。地味だが、これが一番壊れにくい。

いきなり、人の見落としを見つけた

テスト段階で、予想していなかったことが起きた。

すでに人の目を通っていた書類から、チェック漏れが見つかった。 レ点を入れるべき欄が空欄のまま、というものだ。

考えてみると当然かもしれない。人は書類を読むとき、「ここにはレ点があるはずだ」と無意識に補ってしまう。何十枚も見ていればなおさらだ。機械はそれをしない。 空欄は空欄として見る。

ここで感じたのは、人の代わりをさせているのではないということだった。人が得意なところと、機械が得意なところは違う。今回埋まったのは、人がどうしても苦手な種類の見落としだった。

でも、いちばん安心したのは別のところ

成果としては上の話が分かりやすい。ただ、実際に使っていて安心したのは違う点だった。

判断が付かないものについて、勝手に決めずに聞いてくる。

これは意図してそう設計した。チェックのルールに、こう書いてある。

判断が付かない項目、および書類にその項目自体が存在しない場合は、推論せずに確認すること。

なぜこうしたか。**検査という仕事で怖いのは、間違えることより「間違えたことに気づけないこと」**だからだ。

もしAIが「たぶん問題ないでしょう」と埋めてしまったら、こちらはそれを信じる。逆に「たぶん不備です」と言われて、それが的外れなら、確認の手間が増えて信用を失う。どちらも困る。

分からないものを分からないと言ってくれるなら、残りは信じられる。 信頼性というのは正確さの話だと思っていたけれど、実際に使ってみると**「言わないことを決められるか」**のほうが効いた。

これは以前46万件のファイルを仕分けたときに決めたルールと同じ構造だった。

迷ったら全部「要確認」に入れる。AIに「たぶん消していいと思います」と判断させない。

別の業務で、同じ原則がまた効いた。たぶんこれは、AIに判断を任せるときの一般的な作法なのだと思う。

最初は、盛大に誤検出した

もっとも、最初からうまくいったわけではない。

初期に多かったのが「存在しない項目を不備として報告してくる」というものだった。書類にはいくつか種類があって、種類によってある項目とない項目が違う。それを知らないまま「この項目が空欄です」と指摘してくる。

これはAIが賢くないのではなく、こちらが伝えていなかっただけだ。何ができて何ができないかは最初に一通り調べてあったけれど、業務のルールは調べても出てこない。自分で伝えるしかない部分だった。

だからルールを書き足した。

書類に存在する項目のみをチェック対象とすること。

これで解消した。AIへの頼み方をまとめた記事に「同じことを二度説明したら、それは文書にすべきサイン」と書いたけれど、まさにその通りだった。誤検出が出たら、まず自分の指示を疑う。

「作って終わり」ではなく、育てる期間がある

正直に書いておくと、この仕組みはまだ完成していない。

チェックすべきパターンが多く、新しい書式が出てくるたびにルールを足していく必要がある。当面は、出てきた誤検出を見ながら人が教え続けることになる。

これは面倒に聞こえるかもしれないが、人に仕事を引き継ぐときも同じだと思う。最初から完璧に引き継げる仕事はない。何度か一緒にやって、例外を伝えて、だんだん任せられるようになる。相手がAIでも変わらなかった。

そして——誰も見ていない

ここまで書いておいて、いちばん大事なことを書く。

この仕組みが検出した不備を、今のところ誰も見ていない。

結果は共有フォルダにファイルとして出力される。それだけだ。誰が見るのか、いつ見るのか、見たあと何をするのかが決まっていない。 だから、不備が見つかっても何も起きない。

これは仕組みの出来とは関係がない。動作は完璧で、毎日きちんと走っている。それでも何も変わっていない。

以前に作った記入漏れの自動通知は、うまくいった。何が違ったのかを並べると、はっきりする。

あちらが機能したのは、仕組みが優れていたからではなかった。「朝礼」という、もともと人が集まる場があったからだ。出口が先にあって、そこに流し込んだだけだった。

今回はそこが空白のまま作ってしまった。技術の問題ではなく、出口の問題だ。

自動化は「作る」だけでは半分

今回いちばん学んだのはこれだった。

自動化というと、どうしても「仕組みを作ること」に意識が向く。動いた時点で達成感もある。でも実際には、

誰が・いつ・どこで結果を見て、そのあと何をするのか

まで決めて、はじめて仕事が変わる。そこを設計しないと、正確に動く仕組みが、誰にも見られないまま毎日走り続けることになる。

次にやるべきことは、たぶんチェックの精度を上げることではない。結果を、人がすでに見ている場所に届けることだと思っている。

まとめ

1. AIの検査は「分からない」と言える設計にすると信用できる。 正確さより、言わないことを決められるかどうか
2. 誤検出が出たら、まず自分の指示を疑う。 たいてい伝えていないルールがある
3. 仕組みより先に、出口を決める。 見る人と見る場がないと、動いていても何も変わらない

3つ目は、自分がまさに今つまずいているところだ。書きながら、次にやることが決まった気がする。