はじめに
「取引先や拠点ごとにフォーマットが異なる大量の書類を読み取り、社内の別データと突合する」といった業務は、多くの会社に存在すると思います。多くの場合、この突合作業は最終的に人が目視で確認するという形で運用されており、件数が多いほど負荷が大きくなります。
このPoC(概念実証)では、こうした「フォーマットがバラバラな大量書類の読み取り+既存データとの突合」を、生成AIエージェント(Claude/Cowork)とPythonスクリプトの組み合わせで自動化しました。
この記事では、業務の中身そのものよりも、「AIをどこで使い、どこで使わないか」という設計判断にフォーカスして、実際に効果があった工夫を紹介します。同じように「大量の定型書類を継続的に処理する」タイプの業務であれば、業種を問わず応用できる考え方だと思います。
全体像
処理は次の4段階に分かれています。
ステップ0: 未仕分けの書類を、企業・フォーマット単位で自動仕分け
↓
ステップ1: 単一フォーマットの書類からのデータ抽出
↓
ステップ2: フォーマットが異なる複数書類からのデータ抽出
↓
ステップ3: 抽出済みデータ同士の突合・レポート出力
ポイントは、この4段階のうちAIが実際に「読む・判断する」のはごく一部で、残りは決定的なPythonスクリプトが担っているという点です。
工夫1: 「初めて見るフォーマットの解釈」だけにAIを使う
最も効いた設計判断はこれです。
AI(トークン消費)を使うのは、未知のフォーマットを初めて解釈するときだけに限定する。既知のフォーマットは、AIが過去に生成したPythonスクリプトで機械的に処理する。
書類のレイアウトは提出元ごとに異なりますが、同じ提出元であればフォーマットは基本的に毎回同じです。つまり、
- 1回目: AIに1件分の書類を読ませ、その構造を解釈するスクリプトを生成・検証する(ここだけコストが発生)
- 2回目以降: 生成済みのスクリプトを実行するだけ(AI不使用・ほぼ無料)
という「初回だけ賢いAI、以降は安いスクリプト」という役割分担にすることで、処理対象の件数が増えてもAIコストがほぼ増えない構造になりました。
この考え方は、「AIに継続的に読み取らせ続ける」設計と比べて、運用コストが劇的に変わります。処理件数が数百・数千件規模になる業務ほど効果が大きい工夫です。
工夫2: 「判断」と「照合・比較」を切り分ける
もう一つの軸は、AIの判断が必要な処理と決定的に解ける処理をはっきり分けたことです。
| 処理 | 方式 | 理由 |
|---|---|---|
| 未知フォーマットの解釈 | AI | 人間でも読んで判断する必要がある |
| 既知フォーマットの仕分け | 構造指紋(スクリプト) | 表の構造をハッシュ化すれば機械的に一致判定できる |
| 抽出データ同士の突合 | Pythonスクリプト | 表記ゆれの正規化+比較は決定的なロジックで完結する |
たとえば仕分けの段階では、書類上のラベル(名称の記載)ではなく、「表の構造そのもの(罫線・セル配置などのハッシュ値)」を判定軸にしています。ラベルの有無や位置は書類によってまちまちですが、構造指紋なら既知フォーマットかどうかを高速かつ無料で判定できます。AIが必要になるのは、指紋が一致しない=本当に未知のフォーマットが来たときだけです。
「AIでもできるが、実はロジックで完結する処理」を見極めて外に出す。これがコスト最適化の核心でした。
工夫3: エージェントの「スキル」の粒度設計
AIエージェントに手順や生成物を記憶させる「スキル」機能は便利ですが、対象の提出元が数十〜数百に増えると、提出元ごとにスキルを作ってしまうと一覧が埋め尽くされて破綻します。
そこで、
- 提出元ごとの読み取りスクリプトは個別に生成する
- ただしスキル自体は1つに統合し、対応表(マニフェスト)で「提出元・フィンガープリント・対応スクリプト」を管理する
という構成にしました。スキルという単位と、実際の処理ロジックの単位を意図的に分離したことで、対象の提出元がどれだけ増えてもスキル一覧はシンプルなまま保てます。
工夫4: 1回の指示に詰め込みすぎない(バッチ上限)
これは実際に試行して分かったことですが、1つの会話に大量の処理を積み重ねると、会話履歴の再送信によって後半ほどコストが増大します。
そのため、未登録フォーマット(初めて見る書類)の「初回登録作業」には、
1回の指示につき最大10件まで
という上限を明示的に設けました。既知フォーマット(スクリプト実行のみ)には上限を設けず、AIの読み取りが発生する処理にだけ制限をかけるという非対称な設計です。上限を超えた分は処理せず、完了報告に理由と対象一覧を明記して、別の会話での再実行を促す形にしています。
「AIに読ませる作業」と「スクリプトを流すだけの作業」を同じ指示の中に混ぜて実行し、前者だけ件数管理する、という考え方は他の大量データ処理タスクにも転用しやすいと思います。
工夫5: AIの誤読を前提とした精度対策
視覚読み取りベースのAI抽出には、書類上の代表値(見出しなど)を全項目にコピーしてしまうといった誤読パターンが実際に見つかりました。これに対しては、
- 合計値との整合性チェック(内訳の合計が総計と一致するか)
- 周期・区分チェック(想定外の区分に不自然な値が入っていないか)
- 不自然な均一性の検知(全項目が寸分違わず同じ値になっていないか)
といった、抽出後にスクリプトで検証するチェックを組み込みました。AIの出力をそのまま信用せず、AIの後段に決定的な検証ロジックを置くことで精度を担保する、という構成です。抽出はAI、検証はスクリプト、という役割分担がここでも活きています。
全体を通じた設計思想
まとめると、このプロジェクトでのAI活用は次の3原則に集約されます。
- AIは「初めて見るものの解釈」にだけ使う。 繰り返し処理はスクリプト化して再利用する。
- 判断が要らない処理(照合・比較・仕分け)は最初からロジックで書く。 AIに投げない。
- AIを使う処理には、指示単位でのコスト上限を明示的に設ける。 際限なく積み上げない。
AIエージェントに「なんでもやらせる」のではなく、AIでなければできない部分だけを見極めて切り出すことが、処理件数が数百〜数千規模になるシステムでは費用対効果を大きく左右する、というのがこのPoCで得られた実感です。
まとめ
生成AIを業務自動化に組み込む際、つい「全部AIにやらせる」方向に寄りがちですが、
- 未知への対応だけAIに任せ、既知はスクリプトに落とし込む
- 判断が不要な処理は最初からロジックで書く
- AIを使う範囲にはコスト上限を明示的に設計する
- AIの出力は後段の決定的なチェックで裏付ける
という設計を意識するだけで、精度とコストの両面でバランスの良いシステムになりやすいと感じています。同種の「大量の定型書類×フォーマットのばらつき×既存データとの突合」に取り組む方の参考になれば幸いです。