--- title: "止められない帳票業務から、入力作業をなくす" url: https://cv.tanghoong.com/ja/work/ocr-llm-document-pipeline/ locale: ja description: "人による確認キューとチェックポイント再開を備えた、OCR と LLM の帳票パイプライン。グローバルなコンテナ海運会社で稼働 —— 元システムには API がなく、置き換えもできない。" --- # 止められない帳票業務から、入力作業をなくす > OCR と LLM を組み合わせたパイプラインで、大量の海運帳票業務における手入力を大幅に削減しました —— 元システムには API がなく、置き換えることもできない運用環境で。 - **担当:** Senior Business Process Specialist - **能力:** 応用 AI · 業務自動化 · 本番運用の責任 - **領域:** グローバルコンテナ海運 —— 経理・物流の運用 - **制約:** 元システムに API がなく、使える Web 画面すらないことも多い ## 背景 グローバルなコンテナ海運会社のマレーシア拠点で、Senior Business Process Specialist を務めていました。チームは小さく —— 実質は私と同僚 1 名 —— 意思決定の関門は別の 2 か国にあります。経理と物流の担当者は毎日大量の海運帳票を読み、その内容を手でシステムに入力していました。 ## 課題と不明確だった点 この作業が実際にどう行われているかを書き残した人が誰もいなかったので、最初の一歩は自動化ではなく発掘でした。帳票の状態は幅が大きく、機械が生成したきれいなファイルから、経理が電話で問い合わせるしかないほど劣悪なものまであります。そして両端のシステムは互いに独立していました：API はなく、使える Web 画面すらないことも多い。置き換えは最初から選択肢になく、費用の一点だけで却下されました。 ## 私の担当 ドキュメントのない経理・物流の業務を分析し、手作業で、繰り返しが多く、間違いやすい工程のうち、どれが自動化に値するかを判断しました。この帳票パイプラインを設計し、その Python バックエンド API を構築し、周辺の RPA を開発・展開しています。 ## 要件把握 実際に作業している人の隣に座り、業務フロー図に書かれていることではなく本当に起きていることを記録し、そのうえで候補となる各工程を 1 つの問いで検証しました：この工程を自動化したあと、ある火曜の朝 9 時に落ちたら、業務はどうやって続くのか？ ## 設計とトレードオフ LLM 単体の抽出ではなく、OCR と LLM の組み合わせを選びました。これは時点のある判断であり、当時としては正しいものでした：当時の LLM の画像認識では実際の帳票から安定して項目を取り出せなかったため、OCR がフォーマット別の読み取り画面に流し込み、位置がわかっている項目はマスクで位置から取り出し、言語モデルには本当に得意な部分だけをやらせています。連携は意図的に侵襲的でない形にしました —— すでにあるものから読むのであって、置き換える気のない基幹システムの入れ替えを企業に求めるのではありません。当時の私のまとめはこうです：制約が多すぎるので、回り込むしかない —— 今でもそれが、企業向け AI の仕事に対する最も正直な説明だと思っています。 ## 実装と連携 Python のバックエンド API が、フォーマット別の抽出画面と確認キューを支えます。自動処理が止まった位置から続けられる操作画面も用意しました。非同期は RabbitMQ です。全工程に検証と監査証跡があります。RPA は経理と物流にまたがるデータ抽出、検証、照合を担当します。 ## 本番運用の作り込み ここが最も自信を持って擁護できる部分です。抽出した値をデータベースへ直接書き込むことはありません：人による確認キューに入り、そこで修正し、きれいなレコードであっても書き込み前にもう一度確認します。1 回の取り込みは数時間かかることがあり、いつ中断してもおかしくないため、全体をチェックポイント付きのノードとして設計し、中断後は記録された位置から再開します —— 最初からではありません。ジョブは意図的に早朝に開始し、担当者が出社する時点で失敗が見えているようにしました。そうすれば手作業に戻す時間が残り、昼までに引き継げます。そして自動化は「全部か無か」ではありません：機械が途中まで進んだなら、人が画面から残りを引き継げます —— ノードの図でもコードでもなく。 ## 結果 この業務の手入力の大部分がなくなり、その間、運用は一度も止まりませんでした。この経験について数字は一切公表しません —— 意図的な NDA 上の判断であり、口頭でも同じです。 ## 持ち越せる学び ここで固まった設計上の立場は、今でも主張します：費用の理由で基幹システムを入れ替えない企業に対しては、正しい連携方法は「オペレーターの画面にすでに出ているものから読む」です。そして業務のなかの人による確認は、自動化の不足ではありません —— それこそが、この自動化を導入可能にしたものです。 ## 公開できる裏づけ Charlie の追記待ち —— 合成した海運系帳票によるクリーンルーム再現（読み取り画面、確認キュー、チェックポイント再開を含む）は案件 P4 として計画済み、未着手です。