PADで作ったPDF自動分割ツールが不安定だった話

RPAは「作って終わり」ではなかった

業務改善のためにPower Automate Desktop（PAD）で作った帳票（PDF）処理の自動化。最初は「いいじゃん！」と喜んでいたのですが、実際に複数人に使ってもらうようになると、ある問題が出てきました。

大量ページのPDFになると、たまに処理が失敗する。しかも、失敗した後にもう一度実行すると成功する。

「何が原因なんだろう？」そんな状態から、安定して使える仕組みに改善するまでの記録です。

作ったもの：注文書PDFの分割・整理・マージ

今回自動化したかったのは、注文請書PDFの処理です。元データはシステムから出力されたPDF。そのままだと後工程で扱いにくいため、1ページ単位に分割、ページ内の文字情報から企業コードを取得、IDをもとにファイル名を付与、同じ企業コード単位でマージ、ID順に並んだ印刷用ファイルを作成、という流れをPADで自動化しました。

最終的には印刷作業に合わせて、1人で印刷する場合は全体をまとめたファイル、複数人で印刷する場合は企業別、または担当別ファイルを作れるようにしています。

最初は「動けば成功」だった

自分用に作った時は、正直そこまで困りませんでした。多少失敗しても「もう一回実行すればいいか」で済んでいたからです。

でも、他の人にも使ってもらうようになると話が変わります。「処理完了しました」と表示されたのに、実はページが足りない。これは避けなければいけません。

400ページを超えると不安定に？

少ないページ数では問題なく動く。でも、100ページを超えるあたりから時々失敗する。最大では400ページ以上のPDFも扱うため、不安定さが気になっていました。

原因候補として考えたのは、待機時間が短い、PDF分割処理自体が重い、ページ数の判断がおかしい、ファイル生成が追いついていない、など。ただ、再実行すると成功することが多かったため、「処理タイミング」の問題ではないかと考えました。

原因はエラー処理でした

見直したところ、PDF分割アクションでエラーが発生した場合、「次へ進む」設定になっていました。つまり、分割処理が一時的に失敗しても、そのページは処理されないまま次へ進む、という動きになっていました。

RPAとしては処理が止まらないので一見便利です。でも、今回のような帳票処理では危険でした。「最後まで処理できたように見えるけれど、途中のページが抜けている」状態になる可能性があります。

リトライ設定で改善

PADのエラー処理でリトライを設定しました。失敗した場合、もう一度実行、それでも失敗したら再試行、最大3回まで、という形です。

すると……400ページ以上のPDFでも連続して成功。今まで不安定だった処理が、あっさり安定しました。「もっと早く確認すればよかった……」と思ったくらいです（笑）

さらにページ欠損チェックも追加

ただ、リトライを入れたから完全安心、ではありません。万が一を考えて、分割枚数のチェックも追加しました。

元システムから出力されるPDFには、それぞれのファイル内のページ数情報があります。本来分割されるべきページ数とPADで分割成功したページ数を比較するようにしました。

予定420ページ、分割成功420ページならOK。予定420ページ、分割成功418ページなら、何か問題が起きていると判断できます。100％すべての異常を検知できるわけではありませんが、「気づかない欠損」を防ぐ仕組みとしては有効だと思っています。

RPAは「作る」より「育てる」が大事なのかもしれない

今回改めて感じたことがあります。自動化というと、手作業をなくす、ボタン一つで終わる、というところに目が行きがちです。

でも、実際に業務で使うには、エラーが起きた時どうするか、失敗に気づけるか、他の人が安心して使えるか、まで考える必要があります。

自分だけが使う便利ツールから、みんなが使える業務ツールにするには、最後の仕上げが大切でした。

次はWebアップロードの安定化へ

次に改善したいのは、Webページへのアップロード処理。こちらも外部要因が多く、不安定になりやすい部分です。

「とりあえず動く」から「誰が使っても安心して動く」仕組みを目指して、少しずつ改善していきたいと思います。

業務改善は、作った瞬間がゴールではなく、使われながら育てていくものなのかもしれない。今回の経験で、改めてそう感じました。