取引先の料金ページや官公庁のお知らせを、毎日開いて変化を探す作業は見落としが起きやすいものです。この記事では、決まったページを定期的に読み、前回との違いを AI に判断させて、変わったときだけ通知する手順を説明します。
結論
- Samurai App には、ページの変更を自動で検知する専用の機能はありません。ワークフローのステップを組んで作ります。 ページを読み、前回の内容を表から読み、AI に比べさせ、変わっていれば通知して表を更新する流れです。
- 前回の内容は表に残します。 ワークフローの実行は前回の値を持ち越さないので、覚える場所を自分で用意します。
- 確認の間隔は最短 1 時間です。秒や分の単位の監視には向きません。
- AI のステップがあるので、変更がない回もクレジットを使います。
できること・できないこと
できること:
- 公開されているページの本文を読み、「料金の変更だけ知らせる」のように観点を決めて比べること
- 変わった点の要約を Slack などの通知先へ送ること
できないこと、向かないこと:
- ログインが必要なページは読めません。 「ページを読む」は Cookie や秘密の値を載せずに読みます。
- 読むのは本文だけです。 画像だけが差し替わった変更は分かりません。
- 読める長さには上限があります。 既定で 20,000 字まで、指定しても 40,000 字までで、それより後は切られます。長いページの後半の変更は見落とします。
- 厳密な差分の検知ではありません。 AI の判断なので、広告や日付のような変わりやすい部分への反応を抑えるよう頼めますが、結果にはぶれがあります。法令対応のように見落としが許されない確認の代わりにはしないでください。
サイトの利用規約で自動の読み取りを禁じているページは、対象にしないでください。
用意するもの
- 監視するページの URL
- 通知先(Slack なら Incoming Webhook の URL を「設定」→「通知」で登録し、「テスト送信」まで)
- Samurai App で定期実行を作る権限(作成者とマネージャー以上)
手順
完成すると、次のようなワークフローになります。
1. 前回の内容を置く表を作る
チャットで次のように頼むと、表ができます。識別子は後で使うので、返事で確認してください。
page_snapshots という名前の表を作って。列は content(テキスト)だけでいい
「データ」の画面の「テーブルを作成」でも作れます。画面で作った表は既定で自分だけが見られるので、定期実行もこの表を作った人が登録してください。
2. ページを読むステップを足す
「ワークフロー」で新しく作り、「ステップを追加」の「Samurai App」の中から「ページを読む」を選びます。url に監視するページを入れます。読めなかったときは失敗せず、read が false になって、content には読めなかった理由が入ります。
3. 読めたかで分ける
「条件分岐」を足し、「ページを読む」の read が真のときに、この後のステップを置きます。もう一方には「読めませんでした」と書いた「通知先へ送る」を置きます。この分岐がないと、読めなかった理由と前回の内容を AI が比べて、変更ありと判断してしまいます。
4. 前回の内容を読む
分岐の中に「データを読む」を足し、sql に次のように入れます。
SELECT content FROM d_page_snapshots ORDER BY _updated_at DESC LIMIT 1
SQL に書く表の名前は、識別子の前に d_ を付けたものです。page_snapshots のまま書くと「そのテーブルは参照できません」で断られます。
最初の実行では行が 0 件です。次の手順で扱います。
5. AI に比べさせる
「AI で生成」を足し、「出力の項目」に changed(はい / いいえ)と notice(文字)を置きます。プロンプトの例です。値は「変数」で差し込みます。
前回と今回のページの本文を比べ、変わったかどうかを判定してください。
対象は料金と提供条件の変更だけです。日付、広告、ナビゲーションの違いは無視してください。
前回が空なら changed をはいにして、notice に「監視を始めました」と書いてください。
変わっていれば、notice に変わった点を前回と今回の値を並べて書いてください。
前回: {{データを読むステップの rowsJson}}
今回: {{ページを読むステップの content}}
rows ではなく rowsJson を差し込みます。rows は状況によっては出力に含まれず、そのときステップが失敗するためです。
6. 変わったときだけ通知して表を更新する
もう 1 つ「条件分岐」を足し、changed がはいのときに次の 3 つを順に置きます。
- 「通知先へ送る」: 「本文」にページの URL と
noticeを入れます。 - 「コード」(「隔離」): 次のように、ページの本文を表に書ける形へ変えます。
contentという名前で「ページを読む」のcontentを渡します。
return { rows_json: JSON.stringify([{ content: inputs.content }]) };
- 「データを書き換える」:
actionはinsert_rows、tableはpage_snapshots、rowsJsonにはコードのステップのrows_jsonを選びます。
コードのステップを挟むのは、ページの本文の引用符や改行をそのまま差し込むと、JSON が壊れて書き込みが失敗するためです。
7. 公開して定期実行を付ける
「バージョン」タブで「バージョン N を公開」を押し、「トリガー」タブの「定期実行を追加」で間隔を選びます。平日の朝 9 時なら「cron(分 時 日 月 曜)」に 0 9 * * 1-5 です。最初の実行で「監視を始めました」が届けば、ここまでの流れが通っています。
チャットで「このページを毎朝読んで、料金が変わったら通知するワークフローを作って」と頼むと、下書きを作れます。作り方が変わることがあるので、表に前回の内容を残す形になっているかを公開前に確認してください。
無人の実行と承認
「ページを読む」に承認はありません。「データを書き換える」は、会話で AI が使うときは承認のカードが出ますが、ステップとして直接呼ぶ形では、公開の時点で承認された扱いになり、実行して承認ログに記録されます。例外は、管理者がその操作を「禁止」か「毎回確認」にしているときで、この場合は断られます。
全体を 1 つの「AI ボット」のステップに任せる作りは避けてください。AI ボットの書き込みには通常の承認が掛かり、カードへの回答を最大 20 分待ちます。拒否か時間切れになると、書き込まれないまま AI が続きます。すると、次の回も同じ変更を通知し続けます。
メモリに覚えさせないのはなぜか
Samurai App の「メモリ」は会話をまたいで AI へ渡す情報で、ページの本文を毎回書き換えて比べる置き場には向きません。ステップで直接呼べる操作の一覧にもメモリの操作はありません。読み返しと確認がしやすい表を使ってください。
動かないとき
- 通知が毎回届く。 表の書き込みが失敗していないか、「実行」タブで最後のステップを見ます。比べる範囲が広いと、日付などの変化で毎回変更と判断されるので、プロンプトで対象を絞ります。
- 読めませんでしたと届く。 ページが画像、対応していない形式、またはログインの後ろにある場合です。
contentに入っている理由を「実行」タブで確認します。 - 「データを書き換える」が断られる。 管理者が「禁止」か「毎回確認」にしています。設定の変更を相談してください。
- 表の行が読めない。 表を作った人と定期実行を登録した人が違うと、読めないことがあります。同じ人にするか、表の共有を設定します。
よくある質問
複数のページを監視できますか
ページごとにワークフローと表を分けるのが、作りとして分かりやすい形です。実行のたびにクレジットを使うので、件数と間隔を決めてから増やしてください。
クレジットをできるだけ使わずに監視できますか
「コード」のステップで前回と今回の本文が完全に同じかを先に見て、違うときだけ AI に渡す作りにできます。ただし、日付のような小さな違いでも AI へ渡ることになります。
変更の履歴は残せますか
この手順は変わるたびに行を足すので、表の行がそのまま履歴になります。表は読み返せるので、いつ何が変わったかを後で確認できます。