Google Cloud Document AI：大量ドキュメント処理3パターンの比較検証と最適構成の話
1. はじめに
本記事では、Google Cloud Document AIを使用したカスタムOCRバッチ処理の実装において、3つの異なる実装パターン（ループ処理、並行処理、BatchProcess）を比較検証した経験を共有します。
忙しいエンジニアの方のために、まずは本プロジェクトの結論となるサマリーを提示します。
2. プロジェクトの背景と立ちはだかる課題
私の担当プロダクトでは、ドキュメントアップロード時にDocument AIによる情報の自動抽出を行っていますが、バッチ処理基盤の構築にあたり以下の課題を抱えていました。
未処理データの蓄積: 機能導入前に作成された大量のドキュメントが未処理のまま残っている状態
でした。
処理失敗ドキュメントの再処理: アップロード処理に失敗したドキュメントを、後から確実に再処理で
きる堅牢な仕組みが必要でした。
パフォーマンス要件: これら数十万件のドキュメントを効率的かつスピーディに処理することが求めら
れていました。
これらの課題を解決するため、処理時間やリソース使用量を比較し、最適な実装アーキテクチャを選定することにしました。
3. 比較検証した3つのアーキテクチャパターン
目標達成のため、以下の3パターンのバッチ処理を実装・検証しました。
ループ処理（シーケンシャル） 最もシンプルな実装で、1件ずつ順次処理します。
並行処理（Goroutine + セマフォ） Go言語のgoroutineを使用して並行処理を実現し、セマフォで同時
実行数を制御するアプローチです。
3. BatchProcess（LRO） Document AIのバッチAPIを使用し、複数のファイルをまとめてバッチ処理しま す。Long Running Operation（LRO）として非同期で実行されます。
4. 実測から見えた各パターンの評価と特性
実際のプロダクション環境と同等の条件でこれら3パターンを実装し、計測を行いました。 今回は検証のため、1000件のドキュメント（平均5MBのPDF）を対象データとして用意し、同一環境下で比較しています
処理時間とリソース使用量の傾向
ループ処理: 1件ずつ順次処理を行うため処理時間が最長となり、1000件の完了までに約120分
（1件あたり約7.2秒）を要しました。CPU・メモリ・ネットワークの使用量は全て低い状態を保ちます。
並行処理（採用パターン）: Document AIのクォータを考慮して5並列に制御して実行した結果、約30分
（1件あたり約1.8秒）と、比較した中で最も高速に完了しました。一方で、並列実行によりCPU使用率
が高くなり、メモリとネットワークトラフィックも中〜高程度消費します。
BatchProcess: 処理時間は約50〜70分（1件あたり約3〜4.2秒）と、並行処理とループ処理の中間程
度となりました。アプリ側の処理は軽量ですが、GCS（Google Cloud Storage）経由のI/Oが発生するた
め、ネットワーク負荷は低く抑えられます。
なぜマネージドな「BatchProcess」が最速ではなかったのか？
実際の計測でBatchProcessが並行処理よりも遅くなった要因として、以下の3点が挙げられます。
内部的な処理方式: バッチリクエストは内部で全てのドキュメントを同時に並行処理するわけではなく、
キューイングとワーカーの割り当てにオーバーヘッドが発生します。
データI/Oのコスト: バッチ処理は必ずCloud Storageを経由するため、オンライン処理に比べてI/Oの
オーバーヘッドが発生します。
非同期処理の特性: LROとして非同期で実行されるため、ポーリングによる完了待ちの時間が発生します。
BatchProcessの持つ強力なメリット
一方で、BatchProcessには以下のような独自のメリットもあります。
API制限の回避: オンライン処理とは別のクォータ体系で管理されるため、大量処理時に制限に引っかかり
にくくなります。
運用負荷の低さ: 大量データを1回のAPIコールで処理できるため、運用がシンプルになります。
リトライ管理の自動化: Google側でリトライ管理を行うため、アプリ側の実装が簡潔になります。
大容量ファイル対応: オンライン処理のペイロード制限を超えるファイルも処理可能です。
5. オンライン並列処理 vs BatchProcess 総合比較表
実際の計測と実装経験から、各アプローチの特性を以下の比較表にまとめました
6. 採用した構成とその選定理由
最終的に、担当したプロジェクトの本番環境では、実測に基づく比較の結果から「並行処理（Goroutine + セマフォ）」を採用しました。
以下の観点が決め手となりました。
処理時間: 比較した中で最も高速で、BatchProcessよりも半分も短縮できてました。
実装のシンプルさ: LRO状態管理などが不要で、運用が容易でした。
エラーハンドリング: 1件単位での個別のエラーハンドリングが容易に行えます。
デバッグの容易さ: 処理の流れが追いやすく、原因特定が簡単です。
再開機能: DBの状態を確認するだけというシンプルな実装で対応可能でした。
7. まとめ
Document AIを利用したバッチ処理において、マネージドサービスであるBatchProcessは運用負荷の低減に役立ちますが、速度面では自前での並列化に軍配が上がる場合があります。要件（速度優先か、運用簡素化重視か）に応じて、実測に基づいてアーキテクチャを選択することが極めて重要です。
【補足】
本プロジェクトでは、AI開発支援ツール（Cursor）を全面的に活用し、開発プロセスを効率化しました。
AIでは代替できない（限界がある）領域
以下の領域はAIに任せきりにせず、人間が主導する必要がありました。
DB設計の検討やアーキテクチャ決定といった設計判断。
実際の環境での動作確認やパフォーマンステスト（統合テスト）。
LRO状態管理や再開機能のような複雑なビジネスロジックの実装。
AIと人間の役割分担
AIを効果的に活用するためには、どこで人間が判断し、どこでAIを活用するかを明確にすることが重要です。
人間が行う設計判断: どのアーキテクチャパターンを採用するか、DB設計、並行処理の制御方針、エラー
ハンドリング戦略などの「要件定義」と「最終決定」は人間が行います。
AIを活用する実装支援: 人間が決めた設計に基づき、ボイラープレート（定型コード）の生成、API使用方法
の提示、テストコードの自動生成、エラーメッセージからのデバッグ支援などをAIに依頼します。
