Built TechnologiesとAWSが示す文書AIエージェント基盤｜不動産金融の審査・例外処理をどう自動化するか

目次

---

1. 文書AIは「抽出ツール」からエージェント基盤へ移り始めた

企業の文書処理AIは、長いあいだ「PDFから項目を抜き出すツール」として語られてきました。請求書から金額を読む。契約書から日付を拾う。申込書を分類する。もちろん、それだけでも大きな効率化になります。しかし、実際の業務で人が行っているのは、単なる抽出ではありません。複数の文書を突き合わせ、例外を見つけ、規程と照合し、判断に必要な根拠を残すことです。

AWSは2026年7月15日、Built TechnologiesがAmazon BedrockとAWS Intelligent Document Processing Acceleratorを使い、不動産金融向けの文書インテリジェンス基盤を構築した事例を公式ブログで紹介しました。AWSの発表によると、Built Technologiesは5000億ドル超の不動産プロジェクトを扱うソフトウェア企業で、AIを活用した文書処理エンジンを、不動産金融ライフサイクル全体のエージェント製品の土台として位置づけています。

この事例の重要性は、特定業界の自動化にとどまりません。文書を読むAIを、個別業務の便利機能ではなく、審査、保険、融資、資産管理、コンプライアンスを横断する共通能力として設計している点にあります。企業がAIエージェントを本番導入するなら、エージェントが操作する前に、文書を構造化し、評価し、根拠を追える状態にしておく必要があります。

2. AWSが紹介したBuilt Technologiesの文書インテリジェンス事例

Built Technologiesが扱う不動産金融の文書は、量も種類も複雑です。AWSの公式発表では、建設融資のdraw package、ローン契約、請求書、保険証明、検査報告書、募集資料、鑑定書、Excelベースの財務モデルなどが例として挙げられています。1つの取引や資産に、数百ページから数千ページの文書が関わることもあります。

従来のBuilt Technologiesには、OCRと従来型機械学習を使った26個のプロセッサがありました。これは、明確な項目や予測しやすいレイアウトを持つ文書では有効です。しかし、同社がAIロードマップを不動産ライフサイクル全体へ広げるには、250種類を超える文書、500ページを超える文書、入れ子の表、スキャン画像、手書き注記、業界固有の言い回しに対応する必要がありました。

そこでBuilt Technologiesは、AWS Generative AI Innovation Center、AWS PartnerのAND Digital、AWSアカウントチームと協力し、Amazon Bedrockを中核にした文書処理エンジンを構築しました。AWSの発表では、分類、分割、スキーマ生成、抽出、評価、文書推論にAmazon Bedrockを使い、AWS Step Functions、AWS Lambda、Amazon S3、Amazon EventBridge、Amazon DynamoDB、Amazon SQS、Amazon Textractなどを組み合わせた多段パイプラインとして説明されています。

処理の流れは、単純な「OCRして抽出する」ではありません。まずアップロードされた文書をS3に保存し、EventBridgeをきっかけにパイプラインを動かします。OCRでページごとのテキストと画像を正規化し、その後Amazon Bedrockで文書タイプと境界を判定します。分類されたセクションごとに抽出を並列実行し、評価やルール検証を行い、信頼度が低い結果や曖昧な結果は人間のレビューへ回します。

特に興味深いのは、動的スキーマ生成です。ユーザーが新しい文書タイプの例をアップロードすると、Amazon Bedrockが抽出すべきフィールド、構造、出力形式の案を作ります。業務の専門家はそれを修正し、テストし、モデルバージョン間で比較し、新しいプロセッサとして育てられます。文書AIをエンジニアだけの管理物にせず、審査や運用を知る現場の専門家が改善に参加できる設計です。

AWSの発表では、成果として、従来3日から9日かかっていた分類・抽出ワークフローがパッケージ単位で数分に短縮されたこと、250種類超の文書を対象にできること、月間2000万文書、週間30万文書、5万回超のバッチ処理実行へスケールする設計であることが示されています。さらに、本番前の品質評価とHuman-in-the-loopを組み合わせ、金融・コンプライアンス感度の高い業務で信頼性を担保する構成になっています。

3. なぜ文書処理がAIエージェントの土台になるのか

AIエージェントは、画面を操作したり、社内システムに問い合わせたり、申請を作ったりできます。しかし、金融、保険、建設、医療、法務、行政のような文書中心の業務では、エージェントの判断材料の多くが非構造データに埋もれています。PDF、スキャン画像、契約書、添付資料、メール添付、表計算ファイルが読み解けなければ、エージェントは本当に重要な例外を見逃します。

Built Technologiesの事例が示すのは、文書理解を個別画面の裏側に閉じ込めず、横断能力として作ることの価値です。建設融資の支払請求を確認するエージェント、保険証明を検証するエージェント、ローン契約の条項を確認するエージェント、ポートフォリオの例外を探すエージェントは、それぞれ別の業務に見えます。しかし共通して必要なのは、文書を読み、構造化し、根拠を示し、低信頼の結果を人間へ渡す能力です。

これは日本企業にもそのまま当てはまります。稟議書、契約書、見積書、注文書、検収書、社内規程、顧客提出資料、監査資料は、部門をまたいで使われます。最初のPoCでは一種類の帳票を読むだけでも、本番化すると「別の部署の似た文書にも使いたい」「例外処理も見たい」「承認ワークフローへつなぎたい」という要求が出ます。そのとき、個別業務ごとに作り捨てると、保守も評価も権限管理も膨らみます。

文書AIをエージェント基盤として設計するなら、最初から再利用を意識する必要があります。OCR、分類、抽出、評価、監査ログ、スキーマ管理、人間確認、モデル更新の仕組みを部品化し、業務ごとに必要なスキーマやルールを載せ替える。こうすると、1つ目の業務で作った仕組みが、2つ目、3つ目の業務へ展開しやすくなります。

もう一つのポイントは、文書AIが「判断の自動化」ではなく「判断材料の標準化」から始まることです。AIが最終判断まで行うよりも、まず文書を整理し、抜き出した情報に根拠を付け、信頼度を示し、人間が確認しやすい状態にするほうが現実的です。金融や審査のような業務では、この段階設計が信頼を作ります。

4. 実務導入で見るべき設計ポイント

文書AIを導入するとき、最初に決めるべきなのは「どのモデルを使うか」ではなく、「どの文書業務を横断能力にするか」です。請求書だけを処理したいのか、契約書も対象にするのか。単純抽出でよいのか、文書間の不整合や例外検知まで見るのか。ここが曖昧なまま始めると、PoCでは動いても、業務展開のたびに作り直しになります。

次に、文書タイプとスキーマ管理を分けて考えます。同じ「契約書」でも、取引基本契約、秘密保持契約、業務委託契約、利用規約では見るべき項目が違います。抽出項目をコードに埋め込むのではなく、文書タイプごとのスキーマとして管理し、業務担当者がレビューできる形にすることが重要です。Built Technologiesの事例で動的スキーマ生成と専門家レビューが重視されているのは、このためです。

処理基盤では、並列化と制限管理が重要になります。数ページのPDFを1件だけ処理するなら簡単ですが、数百ページのパッケージや数万件のバッチになると、OCR、推論、ストレージ、キュー、再試行、サービス制限が絡みます。AWSの事例では、Step FunctionsのMap state、DynamoDBのatomic counter、SQSキューを組み合わせ、BedrockやTextractの制限内でスケールさせる設計が紹介されています。これはクラウドに限らず、本番文書AIで避けて通れない論点です。

評価設計も早い段階で入れるべきです。抽出結果が正しいか、分類が合っているか、ページ分割が妥当か、低信頼の結果が適切にレビューへ回っているか。これを人の目だけで確認すると、文書タイプが増えるほど破綻します。代表文書セット、期待値、差分比較、バージョン管理を用意し、モデルやスキーマを変えるたびに評価できる状態にしておく必要があります。

現場導入では、最初の対象業務を狭く選ぶことも大切です。たとえば、審査前の添付資料確認、契約書の主要項目抽出、保険証明の有効期限確認、請求書と発注書の突合といった業務は、成果を測りやすく、例外も定義しやすい領域です。最初から全社の全文書を対象にするより、処理量、確認工数、例外率、レビュー時間を測れる業務で基盤の型を作るほうが成功しやすくなります。

5. 金融・審査業務で注意すべき落とし穴

文書AIの最大の落とし穴は、抽出精度だけを見て本番化を判断してしまうことです。たとえ主要項目の抽出精度が高くても、例外の見逃し、文書の取り違え、ページ分割の誤り、古いバージョンの参照、権限外文書の読み込みが起きると、審査やコンプライアンスでは大きな問題になります。金融や不動産の業務では、平均精度よりも、重要な例外をどう扱うかが問われます。

信頼度の設計にも注意が必要です。AWSの発表では、Built Technologiesが金融・コンプライアンス感度の高いプロセスを支えるため、分類・抽出ワークフローに95%超の信頼度を求めたことが説明されています。ただし、信頼度は魔法の保証ではありません。どの項目の信頼度なのか、文書単位なのか、フィールド単位なのか、しきい値を下回ったときに何が起きるのかを業務ルールとして決める必要があります。

Human-in-the-loopも、単に「人が確認する」と書くだけでは不十分です。誰が確認するのか。どの画面で根拠を見られるのか。AIの抽出元ページをたどれるのか。修正結果は次回のスキーマ改善や評価に反映されるのか。確認者が忙しいときにレビュー待ちが詰まらないか。こうした運用まで設計しないと、AIが処理を速くしても、人間確認が新しいボトルネックになります。

セキュリティ面では、文書の保管場所、暗号化、アクセス権、監査ログ、保持期間を明確にする必要があります。エージェント基盤として展開するほど、文書AIは多くの業務データへ近づきます。AIが人間より広い範囲の文書を読める状態にしてはいけません。業務担当者が見られる範囲とAIが参照できる範囲を合わせ、処理結果にも同じ権限制御を適用するべきです。

最後に、モデル更新とスキーマ更新の扱いです。生成AIモデルを変えると、同じ文書でも抽出結果や理由付けが変わることがあります。文書タイプを追加したときにも、既存スキーマとの衝突や評価基準のずれが起きます。本番では、モデルを新しくするたびにすぐ置き換えるのではなく、代表文書セットで差分を確認し、承認してから切り替える運用が必要です。

6. まとめ

Built TechnologiesとAWSの事例は、文書AIが「PDFから項目を抜き出す機能」から、AIエージェントが業務判断に使う横断基盤へ発展していることを示しています。Amazon Bedrockを使った分類、分割、スキーマ生成、抽出、評価、文書推論を、Step FunctionsやS3、Textract、SQSなどの運用基盤と組み合わせることで、大量で複雑な文書を業務ワークフローへ接続しています。

企業がこの流れから学ぶべきことは、文書AIを一つの帳票処理で終わらせないことです。文書タイプ、スキーマ、評価、人間確認、監査ログ、権限設計を共通化し、業務ごとのルールを載せ替えられるようにする。そうして初めて、AIエージェントは根拠のある判断材料を扱えるようになります。

OpenBridgeでは、生成AIやAIエージェントの業務導入において、RAG設計、文書処理パイプライン、外部システム連携、権限管理、Human-in-the-loop、監査ログまで含めたAIシステム開発を支援しています。文書が業務の中心にある企業ほど、AI導入の成否はモデル選定だけでなく、文書を信頼できる業務データへ変える設計にかかっています。