在庫・価格チェックの自動化：依頼する前に決めておく10項目

記事

IT・テクノロジー

ナオ｜業務マニュアル・仕組み化

2026/07/14 19:54

毎朝、複数のモールやサイトを開いて、在庫の有無と価格の変化を目でチェックする。1回は数分でも、積み重なると大きな時間になります。この記事では、在庫・価格チェックの自動化を依頼する前に決めておきたい10項目を、記入例つきで紹介します。

なぜ「作る前に決める」のか

監視と通知の仕組みは、プログラムを作ること自体よりも、「何を、どう検知して、誰に知らせるか」の定義で出来が決まります。ここがあいまいなまま作り始めると、あとから直すたびに費用と時間がかかります。

もうひとつの理由は、通知の信頼性です。誤検知だらけの通知は数日で誰も見なくなり、見られなくなった監視は、動いていても存在しないのと同じになります。

依頼前に決める10項目

各項目に記入例を添えます。自分の業務に置き換えて書き出してみてください。

1. 何を見るか：対象のページと項目を特定します。記入例は「商品Aの販売ページの在庫表示と価格」。

2. どのくらいの間隔か：5分ごとと1日1回では、仕組みも費用も変わります。記入例は「1時間ごと。夜間は不要」。

3. 何をもって「変化」とするか：1円でも動けば通知か、決めた幅を超えたときだけか。記入例は「価格が前回より100円以上動いたら」。

4. 通知先と方法：誰に届けば行動につながるかで選びます。記入例は「担当2名のチャットグループに通知」。

5. ログインの要否：ログインが必要なページの監視は、仕組みが一段複雑になります。記入例は「不要。公開ページのみ」。

6. エラー時に誰が気づくか：監視そのものが止まったことを知らせる通知を別に用意します。記入例は「3回連続で失敗したら管理者にメール」。

7. PC再起動後にどうなるか：自分のPCで動かす場合の設計項目です。記入例は「PC起動時に自動で再開してほしい」。

8. 規約・APIの確認：対象サイトの利用規約と、公式API（データを取得する正規の窓口）の有無を確認します。記入例は「規約は未確認。相談時に一緒に確認したい」。

9. 履歴の残し方：記入例は「スプレッドシートに日時と値を1行ずつ追記」。あとから傾向を振り返れます。

10. 誤検知への対応：記入例は「まずは運用しながら、条件を月1回見直す」。直す担当も決めておきます。

項目8は特に重要です。取得の間隔が短すぎると相手のサイトに負荷をかけ、規約に反するおそれもあります。公式APIがある場合は、画面取得より安定しやすく、利用条件も明文化されていることが多いため、先に確認します。

記入例：ひとつの監視を文章にしてみる

10項目をつなげると、次のような依頼文になります。「特定商品の販売ページを対象に、在庫表示と価格を1時間ごとに確認する。在庫が『あり』から『なし』に変わったとき、または価格が変わったときだけ、チャットに商品名と変化の内容を通知する。ログインは不要。取得が3回連続で失敗したら、別の通知でエラーを知らせる。履歴はスプレッドシートに残す。」

ここまで言葉になっていれば、見積りはかなり正確に出せます。