モバイルファーストのデータ入力アプリを作る方法

モバイルファーストのデータ入力アプリが正しくやるべきこと

モバイルファーストのデータ入力は「小さい画面に収めたウェブフォーム」ではありません。短時間で中断されやすいセッション、片手操作、移動中、そして最適でない環境での速さと確実性を重視したデータ収集です。ユーザーが止まってズームし、読み直し、キーボードと格闘する必要があるなら、そのアプリは本当の意味でモバイルファーストとは言えません。

想定している現場シナリオ

多くのモバイルファーストなデータ入力アプリは、繰り返し発生するいくつかの場面に使われます：

• 現場訪問（作業メモ、写真、使用部品、顧客署名）
• 倉庫でのスキャン（ピッキング/パッキング数、バーコードによる確認）
• 検査（チェックリスト、欠陥、測定値、フォローアップ）
• 営業メモ（会話直後の短いCRM更新）
• 臨床受付（構造化された回答、本人確認、同意）

これらに共通するテーマは：ユーザーはレコードを素早く終わらせて仕事に戻りたい、という点です。

「成功」の定義を測定可能にする

設計と開発の前に、「良い」とは何かを合意しておきます。一般的な指標は以下の通りです：

• レコードあたりの時間（典型的な入力を完了する中央値）
• 完了率（開始されたものに対する正常に送信された割合）
• エラー率（バリデーション失敗、却下されたレコード、後での修正）

これらを早期に追跡すると、実際に効果のある改善に優先順位をつけられます。

役割と制約を明確にする

次を明確にします：

• 誰が入力するか（現場スタッフ、臨時、医療スタッフ、ドライバー）
• 誰が確認/承認するか（スーパーバイザー、QA、バックオフィス）

またUIを形作る制約も文書化します：

• 通信が不安定で圏外になること
• 手袋、濡れた手、騒がしい環境
• 直射日光や低コントラスト
• 共有デバイスやシフト引き継ぎ

これらの基本を押さえることで後の手戻りを防ぎ、アプリが画面ではなく業務に集中するようになります。

画面ではなくユースケースから始める

データ入力アプリで時間を無駄にする最も速い方法は、画面のスケッチから始めることです。代わりに、ユーザーが現場で何をやろうとしているのかを（手袋、電波不良、強い日差し、短い注意時間、厳しいデータ要件という現実を踏まえて）始めに書き出してください。

実際の作業を記述したユーザーストーリーを書く

5〜10件の主要なユーザーストーリーを平易な言葉でまとめます。結果（アウトカム）に焦点を当て、後でテストできるようにします：

• 現場で60秒以内に新しいレコードを作成する
• シフト後や別の場所でレコードを編集する
• 証拠として写真を添付する（損傷、メーター読み取り、棚の状態）
• 中断時に下書きとして保存し、文脈を失わずに再開する
• レビュー/承認のために送信し、ステータスを確認する
• 却下された申請を明確なガイダンスで修正する

「必須」と「任意」を（いつ必須か含めて）定義する

必須フィールドは普遍的ではなく、手順によって変わります。キャプチャ時に必ず集めるべきものと、スーパーバイザーやバックオフィスが後で埋められるものを決めてください。

例：位置情報とタイムスタンプは即時に必須にし、補助的なIDやメモは特定条件がない限り任意にする、といった判断です。

ワークフローを端から端までマップする

UIの詳細に入る前に、全体の流れをマップします：

capture → validate → sync → review → export

これによりハンドオフの明確化（誰がエラーを直すか、誰が承認するか、「完了」の定義）が進み、どこにステータス表示（下書き、キュー、同期済み、承認、却下）が必要かも露呈します。

オフラインで何を動かす必要があるか決める

オフラインで重要なアクション（作成、編集、写真添付、最近のレコード検索）と、オンラインでよいもの（大量エクスポート、管理設定、大規模カタログ）をリスト化してください。この決定がストレージ設計やユーザー期待を左右します。

MVPの範囲と「後回し」リストを設定する

コアのストーリーを信頼性高くサポートするMVPを定義し、ダッシュボードや複雑なルール、詳細な分析など「後でやる」リストを可視化しておくことで過剰実装を防ぎます。

データモデルとバリデーションルールを設計する

データ入力アプリは「何を」正確に捕えるかで成功が決まります。画面の仕上げより先に、データの「形」を定義して、フォーム、APIコール、エクスポート、レポートが一貫するようにします。

エンティティとリレーションシップから始める

記録する実世界の対象（エンティティ）とそのつながりを列挙します。例：顧客 → 現場 → 訪問 → チェックリスト項目。各エンティティについて、保存に必要な属性（必須）と任意属性を定義します。

最初はシンプルに：エンティティとリレーションを減らすほど同期の複雑さが減ります。MVPでワークフローが実証されたら拡張してください。

識別子、タイムスタンプ、誰が何を変更したか

モバイルデータはオフラインで始まることが多いため、サーバがその場でIDを割り振る前提にはできません。考慮すべき点：

• デバイスで作るグローバル一意ID（UUIDが有効）
• 作成/更新タイムスタンプ（端末時刻＋サーバ受信時刻が理想）
• 編集者情報（ユーザーID、必要なら役割やチーム）
• 変更履歴（少なくとも最終編集者と最終編集時刻。規制環境では完全な監査ログ）

これらは説明責任、カスタマーサポート、複数人編集時の競合処理に役立ちます。

バリデーションルールの配置

ルールをどこで実行するか決めます：

• 端末側（即時フィードバック、オフラインで動作）
• サーバ側（単一の真実の源、改ざん防止）
• 両方（多くの現場アプリで推奨）

端末側で必須項目、範囲、フォーマット、簡単なクロスフィールドチェックを行い、サーバは重複チェックや権限、在庫など共有状態に依存するルールを担当するのが現実的です。

添付ファイル：写真、署名、ファイル

各エンティティで許容する添付種類、最大ファイルサイズ、許可フォーマット、圧縮ルール、オフライン時の保存動作を決めておきます。端末の空き容量が少ないときにどうするか、写真を即時アップロードするかWi‑Fi待ちにするかも決めてください。

フィールド定義を文書化する

フィールド名、型、許容値、デフォルト挙動、バリデーションルールをまとめた軽量の「データ辞書」を作り、アプリ、API、下流のレポートで食い違いが出ないようにします。これだけで後の手戻りを何週間も防げます。

モバイルフォームUX：速く、親指で使いやすく、エラーに強く

フォームを立ったまま、歩きながら、手袋をしたままでもどれだけ早く完了できるかが勝負です。目的は単純：タップを最小化し、誤入力を防ぎ、次のアクションを明確にすること。

親指操作に配慮する

大きくタップしやすいフィールドとボタン、明確なラベル、誤タップを避けるための十分な間隔を採用します。レイアウトは予測可能に：画面ごとに主要なアクションは一つ（例：次へ や 保存）にし、配置を一貫させます。片手操作が多ければ、主要アクションは下部に置くと良いでしょう。

適切な入力コントロールを選ぶ

モバイルでのタイピングは遅く誤りが増えます。常に正しい入力タイプを使いましょう：

• 数値フィールドは数値キーボードを開く
• 日付や時刻はピッカーを使う
• Yes/No はトグルにする
• 少数の選択肢はセグメントやラジオボタンにする

これらでトレーニング不要にミスを減らし速度を上げられます。

デフォルト、オートフィル、「前回を繰り返す」

ユーザーのプロファイル、位置情報、現在時刻、直近の保存値などからスマートなデフォルトとオートフィルを使います。繰り返し作業にはテンプレートや「前回を複製」機能を追加し、前のレコードをコピーして差分だけ変えられると非常に効率的です。

ピックリストは特にオフライン時に検索より速いことが多いです。

短いフォームと進捗の可視化

フォームはステップに分けるか折りたたみ式にして短く保ちましょう。進捗（例：「ステップ2/4」）を表示してユーザーの位置を明確にします。任意の詳細は 詳細を追加 の下に隠して、必須項目と混ぜないでください。

パターンを標準化するなら、軽量のUIガイドを作って画面間で再利用してください（参照：/blog/common-pitfalls-and-a-practical-roadmap）。

エラーを防ぐ良いバリデーションとフィードバック

データ入力は静かに失敗します：桁不足、単位の取り違え、重複レコード。優れたアプリは単にバリデートするだけでなく、ミスが起きやすい瞬間にユーザーを正しい入力へ誘導します。

フォーム内でチェックを行う（バックオフィスではなく）

現場チームの実際のやり方に合わせたチェックを追加します：

• 必須フィールド は明確に示し（必要なら「なぜ必須か」も説明）
• 範囲チェック（例：温度0–120）やフォーマット（電話、日付、IDパターン）
• クロスフィールドルール（例：「終了時刻は開始時刻より後でなければならない」「状態 = 損傷 の場合は写真必須」）

バリデーションは速くローカルで動くようにし、電波が不安定でもフィードバックが返るようにします。

エラーは明確に、具体的に、入力の近くに表示する

メッセージはフィールドの近くに表示し、汎用バナーやフォーム末尾だけに出さないでください。平易な言葉で、良い値の例を伝えます：

• 悪い例：「Invalid value.」
• よい例：「数量は1から500までの整数で入力してください。」

送信失敗時は該当フィールドにフォーカスを移し、視覚的にハイライトします。

ソフトワーニングとハードブロックを使い分ける

すべての異常を止める必要はありません。可能性はあるが異常値のとき（例：「走行距離が高すぎるかもしれません」）は、承認してログに残せる警告を出します。ワークフローや法令順守を破るような場合のみハードブロックにします。

重複を事前に防ぐ

名前、住所、資産ID、顧客コードなどを入力する際は、検索/参照と候補の提示（「このレコードと類似しています—これを使いますか？」）を出します。事後のデデュープよりもこれが効果的です。

送信前の簡易レビューを入れる

短いサマリ画面を用意して、間違い（単位の間違い、写真の欠如、誤選択）をスクロールせずに見つけられるようにします。タップ可能にして該当フィールドへすぐジャンプできるようにしてください。

オフライン、同期、コンフリクト処理

現場チームは電波が切れても作業を続けます。接続必須の設計だと必要な瞬間にアプリが失敗します。オフラインをデフォルトと見なし、同期は最適化として扱いましょう。

オフラインファースト：端末を信頼できるソースにする

保存はまずローカルストレージ（端末上のデータベースなど）に書き、UIは常にローカルを参照するように設計します。これによりアプリは速く予測可能になり、地下や田舎、エレベーターでも使えます。

良いルール：ユーザーが「保存」をタップしたら、インターネットの有無に関わらず保存されたと感じられること。

変更をキューに入れて自動で同期する

即時送信にこだわらず、作成/更新/削除をアクションのキューとして記録します。接続が回復したらキューを順に処理し、接続が途切れたら自動で再試行します。

再試行は安全であるべきなので、アップロードを冪等にし、失敗時はバックオフして後で再挑戦しユーザーをブロックしない設計にします。

部分同期で高速化する

全部同期するのは遅くコストがかかります。ユーザーが必要とするものだけをダウンロードする部分同期を計画してください：

• 現在のルート、割り当てリスト、担当地域
• バリデーションに必要な最近のレコードや参照リスト
• 最後の同期以降に変更されたデータだけ

これにより起動時間、ストレージ使用、コンフリクトの可能性が減ります。

コンフリクト戦略を選んで文書化する

同期前に二人が同じレコードを編集するとコンフリクトが起きます。次のいずれかを選び明文化してください：

• Last write wins：最も単純だが作業を上書きすることがある
• フィールドレベルのマージ：異なるフィールドを別々に編集する場合に安全
• ユーザー選択：高価値なレコードでは「自分のものを残す／相手のものを残す」を提示する

どれを採るにしても、ログを残してサポートが説明できるようにします。

同期ステータスを可視化する

データが「届いたかどうか」をユーザーが迷わないよう、Pending（保留）, Synced（同期済み）, Failed（失敗）, Needs attention（対応要） のような明確な状態を表示し、手動の「今すぐ同期」も可能にします。失敗した場合は該当レコードと次に取るべきアクション（編集、再試行、サポート連絡）を示します。

入力を減らすために端末機能を活用する

端末のハードウェアを活用すると入力速度は劇的に上がります。目的は「かっこいい機能を付けること」ではなく、タップを減らし誤入力を避け、記録の信頼性を高めることです。

カメラキャプチャ（適切な圧縮と共に）

証拠写真が有用なワークフロー（損傷写真、領収書、メーター読取）では、カメラから直接添付できるようにします。

端末側で画像を圧縮（実用的な最大解像度にリサイズ）してアップロードを速くし、再撮影オプションと「ラベルをはっきり撮る」などの短いチェックリストを提示して、写真が追跡作業を増やすのではなく減らすようにします。

バーコード/QRスキャンで即時識別

スキャンはID、SKU、資産タグ、出荷コードの手入力を置き換え、最大の速度改善をもたらすことが多いです。

スキャンステップの設計ポイント：

• 関連フィールドを自動入力し（何が埋まったかを示す）
• 即時バリデーション（例：「不明なコード」には次の明確なアクション）
• ラベルが破損している場合の手動入力フォールバック

位置情報取得は有用な場合のみ

GPSは現場訪問、配達確認、監査では役立ちますが、デフォルトで必須にしないでください。明確な同意を求め、「この業務に位置情報を添付する理由」を説明します。連続トラッキングではなく「一度だけ取得」ボタンを使うか、位置が取れない場合は理由を入力して上書きできるようにします。

署名キャプチャ

承認サインが必要な場合は、フローの最後に署名キャプチャを追加します。署名者名、タイムスタンプ、任意の写真と組み合わせると証拠力が高まります。ポリシーで許されるなら「署名なし」の理由入力を必須にする選択肢も提供します。

権限と優雅なフォールバック

ハードウェアが常に使えるとは限らないと仮定してください（カメラをブロック、暗所、GPSなし、古い端末）。権限は必要な直前に求め、その利点を説明し、代替経路（手動入力、ファイルアップロード、理由をつけてスキップ）を用意してフォームが行き詰まらないようにします。

セキュリティ、権限、監査可能性

データ入力アプリは在庫、検査、顧客記録など運用データに触れることが多く、単に侵害を防ぐだけでなく誤った人が誤ったレコードを変更することを防ぎ、何が起きたか説明できるようにすることが重要です。

実際の業務に合ったロールと権限

各ロールが何をできるかを定義し、それをUIとバックエンドの両方に組み込みます：

• 誰が作成できるか vs. 既存のみ編集できるか
• 誰が承認/却下できるか（承認でフィールドがロックされるか）
• 削除できるのは誰か（多くの場合アプリからは不可。代わりに“無効化/アーカイブ”）
• ユーザーが自分のエントリのみ編集できるかチーム全体か

「管理者は何でもできる」をデフォルトにしないでください。昇格操作は明示的で監査可能にします。

端末上のデータを保護する

データが端末に数時間残ることを想定して保護します：

• セッショントークンはOS提供の安全ストレージに（Keychain/Keystore）
• 機密キャッシュは端末上で暗号化（デバイス共有を想定）
• 必要ならアプリロック（PIN/生体認証）のポリシーを実装

通信の安全性

TLSを全通信で使用し、盗難セッションに備え：

• 短寿命アクセス токен とリフレッシュ戦略
• 端末紛失やユーザー退職時のトークン回転/無効化

信頼できる監査ログ

重要な変更については誰が/何を/いつを記録し、可能ならデバイスやアプリバージョンも残します。承認や編集の不一致は不可変な履歴で解決できるようにします。

収集を最小限に、保持も最小限に

本当に必要な機微なデータだけを収集し、保持要件（何を、どれくらい、どう削除するか）を早めに決め、業界や社内ルールに合わせます。

データ入力アプリに重要な技術選択

技術選択は初期は変えやすく、後からは非常に変えにくいです。オフライン動作、迅速な検索、信頼できる同期を当たり前のものにするツールを選んでください。

ネイティブ vs クロスプラットフォーム：現場の現実で判断する

**ネイティブ（Swift/Kotlin）**はカメラ性能、バックグラウンドタスク、企業向けデバイス管理、非常に大きく複雑なフォームが必要な場合に有利です。

**クロスプラットフォーム（React Native/Flutter）**はMVPを速く出し、一貫したUIをiOSとAndroidで提供する上で現実的な選択です。大事なのはイデオロギーではなく、チームが修正を速く出せて、OSアップデートの影響を抑えられるかどうかです。

実用的なルール：アプリが主にフォーム＋オフライン＋同期であればクロスプラットフォームで十分なことが多い。端末固有のワークフローや厳しいエンタープライズ要件が多ければネイティブが長期的には楽になる場合があります。

APIスタイルとバージョニング：早めに決める

データ入力アプリではRESTが単純でキャッシュしやすく現場でのデバッグが容易です。GraphQLは過剰取得を減らしたり複雑な画面を簡素化できますが、キャッシュとエラーハンドリングに厳密さが必要です。

どちらでも、バージョン管理は初日から計画してください：

• エンドポイントにバージョンを付ける（例：/v1/...）
• アプリの更新がロールアウトするまで古いバージョンを運用する
• 「同期ペイロード形式」は契約とみなし、壊すとオフラインユーザーが死活問題になる

オフラインストレージ：実績のあるものを選ぶ

ローカル永続性が速さや信頼性を左右します。

• iOS：Core Data / SQLite
• Android：Room（SQLite）
• クロスプラットフォーム：SQLiteラッパーや成熟した組み込みDB（例：Realm）

選定基準は：検索の高速性、安全なマイグレーション、破損や部分データのデバッグツールです。下書き、添付、同期メタデータ（タイムスタンプ、ステータスフラグ、サーバID）の保存方法も決めてください。

バックグラウンド処理：アップロード、同期、通知

写真や署名、PDFを扱うならファイルアップロードを早期に設計します：圧縮、再試行ロジック、保留状態の明示。バックグラウンド同期はOSの制約（iOSのバックグラウンド制限、AndroidのWorkManager）を尊重し、バッテリーを無駄遣いしない設計にします。

プッシュ通知は、本当にワークフローを改善する場合のみ導入してください（割り当て変更や緊急更新など）。不要な通知は運用コストを増やします。

計測可能なパフォーマンス目標

開発前に目標を定めて「十分に速い」を主観で終わらせないようにします：

• フォーム読み込み時間（例：一般的なフォームで1–2秒未満）
• 検索速度（例：端末上で300ms未満）
• バッテリー影響（例：継続的なGPSは使用しない）

これらがローカルインデックス、ページング、画像サイズ、同期頻度に影響します。

最初のMVPを速く作る方法

ワークフローを早く検証したいなら、ビルドループの速さが重要です。Koder.ai のようなプラットフォームは、チャット駆動の「プランニングモード」からフォーム中心のMVP（Web管理画面、バックエンド、モバイル）を素早く作るのに役立ちます。コードのエクスポートやスナップショット/ロールバック機能があると、フォームロジックや同期挙動を試す際に便利です。

プロトタイプ、現場でのテスト、改善

会議室では完璧に見えるアプリでも、騒がしい現場や強い日差し、手袋をした手、電波の不安定な状況では失敗します。高額な作り直しを避ける最短ルートは、早めにプロトタイプを作り、実際の環境でテストし、フィードバックを継続的に取り入れることです。

クリック可能なプロトタイプから始める

本番コードを書く前に、現実的なフローを模したクリック可能なプロトタイプを作ります：作業者が最初に見る画面、よく使うフォームパス、想定される「やってしまいがち」場面（必須項目の欠落、誤選択、誤タップ）を含めます。実際の現場でユーザーに試してもらい、どこに摩擦があるかを探します。

探すべきは実務上の摩擦です：スクロールが多すぎる、ラベルがわかりにくい、ピックリストが長すぎる、フィールドがユーザーの思考と一致しない、など。

パイロットを実施し、聞くだけでなく測る

少人数で短いパイロットを行い、最も一般的なタスクの完了時間を計測します。定性的なフィードバック（「このドロップダウンは面倒」）と定量的な指標を組み合わせてください：

• 重要イベントの計測：バリデーションエラー、途中離脱ポイント、同期失敗、再試行
• 最も修正や往復が発生するフィールドの追跡

このデータが改善の費用対効果を示してくれます。

証拠に基づいてフォームを反復改良する

パイロット結果を使ってフォームの順序、デフォルト値、ピックリストを改善します。高頻度フィールドを前に移す、よく使われる値を事前選択する、リストを短くする—こうした小さな変更で完了時間は大幅に短縮できます。

また、アプリ内に簡単なフィードバックループを入れ、ユーザーがわざわざメールを探さなくても問題報告や改善提案が送れるようにします：

• 「問題を報告」（可能ならスクリーンショット/ログ添付）
• 「変更を提案」（短い自由記述）

小さなアップデートを迅速に出し、パイロット参加者に何が変わったかを伝えることで現場での採用が進みます。

ローンチチェックリスト：オンボーディング、サポート、信頼性

機能的には完成していても、初日に使えなければアプリは失敗します。起動時にすぐ仕事ができるか、ブロックされたときに助けを得られるか、送信が消えないと信頼できるかが重要です。ローンチを一つのプロダクト機能として扱ってください。

実務ができるオンボーディング

最初のセッションで有効なレコードが作れることを目標にします。スクリーンのツアーではなく、実務完了を優先してください。

共通ジョブ用のスターターテンプレート（例：「日次検査」「配達証明」「在庫数え」）と、良い例を示すサンプルレコードを用意します。日付、単位、必須写真など曲者フィールドには短い文のコンテキストチップ（閉じられる）を付けると定着が速くなります。

管理者がユーザーを招待する場合は、デフォルト（位置、チーム、デバイス権限）を事前設定してアプリを正しいワークフローで開けるようにします。

データのインポート/エクスポートと管理者の準備

ローンチ前に、管理者が既存データやレポートニーズをどう扱うかを決めます。

基本的なCSVインポート/エクスポート（ユーザー、場所、製品/資産、フォームテンプレート）をサポートし、連携が必要ならローンチ時に対応する範囲を文書化して、フィールドマッピングや失敗チェックができるシンプルな管理UIを提供してください。

監視と信頼性指標

クラッシュ、APIエラー、同期異常（詰まったキュー、繰り返し再試行、大きすぎるペイロード）を監視します。重要な成功指標を追いましょう：「作成されたレコード数」、「正常に同期されたレコード数」、「平均同期時間」、「バリデーション失敗率」など。

送信不能時のサポートとエスカレーション

作業者が送信できない場合の明確な対応ルートを定義します：アプリ内の「問題を報告」（ログ添付可）、人的対応目標（例：同営業日中の対応）、時間クリティカルな業務のためのエスカレーション経路。安全な回避策として下書きを保存して手動送信のためにエクスポートする方法も用意します。

オフラインユーザーを壊さない更新方針

オフライン実態を尊重したアップデート戦略を立てます。互換性を一定期間保ち、破壊的なスキーマ変更はマイグレーションを提供し、必須アップデートがある場合はアプリ内で通知して段階的に展開します。エンドポイントやバリデーションを変えるなら同期エラーの急増を監視してから強制アップデートをかけてください。

よくある落とし穴と実践的なロードマップ

多くのデータ入力アプリが失敗する理由は予測可能です：デスクトップソフトのように設計され、完璧な条件でしかテストされず、現実と齟齬が生じたときの対策がないままローンチされること。

避けるべきよくある失敗

過度に長いフォームは古典的なミスです。1件あたりの作業が1分以上かかると、ユーザーは項目を飛ばしたり「N/A」と入力したり、アプリを放棄します。

もう一つはオフライン計画がないこと。現場は地下、田舎、倉庫、車内で働くことが多く、接続は安定しません。

不明瞭なエラーも静かな生産性の殺し屋です。「Invalid value」では何を直すべきかわかりません。平易な言語で修正方法を示してください。

後で響く「隠れた」複雑さ

チームが過小評価しがちな点：

• 添付ファイル（写真、署名、文書）：保存、アップロード再試行、サイズ制限
• 同期＋コンフリクト解決：二人が同じレコードを編集したときの挙動
• 承認とステータス変更：下書き、送信、却下、監査ログ

これらを早期に無視するとローンチ後にワークフローを作り直す羽目になります。

段階的なロードマップ

小さく始め、段階的に拡張します：

1. MVP（2–6週間）：コアフォーム、必須バリデーション、基本的なユーザーロール、簡易レポート/エクスポート
2. オフライン＋信頼性：ローカル下書き、バックグラウンド同期、明確な同期状態、定義されたコンフリクトルール
3. 連携：CRM/ERP、SSO、Webhookとの接続
4. 高度なレポーティング：ダッシュボード、QAサンプリング、例外トラッキング、パフォーマンス指標

時間が限られる中でMVPを作るなら、Koder.ai のようなvibe-codingワークフロー（チャットで誘導してReact管理画面、Go+Postgresバックエンド、Flutterモバイルを生成）でパイロットまで早く到達し、その後にオフライン、同期、監査性を強化していくのが現実的です。

要件の簡易テンプレート（コピーして使える）

• フィールド：名前、型、必須/任意、デフォルト値
• ルール：最小/最大、クロスフィールドロジック、条件表示
• ワークフロー：下書き → 送信 → 承認/却下；誰がいつ編集できるか
• ロール：作成者、レビュアー、管理者；各ロールの権限
• デバイス：想定する端末モデル、OSバージョン、カメラ/バーコード要件、オフライン期待値

現実的なMVP（とその先のロードマップ）を一緒にスコーピングしたいなら、/pricing を参照するか /contact で連絡してください。