TL

Cloud Service

AWS B2B Data Interchange

取引先と交換する EDI 文書を JSON へ自動変換し、ファイルの取り込みから変換・連携までをマネージドに自動化。EDI 処理を自前で作り込む手間を省く AWS B2B Data Interchange。

中級DEA-C01SAA-C03運用上の優秀性信頼性セキュリティ
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.EDI(X12 など)文書を JSON に変換するフルマネージドサービス。
  • 2.S3 へ届いたファイルを取り込み、変換して下流へ連携する。
  • 3.取引先・トランスフォーマー・機能の構成で B2B 連携を自動化する。

解決する課題

  • 取引先と交換する **EDI 文書(X12 など)**を、社内システムが扱いやすい JSON に変換したい
  • EDI のパース・変換ロジックを自前で実装・運用するのが負担で、専用ミドルウェアの保守も避けたい
  • 取引先から届いたファイルの取り込み・変換・下流連携を一連の流れとして自動化したい
  • EDI 連携を **AWS のデータ基盤(S3 やイベント駆動の処理)**へ素直につなぎ込みたい

主要概念と用語

  • EDI(電子データ交換): 受発注・出荷・請求などの商取引文書を、企業間で定型フォーマットでやり取りする仕組み
  • トランザクションセット: EDI 規格で定義される文書種別。受発注や請求書などが番号で識別される
  • 取引先(トレーディングパートナー): 文書を交換する相手企業を表す設定。プロファイルと能力を関連付ける
  • プロファイル: 自社や取引先の識別情報をまとめた設定
  • トランスフォーマー: 入力 EDI を解釈し、出力フォーマット(JSON など)へ変換する定義
  • 機能(ケーパビリティ): 入力元と出力先、トランスフォーマーを結びつけ、文書処理の流れを定義する単位
  • 入力 / 出力ロケーション: 取り込み元と書き出し先。一般に Amazon S3 を用いる

仕様・制限・クォータ

  • 主に X12 などの EDI 規格を入力として扱い、変換結果は JSON などの構造化データとして出力する
  • 入出力は Amazon S3 を中心に連携し、処理の起動はファイル到着を契機にできる
  • 取引先数・トランスフォーマー数・ファイルサイズなどにサービスクォータがあり、必要に応じて引き上げ申請が可能
  • 対応する規格バージョンやトランザクションセット、上限値などの具体的な数値は更新され得るため、最新の公式ドキュメントで確認する

内部の仕組み

B2B Data Interchange は、ユーザーが定義した**機能(ケーパビリティ)**に従って動作します。取引先から届いた EDI ファイルが入力ロケーション(一般に S3)に到着すると、サービスはそれを取り込み、トランスフォーマーで EDI 構造を解釈して JSON などの出力フォーマットへ変換し、出力ロケーションへ書き出します。

構成は 取引先・プロファイル・トランスフォーマー・機能といった要素に分かれ、識別情報や変換ルールを再利用できる形で管理します。EDI 特有のパースやマッピングはサービス側が肩代わりするため、利用者は専用のパーサを実装する必要がありません。変換後の JSON は、後続の Lambda・Step Functions・データ基盤などイベント駆動の処理へ素直につなげられます。

変換が要点

このサービスの本質は「EDI を JSON へマネージドに変換し、取り込みから連携までを自動化する」ことです。EDI のパーサを自作・保守する負担を肩代わりしてくれる点が価値になります。

設計パターン / ベストプラクティス

  • 取引先から届いた EDI を S3 に集約し、変換した JSON を分析基盤やアプリケーションの入力にする
  • 変換結果の出力を契機に イベント駆動(S3 イベントや EventBridge)で後続処理を起動する
  • 取引先ごとにプロファイルとトランスフォーマーを整理し、設定を散らさず再利用する
  • 取り込みに失敗したファイルは隔離用の保管場所へ退避し、再処理できるようにする
  • 取引先の追加・変更が見込まれる場合は、機能の構成を疎結合に保ち変更を局所化する

運用・監視

  • 各機能の処理結果で、取り込み・変換の成功 / 失敗や対象ファイルを確認する
  • 実行イベントは CloudWatchCloudTrail と連携して監視・監査できる
  • 失敗時は EDI の規格不一致・必須項目の欠落・トランスフォーマーの定義ずれを確認する
  • S3 の入出力先の権限設定が正しいか、取り込みが滞っていないかを点検する

コスト

  • 課金は主に処理した文書(トランザクション)の量に基づく考え方になる
  • EDI 専用ミドルウェアの導入・保守や、自作パーサの運用と比べ、運用負荷を含めた総コストで評価する
  • 不要なファイルを取り込み対象に含めないよう、入力先の構成を整理して処理量の増加を抑える
  • 具体的な料金は変動するため、見積もりは公式の料金ページで確認する

セキュリティ

  • 入出力に用いる Amazon S3 側で保存時の暗号化(KMS など)を構成できる
  • サービスや取引先設定へのアクセスは IAM で制御し、最小権限で運用する
  • 取引先ごとの識別情報をプロファイルとして整理し、設定の取り違えを防ぐ
  • 入力 / 出力バケットのバケットポリシーを見直し、想定外の読み書きを防ぐ

関連サービス・比較

EDI のファイル授受そのものは AWS Transfer Family(SFTP などのファイル転送)が担い、B2B Data Interchange は受け取った EDI の変換を担当します。両者は組み合わせて使うことが多く、役割が異なります。

観点B2B Data InterchangeTransfer Family
主目的EDI 文書の変換ファイルの転送・授受
扱う対象X12 などの EDI を JSON へSFTP など経由のファイル
役割取り込み後の変換と連携取引先とのファイル送受信
連携両者を組み合わせて使える両者を組み合わせて使える

ハンズオン / CLI例

# 定義済みのトランスフォーマー一覧を確認する
aws b2bi list-transformers

# 取引先(パートナーシップ)の一覧を確認する
aws b2bi list-partnerships

# サンプルの EDI 入力に対しトランスフォーマーの変換結果を試す
aws b2bi test-mapping \
  --input-file-content file://sample-edi.txt \
  --mapping-template "$(cat mapping.json)" \
  --file-format JSON

AWS Service

AWS B2B Data Interchangeを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

アプリ統合

比較で見る軸

クラウド: AWS / カテゴリ: アプリ統合 / 難易度: intermediate

導入後に効く点

S3 へ届いたファイルを取り込み、変換して下流へ連携する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
アプリ統合
難易度
intermediate
関連資格
DEA-C01 / SAA-C03
設計柱
operational / reliability / security

判断チェックリスト

  • 自社の用途が「アプリ統合 / operational」に近いか確認する。
  • 強みである「EDI(X12 など)文書を JSON に変換するフルマネージドサービス。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合operationalreliabilitysecurityDEA-C01