受発注管理システムをスマホで使いたい、と考えたときに最初に決めるべきなのは製品名ではありません。「アプリ」という一語が、ブラウザで開く画面のことなのか、ホーム画面に置くWebアプリなのか、ストアから配るネイティブアプリなのかで、作る量も運用の手間も年間の費用も変わります。倉庫の棚前で在庫を見ながら発注する、訪問先で取引先の代わりに注文を入れる、電波の届かない現場で数量だけ控える。こうした場面ごとに求められる要件は違います。この記事では、端末側をどう設計するかという1点に絞り、UI要件・代理発注の権限・オフライン耐性・バーコード読取の方式を整理したうえで、ネイティブアプリ化に踏み切る条件と、Web版で止めるべき場面を示します。
まとめ：アプリ化の判断を分ける3条件と費用が跳ねる境界
判断は3点で決まります。使う人が自社の中だけか取引先まで広がるか、通信が切れる場所で入力するか、コードを読み取るか。この3つを紙に書き出せば、ブラウザ版で足りるのか、ストア配信まで必要なのかはほぼ決まります。
費用が跳ねる境界は3か所あります。1つ目は端末内にデータを持たせるかどうか。オフラインで入力を通す設計に入った瞬間、同期と競合解決の実装が乗ります。2つ目はカメラや専用リーダーを使うかどうか。iPhoneのブラウザではバーコード検出の標準APIが既定で無効なため、読取を主要な操作にするならライブラリ実装かネイティブが要ります。3つ目はストア配信を選ぶかどうか。Google Play は2026年8月31日以降、新規アプリとアプリ更新の提出に Android 16（APIレベル36）以上のターゲットを求めており、配り始めた後もOSの年次要件に追随し続ける保守費が固定で乗ります。
前提として、企業間の取引はすでに大半が電子化しています。経済産業省が2025年8月26日に公表した令和6年度電子商取引に関する市場調査では、2024年の国内BtoB-EC市場は514.4兆円、EC化率は43.1%でした。論点は電子化するかどうかではなく、どの端末でどこまで操作させるかに移っています。
受発注管理システムをアプリで使うときに比較する3つの提供形態と選定軸
まず言葉を割ります。ここが曖昧なままベンダーと話すと、見積もりの前提がずれたまま進みます。
ブラウザ版とホーム画面追加型とストア配信型を分ける配布方法と更新負担の比較
スマホで受発注管理システムを使う形は、実装の面から3つに分かれます。
| 形 | 実体 | 配布 | 更新の手間 |
|---|---|---|---|
| ブラウザ版 | レスポンシブWeb | URLを知らせる | サーバ側だけ |
| ホーム画面追加型 | PWA | URL＋追加操作 | サーバ側だけ |
| ストア配信型 | ネイティブ | 審査を経て配信 | OS要件に追随 |
ホーム画面追加型は、Webサイトをホーム画面のアイコンから起動できるようにしたものです。ブラウザのアドレスバーが消えるので見た目はアプリに近づき、通知も条件付きで送れます。iOSでは16.4系（2023年3月）以降、ホーム画面に追加したWebアプリに限ってWeb Pushを受け取れるようになりました。ただし追加操作を利用者にやってもらう必要があり、社内なら手順書で回せても、取引先の担当者に一斉にやってもらうのは簡単ではありません。
ストア配信型は、カメラ・生体認証・バックグラウンド処理といった端末機能を素直に扱える代わりに、審査と配信、そしてOSの世代交代に付き合う運用が生まれます。提供形態そのものの選び分けはWeb受発注システムとは？ASP・クラウド型・パッケージ・自社開発の提供形態と選び方で整理しているので、サーバ側の型と合わせて考えてください。
発注側への配布と受注側の利用で反転する機能要件と端末管理の範囲
同じ受発注管理システムでも、誰の端末で動かすかによって要件は逆を向きます。受注側、つまり自社の営業や倉庫が使う画面は、1人が大量の注文を捌くための一覧性と検索性が主役です。発注側、つまり取引先の担当者が使う画面は、月に数回しか触らない人が迷わず送信できることが主役になります。
この違いを踏まえずに1つの画面を両方へ配ると、たいてい発注側が使わなくなります。取引先に電話とFAXへ戻られては、電子化の効果が出ません。取引先側の利用をどう立ち上げるかは受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方に譲りますが、端末側の設計でも「相手は初回操作でつまずく」という前提を置いてください。
電話回線のEDIから置き換える案件で移行期限から逆算する開発工程
アプリ化の相談は、単独で来るとは限りません。固定電話網のEDIを入れ替える流れの中で、ついでにスマホからも発注できるようにしたいという形で持ち込まれることがあります。NTT東西のINSネット ディジタル通信モードは2024年1月から段階的に終了し、切替後のデータ通信（補完策）の提供終了予定日は2028年12月31日と案内されています。
この期限がある案件では、端末側の作り込みを優先すると本体の入替が間に合いません。まず全取引先が電子的に発注できる状態を作り、スマホ側は後から足す。順序を逆にした案件は、たいてい期限直前に慌てます。判断の逆算は受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断で扱っています。
スマホ画面での注文入力を短時間で終えるための画面設計と操作要件
ここからは画面の中身です。PCの画面をそのまま縮めた発注画面は、現場では使われません。
商品検索を省く注文パッドと再注文を中心に据えた入力動線の設計
企業間の発注は、同じ商品を繰り返し買う取引が大半を占めます。したがってスマホ側で最も使われる機能は、カテゴリを辿って商品を探す導線ではなく、前回の注文を呼び出して数量だけ直す再注文と、型番や商品コードを直接打ち込む注文パッドです。
実装の優先順位を並べると次のようになります。
- 前回・前々回の注文をそのまま複製して数量を変えられる
- よく買う商品をお気に入りとして先頭に固定できる
- 型番の部分入力で候補が絞り込まれ、数量欄へ直行できる
- 取引先ごとの取扱商品だけに絞って表示される
逆に、絞り込み条件を細かく重ねる検索や、閲覧履歴からのおすすめ表示は、消費者向けの発想をそのまま持ち込んだもので、発注業務ではほとんど使われません。作り込む前に、実際の注文データで上位20品目が全体の何割を占めるかを見てください。多くの卸売・資材系では、この比率が高く出ます。
片手操作の範囲と入力回数から逆算する発注画面の配置要件と判定基準
棚の前や運転席の脇で操作する人は、片手しか空いていません。画面の下半分に主要な操作を置く、数量は入力欄をタップさせずに増減ボタンで済ませる、確定ボタンは固定表示にする。こうした細部が入力の完了率を左右します。
設計の基準として、1品目を注文カートへ入れるまでのタップ数を数えてください。3タップを超えると、20品目の発注で60回以上の操作が発生します。紙とFAXのほうが早いと言われる分岐点はこのあたりです。加えて、途中で電話が入って画面を離れても入力内容が消えない下書き保存を用意しておきます。
タブレットの一覧性と現場の置き場所を比較する端末選定の判断基準
タブレットは画面が広く、明細を並べたまま数量を入れられるため、倉庫の入荷検品や店舗のバックヤードでは使いやすい端末です。ただし現場では両手がふさがるため、置き台やスタンド、ストラップといった物理的な段取りとセットで考える必要があります。
端末の選定では、画面サイズよりも運用条件のほうが効きます。粉塵や水濡れがある現場では防塵防滴の等級、屋外では画面の輝度、長時間の棚卸しではバッテリーの持ちです。これらは受発注管理システム側の要件ではありませんが、決めずに進むと導入後に使われない端末が倉庫に積まれます。在庫の照合まで含めて設計するなら受発注在庫管理システムとは？受発注と在庫を連携する仕組み・選び方とカスタム開発の判断も合わせて確認してください。
現場と訪問営業の代理発注を成立させる利用者識別と権限設計の条件
スマホ化の相談で必ず出るのが、営業担当が訪問先で取引先に代わって注文を入れる運用です。ここは機能ではなく記録の設計問題になります。
入力担当者と注文名義人を分けて記録する代理発注の利用者識別方式
代理発注では、画面を操作した人と、注文の意思を持つ人が別になります。この2つを1つの利用者IDに丸めると、後から「誰が頼んだのか」を追えなくなり、数量違いや欠品のときに責任の所在が曖昧になります。
注文データには、発注元の企業と担当者に加えて、入力者と入力経路を持たせてください。営業が代理で入れた注文には代理入力の区分を立て、取引先の担当者へ確認の通知を送って承諾の記録を残す。この一往復があるだけで、後の照会にかかる時間が変わります。
操作証跡と権限の境界を先に定義してから追加する承認機能の範囲
代理発注を許す範囲は、はじめから狭く切っておくほうが運用は安定します。代理で入れられるのは既存の取扱商品だけ、与信枠を超える注文は代理では確定させない、単価の変更は代理入力では不可、といった線引きです。
権限を後から絞るのは、業務が回り始めた後では抵抗が大きくなります。逆に、狭く始めて必要になった分だけ広げるほうが摩擦は小さい。監査対応が求められる業界では、いつ誰がどの端末から入力したかという記録の保持期間も、この段階で決めておきます。
通信が切れる現場で必要なオフライン耐性を決める業務範囲と復旧条件
地下の倉庫、鉄骨に囲まれた工場、山間部の建設現場。電波が不安定な場所での利用があるなら、オフラインの扱いを決めます。ここは作り込みの深さで費用が大きく動く部分です。
端末保存だけを通す方式と在庫引き当てまで行う方式の処理範囲比較
オフライン対応には段階があります。軽いほうから順に、入力途中のデータを端末内に保持するだけの下書き保存、送信を待ち行列に入れて通信回復時に自動送信する方式、商品マスタや在庫数を端末へ複製して単独で完結させる方式です。
| 方式 | 端末に持つもの | 実装の重さ |
|---|---|---|
| 下書き保存 | 入力中の明細 | 軽い |
| 送信待ち行列 | 未送信の注文 | 中程度 |
| マスタ複製 | 商品・単価・在庫 | 重い |
多くの現場は、真ん中の送信待ち行列で足ります。マスタ複製まで必要になるのは、通信が数時間単位で切れる環境か、在庫の可否をその場で確定させないと業務が止まる場合に限られます。単価や在庫を端末に置くと、更新の反映遅れがそのまま誤発注になるため、複製する項目は絞ってください。
送信待ちの注文を二重登録させない一意な識別子と再送処理の設計
オフライン対応で最も事故が起きるのは、通信が回復した瞬間です。送信したかどうか分からず利用者が再送する、電波が切れかけて同じ注文が2回届く、といった形で重複が生まれます。
対策は、端末側で注文ごとに一意の識別子を作り、サーバ側でその識別子を見て2回目以降を無視する仕組みです。サーバが採番するのを待つ設計では、通信が切れている間に識別子を作れません。同時に、送信済み・送信待ち・失敗の3状態を画面で見分けられるようにしておきます。利用者が状態を判断できないことが再送の引き金になるためです。
バーコードとJANコードの読み取り方式を決める端末条件と実装方法の比較
棚卸しや検品を伴う運用では、コード読取の方式選定がアプリ化の判断に直結します。ここがネイティブ化を選ぶ最大の理由になることも多い部分です。
iOSで標準APIが使えないブラウザのカメラ読取に必要な代替方式
ブラウザには BarcodeDetector というコード検出の標準APIがありますが、対応状況には偏りがあります。2026年8月時点で対応表を確認すると、Chrome for Android は対応、Safari は macOS・iOS ともに既定で無効、Firefox は未対応でした。つまり iPhone のブラウザでは標準APIに頼れません。
ブラウザで読み取りたい場合は、JavaScriptの読取ライブラリをカメラ映像に対して動かす実装になります。実務上は動きますが、読み取り速度と精度は端末の性能とカメラの合焦に左右され、暗い倉庫や湾曲したラベルでは失敗率が上がります。1日に数回の照合なら許容できても、数百件を連続で読む棚卸しには向きません。
連続スキャンの速度を基準に選ぶ専用リーダーとの接続方式と端末要件
読み取り件数が多い運用では、カメラではなく専用のリーダーを使う判断になります。接続方式は主に、Bluetooth接続の外付けリーダー、リーダー内蔵の業務用端末、そしてキーボードとして文字列を送るタイプの3つです。
このうち、キーボードとして入力を送るタイプは、入力欄にフォーカスを当てておけばブラウザ版でも動きます。ネイティブ化せずに読取を実現したいときの現実的な選択肢です。一方、読取結果を細かく制御したい、連続スキャンの合間に数量を入れたいといった要件が出ると、端末との接続を直接扱えるネイティブ側に寄ります。読取方式の選定は、業務の件数と場所を数えてから決めてください。
ネイティブアプリ化とWeb版を選び分ける利用条件と運用負担の判断基準
ここが本題です。製品比較の前に、自社がどの形を必要としているかを言い切っておきます。
ストア配信を選ぶ3条件のうち2つ以上に該当する利用環境の判定
ネイティブアプリを作るべきなのは、次の3つのうち2つ以上に該当する場合です。1つ目、通信が切れる場所で入力し、復旧後の自動送信まで求められる。2つ目、コード読取が主要な操作で、専用リーダーとの直接接続や連続スキャンが要る。3つ目、利用者が自社または限られた協力会社の社員で、端末の配布と管理を自社で握れる。
3つ目の条件は見落とされがちですが、実務では最も効きます。端末を管理できるなら、ストアを介さない社内配布の仕組みも取れるうえ、OSの更新時期も統制できるからです。逆に、1つしか当たらないなら、その1つをWeb側の工夫で吸収できないかを先に検討してください。読取だけが理由なら、キーボード入力型のリーダーで解ける場合があります。
取引先側に利用者が分散する場合にWeb版で止める配布運用の判断
Web版のまま進めるべき典型は、使う人の大半が取引先の担当者である場合です。理由は3つあります。相手の端末に何かをインストールしてもらう手間が、そのまま導入率の低下として跳ね返ること。取引先が使う端末やOSの版を自社では統制できないこと。そして、担当者の交代が起きるたびに再インストールの案内が必要になることです。
取引先へ広く配る前提なら、URLを送れば開けて、必要ならホーム画面に追加してもらう形が現実的です。ここで無理にストア配信を選ぶと、使い始めてもらう前の段階で脱落が生まれます。製品タイプごとの向き不向きは受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断を、実際の導入形と効果の読み方は受発注管理システムの導入事例の読み方｜効果指標の前提条件と自社での再現判定を参照してください。
見積もりに含めるOS追随とストア審査対応にかかる継続的な運用費用
ネイティブを選ぶときに抜けやすいのが、作った後に毎年かかる費用です。Google Play は2026年8月31日以降、新規アプリとアプリ更新の提出に Android 16（APIレベル36）以上のターゲットを求めており、対応が間に合わない場合は2026年11月1日までの延長を申請できると案内しています。この要件は毎年更新されるため、機能を1つも変えなくてもビルドと検証と再提出が発生します。
加えて、iOSとAndroidの2つを保守する体制、審査での差し戻し、端末の世代交代に伴う表示崩れの確認が乗ります。初期の開発費だけで比較すると、Web版との差は小さく見えることがありますが、3年で均すと差が開きます。判断の材料として、初期費用と3年間の保守を並べて比較してください。費用のレンジそのものは受注管理システムの比較｜4タイプ別の料金レンジと機能軸・カスタム開発の判断基準で整理しています。
ここまでの条件で自社がどちらに寄るかが見えたら、次は要件の粒度を上げる作業です。既存の受発注業務の型と端末側の要件を突き合わせて設計する段階では、受発注管理システム開発のように業務側から入る開発会社に、現状の注文件数と利用場所を持ち込んで相談すると、作らなくてよい範囲まで含めて線が引けます。
よくある質問
受発注管理システムのアプリは無料で使えますか？
無料の範囲で使える製品はありますが、多くは利用者数・取引先数・注文件数のいずれかに上限があります。取引先へ配る運用では、相手の数が増えた時点で有料の枠に移る設計になっているものが一般的です。無料版は業務の流れを確かめる試用として使い、本番の判断は上限に当たった後の費用で行ってください。無料製品の見極めについては親記事側で扱っています。
既存の受発注システムをアプリ化することはできますか？
できるかどうかは、既存システムがAPIを外部へ公開しているかで決まります。公開されている場合の選択肢は、そのAPIを呼ぶ端末側の別開発です。公開されていない場合は、画面を作り直すか、中間にデータ連携の層を挟むことになり、費用は跳ね上がります。まず既存製品の提供元にAPIの有無と利用条件を確認してください。
スマホ対応とアプリ対応は何が違うのですか？
スマホ対応は、ブラウザで開いたときに画面が縦長の端末向けに整うことを指す場合がほとんどです。アプリ対応と書かれている製品は、ストアで配信するアプリを用意していることを指しますが、中身がWebの画面をそのまま表示しているだけの場合もあります。カタログの表記だけでは判別できないので、オフラインで動くか、コード読取ができるかという機能で確かめるのが確実です。
iPhoneとAndroidの両方に対応させると費用は倍になりますか？
単純に倍にはなりませんが、1.5倍前後を見ておくと安全です。1つのコードから両方を作る仕組みを使えば実装は共通化できるものの、カメラやBluetoothなど端末機能に近い部分と、各ストアの審査対応、そして端末ごとの表示確認は個別に発生します。片方だけ先に出して運用を確かめ、必要になってからもう片方へ広げる進め方も現実的です。
タブレットとハンディターミナルはどちらを選ぶべきですか？
1日の読取件数で分けてください。読取が業務の中心で数百件を連続で処理するなら、読取専用の機構を持つハンディ端末のほうが速く、疲れも少なくなります。読取は補助的で、一覧を見ながら数量を入れる作業が中心ならタブレットが向きます。両方を配る運用は端末管理の負担が増えるため、まず件数の実測から始めるのが順当です。
関連記事
- 受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準：受発注システム全体の型と選び方の基礎です。
- Web受発注システムとは？ASP・クラウド型・パッケージ・自社開発の提供形態と選び方：サーバ側の提供形態を選ぶ判断に使います。
- 受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断：製品タイプごとの選定軸をまとめています。
- 受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方：取引先側の利用を立ち上げる手順です。
- 受発注管理システムの導入事例の読み方｜効果指標の前提条件と自社での再現判定：事例から自社への再現性を測る方法です。
