ai-goofish-monitor：AI で閒魚の商品を自動監視するオープンソースシステム

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor は、Usagi-org が公開している閒魚向けの商品監視システムです。

目的は明確です。閒魚での検索、絞り込み、商品分析、結果記録、通知を自動化し、大量の中古商品から条件に合うものをより早く見つけることです。プロジェクトは Playwright でページ操作を自動化し、画像入力に対応する AI モデルを接続して商品情報をさらに判断します。

プロジェクト：https://github.com/Usagi-org/ai-goofish-monitor

先に結論

ai-goofish-monitor は、単純なキーワード通知スクリプトというより、「閒魚の購入インテリジェンスダッシュボード」に近いです。

主な特徴は次の通りです。

タスク、アカウント、AI 判定基準、ログ、結果を管理できる Web 管理画面。
複数タスクの並行実行。各タスクでキーワード、価格、絞り込み条件、AI Prompt を設定できる。
Playwright で閒魚ページを取得し、ログイン状態やページ操作が必要な場面に対応しやすい。
キーワード一致だけでなく、AI で商品が条件に合うか判断する。
ntfy.sh、企業微信、Bark、Telegram、Webhook などの通知に対応する。
Cron 定期実行、複数アカウント管理、プロキシローテーション、失敗時リトライ、Docker デプロイに対応する。

特定の商品をよく閒魚で探す人、たとえば中古デジタル機器、カメラ機材、GPU、HDD、ゲーム機、楽器、家電、コレクション品を探す人に向いています。ただし「自動で掘り出し物を買うツール」ではありません。閒魚の検索結果は変化し、ログイン状態は失効することがあり、プラットフォームのリスク制御も自動化の安定性に影響します。人間の判断を置き換えるものではなく、補助的なフィルタリングツールとして使うべきです。

解決する問題

閒魚で中古商品を探すと、よく次の問題があります。

商品数が多すぎて手で見るのが疲れる。
タイトルや説明が不統一で、キーワードの取りこぼしや誤判定が起きやすい。
良い価格の出品は短時間で消える。
同じ商品でも地域、価格、状態、出品者が違う。
安い商品にはアクセサリ、故障品、再生品、誘導的なタイトルが混ざる。
複数キーワードを継続的に監視するのは手作業では続きにくい。

普通のキーワード通知で解決できるのは一部だけです。たとえば「ThinkPad X1」を検索すると、アクセサリ、壊れた画面、空箱、分解部品が混ざることがあります。「ソニー A7C」では、レンズセット、レンタル情報、釣りタイトル、異常価格に出会うこともあります。

ai-goofish-monitor の考え方は、まず自動化で候補商品を集め、それを AI に渡して条件に合うか再判断し、最後に注目すべき結果を通知する、というものです。

主な機能

README に列挙されている機能はかなりそろっています。

Web 可視化管理：タスク管理、アカウント管理、AI 基準編集、実行ログ、結果閲覧。
AI 駆動：自然言語でタスクを作成し、マルチモーダルモデルで商品を分析。
複数タスク並行：タスクごとにキーワード、価格、絞り込み条件、AI Prompt を個別設定。
高度な絞り込み：送料無料、新規出品時間範囲、省 / 市 / 区の地域フィルタ。
即時通知：ntfy.sh、企業微信、Bark、Telegram、Webhook など。
定期実行：Cron による周期タスク。
アカウントとプロキシのローテーション：複数アカウント、タスクへのアカウント紐付け、プロキシプール、失敗時リトライ。
Docker デプロイ：コンテナ化された運用。

これらを組み合わせることで、「監視タスク作成」から「命中通知」までの流れをカバーします。

ワークフロー

典型的な流れは次のようなものです。

サービスをデプロイして Web UI を開く。
閒魚アカウントのログイン状態をインポートする。
監視タスクを作成する。
キーワード、価格範囲、地域、新規出品範囲などを設定する。
判定基準を書く、または AI に生成させる。
タスクをリアルタイムまたは定期実行する。
Playwright がページを開き、商品情報を取得する。
AI がタイトル、説明、画像、Prompt をもとに条件適合を判断する。
命中結果を SQLite に保存する。
設定済みの通知チャネルで結果を送る。
Web UI で結果、ログ、価格履歴を見る。

この流れで AI の価値が最も大きいのは 8 番目です。「状態が良い、価格が妥当、アクセサリだけではない、修理品ではない、できれば同城で手渡し」などの自然言語条件を理解できるため、単純なキーワード規則より柔軟です。

Docker デプロイ

プロジェクトは Docker デプロイを推奨しています。

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

デフォルトの Web UI アドレス：

`1`	`http://127.0.0.1:8000`

公式イメージ：

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

イメージ取得が遅い場合、README にはミラー例もあります。

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

Docker イメージには Chromium が含まれているため、ホスト側に別途ブラウザを入れる必要はありません。デフォルトの永続化ディレクトリは次の通りです。

data/：SQLite の主ストレージ。タスク、結果、価格履歴を保存。
state/：ログイン状態の cookie ファイル。
prompts/：タスク用プロンプト。
logs/：実行ログ。
images/：商品画像とタスク一時画像ディレクトリ。

.env の SERVER_PORT を変更した場合は、docker-compose.yaml のポートマッピングも合わせて変更します。

最小構成

最小構成は主に AI モデルと Web UI ログインに関するものです。

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

最初の 3 つは AI モデル接続に必須です。

OPENAI_API_KEY：モデル API Key。
OPENAI_BASE_URL：OpenAI 互換 API エンドポイント。
OPENAI_MODEL_NAME：画像入力に対応するモデル名。

WEB_USERNAME と WEB_PASSWORD は Web UI ログイン用です。README ではデフォルト認証情報が admin/admin123 とされていますが、本番環境では必ず変更してください。

初回利用

初回利用の流れはおおよそ次の通りです。

http://127.0.0.1:8000 を開く。
Web UI にログインする。
「閒魚アカウント管理」に入る。
プロジェクト付属の Chrome 拡張で閒魚ログイン状態 JSON をエクスポートする。
ログイン状態をシステムに貼り付ける。
ログイン状態ファイルは state/ に保存される。例：state/acc_1.json。
「タスク管理」に戻り、タスクを作成してアカウントを紐付ける。
タスクを実行し、結果を見る。

ここで最も重要なのはログイン状態です。閒魚は第三者が自由に取得できる標準 API を公開しているわけではないため、プロジェクトはブラウザのログイン状態を使って通常のページアクセスを模擬します。ログイン状態の失効、リスク制御、captcha、アカウント異常はいずれもタスク実行に影響します。

AI タスクとキーワードタスク

プロジェクトは 2 種類のタスク作成方式をサポートします。

1 つ目は AI判断 です。

「詳細な要件」を入力すると、システムが非同期に分析基準を生成します。複雑な条件に向いています。

本体のみ、アクセサリは不要。
市場価格より明らかに安い場合だけ通知。
状態が良く、説明に水没、修理、隠れた不具合がない。
同城優先、手渡しできるとなお良い。
画像にシリアル番号、箱、重要付属品が写っている。

2 つ目は 关键词判断 です。

これは従来のルール型監視に近く、キーワード、価格、地域などの条件で直接タスクを作成します。AI 生成を使いません。ルールが単純で、多少の誤検知を許容できる場面に向いています。

実際には併用できます。キーワードで初期フィルタし、AI で誤検知を減らす形です。

Web UI でできること

Web UI は、このプロジェクトが普通のスクリプトと違う重要な部分です。

タスク管理ページでは次を設定できます。

AI 作成タスク。
キーワード規則。
価格範囲。
新規出品範囲。
地域フィルタ。
アカウント紐付け。
定期実行ルール。

アカウント管理ページでは次ができます。

閒魚アカウントログイン状態のインポート。
ログイン状態の更新。
アカウント削除。
タスクへのアカウント指定。
システムによる自動アカウント選択。

結果とログページでは次ができます。

命中商品の確認。
結果のエクスポート。
履歴検索。
タスク実行過程の確認。
ログイン失効、リスク制御、AI 呼び出し問題の調査。

システム設定ページでは次ができます。

システム状態の確認。
Prompt の編集。
プロキシとローテーション設定の調整。

長期監視では Web UI が重要です。タスクが増えると、設定、ログ、結果、通知はすぐ管理しにくくなります。

データ保存

現在のオンライン主ストレージは SQLite で、デフォルトパスは次です。

`1`	`data/app.sqlite3`

Docker はデフォルトで SQLite の主 DB を次のようにマウントします。

`1`	`./data:/app/data`

アプリ起動時に DB とテーブルを自動作成し、古い config.json、jsonl/、price_history/ から一度だけ履歴データをインポートしようとします。

注意点として、state/、prompts/、logs/、images/ は引き続きファイルシステム上のディレクトリであり、SQLite 内には入りません。商品画像は次のようなディレクトリに一時保存されます。

`1`	`images/task_images_<task_name>/`

タスク終了後、デフォルトではクリーンアップされます。

この構成は個人または小規模チームに向いています。SQLite は軽量で移行しやすく、ファイルディレクトリにログイン状態、画像、ログが残るため調査もしやすいです。

通知チャネル

プロジェクトは複数の通知チャネルに対応します。よく使う設定は次の通りです。

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

通知はこの種のツールの体験の中心です。監視システムが結果をバックエンドに書くだけなら、ユーザーは結局ページを何度も開く必要があります。プッシュ通知があれば、命中商品をすぐ受け取れます。

実用的には商品価値で通知を分けるとよいです。

普通のキーワード命中はバックエンドにだけ記録。
AI 高信頼度の結果はスマホへ通知。
高価値商品は企業微信または Telegram へ通知。
デバッグ中はログを増やし、安定後にノイズを減らす。

開発者向け実行

Docker を使わないローカル開発には次が必要です。

Python 3.10+
Node.js + npm
Playwright CLI
Chromium または Chrome / Edge ブラウザ

基本コマンド：

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

ワンコマンド起動：

1
2

chmod +x start.sh
./start.sh

start.sh は Playwright CLI とブラウザ条件を確認し、依存関係のインストール、フロントエンドビルド、成果物コピー、バックエンド起動を行います。

バックエンドを手動起動：

`1`	`python -m src.app`

または：

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

フロントエンド開発：

1
2
3

cd web-ui
npm install
npm run dev

テストとビルド：

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

向いている人

ai-goofish-monitor は次のようなユーザーに向いています。

閒魚で特定モデルをよく探す人。
中古デジタル機器、カメラ機材、ゲーム機、ハードウェア部品を監視したい人。
「キーワード検索 + 手動選別」を自動化したい人。
OpenAI 互換モデル API を持ち、AI 判定コストを受け入れられる人。
Docker または基本的なコマンドラインデプロイに慣れている人。
命中結果をスマホ、企業微信、Telegram に通知したい人。

あまり向いていないケース：

デプロイを全く知らず、すぐ使える App だけが欲しい。
ログイン状態、captcha、アカウントリスク制御を扱いたくない。
公式認可された強いコンプライアンスのデータ API が必要。
大規模かつ高頻度にプラットフォームデータを収集したい。
AI に取引リスクを自動判断させ、注文まで代行してほしい。

リスクと境界

この種のツールでは境界を意識する必要があります。

第一に、プラットフォーム規則を守ることです。

閒魚には独自の利用規約、リスク制御、アカウント安全機構があります。自動化アクセスは制限を引き起こす可能性があります。高頻度に取得したり、リスク制御を回避したり、出品者への迷惑行為、プライバシーの一括収集、プラットフォーム秩序の破壊に使ってはいけません。

第二に、アカウントのログイン状態を保護することです。

state/ に保存されるのはログイン状態 cookie ファイルです。これは実質的にアカウントアクセス資格情報です。Git リポジトリにコミットせず、信頼できないサーバーにも置かないでください。サーバーをインターネットに公開する場合、Web UI のデフォルトパスワードは必ず変更し、VPN、リバースプロキシ認証、または内部ネットワークの背後に置くべきです。

第三に、AI 判定は事実保証ではありません。

AI は誤検知を減らせますが、商品の真偽、出品者の信頼性、価格の妥当性、取引安全性を保証しません。最終的には商品詳細、出品者評価、チャット履歴、配送方法、支払いプロセスを人間が確認する必要があります。

第四に、コストに注意してください。

すべての候補商品をマルチモーダルモデルで分析すると、呼び出しコストはすぐ増えます。まずキーワード、価格、地域で強く絞り込み、少数の候補だけを AI に渡すのがよいです。

第五に、プライバシーに注意してください。

商品スクリーンショット、チャット関連内容、アカウント状態、通知内容には機密情報が含まれる可能性があります。通知 Webhook、ログディレクトリ、データベースは適切に保護してください。

普通のスクリプトとの違い

普通の閒魚監視スクリプトは、通常 3 つのことだけをします。

キーワードを検索する。
価格を判定する。
通知を送る。

ai-goofish-monitor はさらに進んでいます。

Web UI でタスクとアカウントを管理する。
AI Prompt で複雑な購入基準を表現する。
マルチモーダルモデルで商品画像と説明を見る。
SQLite に結果と価格履歴を保存する。
ログページでタスク失敗原因を調査する。
プロキシローテーションと複数アカウントで安定性を高める。
定期タスクで長期運用を支える。

機能が多いぶん、デプロイと運用コストも高くなります。一般ユーザーには Docker デプロイが最も簡単です。開発者にとっては、Web UI、FastAPI、Playwright、SQLite の構成が二次開発しやすい形です。

使い方の例

実用的には、小さなタスクから始めるのがよいです。

たとえば中古カメラを探すなら、次のようなタスクを作れます。

キーワード：A7C、索尼 A7C
価格範囲：市場価格に基づいて上限を設定
地域：同じ省または同じ市を優先
新規出品範囲：直近 1 日または数時間
AI 基準：レンズ単体を除外、修理品を除外、明らかなアクセサリを除外、シャッター数と状態に注目
通知：AI 判定を通過した結果だけ通知

安定して動くようになってから、タスク数を少しずつ増やします。最初から数十キーワード、複数アカウント、高頻度 Cron にしないでください。ログイン状態の安定性、誤検知率、AI コスト、通知ノイズを見てから調整するのが安全です。

まとめ

ai-goofish-monitor は、閒魚監視を「キーワードスクリプト」から「管理可能な AI 監視システム」へ進めるプロジェクトです。Playwright でページ操作を自動化し、AI で複雑な判断を行い、Web UI でタスクと結果を管理し、SQLite にデータを保存し、複数通知チャネルで結果を届けます。

特定商品を監視したい個人や小規模チームに向いています。特に中古デジタル機器、ハードウェア、カメラ機材のように、価格変動が大きく、出品タイミングが重要で、説明ノイズが多いカテゴリに適しています。

ただし慎重に使う必要があります。ログイン状態を保護し、デフォルトパスワードを変更し、取得頻度を抑え、AI 結果を人間が確認し、プラットフォーム規則とプライバシー境界を守ることが重要です。補助的なフィルタリングツールとしては価値がありますが、完全自動取引システムとして見ると能力を過大評価しやすいです。

参考リンク：

閒魚 on KnightLiブログ