次の方法で共有

Azure でドキュメントの分類を自動化する

Azure Functions
Azure AI Foundry
Azure AI Foundry SDK
Az AI サービス
Azure AI Search
Azure AI Document Intelligence

この記事では、さまざまなドキュメントを処理するアーキテクチャについて説明します。 このアーキテクチャでは、Azure Functions の Durable Functions 機能を使用してパイプラインを実装します。 パイプラインは、ドキュメントの分割、名前付きエンティティ認識 (NER)、分類のために Azure AI ドキュメント インテリジェンスを介してドキュメントを処理します。 取得拡張生成 (RAG) ベースの自然言語処理 (NLP) では、ドキュメントコンテンツとメタデータを使用して関連情報を検索して生成します。

アーキテクチャ

ドキュメントを識別、分類、および検索するためのアーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

Workflow

次のワークフローは、上記のダイアグラムに対応しています。

  1. ユーザーがドキュメント ファイルを Web アプリにアップロードします。 このファイルには、PDF や複数ページのタグ イメージ ファイル形式 (TIFF) ファイルなど、さまざまな種類の複数の埋め込みドキュメントが含まれています。 Azure Blob Storage にはドキュメント ファイル (1a) が格納されます。 パイプライン処理を開始するために、Web アプリは Azure Service Bus キュー (1b) にコマンド メッセージを追加します。

  2. コマンド メッセージにより、Durable Functions によるオーケストレーションがトリガーされます。 メッセージには、処理するドキュメント ファイルの Blob Storage の場所を識別するメタデータが含まれています。 Durable Functions の各インスタンスは、1 つのドキュメント ファイルのみを処理します。

  3. 分析アクティビティ関数は、処理するドキュメント ファイルの保存場所を渡すドキュメント インテリジェンス分析ドキュメント API を呼び出します。 analyze 関数はドキュメント ファイル内の各ドキュメントを読み取って識別します。 この関数は、各埋め込みドキュメントの名前、型、ページ範囲、およびコンテンツをオーケストレーションに返します。

  4. metadata store アクティビティ関数では、各ドキュメントのドキュメントの種類、場所、ページ範囲の情報を Azure Cosmos DB ストアに保存します。

  5. 埋め込み アクティビティ関数は、セマンティック カーネルを使用して各ドキュメントをチャンクし、各チャンクの埋め込みを作成します。 この関数は、埋め込みと関連するコンテンツを Azure AI Search に送信し、ベクター対応インデックスに格納します。 また、この関数は、検索結果が Azure Cosmos DB の対応するドキュメント メタデータと一致するように、関連付け ID を検索ドキュメントに追加します。

  6. セマンティック カーネルは、NLP の AI 検索ベクター ストアから埋め込みを取得します。

  7. ユーザーは、NLP を使用してデータとチャットできます。 ベクター ストアから取得されたグラウンド データは、この会話に力を発揮します。 Azure Cosmos DB でドキュメント レコードを検索するために、ユーザーは検索結果セットに含まれる関連付け ID を使用します。 レコードには、Blob Storage の元のドキュメント ファイルへのリンクが含まれています。

コンポーネント

  • Durable Functions は、サーバーレス コンピューティング環境でステートフル関数を記述するのに使用できる Azure Functions の機能です。 このアーキテクチャでは、Service Bus キュー内のメッセージによって永続的な関数インスタンスがトリガーされます。 このインスタンスは、ドキュメント処理パイプラインを開始して調整します。

  • Azure Cosmos DB は、任意の数の地理的リージョンにわたってスループットとストレージ容量をスケーリングできる、グローバルに分散された複数モデルのデータベースです。 包括的なサービス レベル アグリーメント (SLA) により、スループット、待機時間、可用性、一貫性が保証されます。 このアーキテクチャでは、Azure Cosmos DB はドキュメント分類情報のメタデータ ストアとして機能します。

  • Azure Storage は、データ、アプリ、ワークロード用のスケーラブルで安全なクラウド サービスのセットです。 これには、 Blob Storage、 Azure Files、 Azure Table Storage、 Azure Queue Storage が含まれます。 このアーキテクチャでは、Blob Storage は、ユーザーがアップロードし、永続関数パイプラインが処理するドキュメント ファイルを格納します。

  • Service Bus は、メッセージ キュー とパブリッシュ/サブスクライブ トピックを持つマネージド エンタープライズ メッセージ ブローカーです。 このアーキテクチャでは、Service Bus によって永続的な関数インスタンスがトリガーされます。

  • Azure App Service には、Web アプリの構築、デプロイ、およびスケーリングを行うためのフレームワークが用意されています。 App Service の Web Apps 機能は、Web アプリケーション、REST API、モバイル バックエンドをホストする HTTP ベースのツールです。 Web Apps を使用して、.NET、.NET Core、Java、Ruby、Node.js、PHP、または Python で開発できます。 アプリケーションは、Windows ベースおよび Linux ベースの環境で実行およびスケーリングできます。 このアーキテクチャでは、ユーザーは App Service でホストされる Web アプリを介してドキュメント処理システムを操作します。

  • ドキュメント インテリジェンス は、ドキュメント、フォーム、画像から分析情報を抽出するサービスです。 このアーキテクチャでは、ドキュメント インテリジェンスを使用してドキュメント ファイルを分析し、コンテンツとメタデータ情報と共に埋め込みドキュメントを抽出します。

  • AI Search は、Web、モバイル、エンタープライズ アプリケーションのプライベートで多様なコンテンツの検索エクスペリエンスを提供します。 このアーキテクチャでは、ユーザーが NLP を使用してドキュメントを検索および取得できるように、抽出されたドキュメントコンテンツとメタデータ情報の埋め込みインデックスが AI Search ベクター ストレージ によって作成されます。

  • セマンティック カーネル は、大規模な言語モデル (LLM) をアプリケーションに統合するフレームワークです。 このアーキテクチャでは、セマンティック カーネルは、AI Search に格納されるドキュメントコンテンツとメタデータ情報の埋め込みを作成します。

  • Microsoft Foundry は、AI ソリューションとサービスとしてのモデル (MaaS) の構築、テスト、デプロイに使用するプラットフォームです。 このアーキテクチャでは、Foundry によって Azure OpenAI モデルがデプロイされます。

    • Foundry プロジェクト は、データ ソースへの接続の確立、エージェントの定義、デプロイされたモデル (Azure OpenAI モデルを含む) の呼び出しに使用できる特殊なワークスペースです。 このアーキテクチャには、Foundry アカウント内に 1 つの Foundry プロジェクトがあります。

    • Foundry Models は、Microsoft がホストする環境で Azure AI カタログから、OpenAI モデルを含むフラグシップ モデルをデプロイするプラットフォームです。 この方法では、MaaS デプロイを使用します。 このアーキテクチャでは、固定クォータで Global Standard 構成を使用してモデルをデプロイします。

代替

  • グローバル配布を容易にするために、このソリューションでは Azure Cosmos DB にメタデータを格納します。 Azure SQL Database は、ドキュメントのメタデータと情報を永続的に保存するためのもう 1 つのオプションです。

  • 永続的な関数インスタンスをトリガーするには、Azure Event Grid など、他のメッセージング プラットフォームを使用できます。

  • セマンティック カーネルの代わりに、 Azure Machine Learning または Azure AI サービス を使用して埋め込みを作成できます。

  • セマンティック カーネルの代わりに Microsoft Agent Framework を使用して、ワークフローを調整できます。

  • ユーザーに自然言語インターフェイスを提供するには、Foundry 内で他の言語モデルを使用できます。 このプラットフォームは、Mistral、Meta、Cohere、Hugging Face など、さまざまなプロバイダーのさまざまなモデルをサポートしています。

シナリオの詳細

このアーキテクチャでは、パイプラインがドキュメント ファイル内のドキュメントを識別し、種類別に分類し、後続の処理で使用する情報を格納します。

多くの企業は、一括スキャンするドキュメントを管理および処理する必要があり、PDF や複数ページの TIFF イメージなど、いくつかの異なる種類のドキュメントが含まれています。 これらのドキュメントは通常、組織外部からのものであり、受け取った会社は形式を管理していません。

これらの制約により、組織はカスタム テクノロジと手動プロセスを含めることができる独自のドキュメント解析ソリューションを構築する必要があります。 たとえば、他のユーザーが手動で個々のドキュメントの種類を分離し、ドキュメントの種類ごとに分類修飾子を追加する場合があります。

これらのカスタム ソリューションの多くは、ステート マシンのワークフロー パターンに基づいています。 このソリューションでは、データベース システムを使用してワークフローの状態を保持し、処理する必要がある状態を確認するポーリング サービスを使用します。 これらのソリューションを維持および強化すると、複雑さと労力が増える可能性があります。

組織では、組織のドキュメント タイプの識別と分類を処理および管理するための、信頼性が高く、スケーラブルで回復力のあるソリューションを求めています。 このソリューションでは、毎日何百万ものドキュメントを処理でき、処理パイプラインの成功または失敗を完全に監視することができます。

NLP を使用すると、ユーザーは会話形式でシステムと対話できます。 ユーザーはドキュメントに関する質問をしたり、ドキュメントの内容に基づいて回答を受け取ることができます。

考えられるユース ケース

  • レポート タイトルを生成します。 多くの政府機関や自治体は、デジタル形式ではない紙の記録を管理しています。 効果的な自動化ソリューションでは、ドキュメント要求を満たすために必要なすべてのドキュメントを含むファイルを生成できます。

  • メンテナンス レコードの管理: 航空機、機関車、機械のメンテナンス 記録などの紙の記録をスキャンして外部の組織に送信します。

  • 許可の処理: 市区町村および郡の許可部門は、許可検査レポート用に生成される紙文書を保持しています。 複数の検査ドキュメントを撮影し、これらの記録全体を自動的に識別、分類、検索できます。

  • Planograms を分析します。 小売および消費者向け製品の企業は、店舗棚のプラノグラム分析を通じて在庫とコンプライアンスを管理します。 店舗棚の写真を撮り、さまざまな製品からラベル情報を抽出して、製品情報を自動的に識別、分類、定量化することができます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

[信頼性]

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

Azure でホストされている OpenAI モデルを使用する Foundry プロジェクトからモデルを呼び出すときの信頼性と高可用性を確保するには、 Azure API Management などの生成 API ゲートウェイの使用を検討してください。 このアプローチでは、複数のモデル デプロイまたは Foundry エンドポイント間の要求を管理します。 Azure バックエンド ゲートウェイは、デプロイ間でのラウンド ロビン、重み付け、および優先順位ベースのルーティングをサポートし、トラフィック分散を完全に制御します。 このアプローチにより、Foundry プロジェクトでは、パフォーマンス、リージョンの可用性、またはコストの要件に合わせて調整された回復力のあるフェールオーバー戦略とインテリジェントな負荷分散を実装できます。

学習と早期の概念実証作業には、 Global Standard デプロイを使用します。 Global Standard は従量課金制であり、最高の既定のクォータを提供し、Azure グローバル インフラストラクチャを使用して各要求を最も利用可能なリージョンにルーティングします。 このアプローチにより、実験中にリージョンのクォータまたは容量の制約が発生する可能性が減少し、既定の開始点として Global Standard を使用するための Microsoft ガイダンスに準拠します。

運用ワークロードの場合は、次の条件に基づいて デプロイの種類 を選択します。

  • データ処理の場所:

    • Microsoft Foundry リージョンで最も高い可用性と推論を行いたい場合は、 Global Standard または Global Provisioned を使用します。一方、保存データは選択した地域に残ります。

    • データ所在地の要件を満たすために、Microsoft が定義したデータ ゾーン (米国のみ、EU のみなど) 内で推論を続ける必要がある場合は、 Data Zone Standard または Data Zone Provisioned を使用します。

  • スループットとコスト モデル:

    • 低〜中程度の負荷、バースト性のある負荷、または探索的な負荷には、Global Standard、Data Zone Standard、Regional Standard などの標準的なデプロイタイプを使用します。 これらの種類では、予約容量のない従量課金制モデルが使用されます。 トラフィック パターンを理解する前に、これらの種類を初期段階で選択してください。

    • 予約済みスループット、一貫性のある待機時間、コスト最適化のために予約を使用するオプションを必要とする予測可能でボリュームの高いワークロードには、グローバル プロビジョニング済み、 データ ゾーン プロビジョニング済み、リージョン プロビジョニングなどのプロビジョニング済みデプロイの種類 を使用します。

ほとんどのチームは、開発のために Global Standard から始まります。または、データ所在地が重要な場合は Data Zone Standard を使用します。 安定した状態のスループットと待機時間の要件を決定した後、重要なパスを プロビジョニング済み SKU に移動します。

ソリューション コンポーネントの信頼性の詳細については、 Azure オンライン サービスの SLA 情報を参照してください。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

このアーキテクチャの最も重要なコストには、次のコンポーネントが含まれます。

  • OpenAI またはその他のモデルを含む Microsoft Foundry を使用したモデル推論の使用
  • ドキュメント インテリジェンスを使用したドキュメントの取り込みと処理
  • AI 検索を使用したインデックス作成と検索の使用

コストを最適化するには、次の推奨事項を検討してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

このソリューションでは、大量のデータを処理するときにパフォーマンスのボトルネックが明らかになる可能性があります。 ソリューションの適切なパフォーマンス効率を確保するために、 Azure Functions のスケーリング オプション、 AI サービスの自動スケーリング、 Azure Cosmos DB のパーティション分割について理解し、計画します。

これらのプラクティスを適用して、ソリューションのスケーリングに合わせてドキュメント分類ソリューションの応答性とコスト効率を維持します。

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパル作成者:

その他の共同作成者:

  • Brian Swiger |プリンシパル ソリューション エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

次の記事では、関連するテクノロジの概要について説明します。

製品ドキュメントについては、次のリソースを参照してください。