エンタープライズアプリケーションに数多くの進歩が見られる現在でも、企業における買掛金（AP）プロセスには、依然として手作業のワークフローが根強く残っています。
請求書は、さまざまなレイアウト、言語、ファイル品質で届きます。経時的に変更された発注書を参照するものもあります。また、ERP（Enterprise Resource Planning）への転記に必要な主要なメタデータが欠落しているものもあります。従来の自動化ツールは通常、ドキュメントからフィールドを抽出できますが、サプライヤー固有のフォーマット、PO（発注書）なしの請求書、曖昧な明細の照合、断片化されたエンタープライズデータ、企業によって異なるビジネスルールなどのエッジケースが運用コストを生み出す可能性があります。
このギャップに対処するため、Snowflake社内で使用するツールであるInvoiceIQを構築しました。
図1：InvoiceIQの請求書詳細
請求書処理をドキュメント解析の問題として扱うのではなく、Snowflake上で直接稼働する、ガバナンスの効いたデータとワークフローの問題として再構築しました。その結果、ドキュメントの理解、エンタープライズデータのエンリッチメント、ビジネスルール、ERPへの送信を1つのシステムに統合した、Snowflakeネイティブな買掛金管理アプリケーションが誕生しました。
本記事では、以下の内容について説明します。
- 従来のAP自動化が多くの価値を取りこぼす理由
- Snowflakeネイティブなアーキテクチャを選択した理由
- InvoiceIQが未処理の請求書を財務部門で利用可能なレコードに変換する仕組み
- 本番環境でのAIドリブンなワークフローの実行から得た教訓
AP自動化における真のボトルネック
モダンなマルチモーダルモデルは、すでに請求書を読み取ることができます。技術的な課題は、もはやAIがページ上のテキストを認識できるかどうかではありません。むしろ、より困難な課題は、実際の財務ワークフローの中でモデルの理解をいかに信頼できるものにするかということです。
実際には、AP自動化が失敗する原因は、モデルがドキュメントを読み取れないことよりも、そのドキュメントを取り巻くワークフローが断片化されていることによる場合が多くなります。データは複数のシステムに分散しています。SaaSのAI機能は汎用的なものが多く、企業固有のAPワークフローに適応させるのは困難です。統合パターンは、適応型のワークフロー向けには設計されていません。そして、最も重要な例外は、企業のサプライヤー、ポリシー、ERPの要件に固有のものであることがよくあります。
それこそが、InvoiceIQが橋渡しするように設計されたラストマイルです。社内では、この問題を、手作業によるレビューを減らし、制御を向上させ、ガバナンスの効いたエンタープライズデータ上に直接構築されるAIアプリケーションの再利用可能なパターンを作成できるシステムを構築することと位置づけました。
Snowflake上でネイティブに構築した理由
私たちは早い段階で、シンプルなアーキテクチャのスタンスをとりました。ワークフローをデータの近くに保ち、決定論的な部分は決定論的なままにし、ワークフロー全体を不透明なエージェントにするのではなく、より広範なシステムの一層としてAIを使用するというものです。
必要なデータがすでにSnowflake内にあったため、この決定は重要でした。発注書、サプライヤーの一次データ、過去の請求書、構成、キューの状態、下流の送信レコードはすでに利用可能であるか、そこでモデル化することができました。そのコンテキストを外部サービスのパッチワークにエクスポートするのではなく、アプリケーションロジックをデータに持ち込みました。
InvoiceIQはSnowparkコンテナサービス（SPCS）を使用してSnowflake内で稼働し、ワークフローの調整、構成、監査履歴もSnowflake内に保持されます。これにより、単一のセキュリティ境界、よりシンプルな運用、そして問題が発生した際に検査しやすいシステムが実現します。
InvoiceIQの仕組み
概要として、InvoiceIQは各請求書を分類、抽出、翻訳、照合、エンリッチメント、意思決定の6つのステージで処理します。各ステージには限定された役割があり、それらが連携することで、未処理のPDFを、Workdayに送信したり、明確な理由を添えてアナリストにルーティングしたりできる、財務部門で利用可能なレコードに変換します。
図2：InvoiceIQパイプラインの概要
分類
最初のステップは、アップロードされたファイルが実際に請求書であるかどうかを判断することです。
些細なことに聞こえるかもしれませんが、実際にはAPチームは請求書と一緒に領収書、発注書、明細書、添付書類を受け取ります。InvoiceIQは、AI_PARSE_DOCUMENTとAI_CLASSIFYを組み合わせてこれらを早期に除外するため、パイプラインの残りの部分は、請求書ワークフローにとって重要なドキュメントにのみ時間を費やすことができます。
抽出とドキュメントの理解
図3：PDFの取り込みから請求書の理解までのドキュメント抽出パイプライン
抽出は、意図的に複数ステージのプロセスになっています。
InvoiceIQは、Snowflakeのドキュメントインテリジェンスサービスを使用して、各請求書の構造化されたビューを構築し、テキストとレイアウト情報を復元し、アナリストのレビューのためにソースドキュメントへのトレーサビリティを維持します。
そのテキストが組み立てられると、AI_COMPLETEがそれをヘッダーフィールドや明細などの構造化された請求書データに変換します。ここが、システムが未処理のドキュメントコンテンツから、ビジネスで実際に操作できる表現へと移行するポイントです。
翻訳と正規化
図4：言語検出と翻訳のワークフロー
請求書の翻訳は、一般的な前処理としては扱われません。
パイプラインはまず、ドキュメント自体からの請求書を認識するシグナルを使用して言語を検出し、次に元のドキュメントの位置を保持し、レビューのために元のテキストと翻訳されたテキストの両方を維持しながら、CORTEX.TRANSLATEを使用して対象のセクションを翻訳します。
請求書は多くの場合、情報がまばらで、数値が多く、構造的に不規則であるため、これは重要です。ワークフローの品質に影響を与える正確なフィールドを翻訳することは、一般的なドキュメント全体の翻訳を行って途中でコンテキストを失うよりも有用です。
照合
図5：請求書の照合アプローチ
PO（発注書）に基づく請求書の場合、照合はAIが運用上意味を持つようになる部分です。
InvoiceIQは、3つの異なるジョブに対して3つの異なる照合方法を使用します。完全一致は、文字列がすでに一致している場合の低コストのショートカットとして機能します。JAROWINKLER_SIMILARITYは、煩雑なサプライヤー名や法人名の解決に役立ちます。そして、AI_COMPLETEは、表現は異なっていてもビジネス上の意味が同じである場合に、請求書の明細とPOの明細のセマンティックな照合を実行します。
これにより、アナリストがすべての不一致を手作業で調整することなく、「Professional Services Q1」などの請求書の明細を、より正式な、または異なる表現の説明を持つ発注書の明細に接続できるようになります。
エンリッチメント
図6：請求書のスマートなエンリッチメント
抽出により、請求書に何が記載されているかがわかります。エンリッチメントにより、最終的なビジネスレコードがどうあるべきかがわかります。
明細が照合されると、InvoiceIQはSnowflake内に存在する記録システムからエンタープライズコンテキストを取り込みます。これには、支出カテゴリ、コストセンター、場所、会社コード、サービス提供日、支払い条件、税関連の値などのフィールドが含まれます。
これは、システムにおける最も重要な設計上の選択の1つです。すべてのフィールドにおいて、PDFが最終的な信頼できる情報源であるべきだとは想定していません。代わりに、チームはどのデータをドキュメントから取得し、どのデータを内部システムやビジネスポリシーによって上書きするかを選択できます。POに基づく請求書の場合、POの記録システムを優先させることができます。POなしの請求書の場合、サプライヤーや過去のコンテキストがドキュメントに欠けている情報を補うことができます。
これにより、このアプリケーションは、スタンドアロンのパーサーよりもはるかに企業固有のAP運用に適応しやすくなります。
意思決定と送信
図7：InvoiceIQの請求書ライフサイクル
照合とエンリッチメントのステージの後、システムは次のアクションを決定します。
請求書は、Eメール統合プロセスまたは手動での読み込みを通じて入力され、AI処理を経て、承認、拒否、重複、またはレビューが必要などの初期結果を受け取ります。注意が必要な項目はアナリストに割り当てられますが、問題のないケースは、従来のAPキューで必要とされるよりもはるかに少ない人的労力で先に進めることができます。
重要なのは、すべての請求書が包括的に自律化されるということではありません。実際に判断が必要なケースのために人間のレビューが確保され、それらのケースが空白の画面ではなく、構造化されたコンテキストとともに届くということです。
本番環境でのAIワークフローの実行
AI機能のリリースは、仕事の半分にすぎません。それらを大規模かつ確実に、つまり安全に、オブザーバビリティを確保し、専任の運用チームなしで実行することが、残りの半分です。InvoiceIQは、Snowflakeのプラットフォームを活用して、これらの懸念事項のすべてをネイティブに処理します。
図8：InvoiceIQをSnowflake上の本番環境で稼働させるための5つの柱：スケーラビリティ、オブザーバビリティ、監査証跡、セキュリティ、評価
スケーラビリティ：SPCSのオートスケーリングと並列AI推論
SPCSが需要に応じてコンピュートを自動的にスケールアップおよびスケールダウンし、SnowflakeのCortex AI関数がSnowflakeのコンピュートレイヤー内で同時に実行されるため、InvoiceIQは手作業による介入なしに変動する請求書の量に対応できます。これにより、余分なネットワークホップ、カスタムのレート制限処理、または専任の運用チームを必要とせずに、単一のパイプライン内で複数の推論ステップを並行して実行できます。
オブザーバビリティ：すべてのトークンの重要性
InvoiceIQにおけるオブザーバビリティは、ランタイムの動作に関するものです。パイプラインを実行するたびに、ステージごとのレイテンシー、Cortex AI呼び出しごとのトークン使用量、エラーと再試行の回数などの運用メトリクスがSnowflakeに書き込まれます。そのテレメトリは、エンジニアがボトルネックを特定し、請求書あたりのコストを把握し、経時的なモデルのパフォーマンスを監視するのに役立つStreamlitダッシュボードを強化します。
監査証跡：最重要項目としての監査
監査証跡は、異なる目的を果たします。システムがどれほど効率的に稼働したかではなく、何が起こったかを記録します。AIドリブンまたは人間によるすべてのアクションがSnowflakeの監査テーブルにイベントとして書き込まれるため、SQLを使用して完全な履歴をクエリでき、関連するアカウントデータと簡単に結合して、コンプライアンスや運用レポートにすぐに利用できます。
セキュリティとアクセス制御：Snowflake RBACとSPCS
セキュリティは、アカウントの他の部分全体で使用されているのと同じSnowflakeのロールベースのアクセス制御モデルに従います。各SPCSサービスは、必要な権限のみを持つ専用のSnowflakeロールの下で実行され、アナリスト、エンジニア、サービスアカウントはすべて、スコープが設定されたロールの下で動作します。その結果、個別のIAMレイヤー、手動での認証情報のローテーション、または外部シークレットのインフラストラクチャを必要とせずに、人間とサービス全体で単一の最小権限モデルが実現します。
評価：TruLensと回帰テスト
InvoiceIQは、精度を1回限りのチェックとして扱うのではなく、品質を継続的に測定します。TruLensは、関連性や根拠などのシグナルについてパイプライン全体のLLM呼び出しをトレースしてスコアリングし、回帰スイートは、人間が検証したグラウンドトゥルースを持つ実際の請求書に対してすべての変更をテストします。このベンチマークファーストのアプローチにより、新しいプロンプト、モデル、SnowflakeのAI機能をより安全に導入できると同時に、チームは品質の低下が本番環境に到達する前に検出できるようになります。
最後に
請求書の自動化には、まだ改善の余地が十分にあります。しかし、その基盤はすでに整っています。
Snowflakeネイティブサービス、ガバナンスの効いたエンタープライズデータ、ターゲットを絞ったAI機能を中心にAPを再構築することで、請求書の抽出を超えて、実際のビジネス環境で実際に稼働できるシステムへと移行しました。その結果は、包括的に自律化されたブラックボックスではありません。それはより有用なものです。つまり、AIを最も役立つ場所に配置し、システムの残りの部分をエンタープライズの真実に基づかせ続ける、制御可能で検査可能、かつ拡張可能なワークフローです。
ビジネスにもたらされた変化
InvoiceIQは、効率と制御の両方を向上させるために構築されました。
社内でのロールアウトにおいて、チームはサプライヤーの請求書の大部分をInvoiceIQによる処理に移行することに成功し、自社のデータに基づいて構築されたエージェント型のAPワークフローを実現しました。これにより、Snowflake CoCoを使用して、稼働開始時にAIドリブンなアナリティクスとインサイトを迅速に利用できるようになりました。同様に重要なこととして、このシステムは将来のAP自動化のためのより強固な技術的基盤を作成しました。これは、ビジネスルール、エンリッチメントロジック、モデルの動作、および監査可能性が共に進化できる基盤です。
問題のない請求書は、数分で受信トレイからERPに移行できます。例外は、コンテキストが事前に入力された状態で届きます。そしてチームは、新しいモデルサイクルのたびにアプリケーションを再構築することなく、経時的に精度を向上させ続けるためのパスを手に入れました。
