【連載第4回】動かなくなったら「生もの」を直すだけ。AIを従えてツールを自分で維持管理する自走力

こんにちは、e-Shikumi-Laboのシンです。

AIを活用してツールを作り、自分で維持管理していく「仕組み化思考」の最終回（第4回）です。

これまで、Geminiの会話ログを自動保存するプロトタイプ作成から、Obsidian連携のためのMarkdown化、そして安全な全自動化への昇華についてお話ししてきました。

最終回となる今回は、Webデータを扱うツールを運用する上で避けて通れない「画面仕様変更による停止への対処法」と、AI時代に人間が持つべき「自走力」の核心についてお届けします。

1. Webデータ取得の割り切り：「画面にないものは取れない」

開発の途中で、「チャットが送信された正確な日時（タイムスタンプ）も一緒に記録したい」と考えたことがありました。

しかし、Geminiの画面構造をいくら解析しても、各発言の正確なタイムスタンプはHTML上に存在していませんでした。

Webデータ取得の大原則は、「ブラウザの画面上に存在しないデータは取得できない」ということです。

API経由ではなく、画面（DOM）からデータを抽出する以上、無いものを無理に取ろうとすると複雑な推測処理が必要になり、かえってトラブルの原因になります。

この「技術的な限界」を理解し、できないことは潔く諦めてシンプルさを保つ判断も、ツール作りの大切な要素です。

他人のWebサイトからデータを取得するツールを扱う以上、Google側のデザイン変更やアップデートによって、ある日突然ツールが動かなくなる時が必ず来ます。

「昨日まで動いていたのに、急に保存されなくなった」

これはツールの欠陥ではなく、他人のプラットフォームに依存している以上回避できない「宿命」です。

大切なのは、「絶対に壊れない完璧なツール」を探し求めることではありません。壊れることを前提として受け入れ、「壊れた時にどこをどう直せばよいか」を把握し、自分でサクッと復旧できる状態を作っておくことです。

今回作成した「Chat Saver for Gemini」では、画面からデータを読み取る処理（DOM解析）を parser.js という独立したファイルに切り出しています。

このように通信処理（content.js）と解析処理（parser.js）を分けておくことで、Geminiの画面デザインが変わったとしても、修正するのは parser.js の中の指定場所（CSSセレクター等）だけで済むようになります。

もし画面変更で動かなくなったら、人間が行う作業は以下の通りです。

DevTools（検証ツール）で新しい要素を確認する
Chromeで Gemini を開き、F12 キー（または右クリック＞「検証」）を押して、質問エリアや回答エリアの新しいHTML構造を確認・コピーします。
AIに修正を依頼する
コードを直接書き換える必要はありません。コピーした最新のHTML要素と、手元の parser.js をAIに渡して修正を指示します。

プロンプト例：
「GeminiのUI変更により parser.js が動かなくなりました。現在の parser.js のコードと、最新の質問エリア・回答エリアのHTML要素を添付します。これをもとにセレクター部分の修正を行ってください。」

自分でコードを解読しなくても、変化した部分（入力情報）を提示するだけで、AIが数秒で修正コードを吐き出してくれます。

全4回を通じてお伝えしてきたかったのは、単なるツールの作り方ではありません。

JavaScriptの文法や細かい書き方を丸暗記する必要はありません。

本当に人間が理解しておくべきなのは、システム全体の「入力（画面から取る）」「処理（重複を弾く）」「出力（GASへ送る）」という構造の地図と、データ取得先への配慮の視点です。

この構造の地図さえ頭に入っていれば、AIが出してきた危ういコードに気づいて修正を命じ、画面が変わっても的確な指示を出してツールを安全にコントロールし続けることができます。

ツールに使われる側から、AIを従えて仕組みを動かす側へ。

皆様もぜひ、AIとの正しい付き合い方を身につけ、自分に合わせた安全な仕組みを作って維持する「自走力」を手に入れてみてください。