技術本部Digitization部Platform Engineeringグループの湯村です。Sansanでは、名刺や請求書などの情報を正確なデータへ変換するために、AIによる自動処理と人による補正を組み合わせた大規模な運用体制を構築しています。この記事では、こうしたデータ化の運用を拡大する中で直面した課題と、それを解決するために構築したデータ基盤hydraの設計について紹介します。
前提
Sansanでは、ビジネスデータベース「Sansan」、経理AXサービス「Bill One」、取引管理サービス「Contract One」など、複数のプロダクトを展開しています。これらのプロダクトでは、名刺の画像や請求書・契約書のPDFといった非構造化データから情報を読み取り、正確な構造化データに変換するデータ化が行われています。このデータ化を担っているのが、私が所属するDigitization部です。
データ化は、AIによる自動処理と人による検証・補正を組み合わせたHuman-in-the-loopで実現されています。この検証・補正を担う人を、私たちはオペレーターと呼んでいます。AIによる処理とオペレーターによる検証・補正を組み合わせることで、各プロダクトの品質基準を満たすデータを生成しています。
対象となる作業は、画像からのデータ抽出のようにオンラインで完結するものから、請求書の代理受領のように物理的な対応を伴うものまで多岐にわたります。Digitization部ではこうした多様なオペレーションを支えるため10を超えるシステムを開発・運用しており、安定的な運営のため、社内のオペレーターに加えて一部の作業を外部パートナー企業にも委託しています。
課題：横断的なオペレーションを阻むデータのサイロ化
各データ化システムはそれぞれ個別にオペレーション体制を構築してきましたが、システムの数と規模が拡大するにつれて、全体を横断した管理や最適化が必要になってきました。
しかし、その判断材料となる作業実績データ、つまり誰がいつどの作業を何件完了したかは各システムに閉じたままで、重要な意思決定や定型的な業務の多くはシステムごとに個別に手作業で行われていました。具体的には次のような課題がありました。
システム横断での最適な人員調整ができない
システムごとに、データ化業務の需要特性は異なります。たとえば名刺のデータ化では継続的に大量の処理が発生する一方、請求書のデータ化では月初に処理が集中し、短い納期での対応が求められます。そのため、需要が急増したシステムに対して、別のシステムで対応可能なオペレーターを柔軟に配置することが重要です。
しかし、各システムの稼働状況を横断的に確認する仕組みがなく、どこにどれだけの余力があるのかが分からないため、こうした調整は困難でした。
作業実績に基づく業務が手作業に依存している
作業実績を基に自動化したい業務もありました。たとえば、外部パートナー企業への支払い金額は作業実績から算出されますが、必要なデータが各システムに散らばっていたため計算ロジックをシステム化できず、担当者の手作業に頼っていました。
これらの課題を解決するために構築したのが、オペレーションデータ基盤hydraです。各システムに散らばっていた作業実績データを一カ所に集約し、横断的な可視化と業務の自動化を目指しました。
アーキテクチャ概要
hydraは、AWSまたはGoogle Cloud上の各データ化システムに分散する作業実績を、共通のイベントデータとして収集・変換し、横断的に活用できるようにする基盤です。中核となるデータストアにはBigQueryを採用しています。
hydraが収集するのは、オペレーターの作業サイクルを表す3種類のイベントです。オペレーターの作業は、「作業を開始する」→「作業を完了する」→「その結果が正誤判定される」というサイクルで進みます。hydraはこのサイクルに対応する「作業の開始」・「作業の完了」・「作業結果の正誤判定」をイベントとして収集することで、「オペレーターがいつ何の作業をし、どう判定されたか」を追跡できます。
このイベントデータは2つの処理方式でBigQueryに取り込まれます。ニアリアルタイムのフローでは、データ化システムがIngestion APIにイベントを送信し、Pub/SubからBigQuery subscriptionを経由してイベントテーブルに書き込まれます。バッチのフローでは、データ化システムがCloud Storageにファイルをアップロードし、日次でCloud Workflowsを使ってBigQueryにロードされます。
イベントデータとは別に、オペレーターのアカウント管理システムのアカウントデータもBigQueryに連携しています。イベントデータとアカウントデータを組み合わせることで、「どの作業に対応可能なオペレーターが何をどれだけ処理したか」を集計できるようになります。
蓄積されたデータはMaterialized Viewなどで集計され、Viewまたはテーブル関数を経由して公開されます。運用を支援するシステムやダッシュボードがこれらを利用して、データの可視化やオペレーションの効率化を実現しています。
技術的な課題と解決策
システムごとに異なる作業実績データのスキーマ
データ化システムは、いずれもオペレーターに作業を依頼するという点では共通しています。しかし、各システムがそれぞれのデータ形式で作業実績を管理しているため、横断的に集計できる形式に整えることが最初の課題でした。
最初に検討したのは、各システムの生データをそのまま収集し、収集後に横断的に扱えるよう変換する方法です。しかし私たちは、このアプローチを継続的にメンテナンスするコストが高いと判断しました。
- 10を超えるシステムそれぞれに個別の変換ロジックを書き、仕様変更に追従してロジックを修正する必要がある
- データ提供元の内部構造に暗黙的に依存するため、データ化システム側のスキーマ変更が検知されないまま下流に伝播し、集計や業務機能に意図しない影響を及ぼすリスクがある
解決策: 共通スキーマの定義
hydraでは、共通スキーマをhydra側が定義し、各データ化システムはそのスキーマに従ってイベントを整形して送信する設計を採用しました。ニアリアルタイムのフローでは、Ingestion APIでスキーマのバリデーションを行い、不正なデータが下流に流れることを防ぎます。
スキーマの設計に当たっては、各データ化システムのコードや既存データ構造を調査した上でスキーマ案を作成し、各システムの開発チームへの提案とフィードバックを繰り返しながら確定しました。
この設計により、次のことを実現できました。
- 横断集計の単純化: すべての作業実績データが同じ構造を持つため、システムごとの分岐や変換なしに横断的な集計クエリを記述できます
- 変更影響の局所化: 共通スキーマがデータ化システムとhydraの間の契約として機能するため、データ化システム側の内部仕様が変わっても、スキーマに従う限り下流の集計・分析ロジックに影響しません
即時性と正確性の両立
hydraが収集する作業実績データには、2つの相反する要件があります。
ダッシュボードでの作業状況の把握には、できるだけ新鮮なデータを即座に反映する即時性が求められます。一方、外部パートナー企業への支払い金額は作業実績に基づいて算出されるため、こちらには高い正確性が必要です。
ストリーミングであれば即時性は得られますが、複数のシステムをまたいでデータの整合性を担保することが難しくなります。一方、バッチであれば正確性は担保できますが、データの反映に遅延が生じます。
解決策: ストリーミングとバッチの併用
即時性はストリーミングで、正確性はバッチで担保する設計としました。即時性が求められるユースケースではストリーミングで取り込んだデータを利用しつつ、日次のバッチ処理でバックフィルすることで、最終的に正確な状態に収束させます。
ストリーミングでの取り込みにはPub/SubのBigQuery subscriptionを採用しています。BigQuery subscriptionは、自前でサブスクライバーを実装することなくPub/Subのメッセージを直接BigQueryテーブルに書き込む仕組みです。料金体系は、サブスクリプションからの読み取りとBigQueryへの書き込みに対する従量課金で、BigQueryへのデータ取り込みに追加料金はかかりません。この仕組みを利用することで、イベントは発生から数秒以内に集計可能になっています。
先述の通り、データの整形はデータ化システム側で実施し、ストリーミング処理で発生しうる重複は日次のバッチ処理で排除する方針としています。そのためPub/SubからBigQueryに取り込むまでのパイプラインでは、データ変換や重複排除の処理は行っていません。この結果、Dataflowなどのストリーム処理コンポーネントを介さないシンプルな構成となり、利用料金の削減にもつながっています。
| 要件 | 処理方式 | 仕組み |
| 即時性 | ストリーミング | データ化システムからのイベントをPub/SubのBigQuery subscription経由でBigQueryに書き込む。 |
| 正確性 | バッチ | 日次でCloud StorageからBigQueryに取り込む。 |
これらにより、現場の状況確認では速報性を活かしつつ、支払い計算のように正確性が重要な処理では後から確定したデータを使う運用を両立できるようになりました。
データ蓄積に伴うクエリコストとレイテンシの増大
hydraのイベントテーブルは追記のみで設計されており、日々データが蓄積されていきます。何も対策をしなければ、データ量の増加に比例してクエリのスキャン量が増え、コストとレイテンシが悪化していくことが予想されました。
解決策: Materialized Viewの増分更新の利用
BigQueryのMaterialized Viewの増分更新を活用し、イベントテーブルから日付・オペレーターごとの完了数などを集計したサマリーテーブルを作成しています。Materialized Viewは前回のリフレッシュ以降に追加された行のみを差分処理するため、イベントテーブルが何億行になっても再計算するのは新規分だけです。
増分更新が利用できるクエリには制約があるため、hydraではこの制約を満たすようにクエリを設計しています。これにより、キャッシュ済みの集計結果が再利用され、データ量が増加してもスキャン量とレイテンシを抑えることができます。
さらに、Materialized Viewを参照するテーブル関数やViewを定義し、集計ロジックを集約しています。利用側はテーブル関数やViewを呼び出すだけでよく、集計ロジックの変更の多くはテーブル関数やViewの修正のみで完結します。
テーブル関数が特に有効に働く例として、日本時間の日付での集計があります。hydraのイベントテーブルはUTC基準の時間単位列パーティショニングを採用しています。さらに、パーティション分割されたMaterialized Viewはベーステーブルと同じパーティション列を使用する必要があるため、サマリーテーブルも同じUTC基準のパーティションになります。この状態で日本時間の日付ごとに集計しようとすると、日本時間の1日分の作業実績がUTCのパーティション境界をまたぎます。UTC基準の日付カラムだけでは、どこからどこまでが日本時間の1日なのかを判定できません。
そこでhydraでは、サマリーテーブルにパーティションキーとなるUTCの日付カラムに加えて日本時間の日付カラムも別途保持しています。クエリ時はUTC日付でパーティションを絞り込みつつ、日本時間の日付カラムを使って集計します。このロジックをテーブル関数内に閉じ込めることで、呼び出し側はタイムゾーン処理の複雑さを意識せずに利用できます。
この設計の結果、データが蓄積してもクエリコストとレイテンシを一定に保てています。
成果
hydraを導入したことで、各データ化システムに散在していた作業実績を横断的に活用できるようになりました。重要なのは、データを一カ所に集めただけでなく、そのデータを管理上の意思決定や業務システムへ直接つなげられるようになったことです。その結果、次のような改善につながっています。
システム横断のモニタリング
以前は、管理メンバーが各データ化システムに個別にアクセスし、データを手作業で抽出・集計しながら作業状況を把握していました。繁忙期などオペレーターの配置を細かく調整する必要がある場面では特に運用工数が大きく、定量データに基づいたタイムリーな意思決定が困難でした。
hydraのデータを活用し、データ化システムごとの作業完了数や稼働オペレーター数をニアリアルタイムかつ時系列で一覧できるダッシュボードを開発しました。さらに、アカウント情報とイベントデータを組み合わせることで、特定の作業を実施できるオペレーターが今どのシステムで何をしているかを横断的に確認できる画面も実現しました。これにより、繁忙期にどの領域で支援が必要か、どこに作業の偏りがあるかを把握できます。従来は複数システムを見比べなければ分からなかった状況を、単一の画面から判断できるようになりました。
作業アサインの最適化
蓄積された作業実績データは、オペレーターへの作業依頼を最適化するためにも活用しています。hydraから各オペレーターの作業あたりの所要時間や完了件数を集計し、作業特性やこれまでの実績を踏まえながら、誰がどの作業を担うのが適切かを判断する仕組みに役立てています。
支払い金額計算の自動化
外部パートナー企業への支払い金額は作業実績に基づいて算出されますが、計算ロジックが複雑です。各データ化システムへ個別に実装するコストも大きく、以前はシステム化が進まず担当者の手作業に依存していました。作業実績データがhydraに一元集約されたことで、計算ロジックを一カ所に実装してシステム化でき、属人化の解消と工数の削減を実現しました。
今後の展望
hydraによる作業実績データの集約は、データ化オペレーション全体の最適化に向けた最初のステップです。
オペレーションの多くはまだ属人的な判断や手作業に依存している部分が残っており、改善の余地があります。今後はhydraが収集するデータをさらに拡充し、需要の予測や最適化を組み合わせて、データ化オペレーション全体の品質と安定性をさらに高めていきます。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
