Difyの書類読み取りアプリは、精度を上げるのをやめた瞬間に現場で使われ始めた

PDFを投げると必要な項目を抜き出してくれる。
そのDifyアプリは作れたのに、現場で使われない時期が1か月くらい続きました。

精度を上げようとして、プロンプトを何度も書き直しました。
頭打ちでした。

使われ始めたのは、精度を上げるのをやめて、「ここだけは人が確認する」と決めた1項目を残してからでした。

「Difyで業務アプリを作る役」になって気づいたこと

私は現場で、ノーコード寄りのAIツールで小さい業務アプリを試しています。

少し前に、Difyで書類の読み取りアプリを作りました。
PDFを投げると、必要な項目を抜き出して一覧にしてくれる、というだけのものです。
作ってすぐは「これで楽になる」と現場でも言ってもらえました。

ところが、運用に乗せた後、別のフォーマットの書類でも使いたい、という話が出てきました。
当然のように、同じアプリでカバーしようとしました。

ここで詰まりました。
フォーマットが少し変わるだけで、抽出結果がずれるのです。
列名が違う、表が分かれている、見出しの位置が違う、それだけで、出てくる結果は手戻りの多いものになりました。

「精度が足りない」と思って、まずプロンプトを書き直しました。
何度も書き直しました。
頭打ちでした。

最初の1種類はうまく動いていたアプリが、2種類目以降で急に頼りなくなる、という体験でした。

壁はどこにあったか

壁は、AIの精度をどこまで上げるか、を一人で抱え込んでいたことでした。

書類読み取りアプリは、最終的に誰かが転記したり、別のシステムに入れたりします。
現場の人は、抜き出した結果を見て、必ず一度は目を通します。

ところが、私は「人が見なくていい状態」を目指してチューニングしていました。
精度を100点に近づけようとしていました。

実際に必要だったのは、100点ではなく、「ここだけは確実」と「ここは曖昧」を分けることでした。

たとえば、社名や日付は元の書類でも崩れにくく、AIで抜き出してもほぼ確実です。
一方で、品目名や金額は、書類のフォーマット差や手書きの影響で、どうしてもブレます。

現場の人は、すべての項目を疑って読み直したいわけではありません。
「ここだけは念のため見てほしい」と分かっていれば、その1〜2項目を確認するだけで先に進めます。

つまり、AIの精度を上げる代わりに、人がどこで確認するかを設計すべきでした。

精度を上げる戦いをしている間、現場の人は、結局すべての項目を疑って二度読みしていました。
それでは、アプリがあってもなくても、手間が大きく変わりません。

この出来事から学べること

書類読み取りアプリは、AI側の精度ではなく、人が確認する1点をどこに置くかで使われ方が変わる、と整理できました。

考え方は3つに絞れました。

1つ目は、抽出する項目を「確実な項目」と「曖昧な項目」に分けて出すこと。
全部を等しく並べるのではなく、信頼度が違うものは見た目を変えて並べます。

2つ目は、曖昧な項目だけを人に見せること。
ハイライトでも、別欄でも構いません。
「ここは念のため確認してください」と分かるようにします。

3つ目は、フォーマット差を1つのアプリで全部吸収しようとしないこと。
書類タイプごとに小さなアプリを並べるほうが、保守も判断もしやすくなります。

これは、別の記事で書いた「手順書ではなく判断書を残す」考え方と、ほとんど同じだと気づきました。
AIに何を任せ、人に何を残すかを、最初から書き分けておく、という発想です。

精度のチューニングだけでは、この境目はうやむやのままでした。

実際に試したこと

最初に変えたのは、抽出結果の見せ方です。

これまでは、抽出した項目を1列の表にして並べていました。
これを、信頼度別に分けた2グループにしました。

確実グループ

• 社名にあたる名称

• 日付

• 文書番号

要確認グループ

• 品目名

• 数量

• 金額

要確認グループには、項目の横に「要確認」のマークを出すようにしました。
ハイライトの色を変えるだけのシンプルな変更です。

次に、フォーマット差の吸収を諦めました。
1種類目の書類のためのアプリと、2種類目の書類のためのアプリを、別々に分けて作り直しました。
プロンプトも、項目の並びも、それぞれの書類に合わせて短く書き直しました。

3つ目は、現場の確認動線です。
要確認グループに項目があれば、最後に「ここだけ確認してください」という一文をアプリ画面に出すようにしました。
全部をチェックしてもらうのではなく、要確認の項目だけ見てもらう導線です。

ここで、2つ失敗しました。

1つ目は、最初に「要確認グループ」を多く取りすぎたことです。
最初は安全側に振って、半分以上の項目を要確認にしました。
すると、現場では「結局全部見るのと変わらない」と言われました。

要確認は3項目以下に絞り直しました。
「絶対に見てほしいところ」だけを残す、という割り切りに変えました。

2つ目は、確認結果をアプリ側で記録していなかったことです。
人が確認したかどうかが残らないので、後から「あれは見たはず」「いや見ていない」とすれ違いました。

確認チェックを残すために、確認済みボタンを1つ足しました。
ボタンが押された記録だけ残るようにしました。
これで、見たかどうかの不明点は消えました。

やってみて分かったこと

良かった点は2つです。

1つは、現場で使われる頻度が、最初の1か月よりも目に見えて増えたことです。
精度を上げようとして触らなくなった時期と、確認設計を変えてから使われ始めた時期が、はっきり分かれました。

精度ではなく、現場が使いやすい確認動線が、運用に効きました。

もう1つは、フォーマットを増やすときの怖さが減ったことです。
1つのアプリで全部を吸収しようとしないと決めたので、新しい書類が出てきたときも、小さいアプリを足すだけで済むようになりました。

意外だったのは、精度を100点に近づけなくても、現場で動くアプリになった、という事実です。

確認する場所が決まっていれば、AIの抜け漏れは「ここだけ確認」で吸収できる。
完璧な抽出を目指していたときよりも、運用に乗ってからの不具合は少なくなりました。

精度を追いかけていた1か月は、現場の使い勝手から見ると、ほとんど前に進んでいませんでした。
進み始めたのは、AI側ではなく、人と画面の境目に手を入れてからです。

明日から試せる一歩

書類読み取りのアプリを作っている、または作りたい人向けの一歩です。
Dify以外のノーコードツールやスプレッドシートのフォームでも、考え方はそのまま流用できます。

• 抽出項目を「確実」と「要確認」の2グループに分けて並べる

• 要確認は3項目以下に絞る（多すぎると全項目チェックに戻る）

• フォーマット差を1アプリで吸収しようとしない

• 書類タイプごとに小さなアプリを並べる

• 確認したかどうかをボタン1つで記録に残す

精度を上げる前に、人が確認する場所を決めることから始めるのが近道でした。

この記事が参考になったら「スキ」で教えてください。次の実験の励みになります。

次の一手（#AI活用100本ノック）

確認設計を入れたことで、書類読み取りアプリは「現場で使われるアプリ」に近づきました。
ただ、まだ確認担当者が一人に集中しているので、属人化しやすい設計のままです。

次は、要確認の項目だけを別の人に流す簡単な分担ルールを作って、確認の負担を分散できるか試してみます。

精度を追うより、確認の流れを設計するほうが、運用としては素直に伸びる気がしています。

関連記事：

• Difyで作る、書類読み取りアプリの失敗しやすいポイント全部のせ：https://note.com/clean_whale1844/n/nb49319d7c72e

• FAQを作ったのに同じ質問が来る本当の理由：https://note.com/clean_whale1844/n/n2d7163c51a42

• 引き継ぎ資料を「手順書」から「判断書」に変えたら、担当者交代後の問い合わせが半分になった：https://note.com/clean_whale1844/n/n24b4ad38b7f0

#AI活用100本ノック 進捗：85/100

次回の実験：要確認項目だけを別の担当に流す分担ルールを作って、確認の属人化を減らせるか試す

このnoteでは、現場改善・AI活用・小さな自作ツールの試行錯誤を記録しています。
初めての方はこちらからどうぞ。
▶ はじめての方へ｜このnoteで書いていること