月末、経理の担当者がAmazonの精算レポートを開いています。
入金額が、帳簿の売上と合わない。
手数料、返金、調整。差の理由を一行ずつ探す作業が、売上が伸びるほど重くなっていきます。
CeligoのAmazon – NetSuite Integration Appとは、AmazonとNetSuiteをつなぐアプリです。
Amazonのセラーセントラルとの間で、注文・商品・在庫・精算のデータを自動でやり取りします。
用意された連携の型（フロー）を設定して使うため、ゼロから開発するより早く始められます。
ただ、入れただけでは、冒頭の差は消えません。
アプリの価値は、入れる前に決める3つで決まります。
SKUの付け方、商品の持ち方、そして精算と勘定科目の対応です。
では、この3つが決まっていないまま動かすと、どこで崩れるのか。
この記事で分かること
- このアプリでつなげるデータの全体像
- 3つの機能（settlement照合・FBA転送・virtual variations）の仕組み
- ほかの方法と比べた、自社に合うかの判断の物差し
- 費用と期間を左右する4つの要因と、フローを動かす順番
- よくある3つの失敗と避け方
CeligoそのものはCeligoとはで、Celigo以外の方法との比較はNetSuiteとAmazonを連携する3つの方法で扱っています。
何がつなげるか｜機能の一覧
| データ | 中身 |
|---|---|
| 注文 | MFN・FBA・SFPの注文をNetSuiteへ取り込む |
| 商品 | NetSuiteの商品・画像・カテゴリ・属性をAmazonへ同期。NetSuiteの全品目の種類に対応 |
| 在庫 | 単一・複数の倉庫の在庫数を更新。在庫品・マトリクス・キットなどに対応 |
| 税 | SuiteTaxまたはAmazonの売上税のレポートで計算・報告 |
| 精算 | 精算レポートを取得し、仕訳を作成 |
| 入金・返金 | 注文の入金をNetSuiteに作成。返金や調整の手数料も処理 |
| FBAの在庫補充 | NetSuiteから入庫計画を作り、受領時に入荷を作成 |
| 複数のアカウント | 複数のAmazonのアカウントをNetSuiteにつなぐ |
（出典：Celigo公式サイト、2026年9月確認）
言葉を先にそろえておきます。
- MFN（Merchant Fulfilled Network）：自社の倉庫から出荷する方式
- FBA（Fulfillment by Amazon）：Amazonの倉庫に在庫を預け、配送を任せる方式
- SFP（Seller Fulfilled Prime）：自社の倉庫から出荷しながら、Primeの表示を付けられる方式
- SuiteTax：NetSuiteの税の計算の仕組み
税の機能は、公式の説明が米国の売上税を想定した書き方です。
日本の消費税の扱いは、提供元に聞いてください。
settlement照合｜Amazonの精算を帳簿と突き合わせる
settlement（精算）は、Amazonからの入金と手数料の明細をまとめたデータです。
Amazonは売上から手数料などを差し引き、まとめて入金します。
冒頭の担当者が一行ずつ探していたのは、この差し引きの中身でした。
アプリの流れは、次のとおりです（出典：Celigo公式サイト、2026年9月確認）。
- Amazonの精算レポートを自動で取得する
- その内容から、NetSuiteに仕訳を作る
- 注文の入金を作り、返金や調整の手数料も処理する
照合（reconciliation）は、帳簿の数字と実際の入金が合っているかを確かめる、経理の作業です。
公式は、資金の流れの管理がしやすくなると説明しています。
ただし、自動で「正しく」合うかは、アプリだけでは決まりません。
手数料・返金・調整を、NetSuiteのどの勘定科目に対応させるか。
それが決まって初めて、自動化が意味を持ちます。
アプリがすることと人が先に決めることを分けると、次のとおりです。
勘定の対応を決める手順
- 直近の精算レポートから、出てくる項目（手数料・返金・調整など）を洗い出す
- 項目ごとに、NetSuiteの勘定科目と、税の扱いを決める
- どの単位で仕訳を作るか（精算ごと・日ごとなど）を決める
- 1か月分を手で計算した結果と、アプリの仕訳を突き合わせる
項目の洗い出しには経理の担当が、仕訳の単位の設定には情報システムの担当が要ります。
片方だけで決めると、後から直す手間が大きくなります。
銀行の入金との消込の全体は、NetSuiteの銀行連携・自動消込ガイドで扱っています。
FBA転送｜NetSuiteからAmazonの倉庫へ在庫を補充する
FBAを使うと、自社からAmazonの倉庫へ在庫を送る作業が定期的に発生します。
この補充の流れを、NetSuiteの側から扱えます。
- NetSuiteから、Amazonへの入庫計画（shipment plan）を作る
- Amazonが在庫を受け取ると、NetSuiteに入荷（item receipt）を作る
入庫計画は、どの商品をどれだけ、どのAmazonの倉庫へ送るかをまとめた計画です。
入荷は、その在庫をAmazon側が受け取ったことを、NetSuiteに記録する処理です。
Celigoには、FBA向けの連携テンプレート「NetSuite – Amazon FBA」もあります。
発注書から入庫計画を作る流れや、Amazonの出荷をNetSuiteの配送として取り込む流れが用意されています。
エラーの管理は、AIと機械学習で強化されていると案内されています（出典：Celigo公式サイト、2026年9月確認）。
設計を分けるのは、出荷の方式の組み合わせです。
FBAだけか、自社出荷（MFN）と混ざっているか。
混ざっているなら、それぞれのデータの流れを分けて描いてから設計します。
在庫の管理の全体は、NetSuiteの在庫管理でできることをご覧ください。
virtual variations｜商品のバリエーションを同期する
Amazonでは、「Tシャツ（親）」の下に「赤・M」「青・L」（子）のような親子の商品を持ちます。
NetSuiteでは、これをマトリクス品目（matrix item）で持つのが一般的です。
色やサイズの組み合わせを、1つの親の商品にまとめて管理する仕組みです。
ただ、色やサイズ違いを、それぞれ独立した在庫品として管理している会社もあります。
このとき使うのがvirtual variationsです。
Celigoの公式では、次の場合に同期を保つ機能と説明されています（出典：Celigo公式サイト、2026年9月確認）。
Amazonの商品のバリエーションが、NetSuiteでマトリクスではない在庫品として設定されている場合です。
マトリクス品目を使っていなくても、Amazonの親子の商品とつなげます。
商品の持ち方は、後から変えにくい部分です。
どちらで持つかを、連携の最初に決めます。
| 持ち方 | 考えやすい会社 | 決めるときの論点 |
|---|---|---|
| マトリクス品目 | これからNetSuiteで商品を作る。色・サイズの組み合わせが多い | 既存の商品を移す手間 |
| 在庫品＋virtual variations | すでに色・サイズ違いを独立した品目で持っている | Amazonの親子とNetSuiteの品目の対応表を保てるか |
商品の構成に加えて、Amazon以外のチャネルでの持ち方も、選ぶ材料になります。
判断の物差し｜Celigoのアプリが合うか
| 自社の条件 | 合う方法 |
|---|---|
| FBAを使い、精算の照合まで自動にしたい | Celigoのアプリ |
| Amazon以外にもつなぐシステムが多く、1つの基盤で管理したい | Celigo（iPaaSとして広げる） |
| 注文と在庫の同期が中心で、Oracleの純正で済ませたい | Oracle純正のNetSuite Connector（対応先にAmazonがある） |
| 独自の値付けやセット商品など、型に合わないルールが多い | REST APIでの個別の開発 |
| 月の注文が少なく、精算も月に数回 | 連携しない。CSVの取込で足りることがある |
iPaaSは、複数のシステムをクラウド上でつなぐ仕組みのことです。
Oracle純正のNetSuite Connectorの対応先には、Amazonが含まれています。
（出典：Oracle NetSuiteヘルプ、2026年9月確認）
iPaaSどうしの違いはCeligo vs Boomi vs Workatoで、CSVの取込はNetSuiteのCSVインポートで扱っています。
これから入れる会社と、すでに使っている会社
これから入れる会社｜費用と期間を左右するもの
Celigoの費用は、公式では金額が公開されていません。
Standard・Professional・Enterpriseの3つのエディションがあり、つなぐ先（エンドポイント）とフローの数で課金すると案内されています。
30日間の無料トライアルもあります（出典：Celigo公式サイト、2026年9月確認）。
アプリの費用とは別に、連携を設計して動かす費用がかかります。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットの経験では、費用と期間を左右する要因は4つです。
- 業務の範囲：注文だけか、在庫・FBAの補充・精算まで含めるか
- 開発の量：アプリの型で足りるか、型に合わないルールを開発で補うか
- 社内の体制：情報システムの担当が少ないと、支援を厚くするぶん期間も延びやすい
- ユーザー数：受入テストと教育の工数、社内の調整の時間が増える
Amazonの連携で差がつきやすいのは、2つ目の開発の量です。
見積もりの前に、次の3つを書き出しておくと話が早く進みます。
- つなぎたいデータ（注文だけか、在庫・精算まで含めるか）
- Amazonのアカウントの数と、出荷の方式（FBA・MFN・SFP）
- Amazon以外に、将来つなぐ予定のシステム
すでにCeligoを使っている会社
NetSuiteのSOAPのWebサービスは、2028.2のリリースで使えなくなる予定です（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
Celigoは、2026年9月にNetSuiteのREST APIに対応しました。
OAuth 2.0には、10月のリリースで対応する予定と案内しています（出典：Celigo公式ヘルプ、2026年9月確認）。
OAuth 2.0は、パスワードを渡さずに、アクセスの許可を与える認証の方式です。
自社のフローがどの接続の方式を使っているか、一覧にしておきます。
認証の変更の全体は、NetSuite認証の「2027年問題」で扱っています。
毎月手で直している精算や在庫の件数も、あわせて数えます。
件数が多いなら、勘定の対応やSKUのルールを見直す時期です。
前の担当者やパートナーが組んだフローの中身が分からない場合は、引き継ぎの棚卸しから始めます。
よくある3つの失敗
冒頭の「どこで崩れるのか」の答えは、次の3つに集まります。
失敗1：SKUがAmazonとNetSuiteで一致せず、同期が崩れる
起きること：注文も在庫も精算も合わない。商品を足すたびに、手で対応づけている。
原因：連携はSKU（商品を見分けるコード）を鍵に突き合わせる。大文字・小文字や全角・半角の揺れを放置していた。
避け方：連携を始める前に、SKUの付け方のルールを1つに決めます。
既存の商品は、対応表を作ってから移します。
失敗2：商品の持ち方を決めずに走り出す
起きること：在庫の数が合わない、商品が二重に作られる、といった手戻りが起きる。
原因：マトリクス品目にするか、在庫品＋virtual variationsにするかを決めないまま設定を始めた。
避け方：商品の持ち方を、連携の設計の最初に決めます。
代表的な商品で試してから、全体に広げます。
失敗3：精算の会計処理を、経理抜きで決める
起きること：月次で数字が合わず、「自動にしたはずなのに毎月手で直す」状態に戻る。
原因：情報システムの担当だけで連携を組み、手数料・返金・調整の勘定科目の対応を後回しにした。
避け方：勘定科目の対応表を、経理と情報システムの担当が一緒に作ります。
1か月分の精算レポートで、手の計算と突き合わせてから本番に移ります。
ベンチャーネットならこう見る｜「決める3つ」の後に「1フローずつ」
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
特定の連携ツールに誘導しない立場です。
仕事の多くは、ゼロからの導入より、他社のあとの引き継ぎや、ほかのシステムとの連携が占めます。
Amazonの連携も、その「つなぐ」仕事の代表です。
型1：先に決める3つ
SKUの付け方、商品の持ち方、精算の勘定の対応。
この3つが決まるまで、アプリの設定には入りません。
第7章の3つの失敗は、どれもこの3つの決め漏れから起きています。
型2：1フローずつ広げる
注文の同期から始め、在庫とFBAの補充、精算の仕訳の順に1つずつ動かします。
全部のフローを一度に動かすと、エラーの原因を切り分けにくくなります。
1つ動かして確かめ、次へ進む。
遠回りに見えて、結局はこのほうが早く確実です。
型に合わないルールが出てきたら、「標準に合わせる／開発する／残す」のどれかに決めます。
アプリの型に業務を寄せるか、REST APIで開発するか、手作業やCSVの取込で残すか、です。
進め方は、週次の定例と課題の管理表で共有します。
エラーを誰が見て誰が直すかも、この表で決めます。
要件を伺うのは、営業ではなく導入コンサルタントです。
最初の打ち合わせでは、主に次の3つを伺います。
- Amazonの業務で、手間と損が大きいのはどこか（転記・在庫のずれ・精算の照合）
- SKUと商品の持ち方は、いまどうなっているか
- 精算の勘定の対応を、経理の担当が見ているか
今日できること｜精算1回分の棚卸し
1時間あれば、直近の精算レポート1回分で次の表を作れます。
| 精算の項目（例） | 件数・金額 | NetSuiteの勘定科目 | 決まっているか |
|---|---|---|---|
| （例）販売手数料 | 320件・48万円 | 支払手数料 | 決まっている |
「決まっているか」が空欄の項目が、連携の前に経理と決める論点です。
あわせて、Amazonの出品のSKUとNetSuiteの品目のコードを10件並べ、揺れがないかを見ます。
この2つで、先に決める3つのうち2つの現状が分かります。
よくある質問
Q1. 日本のAmazon（amazon.co.jp）でも使えますか
Celigoのヘルプでは対応先に日本が挙がっています。
ただし日本では、商品の登録で扱えるカテゴリーは衣料（Clothing）のみと記載されています（出典：Celigoヘルプ、2026年9月確認）。
自社の商品の登録や、日本固有の要件への対応は、導入前に提供元に聞いてください。
Oracle純正のコネクタを含む比較は、NetSuiteとAmazonを連携する3つの方法で扱っています。
Q2. マトリクス品目でないと、Amazonの商品のバリエーションはつなげませんか
いいえ。マトリクス品目でなくてもつなげます。
NetSuite側で在庫品として設定されていれば、virtual variationsで同期を保てます（第4章）。
Q3. 精算レポートは、本当に自動で会計と照合できますか
精算レポートを取得し仕訳を作る機能があります。
自動で正しく合うかは、SKUの整合と勘定科目の対応の設計次第です（第2章）。
Q4. Celigoの費用はどのくらいですか
金額は公開されておらず見積もりが必要です。
3つのエディションがあり、つなぐ先とフローの数で課金されます。
30日間の無料トライアルもあります。
連携の設計と開発の費用は別にかかり、業務の範囲・開発の量・社内の体制・ユーザー数で変わります（第6章）。
Q5. NetSuiteのSOAPの終了は、Celigoの連携に影響しますか
CeligoはNetSuiteのREST APIへの対応を始めています。
自社のフローの接続の方式を一覧にし、提供元の案内に沿って移行の計画を立ててください（第6章）。
Q6. 全部のフローを一度に動かしてもよいですか
おすすめしません。
注文の同期から始め、在庫・精算へ1つずつ広げると、エラーの原因を切り分けやすくなります（第8章）。
まとめ：アプリは強力、成否は設計で決まる
- CeligoのAmazon – NetSuiteアプリは、注文・商品・在庫・精算をつなぐ
- settlement照合で、精算レポートの取得と仕訳の作成を自動にできる
- FBA転送で、入庫計画と入荷をNetSuiteの在庫と連動させられる
- virtual variationsで、マトリクス品目でなくても商品のバリエーションを同期できる
- 成否は、先に決める3つ（SKU・商品の持ち方・勘定の対応）と、1フローずつ広げる順番で決まる
冒頭の担当者が探していた入金と売上の差は、勘定の対応が決まって初めて、自動で説明がつくようになります。
まず直近の精算レポート1回分で、勘定科目の対応を書き出してください。
もう少し詳しく知りたい方へ
SKUと勘定の設計から、フローを動かす順番、独自の連携の開発まで、ご相談をお受けしています。
関連する記事：
