Catena-XとAWSで実現する真のデータ主権：BASF・CircularTreeのPACIFIC事例解説

はじめに：規制と協業が生んだ新しいデータ交換の場

EUの炭素国境調整メカニズム（CBAM）やサプライチェーンデューデリジェンス指令（CSDDD）が本格化する中、自動車産業のサプライチェーンにおけるカーボンフットプリント（PCF）データは、単なるESG報告資料を超え、コンプライアンスの中核要素として位置づけられています。しかし現実は厳しく、多くの企業は今なおExcelファイルやメールでPCFをやり取りしており、データ形式も統一されていないため、比較や検証が困難です。

こうした状況で、Catena-Xは自動車産業の標準化されたデータ交換ネットワークとして注目を集めています。その核心はデータ主権（Data Sovereignty）、すなわち自社のデータは自社で管理しつつ、必要な情報だけを安全にパートナーと共有できることです。BASFとCircularTreeが共同開発したPACIFICは、このCatena-Xデータスペース上で動作するマルチテナントSaaSプラットフォームであり、AWSのネイティブサービスのみでこの難しい要件を解決しました。

本記事では、PACIFICのアーキテクチャを3つの核心軸に分けて解説します：

• IAMベースのテナント分離（Amazon Cognito + AWS Secrets Manager）
• EDC発行認証トークンによるデータ交換セキュリティ
• サプライヤーPCFシステム統合のための柔軟なモジュール設計

各設計がなぜ必要で、どのようなトレードオフを考慮したのか、一緒に考えていきましょう。

参考資料： 本記事はAWS Architecture Blogに掲載された内容を基に再構成しています。

本論1：IAMベースのマルチテナント分離 — 「アカウントではなくポリシーで」

マルチテナントSaaSを設計する際、最初に直面する問いは**「テナントをどのように分離するか」**です。従来の方法は顧客ごとに個別のAWSアカウントを割り当てることですが、管理オーバーヘッドが大きく、オンボーディング速度を低下させます。

PACIFICは別の道を選びました。Amazon Cognito + AWS IAM + AWS Secrets Managerの組み合わせで、アカウントなしでも完全な分離を実現しています。

動作の仕組み

1. テナントオンボーディング： 新規企業が登録すると、自動的に専用IAMロールが作成されます。このロールには、その企業のSecrets Managerシークレットのみ読み取り可能なスコープポリシーがアタッチされます。
2. ユーザー認証： ユーザーはAmazon Cognitoユーザープールに所属し、自社グループにマッピングされます。ログイン時にCognito Identity Poolがグループ情報をIAMロールに紐付け、AWS STSが一時的な認証情報を発行します。
3. データアクセス制御： 発行された認証情報では、自社のEDC（データコネクタ）シークレットとDTR（デジタルツインレジストリ）認証情報のみ参照できます。他テナントのデータはIAMポリシーレベルで完全に遮断されます。

# 例：テナント別IAMポリシー（疑似コード）
# 実際のAWS IAMポリシーJSONです。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:region:account:secret:tenant-{TENANT_ID}-*"
        },
        {
            "Effect": "Deny",
            "Action": "secretsmanager:*",
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "secretsmanager:ResourceTag/TenantId": "${aws:PrincipalTag/tenant-id}"
                }
            }
        }
    ]
}

実践ポイント

• スケーラビリティ： 新テナント追加時にIAMロールとCognitoグループを作成するだけでよいため、数百の顧客企業でも迅速にオンボーディング可能です。BASFはこの方式により、2024年比で2025年の新規オンボーディング企業数が80%増加したと報告しています。
• セキュリティ： アカウント単位の分離と比較して、ポリシー単位の分離はクロステナントアクセスのリスクが相対的に高くなる可能性があります。そのためタグベースの条件キーを必ず使用し、定期的にIAM Access Analyzerで権限の境界をチェックすることを推奨します。
• 日本企業での適用： 日本の金融業界や大企業の情シスでは「アカウント分離」が規制上必須であるケースが少なくありません。このアーキテクチャは、規制が比較的緩やかなB2B SaaSやスタートアップでまず適用し、徐々に規制要件を満たす方向に進化させる戦略が効果的です。

本論2：EDC認証トークンでデータ交換の信頼を確保

テナント分離がプラットフォーム内部のセキュリティを担当するなら、データ交換レイヤーのセキュリティはCatena-Xエコシステムとの相互運用性を決定づける核心です。PACIFICはpcf-exchange-moduleという専用エンドポイントを通じてこの問題を解決します。

EDC間通信の流れ

1. ポリシー交渉： コンシューマー（Consumer）EDCがサプライヤー（Supplier）EDCにPCFデータを要求します。両EDCはCatena-X標準に従い、使用ポリシー（Usage Policy）を交渉します（例：「このデータは30日間のみ使用可能」）。
2. トークン発行： 交渉が完了すると、サプライヤーEDCはサプライヤー企業のCognitoアプリクライアント認証情報を使用して特別なOAuth2認証トークンを発行します。このトークンはサプライヤーのpcf-exchange-moduleエンドポイントのみアクセス可能です。
3. データ転送： コンシューマーEDCは発行されたトークンを使用してサプライヤーの専用エンドポイントを呼び出し、PCFデータを受信します。

// 例：EDCポリシー交渉後に発行されるOAuth2トークン要求（curl）
curl -X POST https://supplier-cognito-endpoint/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=supplier-edc-client-id" \
  -d "client_secret=supplier-edc-client-secret" \
  -d "scope=pcf-exchange-module:read"

# 応答例
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "pcf-exchange-module:read"
}

注意点と限界

• トークン有効期限管理： EDCトークンはデフォルトで1時間有効です。長期間のデータ同期が必要なバッチジョブでは、トークンリフレッシュロジックが必須です。
• EDCコネクタ設定の複雑さ： Catena-X EDCはオープンソースですが、初期設定が難解です。特に各企業がEDCインスタンスを運用する必要があるため、運用負担は小さくありません。PACIFICはこれをSaaSとしてラップして提供していますが、自社構築の場合はEDC運用要員が必要です。
• 日本開発エコシステムでの適用： 日本ではCatena-Xはまだ馴染みが薄いかもしれません。しかし、トヨタ自動車やホンダがグローバルサプライチェーン規制に対応するため、類似のデータスペース導入を検討している可能性を考慮すると、このアーキテクチャは今後2〜3年以内に日本の自動車部品メーカーにも大きな影響を与えるでしょう。先行して学習しておくことをお勧めします。

本論3：サプライヤーPCFシステム統合モジュール — 柔軟性と分離のバランス

PACIFICのもう一つの強みはintegration-moduleです。このモジュールはBASFのような大規模サプライヤーが内部PCFシステム（例：自社API、レガシーERP）とPACIFICを接続できるよう設計されています。

設計原則

1. 非同期かつスケーラブル： AWS Fargate上で実行されるため、トラフィックに応じて自動スケーリングします。サプライヤーが増えてもインフラを気にする必要はありません。
2. 認証の柔軟性： サプライヤーごとに異なる認証方式をサポートします。OAuth2クライアント認証情報、証明書ベース認証、APIキーなど、すべてのシークレットはAWS Secrets Managerに安全に保存されます。
3. データ形式の標準化： 統合モジュールは、入力されるPCFデータが既にCatena-X標準JSON形式に従っていることを前提とします。これがデータの一貫性を保つ核心です。

// Catena-X標準PCF JSON形式の例
{
  "@context": {
    "pcf": "https://catena-x.net/pcf/v1"
  },
  "pcf:productId": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "pcf:companyId": "BASF",
  "pcf:measurementDate": "2025-04-01T00:00:00Z",
  "pcf:carbonFootprint": 12.34,
  "pcf:unit": "kgCO2e",
  "pcf:status": "Active",
  "pcf:declaredUnit": "kg",
  "pcf:geographyCountry": "DE"
}

統合モジュールの利点

• 疎結合： サプライヤーシステムの変更がデータ交換レイヤーに影響しません。新規サプライヤー追加時もintegration-moduleのみ拡張すればよいです。
• データ主権の強化： PCFデータはAmazon S3の企業別プレフィックスに保存され、IAMポリシーが当該企業のみアクセス可能に制御します。データ所有権が明確に保証されます。

限界と補完ポイント

• リアルタイム性： 現状の設計はバッチベースに近いです。リアルタイムPCF更新が必要な場合、Amazon S3イベント通知 + Lambdaを組み合わせて、ニアリアルタイムパイプラインに移行できます。
• データ検証： 標準形式を前提としていますが、実際には形式エラーが発生する可能性があります。統合モジュールにJSON Schema検証ステップを追加することを推奨します。

まとめ：PACIFICが教えることと次のステップ

PACIFICの事例は、単なる技術実装を超え、データ主権と協業という相反する価値をAWSネイティブサービスのみでどう解決するかを示しています。特に以下の点が印象的です：

• IAMベースの分離はアカウント分離よりも運用効率が高く、自動化されたオンボーディングを可能にします。
• EDCトークンベースの交換はCatena-X標準を準拠しつつ、実務で即座に使えるセキュリティレベルを提供します。
• 統合モジュールの分離はサプライヤーシステムの多様性を吸収しながら、核心データ交換ロジックをクリーンに保ちます。

ビジネス成果も明確です。BASFはPCFデータ交換時間を7日から数秒に短縮し、オンボーディング企業数は80%増加しました。これは単なる技術導入ではなく、規制対応を超えた競争優位への転換です。

次のステップとしての学習方向

1. Catena-XおよびEDCの実践： Eclipse Dataspace Componentsの公式チュートリアルを試してみてください。実際にEDCインスタンスを立ち上げると理解が格段に深まります。
2. AWS SaaSアーキテクチャの深化： AWS Well-Architected FrameworkのSaaSレンズドキュメントをお読みください。特にテナント分離パターン（アカウント/ポリシー/データレイヤー）の比較をお勧めします。
3. カーボンアカウンティングデータモデル： PCFデータの意味をより深く理解するには、GHGプロトコルとISO 14067規格を学んでみてください。データの信頼性は技術よりもドメイン知識から生まれます。

合わせて読みたい記事

• CloudflareエージェントLee、AIがクラウド運用を新たに定義
• CUBの新単一呼び出しAPIでGPUプログラミングの煩雑さを解消