· シン · chrome-extension  · 8 min read

【連載第2回】スプレッドシートだけでは読みにくい。GASで「Markdownファイル」も同時に自動生成する仕組み

スプレッドシート保存の「長文やコードが読みにくい」課題を解決!GASを拡張し、GoogleドライブへMarkdown(.md)ファイルを自動生成する仕組みを構築しました。改行バグをAIと修正したプロセスや、画面変更に強い「壊れにくい設計」の工夫を解説します。

スプレッドシート保存の「長文やコードが読みにくい」課題を解決!GASを拡張し、GoogleドライブへMarkdown(.md)ファイルを自動生成する仕組みを構築しました。改行バグをAIと修正したプロセスや、画面変更に強い「壊れにくい設計」の工夫を解説します。

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

AIを使って自分でツールを作り、維持管理していく「仕組み化思考」の第2回です。

前回は、Geminiでの会話ログを自動でスプレッドシートに保存するChrome拡張機能の作成についてお話ししました。

無事にスプレッドシートへデータが溜まるようになり、ひとまず満足していたのですが、実際の業務で使い込んでいくと新たな欲が出てきました。

今回は、スプレッドシート保存から「Markdown(.md)ファイルの自動生成」へと仕組みを拡張したプロセスをお届けします。

1. きっかけは「Obsidian」との出会い

スプレッドシートへの保存自体は便利だったのですが、ログが増えてくると1つの課題にぶつかりました。

長文の回答やプログラミングのコードが1つのセルに詰まると、どうしても読みにくく、再利用しづらいという点です。

そんな折、私はナレッジ管理アプリの「Obsidian(オブシディアン)」を使い始めました。

ObsidianはMarkdown形式のテキストファイルをローカルで快適に閲覧・整理できるツールです。「Geminiとの有益な会話も、ここにMarkdownファイルとして蓄積できたら便利だな」と考え始めたのが、すべてのきっかけでした。

2. 「GASでテキストが作れるなら、.mdもいけるはず」

そこで思い浮かんだのが、Google Apps Script(GAS)の仕様です。

「GASを使えばGoogleドライブにテキストファイルを作成・保存できる。それなら、拡張子を .md にしたMarkdownファイルだって出力できるはずだ」

そう着想を得て、さっそくAIに相談してみることにしました。

Chrome拡張機能(送信側)からデータを2回送信するような無駄な処理は避けたいので、受信側であるGASのコードを拡張してもらう形です。

「現在スプレッドシートに保存しているGASのコードを修正したい。データを受け取った際、スプレッドシートへの追記と同時に、Googleドライブの指定フォルダへMarkdown(.md)ファイルを出力する処理を追加してください。」

GASはGoogleのサービス同士を連携させるのが得意です。1回のデータ受信をトリガーにして、「スプレッドシートへの書き込み」と「Googleドライブへの.mdファイル生成」を同時にこなすコードがあっという間に出来上がりました。

3. 「改行が消えた?」AIとの不具合修正

しかし、実際の出力テストを行ってみるとトラブルが発生しました。

Geminiの回答に含まれる見出しや太字はMarkdown記法(#**)に変換されているものの、なぜか文章中の改行がすべて消え、横一列に繋がった文章になってしまったのです。

私はコードを見ても原因が分からないため、画面で起きている現象をそのままAIに伝えました。

Plaintext

【人間】
文字はMarkdownっぽくなっていますが、改行がすべて消えて横一列の文章になってしまいます。改行が保持されるように直してください。

するとAIから、このような返答がありました。

AI:

「失礼しました。画面上の要素を裏で複製(cloneNode)してテキスト情報を取得する際、ブラウザの処理の都合で改行ルールが無視されていました。HTML構造から正しく改行コードを補完するロジックに修正します。」

専門的な仕様の話はAIに任せれば十分です。コードを解読できなくても、「画面で起きているおかしな現状」をそのまま伝えるだけで、AIは原因を特定して修正してくれました。

4. 画面アップデートに強い「タイトル取得」の工夫

もう1つ、実用化にあたって工夫したのが「ファイル名(チャットのタイトル)の取得方法」です。

Geminiの画面上にある「タイトル文字」が入っているHTML要素を解析して取得しようとすると、Googleが画面のデザインを少し変更しただけで、すぐツールが壊れてしまいます。

そこで、シンプルかつ壊れにくいアプローチを採用しました。

「ブラウザのタブ名(document.title)を取得し、そこから不要な文字(- Google Gemini など)を削ってファイル名にする」という方法です。

JavaScript

// parser.js 内のイメージ(タブ名から不要な文字を除去)
let chatTitle = document.title
  .replace(' - Google Gemini', '')
  .replace(' - Google', '')
  .replace(' - Gemini', '')
  .trim();

Webページの内部構造(HTML)は頻繁に変わりますが、ブラウザのタブに表示されるタイトル形式は変更されにくい傾向があります。他人のサイトからデータを取得する際は、このように「壊れにくい場所からデータを取る」という設計の工夫が大切になります。

次回予告

スプレッドシートでの一覧管理に加え、GoogleドライブへのMarkdownファイル自動出力も実現し、Obsidianで快適に閲覧できるようになりました。

「これで完璧なツールができた」と満足していたのですが、人間とは欲が出るものです。

「毎回手動で意識しなくても、画面を開いている間、全自動で保存してくれないかな?」

そう考えてAIに全自動化を頼んだ結果、アカウントの安全性を脅かすとんでもない罠に足を踏み入れることになります……。

次回は、AIが出してきたコードの危険性と、長年のWebデータ取得経験から学んだ「相手のサーバーに負担をかけないマナー」についてお届けします。

Back to Blog

Related Posts

View All Posts »
【連載第3回】AIが見落とした「1.5秒の罠」。長年のスクレイピング経験とアカウントBANリスクを回避した話

【連載第3回】AIが見落とした「1.5秒の罠」。長年のスクレイピング経験とアカウントBANリスクを回避した話

Gemini会話ログ保存ツールの全自動化に挑戦(第3回)。1.5秒ごとの定期実行によるリスクを回避し、相手のサーバーに負担をかけないスマートなDOM監視処理(MutationObserver)を構築した経緯を詳述。人間がリスクを指摘し、AIに安全な代替案を出させる思考法を伝えます。