ハンディターミナルシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ハンディターミナルシステム開発は、現場の業務と例外を整理し、端末と開発方式を選んだうえで、設計、テスト、段階稼働の順に進めます。この順で進めると、在庫精度と作業効率の安定につながります。

▼全体ガイドの記事
・ハンディターミナルシステム開発の完全ガイド

ハンディターミナルシステム開発の全体像

端末や業務アプリ、上位システム、通信、管理画面を4枚のカードで示した構成図。
端末と業務アプリを、上位システムや通信・管理機能が支えます。

ハンディターミナルシステムは、携帯端末でバーコード、二次元コード、RFIDなどを読み取り、入出荷や在庫の実績を上位システムに登録する仕組みです。

端末や業務アプリに加えて、WMSや基幹システム、無線LAN・モバイル回線を組み合わせます。さらに、管理者画面や端末管理も含めて運用します。

デジタル化する業務の範囲

対象業務は幅広いため、誤出荷や棚卸差異が大きい工程から始めます。

  • 入出荷:入荷検品、棚入れ、ピッキング、出荷検品の記録。
  • 在庫管理:補充、返品、棚卸、棚移動の記録。
  • 製造・配送:部品投入、工程移動、完成品や配送実績の記録。

出荷検品だけを先行し、効果を確認してから入荷や棚卸へ広げる進め方もあります。

製造現場では、シリアル番号やロットまで記録しておくと、トレーサビリティにも活用できます。

導入前に入力回数や検品時間を計測し、再入力件数や在庫更新の遅れも記録しておけば、稼働後の効果を比べられます。

クラウド、パッケージ、スクラッチの選び方

必要な業務の範囲と固有ルールの量で方式を選びます。特に、標準機能で足りるか、連携や設備制御が必要かを見ると、候補を絞り込みやすくなります。

  • クラウドWMS・パッケージ:標準的な入出荷・在庫管理を早く始める場合の候補。
  • ハーフスクラッチ:既存システムの固有ルールを追加開発でつなぐ方式。
  • スクラッチ:特殊なロット管理や独自工程、マテハン制御が必要な場合に検討する方式。

2026年時点では、Android端末を使えるクラウドWMSもあります。たとえば、NSPのLOGIBILITYは、Android 12以上のスマートフォン、タブレット、ハンディ端末に対応します。さらに、LOGIBILITYは入荷・出荷・在庫から必要な機能を選べる方式も案内しています。

冷凍倉庫や屋外では、専用端末の耐環境性を確認します。粉じんや水濡れ、落下が多い現場では、IP等級、耐落下性、読取距離も見ます。そのほか、手袋操作やバッテリー交換性も選定条件になります。

ポイント

導入する業務は、誤出荷や棚卸差異が大きい工程に絞るのが判断の目安です。方式は、標準機能で足りるか、連携や設備制御が必要かで選びます。

ハンディターミナルシステム開発の進め方

要件整理で確認する工程、例外、障害・異常の3分類を中央から結ぶ図。
通常時と例外時の両方を整理すると、画面や処理の抜けを防ぎやすくなります。

開発の成否は、画面を作る前に現場の例外とデータの流れを整理できるかで決まります。

6フェーズごとに完了条件を決めておき、次の工程へ進む前に、関係部門と開発会社の認識をそろえます。関係部門には、現場責任者や情報システム部門、経理・物流管理者が含まれます。

フェーズ1:要件整理と現場の例外の洗い出し

業務フローを作り、例外を含めて、誰が何を読み取るかを決めます。そのうえで、工程、例外、障害・異常の3点を洗い出します。

  • 工程:入荷、検品、棚入れ、補充、ピッキング、出荷、返品、棚卸。
  • 例外:分納、欠品、過剰入荷、バラ出荷、ラベル欠落、ロット・賞味期限違い。
  • 障害・異常:破損、返品、棚移動、通信断、端末故障時の処理。

紙帳票やExcelの項目は、現場の動きに合わせて整理してから画面へ移します。そのため、誰がどこで何を読み、いつ在庫を確定するかを先に決めておきます。

まず、SKU数や1日の入出荷明細数、拠点数を整理します。そのうえで、同時利用者数とバーコード規格を押さえます。ロット・期限・シリアル管理と連携方式も、ここで確認します。

設置環境では、Wi-Fiの死角、端末の利用温度、予備機の有無も確かめます。

例外は通常業務と同じ重要度で扱い、エラー時の承認者も決めておきます。数値が曖昧なままだと、画面の追加や連携の変更が起き、費用と期間が膨らみやすくなります。

フェーズ2:端末と開発方式の実機選定

候補は2〜3種類に絞り、実際の倉庫や店舗で数日試します。カタログからは分からない操作性を、この段階で確かめます。

  • 操作性:手袋でのキー操作、文字サイズ、重量、片手での持ちやすさ。
  • 読取・接続:読取距離と速度、Wi-Fiローミング、スリープ復帰、プリンター接続。
  • 運用耐性:バイブレーション、電池持続時間、交換、落下・水濡れへの耐性。

価格の目安として、ウェルコムデザインの掲載例を見ると、税込7万7,000円のバーコード端末から33万9,900円の堅牢Android端末まであります。いずれも2026年に確認できる参考価格です。

冷凍環境対応のHoneywell CK65には、税込86万2,400円や91万3,000円の掲載例があります(出典:ウェルコムデザイン オンラインショップ、2026年確認)。

端末単価に加えて、クレードルや予備バッテリーの費用も含めます。さらに、保守やMDM、通信費も比べます。

フェーズ3:画面・データ・連携の設計と開発

画面遷移だけでなく、在庫を確定する時点とデータの責任範囲を設計します。入荷予定から出荷実績までのデータを結ぶキーも定めます。キーで結ぶデータの範囲と受け渡しの方式は、設計の段階で整理しておきます。

  • 管理対象:棚番、商品、ロット、期限、作業者、端末、注文、出荷実績。
  • 連携方式:API、CSV、ファイル転送から選ぶ方式と、送受信の頻度。

OMSや販売管理から入荷・出荷予定を受け、端末で実績を登録して、WMSや基幹へ返す流れを明確にします。

通信が不安定な場合は、端末に一時保存し、再送時の重複は取引IDで防ぎます。また、タイムアウト表示や在庫競合、サーバー停止時に作業できる範囲も決めておきます。

配送業務で個人情報、GPS、写真を扱う場合は、端末にデータを残さない設計にします。さらに、認証を強め、MDMによるロックや遠隔消去も設計に含めます。

通信と保存の暗号化、操作ログの監査も、設計書に含めます。どこまで設定するかは、扱う情報の条件に応じて決めます。

フェーズ4:正常系と異常系のテスト

画面の表示だけでなく、実データに近い条件で異常処理を検証します。誤読やスキャン漏れに気づける表示になっているかも、確かめます。

  • 商品・数量:予定外の商品、数量違い、期限切れ、存在しない棚番。
  • 端末・通信:二重読取、通信切断、電池切れ、送信ボタンの連続押下。
  • 在庫処理:在庫引当が競合した場合の処理。

受入テストでは、現場の代表者が一連の業務を操作し、合格条件を数値で判定します。そのなかでは、商品、棚、数量を正しく読めるかも確かめます。

エラーが出たときに次の行動を判断できるか、また復旧後に実績が一度だけ反映されるかを確認します。

管理者画面では、作業状況も確認します。テストデータと担当者、実施日を記録し、結果や残課題、再テスト日も残しておきます。

フェーズ5:段階的な稼働と切替時の混乱の抑制

全拠点と全業務を一日で切り替えず、対象業務や拠点を限定して段階的に導入します。最初の拠点で手順を確かめ、その結果を次の拠点に反映します。

  • 初期確認:端末キッティング、マスタ登録、ラベル発行、問い合わせ対応。
  • 切替時期:繁忙期や棚卸直前、商品入替の集中時期を避ける。
  • 併用期間:旧システムや紙帳票を使う期間。

障害が起きたときの代替手順も、事前に確かめておきます。

切替当日は、現場責任者やシステム担当の連絡先を明確にします。そのうえで、開発会社や端末・ネットワーク担当とも連絡が取れるようにします。

障害に備えて、予備端末と予備バッテリーを用意します。加えて、紙での暫定記録や再入力の手順、出荷を止める判断基準も決めておきます。

稼働後の1〜2か月は、旧システムと新システムのデータの差異を確認します。そのうえで、在庫・出荷・返品実績の突合を定例化します。

フェーズ6:教育とKPIによる現場への定着

相談先や例外処理が分からないと、導入後に利用が進まないことがあります。そのため、作業者と管理者に必要な教育を行います。

  • 作業者向け:入荷、棚入れ、出荷、棚卸、返品、通信断の手順。
  • 管理者向け:マスタ更新、端末追加、アカウント停止、ログ確認、障害切り分け。
  • 習熟確認:新人が一人で操作できるまでの教育時間。

導入後90日間は、検品時間と誤出荷件数を追います。棚卸差異と在庫更新の遅延も、この期間に見ていきます。再入力や端末故障のほか、問い合わせや教育時間も記録します。

改善の判断には、導入台数やアプリ稼働率に加えて、現場の作業結果の数字を使います。

一例として、パナソニック コネクトが公開する舞浜倉庫の事例では、2025年7月時点の想定効果として現場生産性約1.2倍を示しています。

この事例では、入荷作業時間の30%短縮も示されています(出典:パナソニック コネクト、2025年)。自社でも導入前後のKPIを比べ、改善につなげます。

ポイント

6つのフェーズは、それぞれに完了条件を設けてから次へ進みます。迷ったときは、現場の例外と在庫を確定する時点が決まっているかで、進めてよいかを判断します。

ハンディターミナルシステムの費用相場と内訳

導入総額に含める端末・周辺機器、アプリ開発、WMS・基幹連携、マスタ移行を4枚のカードで示した図。
機器以外の開発・連携・移行費も見積もりの範囲に入ります。

費用は、端末台数だけでなく総額で見ます。アプリ開発、WMS・基幹連携、マスタ移行の費用も、対象に含めます。

Wi-Fi・モバイル通信やラベルプリンターに加えて、MDMや保守の費用も見込みます。教育や予備機も、費用に含めます。

公開価格は初期設定や保守範囲が異なるため、見積もりの目安として扱います。

端末・周辺機器の1台あたりの価格

端末価格は、読取機能や利用環境によって幅があります。そのため、一般的な端末と特殊な堅牢端末を分けて見積もります。

  • 一般端末:おおむね7万〜34万円程度が掲載価格の目安です。
  • 堅牢・冷凍対応:特殊仕様では50万〜90万円台もあります。

リサーチノートでは、Android系・業務用端末の税込9万200円〜33万9,900円程度を確認しました。また、Web確認では、税込7万7,000円の簡易端末もありました。

簡易端末は、無線の有無や保証期間が異なります。そのため、端末価格だけでなく仕様の差も確かめます。

周辺機器には、クレードル、充電器、交換バッテリーがあります。さらに、保護ケースやラベルプリンター、アクセスポイントもあります。このほか、SIMやMDM、予備端末もあります。

10台を導入する場合は、故障や充電、繁忙期に備える予備台数を決めます。

購入とレンタルは、3〜5年のTCOで比べます。そのうえで、保守費や電池交換、OSサポート終了後の移行費もTCOに含めます。

クラウド・パッケージの料金体系

料金体系と、端末や通信費の負担先を確認します。月額の表示だけでは比べにくいため、課金の仕組みを細かく見ます。

  • 課金単位:初期費用、拠点、ユーザー、端末、出荷明細、追加機能。
  • 別途費用:端末、ラベルプリンター、通信費、保守範囲。

たとえば、LOGIBILITYは初期費用0円で、フル機能版は月額12万円です。保守サポート込みと案内しています。

一方で、これらは利用者が負担します(出典:NSP「LOGIBILITY」、2026年確認)。そのため、月額料金に含まれる範囲は、見積もりで確認します。

類似サービスでは、初期費用が数万円〜40万円程度、月額が1万〜10万円程度の例があります。料金は、機能や拠点数によって変わります。

端末込みの例では、初期20万円に加えて、1台あたり月額1万8,000円という公開例もあります。ただし、契約期間や保守の範囲が違います。税区分や追加機能も異なるため、一般化はできません。

個別開発と保守の費用の見込み方

開発費は、対象の範囲によって変わります。端末アプリに加えて、WMSや管理画面、APIを含めるかを整理します。さらに、移行や帳票、認証を含めるかも決めます。監視やインフラも、含めるかどうかを確かめます。

  • パッケージ・ハーフスクラッチ:類似相場は120万〜500万円程度。
  • 中規模スクラッチ:500万〜1,500万円程度。
  • 複雑な連携:1,500万〜4,000万円以上、大規模・複数拠点は4,000万円〜1億円以上。

これらは、入出庫やWMSなど周辺システムを含む類似案件の目安です。ただし、ハンディ端末単体の統計ではありません。

保守費は、どこまでを保守の範囲に含めるかで決まります。範囲には、障害対応やOS更新、機種追加、マスタ変更などが入ります。問い合わせや監視、バックアップ、セキュリティ対応も対象になります。

月額保守は、10万〜50万円程度を見込む場合もあります。ただし、24時間対応か平日対応か、改修費を含むかによって、意味が変わります。

見積書では、初期費用や月額、従量の料金を分けて記載してもらいます。保守や機器、通信の費用も、別々に書いてもらいます。教育やデータ移行も、分けて示してもらいます。

ポイント

費用は、端末単価だけでなく総額で比べます。公開価格は目安として扱い、見積もりの前提がそろっているかで判断します。

見積もりを取る際のポイント

見積もりの差は、開発会社の単価だけでなく、前提条件の違いから生まれます。そのため、各社に同じ条件を示して比べます。

  • 範囲:端末台数、対象拠点、業務、連携先、データ移行。
  • 運用:通信環境、テスト、教育、保守。
  • 機能区分:標準機能と追加開発を分けて確認する。

発注前に整理する情報

各社の見積もりを同じ前提で比べられるよう、発注前に業務規模から現場条件、例外の扱いまでを資料にまとめておきます。

  • 業務規模:業種、拠点数、倉庫の広さ、SKU数、入出荷・ピーク件数、同時利用者数。
  • 端末・連携:端末台数、商品コード、ロット・期限・シリアル、ラベル規格、既存システム名、連携方式、帳票。
  • 現場条件:冷蔵・冷凍、屋外、粉じん、水濡れ、手袋、落下、長距離読取。写真や動画も添えます。
  • 例外対応:欠品、過剰入荷、ラベル汚れ、棚番変更、返品、誤読、通信断、端末紛失、出荷確定後の取消。
  • 担当と操作:例外ごとに、誰がどの画面で処理するかを示します。

正常系だけの資料では、工数が安全側に多く積まれます。そのため、各社の見積もりを比べにくくなります。

開発会社の比較社数と評価の観点

初回は、2〜4社程度に同じ資料を渡して、提案と見積の前提を比べます。さらに、現場で実機検証を実施できるかも確かめます。

  • 業務知識:WMS、在庫、入出庫の実績。
  • 技術・運用:基幹連携、オフライン、機種変更、キッティング。
  • 導入後:教育、保守の窓口、現場検証の支援。

開発会社には、標準機能に業務を合わせる範囲と、自社固有の追加開発を分けて説明してもらいます。

標準機能で入出荷を始め、特殊な返品処理だけを追加すれば、初期費用と将来の保守を抑えやすくなります。一方で、帳票や手順をすべて再現すると、カスタマイズ費用と更新時の検証負荷が高くなります。

契約前に確認するリスク

契約前には、端末の継続性やデータの扱いを確認します。また、障害対応と物流記録への影響も確かめます。

  • 端末・基盤:OSサポート期限、端末供給の継続性、SDKの提供条件。
  • 契約・データ:データ持ち出しと解約時の返却、障害時にどこまでを誰が受け持つか、SLA。
  • 運用・安全性:バックアップ、復旧目標、再委託先、セキュリティ監査の範囲。

たとえば、カシオは新規開発と新規顧客への販売活動を停止しており、DT-X450は在庫僅少と案内しています。保守期限は2032年5月までです(出典:カシオ計算機「ハンディターミナル」、2026年確認)。

既存機種を使い続ける場合も、後継機やアプリ移行の計画を用意しておきます。

物流では、法令や取引先の要件に関係する記録も確かめます。たとえば、物流効率化法は、2026年度から一定規模以上の特定荷主などに計画作成や定期報告を求めます。

荷主の指定基準値は、取扱貨物重量9万トン以上です(出典:国土交通省「物流効率化法」理解促進ポータル、2026年確認)。

ハンディ端末は、荷待ち・荷役時間や検品、出荷時刻の記録に使えます。ただし、導入しただけでは法対応は完了しません。記録の定義と運用も、設計に含めます。

ポイント

見積もりを比べる前に、各社へ同じ条件の資料を渡せているかを見ます。前提がそろっていれば、見積もりの差は提案内容の違いとして比べられます。

ハンディターミナルシステム開発でよくある質問

適切な方法は、業務や端末環境によって変わります。導入前によくある質問と、その判断基準を紹介します。

ハンディターミナルはスマートフォンで代用できますか?

代用できる場合があります。たとえば、屋内の標準的なバーコード検品で、落下や水濡れが少なく、カメラの速度で足りるなら、Androidのスマートフォンやタブレットが候補になります。

一方で、冷凍倉庫や長距離スキャン、手袋での操作が必要な場合は、専用端末を実機で比べます。さらに、連続読取や堅牢性、交換電池が要るかも確かめます。

倉庫のWi-Fiが不安定でも利用できますか?

利用できますが、通信断を想定した設計が必要です。そのため、端末への一時保存や復旧後の再送、送信済みIDによる重複防止を決めておきます。

さらに、在庫競合の処理と、通信断中に許可する業務の範囲も決めます。Wi-Fiは、作業場所や棚の高さ、AP切替を実測します。冷凍エリアや屋外も、実際の場所で測ります。

通信環境の改善費も、見積もりに含めます。

開発から稼働まで何か月かかりますか?

標準パッケージは最短1か月から数か月、端末アプリと既存WMS・基幹の連携は3〜6か月程度が目安です。

複数拠点やスクラッチ、マテハン連携を含む場合は、半年〜1年以上が初期の目安です。期間は、マスタ整備やAPI仕様、現場テストの回数によっても変わります。

端末選定や繁忙期の制約も、期間に影響します。ただし、短納期の場合でも、実機テストと切替リハーサルは省きません。

小規模な倉庫でもハンディターミナルシステムを導入できますか?

導入できます。高機能なスクラッチから始めなくても、出荷検品や棚卸をクラウドWMSで始め、必要に応じて機能を広げられます。

端末や拠点、出荷明細の数、機能を分けて試算します。通信費、ラベル機器、保守は、別の項目として試算します。紙やExcelの再入力削減を、投資判断の材料に使います。

ポイント

よくある質問の答えは、業務の規模や現場の環境で変わります。迷ったときは、現場の条件と、通信断や例外時の運用を先に決めておくと判断しやすくなります。

まとめ

開発は、入荷から出荷、返品、棚卸までの業務とデータの流れを整理するところから始めます。端末の選定は、その後に進めます。

6段階(要件整理から定着まで)のそれぞれに、完了条件を設けます。通信断や誤読、在庫競合の扱いも確かめます。さらに、端末故障やOS更新への備えも確認します。

導入前に決めること

導入前には、対象業務、SKU・ロット・期限、拠点と件数をまとめます。加えて、端末・周辺機器、既存連携、通信断時の運用も決めておきます。

セキュリティや移行、教育の計画を整理します。保守とKPIも、導入前に決めておきます。

見積もりは、総額と3〜5年のTCOで比べます。端末単価は、その内訳の一つとして見ます。

次に行うこと

導入前の確認から稼働後の改善まで、次の順序で進めます。

  1. 現場でAs-Is業務を確認し、紙帳票、Excel、商品ラベル、棚番、例外処理を集めます。
  2. 候補端末を実機で試し、同じRFPを複数社へ渡して提案と見積を比べます。
  3. 稼働後は検品時間、誤出荷、棚卸差異、再入力、教育時間を追って定着させます。

導入後はKPIを確認し、導入で終わらせず、追加の改善につなげます。

▼全体ガイドの記事
・ハンディターミナルシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。