リコーがAWS上で構築したスケーラブルなインテリジェント文書処理ソリューション

*この投稿は、リコーのジェレミー・ジャクソンとラド・フルェックによる共著です。* 本稿では、生成 AI、サーバーレスアーキテクチャ、標準化されたフレームワークを組み合わせることで、企業が文書処理のスケーリング限界をどのように克服できるかを示します。リコーは [AWS GenAI インテリジェントドキュメントプロセッシング (IDP) アクセラレータ](http://www.amazon.com/genai-idp-accelerator) を用いて、反復可能で再利用可能なフレームワークを構築しました。このフレームワークにより、顧客のオンボーディング期間が数週間から数日へと短縮されました。また、複雑な文書分割を必要とする新しい AI 集約型ワークフローの処理能力も向上し、その容量は月間 70,000 ドキュメントを超えるまで 7 倍に拡大すると見込まれています。さらに、各デプロイにかかるエンジニアリング時間は 90% 以上削減されました。 リコー・USA インクは、200 カ国以上にわたる多様な顧客基盤にサービスを提供するグローバルな技術リーダーです。そのヘルスケア分野では、主要な健康保険給付者、管理型医療組織、および医療提供者を対象としており、毎月数十万件の重要な文書（保険請求、苦情、異議申し立て、臨床記録など）を処理しています。彼らが直面した課題は、ドキュメント中心のワークフローを近代化する企業に共通するものであり、カスタム手動エンジニアリングへの依存でした。新しいヘルスケア顧客ごとの導入には、専門エンジニアによる独自の開発と調整が必要でした。さらに、展開にはカスタムのプロンプトエンジニアリング、モデルのファインチューニング、統合テストが伴い、これらは顧客間で再利用できませんでした。これはリコーの顧客にとって例外的で個別最適化された体験を提供する一方で、要した時間と労力がボトルネックとなり、拡大を制限していました。今後、処理量が 7 倍に増加すると見込まれる中、リコーは革新の機会を捉えました。 課題は単にプロセスを自動化することだけではありませんでした。ドキュメント抽出とエージェント型ワークフローのための最先端 AI を提供できるスケーラブルなソリューションを構築することが求められていました。このソリューションは、HITRUST、HIPAA、SOC II といった厳格なコンプライアンス基準を満たす必要がありました。これらの要件は、急速に進化する AI の革新とは往々にして対立するものです。コンプライアンスフレームワークは通常、モデルのトレーニング能力を制限するデータ共有を規制しています。また、反復的な AI の開発とデプロイに必要な俊敏性を阻害しうる厳格なセキュリティ制御も義務付けています。これらの課題にもかかわらず、リコーは顧客のためにこの緊張関係を克服することを最優先事項としました。[Amazon Bedrock](https://aws.amazon.com/bedrock/) を通じて利用可能なファウンデーションモデル（FMs）を基盤とし、[Amazon Textract](https://aws.amazon.com/textract/) と組み合わせることで、リコーは顧客が厳格なコンプライアンス基準に適合した最先端の自動化の恩恵を受けられるようにしました。 本稿では、AWS GenAI IDP Accelerator を基盤として標準化されたマルチテナント型のドキュメント分類および抽出ソリューションをリコーがどのように構築し、カスタムエンジニアリングによるボトルネックからスケーラブルで反復可能なサービスへとドキュメント処理を変革したかを探ります。 ## カスタマー概要 リコー・アメリカ合衆国法人は、200 以上の国々の組織に対してデジタル職場サービス、文書管理、およびビジネスプロセス自動化ソリューションを提供するグローバルな技術リーダーです。そのヘルスケア分野において、リコーは主要な健康保険給付者、管理型医療機関、および医療提供者にサービスを提供しており、毎月数千件の重要な書類を処理しています。これには保険請求、苦情、異議申し立て、臨床記録などが含まれます。 「リコー・インテリジェント・ビジネスプラットフォーム内では、主要な IDP（Intelligent Document Processing：文書処理）タスクにおいて最も高度な知能を必要とするワークフローが爆発的に成長しました。私たちは、個別の構築からプラットフォームへの移行が必要でした」と、リコーのポートフォリオ・ソリューション開発部門 AI アーキテクトであるジェレミー・ジャクソン氏は述べています。「顧客のために、AI の統合、運用、進化を行うことで、顧客自身が行う必要をなくします。当社の独自 IDP パターンと技術を AWS GenAI IDP アクセラレーター（GenAI：生成型人工知能）に統合することで、この優位性がさらに強化されました。その結果、HITRUST CSF 認証を取得した構成可能な IDP プラットフォームを提供し、顧客を AI の最前線へと結びつけました。」 医療文書は構造化されておらず、非常に多様な形式で届くことが一般的です。1 つの封筒には複数の文書タイプが含まれている可能性があり、ファックスカバーシート、臨床記録、異議申し立てフォームなど、それぞれ異なるレイアウトと命名規則を持っています。文書のページ数は 15〜50 ページに及び、封入されているものもあれば、ないものもあります。また、医療提供者によって文書構造やフィールドの命名規則、重要な情報の配置が異なります。テンプレートベースの抽出アプローチは効果的ではありませんでした。 リコーのインテリジェントビジネスプラットフォームサービスにおける機能要件には、構造化されていないまたは半構造化されたドキュメントのスキャンからデータ属性を抽出し、各データ属性に対して人間のレビューが必要なタイミングを確実に識別できる信頼性の高い自信度（confidence level）を割り当てることが含まれます。事前に定義された閾値未満の自信度を持つすべての属性は、正確性とコンプライアンスの確認のために人間によってレビューされます。人間のレビュアーは抽出されたデータを検証し、誤りを修正し、会員 ID、診断コード、請求金額などの重要な医療情報が規制遵守の整合性および請求処理に必要な品質基準を満たしていることを確認します。このヒューマン・イン・ザ・ループ（human-in-the-loop）アプローチにより、2 つの主要なビジネス成果が達成されます。すなわち、医療給付者が要求する高い精度レベル（通常 98〜99%）を維持しつつ、完全手動処理と比較して人的レビューコストを 60〜70% 削減することです。 本ソリューションは、文書のさまざまなセクションから会員 ID、プロバイダー情報、請求詳細などの主要データを抽出する必要があり、カバーレターに情報が含まれていない場合は臨床ノートやその他のセクションを検索する機能も必要でした。非機能的要件では、以下の重要な運用ニーズに対応しました： - パフォーマンスとスケーラビリティ – トラフィックの急増にも対応し、数分で最大 1,000 件の文書を処理できるようにしつつ、低トラフィック期間には計算リソースの浪費を避けること - 精度と品質 – 納期およびデータ精度に関する厳格なサービスレベル契約（SLA）を満たすこと - コスト最適化 – 正確性の要件と手動レビューコストのバランスを取る設定可能な信頼度閾値を可能にし、合意された SLA を超える誤った属性の捕捉を抑えつつ、高価な人的レビューを最小限に抑えること - 運用効率 – コード変更ではなく設定変更を通じて迅速な顧客オンボーディングを実現すること ## 複雑な文書処理ワークフローにおける課題 ある時期から、リコーチームは、スキャンされた文書からテキストを検出・抽出する従来の光学式文字認識（OCR）と、テキストと画像を同時に理解できるマルチモーダル AI モデルを組み合わせていました。このアプローチにより、複数の名前や住所を含む文書からデータを抽出する際に類似したフィールドを区別するなど、複雑な課題に対処することができました。 Amazon Bedrock でマルチモーダル FMs が利用可能になって間もなく、単純に Amazon Bedrock への API 呼び出しを行うだけでは（つまり、スキャンしたドキュメントとプロンプトを送るだけ）複雑なワークフローには不十分であることがすぐに明らかになりました。ドキュメントがカバーシートや契約書、承認応答など複数の部分やセクションで構成されている場合、抽出ルールはまずそのセクションタイプを正しく分類することに依存することが多いためです。 このソリューションでは、請求書、異議申し立て、メール、ファックスのカバーシートなどを区別する複雑なドキュメント分類を扱いながら、パケットをより細粒度のドキュメントタイプに分解する必要はありませんでした。また、大規模言語モデル（LLM）にはコンテキストウィンドウの制限があり、コンテキストが埋まってくると指示に従う性能が低下するという課題があります。ドキュメントページサイズの制限により、Ricoh チームは大型ドキュメントに対して代替アプローチを採用する必要がありました。 Ricoh チームはまた、既存の高容量ドキュメント処理ワークフロー（ドキュメントルーティングシステム、ケース管理サービス、下流のビジネスアプリケーションなど）との統合を柔軟に行いながら、処理ステップやモデル選択に対する制御権を維持することも必要でした。これには、医療提供者または患者情報に基づいてドキュメントを分割するという独自の要件も含まれていました。 精度を向上させるために、リコーチームはプロンプトに動的にコンテキストを挿入するより洗練された手段を利用しました。これは、処理対象の文書に応じて、関連する文書メタデータ、以前に抽出されたフィールド、および文書構造情報をプログラムによって AI モデルの指示に追加する技術です。この文脈認識型プロンプティングは、静的なプロンプトと比較して抽出精度を 15〜20% 向上させ、モデルが文書間の関係やフィールドの依存関係を理解するのに役立ちました。 これらの成果は顕著なものでしたが、この成功を再現しようとした際、リコーチームは持続的な障壁に直面しました。具体的には、基盤となるモデルの新機能を取り込むなど、顧客ごとに設定に開発者 40〜60 時間が必要だったのです。リコーは、これらのスケーラビリティ課題に対処するため、AWS ジェネレーティブ AI イノベーションセンターと IDP アクセラレーター（IDP Accelerator）で連携しました。 ## ソリューション概要 リコーは AWS と提携し、[GenAI IDP Accelerator](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws) の実装を行いました。これは、本番環境レベルの文書処理ソリューションをデプロイするのを支援するために設計された参照フレームワークです。このアクセラレーターは、異なる文書タイプやワークフローに最適化された複数の処理パターンを提供します。 チームは、テキスト画像を機械可読なテキストに変換する OCR 技術である Amazon Textract と、インテリジェントな分類および抽出を行うための Amazon Bedrock FMs を組み合わせた「処理パターン 2」[Processing Pattern 2](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/pattern-2.md) を選択しました。このパターンは、テキストの抽出と AI による理解の両方を必要とする複雑な多部構成文書のために特に設計されています。このアプローチではモデルのオーケストレーションに対する完全な制御が可能であり、リコーの多部構成医療文書を扱うのに理想的です。なぜなら、分類を先に行い、その結果に基づいて抽出を行うという順次処理をサポートし、一般的な LLM のコンテキストウィンドウを超える文書もセクションごとに処理して対応できるからです。 本ソリューションは、厳格な医療規制への準拠要件に合致するように設計されました。HIPAA 準拠のため、保護対象の個人情報（PHI）は、[AWS Key Management Service](https://aws.amazon.com/kms/) (AWS KMS) を用いて保存時に暗号化され、転送時には TLS 1.2+ で暗号化されます。アクセス制御は最小権限の原則に従い、[AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) ポリシーによってデータへのアクセスを承認された人員にのみ制限しています。 HITRUST 認証要件に対応するため、本アーキテクチャは [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) を通じて包括的な監査ログを実装し、データアクセスおよび処理アクティビティを記録しています。SOC 2 Type II コンプライアンスへの適合は、それぞれ独自の SOC 2 認証を保持する AWS サービスの活用と、変更管理、イベント対応、継続的監視に関するリコーの文書化された運用統制を組み合わせて実現されています。 従量課金モデルにより、アイドル状態のインフラコストが排除されます。リコーは実際のドキュメント処理分のみに対して支払いを行い、非稼働期間中は請求が発生しません。このコスト予測可能性は、異なるドキュメントボリュームを持つ複数の顧客をサポートする上で極めて重要でした。各顧客のコストは使用量に比例してスケーリングするため、固定のインフラ投資を必要としないからです。 文書は [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) を通じて入力され、イベント駆動型のワークフローがトリガーされます。[AWS Lambda](https://aws.amazon.com/lambda/) 関数が Amazon Bedrock モデルを呼び出し、請求書、異議申し立て、ファックス、苦情、事前承認リクエスト、臨床文書などの文書タイプを特定します。Amazon Textract がテキストとレイアウトを解析し、その結果は構造化データ抽出のために Amazon Bedrock モデルと組み合わせられます。各顧客の要件に固有のカスタムビジネスルール（フィールド検証ルール、文書ルーティング基準、データ変換仕様など）が信頼度スコア計算と併用され、どのフィールドが人間のレビューを必要とするかを決定します。 信頼度スコアは、複数のソース（Amazon Textract と Amazon Bedrock）からの抽出結果を比較し、システムが各抽出されたフィールドに対して持つ確信度を表す数値（0〜100%）を割り当てることで計算されます。顧客が定義した閾値（通常 70〜85%）を下回るスコアを持つフィールドは、人間の検証が必要としてフラグ付けされます。最終出力は Amazon S3 に保存され、低信頼度のケースはレビューキューを通じて人間の検証用にルーティングされます。オペレーターはここで抽出されたデータを検証し、誤りを修正し、将来の処理改善のためのフィードバックを提供します。 AWS GenAI IDP Accelerator から提供されるコア [IDP-Common](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/lib/idp_common_pkg/README.md) エンジンは、統合層として機能し、リコーが確立されたワークフローを維持することを支援しました。IDP Common Package は、AWS 上の加速型インテリジェントドキュメント処理ソリューション向けに共有機能を提供する Python ライブラリです。このソリューションは、AI サービスを利用して文書から情報を自動的に抽出・処理することで、企業における手動データ入力を取り除き、精度を向上させることを目的としています。 各顧客への展開は、[AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) (AWS SAM) アプリケーションとして構成可能な形でインスタンス化され、[AWS CloudFormation](https://aws.amazon.com/cloudformation/) スタックとしてデプロイされることで、迅速なオンボーディングを可能にします。これにより、[Amazon Virtual Private Cloud](http://aws.amazon.com/vpc) (Amazon VPC) 設定、セキュリティグループルール、IAM ロールポリシー、およびサービスクォータといったインフラストラクチャの詳細が抽象化され、チームメンバーは Lambda の予約済み並列処理数やデータベース接続詳細など、顧客固有のパラメータにのみ集中できます。この焦点を絞ったアプローチは、新しい顧客のオンボーディングを行う際に特に価値があります。 モジュラー設計により、リコーは顧客定義の独自ドキュメント分類、業界固有フォーム向けのカスタムデータ抽出、個人識別情報（PII）コンプライアンス適合のための赤塗りルールといった特定のパラメータやカスタム機能を、既存の高容量ワークフローに統合することができました。これにより、確立されたプロセスを妨げずに、顧客オンボーディング時間を数週間から数日へと短縮する自動デプロイメントを通じて運用効率を維持しつつ、ドキュメント処理における高度な AI 機能（インテリジェントドキュメント分類や非構造化フォームからの自動化データ抽出など）を追加することが可能になりました。 ## アーキテクチャの詳細 本アーキテクチャは、コード変更ではなく設定による迅速な顧客オンボーディングの支援、医療規制（HIPAA、HITRUST、SOC 2）への準拠の促進、変動するドキュメント量に対するコスト効率の高いスケーラビリティの提供という3つの主要な目的を念頭に設計されました。インフラ管理のオーバーヘッドを排除し、コストを直接使用量に連動させるためサーバーレスアプローチが採用され、マルチテナント設計における顧客ごとのキュー設定により、リソース効率とワークロードの分離が両立しています。Amazon Bedrock 単体ではなく、処理パターン2（Amazon Textract と Amazon Bedrock）を採用した決定は、LLM のコンテキストウィンドウを超えるドキュメントを処理する必要性と、ドキュメントタイプに基づいてプロンプトに選択的に含めることができる構造化テキスト抽出の要件によって導かれました。 実装では、スキャンされたドキュメントが Amazon S3 にアップロードされると自動的に Lambda 関数が呼び出されるサーバーレスアーキテクチャが採用されました。Lambda 関数は AI サービス（Amazon Textract と Amazon Bedrock）への呼び出しを処理し、抽出した属性とその信頼度スコアを [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) データベースへ出力します。 アーキテクチャは、AWS Well-Architected Framework の原則を複数の柱にわたって取り入れています。**セキュリティ**においては、データは AWS KMS を用いて顧客管理キーで保存時に暗号化され、転送時には TLS 1.2+ で暗号化されます。IAM ロールは機能ごとに分離された最小権限アクセスを強制し、文書の取り込み、処理、検索それぞれに別々のロールが設定されています。CloudTrail は監査証跡のために API コールをログ記録し、CloudWatch Logs はセキュリティ監視のためのアプリケーションレベルのイベントをキャプチャします。 **信頼性**においては、サーバーレス設計により単一障害点が排除され、自動リトライとデッドレターキュー（DLQ）が過渡的なエラーを処理します。**パフォーマンス効率**においては、Lambda の並行実行制限と [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (Amazon SQS) のキュースロットリングにより、高いスループットを維持しつつ API クォータの枯渇を防ぎます。**コスト最適化**においては、従量課金モデルによりアイドル状態のリソースのコストが排除され、Amazon S3 のライフサイクルポリシーが処理済みの文書を低コストストレージ階層へ自動的に移行します。 **運用の卓越性**においては、AWS SAM と CloudFormation を用いたインフラストラクチャとしてのコード（IaC）により一貫したデプロイが可能となり、CloudWatch ダッシュボードとアラームが処理メトリクスとエラーレートに関するリアルタイムな可視性を提供します。 アーキテクチャの重要な部分は SQS キューであり、これによりチームは Lambda の並行処理設定と Amazon SQS の可視性タイムアウトを制御することでメッセージ処理速度を調整し、Amazon Textract および Amazon Bedrock API エンドポイントへのリクエスト発行率を制御することが可能になります。この設計により、サービスクォータ制限（例えば、Amazon Textract における 1 秒あたりのトランザクション数や、Amazon Bedrock における 1 分あたりのリクエスト数など）内に収まることが保証されます。さらに、Amazon SQS は自動的に再試行を支援し、未処理のメッセージを DLQ（Dead Letter Queue：デッドレターキュー）へ送信します。 各顧客には独自の [Amazon EventBridge](https://aws.amazon.com/eventbridge/) ルールと SQS キューが割り当てられており、マルチテナント分離を実現しています。これにより、ある顧客からの大量の処理が他の顧客に影響を与えるのを防ぎつつ、独立したスケーリング（顧客ごとの並行処理制限やスループット制御の適用）を可能にします。 このアーキテクチャでは、ドキュメント保存のために Amazon S3 を使用しています。ファックス、スキャン、SFTP システムなど様々なソースからのドキュメントを管理するために、異なるバケットが作成されています。DynamoDB テーブルにはドキュメントのメタデータと処理状態が格納され、ドキュメントのバージョンを追跡して、同一ドキュメントに対する複数の更新試行を防ぐ役割を果たしています。

リコーがAWS上で構築したスケーラブルなインテリジェント文書処理ソリューション

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト