はじめに
友人の会社（中小企業、エンジニア不在）から「出荷時の検品作業を効率化したい」という相談を受けました。
当初の要望は Google Apps Script（GAS）で検品アプリを作って欲しい というもので、スプレッドシートと連携し、バーコードを入力して商品マスタと照合、検品結果を記録する仕組みをGASで構築しました。
要望通りの機能は実現できましたが、実際に利用すると以下の課題が浮かびました。
- データ件数が増えると処理が遅くなる（1件ごとに数秒待ち）
- 当時の時点でもデータ件数があり、スプレッドシートの読み込みも含めると3~5秒時間がかかっていた
- 同時利用でレスポンスが悪化し、実務スピードに追いつかない
- GASは保守が属人化しやすく、エンジニア不在の会社では維持が難しい
つまり「小規模・単発利用」には十分でも、日常業務に耐えられる仕組みではなかったのです。
そこで「もっと早く、簡単に、ノーコードで業務アプリを作れないか？」と探したときに出会ったのが Retool です。
Retoolとは？
Retoolは、社内業務アプリをノーコード／ローコードで素早く構築できるプラットフォームです。
UIコンポーネント（テーブル、フォーム、スキャナなど）をドラッグ＆ドロップで配置し、SQLやAPIを組み合わせるだけで、検品アプリや在庫管理アプリなどを短時間で開発できます。
インフラ・環境構成
Retoolには クラウド版 と セルフホスト版 の2つの利用形態があります。
- Retool Cloud
- Retool社がフルマネージドで提供
- インフラ管理不要、TLS通信／AES-256暗号化でセキュリティ担保
-
Self-hosted Retool
- Dockerコンテナベースで自社クラウド（AWS/GCP/Azure）やオンプレにデプロイ可能
- 主な構成要素
- backend：アプリAPI・UI処理
- jobs-runner：非同期ジョブ実行
- workflows-backend / workflows-worker：ワークフロー管理
- code-executor-service：JS/Python実行環境
- Postgres：Retool内部DB
-
ワークフロー実行には Temporal を利用し、信頼性の高いスケジュール処理が可能
-
デプロイは Docker/Kubernetes/Helm、あるいは Northflankのテンプレート
でも可
小規模利用なら Cloud、セキュリティ要件が厳しい環境なら Self-hosted、と使い分けができます。
料金体系
料金体系はこちらの通り。ユーザー数やデータ量の制限はありますが、無料プランもあります！
今回はエンジニアが不在の企業向けで、かつ今回の要件には制限に引っ掛からなさそうだったため、FreeのCloud版を前提として検討を進めました。
アプリの要件
今回の検品アプリで満たしたかった要件は次の通りです。
- バーコード読み取り → 商品マスタと照合
- 照合結果（OK/NG）を即時表示
- 出荷指示リストに検品進捗を記録
- PC／スマホ両対応
データソースの準備
最終的には以下の3テーブルを利用しました。
- Product テーブル（商品マスタ）
商品に関する基本情報を保持しています。
- product_id : 商品ID
- product_code : 商品コード
- product_name : 商品名
- barcode : バーコード
- active : 利用中フラグ
- created_at / updated_at : 作成・更新日時
バーコードスキャン時にこのテーブルと突合します。
- Shipments テーブル（出荷情報）:
出荷単位（オーダー）を管理するテーブルです。
- shipment_id : 出荷ID
- order_no : 注文番号
- created_at / updated_at : 作成・更新日時
- status : 出荷ステータス（例：pending、shipped など）
出荷全体の管理単位として利用します。
- Shipment_Items テーブル（出荷明細）
出荷に紐づく個別の商品明細を保持します。
- shipment_item_id : 出荷明細ID
- shipment_id : 出荷ID（Shipments テーブルとリレーション）
- product_id : 商品ID（Product テーブルとリレーション）
- quantity : 出荷数量
- picked_quantity : 検品済み数量
- picking_status : 検品ステータス（例：not_started / completed）
- note : 備考
バーコード照合後、このテーブルを更新して「検品数」や「検品ステータス」を管理します。
テーブル間の関係性（ER的イメージ）
Shipments (出荷)
└─ Shipment_Items (出荷明細) ── Product (商品マスタ)
- Shipments が「出荷オーダー」を表す
- Shipment_Items が「その出荷に含まれる商品明細」を表す
- Product が「商品情報のマスタ」を表す
この構成にすることで、
- Scannerで読み取ったバーコード → Productと照合
- Shipment_Itemsを更新して検品進捗を記録
- Shipmentsのステータスを更新（全品完了したら completed など）
という流れで、検品アプリを実装できます。
なおCloud版ではPostgreSQLを利用することが可能です。
実装フロー
-
Scannerコンポーネント設置
読み取ったバーコードをステートに格納し、画面に表示してデバッグ -
照合処理
Productと突合 → 一致ならOK、不一致ならNGを表示 -
出荷明細更新
Shipment_Itemsに検品済み数量やステータスを反映 -
UI改善
商品名や数量を表示し、作業者が直感的に判断できるように調整
実際のイメージ
なお、画面のキャプチャに含まれるデータについては、全て生成AIで作成したテストデータを利用しています。
注文検索画面
ここで該当の注文情報を検索します。
ピッキング指示画面
注文検索画面で表示された注文番号に対して、ピッキング指示（例えば納品書も一緒に含めて欲しい など）を表示して確認をさせる画面です。漏れないようにフローの中でこの画面だけ独立して作っています。
検収画面
この画面で実際にバーコードを読み取り、数量を入力して検品を行います。
バーコードの読み取りができないケースに備えて、バーコードの番号を手入力できるようにもしています。
初めての利用ではありますが、こういった画面や機能を2人日程度の工数で作ることができました。
また、データの処理速度もスプレッドシートの読み込み時間がなくGASと比較して処理速度も改善されました。（体感1秒未満）
感想
- 私の作り方が良くなかったのかもしれませんが、ノーコードを謳いつつもSQLやJavaScriptを利用するケースがありました
- 言い方を変えるとJavaScriptの埋め込みもできるため、部分的に複雑な処理など行うことが可能
- データのバックアップなどはまだ実装できていないですが、調べてみるとワークフローを利用することでS3やGoogleDriveへバックアップファイルを作成することは可能
- ただし、Freeプランでは利用回数制限あり、かつスケジューラー組んでの実施はできないみたいです
- ノーコード全般ですが、UI上でポチポチ設定する必要があり、AI駆動開発などは出来ないため、AIを利用した開発に慣れていると作りにくさを感じてしまうかもしれないです。（私自身とても感じました）
まとめ
Retoolを使えば、ノーコードで検品アプリを素早く構築できることがわかりました。
またFreeプランでもPoCレベルは十分に利用できるかと思いますし、Cloud版だとインフラを意識せずノーコードで開発できるため、エンジニアリソースが割けない組織には良いツールかなと思いました！