【ITニュース解説】Aprendizados com o AWS Bedrock Data Automation em um Produto de IDP

ある金融技術企業で、AI（人工知能）技術をリードするチームが、文書から必要な情報を自動的に読み取るシステム、すなわちIntelligent Document Processing（IDP）製品を開発した経験を語る。このプロジェクトの目標は、支払証明書のようなPDFファイルや画像データから、支払い日や金額といった構造化された情報を、信頼性が高く、大量に処理できる形で抽出することだった。開発を加速させるため、チームはAWS Bedrock Data Automation（BDA）というサービスを導入したが、その過程で多くの学びと、いくつかの予期せぬ課題に直面したという。

BDAは、クラウドサービスを提供するアマゾンウェブサービス（AWS）が提供するツールで、文書や画像から自動的にデータを抽出する機能を持つ。このサービスの特に便利な点として、「ブループリント」という、どのようにデータを抽出し、整形するかを定義する設計図のようなものを作成する機能がある。ブループリントの作成方法には二つあった。一つは、開発者がJSON Schemaという、データの構造を記述する専門的な形式を使って手動で細かく定義する方法。もう一つは、自然言語、つまり普通の言葉で「どの情報を抽出して、どう処理するか」と指示するだけで、自動的にブループリントを作成する方法だ。後者の自動作成機能は非常に手軽で魅力的で、すぐに動くブループリントができ、期待できるデータ抽出結果が得られたため、チームはこの方法を採用した。初期の開発段階では順調に進み、システムは本番環境でも期待通りに機能していたが、やがて予期せぬコスト問題に直面することになる。

最初の課題は、プロンプト、つまり自然言語の指示で作成されたブループリントが、常に「ドキュメント」として扱われるという点だった。たとえ元のファイルが画像であったとしても、BDAはそれを「ドキュメント」として認識して処理してしまう特性があったのだ。開発中のテストではこの違いが問題にならなかったため、この重要な特性は見過ごされてしまった。しかし、この認識の違いが後になって、深刻な金銭的影響をもたらすことになる。

二つ目の課題は、この誤ったモード認識が引き起こした経済的な影響だった。BDAには、処理するファイルが「ドキュメント」なのか「画像」なのかを区別し、それに応じて処理方法を切り替える機能がある。この設定は単なる技術的な違いにとどまらず、AWSが請求する料金に直接影響する。AWSの料金体系では、ドキュメントとして処理される場合は1ページあたり0.040ドル、画像として処理される場合は1画像あたり0.005ドルと、画像の方が大幅に安価に設定されている。しかし、プロンプトで自動作成したブループリントはすべて「ドキュメント」として扱われたため、実際の処理対象が画像であったとしても、高額なドキュメント料金が適用されてしまった。テスト期間中はその影響が小さく気づかなかったが、本格運用が始まったある月には、約1,000ドルもの追加料金が請求される事態になった。原因を詳しく調査した結果、自動生成されたブループリントが画像の処理モードを適切に考慮していなかったことが判明した。この問題を解決するためには、手動でJSON Schemaを用いてブループリントを再作成し、「ドキュメント」か「画像」かを正しく設定し直す必要があった。この経験は、製品のドキュメントが重要な詳細を明確に伝えていない場合、予期せぬ損失につながる可能性があることを示している。

三つ目の課題は、処理速度、つまりレイテンシだった。BDAで一つの文書や画像を処理するのに、平均で約30秒もの時間がかかった。システム設計上は、非同期処理という、タスクの完了を待たずに次の作業に進める方法を採用することで、システム全体が停止することなくこの遅延に対応できた。しかし、システムを利用するユーザーの視点から見ると、支払証明書をアップロードしてから結果を受け取るまでに30秒待つのは非常に長く、システムの応答が遅いと感じさせてしまう。このユーザー体験（UX）への悪影響を緩和するために、アプリケーションの改修を行ったものの、他の代替技術、例えばAWS Textract（画像やスキャン文書からテキストを自動抽出するサービス）とLLM（大規模言語モデル）を組み合わせたり、OCR（光学文字認識）と後処理を組み合わせたりする方法と比較すると、BDAの処理速度は見劣りする場合もあった。これらの代替手法は、同程度のコストでより短い処理時間を提供できる可能性もある。

これらの課題に直面しつつも、BDAがもたらした明確なメリットも存在した。最大の利点は、データ抽出システムをゼロから全て構築する必要がなく、その複雑性を大幅に抽象化できたことだ。これにより、非常に迅速にプロトタイプを開発し、初期バージョンのシステムを本番環境に投入することができた。また、大規模なインフラ（基盤となるシステム）を構築することなく、小規模なチームでもIDPのような高度なシステムを試すことができた点も大きい。つまり、BDAは開発初期の段階でプロジェクトを加速させるためのツールとして非常に有効に機能した。重要なのは、BDAのような便利なツールがいつ、どのような状況で最も効果を発揮するのか、そしていつ他のより適切な解決策に切り替えるべきかを見極めることだ。

約3ヶ月間のBDA利用を通じて得られた主な教訓は三つあった。一つは、プロンプトを使って作成したブループリントは、どんな場合でも「ドキュメント」として扱われるということ。二つ目は、この処理モードの設定を誤ると、予期せぬ高額なコストが発生する可能性があるということ。そして三つ目は、平均30秒という処理速度が、ユーザー体験に悪影響を与える可能性があるということだ。これらの重要な情報は、ツールの公式ドキュメントには明確に記載されていなかったため、実際の運用を通して初めてその影響が明らかになった。この経験は、新しいAIソリューションに対して常に意欲的であると同時に、その利点と欠点、つまりトレードオフを批判的に評価する視点が、AIプロジェクトを率いる上で不可欠であることを強く示している。BDAは確かに価値のあるツールだが、決してどんな問題も解決できる万能薬ではない。技術的な成熟度とは、特定のツールをいつ採用し、いつ他の手段に置き換えるべきかを判断できる能力を指す。この経験は、将来のプロジェクトで同様の落とし穴を避け、より賢明な技術的選択を行うための貴重な示唆となった。