【ITニュース解説】Lessons Learned with AWS Bedrock Data Automation in an IDP Product

このニュース記事は、金融技術（FinTech）企業でAI技術のリーダーを務めるエンジニアが、新しいAIサービスであるAWS Bedrock Data Automation（BDA）を使って開発した経験から得られた教訓について語るものだ。彼らは、支払い領収書という画像やPDFのデータから、金額や日付などの構造化された情報、つまりコンピューターが扱いやすい形で情報を自動的に抽出する「インテリジェントドキュメント処理（IDP）」という製品を開発していた。IDPは、大量の書類から必要な情報を効率よく読み取るためのシステムだ。この開発を早く進めるために、彼らはBDAの利用を決めた。

BDAは、アマゾンウェブサービス（AWS）が提供するクラウドサービスで、ドキュメントや画像から特定のデータを自動的に取り出すことを目的としている。BDAの重要な機能の一つに「ブループリント」の作成がある。これは、どの情報をどのように抽出し、どのように整形するかを定義する設計図のようなものだ。ブループリントの作成方法には二つあった。一つは「JSON Schema」と呼ばれる、データ構造をコンピューターが理解しやすい形式で手動で記述する方法。もう一つは、自然言語、つまり私たちが日常使う言葉で抽出したいフィールド（項目）とその処理方法を指示するだけで、自動的にブループリントが作成される方法だ。後者の自動生成は、非常に手軽で魅力的であり、開発チームはすぐにこの方法で promising な（将来性のある）結果を得られたため、この自動生成の道を選んだ。開発当初は、すべてが順調に進んでいるように見え、製品も本番環境で稼働し、データの抽出も問題なく行われていた。しかし、ある時予期せぬコストの異常に気づき、システムを詳しく分析した結果、開発段階では見過ごされていたいくつかの問題点が明らかになった。

一つ目の問題点は、プロンプト、つまり自然言語で作成したブループリントは、元のデータが画像であっても、常に「Document（書類）」タイプとして分類されてしまうことだった。開発やテストの段階では、この特徴が抽出の精度に影響を与えなかったため、特に注目されなかった。しかし、この見過ごされた特徴が、後になってコストの増大という形で大きな問題となって現れた。

二つ目の問題は、この誤った「モダリティ」の認識が、最終的に会社の財政に大きな影響を与えたことだ。BDAには「モダリティルーティング」という機能があり、入力されたファイルがドキュメントとして処理されるべきか、画像として処理されるべきかを判断し、適切な処理経路に振り分ける。この設定は、コストに直接的に影響する重要なものだった。具体的には、ドキュメントとして処理される場合は1ページあたり0.040米ドル、画像として処理される場合は1枚あたり0.005米ドルと、画像処理の方が圧倒的に安価に設定されていた。しかし、前述の通り、プロンプトで自動生成されたブループリントはすべてドキュメントタイプとして扱われてしまったため、実際には画像である領収書データもドキュメント料金で処理されていた。初期のテストではこの違いに気づかなかったが、8月には約1,000米ドルという予期せぬ追加費用が発生していることが判明した。原因を調査した結果、自動生成されたブループリントが画像のモダリティ（形式）を正しく認識していなかったことが判明した。この問題を解決するためには、開発チームはブループリントをJSON Schemaを使って手動で再作成し、ドキュメントと画像それぞれの正しいモダリティを設定し、ルーティング機能を有効にする必要があった。エンジニア自身も、この挙動をもっと早く検証すべきだったと反省しているが、AWSのドキュメントがこの制限を明確に示していなかったことも、このような高額な間違いにつながる一因だったと指摘している。

三つ目の問題は、処理にかかる時間、つまり「レイテンシー」だった。BDAの各処理プロセスは平均して約30秒もかかっていた。システム全体の設計としては、非同期、つまり複数の処理を同時に並行して進めるイベント駆動型（特定のイベントをきっかけに処理を実行する方式）の流れで構築されていたため、バックエンドシステムはこの遅延を管理することができた。しかし、ユーザーの視点から見ると、顧客が領収書をアップロードしてから結果が表示されるまでに30秒も待たされるのは、非常に長く感じられ、ユーザー体験を著しく損なうものだった。この問題に対処するため、アプリケーションの改修が必要となったが、当然ながら彼らは代替となるソリューションも比較検討した。その結果、AWSのTextract（画像やPDFからテキストやデータを抽出するサービス）と大規模言語モデル（LLM）を組み合わせたパイプラインや、OCR（光学文字認識）技術と後処理を組み合わせた方法などの方が、同様の結果をより低いレイテンシーとほぼ同等のコストで実現できるケースがあることもわかった。

しかし、これらの課題があったにもかかわらず、BDAにはいくつかの明確な利点も存在した。一つは、IDPパイプラインをゼロから構築する際の複雑さを抽象化、つまり見えないようにしてくれた点だ。これにより、開発者は詳細なインフラ構築に時間を割くことなく、本質的な部分に集中できた。二つ目は、初期のデリバリーが迅速に行えたことだ。BDAのおかげで、動くプロトタイプを素早く展開することができた。そして三つ目は、IDP技術を導入するためのハードルが低くなったことだ。これにより、大規模なインフラ投資ができない小規模なチームでも、IDP技術を試すことが可能になった。今回のケースでは、BDAが初期段階の開発を加速させる「アクセラレーター」として機能したことは間違いなく、これなしでは最初のバージョンのリリースにはもっと時間がかかっただろう。重要な教訓は、BDAのようなサービスをいつ活用し、いつ代替のアプローチがより効果的になるかを見極めることにある。

このAWS Bedrock Data Automationを3ヶ月間使用した結果、彼らが得た主な教訓は次の3点に集約される。プロンプトで作成したブループリントは常にDocumentタイプとして認識されること、モダリティ設定の誤りが予期せぬ大きなコスト超過につながること、そして平均30秒という処理の遅延がユーザー体験を著しく損なうことだった。これらの重要な問題点は、AWSの公式ドキュメントには明確に記載されておらず、実際の運用環境で使ってみて初めて明らかになったものだ。この経験は、AI技術をリードする立場において、新しいソリューションへの熱意だけではなく、そのメリットとデメリット、つまりトレードオフを慎重に比較検討する批判的な思考がいかに重要であるかを改めて教えてくれる。BDAは確かに価値のあるサービスだが、決して万能な解決策ではない。いつこのサービスを採用し、そしていつより適切な代替手段に切り替えるべきかを見極めることこそが、技術的な成熟度を示す一部だと言えるだろう。彼は今後も金融分野でのAIプロジェクトの舞台裏について経験を共有していく予定であり、これらの洞察が他の開発者たちが同様の落とし穴を避け、より情報に基づいた意思決定をする一助となることを願っている。