発注アプリの通知機能で発注忘れは防げる？仕組み・限界・導入前に見るべき条件

◆監修・編集責任者　小園 将隆　2026年10月1日

B2B EC-COLUMN

発注忘れはなぜ起きるのか―繁忙期のうっかりと属人化

週末の仕込みに追われているうちに、いつもの発注日が過ぎていた。
納品予定表を見て初めて気づき、取引先に無理を頼んだ——そんな経験があると、通知で本当に止められるのかが気になります。
発注アプリの通知は、日付を基準に知らせるリマインド型、在庫数の低下をきっかけにする在庫連動型、承認が止まった申請を催促する型に分かれ、原因の違う発注忘れにそれぞれ対応します。
ただし自分の操作やファイル取込では飛ばない、既定では一度しか鳴らない、担当者が代わるとメールが届かなくなるといった穴もあります。
仕組みと穴の両方を知ったうえで、自分の発注の進み方に合う方式と運用を選ぶことが、欠品を減らす近道になります。

繁忙期の確認漏れ・入力ミス

発注忘れは、注意力や気のゆるみの問題として片づけられがちです。
けれど実際に起きた場面を思い出すと、たいていは別の作業が重なっています。
納品の受け入れ、棚の整理、来客対応が続いた日に、発注画面を開く数分だけが後回しになる。
後回しにしたという記憶そのものも、次の作業で上書きされてしまいます。

発注業務の課題を整理した解説では、FAXやメールで受け取った注文書を基幹システムやExcelへ手入力する作業が人的ミスの温床になりやすく、品番や数量の入力間違いが誤発注につながると指摘されています³。
これは書類を受け取って入力する側の話ですが、注文を出す側でも構図は大きく変わりません。
棚を目で見て、メモに書き、別の画面に打ち直す。
人の記憶と転記をはさむ工程が残っているかぎり、忙しい日ほど抜けやすくなります。

ここで区別しておきたいのは、抜けたのが「発注という操作」なのか、「発注すべきだと気づくこと」なのかという違いです。
前者なら思い出させる仕掛けが効きますが、後者、つまり在庫が減っている事実に気づいていない場合は、カレンダーを何度見ても解決しません。
あとで通知の種類を選ぶときに、この分かれ目が効いてきます。

担当者不在で発注が止まる属人化

もう一つよくあるのが、特定の人しか発注の中身を把握していない状態です。
同じ解説でも「あの人でないと発注業務が進まない」という属人化が、発注業務の課題として挙げられています³。

小さな事業所ほど、これは自然に起きます。
どの商品をどこから、どれくらいの周期で、どの単位で頼むのか。
取引先の締め時間や最低ロット、在庫を切らしたときの代替品まで含めると、頭の中にしかない情報は想像より多いものです。
その人が休んだ日、代わりに入った人は「何を発注すべきか」を判断できず、結局は戻るまで待つことになります。

この型の発注忘れは、当人が忘れたわけではありません。
知っている人に情報が届かなかった、あるいは判断できる人がその場にいなかったという、受け渡しの問題です。
だから対策を考えるときも、何時に鳴らすかより先に、誰に鳴らすのかが論点になります。

部署間の情報共有の遅れ

営業・製造・倉庫といった部門間の情報共有の遅れが、トラブルにつながるとも整理されています³。
部門という言葉は大きく聞こえますが、店舗規模でも事情は同じです。
ホールとキッチン、売場とバックヤードのように、在庫を使う人と発注する人が分かれていれば、同じ断絶が生まれます。

使い切ったことを知っているのは現場の人、発注の権限を持つのは別の人。
その間の伝達が口頭やメモだと、伝えたつもりと聞いていないが同時に成立します。
しかも困ったことに、この型は欠品が出るまで誰も間違いに気づきません。

三つの場面を並べると、発注忘れと一言でいっても止まっている場所が違うことが見えてきます。
どこで止まっているかによって、効く通知も変わります。

発注アプリの通知はどんな仕組みで発注忘れを防ぐのか

日付基準のリマインド型通知の仕組み

まず、周期が決まっている発注に効くのが日付基準の通知です。
kintoneで発注管理アプリを作った場合を例にすると、指定した日付フィールドの値を基に、基準日から「〇日前」「〇日後」、時刻は相対時刻または絶対時刻で条件を指定し、条件を満たしたレコードについて作成者・更新者・ユーザー選択フィールドなどの宛先へ通知を送れます⁴。
これは汎用プラットフォームの標準機能であり、発注専用に作られたアプリが同じ仕様とは限らない点は押さえておいてください。

言い換えると、通知が飛ぶかどうかは「アプリの中に日付が入っているか」で決まります。
次回発注日という欄を持ったレコードがあって初めて、その二日前の朝に担当者へ届く、という動きになります。
逆にいえば、発注予定をアプリの外のカレンダーや手帳で管理しているなら、通知は鳴りません。

宛先をフィールドから引ける点も、見逃しやすいわりに実務では効きます。
レコードごとに担当者が違う場合でも、その欄に入っている人へ個別に届けられるからです。
前の節で挙げた属人化、つまり一人の頭の中に発注情報がある状態に対しては、宛先を複数にしておくことで「気づける人」を増やす余地が生まれます。
ただし届くのは知らせであって、何をどれだけ頼むかという中身まで自動で引き継がれるわけではありません。

在庫数をトリガーにする在庫連動型アラート

日付ではなく、数そのものをきっかけにする通知もあります。
店舗向けのPOSサービスでは、アラートbotが在庫などの問題点を監視し、問題が発生したときや発生しそうなときに事前に知らせる仕組みが提供されています。
具体的には、あらかじめ商品ごとに設定した在庫数を下回った場合や、在庫が急になくなった場合に、管理画面の通知とメール通知で自動的に知らせます¹。
これは対応プランで利用できる機能として説明されているものです。

この方式が効くのは、前の節でいう「減っていることに気づいていない」型です。
発注日を覚えていても、売れ方が読めない商品は周期から外れます。
週末に想定より出た、まとめ買いが入った、といった変動を人が追いきれないとき、数が閾値を割った瞬間に知らせが来る意味は大きくなります。

前提として必要なのは、在庫の数がシステムの中で正しく動いていることです。
販売や消費が記録されて初めて残数が減り、閾値を割ったと判定されます。
棚から持ち出して記録しない運用や、在庫を別のExcelで管理している状態では、画面上の数が現実から離れ、通知も当てになりません。
在庫連動型を検討するときは、通知の設定より先に、数が合っているかを見るほうが近道です。

承認の滞留を検知する承認催促型通知

三つ目は、発注する本人ではなく、承認する側に向けた通知です。
申請・承認ワークフローのサービスでは、申請・承認・差し戻し・コメントなど複数のタイミングで通知でき、承認リクエストを持つユーザー向けに曜日・時間帯を指定した自動リマインド通知を送信できます。
通知の経路もメールやブラウザのプッシュ通知に加え、Slack・Teams・Chatwork・LINE WORKS・Google Chatといったチャットツールとの連携が用意されています²。

この型が対応するのは、発注担当者が出し忘れたのではなく、申請は済んでいるのに承認待ちで止まっている場面です。
担当者の側から見ると、自分は手を離れたつもりでいるぶん、気づくのが遅れます。
曜日と時間帯を指定して承認者へ繰り返し届く仕掛けは、ここに直接効きます。

経路が選べることの意味も、現場の感覚に照らすと分かりやすくなります。
決裁する人がメールをほとんど開かないなら、メールで何通送っても状況は変わりません。
普段から開いている画面に出るかどうかが、承認が動くかどうかを左右します。
逆に、承認という工程が存在しない発注なら、この型を中心に据えても得るものはありません。

ここまでの三つを、きっかけ・宛先・効く場面で並べると違いがはっきりします。

通知があっても発注忘れが起きるのはどんなときか

自分の操作やCSV取込では通知されない盲点

通知の仕組みが分かると、次に気になるのは「設定したのに鳴らない」場合です。
kintoneのヘルプには、通知が届かない条件がはっきり書かれています。
自分の操作では自分宛に通知は届かず、Excel／CSVファイルの読み込みでレコードを追加・更新した場合は条件を満たしていても通知は届きません。
さらに、リマインダーの設定前からすでに条件を満たしていたレコードには通知されず、レコードを閲覧できない権限のユーザーや非公開スペースの非参加メンバーにも届きません⁵。
これはkintoneの標準通知機能に共通する仕様で、発注アプリに限った話ではありません。

このうち一つ目は、一人で発注を回している人ほど影響を受けます。
自分で発注予定を登録し、自分に思い出させる——いちばん素直な使い方が、そのままでは成立しないからです。
宛先を上長や別の担当にする、共有の受け取り口を用意するなど、設計を一段変える必要があります。

二つ目は、月初に発注予定をまとめて流し込むような運用と重なります。
手で一件ずつ登録したときは鳴るのに、一括取込に切り替えた月だけ静かになる、という食い違いが起きます。
三つ目は導入直後に効いてきます。
設定した時点ですでに期限が迫っている案件は、ちょうど通知してほしい対象なのに、対象から外れます。
四つ目の権限は、代理担当や別店舗の人を宛先に加えたときに問題になります。
宛先に名前を入れたから届く、とは限りません。

リマインドは既定で一度きり、繰り返し設定が必要

届いたのに防げなかった、という抜け方もあります。
リマインダーの条件通知は、条件を満たしたときに一度送信されると、その後は自動では繰り返し送信されません⁶。
鳴ったときに手が離せず「あとで」と思ったまま流れてしまえば、二度目はないということです。

繰り返したい場合の方法も示されています。
通知を受け取るたびにレコードの日付／日時を手動で更新するか、テーブル内に通知日をあらかじめ複数指定しておく必要があります⁶。
どちらも人の手が入る点は変わりませんが、入るタイミングが違います。
前者は毎回、通知を受けた後に日付を書き換える作業が続きます。
後者は最初に通知日を並べて登録しておき、その登録した範囲までは自動で回ります。

毎週・毎月の定期発注を想定しているなら、ここは設定前に決めておきたいところです。
一度設定すれば永続する仕掛けを思い描いていると、数か月後に通知が途切れていたことに気づく、という事態になりかねません。
定期的な発注をアプリに任せるとは、通知を自動化することと、その自動化を維持する担当を決めることの両方を指します。

担当者交代でメールが届かなくなる運用上のもれ

機能も設定も正しいのに、宛先の情報が古くて届かない、という失敗もあります。
受発注サービスのレビューサイトには、総合卸売・商社・貿易業の会計経理担当者（従業員20〜50人未満の利用者）が、退職した担当者のマスタが変更されずに残っており、メールが届かなくなった担当者が発生したと指摘した投稿があります。
投稿者は、代表者へマスタ変更をメール通知する補助機能があるとよいとも述べています⁷。
これは2021年に投稿された一人の利用体験であり、他の利用者や他社製品に一般化できる不具合ではありません。

それでも、この話が引っかかるのは構図に覚えがあるからだと思います。
退職や異動のとき、人事上の手続きは進んでも、どのシステムのどのマスタに名前が残っているかまでは誰も追いません。
発注アプリの通知先、取引先側に登録された担当者名、共有メールの転送設定——心当たりが一つは出てくるのではないでしょうか。

やっかいなのは、届かないことが静かに進む点です。
通知が鳴らないときにエラーが返るわけではないので、画面の上では何も起きていません。
欠品が出て初めて、そういえばあの通知を最近見ていないと気づく。
通知を増やして安心するより、宛先が生きているかを確かめる仕組みのほうが、結果として発注忘れに効く場面があります。

通知機能以外で導入前に確認すべき条件

既存の発注フロー・承認体制との整合

ここまでに分かったことを、導入前の判断に落とし込みます。
以下は各社の仕様と利用者の指摘をもとに編集部で整理した確認の観点であり、実際に合うかどうかは発注フローや既存システムの構成によって変わります。

最初に決めるのは、自分の発注が何をきっかけに動いているかです。
毎週水曜に出すと決まっているなら日付が起点で、売れ行き次第で頼むなら在庫数が起点になります。
この見極めを飛ばすと、周期型の発注に在庫連動型を入れて反応が鈍い、あるいは変動の大きい商品を日付通知だけで追って欠品する、という噛み合わなさが残ります。

承認についても同じです。
上長の決裁を経てから注文する運用なら、止まりやすいのは承認の手前か、承認そのものか。
承認という工程が存在しないのに催促型の通知を中心に据えても、起点になるリクエストがありません。
逆に、申請してから承認されるまでに日数がかかっているなら、発注者をいくら急かしても現象は変わりません。

もう一つ、在庫連動型を考える場合に避けて通れないのが、在庫数がどこにあるかです。
商品ごとの閾値を割ったかどうかを判定するには、その数をシステムが持っている必要があります¹。
在庫を手書きの台帳や個人のExcelで管理しているなら、通知の機能を比べる前に、そこをどうするかという話になります。

マスタ・権限情報を最新に保つ運用体制

次に見るのは、通知が届き続けるための運用です。
通知は宛先の情報に依存します。
閲覧権限のないユーザーには通知が届かない⁵という仕様がある以上、宛先欄に名前を入れただけでは不十分な場合があります。
退職した担当者のマスタが更新されずに残っていた例⁷も、同じ系列の問題です。

そこで決めておきたいのが、担当が変わったときに誰がどこを直すのかという手順です。
入退社や異動のチェックリストに、発注アプリの通知先と権限が項目として載っているか。
載っていなければ、変更は誰かが思い出したときにしか行われません。
これを決めたからといって発注忘れがなくなるわけではありませんが、「通知が来ていたはずなのに誰も受け取っていなかった」という確認作業は減らせます。

あわせて、届いていないことに気づく手がかりも持っておくと安心です。
たとえば定期発注の通知なら、来るはずの曜日に来ていなければおかしいと分かります。
月に一度、宛先の一覧を開いて在籍していない名前がないか見るだけでも、静かに止まっている状態を見つけやすくなります。

担当人数やITリテラシーに合った通知方式の選び方

最後に、通知をどこで受け取るかです。
管理画面の通知とメール通知で知らせる形¹もあれば、メールやブラウザのプッシュに加えてチャットツールと連携できる形²もあります。
選ぶ基準は機能の多さではなく、受け取る人が普段どの画面を開いているかです。
店頭でレジ画面しか見ない人にメールを送っても、気づくのは閉店後になります。

担当人数も効いてきます。
一人で発注している場合、自分の操作では自分宛に通知が届かないという制約⁵が直接ぶつかります。
この場合は、通知の宛先を別の人にして二人で見る、あるいは誰かが登録して担当者が受け取るというように、登録する人と受け取る人を分ける形を考えることになります。
一人体制のまま通知だけで補おうとすると、設定の工夫がどうしても増えます。

そして、繰り返し通知の手当てを誰が担うかです。
既定では一度しか送られず、繰り返すには日付の更新か通知日の複数指定が要ります⁶。
この作業が宙に浮いたまま導入すると、最初の数週間は順調で、そのあと静かに効かなくなります。
導入の可否を判断する段階で、機能が足りるかと同じ重さで、この手入れを続けられるかを見ておきたいところです。

通知のどの型が合うかは、発注の起点が日付なのか在庫数なのか、承認がどこで止まっているのかによって変わり、自社の運用を外から言葉にするのは意外と難しいところです。

現在の発注の進み方と、在庫や発注予定がどこに記録されているかをお聞かせいただければ、どの型の通知が働き、どこが通知では埋まらないかを一緒に切り分けられます。無料相談で要件を整理する

要点の整理

軸	基準
発注の起点	日付が決まっているならリマインド型、売れ行き次第なら在庫連動型、承認待ちで止まるなら承認催促型
データの有無	在庫連動型は在庫数がシステム上で動いていること、リマインド型は日付がアプリ内にあることが前提
通知が届かない条件	自分の操作、Excel／CSV取込、設定前から条件を満たすレコード、閲覧権限のないユーザーには届かない
繰り返しの可否	既定では一度きり。日付の手動更新か、通知日の複数指定が要る
宛先の維持	退職・異動時にマスタと権限を直す手順を決めておく。届かないことはエラーにならない
受け取り口	管理画面・メール・チャットのうち、受け取る人が普段開いている画面に出るものを選ぶ

通知の設定そのものより、宛先の更新や繰り返し設定を続けられるかが導入後の分かれ目になり、ここは機能一覧を比べても判断できません。 担当人数や交代の頻度、既存システムの構成を伺ったうえで、運用として無理のない通知の置き方と、手当てが必要になる作業の範囲をご一緒に確認できます。

よくある質問

通知メールを担当者全員に転送する設定は発注忘れ対策になるか

気づく人を増やす意味はありますが、宛先を広げるだけでは「誰が出すか」が決まらないため、全員が他の誰かを前提にして動かない状態も起こり得ます。
また、kintoneではレコードを閲覧できない権限のユーザーや非公開スペースの非参加メンバーには通知が届かない⁵とされており、宛先に加えるだけでは届かない場合があります。
転送を考える前に、追加した人がその情報を見られる権限を持っているか、そして一次の担当と代理の担当をどう分けるかを決めておくほうが確実です。

在庫連動型の通知を使うには在庫管理システムとの連携が必須か

必要なのは連携そのものというより、判定の材料になる在庫数をそのアプリが持っていることです。
店舗向けPOSサービスのアラート機能は、商品ごとに設定した在庫数を下回った場合や在庫が急になくなった場合に知らせる¹仕組みで、販売や消費が記録されて残数が動くことが前提になります。
在庫を別のシステムや手元のExcelで管理しているなら、その数をどう取り込むかが課題になり、取り込めないうちは通知の設定だけ済ませても判定が働きません。

承認フローがない一人担当の発注業務でも通知機能は効果があるか

承認催促型は、承認リクエストが残っている状態を起点にするため²、承認工程がなければ出番がありません。
中心になるのは日付基準のリマインド型と在庫連動型です。
ただし一人運用で気をつけたいのが、自分の操作では自分宛に通知が届かない⁵という点で、自分で登録して自分に知らせる形はそのままでは成立しません。
登録する人と受け取る人を分けるか、通知の宛先を別の担当に置くといった設計が必要になります。

リマインド通知を毎回の発注日に自動で繰り返す設定はどう作ればよいか

kintoneのリマインダーの条件通知は、条件を満たして一度送信されるとその後は自動で繰り返されません。
繰り返すには、通知を受け取るたびにレコードの日付／日時を手動で更新するか、テーブル内に通知日をあらかじめ複数指定しておく方法が案内されています⁶。
毎回の更新を続けられるかが不安なら、先に通知日を並べて登録しておくほうが途切れにくくなります。
いずれにせよ登録した範囲を使い切れば止まるため、次の分を足す時期を運用に組み込んでおくと安心です。

1. 1　出典：株式会社スマレジ「アラート機能」（2026年参照時点）
2. 2　出典：株式会社kickflow「申請／承認の通知・共有機能」（2026年参照時点）
3. 3　出典：株式会社マネーフォワード「発注業務を効率化するには？課題の洗い出しからシステム導入まで解説」（2026年参照時点）
4. 4　出典：サイボウズ株式会社「［リマインダーの条件通知］日時を条件にしたリマインド通知を設定する」（2026年参照時点）
5. 5　出典：サイボウズ株式会社「『通知』が届かないときは」（2026年参照時点）
6. 6　出典：サイボウズ株式会社「［リマインダーの条件通知］で、通知が繰り返し送信されるように設定したい」（2026年参照時点）
7. 7　出典：ITreview「BtoBプラットフォーム 受発注の評判・口コミ」（2021年投稿）