三井物産流通グループは、食材や容器メーカーなど取引先300社超に向けた情報共有アプリケーションをデータクラウド「Snowflake」上に刷新した。20年前に外注開発された特定端末依存のレガシーシステムを破棄し、社内7名のプロジェクトチームが環境構築手順をテーブル化することで、計900回の構築処理をわずか2日間で完了させた。
5社統合で売上高1.4兆円規模となったMRGが抱えていたシステム負債
三井物産流通グループ株式会社（以下、MRG）は、中間流通機能の再編を目的に発足した企業だ。2020年6月に三井物産が持株会社である三井物産流通ホールディングスを設立したのち、傘下の事業会社を整理し、2024年4月1日付で事業会社を含む計5社が合併した。
統合に至るまでの経緯と企業規模
| 年月 | 出来事・合意内容 | 主な目的・体制 |
|---|---|---|
| 2020年6月 | 三井物産流通ホールディングス（MRH）設立 | 中間流通機能を統括する持株会社体制を発足 |
| 2023年6月 | グループ5社の合併検討開始を発表 | 個社ごとの事業構造からスピード重視の一体化へ移行 |
| 2024年3月 | 5社の合併契約締結を正式発表 | 存続会社を三井食品とし、株主は三井物産100% |
| 2024年4月 | 三井物産流通グループ株式会社（MRG）発足 | 売上高約1兆4,000億円、従業員数約2,600名体制で始動 |
合併した5社（三井物産流通ホールディングス、三井食品、ベンダーサービス、リテールシステムサービス、物産ロジスティクスソリューションズ）は、それぞれ異なる商流・物流基盤を個別に運用してきた。統合後のMRGでは、商品の受発注、請求、在庫移動などにより、1日あたり数千万件のトランザクションデータが発生している。
この商流・物流データを集約し、取引先との連携を円滑化する過程で、20年前のレガシーシステムが業務のボトルネックとなっていた。
20年もののレガシーシステムが直面していた運用課題
旧情報共有システムは外部ベンダーへ外注して開発されたものであり、以下の技術的負債を抱えていた。
- サーバーの保守期限切れ（EOS）: ハードウェアおよび基盤ソフトウェアのサポート終了に伴い、早急なシステム移行が求められていた。
- 物理端末へのアクセス制限: 特定の社内PC端末からしかログインできない仕様になっており、現場担当者や取引先の作業場所を固定化させていた。
- 個別ファイルによるデータ受け渡し: データの抽出や送付が手作業で行われており、共有先ごとにバージョン差異や誤送信のリスクが存在していた。
これらの課題を解決するため、MRGの情報戦略本部 データ事業推進部 DX推進室は、自社主導でデータを一元管理するクラウドアーキテクチャの設計へと舵を切った。
300社×3工程の環境展開を2日間で完遂した自動化・標準化設計
刷新プロジェクトにおいて最大の論点となったのは、取引先ごとに異なるセキュリティ要件を満たしながら、いかに迅速に展開するかという点であった。取引先は食材メーカーから包材・容器メーカーまで多岐にわたり、各社にSnowflakeの有償契約を求めることは現実的ではなかった。
そこで採用されたのが、Snowflakeの「Native App Framework」と「リーダーアカウント（Reader Account）」を組み合わせたアーキテクチャである。
| 採用技術・設計方針 | 具体的な実装内容 | 解決した現場課題 |
|---|---|---|
| リーダーアカウント方式 | 取引先ごとに専用の無償参照環境を分離して発行 | 取引先側の追加契約・費用負担をゼロ化 |
| READ ONLY（読み取り専用）共有 | データを複製せず、MRGの元データを直接参照 | データ誤削除の防止、最新データへの即時反映 |
| 多要素認証（MFA）の適用 | Native App Framework上でMFAを設定 | 特定PC依存を撤廃し、安全なマルチデバイス接続を実現 |
| 設定のテーブル化と命名規則固定 | 300社×3工程（アカウント作成・アプリ導入・config設定）を共通化 | 手作業での設定ミスを排除し、計900回の処理を2日で完了 |
開発初期の計画では、単一アカウント内で「行アクセスポリシー（Row Access Policy）」を用いて閲覧範囲を制御する方針が検討されていた。しかし、Native Appの制約によりセッション情報の取得が困難であることが判明したため、アカウントそのものを取引先ごとに完全分離する方式へと素早く設計を変更した。
さらに、エンジニア5名、プロダクトオーナーおよびスクラムマスター各1名の計7名という少人数体制を支えたのが、Snowflakeの内蔵生成AI機能「CoCo（旧名：Snowflake Cortex Code）」である。SQL関数やPythonコードから直接LLMを呼び出し、実装コードや構成メモからREADMEやアーキテクチャ設計書のドラフトを自動生成するパイプラインを構築した。これにより、仕様の属人化を防ぎ、運用引き継ぎの負荷を大幅に削減した。
参考記事: 三井倉庫ロジスティクスが3年で50人育成するAI人材モデルと物流DX
卸・メーカー・SaaS各層に波及する企業間データ共有の構造変化
MRGによる基盤刷新は、流通サプライチェーンに関わる複数のプレイヤーに業務プロセスの刷新を促す。
卸・問屋・流通業者：大規模統合時の内製化スピードモデル
卸売業界では、経営統合やアライアンスに伴う「システムの乱立」と「20年以上改修を重ねた基盤のブラックボックス化」が業務効率化の阻害要因となってきた。外部ベンダーに要件定義から改修までを一任する従来の手法では、数億円規模の見積もりと年単位の納期を要し、市場の変化に対応できない。
MRGの事例は、わずか7名の社内混成チームがクラウドデータプラットフォームの標準機能を活用し、短期で外部向け本番環境を立ち上げられることを証明している。外部ベンダーへの丸投げを脱却し、社内に設計・実装の主導権を置く「アジャイルな内製開発」は、統合効果を早期に回収するための必須モデルとなる。
製造業者・メーカー：端末制約の撤廃と需給判断の即時化
食材や包材を納入するメーカー各社は、これまで卸ごとに異なる専用端末や閉域ネットワーク環境を準備し、手動でCSVファイルをダウンロードして自社システムに再入力する手間を強いられていた。
本刷新により、取引先メーカーはWebブラウザと多要素認証（MFA）を用いて、場所を選ばず安全に最新データへアクセスできる環境を手に入れた。ファイル手渡しによるタイムラグがなくなり、卸側の在庫・出荷動向を直接参照できるため、メーカー側の生産計画や需給調整のリードタイム短縮に直結する。
SaaS・テクノロジーベンダー：データ共有パターンの標準化
これまでBtoB企業間のデータ共有といえば、EDIによるバッチ転送、ファイルサーバーへのCSVアップロード、あるいは個別のWebポータル開発が一般的であった。しかし、これらの手法はファイル管理の手間やセキュリティ統制の脆弱性を伴う。
MRGが確立した「リーダーアカウント×Native App×生成AIによるドキュメント自動生成」という構成は、外部数百社を巻き込むデータ共有における設計パターンとなり得る。テクノロジーベンダー側にとっても、データそのものを相手先環境へ転送・コピーさせることなく、アクセス権と計算リソースだけを安全に配賦するアーキテクチャへの対応が求められる。
参考記事: 三菱商事・メディパルHDが出資比率50%に、食・日用品へ拡大で迫る流通インフラ再編
LogiShiftの視点：ファイル送受信の終焉と「AI-Ready」な直接参照エコシステム
サプライチェーンにおける企業間連携は、長年続いてきた「ファイルを書き出して相手に送る」というバッチ処理型のデータ交換から、クラウド上に存在する「同一の元データを直接参照する」アーキテクチャへと移行している。
MRGの事例が示す最大の論点は、単なる旧型サーバーのリプレースにとどまらず、将来の「AIエージェント実装」を見据えたデータ構造の整理を行っている点にある。下華奈子氏が言及している通り、社内5社に散在していたデータを集約し、取引先との共有基盤をSnowflake上に統一したことで、システムは「AIレディー（AI-Ready）」な状態へと移行した。
従来のファイル転送方式では、データが受け渡し先ごとに複製・加工され、分散した断片情報（データサイロ）が生まれる。この状態のまま生成AIや予測モデルを導入しても、参照するデータの鮮度や正確性が担保されず、精度の高い意思決定支援は機能しない。
MRGは、取引先300社のアカウントを分離しつつ元データを「READ ONLY」で直接参照させる設計をとることで、サプライチェーンの上流から下流まで常に単一の正しいデータソース（Single Source of Truth）を保持する環境を整えた。この共通基盤が存在するからこそ、今後は取引先からの需要情報や在庫計画を直接インプットする双方向連携基盤への拡張や、AIエージェントによる需給自動マッチングといった高度な自律運用が現実味を帯びる。
物流・商流の効率化を進める上で、自社システムの刷新と外部取引先との接続プロトコルを同時にアップデートできるかが、プラットフォームとしての卸企業の競争力を決定づける。
参考記事: ライオンに学ぶ2026年4月改正物流効率化法への内製化必須対応
明日から意識すべきこと
取引先を巻き込んだ大規模なデータ連携を安全かつ迅速に進めるため、経営層およびDXリーダーは以下の手順で自社のシステム設計を点検する必要がある。
- 外部共有データの受け渡し経路の洗い出し
社内で利用しているデータ連携手段のうち、専用端末に依存しているものや、手動でのCSV抽出・メール送信に頼っている業務をリスト化する。機密漏洩リスクと現場の作業工数が集中している箇所を特定し、リプレースの優先順位を決定する。
- 「データ複製」から「直接参照」への共有アーキテクチャ転換
自社で利用しているクラウド基盤（Snowflake、AWS、Azure、GCP等）の外部共有機能を精査し、データを相手先に渡すのではなく、権限を分離した上で元データを直接参照させる構成が組めないかを技術検討する。
- 環境構築プロセスのパラメータ化と命名規則の統一
接続先企業が増加しても破綻しないよう、アカウント発行、権限付与、アプリ導入の処理をコードやテーブルで一元管理できる設計を整える。属人的なGUI操作を排除し、再現性のある自動化・標準化手順を確立しておく。
自社内の合理化にとどまらず、取引先が利用しやすいセキュアなインターフェースを提供することが、サプライチェーン全体のデータ連携速度を引き上げる第一歩となる。
出典: ZDNET Japan
出典: 三井物産株式会社 ニュースリリース
出典: 三井物産流通グループ株式会社 ニュースリリース
出典: DATUM STUDIO 事例紹介
