自宅PC不要｜VPSでココナラの新着を監視し、LINE承認後だけ返信する仕組み

ココナラの相談や見積もり依頼は、初動が遅れると受注機会を逃しやすくなります。一方で、自宅PCを24時間起動し続けたり、内容を確認せずに自動返信したりする運用は、安定性・セキュリティ・規約面のリスクが大きくなります。

この記事では、VPS上でGoogle Chromeを常時起動し、Chrome拡張機能で新着を検知し、LINE Messaging APIでスマホに通知し、人が承認した返信だけを送信する構成を整理します。

クリックで拡大

先に確認すべき注意点

この構成は、技術的な設計例です。ココナラの画面を自動監視したり、ブラウザ操作で返信送信したりする処理は、利用規約や運用ルールに抵触する可能性があります。

実運用前には、必ず最新の利用規約、禁止事項、API提供状況、サポートへの確認結果を踏まえて判断してください。人がLINEで承認する設計にしても、サービス側が自動アクセスや自動操作を制限している場合は、その制限が優先されます。

そのため、本記事では「規約上問題ない」「必ず取得できる」「完全自動化できる」といった前提には立ちません。安全寄りに設計するなら、送信まで自動化せず、通知・下書き・承認画面までに留める選択肢もあります。

目指す運用

目的は、ココナラの新着に対して、次のような流れを作ることです。

1. Windows VPS上でChromeを常時起動する
2. Chrome拡張機能がココナラの対象画面を定期的に確認する
3. 新着メッセージや見積もり依頼を検知する
4. サーバー側に検知情報を登録する
5. 返信文をテンプレートまたはAIで下書きする
6. LINEに「返信候補」と承認ボタンを送る
7. スマホで承認・修正・保留・却下を選ぶ
8. 承認済みの返信だけを送信対象にする
9. 送信結果をDBに記録する

ポイントは、検知と下書きは自動化しても、送信判断は人が行うことです。問い合わせ対応では、納期、金額、実現可否、返金、外部連絡先など、誤回答するとトラブルになりやすい情報が含まれます。最後に人が確認するだけで、実用性と安全性のバランスがかなり取りやすくなります。

全体構成

VPSは、クラウド上の常時起動PCとして使います。自宅PCと違い、停電、スリープ、外出中のネットワーク切断に左右されにくいのが利点です。

Chrome拡張機能で監視する理由

ココナラに公式APIがない、または目的の操作にAPIが使えない場合、ブラウザに表示された情報を検知する構成が候補になります。Windows VPSでChromeを開き、Chrome拡張機能のcontent scriptが画面内の未読表示やメッセージ一覧を読み取る形です。

Manifest V3では、バックグラウンド処理は常時ループではなく、イベント駆動のservice workerとして動きます。定期実行にはchrome.alarmsを使います。

{
  "manifest_version": 3,
  "name": "Coconala Approval Reply Monitor",
  "version": "1.0.0",
  "permissions": ["alarms", "storage", "tabs", "scripting"],
  "host_permissions": ["https://coconala.com/*"],
  "background": {
    "service_worker": "service-worker.js"
  },
  "content_scripts": [
    {
      "matches": ["https://coconala.com/*"],
      "js": ["content-script.js"]
    }
  ]
}

監視頻度は短くしすぎない方が安全です。たとえば1分おき、3分おき、5分おきなど、実際の利用状況とサービス負荷を見ながら決めます。取得に失敗した場合は、すぐ連打せず、間隔を空けて再試行します。

検知データの考え方

検知した情報は、その場で返信せず、まずサーバーに登録します。最低限、次の情報を持たせます。

{
  "roomKey": "coconala-room-xxxxx",
  "sourceMessageKey": "latest-message-xxxxx",
  "customerName": "依頼者名",
  "receivedText": "相談本文または要約",
  "receivedAt": "2026-08-05T10:00:00+09:00",
  "source": "chrome-extension-vps"
}

roomKeyとsourceMessageKeyの組み合わせを一意にしておくと、同じメッセージを何度も検知しても二重登録を避けられます。

状態管理を明確にする

この仕組みで重要なのは、1件の問い合わせが今どの段階にあるかを明確にすることです。状態を曖昧にすると、二重返信や未返信の見落としにつながります。

状態遷移をDBに残しておくと、後から「なぜ送信されなかったか」「いつ誰が承認したか」を追いやすくなります。

DBテーブル例

Supabaseを使う場合、承認返信の単位をmessage_jobsのようなテーブルで管理します。

create table message_jobs (
  id uuid primary key default gen_random_uuid(),
  room_key text not null,
  source_message_key text not null,
  customer_name text,
  received_text text not null,
  received_at timestamptz,
  draft_text text,
  approved_text text,
  status text not null default 'DETECTED',
  approval_token_hash text,
  approved_at timestamptz,
  sent_at timestamptz,
  expires_at timestamptz,
  error_message text,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now(),
  unique (room_key, source_message_key)
);

承認URLに使うトークンは、そのままDBに保存せず、ハッシュ化して保存します。URLは長く推測しにくいランダム値にし、有効期限を設定します。

LINE通知で送る内容

LINEには、返信文案だけでなく、判断に必要な情報も一緒に送ります。

• 依頼者名
• 受信時刻
• 問い合わせ本文の要約
• 返信候補
• 「この内容で返信」ボタン
• 「修正して返信」ボタン
• 「保留」ボタン
• 「返信しない」ボタン
• 「ココナラで確認」リンク

承認ボタンは、LINEのpostbackまたは承認用Web画面に遷移するURLで実装します。修正して返信する場合は、スマホで文面を編集できる簡易画面を用意すると実務で使いやすくなります。

下書き生成はテンプレート優先

最初からAIにすべて任せるより、固定テンプレートから始める方が安全です。

お問い合わせありがとうございます。
内容を確認のうえ、対応可否と概算を整理して改めてご連絡いたします。
少々お時間をいただけますと幸いです。

問い合わせ種別を判定できる場合は、条件付きテンプレートに分けます。

OpenAI APIを使う場合も、AIには次の制約を与えます。

• 金額を勝手に提示しない
• 納期を断定しない
• 実現可否を断定しない
• 返金やキャンセル可否を断定しない
• 外部連絡先に誘導しない
• 判断が必要な内容は「確認して折り返す」にする
• 150〜300文字程度に抑える
• 丁寧だが過剰に長くしない

送信前チェック

承認済みでも、送信直前に画面の状態が変わっている可能性があります。送信前には、少なくとも次を確認します。

• 送信先のルームが承認時と一致している
• 最新メッセージが承認対象のメッセージから変わっていない
• 最新メッセージの投稿者が相手側である
• 同じsourceMessageKeyに対して送信済み記録がない
• 承認された文面と送信予定文面が一致している
• 承認期限内である
• VPS上のChromeがログイン状態である
• 通常のメッセージ入力欄が表示されている
• 納品、キャンセル、返金など別種の画面ではない
• 送信ボタンが一意に特定できる

どれか1つでも不一致なら送信しません。状態をSTALEまたはFAILEDにし、LINEに「画面状態が変わったため手動確認が必要」と通知します。

夜間・休日モード

夜間や休日は、即時対応したい一方で、誤返信の影響も大きくなります。安全寄りにするなら、夜間は承認必須にします。

さらに安全にするなら、次のように分けます。

「完全自動で全部返信」ではなく、「安全に止まる条件」を先に設計するのが重要です。

セキュリティ設計

この構成では、VPS、LINE、DB、Chromeプロファイルを扱います。便利さよりも、漏えい時の被害を小さくする設計を優先します。

• ココナラのIDやパスワードをコードに保存しない
• SupabaseのService Role KeyをChrome拡張機能に渡さない
• Chrome拡張機能からは専用APIだけを呼ぶ
• LINEの署名検証を必ず行う
• 承認URLは推測困難なランダムトークンにする
• トークンには有効期限を付ける
• VPSのRDP接続元を制限する
• 可能ならVPNやMFAを使う
• ChromeプロファイルはVPS内だけで管理する
• AIに渡す本文は必要最小限にする
• ログに個人情報や本文全文を残しすぎない

とくに、ブラウザ拡張機能に強い権限を与える場合は、拡張機能の配布範囲とコード管理を厳しく分ける必要があります。

API設計例

APIは、画面検知、承認、送信キューを分けます。

Chrome拡張機能が直接DBを書き換える構成は避けます。必ずサーバー側APIを経由し、認証、重複チェック、状態遷移、ログ記録をサーバー側で行います。

Windows VPSでの構築順序

最初から全自動送信まで作ると、問題が起きたときの原因切り分けが難しくなります。段階的に進めるのが現実的です。

1. Windows VPSを用意する
2. Chromeをインストールする
3. ココナラに手動ログインする
4. Chrome拡張機能を読み込む
5. 対象画面の情報をコンソールに出すだけの検知を作る
6. 検知結果をAPIに送る
7. Supabaseに保存する
8. LINE通知だけを実装する
9. 承認画面を実装する
10. 承認済みジョブだけを送信対象にする
11. 送信前チェックを実装する
12. 小さい件数でテストする
13. 監視ログと失敗通知を追加する

最初の実用ラインは「新着検知とLINE通知」だけでも十分価値があります。送信操作の自動化は、規約確認と安全テストが済んでから判断する領域です。

テスト項目

実運用前には、正常系よりも異常系を多めに確認します。

• 新着1件を検知できる
• 同じ新着を二重登録しない
• LINEに承認通知が届く
• 承認済みだけ送信対象になる
• 修正後の文面が送信対象になる
• 保留、却下が正しく記録される
• 承認期限切れは送信されない
• 承認後に相手から追加メッセージが来たら送信しない
• ログアウト状態では送信しない
• 入力欄や送信ボタンが見つからない場合は送信しない
• 送信失敗時にLINEへ通知される
• VPS再起動後に監視が復旧する
• DB障害やAPI障害時に再試行しすぎない

この種の仕組みは、動くことよりも、危ないときに止まることの方が重要です。

Linux VPSとPlaywrightの選択肢

Windows VPSとChrome拡張機能の組み合わせは、実際のブラウザ画面に近い状態で検知しやすいのが利点です。一方で、Linux VPSとPlaywrightでブラウザを自動操作する構成もあります。

Playwrightは、ブラウザ操作をコードで制御できるため、テスト自動化や監視処理に向いています。ただし、対象サービスの画面変更に弱い点や、自動アクセスとして扱われる可能性は同じです。規約確認と安全設計は、どちらの方式でも必要です。

費用感と運用負荷

小規模に始める場合、費用の中心はVPS、LINE、DB、AI APIです。

Chrome拡張機能による画面監視は、画面のDOM構造が変わると壊れる可能性があります。月1回程度の点検、エラー通知、手動復旧手順は最初から用意しておくべきです。

まとめ

VPS常時監視とLINE承認返信の仕組みは、問い合わせ初動を早くするための実用的な構成です。ただし、対象サービスの規約、画面変更、誤返信、認証情報管理といったリスクもあります。

実装するなら、いきなり完全自動返信を目指すのではなく、次の順番が現実的です。

1. 新着検知だけ作る
2. LINE通知だけ作る
3. 返信候補を下書きする
4. 人が承認したものだけ送信対象にする
5. 送信前チェックと失敗通知を追加する
6. 規約確認の範囲内で送信自動化の可否を判断する

自動化の価値は「人の判断を消すこと」ではなく、「人が判断すべきタイミングを逃さないこと」にあります。この前提で設計すると、実務に乗せやすい安全な仕組みにできます。

関連記事

• ココナラ業務で使える依頼者名抽出ブックマークレット
• ココナラ予約文面コピー用ブックマークレット
• ココナラ売上合計ブックマークレット
• スプレッドシートを簡易DBとして使う外部Webアプリ構成
• Webアプリ開発を依頼するときのアカウント所有設計