Oracleのヘルプに載る、NetSuite Connectorの対応先は7つです。
Amazon・Shopify・eBayは入っています。
楽天市場とYahoo!ショッピングは、見当たりません（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
NetSuite EC連携とは、複数の販売チャネルとクラウドERP「NetSuite」をつなぎ、受注・在庫・会計の情報を一本化する仕組みです。
楽天・Amazonなどのモール、Shopifyなどの自社カート、実店舗のPOSが対象になります。
方式は、公式のNetSuite Connector・iPaaS・個別の開発の3つ。
国内のモールで売る会社ほど、「公式でつなげば終わり」とはいきません。
では、どの方式で、どのチャネルから始めればよいのか。
決め手は方式の性能ではありません。
この記事で分かること
- EC連携の全体像（受注・基幹会計・物流の3つの層）
- 3つの連携方式の違いと、公式コネクタが対応するチャネル
- 自社に合う方式を決める判断の物差し（連携しない選択肢を含む）
- 連携の費用を左右する要因と、一本化した後に見えるもの
- よくある3つの失敗と避け方
EC連携は「3つの層」で考える
「楽天の在庫とAmazonの在庫が合わない」
「受注のたびに、手作業で会計システムへ転記している」
複数のモールやカートで売る会社で、よく聞く悩みです。
チャネルごとに、管理の画面もデータの形も違います。
チャネルが増えるほど、転記とExcelでの突き合わせが増え、在庫のずれや出荷のミスも起きやすくなります。
NetSuiteは、会計・販売管理・在庫管理・購買などを1つにまとめたクラウドERPです。
ERPは、会社の基幹のデータを一元管理する仕組みのことです。
EC連携では、NetSuiteを「情報が集まる中心」に置きます。
| 層 | 中身 | 役割 |
|---|---|---|
| ① 受注の一元化 | 楽天・Amazon・Yahoo!・Shopify・店舗のPOS | 各チャネルの注文と顧客の情報を集める（入口） |
| ② 基幹会計＝NetSuite | 在庫・販売管理・会計 | 何がいくつ売れ、在庫がいくつあるかを集める（中心） |
| ③ 物流 | 3PL・自社の倉庫 | 出荷の指示を受け、出荷の結果をNetSuiteへ戻す |
3PLは、物流の業務を外部の会社に任せる仕組みのことです。
データは、①から②へ注文と在庫が集まり、②から③へ出荷の指示が渡ります。
③の出荷の結果が②に戻って在庫が更新され、①の各チャネルにも正しい在庫が反映されます。
この循環が回ってはじめて、受注から出荷・在庫の更新までが自動で回ります。
複数チャネルの受注をまとめる仕組みは、NetSuiteのマルチチャネル受注管理で扱っています。
物流の連携は、NetSuiteと物流SaaSの連携をご覧ください。
3つの連携方式
| 方式 | 中身 | 向いている会社 | 注意点 |
|---|---|---|---|
| NetSuite Connector | Oracle公式の連携ツール。主要なEC・物流・POSとの連携が用意されている | 対応チャネルが中心で、早く確実につなぎたい | 対応先を事前に見ておく |
| iPaaS（連携基盤） | CeligoやBoomiなどを介してつなぐ | 連携先が多い、業務の流れが複雑 | 基盤の運用と設定の知見が要る |
| 個別の開発 | SuiteScriptやREST APIで独自に作る | 標準で賄えない特殊な要件がある | 開発と保守の負担が大きい |
iPaaSは、複数のシステムをクラウド上でつなぐ仕組みのことです。
AIでの分析まで見据えるなら、データの形がそろう公式コネクタが扱いやすい。
個別の開発は、データの定義を資料に残さないと、後からAIで扱いにくくなります。
この2点は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットの見立てです。
NetSuite Connectorが対応するチャネル
Oracleのヘルプの説明では、NetSuite Connectorは主要なEC・物流・POSとの連携を提供し、データの転送を自動化します。
対応先として載っているのは、次のとおりです（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
- Amazon
- eBay
- Loop Returns（返品の管理）
- Magento 2
- Oracle Simphony（POS）
- Shopify
- Square（POS）
国内のモールは、iPaaSや受注管理のシステムを経由する構成が現実的です。
楽天市場はNetSuiteは楽天市場と直接つながらないで、Yahoo!ショッピングはNetSuite×Yahoo!ショッピング連携で扱っています。
受注管理のシステムを間に置く例は、ネクストエンジン×NetSuite連携ガイドをご覧ください。
個別の開発はRESTで作る
自社で開発するなら、使う技術の寿命にも注意が要ります。
Oracleのヘルプでは、NetSuiteのSOAPのWebサービスは2028.2のリリースで使えなくなり、既存のSOAPの連携は止まると案内されています。
新しく作る連携は、REST WebサービスとOAuth 2.0を使うよう求められています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
OAuth 2.0は、パスワードを渡さずに、アクセスの許可を与える認証の方式です。
iPaaSのCeligoは、2026年9月にNetSuiteのREST APIへの対応を始めました。
OAuth 2.0には、2026年10月のリリースで対応する予定と案内しています（出典：Celigo公式ヘルプ、2026年9月確認）。
iPaaSを使う場合も、提供元の対応の予定を見ておきます。
認証の変更の全体は、NetSuite認証の「2027年問題」で扱っています。
iPaaSの違いは、Celigo vs Boomi vs WorkatoとCeligoとはをご覧ください。
判断の物差し｜どの方式が合うか
| 自社の条件 | 合う方式 |
|---|---|
| 主なチャネルがAmazon・Shopifyなど、公式コネクタの対応先 | NetSuite Connector |
| 楽天市場・Yahoo!ショッピングなど国内のモールが中心 | iPaaS、または受注管理のシステムを経由 |
| チャネルが5つ以上、または物流・会計まで複雑に分かれている | iPaaS |
| セット販売や独自の値引きなど、標準で表せないルールが多い | 個別の開発（RESTで） |
| 1日の受注が少なく、チャネルも1〜2つ | 連携しない。CSVの取込で足りることがある |
冒頭の問いの答えは、この表の左の列にあります。
方式を決めるのは、何を一元管理したいかと、チャネルごとの件数です。
判断の順番を図にすると、次のとおりです。
いまは連携しない方がよい会社もあります。
- 商品コード（SKU）の付け方が、チャネルごとにばらばら
- 在庫を、どの倉庫の数で各チャネルに出すかが決まっていない
- 受注の件数が少なく、転記の手間が1日30分に満たない
この場合は、連携の前に商品マスタと在庫のルールを整える方が効果は大きい。
基幹システムそのものを選ぶ段階なら、Odooや国産ERPが合う場合もあります。
連携の費用を左右するもの
NetSuite本体は、ミニマム構成で月額20万円〜が出発点です。
連携のツールや開発の費用は、これとは別にかかります。
ベンチャーネットが支援したNetSuite導入の費用でも、差ははっきり出ました。
100名程度で他社SaaSや顧客独自のシステムとの連携開発を含めた事例は、2億円程度で、うち約7割が開発でした。
3名程度・購買・販売だけで連携のない事例は、150万円程度です。
差を生んだのは、機能範囲・開発（特に外部システム連携）・社内の体制・ユーザー数の4つでした。
4事例の詳細は、NetSuiteの料金で扱っています。
つなぐチャネルを絞り、公式コネクタで足りる範囲を広げるほど、「開発」の重さは軽くなります。
これから連携を始める会社と、見直す会社
これから連携を始める会社
すべてを一度につなぐ必要はありません。
1つの層ずつ広げるのが安全です。
- 受注の取込：件数が最も多いチャネル1つから始める
- 在庫の同期：欠品と過剰在庫の損失が大きいチャネルに広げる
- 物流と会計：出荷の結果と入金の照合をつなぐ
既存のモールやカートは、多くの場合そのまま使い続けられます。
販売の入口はそのままに、裏側の受注・在庫・会計をNetSuiteでまとめる形が一般的です。
いまの連携を見直している会社
すでに連携を運用している会社は、次の3つを見直します。
- 使っている技術：個別の開発でSOAPを使っていないか（2028.2で止まる）
- エラーの件数：毎月、手で直している注文や在庫の件数はいくつか
- チャネルの増減：この1年で増えた、または減らしたチャネルはあるか
SOAPの連携があれば、RESTへの作り直しを早めに計画に入れます。
手で直す件数が多いなら、方式そのものを見直す時期です。
よくある3つの失敗
失敗1：目的が曖昧なまま、ツールを選ぶ
起きること：受注だけで足りたのに、在庫・出荷・会計まで一度につなぎ、費用と複雑さが膨らむ。逆に、必要な連携を見落として作り直す。
原因：「とりあえず自動化したい」という動機だけで、ツール選びを始めていた。
避け方：「複数モールの在庫を一元化し、欠品を減らす」のように、目的を1文で決めます。
目的が決まると、どの層から始めるかが見えてきます。
失敗2：いまの手作業を、そのまま連携に持ち込む
起きること：担当者しか分からない独自のルールを設定に重ね、連携が前より複雑になる。
原因：「なぜこの作業が必要か」を問わずに、「今と同じ動き」を求めた。
避け方：連携を機に、「本当に要る業務」と「惰性で続けている業務」を分けます。
標準でできることは標準に任せ、独自の作り込みは最小限にします。
独自に作るほど、NetSuiteやモールの仕様変更のたびに直す手間が増えます。
失敗3：「つながった日」をゴールにする
起きること：稼働後に「連携の結果が合わない」「どこを直せばよいか分からない」となり、Excelの二重管理に戻る。
原因：運用のルールと担当の分担を決めないまま稼働した。
避け方：稼働後3〜6か月の運用計画を、最初から組み込みます。
「毎朝、連携のエラーの一覧を見る人」「チャネルの仕様変更の知らせを受ける人」を決めます。
操作のルールと問い合わせの窓口を1枚の手順書にまとめると、引き継ぎも楽になります。
ベンチャーネットならこう見る
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
仕事の多くは、ゼロからの導入より、他社のあとの引き継ぎや、他システムとの連携です。
EC連携の相談で最初に聞くのは、ツールの名前ではなく「いちばん損をしているのはどこか」です。
見える化→整理整頓→連携の設計
欠品か、過剰在庫か、転記の人手か、入金の照合か。
損をしている場所は、いまの受注から出荷・入金までの流れを描くと見えてきます（見える化）。
次に、チャネルごとの独自の作業を、やめる・まとめる・そろえるに分けます（整理整頓）。
商品コードと在庫のルールがそろってから、方式を選び、連携を設計します。
製品やツールが決まっていても、この順番は変えません。
守り→攻め→次へ｜一本化した後に見えるもの
連携は、つながった日がゴールではありません。
受注・在庫・会計が1つにそろうと、打てる手が段階的に広がります。
- 守り：転記と突き合わせが減り、在庫のずれと出荷のミスが起きにくくなる
- 攻め：どのチャネルで何が売れ、在庫がいくつ残るかがすぐ分かる。売れ筋と在庫の分析に回せる
- 次へ：チャネル別の数字を、KPIや管理会計で経営の判断に使う
勘ではなくデータで判断できる状態は、守りが回った後に来ます。
だから最初の一歩は、小さくても確実に回る連携にします。
最初に投げかける問いは、次の3つです。
- チャネルごとの月の受注件数はいくつか（件数の少ないチャネルは、連携しない選択肢も残す）
- 商品コードと在庫のルールはそろっているか
- 稼働後に、誰がエラーを見るか（決まらなければ、つなぐ範囲を小さくする）
今日できること｜チャネルの棚卸し
1時間あれば、次の表を埋められます。
| チャネル | 月の受注件数・取込の方法 | 1か月の手作業の時間 | 困っていること |
|---|---|---|---|
| （例）Amazon | 1,200件・CSVを手で取込 | 20時間 | 在庫のずれで欠品 |
件数と手作業の時間が大きいチャネルが、最初につなぐ候補です。
「困っていること」が在庫なら在庫の同期から、会計なら入金の照合から始めます。
よくある質問
Q1. どのモールやカートでも連携できますか
多くのチャネルとつなげますが公式コネクタの対応先は限られます。
Oracleのヘルプの一覧には、Amazon・Shopify・eBayなどが載っています。
楽天市場やYahoo!ショッピングは、iPaaSや受注管理のシステムを経由する構成が現実的です（第2章）。
Q2. 受注の一元管理は、何から始めればよいですか
「何を一元管理したいか」を決めることからです。
在庫なのか、会計への転記なのか、出荷なのか。
目的が決まると、3つの層のどこから始めるかが見えてきます。
Q3. いまのモールやカートは、そのまま使い続けられますか
多くの場合は使い続けたままNetSuiteとつなげます。
販売の入口はそのままに、裏側の受注・在庫・会計をNetSuiteでまとめる形が一般的です。
Q4. NetSuiteの費用はどれくらいかかりますか
ミニマム構成で月額20万円〜が出発点です。
使うモジュール・ユーザー数・オプションで変わり、構成によっては月額数百万円規模になることもあります。
連携のツールや開発の費用は別にかかり、外部連携の開発が導入費用の約7割を占めた支援事例もあります（3-1）。
Q5. 連携は社内だけで作れますか
標準的な構成なら社内主導で進められる場合もあります。
チャネルが多い場合や、業務の流れが複雑な場合は、設計の段階でつまずきやすくなります。
連携の経験がある相手と、設計だけでも一緒に見ると安全です。
Q6. 以前に作ったSOAPの連携は、使い続けられますか
2028.2のリリースで使えなくなる予定です。
Oracleのヘルプでは、SOAPの連携はRESTへの移行を早めに計画するよう案内されています（第2章）。
まとめ
- EC連携は、受注・基幹会計・物流の3つの層で考える
- 方式は、NetSuite Connector・iPaaS・個別の開発の3つ。公式コネクタに楽天市場とYahoo!ショッピングは見当たらない
- 方式を決めるのは、何を一元管理したいかと、チャネルごとの件数
- 個別の開発はRESTとOAuth 2.0で作る。SOAPは2028.2で使えなくなる予定
- つながった後は、守り→攻め→次へとデータの使い道が広がる
公式でつなげるチャネルは、7つのうちどれか。
残りのチャネルの件数と手作業の時間は、どれほどか。
その2つを書き出すことが、方式を選ぶ最初の作業です。
もう少し詳しく知りたい方へ
チャネルの棚卸しから、方式の選び方、連携の開発まで、ご相談をお受けしています。
チャネル別の記事：
