AWS、データ標準化のボトルネック解消へAI活用

データ収集と生成が加速する中、生データを生成する能力とそれを標準化する能力との間の格差は広がり続けています。自動化がない場合、この格差は分析の遅延や解釈の複雑化、共有データのグローバルな価値の制限という重大なボトルネックとなります。

メタデータ調和（異なるソースからのデータセットが連携できるようラベル、識別子、フォーマットを標準化するプロセス）はまだ手作業に頼っている部分が大きいです。AI を活用したメタデータの補正と調和は、この課題に対する解決策となり、時間のかかる業務だったメタデータ管理を、データ量に応じて拡張可能なプロセスへと変革します。これにより、科学のオープン化を阻害するのではなく、それを支える仕組みが実現されます。

本稿では、AI を活用したメタデータ補正の実践的な手法を紹介し、人間による検証を組み合わせたアプローチから自律型エージェント駆動のワークフローに至るまでの2つの実装方法を解説します。さらに、これらのソリューションを組織内で導入する際のガバナンスに関する考慮事項も提案します。

メタデータの補正と調和のワークフロー

この課題に対処するため、AWS を基盤とした中央集権型のメタデータ補正・調和ワークフローを開発しました。これは、多様なメタデータソース間での一貫性、相互運用性、および精度の確保を目的としています。

本システムでは、大規模言語モデル（LLM）を活用したスキーマ整合化と補正推奨の生成に Amazon Bedrock を採用しています。また、スキーマや結果の保存には Amazon Simple Storage Service (Amazon S3) を、ジョブ管理には Amazon DynamoDB を、認証機能には Amazon Cognito を、計算リソースには Amazon Elastic Container Service (Amazon ECS) をそれぞれ利用しています。ワークフローには、メタデータスキーマの整合化、データの完全性の検証、および補正推奨事項の生成を行う調和パッケージが含まれています。

このメタデータ補正・調和システムは、データを検証し、推奨事項を生成した上で最終承認のためにユーザーに制御権を返すという循環型のワークフローとして動作します。以下の図はこの高レベルな流れを示しています。

図 1: メタデータ補正・調和ワークフロー

図に示す通り、このプロセスはユーザーがメタデータファイルをアップロードすることから始まります。システムはその後、2 つの並列検証ストリームを実行します。1 つ目はスキーマ整合性チェックで、カラム構造が期待される形式と一致しているかを確認します。2 つ目はメタデータフィールドの妥当性確認で、個々のフィールド値が基準に適合しているかを精査します。

問題が検出された場合、システムは対象を絞った修正推奨事項を生成し、ユーザーに表示します。最終的な変更決定権は常にユーザーが保持します。この「人間がループに参加する」アプローチにより、自動化によってプロセスのスピードアップを図りつつも、研究者によるコントロールと専門知見を維持することが可能になります。

スキーマ整合性

メタデータ修正における最初のステップは、ソースデータとターゲットデータのスキーマを比較することです。必要なカラムが存在し、適切に整列しているかを確認します。よくある問題としては、命名規則の不一致（同義語、誤字、略語）、不足または余分なカラム、そしてカラムの分割や結合が必要なケースが挙げられます。

単純な命名の相違にはファジー文字列マッチングで対応できますが、より複雑な整合性の課題には別のアプローチが必要です。Amazon Bedrock で利用可能な大規模言語モデル（LLM）は、この問題に意味理解をもたらします。単なる文字列の類似性だけに頼るのではなく、LLM を活用したアプローチでは、業界固有の同義語を認識したり、周囲のカラムから意味を推測したり、ソースカラムを複数のターゲットカラムに分割すべきか、その逆を行うべきかを検出したりできます。

この意味ベースのマッチングは、ルールベースシステムが見逃すケースもカバーします。

メタデータフィールドの妥当性確認

メタデータフィールド検証コンポーネントは、個々のフィールド値がスキーマ要件に適合しているかを確認します。システムは各フィールドを事前に定義されたルールに対して評価し、違反を 3 つのタイプに分類します。

必須フィールドの検証では、欠落している、空である、または空白のみで構成されている必須フィールドを特定します。例えば、必須のサンプル識別子が行から欠けている場合、その行は追加処理が行われる前に警告フラグが立ちます。

列挙値の検証では、フィールドの内容がスキーマで定義された制御語彙と一致するかどうかを比較します。特定の機器タイプ（シーケンシングシステムなど）のみを受け付けるフィールドの場合、リスト外の値が入力されると検証エラーが発生します。これにより、標準化されたフィールドに自由記述による不整合が混入するのを防ぎます。

パターン検証では、正規表現マッチングを用いて書式規則の適合性を確認します。日付フィールドには YYYY-MM-DD 形式が求められる一方、識別子フィールドには特定の英数字パターンが必要となる場合があります。期待されるフォーマットから外れた値は警告フラグとして扱われます。

各検証失敗は分類され、推奨システムが適切な修正を生成できるよう十分な文脈と共に記録されます。構造化されたエラーレポートでは、問題の場所、タイプ、性質が明確に示されます。

メタデータフィールドの推奨

メタデータフィールドの検証中にエラーが検出された場合、システムは自然言語処理（NLP）と AI ベースの手法を組み合わせる多層構造を用いて推奨事項を生成します。このアプローチは、コスト効率、パフォーマンス、解釈可能性のバランスを取るために設計されています。

LLM を呼び出す前に古典的な NLP と埋め込みベースの類似性を優先することで、推論コストを予測可能に保ちつつ、正確でスケーラブルな推奨を実現しています。

これらの手法は、バギングやブースティングアーキテクチャ内で個別に、あるいは連続して動作します。どの手法を使用するかは信頼度閾値に基づいて動的に選択されます。この適応的な多層構造により、単純なメソッドで一般的な修正を効率的に処理し、文脈推論が必要な曖昧または新規のケースのみを高度なモデルが解決できます。

1. 埋め込みによる意味的類似性

ベクトル埋め込みを使用することで、システムはメタデータ値の意味的な比較が可能になり、類似度閾値に基づいて近接する一致を特定できます。これにより、類義語、略称、または頭字語などの一般的なバリエーションに対する正確な修正がサポートされます。例えば、「Human」を「Homo sapiens」に、「NYC」を「New York City」にマッピングすることが可能です。

このアプローチは、Amazon Bedrock で利用可能な小型で効率的な埋め込みモデルに依存しており、その出力はキャッシュできます。これにより、LLM 駆動の推論よりもコスト効果の高い代替手段となりながら、精度も維持されます。

本ワークロードに最適な埋め込みモデルを選定するため、ドメイン固有の生医学モデルや Amazon Titan など複数のモデルを評価しました。その結果、汎用および生医学メタデータタスクでの高いパフォーマンス、商用利用の容易さ、Amazon Bedrock における推論との互換性を理由に、Amazon Titan を採用しました。これにより、独自でドメイン固有モデルを運用する際のオーバーヘッドを負わず、サポートされスケーラブルな埋め込みソリューションが必要な組織にとって、非常に適した選択肢となります。

2. コンテキスト推論

コンテキスト推論では、メタデータ自体内の関係性や共通パターンを特定することで、システムが修正を提案できるようになります。多くのデータセットは内部整合性を示しており、類似する行同士が列にわたって構造的な特徴や繰り返し値を共有しています。これらの局所的な類似性を分析することで、モデルは現在のアップロードに含まれる情報のみを用いて、欠落しているまたは矛盾したメタデータ値を推論できます。これにより、大規模な外部学習データの必要性を回避することが可能になります。

本実装では、文脈推論は距離加重 k 近傍法と TF-IDF（Term Frequency-Inverse Document Frequency）特徴表現、そして共起統計を組み合わせたハイブリッドアプローチを通じて行われます。データセットの各行は、テキスト、カテゴリカル、数値フィールドから構成される複合ベクトルに変換されます。具体的には、テキストフィールドを TF-IDF 表現に変換し、カテゴリカル値はワンホットエンコーディングまたはコンパクトな学習済み表現で符号化し、数値フィールドは比較可能な範囲にスケーリングします。

その後、システムはコサイン距離やユークリッド距離を用いて各行間の類似度を測定し、最も類似した事例の中で加重投票を行うことで欠損値を予測します。この際、より近い近傍ほど大きな影響力を持ちます。

さらに、ポイントワイズ相互情報量（PMI）を用いた共起分析によって精度が向上します。これにより、データセット内で自然に一緒に出現する値の組み合わせが特定されます。PMI は単なる頻度を超えた統計的関連性を測定し、「カラム A に X が含まれる場合、カラム B には通常 Y が含まれる」といったパターンを捉えます。

最終的な推奨結果は、類似度と共起信号を設定可能な重みで組み合わせることで得られます。これにより、外部学習に依存せず内部データ構造に基づいた、安定性が高く説明可能な推薦が可能になります。その結果、小規模または特殊なデータセットであっても効率性と信頼性を維持できます。

3. フラジーマッチング

レベンシュタイン距離などのファジー検索アルゴリズムは、入力ミスやフォーマットの不整合を検出し修正します。特に、誤字脱字、空白の不一致、句読点の違いなど、手動で入力されたメタデータにおけるエラーを解決する際に効果を発揮します。ファジーマッチングは、意味論的または文脈的な推論レイヤーが適用される前に低レベルの不整合を捉えるため、修正ワークフローの初期段階で通常適用されます。

4. LLM ベースの解決策（フォールバック層）

ルールベースの NLP や埋め込み類似度モデルを含む以前の検証手法では十分な信頼度が得られない場合、Amazon Bedrock を介した LLM ベースの解決策がフォールバック層として機能します。これらのモデルは複雑なメタデータ構造にわたって推論を行い、曖昧なパターンや過去に見たことのないパターンを解釈できます。LLM による推論は選択的に呼び出されるため、計算集約的な推論は、単純なアルゴリズムでは高い信頼度でフィールドを解決できない場合にのみ使用されます。その後、結果は人間のレビューに供され、下流のデータ統合における精度と追跡可能性が維持されます。

まとめ

メタデータの補正と調和ワークフローは、3 つの段階で構成されています。まず LLM による意味解析を用いたスキーマ整合化、次に階層型ルールベースアプローチに基づくフィールド検証、そして埋め込みベクトル・ファジーマッチング・文脈推論を活用した推奨機能です。定型の補正処理には簡易な手法が用いられ、従来の方法では対応できないエッジケースについては LLM による解決策をフォールバックとして用意しています。

事前準備

本アプリケーションを導入する前に、以下のツールがインストールされていることを確認してください。

• AWS Cloud Development Kit (AWS CDK) とフロントエンド開発には Node.js 18+
• API およびプロセッサには Python 3.11+
• Amazon ECS (AWS Fargate)、Amazon DynamoDB、Amazon S3、Amazon Cognito、Amazon Virtual Private Cloud (Amazon VPC)、AWS Identity and Access Management (IAM)、AWS CloudFormation、Amazon Elastic Container Registry (Amazon ECR)、Amazon CloudWatch へのアクセス権限を持つ認証情報で設定された [ AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/)
• AWS CDK Toolkit (npm install -g aws-cdk)
• コンテナイメージの構築には Docker
• 提供されている Makefile コマンドの実行には Make
• 依存関係の管理には Python パッケージマネージャーの uv

node -v          # 18 or higher
python --version # 3.11 or higher
aws --version    # AWS CLI configured with credentials

はじめに

ステップ 1: リポジトリのクローンと依存関係のインストール

リポジトリをクローンし、Python および TypeScript の依存関係をすべてインストールしてください。

git clone https://github.com/aws-samples/sample-intelligent-metadata-harmonization.git
cd metadata-harmonization

# Create and activate Python virtual environment
make createPythonEnvironment
source .venv/bin/activate

# Install all dependencies (Python packages, TypeScript packages, CDK, frontend)
make install

make install コマンドを実行すると、uv を使用してプロセッサ、API、エージェント、評価パッケージが編集可能な Python パッケージとしてインストールされ、インフラストラクチャおよびフロントエンドプロジェクトに対して npm install が実行されます。

ステップ 2：デプロイの設定

設定テンプレートをコピーし、AWS アカウントの詳細を記述して編集してください。

cp config.yaml.example config.yaml

config.yaml を編集します：

appName: "metadata-harmonization-app"
env: "dev"

dev:
  profile: "your-aws-profile"
  deploymentName: "metadata-harmonization-dev"
  accountNumber: "123456789012"     # Your 12-digit AWS account number
  region: "us-east-1"
  deploymentStage: "dev"
  removalPolicy: "destroy"
  logLevel: "INFO"
  targetPlatform: "linux/amd64"

設定を検証する：

make validateConfig

ステップ 3：インフラのデプロイ

AWS CDK のブートストラップ（初回のみ）を実行した後、デプロイを開始します。

# First-time setup: prepare your AWS account for CDK
make bootstrap

# Deploy all AWS resources
make deploy

make deploy コマンドを実行すると、API のコンテナイメージがビルドされ、Amazon ECR にプッシュされた上で AWS CDK スタックがデプロイされます。これにより、Amazon DynamoDB テーブル、Amazon S3 バケット、Amazon Cognito ユーザープール、そして Amazon ECS Fargate サービスが作成されます。

デプロイ完了後、作成されたリソースの識別子を含むローカルの .env ファイルを生成してください。

make createLocalDotEnvFile

ステップ 4: Amazon Cognito ユーザーの作成

デプロイ後は、アプリケーションにログインできるようにするために、Amazon Cognito ユーザープール内にユーザーを作成します。

• Amazon Cognito コンソール を開きます。
• デプロイによって作成されたユーザープール（例：metadata-harmonization-users）を選択します。
• Users に移動し、Create user を選択します。
• ユーザーのメールアドレスと仮パスワードを入力します。

• ユーザー作成を選択してください。

初回ログイン時に、ユーザーは恒久的なパスワードの設定を求められます。

ステップ 5：Web アプリケーションをローカルで実行する

API サーバーと Next.js フロントエンドの両方を起動します。

# Run both API and frontend together (recommended)
make runLocal

あるいは、別々のターミナルでそれぞれ実行することも可能です。

# Terminal 1: API server
make runApiLocal

# Terminal 2: Frontend
make runUiLocal

システムへのアクセス先は以下の通りです。

• Web インターフェース：http://localhost:3000
• API ドキュメント：http://localhost:8080/api/docs

ステップ 6：メタデータエージェントの実行

API サーバーが稼働している状態で、別のターミナルを開いてエージェントを実行します。

uv run metadata-agent validate data/synthetic_dataset/simple_test.csv --interactive

このエージェントは、モデルコンテキストプロトコル（MCP）を介して API に接続し、データの検証を行い、失敗報告を取得した上で、自動的に修正を適用します。

人間の関与（Human-in-the-loop）

メタデータ品質と信頼性を維持するためには、人間の監視が不可欠です。本システムは、データ提供者が自身の投稿を管理できる協働ワークフローとして設計されています。インターフェースでは即座にフィードバックや推奨事項、実行可能な修正案が表示されるため、データ提供者はデータの整合性を保ちながら、効率的にメタデータを検証し承認することが可能です。

UI フローとインタラクション

人間の関与プロセスは、データ提供者がブラウザのインターフェースからメタデータファイルを選択してアップロードすることから始まります。データ提供者は、検証を開始する前にローカルでメタデータを確認・修正できるため、軽量なクライアントサイドツールを用いて提出前の調整を行うことが可能です。準備ができたらメタデータ処理をトリガーし、データをクラウドへ送信して自動検証と調和処理を行います。

ワークフローが実行されると、以下の 2 つの結果のいずれかが発生します：

メタデータがスキーマと完全に整合し、統合のために下流へ出力される検証パスがあります。また、欠落または不整合なフィールドに対する詳細な推奨事項を生成する検証失敗のケースもあります。

これらの推奨事項は、レビューと修正のためにインターフェース上に直接表示されます。貢献者はフラグ付けされたエントリを確認し、AI が生成した提案を検討して、それらを受け入れ、編集、または却下することができます。満足したら、修正されたメタデータを再検証のために再提出します。成功した提出は自動的に確認され、下流へ伝播されて、調和のプロセスが完了します。

図 2: 人間が関与するメタデータ修正ワークフロー

このサイクルを繰り返すことで、手作業の負担は軽減されつつも、最終出力に対する貢献者の所有権は維持されます。

以下の動画では、自動化と人間のレビューが単一の簡素化されたプロセスの中でどのように共存するかを示しています。研究者が数日かけて手動でメタデータの整合性を合わせることに頼るのではなく、このシステムは協力的なアシスタントとして機能し、修正を加速させると同時に検証を支援します。