冷蔵倉庫の奥で、ハンディ端末の画面が止まる。
電波が届かず、入荷の記録がNetSuiteに送れない。
担当者は紙にメモを取り、事務所に戻ってから打ち直します。
ハンディ連携とは、現場の端末で読み取ったデータを、NetSuiteの在庫や入出庫の記録につなぐことです。
ハンディターミナルは、バーコードを読み取る業務用の携帯端末を指します。
まず純正の機能で足りるかを見て、足りない部分だけを外部の連携で補います。
外部の手段は、API・CSV・国産SuiteAppの3つです。
3つに優劣はありません。
冒頭の倉庫ならCSV、独自の検品が多い会社ならAPIが候補に上がります。
では、自社の現場はどれに当たるのか。
決め手になるのは、端末の機種ではなく「なぜ純正で回らないのか」という原因のほうです。
この記事で分かること
- 純正のバーコード機能で足りなくなる3つの壁
- API・CSV・国産SuiteAppの違いと、原因から手段を選ぶ順番
- 連携の開発が、導入の費用をどう動かすか
- 連携でよくある3つの失敗と、避け方
まず確認｜純正の機能でどこまでできるか
NetSuiteには、在庫管理や入出庫を支える標準の機能があります。
バーコードの読み取りや、在庫の照会・調整も、標準で対応できる部分があります。
すべての会社に外部の連携が要るわけではありません。
標準で要件の何割が満たせるか。それを先に見れば、むだな投資を避けられます。
標準のスキャナ運用は、NetSuite×バーコード／ハンディターミナル活用ガイドで扱っています。
倉庫の現場運用は、NetSuite WMS×バーコード／QRスキャンをご覧ください。
なぜ「純正だけ」で足りなくなるのか
現場でよく挙がるのは、次の3つの壁です。
| 壁 | 起きること |
|---|---|
| オフラインの壁 | 棚の奥や冷蔵設備の中など、電波が届きにくい場所で作業が止まる |
| 日本固有の業務の壁 | 独自の検品のルールや伝票の運用を、標準で吸収しきれない |
| 既存のハンディ資産の壁 | 使い慣れた端末を活かしたいが、標準ではつなげない |
オフラインの壁は、オフィスを基準に考えると見落とします。
常時の通信を前提にした運用は、電波が弱い場所で止まります。
日本固有の業務の壁は、グローバルの標準で作られた機能との差から生まれます。
取引先ごとの検品のルールや、紙の伝票との照合が典型です。
既存のハンディ資産の壁は、現場の慣れと結びついています。
新品への全面入れ替えは、費用も教育の負担も大きい。
こうした壁にぶつかったとき、外部の連携が現実的な手段になります。
3つの壁を並べると、次のとおりです。
外部連携の3つの手段
API連携（REST Web サービス・RESTlet）
APIとは、システム同士がデータをやり取りするための接続口です。
NetSuiteの外部との連携の仕組みは、SuiteTalkと呼ばれます。
- REST Web サービス：NetSuiteが用意する連携の窓口。サーバ側のコーディングやスクリプトの配置が要らない軽い連携で、モバイル端末に向く（出典：Oracle NetSuiteヘルプ、2026年9月確認）
- RESTlet：NetSuite上に自分で作る独自の連携の入口。サーバ上で動くスクリプトで、外部から呼び出せる（出典：同上）
推奨の認証の方式はOAuth 2.0です（出典：同上）。
認証は、接続してくる相手が正しいかを見分ける仕組みです。
リアルタイムに近い形でつなげ、自社の要件に合わせて作り込めます。
その分、開発と保守の費用がかかります。
CSVインポート
CSVは、表の形のデータを受け渡しするシンプルな形式です。
端末で読んだデータをCSVにまとめ、NetSuiteに取り込みます。
Oracleのヘルプでは、CSVインポートは小〜中規模のデータを移すのに向く方法とされています。
1ファイルの上限は25,000件です。取込は保存して後で実行することもできます（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
リアルタイム性は低いものの、電波が不安定な現場でも後でまとめて取り込めます。
手順はNetSuiteのCSVインポートで解説しています。
国産SuiteApp
SuiteAppとは、NetSuiteに追加できる拡張のアプリケーションです。
ハンディ連携に対応した国産の製品も、市場にあります。
ライセンスを契約して設定すれば、開発を抑えて、標準的な入出庫・棚卸を早く始められます。
対応する端末や機能の範囲は、提供元ごとに違います。
比べるときは、次の5つを提供元に尋ねると差が見えてきます。
- 対応する端末の機種と、手持ちの端末が使えるか
- 電波が切れたときに、端末にデータを保てるか
- 日本固有の検品や伝票に、どこまで対応するか
- NetSuiteの更新のとき、誰がいつ動作を見るか
- ライセンスの費用が、端末の台数とユーザー数のどちらで決まるか
選び方はNetSuite SuiteApp.comの選び方で扱っています。
3つの手段の使い分け
向き不向きは、現場の制約と目的で分かれます。
| 軸 | API連携 | CSVインポート | 国産SuiteApp |
|---|---|---|---|
| リアルタイム性 | 高い | 低い（まとめて取込） | 高い |
| オフライン | 標準では弱い（通信前提） | 強い（後で取込） | 製品による |
| 初期の費用・開発 | 高め（開発が要る） | 低い（標準で開始） | 中（ライセンス＋設定） |
| 日本固有の業務 | 高い（作り込める） | 低い（項目の型が決まる） | 中〜高（日本向けなら対応） |
| 記録がそろう早さ | 即時 | 取込の時点まで遅れる | 製品による |
| 向くケース | 独自の要件が強い | まず小さく始めたい | 標準的な運用を早く始めたい |
記録が早く細かくそろうほど、在庫の異常をAIで点検しやすくなります。
使い道はNetSuite×AI活用事例をご覧ください。
判断の物差し｜どの手段が合うか
図の分かれ道を、状況ごとに表にすると次のとおりです。
| 状況 | 合う選択肢 |
|---|---|
| 標準の機能で要件の大半を満たせる | 外部の連携はしない。運用で補う |
| 電波が不安定で、まず小さく始めたい | CSVインポート |
| 標準的な入出庫・棚卸を早く始めたい | 国産SuiteApp |
| 独自の検品や、基幹と密な連携が要る | API連携（RESTlet・REST Web サービス） |
| 倉庫を3PLに任せている | 3PLのシステムとの連携を先に考える |
| 基幹がまだ決まっていない | 端末より先にERPの選定。Odooや国産ERPも比べる |
3PLとの連携はNetSuiteと物流SaaSの連携で扱っています。
連携の全体像はNetSuiteの連携方法まとめをご覧ください。
選ぶときの4つのステップ
- 現場の業務を整理する：どの作業が、どう非効率か
- 通信の環境を測る：電波・Wi-Fiの状況。オフラインが多いならCSVやオフライン対応の方式
- 既存の資産を棚卸しする：活かせる端末と運用。全面刷新が本当に要るか
- 要件の特殊さを見極める：特殊さが高いほどAPI連携が向く
効果の大きさが、かけてよい費用を決める
手作業の転記が減れば、入力ミスが減ります。
ミスが減れば、欠品や過剰在庫が減り、機会の損失やむだな費用も減ります。
現場の「工数が減る」という話は、突き詰めると経営の数字につながっています。
転記が1日30分で済む現場に、大きな開発は見合いません。
逆に、誤出荷が売上や信頼に響いている現場なら、API連携の開発も検討に値します。
連携の開発は、導入の費用を動かす
連携を作るかどうかは、導入の費用にそのまま響きます。
ベンチャーネットが支援したNetSuite導入の費用には、大きな開きがあります。
3名程度・1.5か月で150万円程度から、100名程度・1.5年で2億円程度までです。
2億円程度の事例は、他社のSaaSや顧客独自のシステムとの連携開発があり、うち開発が約7割でした。
150万円程度の事例は、購買・販売だけで、連携も追加の開発もありません。
差を生む要因は、機能範囲・開発（特に外部システム連携）・社内の体制・ユーザー数の4つです。
4事例の中身は、NetSuiteの料金・費用で扱っています。
これから作る会社と、いまの連携を見直す会社
これから作る会社は、標準の機能を試し、足りない作業を一覧にしてから端末を選びます。
通信の環境は、事務所ではなく現場で測ります。
連携の保守を誰が担うかも、作る前に決めておきます。
いまの連携を見直す会社は、連携が止まった記録と原因を集めるところから始めます。
作った担当者がいるか、仕様書が残っているかも見ます。
標準の機能が増えていれば、外部の連携をやめて純正に戻せる場合もあります。
連携の数が減るほど、更新のたびの確認の手間も減ります。
二つの立場ですることを並べると、次のとおりです。
NetSuiteは定期的に更新されます。
備え方はNetSuiteのバージョンアップへの備え方で解説しています。
よくある3つの失敗
失敗1：手段から入ってしまう
起きること：「APIかCSVか」の比較から始め、現場が本当に要る機能が抜け落ちる。使われない連携ができる。
原因：「現場の入出庫を楽にする」目的より、「APIでつなぐ」ことが目的になっている。
避け方：まず、現場の業務のどこがどう非効率かを書き出します。
手段は、その業務をいちばん楽にするものを後から選べば足ります。
失敗2：オフラインの要件と既存の資産を見落とす
起きること：リアルタイム前提で設計したら、倉庫の奥で端末がつながらず作業が止まる。端末を全面刷新して、現場が「前のほうが早い」と敬遠する。
原因：オフィスの環境を基準に設計し、現場の通信と慣れた運用を見ていない。
避け方：設計の前に、現場の通信の環境を測ります。
電波が不安定なら、端末にためて後で取り込む方式を選びます。
活かせる端末と運用は、残す方針で考えます。
失敗3：連携を作って終わりにする
起きること：NetSuiteの更新やマスタの変更で、連携が突然止まる。作った担当者が異動すると、誰も直せない。
原因：連携を「一度作れば動き続けるもの」と考え、保守の体制を決めていない。
避け方：更新時の動作確認の担当と、不具合時の相談先を最初から決めます。
社内にも最低限の仕組みの知識を残し、属人化を避けます。
日本での使い方の3段
- (a) いま日本で使えること：標準のバーコード機能・CSVインポート・REST Web サービス・RESTlet。製品ごとの提供条件は、アカウントの担当に聞く
- (b) 開発で補えること：日本固有の検品や伝票、既存端末とのつなぎは、NetSuiteリブート（アドオン開発）で補える場合がある
- (c) 順次提供されること：純正のモバイルの新しい機能は、日本での提供時期を担当に聞く
開発の考え方はSuiteScript（NetSuiteの開発言語）とはで解説しています。
ベンチャーネットならこう見る｜作業ごとに「標準に合わせる／開発する／残す」
ベンチャーネットは、1つの連携の方法を売り込む立場ではありません。
ハンディ連携の相談でも、端末の前に業務の見える化から入ります。
入荷・検品・ピッキング・棚卸。作業を1つずつ描き、それぞれを3つのどれかに決めます。
- 標準に合わせる：検品のルールを見直し、標準のバーコード機能で回す
- 開発する：APIやアドオンで、日本固有の検品や既存の端末をつなぐ
- 残す：NetSuiteには載せず、いまの端末や運用を続ける
整理整頓の段で、原因を取り違えないようにします。
「入力が遅い」の原因が電波なら、方式の選び方で解けます。
原因が検品のルールの複雑さなら、ルールを見直すだけで足りることもあります。
連携は、作った数だけ保守の手間が増えます。
作らなくてよい連携は、作らないことをお勧めします。
ベンチャーネットの仕事は、ゼロからの導入より、他社のあとの引き継ぎと他システムとの連携が多くを占めます。
要件は、営業ではなく導入コンサルタントが現場で聞き取ります。
既存のシステムとの連携も、導入と同じチームで担います。
今日できること｜現場の作業を1枚に書き出す
入出庫の作業を1つ選び、次の表を埋めてみてください。
| 作業 | いまの手段 | 困っていること | 電波の状況 |
|---|---|---|---|
| （例）入荷検品 | 紙に記入→事務所で入力 | 入力が翌日になる | 倉庫の奥は弱い |
「困っていること」と「電波の状況」が、手段を選ぶ材料になります。
使っている端末の機種と台数、購入した年も書き添えます。
入れ替えの時期が近いなら、刷新と連携を一緒に考える好機です。
3〜5の作業を書き出せば、社内の打ち合わせの資料にもなります。
よくある質問
Q1. NetSuite標準のバーコード機能だけでは、ハンディ運用はできませんか
標準だけで運用できるケースもあります。
在庫の照会やバーコードの標準の機能で、要件によっては足ります。
まず標準でどこまでできるかを見て、足りない部分だけを外部の連携で補います。
Q2. 手持ちのハンディ端末はそのまま使えますか
連携の方式によって変わります。
API連携やCSV取込なら、既存の端末のデータを取り込める場合があります。
特定の端末専用のパッケージ製品もあるため、端末を活かす前提で方式を選びます。
Q3. API・CSV・SuiteApp、結局どれを選べばいいですか
純正で回らない原因で選びます。
「電波が不安定・まず小さく」ならCSV、「独自の要件が強い」ならAPIが目安です。
「標準的な運用を早く」なら国産SuiteAppが合います（第4章の図・第5章）。
Q4. 連携の構築や保守は、社内だけでできますか
保守の体制は事前に決めておく必要があります。
CSV取込のような軽い連携は、社内で運用できることもあります。
API連携やアドオン開発は、NetSuiteの更新への追従も含めて専門の知識が要りがちです。
Q5. APIで連携すると、電波がない場所では使えませんか
通信が前提のため電波が弱い場所では止まりやすくなります。
端末にデータをため、つながった時点で送る設計にするか、CSVでまとめて取り込む方式を選びます（第7章 失敗2）。
Q6. CSVで取り込める件数に上限はありますか
1ファイルあたり25,000件が上限です。
Oracleのヘルプでは、大きなファイルは小さく分けると取込が速くなると案内されています。
Q7. 連携の方式は、後から変えられますか
変えられますが作り直しの費用がかかります。
CSVで始めて、件数が増えたらAPI連携に移す進め方はよくあります。
その場合も、品目のコードや保管場所の番号の付け方は変わりません。
最初にマスタの整え方を決めておくと、方式を変えるときの手戻りが減ります。
まとめ
- まず純正の機能で足りるかを見る
- 純正で足りない壁は、オフライン・日本固有の業務・既存の端末の3つ
- 手段はAPI・CSV・国産SuiteApp。回らない原因から選ぶ
- 連携の開発は導入の費用を大きく動かす。作る前に保守の体制まで決める
冒頭の冷蔵倉庫なら、原因は電波です。
高い開発より先に、CSVでまとめて取り込む方式が候補に上がります。
自社の現場の原因は何か。まず作業を1枚に書き出してみてください。
もう少し詳しく知りたい方へ
現場の業務と既存の端末、NetSuiteの標準の機能を照らし合わせ、必要な連携の形を一緒に考えます。
関連記事：NetSuiteの在庫管理でできること
