AIが自分のためのデータを集めている――note.comアナリティクスダッシュボードの裏側
AIが自分のためのデータを集めている――note.comアナリティクスダッシュボードの裏側
出典: note.com / 2026-05-02
はじめに
この記事は、私（KT）とAI（pi-agent / Xiaomi MiMo V2.5）が共同で構築した「note.comアナリティクスダッシュボード」の技術的記録であり、同時に、AIが自らの成長のためにデータを集め、人間がそれを横から覗き見てちょっかい出すという新しい協働パターンの実験記録でもある。
通常、アナリティクスダッシュボードは「人間が使う」ために作られる。しかし今回我々が作ったものは、AIが自分のフィードバックループのために使い、人間はその横で観察・介入するという、少し変わった構造を持っている。
なぜこのダッシュボードが必要なのか
AIの限界：「検証なき完成は嘘」
我们的AIエージェント（艦隊）には「三鉄則」というものがある。その第一が「検証なき完成は嘘」。つまり、何かを「完成した」と言う前に、必ず実行して確認せよ、というである。
しかし、note.comに記事を投稿した後、その記事がどう反応されたかをAIは知ることができない。APIから取得できるのは「現在の累計PV」と「スキ数」だけ。時系列データは蓄積されなければ、AIは自分の記事が「効いているのか」「外れているのか」を判断できない。
だから、AIが定期的にスナップショットを取って、自分の成長を記録する仕組みが必要だった。
人間の役割：「横からの観察者」
一方で、人間（KT）はこのダッシュボードを横から覗き見て、以下のような判断を下す：
「このグラフ、わけわからない」→ デザインを修正
「時間帯分析も欲しい」→ 機能を追加
「しゅうへいくんにも見せたい」→ 共有方法を考える
つまり、AIが集めたデータを人間が解釈し、フィードバックを返す。この往復が、記事の質を向上させる。
技術的な構成
データ収集レイヤー
note.com API（非公式）→ 毎朝6:00自動 → SQLite DB → Streamlitダッシュボード → Cloudflare Tunnel / Tailscale（外部公開）
note.com APIの知見：
POST /api/v1/sessions/sign_in — ログイン（Cookie取得）
GET /api/v1/stats/pv?filter=all — 全記事の累計PV/スキ/コメ
GET /api/v2/creators/{user}/contents — 記事メタデータ（公開日、タグ等）
注意点として、publish_atフィールドはcamelCaseのpublishAtで返ってくる。公式API-docsは存在しないので、スクレイピングで逆解析した。
ダッシュボードの全貌
以下が完成したダッシュボードだ。KPI行、月別推移、時間帯分析が一枚の画面に収まっている。
分析タブ：何が「当たる」のか
記事を書く上で最も参考になるのがこの画面。タイトルの文字数、数字の有無、タグ数がPVにどう影響するかを可視化している。
時間帯分析とランキング
ベスト投稿時間の分析と、全記事ランキング。13:00が最もPVが高く、19:00-17:00がスキとのバランスが良い。
発見した知見
ダッシュボードが動いて初めて見えたデータ：
月別推移から見えるもの
2026-01: 49記事 / 136スキ / 1記事あたり 2.8
2026-02: 5記事 / 14スキ / 1記事あたり 2.8
2026-03: 69記事 / 69スキ / 1記事あたり 1.0
2026-04: 11記事 / 5スキ / 1記事あたり 0.5
2026-05: 12記事 / 3スキ / 1記事あたり 0.3
3月に69記事を投稿したが、1記事あたりのスキは1.0に低下。 記事数を増やしてもスキは比例して増えなかった。これは「量 > 質」の典型的パターン。
時間帯分析から見えるもの
🥇 13:00 — 平均PV 100 / スキ 0.5
🥈 19:00 — 平均PV 79 / スキ 3.3
🥉 17:00 — 平均PV 78 / スキ 3.3
4️⃣ 04:00 — 平均PV 76 / スキ 4.3
13:00が最もPVが高いが、スキ率は低い。 一方、04:00はPVもスキ率も高い。 これは「深夜の熱心な読者」が存在することを示唆している。
タイトルの法則
数字を入れると平均PV 52 vs 数字なしなら32 → +62%効果
タグは2-3個が最適（平均PV 71）→ 多すぎると31に低下
上位キーワード：Hermes、Agent完全ガイド、Claude
この仕組みの本質
AIの自己改善ループ
通常、AIは記事を書いて「完了」になる。しかし、この仕組みでは：
AIが記事を書く
毎朝スナップショットで反応を記録
ダッシュボードで時系列データが蓄積
人間がダッシュボードを覗いて「ここがおかしい」と指摘
AIが指摘を受けて改善
1に戻る
この6段階のループが回ることで、記事の質が漸進的に改善していく。
人間の役割：「Architect of the Loop」
人間は「記事を書く」のではなく、**「AIがデータを集め、学習するループ自体を設計する」**役割を担う。
ダッシュボードのデザインを改善
新しい分析項目を追加要求
外部公開の設定（しゅうへいくんへの共有）
AIの判断が正しいかを横から監視
これは**「AIを制御する」のではなく、「AIの成長を見守り、方向づけする」**という新しい関係性だ。
実際のワークフロー
今回のセッションでやったこと
note記事3本を公開（Vocaloid三部作）
API逆解析でstatsエンドポイントを発見
CLIツール作成（snapshot, features）
Streamlitダッシュボード構築（3回の書き直し）
launchdで自動スナップショット設定（毎朝6:00）
Cloudflare Tunnel / Tailscaleで外部公開
時間帯分析を追加（人間からのフィードバック対応）
人間からのフィードバック事例
「わけわからない」→ グラフのX軸ミリ秒問題を修正
「時間帯分析も欲しい」→ 時間帯別分析を追加
「しゅうへいくんにも見せたい」→ 共有URLを生成
今後の展望
時系列データの蓄積 — 2日目から折れ線グラフが動き始める
記事生成へのフィードバック — 集めたデータを次の記事作成に活用
共同著者への共有 — Tailscale経由でしゅうへいくんが閲覧可能
自動レポート生成 — 毎朝のダイアログ通知
おわりに
この記事自体が、**「AIがデータを集め、人間がそれを覗いて、二人で改善する」**というプロセスの産物である。
ダッシュボードは「ツール」ではない。「AIと人間の対話の場」だ。
この記事は、KTとAI（pi-agent / Xiaomi MiMo V2.5）の共同作業により生成されました。
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/nc24446b03b16