CFCL 基幹システム統合プロジェクト｜連携インターフェース要件読み取り専用の元資料に基づくv0.2 ドラフト
CFCL IT統合プロジェクト／作成日 2026-07-14／対象：DPシステムと周辺システム（倉庫WMS・スマレジ・Shopify・JOOR・会計）の連携方式・データ項目・タイミング
本書は、新しい中核システム「DP」と、残置する周辺システム（倉庫WMS（ロジザード）／スマレジ（店頭POS）／Shopify（自社EC）／JOOR（海外卸B2B）／会計（MF会計・銀行・バクラク））との
連携インターフェース（IF）要件を整理したv0.2ドラフトです。
現時点の設計は「たたき台／イメージ」の位置づけであり、記載の連携方式（API/CSV等）は
すべて仮置きです。周辺システムとのAPI自動連携が本当に実現できるかどうかは、本プロジェクト最重要の未確定論点であり、
2026年7月17日のERP確認MTGでベンダー（MCF）に実現可否・工数目安を確認したうえで確定します。
01連携の全体像
DPを中核（ハブ）に、5つの周辺システムを「残置したまま連携」する構成。現状は手作業（CSV手取込・手コピペ・手貼付）でつながっており、これを自動連携に置き換えるのが本プロジェクトの核心。
DPシステム（新・中核）企画〜生産〜受発注〜在庫〜出荷〜卸請求を一気通貫
周辺システムの位置づけ（残置・DP代替可否）
| システム | 現行の役割 | DP代替可否 | 連携方向 | 優先度 |
|---|
| 倉庫WMS（ロジザード） | 物流倉庫の入出庫・在庫 | 残置（IF連携） | DP⇄WMS | Must |
| スマレジ（POS） | 店頭販売・店頭在庫 | 残置（IF連携） | DP⇄スマレジ | Must |
| Shopify（EC） | EC販売・EC在庫 | 残置（IF連携） | DP⇄Shopify | Must |
| JOOR | 海外卸（wholesale）受注管理 | 【要判断】残置IF or DP注文管理へ集約 | JOOR→DP | Should |
| MF会計（Money Forward） | 会計GL・決算 | 残置（IF連携） | DP→MF | Must |
| 銀行（りそな等） | 入出金 | 残置（IF連携） | 銀行→MF | Should |
| バクラク | 経費・請求書処理 | 残置（IF連携） | バクラク→MF | Should |
出典：要件定義書v0.1「01_スコープ定義」「06_連携IF一覧」
02システム別 連携要件（詳細）
周辺システムごとに、連携内容（データ項目）・方向・タイミング（頻度）・現行方式（As-Is）・To-Be方式（仮置き）を整理。To-Be方式はすべて7/17 MTGでの確認結果により変わりうる。
① 倉庫WMS（ロジザード）MustIF-02
連携内容マスタ／入出庫指示・実績／在庫実績
連携方向双方向（DP⇄WMS）
タイミング日次／随時
現行方式(As-Is)手CSV取込（毎回エラー発生）。AO⇄倉庫連携は「毎日手動でやらないとつながらない」状態。分納をAOが「全入荷」と誤認しエラーとなり、手動Excel管理に切り替わる事例あり。
To-Be方式(仮置き)API連携・日次バッチ（仮置き・要ベンダー確認）
未確定：API連携・日次バッチが実現できるかが本プロジェクトの最優先確認事項。標準実装の有無、個別開発時の工数目安（API 1本あたりの目安）を7/17 MTGで確認する。実現できない場合は計画全体の見直しが必要。
② スマレジ（店頭POS）MustIF-03
連携内容マスタ／店舗入出荷実績／売上／顧客
連携方向双方向（DP⇄スマレジ）
タイミング日次
現行方式(As-Is)一部バッチ連携・二重管理。店頭在庫を週次で手貼付。店舗では「スマレジと紙のアナログ数字を突き合わせて手入力」しており、在庫データがAladdinと連携せず乖離が発生。
To-Be方式(仮置き)API連携で店頭在庫・売上・顧客を自動同期（仮置き・要ベンダー確認）
未確定：API連携での自動同期可否を7/17 MTGで確認する（現状は一部バッチ連携にとどまる）。
③ Shopify（自社EC）MustIF-04
連携内容マスタ／EC在庫／EC受注・売上／顧客
連携方向双方向（DP⇄Shopify）
タイミング日次
現行方式(As-Is)手動連携（エラー発生）。EC在庫・EC受注を手貼付で同期している。
To-Be方式(仮置き)API連携でEC在庫・EC受注を自動同期（仮置き・要ベンダー確認）
未確定：API連携での自動同期可否を7/17 MTGで確認する。
④ JOOR（海外卸受注）ShouldIF-06
連携内容マスタ／卸（wholesale）受注
連携方向一方向（JOOR→DP）
タイミング随時
現行方式(As-Is)手動連携（手入力）。国内展示会受注はJOOR/AOへの手入力とExcelで対応。
To-Be方式(仮置き)API／CSV連携で残置、またはDP注文管理へ集約（いずれかを8/17ゲートまでに確定・仮置き）
未確定：JOORはDPの注文管理と機能が重複。「残して連携」か「DPへ集約」かを、機能重複の実態を確認したうえで8/17の意思決定ゲート（G1）までに確定する。海外卸（International）の業務設計・マスタに影響する重要論点。
⑤ 会計（MF会計／銀行／バクラク）MustIF-01 / IF-07 / IF-08
連携内容DP→MF会計：請求／売上仕訳 ／ 銀行→MF会計：入出金明細 ／ バクラク→MF会計：経費・請求書処理
連携方向いずれも一方向（DP→MF、銀行→MF、バクラク→MF）
タイミングDP→MF：日次／締め ／ 銀行→MF：日次 ／ バクラク→MF：月次
現行方式(As-Is)DP→MFは新規連携（現状は手作業想定）。銀行はAPI未連携預金を手import。バクラク経費は月次で手集計。
To-Be方式(仮置き)DP→MF：API／CSV連携（Must） ／ 銀行→MF：銀行API連携（Should） ／ バクラク→MF：API連携（Should）（いずれも仮置き・要ベンダー確認）
備考：DPは請求（AR：売掛管理）までを担い、GL（総勘定元帳）・決算はMF会計側で行う役割分担（要件定義書v0.1に明記）。
03連携IF一覧（まとめ表）
要件定義書v0.1「06_連携IF一覧」より、対象5システムに関わるIFを抜粋。
| IF-ID | 連携元 | 連携先 | データ内容 | 方向 | 頻度 | 現行方式(As-Is) | To-Be方式(仮置き) | 優先度 |
|---|
| IF-02 | DP | 倉庫WMS(LZ) | 入出庫指示／在庫実績 | 双方向 | 日次／随時 | 手CSV（毎回エラー） | API連携 | Must |
| IF-03 | DP | スマレジ(POS) | 店頭在庫／店頭売上 | 双方向 | 日次 | 手貼付（週次更新） | API連携 | Must |
| IF-04 | DP | Shopify(EC) | EC在庫／EC受注 | 双方向 | 日次 | 手貼付 | API連携 | Must |
| IF-06 | JOOR | DP | 卸(wholesale)受注 | 一方向 | 随時 | 手入力 | API/CSV（or集約） | Should |
| IF-01 | DP | MF会計 | 請求／売上仕訳 | 一方向 | 日次／締め | (新規/手作業) | API/CSV連携 | Must |
| IF-07 | 銀行(りそな等) | MF会計 | 入出金明細 | 一方向 | 日次 | 手import | 銀行API連携 | Should |
| IF-08 | バクラク | MF会計 | 経費／請求書処理 | 一方向 | 月次 | 手集計 | API連携 | Should |
出典：要件定義書v0.1「06_連携IF一覧」。参考：IF-05（FUKU296→DP、商品/品質/仕様マスタ）は製品マスタ連携のためスコープ外（別Issueで扱う）。
04未確定論点・7/17 ERP確認MTGでの確認事項
API連携可否が確定するまで、本書の連携方式（To-Be方式）はすべて仮置き。以下がCEOが7/17のベンダー確認MTGで押さえるべき論点（優先順）。
論点① 連携できなければ全部が崩れる（最重要）。本プロジェクトの前提は「周辺システムとの自動連携(IF)」。特に倉庫WMSは現状“毎回エラー”。API連携・日次バッチが実現できるかを、標準実装の有無・個別開発時の工数目安まで具体化させることが7/17の最優先事項。
論点② JOORの扱いを早期に決める。DPの注文管理とJOORは機能が重複。「残して連携」か「DPへ集約」かで、海外卸（International）の業務設計とマスタが変わる。8/17の意思決定ゲート（G1）までに確定。
システムごとの確認したいこと（ERP確認MTGアジェンダより）
| システム | 連携内容 | 現行（As-Is） | 確認したいこと |
|---|
| 倉庫WMS（ロジザード） | マスタ／入出庫指示・実績／在庫実績 | 手CSV（毎回エラー発生） | API連携・日次バッチの実現可否 |
| スマレジ（POS） | マスタ／店舗入出荷実績／売上／顧客 | 一部バッチ連携／二重管理 | API連携での自動同期可否 |
| Shopify（EC） | マスタ／在庫／売上／顧客 | 手動連携（エラー発生） | API連携での自動同期可否 |
| JOOR（卸受注） | マスタ／卸受注 | 手動連携 | DP注文管理へ集約 or IF連携残置、どちらが可能か（機能重複の実態確認） |
出典：ERP(DPシステム)確認MTG アジェンダ260717。あわせて「1APIあたりの想定工数」など標準実装/個別開発の概算を持ち帰らせることが目標。
関連するDP System QA（システム連携関連の質問）
- マスタ及び受発注登録でのCSV一括アップロードは標準実装されているか、開発での追加対応は可能か
- 標準でのAPI連携が実装されているものはあるか、開発での追加対応は可能か
出典：DP System QA「ヒアリング項目」No.1, No.2
05今後のスケジュール（関連ゲート）
| 日程 | 内容 |
|---|
| 2026-07-17 | ERP確認MTG：周辺システム連携の実現可否・開発要件範囲・想定スケジュール・DP機能資料への疑問点を確認 |
| 2026-08-17 | JOOR意思決定ゲート（G1）：残置IF連携 or DP注文管理へ集約を確定 |
| 2026-08-24 | 要件定義v1.0確定（目標） |
| 2026-09-14 | IF方式（API／iPaaS／CSV）選定ゲート |
出典：分析レポート「06 論点・リスク」／要件定義書v0.1「07_フェーズ計画」