ネクストエンジンAPIは、ネクストエンジンで管理する受注・在庫・商品などのデータを、基幹システム、WMS、POSなどと連携するアプリを開発するためのインターフェースです。定期的なデータ受け渡しで足りるならCSV、既存アプリで要件を満たせるならアプリ、独自の項目・処理・双方向連携が必要ならAPIによる開発を検討します。
この記事では、ネクストエンジンAPIで連携できるデータの方向、連携方式の選び方、独自開発前に整理すべき内容、開発アプリの公開形態によるAPI通信費用を順に解説します。
ネクストエンジンAPIでできる連携
ネクストエンジンAPIは、ネクストエンジンアプリの開発に使うインターフェースです。ネクストエンジン本体にない処理を追加したり、外部システムとの間でデータを受け渡したりするために利用します。
対象になり得るのは、EC店舗や実店舗の受注、在庫、商品などの運営データです。たとえば、ネクストエンジンの受注情報を基幹システムへ渡す、倉庫側の出荷実績を取り込む、POSの販売による在庫変動を連携するといった構成が考えられます。
ネクストエンジンと外部システムのデータ連携方向
基幹システム連携では、ネクストエンジンから販売管理システムや売上管理システムなどへデータを渡すだけでなく、基幹システムからネクストエンジンへデータを連携することも可能と案内されています。公式の基幹システム連携案内では、CSV連携、アプリ連携、ネクストエンジンAPIを使った独自アプリ開発が選択肢として示されています。
ただし、「双方向に連携できる」という説明だけで、任意の項目を自由に相互更新できるとは限りません。実際に確認すべきなのは、次のような内容です。
- どのデータを連携するか：受注、在庫、商品、出荷実績など
- どちらを正しいデータの基準にするか
- 参照だけでよいか、登録・更新まで行うか
- 連携のタイミングをどうするか
- エラーや重複が起きたときに、どちらのシステムで修正するか
この整理がないままAPI開発を始めると、同じ在庫や受注を双方から更新して不整合が起きる可能性があります。APIは連携の手段であり、業務上のデータ管理ルールまで自動的に決めるものではありません。
CSV・既存アプリ・独自API開発の選び方
連携方式は、必要な自動化の範囲と、既存システムをどこまで変更できるかで判断します。まずCSVで運用できるか、次に既存アプリが要件に合うかを確認し、それでも不足する場合に独自API開発を検討すると、不要な開発を抑えやすくなります。
| 方式 | 向いているケース | 主な確認点 |
|---|---|---|
| CSV連携 | 決まった形式のデータを、必要な頻度で受け渡せればよい | 作成・取り込みの頻度、項目、手作業の有無 |
| 既存アプリ | 対応するアプリがあり、対象データや更新方向が要件に合う | 対応項目、実行方法、費用、既存システムの改修要否 |
| 独自API開発 | 独自の項目・変換・判定・継続的な自動処理が必要 | API仕様、認証、開発体制、双方の改修範囲 |
CSV連携が向くケース
CSV連携は、受注データや在庫情報などを決まった形式で受け渡せればよい場合に向いています。ネクストエンジンから各種データをダウンロードし、外部システムへ取り込む運用が基本です。
出力項目やレイアウトが合わない場合でも、カスタムデータ作成アプリによってCSVテンプレートを調整できる場合があります。連携頻度が1日数回などで足り、担当者による確認やアップロードを許容できるなら、APIを使わずに目的を達成できる可能性があります。
一方、常時自動で同期したい場合や、外部システム側の更新をすぐネクストエンジンへ反映したい場合は、CSVだけでは作業が残りやすくなります。リアルタイム性、処理量、手作業を許容できるかを基準に判断してください。
既存アプリ連携が向くケース
利用中の基幹システム、WMS、POSなどに対応する連携アプリがあり、必要なデータと処理方法が一致するなら、既存アプリの利用が現実的です。自社で認証やエラー処理を設計する必要がなく、独自開発より導入負担を抑えやすい点が利点です。
ただし、連携先の名称や導入実績が掲載されているだけで、そのまま自動連携できるとは判断できません。アプリによって、受注だけ、在庫だけ、出荷実績だけというように対象データが異なります。自動連携に見えても、ボタン操作やCSVを併用する場合があります。
確認する項目は、次のとおりです。
- 受注・在庫・商品・出荷実績のどれに対応するか
- ネクストエンジンから外部システムへの一方向か、双方向か
- API、CSV、バッチ、ボタン操作のどれで動くか
- 利用中の製品版や設定が対象になるか
- アプリ料金、接続先サービス料金、初期設定費用が別にかかるか
また、公式案内でも、利用中システムのカスタマイズが必要になる場合があるとされています。アプリを入れれば完了するとは限らないため、ネクストエンジン側と連携先システム側の両方で確認します。
独自API開発を検討するケース
独自API開発は、CSVや既存アプリでは満たせない要件がある場合に検討します。具体的には、独自のデータ変換や判定処理、複数システムをまたぐ処理、継続的な自動連携、標準の項目では扱えない業務データなどが該当します。
ただし、独自開発ではネクストエンジン側のアプリだけでなく、基幹システムやWMS、POS側の受け入れ機能も必要です。外部システムに必要な項目を保存できない、APIやファイルの取り込み口を追加できないといった場合は、連携先側の改修も発生します。
そのため、独自開発を選ぶかどうかは「ネクストエンジンAPIで実現できるか」だけでなく、「連携先システムを含めて運用できるか」で判断します。
独自API開発を始める前に整理すること
独自開発では、いきなりプログラムを書くのではなく、連携するデータ、更新方向、同期タイミング、エラー時の扱いを先に決めます。これらが決まっていないと、APIを呼び出せても業務で安全に使える連携にはなりません。
連携要件をデータ単位で決める
まず、連携対象をデータ単位で洗い出します。受注を基幹システムへ送るのか、在庫をWMSから受け取るのか、商品情報をネクストエンジンから外部システムへ渡すのかによって、必要なAPIや処理は変わります。
各データについて、次のように決めておくと方式を比較しやすくなります。
- 連携するデータ項目を決める
- 参照だけか、登録・更新も行うかを決める
- データの更新元と更新先を決める
- 同期する頻度やタイミングを決める
- エラー、重複、通信失敗時の再処理方法を決める
たとえば在庫を連携する場合、ネクストエンジンの在庫をWMSへ渡すだけなのか、WMSの入出庫実績を受けてネクストエンジンの在庫を更新するのかで、必要な方向が変わります。受注も、受注の参照だけでよいのか、外部システムから登録やステータス更新を行うのかを分けて考えます。
既存システム側で確認すること
基幹システム、WMS、POS側では、データを受け渡す機能と改修余地を確認します。製品名が連携実績一覧に載っていても、利用中のバージョンや契約プラン、設定まで同じとは限りません。
確認する内容は、次のように整理できます。
- 必要なデータ項目を保存できるか
- 外部からの登録・更新を受け付けられるか
- CSV、API、ファイル転送など利用できる接続方法は何か
- 既存の在庫・受注連携と処理が競合しないか
- 障害発生時に、どの会社・担当者が復旧するか
この確認を省くと、ネクストエンジンからデータを送れても、連携先で取り込めない、項目が欠落する、既存処理と二重更新になるといった問題が起こります。連携アプリの提供会社、ネクストエンジン、既存システムの担当会社の責任範囲も、開発前に決めておくと運用時の判断がしやすくなります。
認証からAPI実行までの位置付け
NEXT ENGINE APIのクイックスタートでは、`access_token`を取得し、商品検索APIをcurlとTypeScriptで実行するまでの流れが示されています。まず認証情報を取得し、その情報を使って対象APIへリクエストを送る、という順序で理解するとよいでしょう。
`access_token`は、APIリクエストを実行する際に使う認証情報です。取得後に商品検索などの対象APIへリクエストを送り、処理結果を確認します。
ただし、アプリ作成時の設定内容、認証に必要な具体的なパラメータ、APIごとの入力項目や実装手順は、利用するAPI仕様に沿って確認する必要があります。クイックスタートで商品検索を実行できても、それだけで受注更新や在庫更新の仕様まで確定するわけではありません。
開発開始前には、次の準備を分けて進めます。
- APIで実現したい業務とデータ項目を決める
- 開発アプリの利用者と公開範囲を決める
- 開発者向けドキュメントで認証と対象APIの仕様を確認する
- テスト用のデータやエラー時の確認方法を用意する
- 本番運用時の監視、再実行、問い合わせ窓口を決める
開発アプリの公開形態とAPI通信費用
独自アプリを運用する場合は、開発費や外部サービス費とは別に、API通信費用が関係することがあります。費用はアプリを誰に公開するかによって扱いが異なります。
公開範囲による通信費用の違い
「すべての企業に公開」は、他社にも公開・販売する形態です。提供されている開発アプリのAPI通信費用の案内では、この公開形態のAPI通信費用は無料とされています。
一方、「特定企業にのみ公開」は、1社だけが利用できる形態です。この場合は、月間のAPIリクエスト回数と通信データ量に応じてAPI通信費用が発生します。
自社専用の連携アプリを作る場合は、通常は特定企業向けの公開形態を前提に、開発費だけでなく運用後の通信量も見積もります。ここでいうAPI通信費用は、アプリの開発費、アプリ自体の販売価格、WMSやPOSなど外部サービスの利用料とは別の費用です。
特定企業向けアプリの料金の見方
提供ページに掲載されている特定企業向けアプリの料金は、次のとおりです。金額は税抜の月額です。表のリクエスト回数と通信データ量は、それぞれ別の料金判定に使われます。両方の利用量を一つの行の条件として組み合わせるものではありません。
| 料金判定の区分 | 月間APIリクエスト回数 | 月間通信データ量 | 月額料金（税抜） |
|---|---|---|---|
| 無料 | 1〜1,000回 | 3GBまで | 無料 |
| 第1段階 | 1,001〜2,000回 | 4GBまで | 5,000円 |
| 第2段階 | 2,001〜5,000回 | 5GBまで | 10,000円 |
| 第3段階 | 5,001〜10,000回 | 6GBまで | 30,000円 |
| 要相談 | 10,001回以上 | 6GB以上 | 要相談 |
料金は、リクエスト回数と通信データ量をそれぞれ料金表に当てはめ、該当する料金のうち高い方を基準にすると案内されています。たとえば、リクエスト回数が無料の範囲でも通信データ量が有料帯に達していれば、通信データ量側の料金が適用されます。反対に、通信データ量が少なくてもリクエスト回数が多ければ、リクエスト回数側の料金が基準になります。
10,001回以上または6GB以上の利用は要相談とされています。なお、料金表では6GBまでの区分と6GB以上の区分が隣り合っているため、6GBちょうどの扱いは契約時に確認が必要です。大量の受注取得や商品データの定期取得を行う場合は、処理頻度や1回あたりの取得量も設計段階で確認します。
利用量を継続して確認する
API通信費用が発生する公開形態では、開発後も利用量を確認します。案内上は、ネクストエンジンの「アプリを作る」内にある「リクエスト履歴」から、APIリクエスト回数と通信データ量を確認できます。
処理を追加したときや取得対象を増やしたときにも利用量を確認すると、料金帯の変化を把握しやすくなります。特に、次の変更は通信量が増えるきっかけになります。
- 取得する受注・商品・在庫の件数を増やす
- APIの実行頻度を上げる
- エラー時の再試行回数を増やす
- 複数の処理を同じアプリに追加する
通信量の確認だけでなく、必要なデータだけを取得できているか、失敗した処理を無制限に再試行していないかも確認します。これにより、費用だけでなくAPI処理の安定性も管理できます。
まとめ
ネクストエンジンAPIは、受注・在庫・商品などのEC運営データを、基幹システム、WMS、POSなどと連携するための仕組みです。定期的な受け渡しならCSV、要件に合う既存アプリがあるならアプリ、独自の項目・変換処理・双方向連携が必要ならAPI開発を検討します。
独自開発では、先にデータ項目、更新方向、同期タイミング、既存システム側の改修可否を整理することが重要です。特定企業向けに公開するアプリでは、APIリクエスト回数と通信データ量のうち高い方を基準にAPI通信費用が決まるため、「アプリを作る」内の「リクエスト履歴」で利用量を継続的に確認します。