· シン · chrome-extension · 9 min read
【連載第3回】AIが見落とした「1.5秒の罠」。長年のスクレイピング経験とアカウントBANリスクを回避した話
Gemini会話ログ保存ツールの全自動化に挑戦(第3回)。1.5秒ごとの定期実行によるリスクを回避し、相手のサーバーに負担をかけないスマートなDOM監視処理(MutationObserver)を構築した経緯を詳述。人間がリスクを指摘し、AIに安全な代替案を出させる思考法を伝えます。

こんにちは、e-Shikumi-Laboのシンです。
AIを使って自分でツールを作り、維持管理していく「仕組み化思考」の第3回です。
前回は、スプレッドシートへの追記と同時に、GoogleドライブへMarkdown(.md)ファイルを自動出力する仕組みづくりについてお話ししました。
スプレッドシートでの一覧管理と、Obsidianでの快適な閲覧環境が整い、ツールとしてはかなり完成度に近づいていました。
しかし、実際に使い込んでいくと、運用の面で新たな課題が出てきました。今回は、「手動ボタン」から「全自動化」へ移行する中で直面したリスクと、安全なコードへ進化させたプロセスをお届けします。
1. 「ボタンを押す手間」をゼロにしたい
プロトタイプの段階では、画面上に配置したボタンを押してログを保存する仕組みにしていました。
しかし、人間が手動で運用する以上、どうしても限界があります。
会話に集中していると、保存ボタンを押し忘れて画面を閉じてしまう
会話が長くなると、画面上に表示されていない過去の発言を取りこぼしてしまう
「画面を開いて会話をしているなら、人間の手を煩わせず、裏で全自動で保存してほしい」
そう考えた私は、AIに全自動化のコードを書くよう依頼しました。
2. AIが出してきた「1.5秒ごとに画面を巡回する」コード
AIに相談すると、すぐに全自動化のコードが提示されました。
その仕組みは、「1.5秒ごとにタイマーを起動し、裏で画面全体をチェックして新しい発言があれば送信する」というものでした。
実際に試してみると、ボタンを押さなくても会話したそばから自動でログが蓄積されていき、一見すると非常によくできた全自動化に見えました。
しかし、この「1.5秒周期の監視」に対して、私はどこか引っかかるものを感じました。
3. 「ブラウザ内なら大丈夫?」にひそむBANリスク
最初は「自分のブラウザ上で画面を見張っているだけ(ローカル処理)だから、大丈夫だろう」と思いました。
しかし、過去にWebデータ取得(スクレイピング)に取り組んでいた経験から、「相手のサーバーに不自然な挙動を見せるのは危険だ」という感覚が頭をよぎりました。
そこで念のため、AIに「この1.5秒監視のコード、リスクはない?」と確認してみることにしました。すると、AIから思わぬ返答がありました。
AI:
「実はリスクがあります。
外部送信(GAS)のスピードが早すぎる
1.5秒周期で監視していると、Geminiの回答が終わった瞬間に、人間には不可能な速度(わずか1.5秒以内)で毎回きっちり外部へデータが送信されます。相手のサーバーから見れば『回答直後に正確なインターバルでログを転送している=自動化ツールが動いている』と一発で判定できてしまいます。
同じブラウザ内にも監視プログラムがいる
Geminiのタブ内では、あなた自身のブラウザ上でGoogle側のセキュリティスクリプトもリアルタイムで動いています。超高頻度で画面の監視や操作を行うと、機械的検知のフラグを立てられるリスクがあります。」
「ブラウザの中だから安全」という思い込みの裏に、Googleアカウントの制限(BAN)につながりかねない重大なリスクが隠されていたのです。
指示された機能を作ることに集中するAIは、そこまで配慮が回っていませんでした。AIは「動くコード」は作れても、「アカウントリスクや相手への配慮」までは自発的に計算してくれないということを痛感した瞬間でした。
4. AIに代替案を考えさせて出会った、スマートな仕組み
危険な1.5秒の巡回処理をやめさせるため、私はAIに次のように指示を出しました。
「1.5秒ごとの定期実行(タイマー処理)はやめてください。相手のサーバーに負担をかけず、アカウントリスクのない安全な別の方法を考えてください。」
人間側が「安全な技術」を知っている必要はありません。リスクを指摘して「別のやり方にして」と投げるだけで、技術的な代替案はAIが考えてくれます。
そこでAIが提案してきたのが、ブラウザの標準機能である MutationObserver(画面変更の監視機能) でした。
私自身、画面のHTML構造の変化があった瞬間だけをピンポイントで検知する、そんな便利な仕組みがあることすら知りませんでした。
さらにAIは、Geminiが長文を回答している途中で何度もデータ送信されるのを防ぐため、「画面の動きが止まってから3秒間待機し、生成が完了したタイミングで1回だけ送信する(デバウンス処理)」という工夫もセットでコードに組み込んでくれました。
JavaScript
// content.js 内のイメージ(画面の変化を検知し、静止してから3秒後に送信)
const observer = new MutationObserver((mutations) => {
clearTimeout(debounceTimer);
debounceTimer = setTimeout(() => {
scanAndAutoSave(); // 画面の動きが止まってから送信処理を実行
}, 3000);
});「リスクのあるやり方を指摘し、別の方法をAIに考えさせる」。
このやり取りによって、相手のサーバーへ負担をかけず、安全で無駄のない全自動保存ツールへと進化させることができました。
次回予告
全自動化と安全性の両立に成功し、「Chat Saver for Gemini」は実用ツールとして完成しました。
しかし、他人のWebサイトからデータを取得するツールを扱う以上、避けて通れない宿命があります。
それが、「相手のサイトデザインや仕様変更(アップデート)によって、ある日突然動かなくなる」という問題です。
次回は、ツールが壊れた時の冷静な対処法と、parser.js を使ったメンテナンス手順、そしてAI時代に人間が持つべき「自走力」の核心についてお届けします。お楽しみに!



