近隣スーパーの特売チラシを毎朝確認するのは手間ですが、それ以上に横断比較ができないため、どこが一番安いか判断しにくいという問題があります。
この検証では、郵便番号を入力するだけで近隣スーパーのチラシを収集・解析する仕組みを作りました。技術的には動きましたが、公開はしないという判断をしています。
この検証の概要
検証時期 | 2026年6月8日〜（検証中） |
|---|---|
やりたかったこと | 郵便番号を入力するだけで「今日の近隣スーパー特売一覧」が自動生成される仕組みを構築する |
構成 | Browser Use CLI（画像取得）＋ Vision解析（チラシ読み取り）＋ 常駐型エージェント（オーケストレーション） |
成果 | 75ステップ完走、チラシ画像30枚を取得・解析 |
ランニングコスト | 約¥30/月（軽量モデルでオーケストレーション＋Vision） |
判断 | 個人利用に限定。一般公開はしない |
結論：技術的にできることと、公開してよいことは別
この検証で最も重要な判断です。
当初は3ステップの構想がありました。
- 個人用CLI
- ブラウザからアクセス可能に
- 広告付きで一般公開
しかし調査の結果、チラシデータの法的リスクが判明し、ステップ1（個人利用）に限定する判断をしました。
理由は明確です。チラシ画像の著作権と、情報ポータルの利用規約を考慮し、再配信しないという判断です。
「自分で見るために自動化する」ことと、「集めたものを他人に配信する」ことは、法的にまったく違います。この線引きを検証の途中で確認したことに意味があります。
設計の要点：テキスト層と画像層を分ける
技術的に最も効いた設計判断です。
層 | 対象 | 手法 |
|---|---|---|
テキスト層 | 店舗一覧 | DOM から抽出 |
画像層 | チラシの中身 | Vision解析 |
この役割分担が明確で、実装がシンプルになりました。
チラシは画像なので、中身を読むにはVisionが必要です。しかし「どの店舗があるか」はHTMLに書かれています。全部をVisionで解こうとすると、コストも精度も悪化します。
ブラウザ操作を「ツール」として呼ぶ
トークン効率に大きく影響した判断です。
Playwrightでコードを生成させる方式ではなく、ブラウザ自動化CLIをツールとして呼び出す方式を採用しました。
効果は明確です。LLMのトークン消費を5〜10分の1に削減できました。
AIにコードを書かせると、コード自体が出力トークンになります。既にあるコマンドを呼ぶだけなら、その分が不要になります。
実装で詰まった点
問題 | 原因 | 対処 |
|---|---|---|
想定していたURLが404 | サイト構造が想定と違った | 店舗ページ本体の画像CDN URLを直接ダウンロードする方式へ変更 |
シェル展開が効かない | Python subprocess経由ではシェルの展開が行われない | ファイルを読み込んで実行する専用ツールを別途実装 |
Vision APIが空レスポンスを返す | 推論トークンが不足していた | 出力トークン上限を2000 → 8000へ引き上げ |
環境変数が空になる | モジュールレベルで読むと、読み込み処理より先に評価される | 参照タイミングを遅らせる |
3つ目が特徴的です。推論モデルでは、出力トークンの上限に「思考」の分も含まれます。通常の感覚で上限を設定すると、答えを出す前に打ち切られて空になります。
また、推論モデルでは従来の max_tokens ではなく max_completion_tokens を使うという仕様差も記録されています。
高解像度版を取得する
実装上の発見です。
画像CDNのURLに含まれるサイズ指定パラメータを置き換えることで、高解像度版を取得できました。
Vision解析では、画像の解像度が読み取り精度に直結します。表示用のサムネイルではなく、元の解像度で取得できるかどうかが結果を左右します。
また、一部の店舗については公式サイトから直接取得できるURLパターンを発見し、ブラウザ自動化なしで取得できるようになりました。
ポータル経由でなくても取れるものは、直接取ったほうが速くて確実です。
絞り込みの精度をどう出すか
この仕組みで意外と難しいのが、対象店舗の選別です。
検索結果には業種を問わず大量の店舗が含まれます。そこから食品スーパーだけを抽出する必要があります。
対処として多層のスーパー判定を実装しました。
- ホワイトリスト（30以上のチェーン）
- ブラックリスト
- 店名の正規化
結果、業種無差別の327件から食品スーパー26件を正確に絞り込み、誤判定をほぼゼロにできました。
さらに「常時取得店舗」を固定登録する仕組みも併用しています。自動判定に頼りきらず、確実に取りたい対象は明示的に登録しておくという設計です。柔軟性と確実性を両立できます。
通知：優先順位で経路を切り替える
結果の届け先も実装しています。
Discord Webhook → 別の通知サービス → ターミナル出力環境変数が設定されていれば上位の経路を使い、なければ下位にフォールバックする構成です。
実装は標準ライブラリのみで、追加依存なし。文字数制限を超える場合は末尾を自動トリムする処理も入れています。
通知先の制約（文字数上限）に合わせる処理を入れておかないと、長い結果で失敗します。
コスト
月間ランニングコストは約¥30という試算です。オーケストレーションとVisionの両方を軽量な推論モデル1つで担当しています。
Vision と Function Calling を1モデルで担えるため、アーキテクチャがシンプルになりました。モデルを使い分けると、その分だけ構成が複雑になります。
既存資産の再利用
この検証がスムーズに進んだ理由も記録されています。
既存スキルの巡回ループ・待機の作法・出力プレフィックスの処理をそのまま流用できました。
ブラウザ自動化で必要になる処理は、対象が変わっても共通する部分が多くあります。一度作った作法を型として持っておくと、2つ目以降が速くなります。
残っている改善点
- チラシ有無の事前判定（未登録店の早期スキップ）による効率化
- 他店舗の公式サイトからの直接取得への対応
- 複数日にわたるチラシ履歴の蓄積と「いつもより安い」検出機能
3つ目が本質的です。今日の価格だけでは「安いかどうか」は判断できません。履歴があって初めて比較になります。
よくある質問
なぜ一般公開しないのですか？
チラシ画像の著作権と、情報ポータルの利用規約を考慮したためです。自分で見るために自動化することと、収集したものを他人に配信することは法的に別の問題になります。
トークン消費を抑えるコツは？
AIにコードを書かせず、既存のCLIをツールとして呼ぶことです。この検証では消費を5〜10分の1に削減できました。
Vision APIが空を返します
推論モデルでは出力トークンの上限に思考分も含まれます。上限が低いと答えを出す前に打ち切られます。この検証では2000から8000へ引き上げて解消しました。
画像の解析精度を上げるには？
高解像度版を取得することです。画像CDNのサイズ指定パラメータを置き換えることで、表示用サムネイルではなく元解像度の画像を取得できる場合があります。
まとめ
- 技術的にできることと、公開してよいことは別。調査の結果、個人利用に限定する判断をした
- 設計の要点は「テキスト層はDOM抽出、画像層はVision解析」の役割分担
- AIにコードを書かせず既存CLIをツールとして呼ぶことで、トークン消費を5〜10分の1に削減
- 推論モデルでは出力トークン上限に思考分が含まれる。低いと空レスポンスになる
- Vision解析では高解像度版の取得が精度に直結する
- 絞り込みは自動判定＋固定登録の併用で柔軟性と確実性を両立
- 既存スキルの作法を流用すると2つ目以降が速くなる
自動化を進めるときは、技術的な可否と同時に、その使い方が許されるかを確認する必要があります。動いたものを公開しない判断も、検証の成果の1つです。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。