紙やExcelで在庫を管理していると、最新版が分からない、出庫の反映が遅れる、棚卸し差異の理由が追えない、という問題が起きやすいですよね。
PowerApps 在庫管理アプリは、いきなり大きなシステムを作るより、まず入出庫と棚卸しをSharePointに残す形から始めると作りやすいです。
現場で使うなら、画面の見た目だけでなく、品目ID、履歴、数量、保管場所をどう扱うかが大事になります。
PowerApps在庫管理アプリの全体像
PowerAppsで在庫管理アプリを作るときは、最初に業務の流れを分けると設計しやすいです。入庫、出庫、棚卸し、確認の役割を分けて、まずは小さく使える範囲から始めます。
在庫管理アプリでできること
PowerAppsで作る在庫管理アプリでは、入庫、出庫、棚卸し、在庫確認を1つの流れにできます。
たとえば、商品を受け取ったら入庫を登録し、現場へ持ち出したら出庫を登録します。
月末や週次の棚卸しでは、実際に数えた数量を入れて、システム上の数量との差を見ます。
紙やExcelの在庫表でも同じことはできますが、更新のタイミングが人によってズレやすいです。
PowerAppsなら、スマホやタブレットから登録できるため、現場で動いたタイミングに近い形で履歴を残せます。
MicrosoftのPower Apps概要では、Power Appsはローコードで業務アプリを作り、さまざまなデータソースへ接続できるプラットフォームとして説明されています。
在庫管理では、この特徴を使って、現場入力と管理者確認をつなげます。
在庫管理アプリの目的は、在庫数をきれいに見せることだけではありません。誰が、いつ、何を、どれだけ動かしたかを追える状態にすることです。
入庫 出庫 棚卸しを分ける
在庫管理では、入庫、出庫、棚卸しを同じ「数量入力」として扱いたくなります。
ただ、運用では意味が違います。
入庫は在庫を増やす処理です。
出庫は在庫を減らす処理です。
棚卸しは、理論上の在庫と実際の数量を合わせる確認です。
この3つを区分せずに保存すると、あとから差異の原因を追いにくくなります。
SharePointリストに保存するときも、MovementType のような列を作り、区分を残しておくと便利です。
| 区分 | 数量への影響 | 主な利用シーン |
|---|---|---|
| 入庫 | 在庫を増やす | 仕入れ、返品、補充 |
| 出庫 | 在庫を減らす | 使用、出荷、持ち出し |
| 棚卸し | 実数を確認する | 月末、週次、スポット確認 |
最初は入庫と出庫だけでもよいですが、棚卸しを後回しにすると、差異が見えたときに原因を追えません。
小さく始める場合でも、棚卸しの記録欄だけは用意しておくのがおすすめです。
QRコードやバーコードで入力ミスを減らす
在庫管理アプリでよく起きる問題は、品目名の入力ミスです。
「ネジ M4」と「M4ネジ」のように表記が分かれると、検索や集計が崩れます。
そこで、品目名ではなく品目IDを軸にします。
棚や商品ラベルにQRコードを貼り、PowerAppsで読み取って品目を特定する形です。
Microsoft LearnのBarcode reader controlは、キャンバスアプリでバーコードやQRコードを読み取るためのコントロールです。
在庫管理では、品目ID、棚番、ロケーションコードを読み取る用途に向いています。
読み取り後は、LookUp で商品マスタから該当品目を探し、品目名や単位を画面に表示します。
手入力に頼りすぎると、少しずつ表記ゆれが増えます。
最初からコード化しておくと、現場入力が安定します。
SharePointリストの設計
在庫管理では、SharePointリストの作り方があとから効いてきます。現在庫だけを1列で持つより、商品マスタと入出庫履歴を分けて、在庫の動きが追える設計にします。
商品マスタと入出庫履歴を分ける
PowerAppsとSharePointで在庫管理を始めるなら、まずは商品マスタと入出庫履歴を分けます。
Microsoft LearnのSharePoint接続ドキュメントでは、キャンバスアプリからSharePoint Onlineなどへ接続できることが説明されています。
部門内の在庫管理なら、SharePointリストは始めやすいデータソースです。
ただし、1つのリストに全部入れると、後から扱いにくくなります。
商品マスタは「何を管理するか」の一覧です。
入出庫履歴は「いつ、どれだけ動いたか」の記録です。
棚卸し履歴は「実際に数えた結果」です。
| リスト | 主な列 | 役割 |
|---|---|---|
| 商品マスタ | 品目ID、品目名、単位、保管場所、最低在庫 | 管理対象を固定する |
| 入出庫履歴 | 品目ID、区分、数量、日時、担当者、メモ | 在庫の動きを残す |
| 棚卸し履歴 | 品目ID、理論在庫、実棚数、差異、棚卸し日 | 差異を確認する |
この形にすると、商品名を変更しても過去の入出庫履歴を残しやすいです。
マスタと履歴を分けるだけで、運用の見通しがかなり良くなります。
現在庫は履歴から考える
在庫管理アプリを作るとき、現在庫を商品マスタの1列に持たせたくなります。
もちろん、現在庫列を持つ設計もあります。
ただ、すべてを現在庫の上書きで処理すると、なぜ増えたのか、なぜ減ったのかが残りません。
在庫が合わないときに、「誰がいつ動かしたか」を追えないのは痛いです。
そのため、基本は入出庫履歴を追加し、現在庫は集計で考えます。
入庫はプラス、出庫はマイナス、棚卸しは差異確認として扱います。
小規模ならPowerApps側で集計してもよいですが、履歴が増える場合はビューやPower Automate、Power BI、Dataverseなども検討します。
直接上書きだけで進めると、差異の説明が難しくなります。
在庫数は業務判断に使われるため、履歴なしの上書き運用は避けたいです。現在庫列を持つ場合でも、入出庫履歴は別で残しておくと安心です。
品目IDと保管場所を固定する
在庫管理で大事なのは、品目名より品目IDです。
品目名は人が読むための名前なので、表記ゆれが起きやすいです。
一方、品目IDはアプリが品目を特定するためのキーです。
QRコードやバーコードに入れる値も、品目IDにしておくと扱いやすいです。
保管場所も固定しておきます。
「倉庫A」「第1棚」「ライン横」など、現場で通じる粒度にします。
細かくしすぎると入力が重くなりますが、粗すぎると探せません。
最初は保管場所、棚番、単位、最低在庫を商品マスタに持たせるとよいです。
| 列名 | 型の例 | ポイント |
|---|---|---|
| ItemCode | 1行テキスト | QRコードに入れる固定ID |
| ItemName | 1行テキスト | 画面表示用の品目名 |
| Location | 選択肢 | 保管場所を統一する |
| Unit | 選択肢 | 個、箱、kgなど |
| MinStock | 数値 | 最低在庫アラートに使う |
品目名だけで検索する設計は、最初は楽でも後から苦しくなりやすいです。
入出庫画面とQRコード読み取り
データ設計ができたら、現場で迷わず使える画面に落とし込みます。品目検索、QR読み取り、数量入力、保存完了までの流れを短くし、入力ミスを減らします。
一覧画面で対象品目を探す
在庫管理アプリの入口は、品目一覧です。
Galleryに商品マスタを表示し、品目名、品目ID、保管場所、現在庫を見せます。
現場では、一覧が長すぎると探すだけで時間がかかります。
検索ボックス、カテゴリ、保管場所、よく使う品目の絞り込みを用意します。
たとえば、検索ボックスの値で品目名や品目IDを絞り込み、ドロップダウンで保管場所を選べるようにします。
一覧では、現在庫と最低在庫も見えると便利です。
最低在庫を下回っている品目には、赤いラベルやアイコンを出します。
ただし、赤い表示を増やしすぎると、どれが本当に重要か分かりません。
警告だらけにならないよう、最低在庫や欠品だけに絞るのがよいです。
一覧画面では、すべてを表示するより、今日動かす品目を早く見つけられることを優先します。検索、カテゴリ、保管場所の3つがあると使いやすいです。
QRコードで品目IDを読み取る
QRコードやバーコードを使う場合は、品目IDを読み取り、その値で商品マスタを探します。
画面にBarcode reader controlを置き、読み取った値を変数や入力欄に入れます。
その後、LookUp(Items, ItemCode = 読み取り値) のような考え方で品目を特定します。
読み取った品目名、単位、保管場所を画面に表示すれば、作業者は合っているか確認できます。
読み取り、確認、数量入力の順にすると、ミスが減ります。
QRコードを使うときは、次のような値を入れると扱いやすいです。
- 品目IDだけを入れる
- 棚番だけを入れる
- 品目IDとロケーションを組み合わせる
最初は品目IDだけがおすすめです。
複雑な値を入れると、アプリ側で分解する処理が増えます。
棚ごとにQRコードを貼る場合は、棚番を読み取り、該当場所の品目だけ表示する使い方もできます。
入庫 出庫 棚卸しを同じ型で扱う
入庫、出庫、棚卸しは意味が違いますが、画面の入力パターンは似ています。
基本は、品目を選び、区分を選び、数量を入力し、保存します。
そのため、同じ画面に区分ボタンを置き、選んだ区分によって表示を変えると作りやすいです。
入庫なら「入庫数」、出庫なら「出庫数」、棚卸しなら「実棚数」と表示します。
入力欄は同じでも、ラベルを変えるだけで現場は迷いにくくなります。
区分ボタンを大きくし、選択中の区分を色で分かるようにします。
保存前には、品目名、区分、数量を確認します。
特に出庫は在庫を減らす処理なので、数量が大きいときは確認を出してもよいです。
誤出庫は現場トラブルにつながりやすいため、出庫時だけ注意表示を出す設計が合います。
Patchで在庫履歴を保存する
在庫管理アプリでは、保存時に何を残すかがあとから効いてきます。入出庫履歴を1行ずつ追加し、品目ID、区分、数量、日時、担当者を記録します。
履歴追加を基本にする
入出庫履歴を保存するなら、Patchを使ってSharePointリストに新しい行を追加できます。
Microsoft LearnのPatch関数では、データソースのレコードを作成または変更する関数として説明されています。
在庫管理では、入出庫のたびに履歴追加する形が分かりやすいです。
例として、StockMovements というSharePointリストに履歴を追加します。
Patch(
StockMovements,
Defaults(StockMovements),
{
ItemCode: txtItemCode.Text,
MovementType: ddMovementType.Selected.Value,
Quantity: Value(txtQuantity.Text),
MovedAt: Now()
}
)この例では、品目ID、区分、数量、日時を保存しています。
実際には、担当者、保管場所、メモ、入力元画面なども残すと運用しやすいです。
保存する項目は多すぎても入力が重くなりますが、品目ID、区分、数量、日時、担当者は残したいです。
現在庫を直接上書きしすぎない
Patchを使えば、商品マスタの現在庫列を直接更新することもできます。
ただし、現在庫だけを更新すると、在庫が変わった理由が見えません。
たとえば、現在庫が100から70になったとき、出庫なのか、棚卸し調整なのか、誤入力の修正なのかが分からなくなります。
そのため、基本は履歴を追加します。
現在庫列を持つ場合でも、履歴追加とセットで更新します。
処理の考え方は次のようになります。
- 入出庫履歴に1行追加する
- 必要に応じて商品マスタの現在庫を更新する
- 保存後に一覧を再読み込みする
- 成功通知を表示する
履歴を残すだけでなく、保存が成功したかも作業者に見せます。
保存済みの表示がないと、作業者は二重登録してしまうことがあります。
二重登録を防ぐため、保存ボタンの連打対策も入れておくと安心です。
保存後の通知とエラー表示を作る
保存処理は、成功時と失敗時を分けて考えます。
成功したら「登録しました」と表示し、入力欄をクリアします。
失敗したら「保存できませんでした」と表示し、入力内容を消さないようにします。
現場では通信状態が悪い場所もあります。
保存失敗時に入力内容が消えると、作業者の負担が大きいです。
Power Appsでは、Notify や IfError を使って、成功と失敗を分けて表示できます。
たとえば、保存ボタンの処理では、次のような考え方にします。
IfError(
Patch(
StockMovements,
Defaults(StockMovements),
{
ItemCode: txtItemCode.Text,
MovementType: ddMovementType.Selected.Value,
Quantity: Value(txtQuantity.Text),
MovedAt: Now()
}
),
Notify("保存できませんでした", NotificationType.Error),
Notify("保存しました", NotificationType.Success)
)実際のアプリでは、数量が空なら保存しない、0以下なら警告する、出庫数が現在庫を超えたら止める、といったチェックも入れます。
入力チェックは地味ですが、在庫管理ではかなり重要です。
保存処理は「登録できるか」だけでなく、「間違った登録を防げるか」まで見る必要があります。数量、区分、品目IDのチェックは必ず入れたいです。
運用で失敗しないポイント
アプリは作って終わりではなく、毎日使われる運用に合わせる必要があります。委任、通知、権限、マスタ変更を最初から決めておくと、あとで作り直しにくくなります。
委任とデータ量を最初から見る
在庫管理アプリは、使い続けるほど履歴が増えます。
最初は数百件でも、毎日入出庫があるとすぐに数千件になります。
Power Appsでは、式やデータソースによって委任できる処理とできない処理があります。
Microsoft Learnの委任の概要では、大きなデータセットを扱うときに、サーバー側で処理できる式を使う重要性が説明されています。
在庫履歴では、全件をアプリに読み込んでから絞るより、日付や品目IDで先に絞る設計が安全です。
たとえば、次のような見方を用意します。
- 今日の入出庫
- 今月の入出庫
- 品目ID別の履歴
- 保管場所別の在庫
- 最低在庫を下回った品目
日付、品目ID、保管場所の列は、絞り込みでよく使います。
最初から検索条件を決めておくと、履歴が増えても扱いやすいです。
全件表示を前提にすると、後から表示速度や委任警告で困りやすいです。
最低在庫や棚卸し差異を通知する
在庫管理アプリを現場で使うなら、見に行かないと分からない状態を減らします。
最低在庫を下回ったら通知する、棚卸し差異が大きいときだけ管理者へ知らせる、という形です。
Power Automateと組み合わせれば、SharePointリストに行が追加されたタイミングで通知できます。
通知条件は、最初から複雑にしすぎないほうがよいです。
まずは最低在庫と大きな差異に絞ります。
通知が多すぎると、誰も見なくなります。
通知過多は運用を弱くします。
在庫管理で使いやすい通知は、次のようなものです。
| 通知 | 条件例 | 宛先 |
|---|---|---|
| 欠品通知 | 現在庫が0 | 管理者 |
| 最低在庫通知 | 現在庫が最低在庫未満 | 発注担当 |
| 差異通知 | 棚卸し差異が一定以上 | 現場責任者 |
| 未処理通知 | 棚卸し差異の確認が未完了 | 管理者 |
通知は、すぐ必要なものだけに絞るのがコツです。
マスタ変更と権限を決める
在庫管理アプリで意外と大事なのが、誰が商品マスタを変えられるかです。
品目ID、品目名、単位、保管場所、最低在庫を誰でも変更できると、集計が崩れやすくなります。
現場担当者は入出庫を登録し、管理者は商品マスタを更新し、閲覧者は在庫を見るだけ、という分け方が分かりやすいです。
SharePointリストの権限やアプリ内の表示制御で、担当者、管理者、閲覧者を分けます。
ただし、複雑なロールや厳密な権限が必要なら、SharePointだけで無理に作り込まないほうがよいです。
Microsoft LearnのDataverse概要では、業務データを扱うためのデータプラットフォームとしてDataverseが説明されています。
品目数が多い、部署をまたぐ、権限が細かい、監査ログが重要、といった場合はDataverseも候補になります。
まずはSharePointで小さく開始し、運用が固まったらDataverse化を検討する流れが現実的です。
SharePointは始めやすさが強みです。一方で、複雑な権限、関連テーブル、多拠点運用、厳密な監査が必要な場合は、Dataverseや既存システム連携も視野に入れると安心です。
PowerApps 在庫管理に関するよくある質問
まとめ
PowerAppsで在庫管理アプリを作るなら、まずSharePointリストで商品マスタと入出庫履歴を分け、QRコードやPatchで現場入力を短くするのが現実的です。
在庫は毎日動くので、最初から履歴、委任、権限、通知を意識して作ると、あとから育てやすくなります。
まずは1つの倉庫、1つの品目カテゴリ、1つの入出庫フローに絞って、在庫管理テンプレートとして使える形から始めてみてください。
