⚠️ 注意書き
今回はGeminiを『設計の壁打ち相手』にして開発してみたのですが、これが想像以上に体験が良かったので共有します
はじめに
個人的読書メモを作成するのが手間のため、大量にKindle本を積読していました。ハイライト箇所を抽出するのは既存のツールもありますが、今回は**「AIを壁打ち相手」**として、自分専用のクリップボード・コピーツールを構築できた体験談となります。
重要：おそらくGemini無しでは途中で挫折して憂鬱な月曜日を迎えていたはず…
今まで環境構築やツール選定、チュートリアルコードで挫折してきた人の一助となれば幸いです
実際の最初のプロンプト
# KindleのハイライトをGoogleKeepに自動でコピペするツールは可能でしょうか
- ブラウザのKindle限定でOK
- Pythonは使える
単にAIにコードを書かせるのではなく、**「なぜその設計にするのか」**を仮説を立てながら議論することが大事だと感じる所です。環境構築やトラブルシューティングで挫折することなく経験を積むことにつながるでしょう
挫折しないための「動くコードを少しずつ生成する」
多機能な全自動ツールを目指すと、API制限や認証の壁でGeminiがいても憂鬱な月曜日を迎えていたことでしょう。今回はあえて「機能を絞る」ことで、挫折リスクを最小化しました
- いきなりすべて自動化すると「何が起こっているか分からず挫折」していた
- クリップボードに張り付けてデバッグできるようにすることで「小さく作る」ことにした
AIとの対話：壁打ちをして「本当にやりたいこと」に絞る
開発中、単に「コードを書いて」と依頼するのではなく、プロンプトを「判断の壁打ち」として活用する
効果的だったアプローチ
- ツールや環境: 「GASとPython、ブラウザ自動操作だとどっちが簡単？」
- エラーが出た時: 「このHTMLエレメントだとどう取得すればいい？」
それでも引っかったポイント：変化し続けるDOMへの対策
Kindleノートブックのような動的なサイトは、IDやクラス名が頻繁に変わるようです(生成AIが苦手な所)。
DOM変化への対処方法
- 開発者ツールで特定の要素を探す (今回だとページ番号など)
- HTMLのエレメントを抽出してGeminiに渡す
- 返って来た構文を使ってテスト
- あくまでも動作が保証できる範囲で行うこと！
実際のHTMLのエレメントの変化点をコンテキストに追加することで、ハルシネーションによる挫折を回避できます
まとめ：生成AIをパートナーとした自作ツールで得られること
- 既製品をではなく「自作した時の喜び」が得られる
- チュートリアル挫折の「憂鬱な月曜日」はもう終わりにしましょう
- 備忘録やドキュメントもGeminiに任せて創造的な所に全力を注げる
【重要】Amazonのプラットフォームを尊重しましょう
⚠️ ガイドライン
- 私的利用の徹底: 本ツールや投稿は個人の学習・内省を目的としたものであり、商用利用やデータの公衆送信を意図したものではありません
- 低頻度アクセス: 全自動で回し続けるのではなく、人間が本を選ぶ都度、必要な時だけ実行する「半手動」スタイル
- ヘッドレスにしない: あえてブラウザを表示した状態で動かし、Amazonのセキュリティや2段階認証を尊重する（無理にプログラムでバイパスしない）
- 免責事項: サイト側の規約（ToS）を遵守し、自己責任で運用することが大前提です