Amazonでの販売が伸びるほど、注文・在庫・精算のデータをNetSuiteに反映する作業は重くなります。
その負担を減らす方法の一つが、Celigo（セリゴ）の「Amazon – NetSuite Integration App」です。Amazonとの連携を、プログラミングなしで構築できる仕組みです。
この記事では、このAppで具体的に何ができるのかを、実装目線で解説します。とくに掘り下げるのは、次の3つの機能です。
- settlement照合：Amazonの精算データを自動でNetSuiteと突き合わせる
- FBA転送：NetSuiteからAmazon倉庫への在庫補充を扱う
- virtual variations：色・サイズ違いなどの商品バリエーションを同期する
なお、「そもそもCeligoとは何か」を知りたい方は、別記事【Celigoとは｜NetSuite連携を加速するiPaaS】で基礎から解説しています。「Celigo以外の連携方法とも比べたい」方は、別記事【NetSuiteとAmazonを連携する3つの方法】をご覧ください。
この記事は、すでにCeligoを連携の候補として考えている方に向けた、一段深い実装ガイドです。
この記事で分かること
（読了の目安：約10分）
Celigo Amazon-NetSuite Appとは（30秒で要点）
最初に、このAppの要点を30秒で押さえます。
Celigoの「Amazon – NetSuite Integration App」は、AmazonセラーセントラルとNetSuiteをつなぐアプリです。注文・商品・在庫・精算などのデータを、自動でやり取りできます。
あらかじめ用意された連携の型（プリビルトの「フロー」）を設定して使うため、ゼロから連携を開発するより、早く始められます。
ポイントは、扱えるデータの幅が広いことです。
- 注文（Amazonで売れた商品の情報）
- 商品（NetSuiteの商品マスタ）
- 在庫（在庫数の更新）
- 精算（Amazonからの入金・手数料の明細）
「手作業の転記をなくしたい」「販売が増えてもバックオフィスの手間を増やしたくない」。そんな課題を持つ企業が、このAppの主な対象です。
CeligoそのものやiPaaS（複数システムをクラウド上でつなぐ仕組み）の基礎は、別記事【Celigoとは】で解説しています。ここでは、Appの機能そのものに絞って見ていきます。
何が連携できるか【機能別対応一覧表】
まず、このAppで連携できるデータの全体像を、表で俯瞰します。個別の機能は、このあと順番に解説します。
| 連携データ | 内容 | 対応状況 |
|---|---|---|
| 注文 | Amazonの注文をNetSuiteへ取り込む | MFN・FBA・SFPの注文に対応 |
| 商品 | NetSuiteの商品・画像・カテゴリ・属性をAmazonへ同期 | NetSuiteの全アイテム種別に対応。virtual variations機能あり |
| 在庫 | 在庫数の更新 | 単一・複数の倉庫ロケーションに対応 |
| 税 | 売上税の計算・レポート | NetSuite（SuiteTax）またはAmazonの税レポートを利用 |
| 精算（settlement） | 精算レポートの取得と照合 | 自動取得し、仕訳を作成して照合 |
| FBA在庫補充 | Amazon倉庫への在庫転送 | NetSuiteから入庫計画を生成、入荷時に受領を自動作成 |
（出典：Celigo公式サイト Amazon – NetSuite Integration App）
ここで出てきたMFN・FBA・SFPは、Amazonの出荷方式です。
- MFN（Merchant Fulfilled Network）：自社の倉庫から出荷する方式
- FBA（Fulfillment by Amazon）：Amazonの倉庫に在庫を預け、配送を代行してもらう方式
- SFP（Seller Fulfilled Prime）：自社倉庫から出荷しながら、Primeマークを付けられる方式
この表はあくまで標準機能の俯瞰です。実際に何をどこまで連携できるかは、自社の業務要件と設定によって変わります。導入前の確認をおすすめします。
それでは、注目度の高い3つの機能を順番に見ていきます。
settlement照合｜Amazon精算を自動で消し込む
最初は、経理の負担に直結するsettlement照合です。
settlement（精算） とは、Amazonからの入金や手数料の明細をまとめたデータのことです。Amazonは売上から手数料などを差し引いて、まとめて入金します。その内訳を記録したのが精算レポートです。
この精算を手作業でNetSuiteと突き合わせるのは、地道で骨の折れる作業です。入金額と個々の注文・手数料が一致しているかを、ひとつずつ確認する必要があるからです。
Celigoのアプリは、この作業を自動化します。具体的には、次の流れです。
- Amazonの精算レポートを自動で取得する
- その内容をもとに、NetSuiteに仕訳（journal entry）を作成する
- 入金額と明細を照合（reconciliation＝消し込み）する
ここで照合（reconciliation） とは、「帳簿上の数字」と「実際の入金」が合っているかを突き合わせる、経理の作業を指します。
この自動化により、キャッシュフローの管理がしやすくなり、支払いの食い違いも見つけやすくなります（出典：Celigo公式サイト）。
ただし、ひとつ大切な注意点があります。
settlementが「自動で、正しく」合うかどうかは、Appの性能だけでは決まりません。Amazonの手数料・返金・各種調整を、NetSuiteのどの勘定科目に対応づけるか。この設計が決まっていて初めて、自動照合は意味を持ちます。
そして、この設計は経理と情シスの境界領域にあります。技術だけでも、経理だけでも、きれいには解けません。両者がすり合わせて初めて、自動化が現場で回り始めます。ベンチャーネットは、その間をつなぐ役割も含めて連携を設計します。
FBA転送｜NetSuiteからAmazon倉庫への在庫補充
次は、在庫補充にかかわるFBA転送です。
FBA（Amazonの倉庫に在庫を預ける方式）を使う場合、自社からAmazonの倉庫へ在庫を送る作業が定期的に発生します。この補充の流れを、NetSuite側から扱えるのがこの機能です。
具体的には、次のことができます。
- NetSuiteの発注データをもとに、Amazonへの入庫計画（shipment plan） を作成する
- Amazonが在庫を受け取ると、NetSuiteに入荷（item receipt） を自動で作成する
ここで入庫計画（shipment plan） とは、「どの商品を、どれだけ、どのAmazon倉庫へ送るか」をまとめた計画のことです。入荷（item receipt） は、その在庫がAmazon側で受領されたことをNetSuiteに記録する処理です。
この機能により、Amazon倉庫への在庫移動を、NetSuiteの在庫データと連動させながら進められます（出典：Celigo公式サイト）。
在庫の動きが手作業の記録に頼らなくなるため、FBAの在庫数とNetSuiteの在庫数のずれを抑えやすくなります。
なお、自社で使えるかを見極めるポイントは、出荷方式の構成です。FBAだけなのか、自社出荷（MFN）と混在しているのか。混在の場合は、それぞれのデータの流れを整理してから連携を設計すると、後の手戻りを防げます。
virtual variations｜商品バリエーションの同期
3つ目は、商品の持ち方にかかわるvirtual variationsです。やや専門的ですが、つまずきやすい部分なので、かみ砕いて説明します。
まず前提として、Amazonでは「Tシャツ（親）」の下に「赤・M／赤・L／青・M…（子）」という親子のバリエーションを持ちます。
一方NetSuiteでは、こうしたバリエーションをmatrix item（マトリックスアイテム） という仕組みで持つのが一般的です。matrix itemとは、色やサイズの組み合わせを一つの親商品にまとめて管理する仕組みです。
ところが、すべての企業がmatrix itemを使っているわけではありません。色・サイズ違いを、それぞれ独立した在庫アイテムとして管理している企業もあります。
このとき役立つのがvirtual variationsです。
virtual variationsとは、Amazonの商品バリエーションを、NetSuite側で同期し続ける機能です。NetSuiteで（matrixではない）在庫アイテムとして設定されている場合に、その親子関係を保ったまま同期します（出典：Celigo公式サイト）。
つまり、NetSuiteのmatrix item機能を使っていなくても、Amazonの親子商品と連携できる、ということです。
ここでの見極めポイントは、「自社の商品を、NetSuiteでどう持つか」を連携の最初に決めることです。matrix itemで持つのか、在庫アイテム＋virtual variationsで持つのか。商品構造の設計はあとから変えにくいため、走り出す前に方針を固めておくことが重要です。
導入でつまずきやすい点【App固有の失敗パターン】
ここまで3つの機能を見てきました。どれも強力ですが、Appを入れただけで自動的にうまくいくわけではありません。
これは、不安をあおるために書くのではありません。Appの価値は、入れた後の「設計」と「運用」で決まります。事前に知っておくだけで避けられるつまずきが多いからこそ、現場で見えてくる典型的なパターンを共有します。
ここで扱うのは、Celigo Amazon-NetSuite Appに固有の、実装でつまずきやすい4つの点です。
失敗1：SKU（商品コード）がAmazonとNetSuiteで一致せず、同期が崩れる
こんな状態に心当たりはないでしょうか。
- AmazonのSKUとNetSuiteのアイテムコードがバラバラになっている
- 大文字小文字や全角半角といった表記のゆれを放置している
- 商品を追加するたびに、手で対応づけをしている
連携は、両システムのSKU（商品を識別するコード）を鍵にしてデータを突き合わせます。この鍵がずれていると、注文も在庫も精算も合わなくなります。
原因はAppの性能ではなく、商品マスタの設計にあります。
回避するには、連携を始める前にSKUの命名ルールを統一しておくことです。ベンチャーネットでは、「つなぐ前に、マスタを整える」工程から一緒に進めることを大切にしています。
失敗2：virtual variationsとmatrix itemの設計を決めずに走り出す
次は、商品の持ち方の問題です。
- Amazonの親子商品を、NetSuiteでどう持つかを決めていない
- matrix itemにすべきか、在庫アイテム＋virtual variationsかが曖昧なまま設定を始める
- とりあえず動かしてから考えようとしている
H2-5でも触れたとおり、商品構造の設計はあとから変えにくい部分です。決めずに進めると、在庫数が合わない、商品が二重に作られる、といった手戻りが発生します。
回避の基本は、商品の持ち方を連携設計の最初に決めることです。
どちらが自社に合うかは、商品構成や運用次第で変わります。判断に迷う部分なので、一人で抱え込まず相談しながら決めるのが安全です。
失敗3：settlementの会計処理を、経理抜きで決めてしまう
3つ目は、精算照合の落とし穴です。
- 情シスだけで連携を組み、会計の対応づけを後回しにする
- 手数料・返金・調整を、どの勘定科目に振るか曖昧なまま進める
- 月次で数字が合わず、結局手で直している
settlement照合は、経理と情シスの境界領域にあります。技術だけでも経理だけでも解けません。どちらかが欠けると、「自動化したはずなのに、毎月手作業」という状態に逆戻りします。
回避するには、勘定科目のマッピングを経理と情シスが一緒に設計することです。ベンチャーネットは、この両者をつなぐ翻訳役としても伴走します。
失敗4：全フローを一度に有効化し、エラーの切り分けができなくなる
最後は、実装の進め方の問題です。
- 注文・在庫・商品・税・精算の全フローを同時にONにする
- 本番でいきなり、すべてを一度に回す
- エラーが出ても、どのフローが原因か特定できない
連携のフローは、互いに影響し合います。一気に動かすと、問題が起きたときの切り分けが難しくなります。
回避の定石は、注文同期のような一つのフローから始め、確認しながら範囲を広げていくことです。
完璧な状態を一度に目指すより、まず一つ動かして、確かめながら磨いていく。連携では、この進め方が結局いちばん早く、確実です。
ここまで4つのつまずきを見てきました。共通しているのは、どれも「Appの問題」ではなく「設計と進め方の問題」だということです。
機能は強力です。だからこそ、その力を活かせるかどうかは、自社の業務にどう合わせて設計するかにかかっています。
そして、その設計は一人で抱え込む必要はありません。ベンチャーネットは、NetSuiteの導入から、その先のAmazon連携の設計・運用まで、一緒に考える伴走者でありたいと考えています。
よくある質問（FAQ）
Celigo Amazon-NetSuite Appについて、よく寄せられる質問にお答えします。
Q1. 日本のAmazon（amazon.co.jp）でも、CeligoのAppは使えますか？
対応の可否は、対象とするマーケットプレイスやコネクタの設定によって変わります。導入前の確認をおすすめします。
Celigoは海外発のサービスです。日本のAmazonや日本固有の要件に対応できるかは、自社の構成にあわせて事前に確認するのが確実です。なお、連携方法そのものを比較したい場合は、別記事【NetSuiteとAmazonを連携する3つの方法】が参考になります。Oracle純正コネクタの日本対応も含めて整理しています。
Q2. NetSuiteのmatrix itemでないと、Amazonの商品バリエーションは連携できませんか？
いいえ。matrix itemでなくても連携できます。
Amazonの商品バリエーションが、NetSuite側で（matrixではない）在庫アイテムとして設定されている場合です。このときvirtual variations機能で、親子関係を保ったまま同期できます（出典：Celigo公式サイト）。どちらの持ち方が自社に合うかは商品構成次第なので、連携の設計を始める前に方針を決めておくことが重要です。
Q3. Amazonのsettlement（精算）レポートは、本当に自動で会計と照合できますか？
精算レポートを自動で取得し、仕訳を作成して照合する機能があります（出典：Celigo公式サイト）。
ただし、自動で「正しく」合うかは、設計次第です。SKUの整合と、手数料・返金・調整をどの勘定科目に対応づけるかを、経理と情シスで事前に決めておく必要があります。この設計ができていれば、月次の照合作業を大きく減らせます。
Q4. Celigoの費用はどのくらいですか？
利用する機能や連携の規模によって変わります。一律の公開価格はなく、要件に応じた見積もりが必要です。
具体的な費用感は、連携したいデータの範囲（注文だけか、在庫・精算まで含めるか）や、つなぐシステムの数を整理したうえで確認するのが確実です。費用だけで判断せず、自社の業務に必要な範囲を見極めることをおすすめします。
まとめ｜Appは強力、設計は一人で抱えなくていい
Celigoの「Amazon – NetSuite Integration App」は、注文・商品・在庫・精算を自動で連携できる、実用的なアプリです。
とくにこの記事で見てきた3機能は、Amazon販売のバックオフィスを大きく軽くします。
- settlement照合：精算の消し込みを自動化する
- FBA転送：Amazon倉庫への在庫補充をNetSuiteと連動させる
- virtual variations：matrix itemでなくても商品バリエーションを同期する
ただ、この記事でいちばんお伝えしたかったのは、機能の便利さではありません。
連携の成否を分けるのは、「自社のAmazon業務の、どこを、どうつなぐか」という設計です。SKUの整合、商品の持ち方、精算の会計処理、フローを動かす順番。どれも、Appの機能そのものより、設計と進め方の問題でした。
そして、その設計は一人で抱え込む必要はありません。
ベンチャーネットは、NetSuiteの導入から、その先のAmazon連携の設計・運用まで、業務全体を見渡して伴走します。
- これから連携を考える方 へ：まずは「Amazon業務のうち、何をNetSuiteとつなぐ必要があるか」の棚卸しから、一緒に整理できます。
- NetSuiteの導入そのものから検討したい方 へ：連携の土台となるNetSuiteの導入支援も承っています。
- 既存のNetSuiteに、独自の連携を組み込みたい方 へ：アドオン開発・API連携を支援する「NetSuiteリブート」もご相談いただけます。
「何から手をつければいいか分からない」段階でも構いません。自社だけで判断が難しいと感じたら、お気軽にご相談ください。一緒に、つながる業務の形を考えていきましょう。
