note記事を「公開して終わり」にしない。ダッシュボードとChatGPTで改善サイクルを作った

noteの記事って、公開したあと、どうしていますか？

自分はこれまで、AIと一緒にnote分析ダッシュボードを作り、記事ごとのIMP（表示回数）やPV（閲覧数）を記録してきました。

最初は数字を自動で残したかっただけ。

そこから記事比較、4象限分析、AIによる施策提案と、少しずつ機能を増やしてきました。

ただ、一つ気になっていたことがあります。

「改善すべき記事が見つかったとして、その先はどうする？」

数字を見て終わりにするのではなく、実際に記事を改善して、その結果をまた数字で確認したい。

そこで今回、note分析ダッシュボードとChatGPT、GitHubをつなぎ、公開済みの記事を継続的に改善する仕組みを作りました。

2026年10月18日、本番ダッシュボードから記事情報をChatGPTへ引き継ぐところまで動作を確認しています。

今回は、その仕組みの全体像と、これから実際に検証していきたいことを紹介します。

目指しているのは、記事を育てる改善サイクル

まず、今回作りたかった仕組みの全体像から紹介します。

流れはこうです。

ダッシュボードで観測する
↓
改善すべき記事を見つける
↓
ChatGPTで改訂案を考える
↓
GitHubで差分を確認し、noteへ反映する
↓
またダッシュボードで評価する
↓
次の改善へ

例えば、IMPが多いのにPVが少ない記事が見つかったとします。

「もっと表示されるようにしよう」ではなく、「なぜ記事を開いてもらえていないのか？」を考える。

タイトルが分かりにくいのかもしれないし、アイキャッチと内容が合っていないのかもしれません。

ただし、数字だけで原因を決めつけることはできません。

そこで実際の記事本文や過去の変更履歴を確認して、必要な改善を考えます。

そして変更したあと、またダッシュボードへ戻ってくる。

この繰り返しで、記事を少しずつ育てられないか。

自分が作りたかったのは、単なる分析ツールではなく、この循環でした。

ダッシュボードで「何を改善するか」は見えてきた

そもそもの出発点は、noteの数字を記録するためのダッシュボードでした。

以前の記事では、こんなことを書いています。

「数字は分かった。でも、次に何をすればいいんだろう？」

▶ 実際に使っているnote分析ダッシュボードを公開した話

その後、IMPとPVを分けて考えるようになりました。

IMPが少ない記事と、IMPは多いのにPVが少ない記事では、試すべき施策が違うかもしれない。

そう考えて作ったのが、記事を4象限に分類する「記事ポジション分析」です。

▶ IMP×PV率の4象限で「次に直す記事」を見える化した

この記事でも、欲しかったのはグラフではなく「改善サイクル」だと書いていました。

それからAIによる施策提言や、記事ごとの成長推移を比較する機能も追加しています。

少しずつ、どの記事を改善するかは考えやすくなってきました。

でも、改善対象を見つけることと、実際の記事を改訂することは別です。

次に必要だったのは、分析から実際の改訂へつなぐ仕組みでした。

GitHubに記事を保存した理由が、ここでつながった

もう一つ、これまで準備してきたことがあります。

公開済みのnote記事をGitHubで管理することです。

GitHubには記事本文、画像、記事情報などを保存しています。

こうしておけば、ChatGPTがGitHubとの連携を通じて、実際の記事本文を確認できます。

さらに、GitHubのPR（Pull Request）を使うと、変更前と変更後の差分を比較できます。

AIがどこを直そうとしているのか確認してから、自分で採用するか判断できるわけです。

▶ ChatGPTとGitHubでnote記事を管理｜本文・画像・修正履歴をAIと扱う実践記録

前回の記事では、この管理基盤を紹介しました。

そして今回、そのGitHub管理と分析ダッシュボードをつなぎました。

記事を保存しておくだけではなく、実際に改善するための原稿として活用する。

ようやく、やりたかったことが少し形になってきました。

ダッシュボードからChatGPTへ、改善したい記事を渡せるようにした

今回追加したのは、**「ChatGPT改善依頼をコピー」**というボタンです。

ダッシュボードの「記事ポジション」で気になる記事を選ぶと、詳細画面にボタンが表示されます。

ボタンを押すと、記事No.、タイトル、公開URL、取得日時、IMP、PV、スキなどを含む依頼文をコピーできます。

あとは、その文章を普段使っているKira AI LabのChatGPTプロジェクトに貼り付けるだけです。

ダッシュボードから別のAI APIを呼び出す仕組みにはしていません。

以前作った記事成長比較ラボでも、分析データを文章としてChatGPTへ渡す方法を試していました。

今回は、その考え方を記事の改訂につなげています。

改善の入口は2つあります。

一つは、自分がダッシュボードを見て改善する記事を選ぶ方法。

もう一つは、ChatGPTに「改善すべき記事はない？」と相談し、候補を探してもらう方法です。

どちらも、対象の記事が決まったあとは共通の流れに進みます。

ChatGPTが最新データと記事本文を確認し、必要なら改訂案を作る。

変更内容をGitHubのPRで確認し、自分が判断してnoteへ反映する。

ボタンを押しただけで、勝手に記事を書き換えたり公開したりするわけではありません。

このくらい人間の判断を残した方が、今の自分の運用には合っています。

でも、AIに「いい感じに直して」では足りない

ここで、もう一つ重要な問題があります。

ChatGPTに記事を渡したとして、何を基準に改善させるのか？

これを決めずに「PVが増えるように書き直して」と頼むだけでは、うまくいかない可能性があります。

例えば、実際に体験した失敗談。

AIが読みやすさを優先して、失敗した部分を削ってしまったらどうでしょう。

文章はきれいになるかもしれません。

でも、その失敗こそが読者にとって価値のある情報だったかもしれない。

また、タイトルを目立たせようとして、記事に書いていない成果を付け加えてしまうのも避けたいところです。

そこで今回、記事を改善するためのルールも整理しました。

現時点では、READ / VALUE / KEEP / DO / TALK / NEXTという6つの観点から、記事の改善余地を確認する方式を試しています。

大事にしているのは、全部を直そうとしないことです。

改善の目的を一つに絞る。

すでに良い部分は残す。

実際に起きたことや数字を勝手に変えない。

そして、改善する理由がなければ無理に変更しない。

AIに記事を渡す仕組みと同じくらい、AIにどう直させるかというルールが重要だと思っています。

この改訂ルールについては、実際に使った事例も含めて、次の記事で詳しく紹介する予定です。

実際に動いた？ 本番で確認してみた

今回の機能は、GitHubでコードを管理し、Mac miniからApps Scriptへ反映しました。

途中、記事No.の照合に使うスプレッドシートの列指定を間違えていたため、修正する場面もありました。

修正後、本番ダッシュボードでテストを実施しています。

対象にしたのは、GPT-6 Astraの利用状況を検証した記事です。

2026年10月18日10時取得のデータでは、累計IMPが12,567、PVが165でした。

ダッシュボードからコピーした依頼文をChatGPTへ渡し、GoogleスプレッドシートとGitHubの情報を照合しました。

結果、記事No.、タイトル、URL、分析値まで正しく一致しました。

これで、ダッシュボードで選んだ記事を、対応する記事情報と一緒にChatGPTへ引き継げることは確認できました。

ただし、今回のテストではこの記事自体を改訂していません。

確認できたのは、改善対象を正しく指定して、ChatGPTへ渡すところまでです。

記事を改善する実験も始めている

一方で、実際に記事を改訂する流れも別に試しています。

最初の事例は、Threadsの自動投稿で事実が変わってしまった経験を書いた記事です。

▶ Threads自動投稿をAIで作って分かった。文章生成より「事実を変えない」ことの方が難しかった

この記事では、AIによる改訂案を作り、GitHubのPRで確認してからnoteへ反映するところまで実施しました。

興味深かったのは、AIにすべてを書き直させなかったことです。

読者が自分でも使える確認手順や、後から見返せるチェック項目、関連記事への案内など、必要な箇所を中心に改訂しました。

一方、タイトルやアイキャッチは維持しています。

これは、先ほど触れた改訂ルールを使った最初の事例です。

ただし、記事を改訂できたことと、改善効果があったことは別です。

改訂前の参考値は、2026年10月18日10時時点で累計IMPが1,481、PVが23。

この変更によってPVが増えたかどうかは、まだ確認できていません。

10月25日に7日後のデータを確認し、改訂前後の増分や関連記事への影響などを見ていく予定です。

数字が増えたとしても、別の施策や時間経過の影響があるため、改訂だけの成果と決めつけないようにします。

記事を直したところで終わりにせず、そのあとを観測して初めて次の判断につなげられる。

この部分は、これからの検証です。

育てたいのは、記事だけではない

今回の仕組みで、もう一つ試してみたいことがあります。

それは、記事を改善するAIの使い方そのものも、少しずつ育てられないかということです。

例えば、AIが提案した改訂案を見て、

「これは読者の役に立ちそう」

「この変更は実体験を変えてしまうから採用できない」

「この記事は今のままでいい」

と判断する場面があります。

その理由を残しておけば、次に改訂するときの参考になります。

さらに、変更後の数字も確認すれば、どういう改善に可能性がありそうか、次の仮説を考えられるかもしれません。

もちろん、AIのモデルが自動的に学習して賢くなるという話ではありません。

人間の採否判断と検証結果を蓄積して、改訂ルールやプロンプトを必要に応じて見直していくということです。

記事を改善する。

その結果から、改善方法そのものも見直す。

そして、また次の記事へ。

これが、今考えている改善サイクルのもう一つの狙いです。

まとめ｜ダッシュボードへ戻るところまでが改善

最初は、noteの数字を自動で残したかっただけでした。

そこからダッシュボードを作り、記事の違いを見つけ、AIによる施策提案を追加してきました。

GitHubには公開済み記事を保存し、改訂の差分を確認できるようにしました。

そして今回、その2つをつなぐ入口ができました。

数字を見る → 改善を考える → 記事を直す → 結果を見る → 次の改善を考える。

この流れを繰り返せるか、これから実際に試していきます。

まだ、この仕組みによって記事のPVが伸びると証明できたわけではありません。

でも、記事を公開して終わりにするのではなく、継続して育てるための準備は進みました。

そして、次に考えたいのは改善の「中身」です。

AIに記事を渡せるようになった。では、AIには何をどう指示すれば、元の記事の価値を壊さずに改善できるのか？

実際に使っている6つの評価軸は、どんな考えで設計したのか。

なぜ、直す部分だけでなく「直さない部分」も決めるのか。

そして、実際の記事ではどんな改訂案ができたのか。

ここを次回、具体例とともに掘り下げたいと思います。

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

次回：AIにnote記事をどう直させる？ 6つの評価軸と改訂プロンプトを、実際の改訂例とともに紹介する予定です。

2026年10月19日追記｜予告していた続編を公開しました。

6つの評価軸（READ／VALUE／KEEP／DO／TALK／NEXT）の考え方、Threads記事で実際に改訂した箇所、読者が使えるプロンプト例を公開しています。なお、改訂によるPV改善の効果はまだ検証中です。

▶ AIにnote記事をどう直させる？6つの評価軸と改訂プロンプトを実例で解説

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

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