note分析ダッシュボードの作り方｜GASを知らなかった私がAIと試した構成・手順【後編】

noteのIMPやPVを記録して、「前回からどれだけ変わった？」を見られるようにしたい。でも、作り始めたころの自分はGoogle Apps Script（GAS）という言葉すら知りませんでした。

そんなところからAIに相談し、Googleスプレッドシート（Google Sheets）、GAS、Playwright、HTMLを組み合わせたnote分析ダッシュボードを少しずつ作ってきました。

今から始めるなら、まずSheetsに数字を残すだけで十分です。 前回との差が見られるようになってから、必要に応じて自動取得や画面作りへ進めばいいと思います。

この記事では、実際に組み立てた構成、AIへの依頼文の再現例、つまずいた箇所と直し方、そして「今から作り直すなら」の7ステップを紹介します。完成コードを丸ごと配布する記事ではなく、どういう順番で考え、作ってきたのかをたどる実践記録です。

note分析ダッシュボードの全体像｜完成画面は前編へ

ダッシュボードの完成画面や「なぜ作ったのか」については、前編で紹介しています。

前編はこちら

前編では、

数字を見る
↓
比較する
↓
施策とつなぐ
↓
次に何をするか考える

というところまでを中心に書きました。

今回は、その裏側です。

どうやってここまで作ったのか。

できるだけ順番通りに振り返ります。

出発点はGoogle Sheets｜noteの数字を履歴に残したかった

今の仕組みだけを見ると、

note
↓
Macで自動取得
↓
Googleスプレッドシートへ保存
↓
Apps Script
↓
HTMLダッシュボード
↓
AI分析

と、それなりのシステムに見えます。

でも、最初からこの構成を考えていたわけではありません。

始まりはもっと単純でした。

「noteの数字を毎回残しておけば、あとから比較できるんじゃない？」

というだけです。

まず思いついたのがGoogleスプレッドシートでした。

専用データベースを作るつもりもありませんでした。

大きなシステムを作る時間もありません。

なので最初は、

「とりあえずSheetsに保存しよう」

から始めました。

GASとは？Google Sheetsで自動処理できることをAIに教わった

Googleスプレッドシートへデータを保存したり、自動処理をしたりできないか。

そんなことをAIに相談している中で出てきたのが、

Google Apps Script

でした。

いわゆるGASです。

正直、このとき初めて知りました。

Google Sheetsでは「拡張機能 → Apps Script」から、そのスプレッドシートと連携するスクリプトを作成できます。Google公式でも、Apps ScriptからSheetsを読み書きしたり、機能を追加したりできることが案内されています。

「あ、スプレッドシートってコードまで動かせるんだ」

というところからです。

GAS未経験からの開発｜AIにコードを頼み、動かして直す

ここは今回かなり大きかったところです。

GASの本を読んで勉強して、

JavaScriptを勉強して、

それから作り始めた。

という流れではありません。

先に、

「こういうものが欲しい」

をAIへ伝えました。

そして必要なコードを作ってもらいました。

貼る。

動かす。

エラーが出る。

エラーをAIへ返す。

修正版をもらう。

また動かす。

だいたいこの繰り返しです。

GAS初心者向け｜AIへの依頼文の再現例

当時のプロンプトを一字一句保存しているわけではないので、ここからは今から同じことを作るならどう頼むかという再現例です。

たとえば最初なら、こんな感じです。

ポイントは、

「コードを書いて」ではなく、「最終的に何をしたいのか」まで伝えること。

でした。

LEVEL 1｜Google SheetsにnoteのIMP・PVを記録する

同じようなダッシュボードを作りたい人に、最初からPlaywrightやHTMLをおすすめするつもりはありません。

まずはSheetsだけで十分です。

たとえば、

取得日時
記事タイトル
記事URL
IMP
PV
スキ
コメント

だけ残します。

最初は手入力でも構いません。

重要なのは、

「今いくつ？」ではなく、「前回からどう変わった？」を見られるようにすること。

です。

1週間でも残せば、

「この記事は昨日からPVが増えている」

「IMPは伸びているのにPV率はあまり変わっていない」

といった変化が見えてきます。

これだけでも、公式ダッシュボードを見るときとは少し違う視点になります。

LEVEL 2｜Playwrightでnoteの数字を自動取得する

当然ですが、記事が増えてくると手入力が面倒になります。

そこで次に考えました。

「noteの画面を自動で開いて、数字を取れない？」

AIに相談して出てきた選択肢のひとつがPlaywrightでした。

Playwrightはブラウザをプログラムから操作できる仕組みで、Chromiumなどのブラウザを起動してページを開いたり操作したりできます。

自分の環境ではMac上に、

Node.js
Playwright
Chromium

を入れました。

そしてnoteのダッシュボードから必要な数字を取得しています。

Mac側の構成｜データ取得・送信・流入元取得を分ける

最終的には、Mac側の処理も少しずつ分けていきました。

たとえば役割としては、

noteから記事別データを取得
↓
取得結果をGoogle側へ送る
↓
流入元を取得
↓
流入元もGoogle側へ送る
↓
一連の処理をまとめて実行

という感じです。

最初は一つの処理にまとめようとしていましたが、途中で失敗したときに「どこで止まったのか」が分かりにくくなりました。

そこで、取得・送信・流入元取得などを役割ごとに分け、最後にまとめて呼び出す形にしています。

実際の開発では、

collect-snapshot.js

send-snapshot.js

collect-referrers.js

send-referrers.js

run-analytics.js

といった形で処理を分けています。

最初からきれいに分けたわけではなく、後から管理しやすいように整理していきました。

失敗①｜自動ブラウザのGoogleログインで止まった

最初から順調だったわけではありません。

自動ブラウザからGoogleへログインしようとしたところ、うまくいきませんでした。

自動操作ブラウザ側からのログインがブロックされる状態になり、

「もうここで終了では？」

となりました。

そこで方針を変更しました。

Googleログインを毎回自動化するのではなく、noteへログインした状態を保持し、そのセッションを再利用する構成へ変更。

ここは、

「最初に考えた方法がダメなら、別の方法をAIと考える」

という今回の作り方を象徴している気がします。

失敗②｜HTTP 404後の再送でデータを二重登録した

もうひとつ印象に残っている失敗があります。

MacからGoogle側へデータを送ったとき、

HTTP 404

が返ってきました。

当然、

「保存に失敗した」

と思います。

そこで再送しました。

ところがGoogleスプレッドシートを確認すると、1回目のデータも保存されていました。

つまり、

エラーに見えたので再送したら、同じデータを二重登録してしまった

わけです。

そこで、

同じ取得日時
＋
同じ記事URL

のデータが存在する場合は、再送されても追加しないようにしました。

いわゆる重複防止です。

このあたりも、

「404なのにSheetsには保存されている。何が考えられる？」

「同じデータを何度送っても二重登録されないようにしたい」

とAIへ状況を伝えながら直しています。

データの整合チェック｜自動取得した数字は正しい？

ここで気づいたことがあります。

自動化は便利です。

でも、

間違った数字も高速で保存できます。

そこで途中から、データ同士の整合性も確認するようにしました。

たとえば、

記事別PVの合計
と
全体PV

が大きくズレていないか。

流入元の数字と記事側の数字はおかしくないか。

単に、

「データを取得できた」

だけではなく、

「取得した数字は本当に正しそうか？」

を見るようになりました。

失敗③｜「もっとみる」で21記事目を取得できなかった

このチェックを入れていたことで、別の問題にも気づきました。

記事数が21本になったときです。

全体の数字と、記事別データの合計が合わなくなりました。

調べてみると原因は、

「もっとみる」

でした。

noteの記事一覧は、最初に表示されている記事だけでは全件ではなく、それ以降の記事は「もっとみる」の先にありました。

ところが、自分の取得処理は最初に表示されている20記事しか見ていなかった。

その結果、21記事目を取り逃していました。

現在は、

「もっとみる」を展開
↓
全記事を取得
↓
記事ごとの数字を集計
↓
全体値と照合

という形になるよう取得処理を見直しています。

AIにコードを書いてもらっても、

サイト側の表示仕様まで勝手に全部理解してくれるわけではありません。

ここは人間側が、

「数字がおかしい」

と気づく必要がありました。

Macのlaunchdで定時実行｜10時と19時のデータを残す

取得処理が安定してきたところで、次に定時実行へ進みました。

現在は基本的に、

10時

と

19時

にデータを残しています。

Macでは launchd がLaunchAgentなどを管理する仕組みとして使われているため、自分の環境ではこれを利用して定時処理を動かしています。

10時に取得。

19時に取得。

同じ形式で履歴を残します。

そうすると、

現在値を見る

ではなく、

「この9時間でどれだけ動いた？」

が見られるようになります。

LEVEL 3｜SheetsとHTMLダッシュボードを分ける

しばらくはGoogle Sheetsの中にダッシュボードを作っていました。

グラフを出したり、

前回との差を出したり、

記事ごとの数字を比較したり。

Sheetsだけでもかなりできます。

ただ、情報が増えてくると、

「毎日見る画面としてはもう少し整理したい」

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

そこで、

データを保存する場所と、見る場所を分ける

ことにしました。

Google Sheetsはデータの正本。

HTMLダッシュボードは閲覧・分析用。

という役割分担です。

Google Sheets側も、必要になったものを増やしていった

現在は分析関係だけでも、

記事別スナップショット
流入元記録
note全体スナップショット
マーケ施策ログ
SNS投稿記録
ダッシュボード設定
ダッシュボード計算

などに分かれています。

これも、最初から設計したわけではありません。

必要になるたびに追加しています。

途中では、表示用のセルと計算用データがぶつかって #REF! になったこともありました。

そこで現在は、

計算する場所

と

見せる場所

を分けています。

HTMLダッシュボードの構成｜当初は4タブで作った

この記事で紹介する構築当時のPC版ダッシュボードは、

サマリー

マーケ分析

記事別

流入・施策

の4つです。

それぞれ、

「今どうなっている？」

「次に何をする？」

「どの記事？」

「なぜ動いた？」

を見る場所として分けました。

その後も改良を続け、現在公開しているマーケ分析AI秘書の記事では、記事ポジションや使い方を含む6画面を紹介しています。4タブの画像は、作っていた当時の段階を示すものです。

前編では、初期の完成画面を実際のスクリーンショットで公開しています。

AI分析を追加｜数字を記事改善の判断材料にする

ダッシュボードを作るうちに、

「数字を見るだけじゃなく、この数字をAIにも見てもらえばいいのでは？」

となりました。

そこで現在は、取得した数字をAIにも渡して分析しています。

ただし、

AIの提案＝正解

とはしていません。

AIに、

「ここが動いている」

「この記事はIMPに対してPV率が低そう」

「この流入が増えている」

といった観点を出してもらう。

それを見て、

何を変えるかは自分で決める。

という使い方です。

ダッシュボードの目的は、

AIにnote運営を丸投げすることではなく、

人間が考えるための材料を増やすこと

だからです。

今から始めるなら｜note分析ダッシュボードを作る7ステップ

今の完成版をいきなり再現する必要はないと思っています。

自分なら、今からゼロから始める場合は次の順にします。

1. Google Sheetsへnoteの数字を手動で残す

2. 前回との差分を計算する

3. 記事ごとに比較する

4. 手入力が面倒になったら自動取得する

5. 流入元や施策ログを追加する

6. 情報が増えたらHTML化する

7. 最後にAI分析を加える

特に重要なのは、

LEVEL 1だけでも十分使える

ということです。

最初から完成形を作る必要はありません。

新しい有料サーバーや専用DBは契約しなかった

今回の構成では、自分がすでに持っているMacやGoogle環境を使っています。

この仕組みのために、

新しく専用サーバーを契約したり、

有料データベースを契約したり、

大きな分析基盤を導入したり、

ということはしていません。

だから、

「何でも完全無料で作れる」

という意味ではありません。

自分の場合は、手持ちの環境を組み合わせることで、新しい固定費を増やさずに作れた

ということです。

これは個人で使う仕組みとしては結構大きかったです。

AIが全部やってくれたわけでもない

今回AIにかなり助けてもらいました。

コード生成。

エラー原因の整理。

修正案。

構成の相談。

HTML。

分析方法。

知らなかった技術の説明。

かなりの部分をAIと一緒に進めています。

でも、人間側に残った仕事もあります。

何を見たいのか。

その数字はおかしくないか。

何を改善したいのか。

AIの提案を採用するのか。

ここは自分で決めています。

今回一番印象に残ったのは、

コードを全部知っていたから作れたのではなく、「作りたいもの」をAIへ伝え続けたことで育っていった

ということです。

コードの公開範囲｜認証情報やセッションは除く

今回の記事では、

全体構成
データの流れ
Sheetsの役割
GAS
Playwright
定時取得
重複防止
整合チェック
HTML化
AI分析
失敗したところ

まで公開しました。

ただし、実際のコードには、

認証情報
セッション情報
APIキー
トークン
WebアプリURL

など、公開すべきでない情報が含まれる可能性があります。

そのため、コード本体を公開する場合は、そこを除去した公開用の形にする必要があります。

秘密情報まで「全部公開」するつもりはありません。

そこだけは安全優先です。

逆に、

「Sheetsの列構成が見たい」

「GASのこの部分を見たい」

「Windowsならどうする？」

「HTMLの作り方をもっと詳しく知りたい」

などがあれば、コメントで教えてください。

質問が多いところは、実際のコードを整理して別の記事にするのも面白そうです。

前後編の内部リンクで読者回遊も観測する

今回の記事は、あえて前編と後編に分けました。

前編では完成したものを見る。

後編では作り方を見る。

そして、

前編 → 後編

後編 → 前編

と内部リンクをつないだら、読まれ方に何か変化が出るのか。

これも自分のダッシュボードで追ってみます。

ただし、note上でリンククリックそのものを直接計測できるとは限らないため、記事ごとのPV推移やnote内流入、公開後の動きなどから、回遊の兆候を見る実験として扱う予定です。

前編はこちらです。

よくある質問｜GAS初心者のnote分析ダッシュボード作り

Q. GASを知らなくても、noteのアクセス解析データを記録できる？

できます。まずはGoogle Sheetsに取得日時、記事タイトル、URL、IMP、PV、スキなどを手動で残すところから始められます。自動化は、履歴を使うようになってから考えても遅くありません。

Q. PlaywrightやMacがないと、この記事のやり方は試せない？

LEVEL 1の手動記録には必要ありません。PlaywrightとMacのlaunchdは、自分が実際に自動化で使った環境です。ほかの環境での自動取得手順を検証した記事ではないので、同じように動くとは断定できません。

Q. 記事に書かれた手順だけで完成版をそのまま再現できる？

この記事で公開しているのは構成、考え方、AIへの依頼文の再現例、失敗と改善の記録です。認証情報を含み得る完成コードや設定一式は公開していないため、そのままコピーして動く手順書にはなっていません。まずはSheetsへの記録から試し、必要な機能を少しずつ足すのがおすすめです。

まとめ

最初は、

「noteの数字をスプレッドシートに残せないかな？」

くらいでした。

GASという存在も知りませんでした。

そこからAIに聞きながら、

Sheets
↓
GAS
↓
Playwright
↓
自動取得
↓
HTMLダッシュボード
↓
AI分析

まで少しずつ育てました。

途中ではGoogleログインで止まり、404で二重登録し、21記事目を取り逃しました。

一発で完成したわけではありません。

でも、

動かす → おかしいところを見つける → AIに聞く → 直す

を繰り返せば、知らなかった仕組みでもかなり形にできる。

今回のダッシュボード作りで一番感じたのはそこでした。

作り方を知らなくても、「何を作りたいか」が分かっていれば、AIと一緒に少しずつ形にできる。

これからも、このダッシュボード自体を改善しながら、実際のnote運営にも使っていきます。

このnoteでは「AI副業で月1万円」を目標に、AIを仕事や副業で実際に使いながら、うまくいったこと・失敗したこと・改善したことを記録しています。

📊 あわせて読みたい｜note分析ダッシュボード実践シリーズ

AIと一緒にnoteの分析環境を作り、数字の見える化から記事改善、次の施策の提言まで進めた記録です。

① ダッシュボードを作った話（前編）

② 作り方と試行錯誤（後編）

③ 分析機能の改善

④ 全画面公開・AIによる施策提言（最新版）

⑤ 分析から記事改訂・評価へ（2026年10月18日公開）

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

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