スマートフォン 業務アプリ 開発をタイの工場で成功させる鍵は、画面の見栄えや機能数ではありません。共有・堅牢端末、バーコードとカメラ、途切れるWi-Fi、オフライン同期、MDM、権限、監査、タイ語と日本語、そして現場で判定できる受入条件を、最初から一つの運用として設計することです。本稿では、工場の作業実行に範囲を絞り、RFPから90日PoC、FAT/SAT型の受入、総保有コストまで具体化します。
なぜ工場のスマートフォン業務アプリ開発は一般的な業務アプリと違うのか
オフィス向けアプリでは、一人一台の端末、安定した通信、落ち着いた入力環境を暗黙の前提にしがちです。工場の現場では前提が反転します。端末は交替勤務で共有され、手袋や油、粉じん、落下、強い照明の中で操作されます。作業者は数秒で入力を終えなければならず、アクセスポイントの切替や金属設備の影響で通信が一時的に切れることもあります。入力の失敗は単なる不便ではなく、仕掛品の所在不明、誤投入、品質記録の欠落、二重計上につながります。
だから評価すべき対象は「アプリ単体」ではなく、端末、ネットワーク、認証、配布、バックエンド、マスタ、現場手順、サポートを含む実行系です。既存の一般的な開発判断については工場向け業務アプリ開発の費用と進め方を参照し、本稿ではその中でもショップフロアのモバイル実行に焦点を当てます。端末選定の基礎は工場タブレット・端末選定ガイドも併せて確認すると、RFPの前提を揃えやすくなります。
タイ投資委員会（BOI）の公式発表では、2026年上期の投資申請は1,299件、1.47兆バーツで前年同期比37%増、うちデジタル分野は1.12兆バーツでした。これは実現済み投資額ではなく投資申請額ですが、タイでデジタル基盤への関心と案件規模が大きい背景を示します。一方、工場アプリの投資判断はマクロ数字ではなく、自社の停止時間、入力工数、誤処理、端末運用負荷で行うべきです。
工場モバイルアプリの対象業務を「現場の一取引」に分解する
最初に「生産管理をモバイル化する」のような大きな表現を、現場の一取引へ分解します。例えば、材料受入なら「ラベル読取→品目・ロット照合→数量入力→保管場所読取→受入確定」です。工程完了なら「作業指示読取→設備・作業者確認→良品数・不良数入力→不良理由選択→次工程へ払出」です。保全点検なら「設備読取→点検項目表示→測定値入力→異常写真→責任者通知」です。
一取引ごとに、開始条件、必須入力、エラー時の戻り先、確定の瞬間、取消権限、ERP/MESへ反映する単位を決めます。画面一覧から始めると例外処理が後回しになり、現場試験で「読めないラベルをどうするか」「通信切断中に確定してよいか」「二度押ししたらどうなるか」が発覚します。取引一覧から始めれば、UI、API、監査ログ、試験項目を同じ単位で結び付けられます。
優先順位は頻度・時間・誤り影響・標準化可能性で決める
候補業務ごとに、月間件数、一件当たり時間、再入力率、誤り発生時の影響、拠点間の共通度を置きます。ただし重み付けは会社ごとに変わります。例えば「頻度40%、時間25%、誤り影響25%、標準化10%」という点数は、あくまで例示です。品質保証を最優先する工場なら誤り影響を50%にしてよいでしょう。
PoCでは、価値が大きくても例外が多すぎる業務より、バーコードで対象を確実に特定でき、前後工程が明確で、90日以内に現場評価できる業務を選びます。「材料払出」「工程完了」「完成品入庫」など一つの流れに限定すると、成功条件が曖昧になりません。
堅牢端末・共有端末モデルを先に決める
工場の端末モデルには、個人配布、シフト共有、工程固定、専用スキャナ一体型、一般スマートフォン＋外付けスキャナなどがあります。どれが正しいかではなく、作業時間、落下リスク、読取回数、衛生、充電、紛失、保守交換に合うかで選びます。
個人配布は利用者追跡と通知に向きますが、台数と管理負荷が増えます。共有端末は台数を抑えやすい一方、サインイン・サインアウト、前利用者のデータ消去、充電責任、故障引継ぎを設計しなければなりません。工程固定端末は持ち出しを防ぎやすい一方、設備停止時の代替手段が必要です。
共有端末では「誰の操作か」を端末所有者と分離する
共有端末の端末IDは、作業者IDではありません。取引には少なくとも、端末ID、アプリ版、作業者ID、役割、工程、時刻、取引IDを記録します。短いPINだけで重要処理を許すのではなく、社員証の読取、企業ID、必要に応じた再認証を組み合わせます。休憩やシフト交替では自動ロックし、未送信データがある場合の引継ぎ手順も定義します。
NIST SP 800-124 Rev.2は2023年5月公表で、企業モバイル端末のライフサイクルと集中管理を扱います。調達時だけでなく、登録、構成、監視、更新、紛失、廃棄までを管理対象にする考え方は、共有端末モデルの土台になります。
端末評価は仕様表ではなく実作業で行う
候補端末を現場へ持ち込み、実際のラベル、手袋、照明、通信環境で試します。最低限、片手操作、連続読取、傷んだラベル、反射材、低い位置、高い棚、写真の焦点、音と振動、バッテリー交換、充電器の置き場を確認します。IP等級や落下仕様は候補を絞る材料ですが、現場適合の代わりにはなりません。
バーコードアプリ開発は「読めた後」の検証が本体
バーコードを読み取るだけなら、多くのSDKで実装できます。難しいのは、読み取った値が何を表し、現在の取引で許可されるかを即時に判定することです。GS1 General Specificationsを基準に、GTIN、ロット、シリアル、有効期限などの識別子を扱う場合は、区切りや可変長、先頭ゼロを文字列として正しく処理します。独自コードが混在するなら、コード体系、発行主体、桁数、チェック、再利用可否を台帳化します。
読取パイプラインを段階化する
推奨する処理順は、①画像またはスキャナ入力、②形式解析、③識別子抽出、④マスタ照合、⑤業務ルール検証、⑥利用者への確認、⑦取引確定です。各段階のエラーを分けると、「カメラが読めない」「コードは読めたが形式不正」「品目は存在するがこの工程では使用不可」を別々に改善できます。
読取後の画面にはコード文字列だけでなく、品名、ロット、数量単位、工程、ステータスなど作業者が照合できる情報を大きく表示します。音・色・振動は補助手段とし、赤緑だけに依存しません。誤読時の手入力は完全禁止ではなく、権限、理由、二者確認、監査ログを付けて例外経路として残す方が、停止を避けつつ統制できます。
カメラ画像は必要最小限に保持する
異常写真は有用ですが、背景に人、図面、顧客情報が写る可能性があります。撮影目的、保存期間、閲覧権限、端末ギャラリーへの保存禁止、アップロード後のローカル削除を定義します。画像そのものが不要なら、読取フレームを保存しない設計を既定にします。
オフライン業務アプリはローカル正本と同期契約から設計する
工場Wi-Fiは改善すべきですが、完全な常時接続を成功条件にすると現場実行がネットワークに引きずられます。Androidのoffline-first公式ガイドは、信頼できるネットワークがなくても中核機能を使えること、ローカルデータを読み取りの正本にする考え方、キューイングや遅延書込、競合解決を説明しています。
重要なのは「全部オフライン可」ではありません。参照、入力、確定を分けます。作業指示の参照と実績の一時保存はオフライン可でも、ロット引当や在庫移動の最終確定はオンライン照合が必要な場合があります。逆に、停電復旧時の安全点検など、通信がなくても必ず記録すべき業務もあります。取引単位で可否と制約を表にします。
ローカル正本は画面と同期状態を一貫させる
画面がサーバーAPIを直接読み、送信待ちだけ別の保存領域に置くと、利用者には「送ったはずなのに一覧にない」と見えます。端末内データベースを画面の読み取り元にし、サーバーからの取得結果も作業者の入力もそこへ反映します。各レコードには、ローカル状態（下書き、送信待ち、送信中、同期済み、要確認）、更新時刻、サーバー版、取引IDを持たせます。
利用者には通信アイコンだけでなく、「未送信3件」「最終同期10:42」「1件要確認」のように行動可能な状態を示します。再試行ボタンだけに頼らず、バックオフ、電池、接続種別、アプリのライフサイクルを考慮して自動同期します。ただし大量データや画像は、充電中・Wi-Fi接続中などの条件を設定できます。
冪等性で二度押しと再送を安全にする
オフライン同期では、端末が送信後の応答を受け取れず再送することがあります。サーバーが毎回新しい実績として登録すると二重計上になります。端末で取引ごとに一意なidempotency key（取引ID）を発行し、サーバーは同じキーを再受信したとき、二重登録せず初回結果を返します。
この仕組みはUIの二度押し防止とは別です。ボタンを無効化しても通信再試行は起こり得ます。逆にサーバー冪等性があっても、作業者が別取引として同じ現品を二回処理する可能性は残ります。業務キー（作業指示＋工程＋ロットなど）による重複警告も組み合わせます。
競合解決を「最後の更新で上書き」に固定しない
二台の端末が同じ指示をオフラインで更新した場合、単純なlast-write-winsは正しい情報を消す恐れがあります。数量実績は追加イベントとして記録し、指示の状態遷移はサーバー版番号で楽観ロックし、注記は追記型にするなど、データの意味に応じて方式を分けます。
競合時に必要なのは技術的なマージだけではありません。誰が判断できるか、現場を止めるか、仮保留にするか、訂正履歴をどう残すかを決めます。「自動解決」「作業者が選択」「監督者レビュー」「管理部門が訂正」の四段階に分類すると、例外キューを運用しやすくなります。
MDM・非公開配布・キオスクで工場端末を運用する
アプリを完成させても、端末登録、設定、配布、更新、紛失対応が手作業なら、多拠点展開で破綻します。Android Enterpriseは、仕事用プロファイル、完全管理端末、専用端末、managed Google Playを通じた非公開アプリ配布などの管理モデルを案内しています。Apple Platform Deploymentは、Apple端末の管理と展開をまとめています。
MDM工場端末の基本ポリシー
工場専用端末なら、許可アプリ、OS最小版、画面ロック、暗号化、コピー＆ペースト、スクリーンショット、カメラ、USB、開発者モード、未知の配布元、Wi-Fi証明書、VPN、リモートロック・消去を検討します。ただし一律に厳しくすると保全作業や緊急連絡を妨げます。端末グループを工程・用途別に分け、ポリシー例外に承認者と期限を持たせます。
キオスクモードは、専用端末で不要な操作を減らすのに有効です。一方、Wi-Fi再設定やサポート情報へ到達できなくなると復旧が遅れます。現場責任者が使える管理メニュー、オフライン診断、端末IDと連絡先の表示、解除手順を準備します。
更新は全台同時ではなくリング配布する
開発、試験、パイロット工程、先行拠点、全拠点というリングを設けます。新バージョンは旧APIとの互換期間を持たせ、失敗時に一つ前へ戻せるか、少なくとも業務継続版を再配布できるようにします。強制更新の時刻はシフトと生産計画に合わせます。DBスキーマ変更では、旧版と新版が混在する時間を試験します。
最小権限・監査・モバイルセキュリティを業務設計へ埋め込む
OWASP MASVSは、ストレージ、暗号、認証、ネットワーク、プラットフォーム、コード、耐解析性、プライバシーなどの管理群を示します。チェックリストを納品直前に当てるのではなく、データ分類と脅威モデルをRFPと設計レビューに組み込みます。
権限は役職名より作業と工程で切る
「作業者」「管理者」だけでは権限が粗すぎます。閲覧、登録、取消、上書き、マスタ変更、例外承認、データ出力を分け、工場・建屋・工程・シフトなどの範囲を掛け合わせます。普段使わない強い権限は常時付与せず、申請して期限付きで有効にする方式も検討します。
端末紛失を前提に、アクセストークンの寿命、更新トークンの保護、証明書失効、リモート無効化を設計します。端末内には必要期間・必要範囲のデータだけをキャッシュし、ログにパスワード、トークン、個人情報、製造秘密を出さないようにします。TLSだけで終わらず、証明書検証、API認可、レート制御、不正端末の検知も試験します。
監査ログは「誰が何を変えたか」を再現できる粒度にする
最低限、利用者、端末、アプリ版、時刻、処理、対象、変更前後、理由、オンライン／オフライン、同期時刻、承認者を関連付けます。端末時刻だけを信用せず、サーバー受信時刻も保持します。オフライン時刻のずれは異常として検知し、並び順に影響することを利用者へ示します。
訂正は元レコードを書き換えて消すのではなく、取消・訂正イベントとして追記し、最新状態を再計算できる形が望まれます。保持期間は品質、顧客契約、法令、社内規程に合わせ、無期限保存を既定にしません。電子文書や署名に関係する場合は、タイのETDAのセキュリティ関連情報なども確認し、個別要件は専門家と判断します。
タイ語・日本語の現場ローカライズは翻訳だけではない
日本語で設計し英語を経由してタイ語へ翻訳すると、現場用語が不自然になりやすくなります。品目、工程、設備、品質、不良、保留、解除などの用語集を、日本人管理者、タイ人監督者、実作業者で合意します。UIラベルだけでなく、エラー、ヘルプ、教育資料、MDM通知、サポート手順も対象です。
一画面一判断にして言語負荷を下げる
文章を短くし、動詞を先に置き、エラーでは「何が起きたか」「何を確認するか」「次に何をするか」を分けます。例えば「処理できません」ではなく、「このロットは工程Aで未完了です。工程Aの実績を確認するか、監督者へ連絡してください」とします。コードE104のような識別子を付けると、タイ語画面を見た日本人サポート担当とも状況を共有できます。
日付、時刻、数字、小数点、単位、氏名順、仏暦・西暦を確認します。データ保存は言語に依存しないコード値とし、表示文言だけをローカライズします。自由入力の不良理由を増やしすぎず、標準コード＋補足欄にすると、集計と多言語表示を両立できます。
現場受入は両言語の代表者で行う
翻訳レビューだけでなく、タイ人作業者が実端末で代表シナリオを実行し、日本人管理者が帳票・集計・監査を確認します。理解できたかを質問するのではなく、説明なしで正しく完了できるか、エラーから復帰できるかを観察します。教育資料には実画面と実ラベルを使い、更新時に差分を反映できる所有者を決めます。
RFPに書くべき工場モバイルアプリの要求事項
RFPは機能一覧だけでは比較できません。以下を同じ粒度で提示すると、提案各社の設計力と見積範囲を比較できます。
- 対象工場、工程、利用者、シフト、端末台数と同時利用数
- 一取引の業務フロー、正常系、例外、承認、取消
- バーコード体系、実物サンプル、カメラ・スキャナ条件
- オフラインで許可する参照・入力・確定、想定切断時間、同期競合
- ERP/MES/WMSとのAPI、マスタ所有者、更新頻度、障害時責任分界
- 共有・専用端末モデル、MDM、非公開配布、キオスク、OS更新
- 認証、最小権限、監査、暗号化、ログ、脆弱性対応
- 日本語・タイ語の用語集、翻訳レビュー、教育、サポート時間
- 性能、可用性、監視、バックアップ、復旧目標
- FAT/SAT型の受入項目、証跡、重大度、合否判定
- ソース、設計書、API仕様、運用手順、引継ぎ物
- 初期費、継続費、変更単価、ライセンス、端末、通信を含むTCO
「オフライン対応」「高セキュリティ」のような形容詞は、試験可能な条件に変えます。例えば「10分切断後も20件を登録でき、再接続から5分以内に自動同期し、同じ取引IDを3回再送してもサーバー登録は1件」という形です。数値は自社工程の実測から決め、例文をそのまま要件化しないことが重要です。
90日PoCで設計・実装・現場検証を一巡する
90日は一般的な納期の主張ではなく、範囲を絞ったPoCを管理するための例示的な枠です。前提として、対象は一工場・一工程・一種類の取引、既存APIを利用可能、端末20台以下、二言語、重大な基幹改修なしとします。条件が違えば期間も変わります。
1〜15日目：現場観察と基準値
作業者の動線、ラベル、手袋、端末置き場、Wi-Fi切断地点、例外処理を観察します。現行の一件時間、再入力、紙の滞留、誤り、問い合わせ件数を測ります。データを取れない場合は、少なくとも観察日、シフト、標本数を記録し、推測と実測を分けます。用語集、取引定義、PoC合否条件もこの期間に凍結します。
16〜40日目：歩ける最小フローを作る
認証、指示取得、バーコード読取、入力、ローカル保存、同期、監査までを一貫して動かします。画面を大量に作るより、一本の取引を端から端まで通します。API契約、取引ID、競合、エラーコードを早く確定し、MDMのテストグループへ配布します。
41〜60日目：切断・故障・誤操作を試す
アクセスポイント間移動、完全切断、応答消失、二度押し、端末再起動、電池切れ、古いアプリ版、サーバー停止、同一現品の二重読取を再現します。正常系のデモだけでは、現場の継続性を評価できません。監査ログから一連の操作を再構成できるかも確認します。
61〜80日目：限定シフトで運用する
教育後、対象者と時間帯を限定して実運用します。紙や既存端末への戻し方を決め、問題を重大度で分類します。日次で、完了件数、失敗率、同期遅延、例外、サポート呼出し、バッテリー、作業者のコメントを確認します。新機能要求と欠陥を混ぜないようにします。
81〜90日目：SATと展開判断
受入シナリオを再実行し、未解決事項、運用負荷、TCO、次工程への影響を確認します。「成功だから全工場展開」ではなく、継続、条件付き継続、再設計、中止の基準で判断します。次段階では工程・拠点を一度に増やさず、同期負荷、マスタ統制、サポート体制を段階的に検証します。
FAT/SAT型の受入で現場稼働を判定する
ここでいうFAT/SAT型は、設備案件の考え方をソフトウェア受入へ応用するものです。FAT相当では、管理された環境で機能、API、オフライン、セキュリティ、負荷、復旧を確認します。SAT相当では、実工場の端末、無線、ラベル、作業者、シフト、周辺システムで確認します。
受入条件は再現手順と証跡をセットにする
各項目に前提データ、手順、期待結果、許容差、証跡、合否判定者を持たせます。例示として、次のような項目があります。
- 傷や反射を含む承認済みラベルセットを、指定距離・角度で読み取れる
- 通信切断中の登録が端末再起動後も残り、再接続後に欠落・重複なく同期される
- 同一取引IDの再送が一件として扱われ、初回と同じ結果を返す
- 権限外の取消・マスタ変更・データ出力が拒否され、監査ログに残る
- 紛失端末を無効化し、以後のAPIアクセスが拒否される
- タイ語・日本語の主要シナリオを対象作業者が補助なしで完了できる
- 旧版混在、サーバー停止、復旧後の再同期で業務データが整合する
性能値は「画面が速い」ではなく、ネットワーク条件、同時利用、データ量を伴って定義します。例えば「工場内Wi-Fi、同時50台、95パーセンタイルで読取後確認2秒以内」は例にすぎません。実測基準と生産上の許容時間から値を決めます。
スマートフォン業務アプリ開発のTCOを比較する
初期開発費だけで提案を比べると、運用開始後の端末交換、MDM、OS更新、問い合わせ、バックエンド監視、言語更新が抜けます。TCOは少なくとも次の区分で見ます。
- 発見・設計：現場観察、業務整理、UX、セキュリティ、アーキテクチャ
- 実装・試験：アプリ、API、連携、オフライン、テスト自動化、FAT/SAT
- 端末：本体、予備機、ケース、スキャナ、バッテリー、充電設備、修理
- 管理：MDM、ID、証明書、非公開配布、監視、ログ、バックアップ
- 通信・基盤：Wi-Fi改善、回線、クラウド、データ転送、画像保管
- 運用：ヘルプデスク、教育、翻訳、マスタ管理、シフト外対応
- 変更：OS・SDK更新、脆弱性対応、ERP変更、新工程、新言語
- 停止・リスク：障害時の代替手順、再入力、誤処理、監査対応
例示的なTCO計算
仮に、端末30台、予備3台、対象取引は一日2,000件、年間稼働250日、評価期間3年とします。初期設計・開発を600万バーツ、端末と周辺機器を99万バーツ、MDM・基盤・保守を年120万バーツ、教育・更新を年40万バーツ、Wi-Fi改善を60万バーツと仮定すると、単純合計は1,239万バーツです。これは市場平均ではなく、計算方法を示す仮定上の例です。税、資本コスト、為替、既存ライセンス、社内人件費は含めていません。
便益も同様に仮定を明記します。一件当たり8秒短縮、一日2,000件、250日なら年間約1,111時間です。ただし、この全時間が残業削減や増産へ転換されるとは限りません。便益化率を40%、人件費を一時間300バーツと仮定すれば、時間便益は年間約13.3万バーツです。この例では時間短縮だけで投資を正当化できず、誤投入防止、仕掛削減、追跡時間、監査、停止回避などを別々に測る必要があると分かります。
ROIを高く見せるために全便益を足し込むのではなく、同じ損失を二重計上していないか確認します。例えば再入力時間と誤処理の復旧時間が同じ作業を含む場合があります。最小、基準、最大の三ケースを作り、どの仮定が結論を変えるか感度分析します。
運用開始後に追うべき指標
ダウンロード数やログイン数だけでは、現場成果を測れません。取引成功率、初回読取成功率、同期待ち件数、95パーセンタイル同期時間、競合件数、手入力例外、取消・訂正、アプリクラッシュ、旧版端末、MDM準拠率、サポート呼出しを追います。業務成果として、一件時間、仕掛滞留、誤投入、欠落記録、追跡調査時間、監査指摘も比較します。
指標には所有者と対応基準を置きます。例えば同期待ちが閾値を超えたらIT、読取失敗が特定ラベルに集中したら生産技術、手入力例外が増えたらマスタ責任者が調査する、といった形です。ダッシュボードを作るだけでなく、週次・月次の改善会議で判断につなげます。
よくある失敗と回避策
第一の失敗は、紙の帳票をそのまま小さい画面へ移すことです。必要な判断と入力順に再構成し、スキャンで補える項目を減らします。第二は、オフラインを「後で追加できる機能」と扱うことです。データモデルとAPI契約に影響するため、最初の縦切り実装から含めます。
第三は、パイロット端末への手動インストールで成功と判断することです。実運用では登録、更新、紛失、退役が続くため、PoCからMDMと配布を通します。第四は、日本人管理者だけで受入することです。実作業者の言語、手袋、動線、例外復帰をSATで確認します。第五は、ERP接続ができた時点を完成とすることです。二重送信、遅延、マスタ不整合、障害復旧まで試します。
工場モバイルアプリはどの端末を選ぶべきですか？
読取回数が多く落下リスクが高い工程では、専用スキャナ一体型の堅牢端末が候補です。写真や一般的な入力が中心なら、管理されたスマートフォンでも足りる場合があります。仕様だけで決めず、実ラベル、手袋、照明、Wi-Fi、充電、修理交換を含む現場試験で比較してください。共有か個人配布かによっても認証と運用コストが変わります。
オフライン業務アプリは通信なしで何までできますか？
業務ごとに異なります。参照と入力は可能でも、在庫やロットの最終確定はオンライン照合が必要な場合があります。取引ごとに、オフライン可否、保持期間、上限件数、再接続時の同期、競合時の責任者を定義します。「全機能対応」という表現ではなく、切断試験で受け入れます。
MDM工場端末で個人スマートフォンを使えますか？
技術的には仕事用領域を分ける方式がありますが、安全、カメラ、データ分類、労務、サポート、退職時消去を考える必要があります。製造秘密や専用周辺機器を扱う工程では企業所有の完全管理・専用端末が適することが多い一方、承認や閲覧中心ならBYODを検討できる場合もあります。リスク評価と就業規則を基に決めます。
バーコードアプリ開発でGS1対応は必須ですか？
取引先や物流でGS1識別子を扱うなら、General Specificationsに沿った解析と検証が重要です。工場内の独自コードだけなら必ずしもGS1へ置き換える必要はありませんが、体系、重複防止、桁、発行・廃止責任を明文化してください。両方が混在する場合は、形式判定とエラー表示を分けます。
スマートフォン業務アプリ開発の費用はどう見積もりますか？
画面数だけでなく、オフライン同期、連携API、バーコード体系、端末・MDM、二言語、セキュリティ試験、現場受入、運用保守を区分して見積もります。3〜5年のTCOと、前提を明記した便益シナリオで比較してください。本稿の金額例は市場平均ではなく、計算構造を示す仮定です。
まとめ：アプリではなく現場実行の仕組みを受け入れる
タイ工場のスマートフォン業務アプリ開発では、取引単位の業務設計、共有・堅牢端末、バーコード検証、ローカル正本、冪等同期、競合処理、MDMと非公開配布、最小権限、監査、日タイの現場ローカライズを一体で設計する必要があります。RFPでは形容詞を試験可能な条件へ変え、90日PoCでは一本の流れを端から端まで通し、FAT/SAT型の証跡で展開可否を判断します。TCOは初期開発だけでなく、端末・管理・更新・サポート・停止リスクまで含めて比較しましょう。
対象工程の切り出し、オフライン範囲、端末モデル、RFPの受入条件を整理する検討段階から、TOMAS TECHへご相談いただけます。現場の実測値と既存ERP/MESの条件を確認し、PoCで確かめる範囲を一緒に具体化します。
参考資料
- NIST SP 800-124 Rev.2: Guidelines for Managing the Security of Mobile Devices in the Enterprise
- Android Developers: Build an offline-first app
- Android Enterprise overview
- Apple Platform Deployment
- OWASP Mobile Application Security Verification Standard
- GS1 General Specifications
- Thailand BOI: Investment Applications in First Half of 2026
- ETDA: Security recommendations
