文書処理リソースの選び方
契約書、請求書、報告書——文書を扱う処理は、生成するのか、読み取るのか、署名するのかで必要なリソースが分かれる。それぞれ論点が異なるため、まず自分がどれをしたいのかを切り分けたい。
生成する場合
HTML から PDF を作る構成が一般的だが、日本語ではフォントの埋め込みが最初の関門になる。変換環境に日本語フォントが無いと、CSS で指定しても反映されず文字化けする。また画面表示用の CSS と印刷用の CSS は別物で、改ページ位置やヘッダーの繰り返しは印刷用のスタイルで制御する。請求書のように書式が意味を持つ文書では、実際に出力して確認するまで完了とは言えない。
読み取る場合
日本の業務書類は罫線が多く、縦書きも混ざるため、汎用の OCR が苦手とする条件が揃いやすい。印刷された文書なら実用水準にあるが、手書き、低解像度のスキャン、複雑な帳票では精度が落ちる。実際の書類サンプルで検証したうえで、帳票特化のサービスと比較して判断するのが確実だ。
読み取り結果は後処理込みで設計してください
OCR の出力をそのまま使える場面はほとんどありません。金額のカンマ、日付の形式、全角半角の揺れ——といった正規化処理が必ず要ります。読み取り精度の比較だけでなく、その後の整形にどれだけ手間がかかるかまで含めて評価してください。
署名する場合
電子署名は「送って終わり」ではなく、相手が署名するまで待つ非同期の処理になる。完了を Webhook で検知し、署名依頼・リマインド・期限切れ・辞退といった状態をアプリ側でも保持しておかないと、契約がどこで止まっているか分からなくなる。あわせて、署名済み文書の保管方針（サービス側に置くのか自社で保管するのか）を運用開始前に決めておきたい。