--- title: "データパイプラインの事例｜製造・医療・小売・通信の構成から導入判断まで【2026年版】" url: "https://www.issoh.co.jp/column/details/18820/" published: 2026-10-23 updated: 2026-10-23 categories: ["AI"] publisher: "株式会社一創" --- # データパイプラインの事例｜製造・医療・小売・通信の構成から導入判断まで【2026年版】 セブン‐イレブン・ジャパンは約2万1,000店のPOSデータを、目標1時間のところ実績1分でクラウドに集めています。この記事では、データパイプラインの事例を製造・医療と製薬・小売・通信の4業種から1件ずつ取り上げ、公開されている一次情報だけをもとに「どこから取り込み、どこに貯め、誰に届けているか」を分解しました。各事例の構成と遅延の数値を横に並べたうえで、自社でストリーミングまで踏み込むべき条件と、日次バッチのままで十分な条件を言い切ります。 ## まとめ：4業種の事例に共通する構成と自社で最初に決める3つの数字 4件の事例を並べると、ツールの名前は違っても構成は同じ3段に収まります。発生元から取り込む段、整えて貯める段、使う人や仕組みへ届ける段です。差が出るのは段の中身ではなく、どこまでの遅れを許すかという要件のほうでした。 小売のPOSと通信のアプリログは分単位の鮮度を求めてストリーミングを選び、製造の設備データは数分の遅延で足りるためマイクロバッチ寄りの構成になっています。複数病院の診療データを扱うMID-NETは、鮮度よりも施設間で形をそろえる標準化と品質管理に設計の重心がありました。 自社で検討を始めるときは、許容できる遅延、取り込むソースの数と形式、データを受け取る利用者の3つを数字で書き出してください。この3つが埋まらないうちは、どの事例の構成を真似ても過不足が出ます。 ## データパイプラインの事例を読む前に押さえる取込・蓄積・配信の3区分 公開事例は導入した製品名を前面に出して書かれるため、そのまま読むと「何を買ったか」の比較で終わりがちです。構成を3区分に置き直してから読むと、自社との違いが見えてきます。 ### 事例を分解する3つの軸と4件の構成を一覧で比べるための表の読み方 軸は、ソースの種類、許容される遅延、配信先の3つです。取り上げる4件をこの軸で並べると次のようになります。 | 業種と事例 | 主なソース | 遅延の水準 | 蓄積先 | 配信先 | | ------------- | -------------- | ---------- | ---------------- | -------------- | | 製造：三菱マテリアル | 生産設備の稼働データ | 数分 | S3とSnowflake | BIダッシュボード | | 医療と製薬：MID-NET | 電子カルテ・レセプト・DPC | 鮮度より標準化を優先 | PMDA管理のデータベース | 行政と製薬企業の調査 | | 小売：セブン‐イレブン | 全店のPOS | 1分から10分以内 | SpannerとBigQuery | 本部・加盟店・取引先のAPI | | 通信：NTTドコモ | アプリの分析イベント | リアルタイム | BigQuery | 施策分析とレコメンド | 表の右2列を見ると、蓄積先は各社の既存クラウドに合わせて選ばれ、配信先は事業の目的から決まっていることが分かります。真似るべきは製品の組み合わせではなく、遅延の水準を決めた理由のほうです。 ### データ連携の事例との違いは業務の同期ではなく分析と機械学習への供給 受注データを基幹システムからSaaSへ渡すような連携は、業務を止めないための同期が目的です。こちらは[データ連携の事例を6つの型に整理した記事](https://www.issoh.co.jp/column/details/16920/)で扱っています。本記事の4件はいずれも、集めたデータを分析やレコメンドに回すための経路で、受け手が人の意思決定や学習モデルである点が違います。 この違いは失敗の現れ方を変えます。業務連携は止まればすぐ現場が気づきますが、分析用の経路は誤った値が正常終了のまま流れ続けることがあります。定義や冪等性の考え方は[データパイプラインの種類と設計原則](https://www.issoh.co.jp/tech/details/15848/)にまとめました。 ## 製造業の事例：三菱マテリアルが設備稼働データを数分で可視化した構成 導入を支援したアイレットが2024年9月10日に公開した[三菱マテリアルの工場IoT基盤の事例](https://cloudpack.jp/casestudy/24-13.html)は、製造業のパイプラインで詰まりやすい箇所をどう越えたかが具体的に書かれています。稼働は2023年9月です。 ### SiteWise EdgeからSnowpipeまで5段で設備データを運ぶ流れ 当初は国内3拠点で始まり、生産設備の運転データを次の順で運んでいます。 1. 工場側の AWS IoT SiteWise Edge ゲートウェイで設備の運転データを取得する 2. Amazon Kinesis Data Streams へ送信する 3. Amazon Data Firehose を経由して Amazon S3 に保存する 4. S3 を Snowflake の外部ステージとして参照し、Snowpipe が S3 のイベント通知を受けて自動で取り込む 5. Snowflake 上のデータを BI ダッシュボードで可視化する その後は国内全拠点へ広がり、接続設備は約300台、月間のレコード量は約20億行に達しています。設備稼働データを数分のレイテンシで見られるようになった点が成果として挙げられました。 ### ETL処理を省いた決め手はOPC UAで情報モデルをそろえた設計 出発点の課題はコストでした。SiteWise から Amazon Redshift へロードする際のETL処理で費用が膨らむ懸念があり、データサイエンス室の立ち上げに合わせてDWHとBIの移行も必要になっていました。 解決の鍵は、変換を後段で頑張るのではなく、発生元で形をそろえた点にあります。設備の情報を国際標準の OPC UA で情報モデル化し、半構造化のまま記録できるようにした結果、ETLなしでセンサーの値を蓄積できるようになりました。値が変わらない区間は最初と最後のレコードだけを残し、時系列クエリの対象量も削っています。工場側のプロトコル差を吸収する方法は[BigQueryを製造業で使う構成と連携方式](https://www.issoh.co.jp/column/details/16524/)でも比較しています。 設備の種類が多い工場ほど、この順序が効きます。 ## 病院と製薬の事例：MID-NETが複数病院の診療データを集めて調査に回す仕組み 医療分野で公開情報が最も厚い事例は、医薬品医療機器総合機構（PMDA）が運営する[医療情報データベースMID-NET](https://www.pmda.go.jp/safety/mid-net/0001.html)です。病院と製薬企業をつなぐ、業種をまたいだパイプラインとして読めます。 ### 9つの協力医療機関から電子カルテ・レセプト・DPCを集める構成 MID-NETが保有するのは、国内9の協力医療機関の電子カルテ（オーダリングや検査結果を含む）、レセプト、DPCのデータです。病院ごとに異なるシステムから集めたデータを共通の形にそろえる標準化と、品質管理の考え方をPMDAが定め、管理と運営は医薬品の製造販売後調査の基準であるGPSP省令に準拠するよう努めるとしています。 受診者が自分の情報の利用を拒否したい場合は、受診した医療機関に申し出る仕組みも用意されています。個人の診療情報を扱うパイプラインでは、オプトアウトの受付経路も構成要素の一部になるということです。 ### 製薬企業の製造販売後調査にデータが使われるまでの利用承認の流れ [PMDAが公開しているMID-NETの利用承認の一覧](https://www.pmda.go.jp/safety/mid-net/0010.html)には、PMDA自身の調査、製造販売業者による調査、大学などによる調査が承認日とともに掲載されています。製造販売業者の調査で最も古い承認は2018年9月です。 ここで読み取るべきは、集めたデータを誰がどの目的で使えるかが、技術ではなく承認手続きで制御されている点です。病院内の部門間でデータを流す場合も、利用目的と承認者を先に決めてから経路を設計します。院内システム同士のつなぎ方は[医療のデータ連携の4方式](https://www.issoh.co.jp/column/details/16926/)で整理しました。 ## 小売の事例：セブン‐イレブンが約2万店のPOSを1分で集めたストリーミング構成 [セブン‐イレブン・ジャパンのデータ基盤「セブンセントラル」の事例](https://cloud.google.com/customers/sej)は、Google Cloud の公式事例として公開されています。店舗数は2020年8月末時点で20,980店です。 ### Pub/SubからSpannerとBigQueryへ流す4段の経路と遅延の実測値 店舗のPOSデータはメッセージングサービスの Cloud Pub/Sub で受け、Dataflow と Cloud Spanner を組み合わせてリアルタイムに加工・集計し、Spanner と BigQuery に格納します。利用者へは Apigee を通した統一APIで届けます。 注目すべきは遅延の数字です。目標の1時間に対して実績は1分で、全店が稼働した段階でも5分程度、悪くても10分以内という見込みが示されています。開発の本格開始は2019年初頭、本格稼働は2020年9月でした。 ### 配信をAPIに統一して本部・加盟店・取引先の参照経路を一本化 この事例で見落とされやすいのが配信の段です。本部、加盟店、パートナー企業がそれぞれ別の抽出ファイルを受け取る形にすると、利用者が増えるたびに経路が分岐し、同じ数字が部署ごとに食い違います。セブンセントラルは参照の入口をAPIにそろえ、データのサイロ化の解消と新サービス開発までの期間短縮を狙いとしています。 利用者が社外にまで及ぶなら、配信の形は蓄積先の選定より先に決めてください。 ## 通信の事例：NTTドコモがログ分析の1.5〜2日の遅れを解消した経路 [NTTドコモの情報サービス「マイマガジン」の事例](https://cloud.google.com/customers/nttdocomo202202)は、2021年11月のリニューアルで Google Cloud を採用した記録です。バッチからストリーミングへ移した前後の差が明確に書かれています。 ### 日次バッチからPub/Sub・Dataflow・BigQueryへの移行で変わる分析速度 旧システムでは、ログを日次バッチで抽出してDWHへロードしてから集計していたため、分析結果は1.5〜2日遅れで届いていました。新しい構成では、分析イベントを Pub/Sub で受け、Dataflow で BigQuery へストリーミングしています。 その結果、キャンペーン施策やA/Bテストの結果をすぐに確かめられるようになりました。BigQuery と Vertex AI を組み合わせたレコメンドも内製で実装しています。イベントを1件ずつ流す処理モデルの考え方は[ストリーム処理の仕組みとバッチとの使い分け](https://www.issoh.co.jp/tech/details/15301/)で解説しました。 遅れが施策の打ち手を縛っていた。ここが移行の理由です。 ## 4事例の比較から導く自社の構成判断とパイプライン化を見送る条件 ここからは4件を材料に、自社がどこまで作り込むべきかを条件付きで示します。 ### ストリーミングを採用する条件は遅延が施策や売上の数字に直結する場合 セブン‐イレブンとNTTドコモがストリーミングを選んだ理由は、どちらも「遅れると打ち手が遅れる」と説明できたからです。店頭の状況を本部と加盟店が同時に見る、A/Bテストの結果をその日のうちに次の施策へ反映する、という具体の用途が先にありました。 逆に、月次の経営会議や週次の在庫補充に使うデータでストリーミングを選ぶのは過剰です。製造の三菱マテリアルも分単位の遅延で成果を出しています。「1時間遅れたら誰がいくら困るか」に数字で答えられないなら、日次か時間単位のバッチから始めます。 ### パイプライン化を見送る場面は利用者とデータ定義が固まっていないとき 4件に共通するのは、使う人と使い道が構築前に決まっていた点です。セブン‐イレブンは本部・加盟店・取引先、MID-NETは行政と製薬企業の調査、NTTドコモは施策担当者とレコメンドでした。 受け手が決まらないまま「とりあえず全データを集める」計画は、見るテーブルが定まらず、品質の確認基準も作れません。ソースが1〜2個で更新が週次程度なら、スケジュール実行のSQLで足ります。売上や顧客の定義が部署ごとに揺れている段階でも、自動化を見送る判断が必要です。手作業で数か月回して定義が安定してから配管を敷くほうが、作り直しの工数は小さく済みます。 ### 事例を自社の計画に当てはめる4ステップと外部へ委ねる範囲の線引き 事例を自社の計画に落とすときは、次の順で進めます。 1. 受け手と用途を1つに絞り、許容できる遅延を時間で書き出す 2. ソースごとに取り出し方（API、DB、ファイル、設備プロトコル）と件数を棚卸しする 3. 4事例のうち遅延とソースが近いものを選び、蓄積先と配信の形を比べる 4. 最初の1本を本番で動かし、鮮度と件数の監視を付けてから対象を広げる 手順1と2の判断は社内に残し、取込の実装や監視の組み込みは外部に任せても進められます。要件の整理から一緒に詰めたい場合は、[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)で構成案の比較から相談を受け付けています。 ## よくある質問 データパイプラインの事例を調べている方から寄せられやすい質問に、公開情報の範囲で答えます。 ### データパイプラインの例を身近な業務で挙げるとどのようなものですか？ 店舗のレジで記録された売上が本部の集計画面に反映されるまでの流れが代表例です。セブン‐イレブンの事例では、POSデータをメッセージングで受け、加工・集計してデータベースに格納し、APIで本部や加盟店に届けています。社内なら、基幹DBの受注データを毎朝DWHへ取り込み、営業会議用のダッシュボードを更新する仕組みも同じ構造のパイプラインです。 ### 導入事例で費用が書かれていないのはなぜですか？ 公開事例の多くは製品ベンダーや構築会社の発信で、契約金額は取引先との守秘の対象になるためです。本記事で取り上げた4件にも費用の記載はありません。代わりに、遅延の実測値、設備台数、月間のレコード量といった規模の数字は書かれていることが多く、自社の見積もり比較では「同じ規模のデータ量で何が必要になるか」を見る材料として使えます。 ### 製造業で設備データを集めるときに最初につまずく点は何ですか？ 設備ごとに通信方式とデータ形式が違う点です。三菱マテリアルの事例では、設備の情報をOPC UAで情報モデル化して形をそろえ、ETL処理なしで蓄積できるようにしていました。古い設備が多い工場では、設備側で取り出せる項目と周期を先に一覧にしてから、ゲートウェイの方式を選ぶと手戻りが減ります。 ### 病院や製薬会社の診療データを扱うときに追加で必要な設計は何ですか？ 施設間のデータ標準化、品質管理、本人の利用拒否を受け付ける経路の3つです。MID-NETでは9の協力医療機関のデータを標準化し、受診者が医療機関へ申し出れば以降の利用を止める仕組みを設けています。データの利用は目的ごとに承認を経て行われ、製薬企業の調査にも使われています。 ### 中小企業でもデータパイプラインの事例は参考になりますか？ 構成の考え方は規模を問わず参考になります。大企業の事例から借りるべきは製品の組み合わせではなく、遅延の要件を数字で決め、受け手を先に固めてから経路を作る順序です。ソースが3つを超えて手作業の突き合わせが毎週発生しているなら、日次バッチの小さなパイプラインから始める時期にあたります。 ## 関連記事 - [リアルタイム分析とは？バッチとの違いと導入を見送る判断基準を解説](https://www.issoh.co.jp/column/details/16550/)：ストリーミングを選ぶかどうかの判断をさらに掘り下げています。 - [BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸](https://www.issoh.co.jp/column/details/16516/)：蓄積先にBigQueryを選んだ事例を類型で整理しています。 - [データ分析基盤とは？構成要素・費用・内製と外注の判断基準をわかりやすく解説](https://www.issoh.co.jp/column/details/16250/)：パイプラインを含む基盤全体の構成と費用の考え方です。 - [データ分析基盤の導入手順と期間｜工程・体制・外注の契約形態まで解説](https://www.issoh.co.jp/column/details/16252/)：事例を自社計画に落とした後の工程と期間の目安です。 - [製造業のデータ連携｜設備・MES・基幹の階層別インタフェース設計と段階導入](https://www.issoh.co.jp/column/details/16922/)：工場の設備データを基幹とつなぐ階層別の設計を扱っています。 --- 出典: [データパイプラインの事例｜製造・医療・小売・通信の構成から導入判断まで【2026年版】]()（株式会社一創）