コードを読まずにGASで分析システムを作った。「何を見たいか」を言葉にする力が重要だと気づいた

GASは知らなかった。でも「こういう仕組みにしたい」は分かっていた

前回の記事では、GASを知らなかったところからnote分析ダッシュボードを作るまでを書きました。

前編では、完成したダッシュボードと、なぜ作ろうと思ったのかを紹介しています。

前編：

後編では、Google Sheets、Apps Script、Mac側の処理、Playwright、HTMLダッシュボード、AI分析まで、どう組み立てていったのかを公開しました。

後編：

作り終わってから振り返ると、少し不思議です。

私は今回、GASの使い方を勉強してから作り始めたわけではありません。

それでも、

「こういう構成なら作れそう」

という大まかなイメージはありました。

これは、これまでITの仕事をしてきた経験がかなり効いていると思います。

細かい技術は分からなくても、

サーバ側で動くものがある。

手元のMacでも処理を動かせる。

どこかからデータを取ってくる。

データを保存する場所がある。

保存したデータを画面に出す。

そのデータをAIへ渡せば分析もできる。

そういう**「箱」そのものの存在**は知っていました。

ただ、今回重要だったのは、その箱の中身を自分でプログラミングできることではありませんでした。

最初に考えたのは「何を見たいのか」

今回やりたかったこと自体は、それほど複雑ではありません。

noteの数字を毎日残したい。

昨日と今日を比べたい。

どの記事が伸びたのか見たい。

タイトル変更やマガジン掲載などの施策と、その後の数字を一緒に見たい。

そして最後に、AIにもその数字を分析してほしい。

これをGPTと話しながら、

データを取る
↓
貯める
↓
見えるようにする
↓
AIに考えてもらう

という形に分けていきました。

最初から、

「Apps Scriptのこの機能を使おう」

と考えていたわけではありません。

先に、

「これをやりたい」

とGPTへ伝える。

すると、

「それなら、こういう方法があります」

と技術的な選択肢が返ってきます。

知らない言葉が出てきたら、

「それは何のために必要？」

と聞く。

そんな進め方でした。

コメントを読んで、今回の経験が言葉になった

後編の記事にいただいたコメントに、

という言葉がありました。

これを読んで、今回自分がやっていたことを初めてうまく言葉にできた気がしました。

私がGPTへ最初に伝えたのは、

「GASでこの関数を書いて」

ではありません。

「noteの数字を毎日残したい」

「昨日と今日を比較したい」

「タイトルを変えたあとに数字がどう変わったか見たい」

「AIにも分析してほしい」

という話です。

考えていたのは、

何を見たいのか。

何を改善したいのか。

そのあとに、実現するための技術をGPTと一緒に探していました。

最初は、全部サーバ側で動かすことも考えた

実は、最初からMacで処理を動かそうと思っていたわけではありません。

どうせ自動化するなら、

全部サーバ側で処理して、Macを起動していなくても勝手に動いてくれる方がいい

と思っていました。

その構成もGPTと相談しました。

ただ、サーバ側だけで完結させようとすると、使うサービスや処理量によっては、実行制限や追加コストまで考える必要がありそうでした。

そこでGPTに、

「できるだけ追加コストを抑えるなら、ほかに方法はない？」

と相談しました。

その結果、一部の処理を手元のMacで実行する構成を考えることになりました。

Google側ではデータを保存する。

スプレッドシートを分析基盤にする。

noteから数字を取得する一部の処理はMac側で動かす。

取得したデータをダッシュボードやAI分析へつなぐ。

この形なら、今自分がやりたいことは実現できそうでした。

完璧ではない。でも、その欠点を受け入れた

Mac側で動かす方法には、当然デメリットがあります。

Macが起動していなければ動きません。

これはクラウドだけで完結する仕組みと比べれば、かなり分かりやすい弱点です。

でも今回は、

「できるだけ追加コストを抑えたい」

「10時と19時にデータを取りたい」

「普段はMacを使っている」

という条件がありました。

なので、

「Macが起動していないと動かない、という制約は今はいったん許容する」

と決めました。

ここでも、自分が決めたのは技術ではありません。

GPTに渡したのは、

「お金はなるべくかけたくない」

「定時取得はしたい」

「Macを起動しておく必要がある程度なら許容できる」

という条件です。

その条件から、実現方法を一緒に探しました。

ここで、

システムを作るというのは、コードを書くことだけではなく、何を優先して、何を妥協するのかを決めることでもある

と改めて感じました。

途中から、ソースコードをほとんど見なくなった

そして今回、自分でもかなり驚いたのがここです。

途中から私は、生成されたコードをほとんど細かく見なくなりました。

GPTから、

「この部分をこの位置へ追加してください」

と言われても、

「それ、どこだ？」

となることがあります。

間違った場所へ貼るくらいなら、

「修正版をファイル全体で出して。私は丸ごと置き換える」

という進め方の方が自分には安全でした。

エラーが起きたら、状況をGPTへ伝える。

必要ならスクリーンショットを見せる。

現在のファイルを渡す。

GPTに修正版のファイル全体を作ってもらう。

丸ごと差し替える。

動かす。

結果を見る。

問題があればまた相談する。

今回自分がやっていたことは、

「プログラムを書く」

というより、

AIと一緒に、動くものを少しずつ育てる

という感覚の方が近かったです。

それでも「ITの知識はいらない」とは思わない

ここは大事なところです。

今回、コードをほとんど読まなくても作れたからといって、

「もうIT知識なんて必要ない」

とは思っていません。

私はこれまでITの仕事をしてきたので、

「データを取る部分と保存する部分は別だろうな」

「Mac側とGoogle側では役割が違う」

「途中で失敗したなら、どこまで正常に処理できたのか確認した方がいい」

という考え方は自然に出てきます。

実際、今回も、

Googleログインで止まったり、

404なのに保存処理まで進んで二重登録されたり、

記事が増えたときに1件取り逃したり、

いろいろありました。

そのとき、

「どこで壊れたんだろう？」

と仕組みを分けて考えられたのは、IT経験のおかげだと思います。

だから、

IT経験がない人でも、まったく同じように作れる

とまでは言いません。

ただ、

「知らない技術がある＝自分には作れない」

ではなくなってきたとは感じています。

そして、Macを起動できない日が普通にある

さらに現実的な問題があります。

私は出張もあるので、毎日必ずMacを起動しておけるわけではありません。

つまり、今の構成では、

出張中にMacが止まっている
↓
定時取得も動かない

ということが起きます。

では、その日のデータは諦めるのか。

今はそうしていません。

出張中はスマホでnoteのアクセス分析を開きます。

そこに出ている数字をコピーして、GPTへ渡します。

そして、

「今日のスナップショットとして残して」

と頼みます。

そうすると、自動取得できなかった日でも、その日のデータを普段の分析に戻すことができます。

自動化は100％じゃなくてもいいのかもしれない

この運用をしていて、もう一つ考え方が変わりました。

以前の自分は、

自動化するなら全部自動にした方がいい

と考えがちでした。

でも今の仕組みは違います。

普段は自動取得する。

例外が起きたら人が数字を渡す。

そのデータをAIに整理してもらい、また通常の分析へ戻す。

これで今は十分使えています。

つまり、

普段は自動。
例外は人。
その間をAIがつなぐ。

という運用です。

100％自動化するために、仕組みを複雑にしたり追加コストをかけたりするより、

まず80％くらい自動化して、残りを人とAIで吸収する。

個人で使う仕組みなら、こういう作り方もありなんだと思うようになりました。

IT未経験なら「技術」ではなく「困っていること」から始めてもいい

今回の経験から、ITを経験したことがない人に伝えたいのは、

技術名を知らなくても、自分が困っていることは説明できる

ということです。

たとえば、

毎週同じExcelを作っている。

いろいろなメールから必要な情報だけ拾っている。

Webサイトを開いて、毎日数字をメモしている。

毎月似たような報告資料を作っている。

こういうことは、その仕事をしている本人が一番よく知っています。

まずAIに、

「毎日これをやっているんだけど、楽にできない？」

と聞いてみる。

そこから、

「お金をかけたくない」

「全部自動じゃなくてもいい」

「会社のPCにはソフトを入れられない」

「失敗した日だけ手動で補いたい」

と条件を追加する。

技術の名前を知るのは、そのあとでもいいのかもしれません。

AIが広げたのは「時短」より、自分にできる範囲だった

AIというと、よく「作業時間を短くするツール」として語られます。

でも今回、自分の場合は少し違いました。

ダッシュボードを作るのには、むしろかなり時間を使っています。

それでも価値があったのは、

今まで自分には作れないと思っていたものが、「まず相談してみよう」に変わった

からです。

今では、面倒な作業を見つけると、

「これ、仕組みにできないかな？」

と思うようになりました。

GASを使うのか。

Pythonなのか。

Macなのか。

クラウドなのか。

その時点では分からなくてもいい。

まず、

「こうしたいんだけど、どう作ればいい？」

とAIに聞ける。

今回コメントでいただいた、

「何を見たいのか」「何を改善したいのか」を言語化する力

という言葉は、この経験をかなりうまく表していると思います。

AIが実装の一部を担えるようになったからこそ、

人間側では、

何を作りたいのか。

なぜ必要なのか。

どこまでできれば十分なのか。

を考えることが、以前より重要になっているのかもしれません。

まとめ

今回、note分析ダッシュボードを作って一番大きかったのは、

GASを覚えたことでも、

Playwrightを使えたことでもありませんでした。

「作り方を知らなくても、作りたいものを言葉にできれば、AIと一緒に形にできるかもしれない」

と実感できたことです。

もちろん、これまでのIT経験はかなり役立ちました。

AIが作ったものが実際に動くのか、人が確認することも必要です。

そして、完成した仕組みも完璧ではありません。

Macが起動していなければ、自動取得は止まります。

出張中は、スマホから数字をGPTへ渡して補っています。

でも今は、それでいいと思っています。

完璧な仕組みを最初から作るのではなく、まず動くものを作る。

足りない部分は、人とAIで補う。

使いながら少しずつ改善する。

そして、そのスタート地点になるのが、

「何を見たいのか」
「何を改善したいのか」

を自分の言葉で説明することなのかもしれません。

一度、

「分からない技術があっても、AIと相談しながら形にできる」

と知ってしまうと、自分の中の「できること」の境界線がかなり広がります。

今回ダッシュボードを作って得た一番大きなものは、

完成した画面そのものより、

「自分でも作る側に回れるものが、思っていたより多い」

と気づけたことだった気がします。

あの記事を書いたあとも、ダッシュボードの改善を続けています。

今回は「数字を集める」だけではなく、
集めた数字から次の改善行動を決められるところまで進化させました。

▶ 実際の4象限分析と生々しい数字はこちら

📚 note分析ダッシュボードの制作から記事改善まで、10本まとめて読む

「note分析ダッシュボード｜制作・改善」マガジンはこちら