作って使う

2026.09.05 実物 4分で読めます 2026.09.05 更新

ポイ活マネージャー — 買う日を決める前の、見回りを減らしました

レシートとポイント情報が、日付を選ぶカレンダーに集まるイラスト。買う日の判断は自分でする。
この記事の目次
  1. 01 楽天のイベント・購入履歴・ポイントをまとめる
  2. 02 画面の代わりに、データの流れを出します
  3. 03 完全な入力ゼロではありません
  4. 04 何で作ったか
  5. 05 止まるところも見えるようにする
  6. 06 9月5日追記:画面を閉じたあとの動きも見直しました
  7. 07 同じような道具を考えるなら

買う日を決める前に、イベントの予定、キャンペーン、購入履歴を見に行く。その見回りを減らしたくて作ったのが、ポイ活マネージャーです。

6月に作った最初の5本のうち、日常で使い続けているのはこれです。ほかは3本を廃止し、メールアプリは使わずに残しています。

楽天のイベント・購入履歴・ポイントをまとめる

楽天のイベント情報と、自分の購入履歴・ポイント実績を集めて、購入日の候補を出します。僕はそれを見て、必要な買い物をいつするか考えます。

ポイントの条件や上限は企画ごとに変わります。アプリの表示は判断材料で、購入時には対象商品やエントリー条件を公式ページで確認します。その確認を助けるために、何を作ったかを紹介します。

画面の代わりに、データの流れを出します

このアプリの画面には資産額や保有残高が出るため、スクリーンショットは公開していません。代わりに、どんな流れで動くかを図にしました。

集める

イベント情報は30分ごと、購入履歴やポイントは12時間ごとに取りに行く。

まとめる

集めた情報をパソコンに保存し、買う日の候補と実績を画面に出す。

確認して決める

条件を確認し、必要な補正をする。買うかどうかは自分で決める。

自動にしたのは主に収集です。初期設定、再ログイン、状態の更新は残っています。

前日にメールで知らせる機能も付けました。集めた情報を見に行くきっかけまで用意したかったからです。

完全な入力ゼロではありません

ギフト券の状態は手動で更新します。イベントの上限が通常と違う場合には、補正も必要です。ログインが切れたら、もう一度ログインし直します。

それでも、イベントや履歴を毎回転記するよりは使いやすい。買うかどうかは自分で決めるけれど、その前の情報集めは任せられる。 そこが、僕には合っていました。

廃止した3本にも、自動取得を備えたものはあります。だから、入力しないことだけを理由に「これが残った」とは言えません。買い物をするたびに、集めた数字を見る用事があったことも大きいです。

何で作ったか

部品使ったものこの構成にした理由
裏側の処理Pythonの標準ライブラリPythonに最初から付いている部品を使う
画面HTMLとJavaScript表示前にファイルを変換する作業を増やさない
ログインが必要なページの取得Playwright保存したブラウザのログイン状態を使う
保存先JSONファイル集めたデータを、アプリのコードとは別に保存する

Playwrightは、プログラムからブラウザを動かすための道具です。JSONは、項目名と値を並べて保存するファイルです。

特別な構成にしたかったわけではありません。自分用の小さなアプリなので、必要な部品に絞り、動かなくなったときに調べる場所を増やさないようにしました。

止まるところも見えるようにする

困るのは、楽天へのログインが切れることです。切れると、履歴の取り込みも止まります。この記事を書くときも「再ログインしてください」と出ていました。

画面が開くことと、数字が最新であることは別です。取り込みに失敗したことを表示しなければ、古い数字をそのまま見てしまいます。

AIの更新情報を読むために作ったAI Radarでも、毎朝のまとめと一緒に処理の結果を見られるようにしています。「更新があった日」「生成に失敗した日」「記録がない日」を読む画面の上に並べ、情報がない理由を見分けます。

「自動で取れる」までで完成にせず、取れなかったときに何が見えるかまで確かめる必要がありました。

9月5日追記:画面を閉じたあとの動きも見直しました

作ったあとに設計を点検すると、イベント情報の収集には画面を開いている必要がありました。パソコンで裏側の処理が動いていても、画面を閉じると新しい予定が取り込まれない。その分担を直しました。

収集、買う日の候補の計算、通知の準備を、パソコンで動く同じ処理へまとめました。画面は結果を読むことと、必要な入力をすることを担当します。パソコン自体が止まっている間は動きません。

保存も見直しました。PCとスマホで開いたとき、古い画面の内容が新しい変更を消さないようにし、保存に失敗した入力は画面に残すようにしました。取得についても、最後に試した時刻と、最後に取れた時刻を分けました。

これは修正時の動作確認までの記録です。長く使った結果は、また別に確かめます。画面が開くことに加えて、閉じている間と、失敗したときの動きも確認する。 自分用の道具でも、その点検が必要でした。

同じような道具を考えるなら

最初からデータを全部つなぐより、まず「何を決める画面か」を1つに絞ると、必要な情報が見えてきます。

僕の場合は「買う日を決める」でした。そこに関係する予定と実績を集め、手で直すところは残す。入力欄をゼロにすることより、毎回の見回りを減らすほうが役立ちました。

いつ作ったか、いま使っているかは、この道具のページに載せています。

訂正(2026年9月5日):「自分は入力しない」「捨てた3本は全部手入力」という誤りを直しました。確認できなかった過去の故障談と、道具の一覧が毎日更新されるという説明も削除しました。