インテリジェントドキュメント処理のためのスキーマ生成自動化

インテリジェントドキュメント処理（IDP）の手法を用いて文書から情報を抽出するには、まず各文書クラスに対して何を抽出するかを定義するスキーマが必要です。しかし、数千もの文書があり、どのようなクラスが存在するかさえわからない場合に、どのようにしてスキーマを作成すればよいのでしょうか？これを大規模に実行しようとすると多大な手作業が必要となり、その後の IDP 取り組みの正当性を説明することが困難になります。 本記事では、当社のマルチドキュメント発見機能がこの問題をどのように解決するかをご紹介します。これは自動化された前処理ステップとして機能し、未知の文書を分析してタイプ別にクラスタリングし、[IDP Accelerator](https://aws.amazon.com/blogs/machine-learning/accelerate-intelligent-document-processing-with-generative-ai-on-aws/) で使用可能なスキーマを生成します。新しい機能では、自動クラスタリングにビジュアルエンベディング（視覚的埋め込み）を、スキーマ生成にはエージェントを活用する方法について解説します。また、ご自身の文書コレクションでこのソリューションを実行する手順もご案内します。 ## IDP アクセラレーター [IDP Accelerator](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws) は、ドキュメントの自動処理と情報抽出のためのスケーラブルでサーバーレスなオープンソースソリューションです。このソリューションを特定のドキュメントタイプに合わせてカスタマイズするには、クラスとフィールドを指定する [設定ファイル](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/configuration.md) が必要です。最小限の設定例については、IDP Accelerator の [GitHub リポジトリ](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/configuration.md#minimal-configuration-example) を参照してください。 ドキュメントタイプを十分に理解していない場合、このスキーマを作成するのは困難です。IDP Accelerator には [ディスカバリーモジュール](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/discovery.md) が含まれており、単一のサンプルドキュメントからクラス設定を初期化できます。ただし、すでにドキュメントクラスを知っており、各クラスに対して代表的なサンプルドキュメントを特定できる必要があります。本記事で紹介するマルチドキュメントディスカバリー機能は、この前提条件を取り除き、ラベル付けされていないドキュメントコレクションに IDP Accelerator を適用するための道のりを加速します。 ## ソリューション概要 以下の動画は、IDP Accelerator コンソールにおけるソリューションを示しています。 多文書発見機能は、分類されていないドキュメントコレクションを、下流の IDP イニシアチブに備えた構造化されたスキーマへ自動的に変換します。このソリューションは、IDP アクセラレータの既存の Discovery モジュールに統合されています。これは、「単一ドキュメント」発見機能に並ぶ新しい「複数ドキュメント」機能です。オーケストレーションとサーバーレスコンピューティングには、[AWS Step Functions](https://aws.amazon.com/step-functions/) ステートマシンと [AWS Lambda](https://aws.amazon.com/lambda/) 関数が提供されます。このソリューションは、[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) バケットまたは Zip ファイルのアップロードからドキュメントを処理します。[Amazon Bedrock](https://aws.amazon.com/bedrock/) を通じて利用可能なモデルがスキーマを生成し、自動的に IDP Accelerator 設定ファイルに統合されます。以下の図は完全なワークフローを示しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-2.png) 発見ジョブは、[Amazon S3](https://aws.amazon.com/s3/) 内の各ドキュメントを [Amazon Bedrock](https://aws.amazon.com/bedrock/) で利用可能な埋め込みモデルを使用してベクトル埋め込みに変換することから始まり、類似するドキュメントをクラスタリングします。[Strands Agents](https://strandsagents.com/) と Amazon Bedrock の大規模言語モデル（LLM）で構築されたエージェントが各クラスタを分析し、ドキュメントの種類を特定してスキーマを生成します。最後に、リフレクションステップでスキーマを相互にレビューし、最終的な確認前に重複や不整合を検出します。 ## 技術詳細 プロセスの各ステップを順を追って説明し、重要な意思決定と実装の詳細について解説します。 ## 埋め込み生成 このワークフローでは、各ドキュメントに対して埋め込みを作成し、視覚的特徴を数値表現に変換します。多ページドキュメントの場合、最初のページのみが使用されます。現在、このワークフローは OCR ベースのテキストではなく視覚的埋め込みを使用しています。これは、テキストコンテンツが類似している場合でも、ドキュメントの種類を区別するレイアウト、書式、構造的な手がかりを視覚的埋め込みが捉えることができるためです。本ソリューションでは、発見ジョブのデフォルト埋め込みモデルとして [Cohere Embed v4](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-embed-v4.html) を Amazon Bedrock 経由で使用しています。埋め込みステップは、画像圧縮、リトライロジック、レート制限といった一般的な課題や障害を自動的に処理します。 ## ドキュメントクラスタリング マルチドキュメント発見機能は、[シルエットスコア](https://en.wikipedia.org/wiki/Silhouette_(clustering)) を用いて、コレクション内に存在するドキュメントタイプの数を学習します。この文脈において、シルエットスコアはクラスター間の分離度合いと、各クラスター内のドキュメントの凝集度を測る指標として機能します。k-means クラスタリング（k-means clustering）を用いて、エージェントはデフォルトで k 値を 2 から 20 の範囲でテストし、最も高いシルエットスコアを示すグループ化を選択します。ここで k は、コレクション内の異なるドキュメントタイプの数を表します。意味のあるクラスターを作成するためには、各クラスターに少なくとも 2 つのドキュメントが含まれている必要があります。必要に応じて、この制約を満たすために k の上限値は 20 よりも低い値に引き下げられます。 ## エンベディングとクラスタリングの評価 エンベディングおよびクラスタリングのアプローチを検証するため、[OCR-benchmark データセット](https://huggingface.co/datasets/getomni-ai/ocr-benchmark) のテストセットバケットに含まれるサブセットに対して、Cohere Embed v4 を用いた実験を行いました。このバケット名を確認するには、CloudFormation コンソールにアクセスし、IDP Accelerator スack を選択して「Outputs」タブを開き、「S3TestSetBucketName」というキーを探してください。 このデータセットは単一ページのドキュメントタイプで構成されています。デプロイされたサブセットには、9 つのドキュメントタイプ（銀行小切手、商業賃貸借契約書、クレジットカード明細書、配送伝票、機器点検記録、用語集、請願書フォーム、不動産関連書類、シフトスケジュール）にわたる 293 ドキュメントが含まれています。 Cohere 埋め込みモデルを使用して、k-means クラスタリングがこれらのグループを正しく識別できるかを評価するために、最適な k 値を選択するための指標としてシルエットスコア（silhouette score）を検証しました。パイプラインの最初の 2 つの段階（埋め込みとクラスタリング）を実行し、k 値が 2 から 20 の範囲にわたるシルエットスコアを分析しました。以下のプロットは、これらの k 値におけるシルエットスコアの分布を示しています。最も高いシルエットスコアは k=9 で得られ、これはデータセット内の文書タイプの真の値（ground truth）と一致します。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-3.png) TSNE プロット（t-distributed Stochastic Neighbor Embedding plot、高次元データを 2 次元空間に圧縮しつつデータ点間の関係を保持する可視化手法）は、これらの埋め込みを 2 次元空間で可視化したものであり、クラスタ分類の結果は凡例に表示されています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-4.png) クラスタリングは、調整兰德指数（ARI）と正規化相互情報量（NMI）においてともに 1.0 という完璧な値を達成しました。ARI はクラスタリングが真のグループ分けとどれだけ一致しているかを測定する指標であり、NMI は予測されたクラスタと実際のクラスタの間で共有される情報の量を定量化するものです。すべてのクラスタは、100% の純度をもって、真の文書クラスと 1 対 1 で対応しています。これらの結果は、高品質なマルチモーダル埋め込みが、教師なしでの文書分類を可能にすることを示しています。これらの埋め込みは、ラベル付き学習データを用いずに、銀行小切手、不動産書類、クレジットカード明細など多様な文書タイプを正確に分離します。 **注:** このベンチマークデータセットにおけるパフォーマンスが、特定の文書データにおいても同様の結果を保証するものではありません。なぜなら、データセットの特性が結果の品質に直接影響を与えるからです。 ## エージェント型スキーマ生成 クラスタが特定された後、パイプラインはエージェントフェーズに入ります。各クラスタに対して [Strands Agent](https://strandsagents.com/latest/) が呼び出され、ドキュメントタイプの判定とスキーマの生成が行われます。モデル駆動アプローチを採用した Strands Agents を選定しました。これにより、モデルが各スキーマを自律的に推論する柔軟性が得られます。エージェントは、スキーマを生成する前にクラスタ内のさまざまな場所でドキュメントを戦略的に可視化し、多様性を十分に把握する必要があります。具体的には、中心付近のドキュメント 1 つ、周辺部のドキュメント 1 つ、そして中間距離にあるドキュメント 1 つを検査します。より決定論的で固定されたサンプリングアプローチではここでの要件を満たすことはできません。なぜなら、クラスタリングの品質は特定のドキュメントに大きく依存するためです。これを実現するために、エージェントには 2 つの専門ツールが用意されています。 - クラスタ分析ツール – クラスタ中心からの距離順に並べられたドキュメント ID を取得し、エージェントがクラスタ内の多様性の範囲全体を戦略的にサンプリングできるようにします。 - ドキュメントビューアツール – ドキュメント画像を取得・圧縮して視覚的な検査を可能にし、モデルのコンテキストウィンドウに対するサイズ制約を自動的に処理します。 エージェントのシステムプロンプトには、JSON Schema の慣習および [IDP Accelerator 設定](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/tree/main/config_library) の要件に関するドメイン専門知識が組み込まれています。このプロンプトはエージェントに対して以下を指示します。 翻訳全文 - 十分なカバレッジがあると確信できる場合は、戦略的にサンプルドキュメントを選択し、早期に停止する。 - 適切なメタデータ、型定義、および説明を含む JSON スキーマを生成する。 - x-aws-idp-document-type や x-aws-idp-evaluation-method など、IDP Accelerator 固有のアノテーションを含める。x-aws-idp-evaluation-method は、Stickler ベースの評価拡張機能によって使用される。 - 住所、行項目、税情報などの一般的な構造に対して再利用可能な $defs を作成する。 - フィールドのタイプに基づいて適切な評価方法を適用する：文字列には EXACT、数値には NUMERIC_EXACT、複雑なまたはネストされたオブジェクトには LLM を使用する。 これらのツール、プロンプト、およびモデルは、エージェントが自身のサンプリング戦略について推論する能力を備えるように装備している。これらのエージェントは並列で実行されるため、次のクラスターを開始する前に各クラスターの完了を待つ必要はない。 ## スキーマ分析 各エージェントが独立してスキーマを生成した後、スキーマ分析ステップでは出力間の全体的な差異性を評価します。発見されたドキュメントのグループ分けが明確に分離されているか、それとも重複しているかを検証し、生成されたスキーマが完全かつ一貫性があるかも確認します。また、ドキュメントタイプ間での冗長性や重複がないかも調査します。これらの知見に基づき、クラスタの統合やフィールド定義の精緻化など、具体的な推奨事項を提示します。さらに、クラスに関する人間が読みやすい概要を含むサマリーレポートを生成します。この品質レポートは、IDP Accelerator の Discovery Job 詳細画面で確認可能です。 ## ドキュメントでのジョブ実行 ご自身のドキュメントに対してマルチドキュメント発見ワークフローを実行するには、IDP Accelerator コンソールで以下の手順に従ってください。 **ステップ 1: 新しい設定の作成** まず、IDP Accelerator コンソールで新しい設定を作成します: - 「Configuration」セクションに移動し、「View/Edit Configuration」を選択します。 - 「Document Schema」>「Wipe All」を選択して、新しい空の設定を作成します。 - 「Save as Version」を選択し、説明的なバージョン名を入力した後、再度「Save as Version」を選択します。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-5.png) **ステップ 2: マルチドキュメント発見の実行** 設定が準備できたら、発見プロセスを開始します: - Discovery セクションに移動し、[Multiple Documents] オプションを選択します。 - 先ほど作成した構成バージョンを選択します。 - ドキュメントソースを設定します: [S3 Path] または [Zip Upload] のいずれかを選択してください。 - ソースバケットを選択します。 - ドキュメントが保存されている S3 プレフィックスを指定します。 **注:** Source Bucket オプションを使用するには、ドキュメントを IDP Accelerator の既存のバケット（Discovery Bucket、Test Bucket、または Input Bucket）のいずれかに追加する必要があります。 - [Start Discovery] を選択してステートマシンを開始します。 ## **ステップ 3: 発見ジョブの監視と結果の確認** 発見ジョブの進行状況を追跡します: - [Multi-Document Discovery Jobs] テーブルに、実行ステータス、現在のステップ、メタデータを示す新しいエントリが表示されます。 - ジョブが完了したら、[Source] フィールドを選択して結果を表示します: ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-7.png) - Discovery Job Details の下部にスクロールして、Quality Report にアクセスします: ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/01/ml-20447-8.png) 発見されたクラスとその JSON スキーマは、自動的に構成ファイルに統合されます。 ## Best practices for optimal results スケーリングされたマルチドキュメント発見ジョブを実行する前に、念頭に置いておくべきいくつかのベストプラクティスがあります。現在のワークフローは各 PDF の最初のページのみを処理するため、入力ファイルが単一ドキュメントファイルであることを確認してください。複数ドキュメントのパケットはまだサポートされていません。初期結果を取得した後、スキーマを確定する前に、重複するクラスターや不均等なドキュメント分布といった問題を見逃さないよう、品質レポートのサマリーを徹底的にレビューしてください。 ## Next steps ここから進むべき道は、ワークフローが文書内で発見した内容によって異なります: - スキーマがクリーンで、品質レポートで重複率が低い場合: 文書に対して IDP をスケーリングして実行する準備が整いました。スキーマは自動的に IDP Accelerator の設定における classes フィールドに追加されます。 - 品質レポートで重複クラスターが警告された場合: レコメンデーションを確認し、それらを使用して生成されたスキーマを精緻化してください。これには、類似したスキーマを単一のクラスターに統合するか、重複を減らすためにフィールド定義を調整することが含まれる可能性があります。 - クラスター間でスキーマの品質が不均一な場合: ドキュメントコレクション内にドキュメントタイプの分布が極端に偏っていないか確認してください。よりバランスの取れたサブセットに対して発見ジョブを実行することで、エージェントがより信頼性の高いクラスターとスキーマを生成できるようになります。 ## 結論 本記事では、ドキュメントを処理する前にスキーマが必要であるという課題と、スキーマを構築する前にドキュメントを処理する必要があるという課題を解決するマルチドキュメント発見機能についてご紹介しました。このソリューションは、ビジュアル埋め込み（visual embeddings）、自動クラスタリング、そして多モーダル大規模言語モデル（LLM）を用いたエージェント型スキーマ生成を組み合わせたものです。これにより、不明な文書の不透明なコレクションを、構造化されレビュー可能なドキュメントクラスおよびスキーマへと変換します。埋め込みの生成、クラスタの調整、並列分類とスキーマ生成のワークフロー処理方法をご覧いただいたことでしょう。また、リフレクションステップが、エージェントによって生成された出力に対する人間によるレビューのための透明な分析を提供する方法もご覧いただきました。 マルチドキュメント発見機能がお客様のドキュメントコレクションでどのように機能するか、ぜひお聞かせください。結果や質問、ご提案をコメント欄でお知らせください。

インテリジェントドキュメント処理のためのスキーマ生成自動化

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

調べる

選ぶ

サイト