在庫が減っていることに気づくのは、いつも棚を見に行った担当者の目視です。
発注担当が出張や休みで不在だと、気づいたはずの在庫切れがそのまま数日放置され、現場から「もうないんですけど」と催促されて初めて発注書を作り始める。
発注のたびにExcelの在庫表を見ながら数量を決め、上長にメールで確認を取り、承認が返ってくるまで発注を止めておく作業も、担当者の記憶とタイミング任せというのが実情です。
Power Automateを使うと、在庫リストの数量が発注点を下回った品目を自動で拾い上げ、発注の承認依頼を上長に回し、承認された結果だけを発注記録として残す仕組みを組めます。
この記事では、在庫リストの閾値判定から発注承認、発注記録までの完成イメージと手順、そして自動化するからこそ必要になる誤発注を防ぐ確認ポイントを整理しています。
在庫発注ワークフローの完成イメージ
在庫発注ワークフローは、在庫リストの閾値割れを検知するところから、発注承認、発注記録までをひとつのフローで完結させる仕組みです。
毎朝決まった時刻にPower Automateが在庫リストを確認し、現在庫数が発注点を下回っている品目があれば、品目ごとに発注担当へ承認依頼を送ります。
発注担当が承認すると、品目名・発注数量・発注先が発注記録リストに1件ずつ書き込まれ、却下すればその品目は今回見送りとして記録だけが残る流れです。
目視での棚チェックと、発注のたびにメールで確認を取るやり取りの両方が、この仕組みに置き換わります。
在庫リストはSharePointリストとExcelのどちらで管理するか
閾値判定の元になる在庫リストを、SharePointリストで持つかExcelの表で持つかは、この後の手順の組み方に関わるため先に決めておく必要があります。
| 管理方法 | 閾値判定の組み方 | 向いている規模 |
|---|---|---|
| SharePointリスト | 「複数の項目の取得」で全件を取得し、Apply to eachで1品目ずつ現在庫数と発注点を比較する | 品目数が多い、複数人で同時に更新する |
| Excelのオンラインブック | 「表内に存在する行を一覧表示」で全行を取得し、Apply to eachで同様に比較する | 品目数が少なく、担当者が手元のExcelで運用したい |
ここでは以降、SharePointリストを使う前提で手順を進めますが、複数人が同時に在庫数を更新する運用ではExcelのファイルロックによる同時編集の制限を受けにくく、実務でも扱いやすい方法だからです。
Excelで運用する場合も、閾値判定の考え方とApply to each以降の手順はそのまま流用できます。
在庫発注ワークフローを作る手順
在庫リストの置き場所が決まったら、閾値判定から発注記録までを次の順番で組んでいく流れです。
Step1. 在庫リストに発注点の列を用意する
SharePointリストに、品目名、現在庫数、発注点、発注数量の目安、発注先を列として用意します。
発注点は品目ごとに使用ペースが違うため、一律の数値ではなく品目ごとに個別の値を入力しておく列です。
発注数量の目安は、承認依頼の本文にそのまま差し込むための参考値として使う列です。
Step2. 毎朝在庫リストを確認し閾値割れを抽出する
トリガーには「繰り返し」を使い、毎朝1回フローが実行されるように設定します。
続けて「複数の項目の取得」アクションでStep1の在庫リストを全件取得し、「Apply to each」で1品目ずつ処理する構成です。
Apply to eachの中に「条件」アクションを置き、現在庫数が発注点以下かどうかをその場で判定する構成です。
現在庫数と発注点はどちらも品目ごとに違う値のため、リストから取得した動的な値同士を条件で直接比較する形になります。
Step3. 閾値割れの品目ごとに発注承認を依頼する
条件の「はい」側に、承認コネクタの「開始して承認を待つ」アクションを追加します。
タイトルと詳細には、Step1で取得した品目名、現在庫数、発注点、発注数量の目安を差し込み、発注担当が数字を見ただけで判断できる内容にする構成です。
承認アクション自体の基本的な組み方は別の記事で詳しく解説しています。
Step4. 承認された品目だけを発注記録リストに書き込む
承認結果で条件分岐し、承認された品目だけSharePointコネクタの「項目の作成」アクションで発注記録リストに書き込みます。
書き込む列は、発注日時、品目名、発注数量、発注先、承認者です。
却下された品目は発注記録リストには書き込まず、承認依頼のやり取り自体をログとして残すだけにとどめます。
誤発注を防ぐ人の確認ポイント
閾値割れを自動で検知する仕組みにしても、発注そのものを人の確認なしに実行しない設計にしておく必要があります。
承認依頼の本文に現在庫数と発注点の両方を必ず表示し、発注担当が「本当に今発注する数量として妥当か」を数字で判断できるようにしておくことが前提です。
需要が一時的に落ち込んでいる品目や、すでに別ルートで発注済みの品目まで機械的に承認依頼が飛んでしまうと、承認担当の側が慣れで承認してしまう恐れがあります。
もうひとつの注意点は、フローを毎日実行する設計にした場合、前日の承認依頼がまだ回答されないうちに翌朝また同じ品目の承認依頼が届いてしまう二重依頼です。
在庫リストに「発注依頼中」のような状態列を追加し、承認依頼を送った品目はこの列を更新して、Step2の条件で発注依頼中の品目を対象から外す形にしておくのが二重依頼を避ける設計です。
そして承認か却下の結果が返ってきた時点で、SharePointコネクタの「項目の更新」でこの状態列を空に戻します。
状態列を戻さないと、一度発注依頼を送った品目が発注依頼中のまま固定され、在庫が再び発注点を下回っても検知の対象から外れたままになるためです。
在庫の増減を自動で検知して通知する仕組み自体は、Google Apps Scriptでも同じ考え方で組めます。
Google Workspace環境で在庫アラートだけを組みたい場合の手順は別の記事で扱っています。
在庫発注の承認ワークフローでお困りではありませんか？
「発注担当が不在のときに在庫切れへの対応が遅れる」「Excelの在庫表とメールでのやり取りだけで発注管理が属人化している」「自動化したいが誤発注が怖くて踏み出せない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、Power Automateの業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. 発注点は品目ごとに違う値を設定できますか？
設定できます。
在庫リストに発注点の列を用意し、品目ごとに個別の数値を入力しておく形です。
使用ペースが速い品目は発注点を高めに、動きが遅い品目は低めに設定しておくと、実態に近い閾値判定になります。
Q. 在庫リストをExcelで管理していてもこの仕組みは使えますか？
使える仕組みです。
「表内に存在する行を一覧表示」アクションでExcelの表から全行を取得し、以降はSharePointリストの場合と同じくApply to eachで1行ずつ比較する形に組み替えられます。
ただし複数人が同時に在庫数を更新する運用では、SharePointリストのほうがファイルの同時編集による制限を受けにくい仕組みです。
Q. 承認依頼が二重に届くことはありませんか？
在庫リストに発注依頼中かどうかを示す状態列を追加せずに毎日実行すると、前日分の回答が済む前に同じ品目の承認依頼が翌朝も届く二重依頼が起こり得ます。
承認依頼を送った時点で状態列を更新し、閾値判定の条件からその品目を除外する設計にしておくことで防げる仕組みです。
Q. 承認が却下された品目はどう扱われますか？
却下された品目は発注記録リストには書き込まれず、その回の発注は見送りになります。
翌朝以降も現在庫数が発注点を下回ったままであれば、Step2の閾値判定に再び該当し、承認依頼が改めて届く仕組みです。
