📖

re:Invent 2023: AWSが.NETアプリにAI機能を追加する方法を解説

2023/11/28に公開

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!

📖 AWS re:Invent 2023 - Enrich your .NET applications with AI capabilities (XNT305)

この動画では、.NETアプリケーションにAI機能を簡単に追加する方法を学べます。Amazon TranslateやComprehend、Textract、Rekognitionなどのサービスを使って、インテリジェントな文書処理システムを構築するデモを見ることができます。さらに、Amazon CodeWhispererというAIコーディングアシスタントを使ってコードを生成する様子も紹介されています。MLの専門知識がなくても、数行のコードでAI機能を実装できる魅力的な内容となっています。
https://www.youtube.com/watch?v=I5qdrbi72ho
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。

本編

セッション概要と講演者紹介

Thumbnail 0

本日のセッション、XNT305「.NETアプリケーションにAI機能を追加する」へようこそ。始める前に簡単な質問ですが、ここに.NET開発者の方はどのくらいいらっしゃいますか?素晴らしいですね。.NET開発者の方々、既存の.NETアプリケーションをお持ちの方々に、AWSサービスを使ってAI機能を追加する方法をお見せします。このセッションでは、一連のデモを通じて、エンドツーエンドのインテリジェントドキュメント処理アプリケーションを構築します。単に異なるサービスのデモを見るだけでなく、これらのサービスを使ってエンドツーエンドのアプリケーションを構築する方法をご覧いただけます。

私はAlexander Dragunovで、スウェーデンのストックホルムを拠点としています。私はPrasad Raoで、イギリスのロンドンを拠点としています。私たち二人とも.NET開発者としてキャリアをスタートし、現在はAWSで.NET on AWSに携わっています。それでは始めましょう。

AWSのAI/ML戦略と3層構造

Thumbnail 70

AWSの使命は、人工知能と機械学習に関して長年培ってきた経験と専門知識を、すべての開発者の手に届けることです。言い換えれば、機械学習を簡素化し、開発者がインテリジェントなアプリケーションを簡単に構築できるようにしたいのです。

Thumbnail 90

Thumbnail 110

詳細に入る前に、人工知能と機械学習の重要性を簡単に振り返ってみましょう。IDCによると、2026年までに人工知能への世界的な支出は3,000億ドルに達し、平均的なIT支出の4.2倍のスピードで成長するとされています。 また、Deloitteによると、ビジネスリーダーの94%がAIは自社の成功に不可欠だと考えています。私たちのような開発者にとって、これはML機能を持つアプリケーションの開発が、私たち全員が身につけるべきスキルであることを意味します。

Thumbnail 130

Thumbnail 140

AWSでは、AI/MLを3つの層で考えており、あらゆる層を民主化することで、皆さんとそのチームがAI/MLの採用をより迅速に進められるようにしています。 最下層から始めると、これはML専門家向けで、自らモデルの構築、調整、トレーニング、デプロイを行うことに慣れている人々が、PyTorchやTensorFlowなど、選択したフレームワークでフレームワークとチップレイヤーで作業します。

Thumbnail 160

次に、中央にAmazon SageMakerがあります。Amazon SageMakerは、機械学習ワークフローのあらゆる段階で複雑さを取り除きます。開発者やデータサイエンティストの皆さんが、大規模な機械学習モデルを簡単に構築・デプロイできるようにします。ここで手を挙げて教えていただきたいのですが、.NET開発者として、SageMakerやML基盤に携わっている方は何人いらっしゃいますか?誰もいませんね。その通りです。

Thumbnail 190

そこで登場するのがAWS AIサービスです。.NET開発者が簡単なAPIを使って、アプリケーションにインテリジェンスを追加できるようにします。事前に学習されたモデルは、アプリケーションやワークフローに統合できる即座のインテリジェンスを提供します。また、Amazon Bedrockという生成AIもあり、シンプルなAPIを使ってすべての基盤モデルにアクセスできます。これは.NET開発者にとって非常に興味深いものですが、今回のセッションの焦点ではありません。

AWS SDK for .NETの特徴とAIサービスの活用

このセッションでは、ハイライトされたサービス、つまりAmazon Translate、Amazon Comprehend、Amazon Textract、Amazon Rekognitionに焦点を当てます。実際のビジネスユースケースを解決するエンドツーエンドのインテリジェントドキュメント処理システムを構築しますが、それをAI コーディングコンパニオンのAmazon CodeWhispererを使って行います。私たちがコードを書くのではなく、プロンプトを与えるだけです。Amazon CodeWhispererがほとんどのコードを書きます。これについては、最初のデモでまもなくお見せします。Alex、お願いします。

Thumbnail 270

ありがとう、Prasadさん。AWSサービスとやり取りする方法は複数あります。AWS consoleを使って手動で全てを行うこともできますし、 CLIつまりCommand Line Interfaceを使うこともできます。あるいは、開発者の皆さんなら、おそらくSoftware Development Kit(SDK)を使うでしょう。Python、JavaScript、TypeScript、.NET(C#)など多くの言語用のSDKがあり、今週はRustとKotlin言語のサポートも発表されました。

AWS SDK for .NETについて興味深い事実は、2008年にリリースされた最初のAWS SDKだったということです。SDK for Python、SDK for Java、SDK for TypeScriptよりも前です。NuGetを通じて配布され、すべてのAWSサービスへのプログラムによるアクセスを提供し、様々な拡張ライブラリを含み、.NETのクロスプラットフォームサポートを提供し、オープンソースで、コードはGitHubで公開されています。

Thumbnail 340

ご想像の通り、SDK は AWS の全サービスへのプログラムによるアクセスを提供します。今日は特に AI サービスに焦点を当てます。SDK は AWS サービスとの対話に関する複雑さを全て隠蔽します。ペイロードを XML や JSON として渡すこと、パラメータをヘッダーやペイロードボディに渡すこと、リクエストに署名することなどを考える必要はありません。 SDK がバックグラウンドで全てを処理します。C# コードを書いて意図を表現するだけで、SDK が残りの作業を行います。

Amazon CodeWhispererを活用したAIサービス統合デモ

Thumbnail 360

SDK を使用して AWS サービスと対話する際には、非常に一貫したコーディングパターンがあります。 まず、関連する NuGet パッケージをインポートし、使用する名前空間に対して using ステートメントを追加します。次に、クライアントオブジェクトをインスタンス化します。その際、リージョンや認証情報などのパラメータを任意で渡すか、設定ファイルから取得することができます。リクエストを作成する際は、C# クラスに型付けされているため、開発環境からの支援(IntelliSense、必須パラメータの渡し方、サービス上での操作の呼び出し方など)を全て受けられます。結果を受け取り、アプリケーションのビジネスロジックに基づいて、その結果を表示するか、さらなる処理のために渡します。

Thumbnail 470

一貫したコーディングパターンがあるとはいえ、どのサービスを呼び出すべきか、どのパラメータを渡すべきか、必須パラメータは何か、ベストプラクティスは何かを知る必要があります。多くの開発者は新しい API や SDK の使用を始める際に苦労します。ドキュメントを読んだり、インターネットで例を検索したり、コピー&ペーストしたりする必要があります。では、この作業を支援するツールがあったらどうでしょうか?新しい SDK を使用する際に、開発者の生産性を加速させることができるのです。ここで Amazon CodeWhisperer の出番です。

CodeWhisperer は、Amazon とオープンソースコードの何十億行ものコードで訓練された AI コーディングアシスタントで、安全な方法でコードを書くのを助けます。コメントなどで英語で意図を示すと、1行または関数全体のコードを生成してくれます。CodeWhisperer は汎用的なコーディングアシスタントですが、AWS SDK 用に特別調整されています。AWS SDK と CodeWhisperer を併用すると、私たちが持つ全てのベストプラクティスに基づいたコードスニペットを提供します。

Thumbnail 560

CodeWhisperer は、Visual Studio Code、JetBrains Rider、その他の JetBrains 開発環境を含む開発環境の拡張機能として利用できます。2日前、Visual Studio Toolkit の一部として Visual Studio 2022 のサポートを発表しました。JavaScript、TypeScript、Python、Java、PHP、Go、そして今日のトピックである C# を含む複数のプログラミング言語で利用可能です。では、最初のデモに進み、実際のシナリオでどのように使用するかをお見せしましょう。

Amazon Comprehendを用いた言語検出と翻訳デモ

Thumbnail 590

現在のシナリオは単純です。テキストがあり、そのテキストの言語を特定したいと思います。もし英語でない場合は、英語に翻訳したいと考えています。デモに移りましょう。まず、アプリケーションをお見せし、その後、コードをお見せします。これは.NET 8で書かれたサンプルアプリケーションです。.NETの最新の長期サポートバージョンです。ここにAmazon Lambdaについてのフランス語のテキストがあります。

Thumbnail 610

このテキストを英語に翻訳したいと思います。まず、どの言語かを理解し、それから翻訳したいと思います。そこで、このボタンがあります。これが私の関数のプレースホルダーで、現時点では何もありません。これから私の意図を書いていきます。まず言語を検出したいと思います。

Thumbnail 650

Thumbnail 660

これはAmazon CodeWhispererからの提案です。おそらくDetectDominantLanguageRequestクラスを使う必要があると言っています。これは理にかなっています。そして、これが翻訳したいテキストだと言っています。次にCodeWhispererは、Amazon Comprehendクライアントの非同期のDetectDominantLanguageメソッドを呼び出す必要があると提案しています。そして、最初の言語を取得して表示する必要があります。私はただTabキーをクリックしているだけです。

Thumbnail 680

Thumbnail 690

興味深いのは、次に何をしたいかをコメントで提案していることです。それは翻訳で、まさに私がやりたいことです。TranslateTextRequestを作成する必要があると言っています。ソース言語を渡す必要があり、SourceLanguageCodeは先ほどの行で検出した言語です。英語に翻訳したいので、これが翻訳したいテキストです。そして、translateクライアントのtranslate textメソッドを呼び出し、レスポンスを出力します。ここでも、私は何度もTabキーをクリックしただけです。

Thumbnail 720

Thumbnail 740

実行して、この生成されたコードが実際に機能するかどうか見てみましょう。テキストを取得し、translateメソッドを呼び出しています。ご覧のように、検出された言語はフランス語で、テキストは英語に翻訳されています。このテキストがフランス語から英語に翻訳されたものだと知らなければ、この英語のテキストを読むだけでは、非常に自然に聞こえます。これは、Amazon Translateが以前使用していた統計ベースの翻訳サービスではなく、ニューラル機械学習翻訳エンジンを使用しているからです。そのため、本当に自然に見えます。これが他の言語から翻訳されたものだとは理解できないでしょう。

はい、これが最初のデモでした。では、Prasad、再びあなたの番です。

ありがとう、Alex。それとも Amazon CodeWhisperer にコードを書いてもらったことに感謝すべきかな? 君は何もしていないよね。

いや、コメントを書いたし、何度もTabキーを押したよ。

それがほとんど全てだよね?

まあ、何かはしたんだよ。

Intelligent Document Processing(IDP)の概要

Thumbnail 790

Thumbnail 800

はい、その通りですね。 Alexが示したように、Amazon Comprehendを使用して言語を検出するのは非常に簡単です。 Amazon Comprehendには、言語検出以外にもさまざまな機能があります。エンティティの検出、個人を特定できる情報の検出、ポジティブかネガティブかを判断するセンチメント分析、キーフレーズの抽出、ドキュメントの分類やトピックに基づくファイルの整理などが可能です。Amazon Comprehendが提供するこれらの機能は、すべてNLP(Natural Language Processing)ツールの範疇に入ります。

Thumbnail 830

Thumbnail 840

Thumbnail 870

オープンソースで無料で利用できるNLPツールは多数ありますが、それらにはコストがかかります。そのコストとは、開発者に必要とされるML開発の経験です。 モデルの開発は簡単な作業ではなく、多段階のプロセスです。データの準備から始まり、モデルのトレーニングに必要なデータの種類を知る必要があります。また、ゼロからモデルを作成する場合は、正確にトレーニングできるよう何千ものファイルを収集する必要があります。適切なモデルを選択し、適切なアルゴリズムを見つけ、 適切なデータセットを提供して、モデルを完全に作成し構築できるよう、反復的に行います。

Thumbnail 880

Thumbnail 900

モデルが構築され、調整され、本番環境にデプロイされた後も、 関連性を保つために継続的なモニタリングと管理が必要です。AWS AIサービスを使用する場合、これらの作業は必要ありません。AWS AIサービスの事前トレーニング済みモデルは、すぐに使える知能を提供し、 さらに使いやすいAPIも提供します。独自のモデルを構築する場合、アプリケーションでアクセスできるようにラッパーとAPIを作成する必要があります。

しかし、AWS AIサービスを使用すれば、それらはすべて既に完了しています。Amazon Comprehendの使用がいかに簡単かを見てきましたが、さらに深く掘り下げて、Comprehendの使用方法を完全に理解するために、もう一つのデモを見てみましょう。Alex、お願いします。

Amazon Textractを用いたドキュメント分類デモ

Thumbnail 940

Thumbnail 950

ありがとう、Prasad。もう一つのデモをすぐに行いましょう。Prasadが言及したように、Amazon Comprehendはテキストの言語を検出できるだけでなく、複数のタスクを実行できます。 では、Comprehendを使用してテキスト内のエンティティを検出する方法を見てみましょう。

Thumbnail 1010

私のデモアプリケーションと、CEOのAdam Selipskyについてのサンプルテキストがあります。このテキスト内のさまざまなエンティティを検出したいと思います。メソッドのプレースホルダーがありますが、このメソッドは空なので、Amazon CodeWhispererを使ってコードを生成します。まず、意図を書きます:エンティティを検出する。DetectEntitiesRequestを使用し、Textを設定し、言語を英語にします。次に、detect entitiesの非同期メソッドを呼び出し、StringBuilderを作成し、行を追加し、もう1行追加して、レスポンスのコレクションを反復処理します。 最後に、結果を出力します。

Thumbnail 1030

Thumbnail 1060

CodeWhispererがコードを生成しました。このコードは少し変わっているように見えるかもしれません。なぜStringBuilderを使うのか、なぜ等号の数でAppendLineを使うのか、なぜSubstringを使うのかなど、疑問に思うかもしれません。実は、CodeWhispererは基本モデルだけでなく、私が作業している文脈も理解しています。ファイル内には、個人を特定できる情報を検出する別のメソッドがあるようです。その別のメソッドはこのような感じです。

Thumbnail 1080

Thumbnail 1090

この別のメソッドでは、このStringBuilderパターンを使用しています。CodeWhispererは「なるほど、この組織ではStringBuilderが使われているようだ。開発者はStringBuilderが好きなようだ。このコーディングスタイルを真似たコードを生成しよう」と考えます。そのため、CodeWhispererが生成したエンティティ検出メソッドのコードがこのようになっています。以前誰かが書いたコードを真似ているのです。

Thumbnail 1100

Thumbnail 1120

Thumbnail 1130

もう一度実行してみましょう。テキストをコピーしてエンティティを検出します。再コンパイルが必要なようです。もう一度実行します。これが私のテキストで、これらがComprehendから得られた結果です。Adam Selipskyは99%以上の確信度で人物として検出されました。Amazon Web ServicesとAWSは99%以上の確信度で組織として検出されました。また、multi-billion dollarは数量として、2021は日付として検出されました。これはComprehendが提供する機能であり、開発者としてこの情報をアプリケーション内でどのように使用するかは自由です。これが2つ目のデモでした。Prasad、お願いします。

Amazon Textractによるデータ抽出とクエリ機能

Thumbnail 1190

Thumbnail 1200

ありがとう、Alex。そしてCodeWhispererにも感謝します。Amazon AIサービスを簡単なAPIで使用する方法が分かりました。では、これを使って実際のビジネスユースケースを解決するIntelligent Document Processingを構築しましょう。さて、書類仕事。書類仕事が好きな人はいますか?おっ、1人いますね。素晴らしい。ほぼすべての業界、すべての組織において、書類仕事は共通の課題です。

Thumbnail 1210

金融、医療、保険、小売など、どの業界でも書類作業は避けられません。ほとんどの企業では、手作業による文書処理を行っていますが、これは効果的にスケールすることができません。ここで、Intelligent Document Processing(インテリジェント文書処理)が重要になってきます。Intelligent Document Processingとは、人工知能と機械学習を使用して文書からテキストや洞察を抽出することを指す業界用語です。デモでお見せするように、これらの文書は構造化、半構造化、または非構造化のいずれかです。

ある銀行の住宅ローン借り換えプラットフォームを刷新した経験をお話しします。約5年前、私はイギリスの銀行のコンサルタントとして、巨大な.NETモノリシックアプリケーションとして構築された住宅ローン借り換えプラットフォームに携わっていました。ワークフローの各段階で手作業のステップがありました。コンサルタントとして、私たちはこれを近代化する任務を負っていました。モノリスをマイクロサービスに分割し、DevOpsパイプラインを効率化することで、確かに近代化を実現しました。しかし、文書処理の多くの側面は依然として手作業のままでした。今、Amazon AIサービスについての知識を持つ私なら、その手作業の文書処理ステップに対して異なるアプローチを取るでしょう。

Thumbnail 1300

保険会社の顧客向けに請求処理システムを構築することを考えてみましょう。請求処理は、請求が受理されるか却下されるか、そして保険会社が支払いを行うべきかどうかを決定する前に、複数のチェックポイントを通過する必要があります。これらのステップを自動化する上で、Optical Character Recognition(OCR、光学文字認識)が重要な役割を果たします。請求フォームのような構造化された文書の場合、OCRはすべての情報を自動的に抽出し、意思決定のためのビジネスルールに提供することができます。しかし、退院サマリーや医療記録に記載された医師の手書きメモなどの補助文書は、手動でのレビューが必要です。この手動の介入がボトルネックとなり、スケーラブルではありません。

Thumbnail 1360

インテリジェント文書処理を使用して同じシステムを構築する場合、ほとんどのシナリオでは、文書を直接処理し、自動的に決定を下すことができます。手動の介入が必要なシナリオはわずかです。例えば、100万ドルの請求を処理する場合、すべての文書が揃っていることを確認するために手動チェックが必要かもしれません。または、文書処理の前段階が閾値を満たさない場合(例えば、低い信頼度スコアで処理された場合)、手動の介入が必要になるでしょう。しかし、ほとんどのシナリオでは、文書は自動的に処理され、ボトルネックが解消されます。

Thumbnail 1400

インテリジェント文書処理パイプラインの構築を始めましょう。画面に表示されているのは、請求処理システムや、ローン申請や銀行口座開設などの実際のビジネスユースケースを構築する際に経るプロセスの高レベルな表現です。ほとんどの文書処理はこれらのステップに従います。左から始まり、まずデータキャプチャがあります。ここでは、すべてのファイルを特定の安全な場所に集約します。次に、これらのファイルを識別し分類する必要があります。分類は重要です。なぜなら、給与明細書や銀行口座明細書など、異なるタイプの文書には異なるデータ抽出パイプラインが必要だからです。

分類後、ドキュメントは適切なパイプラインにルーティングされ、データが抽出されます。データ抽出後、特定のシナリオに基づいてオプションのエンリッチメントステップがある場合があります。例えば、ドキュメントにマスクする必要のあるPII情報が含まれている場合、それがデータのエンリッチメントとなります。最後のステップはレビューと検証で、どのシナリオが手動介入を必要とし、どれがビジネス判断のためのストレートスルー処理を進められるかを決定するためのビジネスルールを実装できます。

Amazon Textractを用いた請求書処理デモ

Thumbnail 1490

それでは、各ステップをより詳しく見ていきましょう。 左から始めると、データキャプチャがあります。Amazon S3は、すべてのドキュメントを安全に保存できる場所です。これを、すべてのドキュメントの中央集中型受信箱と考えてください。そこから、これらのドキュメントを識別し分類する必要があります。

Thumbnail 1510

特にクレーム処理について話すと、複数の種類のドキュメントがあります:クレームフォーム、請求書や退院サマリー、医療記録、身分証明書などの裏付け文書です。これらはAmazon TextractとAmazon Comprehendサービスを使用して分類できます。このプロセスをもう少し詳しく見てみましょう。

Thumbnail 1560

これは、数分後にデモンストレーションするものです。Intelligent Document Processing (IDP)パイプライン全体のドキュメント分類部分です。業界やユースケースに基づいて、私たちが馴染みのあるドキュメントのセットがあります。これらのドキュメントは通常PDFやJPEGなどの画像であるため、 Amazon Textractを使用して生のテキストデータを抽出します。次に、Comprehendカスタム分類器に必要な特別なCSVドキュメントを準備します。このCSVには2つの列があり、1つはドキュメントタイプ用、もう1つは生のテキストデータ用です。

Thumbnail 1610

Amazon Comprehendカスタム分類器をトレーニングし、リアルタイムエンドポイントにデプロイします。このエンドポイントを使用して、新しいドキュメントがシステムに入ってきたときに、ドキュメントタイプを判断するために呼び出すことができます。タイプに基づいて、異なる処理パイプラインにルーティングします。例えば、請求書の場合は明細項目を抽出する必要があるかもしれません。運転免許証の場合、 年齢などの個人情報を抽出します。医療文書の場合は、別のパイプラインを使用して処理します。

Thumbnail 1630

Thumbnail 1640

それでは、デモをご覧いただきましょう。これは皆さんもご存知のアプリケーションで、現在IDPパイプラインの文書分類段階にいます。これから3つのことを行います。まず、トレーニングデータを準備します。私たちの業界に関連する特定の文書でカスタム分類器をトレーニングする必要があるからです。次に、分類器を作成し、リアルタイムエンドポイントをセットアップします。最後に、このエンドポイントを使用して文書タイプを検出します。

Amazon ComprehendによるPII検出デモ

Thumbnail 1680

Thumbnail 1720

コードに切り替えましょう。このコードを書く際にはCode Whispererを多用しましたが、このデモでは使用しません。まず、いくつかのヘルパーメソッドがあります。GetDocumentLinesメソッドはTextractを使用して生のテキストデータを抽出します。リクエストでは、S3バケット内の文書の場所を指定します。DetectDocumentTextメソッドを呼び出すと、行のリストが返され、それをStringBuilderに追加します。結果として、1つの長い行に文書のすべてのテキストが得られます。

Thumbnail 1730

Thumbnail 1740

2つ目のメソッドは、必要なCSVファイルを作成します。ここでは、S3バケット内のすべてのファイルを反復処理しています。各ファイルには、文書の種類を示すプレフィックスがあります。このプレフィックスに基づいて、文書タイプと抽出された生のテキストデータを入れてCSVファイルを作成します。このファイルがどのように見えるか、お見せしましょう。すべての文書の処理には時間がかかるため、すでに作成してS3バケットにアップロードしてあります。

Thumbnail 1790

Thumbnail 1800

AWS Toolkitをインストールしたジェットブレインズのライダーを使用しているので、IDEから直接S3バケットにアクセスできます。これが私のS3バケットで、すでにCSVファイルをアップロードしてあります。このファイルはローカルにもあるので、ここからお見せします。これが私のCSVファイルで、2つの列があります。1つは文書タイプ用、もう1つは生のテキスト用です。運転免許証、パスポート、保険ID、その他様々な文書タイプがあります。

Thumbnail 1810

Thumbnail 1820

運転免許証がいくつか、パスポートがいくつか、保険IDがいくつか、CMS 1500フォームがいくつか、といった具合です。これがCSVファイルの見た目です。次のステップは、実際に文書分類器を作成することです。ここでも準備が必要です。すべての分類器をループ処理し、文書分類器が存在しない場合は、CreateDocumentClassifierRequestを使用します。多くの文書タイプがあるためマルチクラス分類であることを指定し、文書分類器の名前を提供します。

Thumbnail 1880

次に、Amazon Comprehend に S3 バケットへのアクセス権を与える必要があります。Comprehend に S3 バケットへのアクセスを許可する IAM ロールはすでに作成済みです。Comprehend CSV フォーマットのトレーニングドキュメントを使用することを指定し、これが S3 バケット内のファイルです。そして、分類器を作成します。分類器の作成にはかなり時間がかかるため、すでに作成済みです。分類器ができたら、このリアルタイムエンドポイントを作成します。この分類器をリアルタイムエンドポイントにデプロイして、自分のドキュメントで訓練された分類器を使ってドキュメントのタイプを検出できるようにします。CreateEndpointRequest を使用して、CreateEndpointAsync を呼び出すだけです。

IDPパイプラインの最終ステップと人間によるレビュー

Thumbnail 1910

Thumbnail 1920

セットアップが完了したら、ファイルを選択できます。これは例えば退院サマリーです。そして、Detect document type メソッドを呼び出すことができます。これが退院サマリードキュメントであると、99% 以上の確信度で判定されます。コードに戻ると、ドキュメントタイプの検出は次のようになります。画像をダウンロードする定型的なコードがありますが、実際の API コードは ClassifyDocumentRequest を呼び出す部分です。ドキュメント、つまり画像をバイト配列として提供し、この分類器を使用することと一部の設定を指定します。そして ClassifyDocument メソッドを呼び出します。

Thumbnail 1970

出力として、確信度スコア付きのクラスのリストを取得します。これは 99% の確信度で退院サマリーであり、非常に低い確信度で CMS 1500 フォームである可能性があります。はい、これがデモでした。では、Prasad さん、お願いします。

Thumbnail 1990

ありがとう、Alex。次のステップです。ドキュメントを分類したら、正確にデータを抽出できるよう、適切なデータパイプラインにルーティングする必要があります。データは構造化文書である請求フォームかもしれません。これは別のデータパイプラインを通ることになります。退院サマリーや医療転記のメモかもしれません。これらは別のパイプラインに送られます。これらのドキュメントからデータを取得するには Amazon Textract を使用できます。ドキュメントからの抽出が不要なシナリオもあるかもしれません。例えば、パスポートや運転免許証などの身分証明書を使って本人確認をしたい場合、直接 Amazon Rekognition に渡すことができ、自動的に処理してくれます。

まずは Amazon Textract を詳しく見て、データ抽出パイプラインがどのように機能するかを確認し、その後 Amazon Rekognition に戻って ID 検証の仕組みを見てみましょう。Alex さん、お願いします。

Thumbnail 2050

Prasad、ありがとうございます。先ほど、Amazon Textractの機能の1つをお見せしました。それは、生のテキストデータを抽出する方法です。これは、CSVファイルを作成するために使用したデータです。しかし、Textractはそれ以上のことができます。テーブルやフォームも処理できるのです。Textractがテーブルを処理する際、ドキュメントの構造を保持します。そのため、Textractで得られる結果は、元のテーブル構造を維持しています。列にアクセスしたり、行にアクセスしたり、ヘッダーに関する情報を取得したりすることができます。

Thumbnail 2100

Textractがフォームを処理する場合、生のテキストとして出力するのではなく、キーと値のペアとして出力します。これも、単なるテキストの塊ではなく、キーと値のペアとしてデータを処理する方がはるかに便利です。しかし、Textractはさらに多くのことができます。

ドキュメントの構造について全く考えたくない場合はどうでしょうか?ドキュメント内の特定のデータポイントに関する情報だけが必要な場合はどうでしょうか?Textract Queriesを使用して、ドキュメントから特定のデータポイントを抽出する方法を見てみましょう。Textract QueriesはAmazon Textractの人工知能機能で、事前に訓練されたモデルです。これにより、平易な英語でテキストで質問し、回答を得ることができます。例えば、保険IDカードのドキュメントがある場合、「会員名は何ですか?」と尋ねると、Textract Queryは「John Doe」と答えます。これにより、ドキュメントの構造や解析方法を理解する必要がなくなります。デモでその動作を見てみましょう。

Amazon Rekognitionの概要と本人確認プロセス

Thumbnail 2150

Thumbnail 2170

Thumbnail 2200

このデモンストレーションでは、保険IDカードを用意しています。まず、このカードからテキストを抽出するためにTextractを使用すると、テキストの塊、つまり単なる行と単語の集まりが得られます。しかし、同じドキュメントにTextractのフォーム機能を使用すると、同じデータが返されますが、キーと値のペアとして構造化されています。例えば、会員ID、グループ番号、支払者ID、その他の情報を見ることができます。

では、コード内でこれがどのように機能するか見てみましょう。私のPages と AnalyzeDocument メソッドでは、フォーム機能を利用するために AnalyzeDocumentRequest を使用しています。ドキュメントを提供し、"FORMS" という機能タイプを使用したいことを指定します。AnalyzeDocument メソッドを呼び出して結果を取得すると、特にキーと値のペアに注目します。BlockType KEY_VALUE_SET をフィルタリングし、これらのキーと値のペアの関係を取得します。

Thumbnail 2230

Textract は回答の幾何学的情報も返します。これには境界ボックスも含まれます。画面上では、赤く強調表示された領域が見えますが、これは Textract が提供する情報を表しています。これは特に検証に役立ちます。特に信頼度が低いものがある場合に有用です。

Thumbnail 2330

Thumbnail 2350

Thumbnail 2360

しかし、Textract にはさらなる機能があります。 私たちは平易な英語でも質問することができます。同じ保険IDカードの文書を使って、「会員の名前は何ですか?」と尋ねることができます。 答えは99%の信頼度で「John Doe」と返ってきます。さらに、この値がドキュメントのどこから来ているかという情報も付いています。ここでも、信頼度が低い場合は、手動での検証のためにフラグを立てることができます。

コードの観点から見ると、これまで使ってきたのと同じコーディングパターンが見られます。AnalyzeDocumentRequest を作成しますが、今回は "QUERIES" という機能を使用したいことを指定し、この QUERIES 機能の設定を提供します。

Thumbnail 2430

設定にはクエリのリストが含まれています。クエリは単なるテキストで、英語での質問です。同じリクエストで複数の質問をすることができます。ここでは1つの質問だけをしていますが、複数の質問をして結果を得ることもできます。そして再び、このAnalyzeDocumentメソッドを呼び出してクエリ結果を取得しています。答えは何で、信頼度はどれくらいでしょうか?数行のコードで、ドキュメントから情報を抽出する強力な方法を提供できるのです。

Thumbnail 2440

Thumbnail 2450

Thumbnail 2470

もう1つ例を示したいのは、請求書の扱い方です。請求書も非常に特殊な種類のドキュメントで、明細項目や価格、ベンダーに関する情報、ベンダーの特性などの情報を取得したいものです。ここでは保険の請求書があり、後ほどコードをお見せします。これが私の保険請求書で、病院の情報、患者の情報、そしていくつかの明細項目があります。そしてこれがAmazon Textractによって抽出された情報です。価格付きの明細項目と、概要フィールドがあります。

Thumbnail 2490

Thumbnail 2510

多くの情報がありますが、受取人の住所、受取人名、ベンダー名、ベンダーの住所、そして請求書自体の情報、例えば合計金額、税金、小計などが見られます。コードの観点から見ると、Amazon Textractには請求書や経費を扱う特別なメソッドがあります。この特定のユースケースのためにAnalyzeExpensesというメソッドがあります。AnalyzeExpenseRequestを作成し、分析したいドキュメントだけを入力として提供します。そしてこのAnalyzeExpenseメソッドを呼び出すと、出力としてドキュメントのリストが得られます。

Thumbnail 2570

各ドキュメントには明細項目グループの構造があります。各明細項目グループには明細項目があります。請求書はかなりツリー構造になることがあるからです。各明細項目について、価格や品目を確認しています。また、ベンダー名、ベンダーの住所、メールアドレスなどの概要フィールドもすべて取得しています。つまり、これはAmazon Textractの経費を特に扱う事前トレーニング済みモデルです。ご覧の通り、この機能は10行程度のコードで実現できます。自分でこの機能を構築したら、どれだけ時間がかかるか想像してみてください。

Amazon Rekognitionを用いた顔認証デモ

Prasad: 正直に教えてください。あなたがどれくらい書いて、Amazon CodeWhispererがどれくらい書いたのですか?

Alex: この場合、半々だったと思います。

Thumbnail 2600

Prasad: そうですね。つまり、これは生産性向上ツールということです。 できる限りあなたをサポートしてくれます。次のステップでは、パイプラインがさらに構築されていくのが分かります。最後に全体のパイプラインを振り返る際に、もう一度まとめますが、次のステップはエンリッチメントです。先ほど言ったように、これはオプションのステップですが、抽出されたデータを強化したいシナリオがあるでしょう。PIIについて話しましたが、請求フォームには確実にPII情報が含まれており、マスクする必要があるかもしれません。そうしないと、データにアクセスすべきでない人がアクセスできてしまう可能性があります。それを避けるために、ドキュメント内のPII情報を特定し、下流に送信する前にマスクするか、アクセスすべきでない人にはそのドキュメントを送信しないようにする必要があります。デモを通じて、PII情報をどのように特定できるか見てみましょう。

Alex: 自分でクリックできますよ。

Prasad: そうしましょう。

Thumbnail 2660

Thumbnail 2670

Thumbnail 2690

Alex: はい、次のデモですね。 Prasadが言ったように、ドキュメント内の個人を特定できる情報を識別し、おそらくマスクしたいと思います。 あるいは、検出したものに基づいて、ドキュメント処理パイプラインの異なるルートに進むかもしれません。例として、このドキュメントを見てみましょう。これは退院サマリーです。 これは医師が作成したサンプルテキストです。そして、これが検出された個人を特定できる情報です。これは医師の名前、個人名、そして実際に35歳という年齢も含まれており、これも個人を特定できる情報として分類されています。

Thumbnail 2720

これが、私たちの例で年齢情報が得られる場所です。

Thumbnail 2730

Thumbnail 2780

では、コード内でこれがどのように機能するか見てみましょう。以前見たものと似たコーディングパターンが見られます。 ここでは2つのサービスを組み合わせて使用しています。まず、Amazon Textractを使用して文書から生のテキストを抽出し、次にAmazon Comprehendを使用して個人識別情報(PII)を検出します。テキスト抽出には、DetectDocumentTextRequestを使用してすべてのテキストを取得し、StringBuilderを作成してテキストを準備します。その後、DetectPiiEntitiesRequestを呼び出し、入力としてテキストを提供し、言語として英語を指定します。DetectPiiEntitiesAsyncメソッドを呼び出すと、エンティティのリストが返されます。これらのエンティティを列挙し、エンティティの種類と信頼度スコアを出力します。この例は、複数のサービスを組み合わせて実際のAI強化アプリケーションを構築する方法を示しています。

Thumbnail 2800

Thumbnail 2810

Thumbnail 2820

これで、エンリッチメントのデモを終わります。 では、ドキュメント処理パイプラインの最後のステップについて説明しましょう。ポジティブなシナリオでは、ドキュメント処理の前のステップがすべて高い信頼度で完了した場合、それらのドキュメントを下流に送信して、 クレームの承認や拒否などのビジネス決定を行うことができます。しかし、 前のドキュメント処理ステップの信頼度が低い場合や、ビジネスが設定した閾値を満たさない場合は、手動レビューを組み込むことができます。

IDPパイプラインの全体像

例えば、ビジネスが95%の閾値を設定しているのに、Amazon Textractによるデータ抽出の信頼度が80%の場合、手動レビューを開始することになります。Amazon A2I(Amazon Augmented AI)というサービスがあり、人間によるレビュープロセスの自動化を支援します。また、100万ドル以上のクレームなど、他のビジネスルールを設定し、それに応じて人間によるレビューを組み込むようにプロセスをカスタマイズすることもできます。

Thumbnail 2870

Amazon Rekognitionにも同じ原則が適用されます。IDを検証する際、信頼度スコアが提供されます。 そのスコアが閾値に一致する場合は、ビジネス決定のために下流に渡すことができます。一致しない場合は、身分証明書の手動レビューが確実に行われるようにすることができます。

Thumbnail 2910

Amazon Rekognitionについて詳しく見ていきますが、これが全体的なエンドツーエンドのパイプラインです。各ステップで、プロセスを自動化するためのAmazon AIサービスが利用できます。これらの自動化されたステージを組み合わせることで、全体的な労力とコストを削減し、ドキュメント処理のビジネス成果を向上させることができます。

セッションのまとめと次のステップ

では、Amazon Rekognitionについてもう少し詳しく見ていきましょう。画面に表示されているように、Amazon Rekognitionは幅広い機能を提供し、様々なユースケースを可能にします。開発者が画像や動画の分析インテリジェンスをアプリケーションに簡単に追加できるようにします。APIに画像、動画、さらにはライブフィードを提供すると、エンティティを検出し、他のユースケースを可能にします。例えば、非常に正確な顔分析と顔認識を提供し、人数カウント、有名人認識、公衆衛生アプリケーションなどのユースケースを可能にします。

Thumbnail 2980

要するに、Amazon Rekognitionは、複数のAI/ML機能と強力な顔認識APIセットを提供するマネージドAIサービスであり、このデモで焦点を当てている本人確認のユースケースを可能にします。もう少し詳しく見てみましょう。

これが、Amazon Rekognitionを使用した典型的な本人確認プロセスの流れです。ユーザーが提出したパスポートや運転免許証などの身分証明書があり、そのユーザーとビデオで話をして、身分証明書のユーザーと同一人物であることを確認したいかもしれません。ビデオに映っている人物が身分証明書の人物と一致することを確認する必要があります。また、この人物がビデオでライブであることを確認する必要があります。つまり、単なるスクリーンショットではないということです。

このビデオストリームを身分証明書と比較する際、不正な書類のリストやデータベースに対してこのビデオを検索することもあるでしょう。すべてが正しければ、同じユーザーであることを確認します。これが、これからデモで見ていくことです。

Thumbnail 3040

Thumbnail 3050

デモに切り替えて、コードをお見せしましょう。IDがあります。スウェーデンでは、運転免許証を更新する際、 このようなプロセスを経ます:写真ブースに行って自分の写真を撮り、紙の申請書に写真を添付して警察に送ります。警察はそれを受け取り、写真付きでスキャンし、運転免許証に印刷します。つまり、運転免許証の写真はコピーのコピーのコピーのようなものなので、品質はあまり良くないと言えるでしょう。これがここにアップロードしたIDで、そしてこれがカメラのスクリーンショットです。このIDカードを提出した人物と同一人物かどうかを確認したいと思います。

Thumbnail 3090

Thumbnail 3120

これが私のIDカードです。先ほど言ったように、コピーのコピーのコピーです。そしてこれが私のセルフィーです。それでも、Amazon Rekognitionは99.98%、つまりほぼ100%の確信度で同一人物だと判断しています。私がIDカードを提出したけれど、Prasadが面接に来たというケースを想像してみてください。 その場合、「申し訳ありませんが、一致する顔がありません」と表示されます。

Thumbnail 3180

コードを見てみると、先ほどと同じ一貫したパターンが見られます。CompareFacesRequestを作成し、SourceImageとTargetImageの2つのパラメータだけを提供して、Amazon Rekognition clientのCompareFacesメソッドを呼び出しています。複数の顔が一致した場合は、単に顔を取得し、その顔にはバウンディングボックスがあり、それを画像上に表示しています。また、類似度のパーセンテージである確信度の情報も含まれています。しかし、ここでも数行のコードで強力な機能が得られます。一致する顔がない場合は、単に「一致する顔がありません」と表示します。これがPrasadの場合でした。 以上で、最後のデモを終わります。

Thumbnail 3190

Thumbnail 3200

さて、セッションの終わりに近づいてきました。簡単に振り返ってみましょう。今日見てきたのは、開発者がいかに簡単にアプリケーションにインテリジェンスを追加できるか、 しかもMLスキルを必要とせずにです。繰り返しますが、MLスキルを必要とせずに、開発者はアプリケーションにインテリジェンスを追加できるのです。これを、Amazon Translate、Amazon Comprehend、Amazon Textract、そしてAmazon Rekognitionのデモを通じて見てきました。コーディングのほとんどは、AIコーディングコンパニオンのAmazon CodeWhispererによって書かれています。

Thumbnail 3230

Thumbnail 3260

さて、始めるにあたって、Amazon CodeWhispererは個人ライセンスでは無料で使用できます。個人の方は無料で使えますので、ぜひ試してみてください。2つ目のリンクはデモアプリケーションです。ライブデモで紹介したすべてのコードスニペットがGitHubリポジトリにありますので、クローンして独自のエンドツーエンドのドキュメント処理パイプラインを試すことができます。3つ目は、すべてのAWS AIサービスを探索することです。以上で終わります。ご参加いただき、ありがとうございました。アンケートにぜひご回答ください。私たちの成果と改善点を理解するために非常に重要です。


※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。

Discussion