古いMacでAI Agentを24時間運用する — pm2、Playwright、Discordの実践

古いMacでAI Agentを24時間運用する — pm2、Playwright、Discordの実践

「クラウドのサーバー代を節約するために、自宅の古いMacを24時間稼働のAIエージェントにするのは正解でしょうか？」結論から言うと、これは非常に泥臭く、しかし信じられないほど実用的なソリューションでした。私のデスクの下では、2018年製の古いMac Mini（メモリ24GB）が、pm2とPlaywrightを駆使して、人間のようにWebを巡回し、Discord経由で報告を上げる「自律型エージェント」として静かに働き続けています。

なぜローカルの古いMacなのか？

Webスクレイピングやブラウザの自動化タスク（Playwright）は、AWS EC2やサーバーレス環境で実行しようとすると、ヘッドレスブラウザのメモリ消費量が激しく、あっという間に高額なコストに跳ね返ります。また、サイト側から「クラウドIPからの怪しいアクセス」としてブロックされるリスクも高まります。そこで、不要になったMac Miniの出番です。自宅の家庭用ISPのIPアドレスを使用でき、かつ24GBのメモリを自由に使えるこの環境は、スクレイピングのエッジノードとして理想的でした。

pm2によるプロセス管理とDiscordコントロール

エージェントのプロセスは、Node.jsのプロセス管理ツールであるpm2で監視しています。サーバーが再起動しても自動で立ち上がるように設定し、安定稼働を目指しました。そして、このエージェントへの指示出しやステータス確認は、全て私が日常的に開いているDiscordのUIを通じて行われます。スラッシュコマンド（/crawl jobfitなど）を打ち込むと、ローカルのMacが即座にブラウザを立ち上げて作業を開始する仕組みです。

恐怖のメモリリーク事件：クラッシュした2週間目

しかし、ブラウザの自動化は甘くありませんでした。運用を開始してちょうど2週間が経過した頃、Discordのエージェントが突然沈黙しました。ローカルMacにリモートログインしてみると、画面は真っ暗で、システム全体が完全にフリーズしていました。

原因は、私の書いたPlaywrightのスクリプトの欠陥でした。ネットワークエラーが発生してタスクが失敗した際、try/finallyブロックで確実にbrowser.close()を呼び出してブラウザプロセスを終了させる処理を書き忘れていたのです。その結果、目に見えないバックグラウンドのChromeプロセスが数十個も蓄積（メモリリーク）し続け、最終的にMacの24GBのメモリを完全に食い尽くし、OSごと道連れにしてクラッシュさせてしまいました。
この大惨事を経験してからは、スクリプトの堅牢性を徹底的に見直し、さらにpm2の設定でmax_memory_restart: '1500M'という安全装置（上限に達したら強制再起動）を設けることで、過去6ヶ月間で意図しないダウンはたったの4回（いずれも自動復旧）に抑えられています。Playwrightの公式ドキュメントにあるリソース管理のベストプラクティスを甘く見てはいけません。

1人開発の強力な「非同期チームメンバー」

今やこのエージェントは、私が寝ている間に政府のポータルサイトを巡回し、新しいデータを取得し、エラーがあればDiscordに通知してくれる、文句を言わない優秀なチームメンバーです。自動化とローカルリソースの活用に関する私のスタンスについては、著者プロフィールや技術ブログ一覧でも語っています。もしあなたが自宅に古いPCを眠らせているなら、エージェント化を試してみてはいかがでしょうか。