記事は誰が選び、誰がリライトの判断をするのか──そのすべてをAIが担う「AI編集長」の仕組みを、n8n × ChatGPT × Notionで自作した全記録をまとめました。
なぜ「AI編集長」が必要なのか？
ブログ記事を量産する時代から、検索意図を満たす本質的な情報を届ける時代へと変化する中、リライトや構成調整の重要性はかつてないほど高まっている。
しかし、その判断を人力で担うには時間・労力・主観の限界がある。ここでは、なぜAIを「編集長」という立場に据える必要が出てきたのかを明らかにする。
人間のリライト判断が抱える3つの問題
第一に、記事のPVが落ちても「どこをどう直すか」の判断が属人的になりやすい。第二に、直帰率や滞在時間といった指標は見えても、それが文章のどこに影響しているかは感覚に頼りがちである。
第三に、見出し構成やトピックの抜け漏れに気づきづらく、結果的に「改修しても効果が出ないリライト」に陥りやすいという問題がある。
ChatGPTの能力をどう“判断”に使うか？
ChatGPTは単なる生成ツールではなく、構成評価・網羅性の確認・検索意図の補完といった「編集視点の分析」も可能だ。
記事の見出し構造や内容要約、想定読者のニーズなどを踏まえて、「何が足りないか」を指摘する役割を担わせることで、AIが“考える編集者”として機能する。
「構造としての編集機能」に向いているのは誰か？
人間が1記事ずつ手動で評価し、修正すべきかを判断するのは非現実的である。
構造を抽出し、データに基づいたルールで判断し、提案を定型化して返す作業はむしろAIにこそ向いている。
特に、n8nやNotionなどの外部ツールと連携することで、AIに「編集判断をさせるプロセス」自体を自動化できる点が大きなメリットとなる。
AI編集長の構成全体像
このAI編集長という仕組みは、いくつかのツールをつなげて、自分の代わりに「何をリライトすべきか」を判断してくれるように作っている。
実際には人間が見てる数字（PV、直帰率、滞在時間）をもとに、AIに判断させて、それをNotion上で管理できるようになってる。ここでは、構成の全体像と、それぞれの役割をざっくり整理しておく。
主要ツールと役割の対応表
| ツール | 役割 |
|---|---|
| n8n | すべての処理を自動で回すハブ。時間になったら動く。 |
| Google Analytics 4 | PV、直帰率、滞在時間などの数値データを取得する。 |
| ChatGPT（API） | 取得した記事データに対して、リライトの必要性を判断する。 |
| Notion | 提案内容を記録・確認・ステータス管理する編集ダッシュボード。 |
仕組みの流れ（PV取得 → 判断 → 提案）
まずGA4から直近30日分のPVデータを取得する。
PVが多い記事、または過去と比べて落ち込んでる記事を対象に、ChatGPTへ「この記事は改善すべきか？」を判断させる。
出力されたコメント（構成が弱い、情報が古い、ニーズに合っていないなど）をそのままNotionに送って、リライト対象リストとして残しておく。
これをn8nがすべて自動でやってくれるので、毎週土曜とかに「今週のリライト候補」をNotionで確認すれば済むようになる。
人間はどこで関与すべきか？
この仕組みの中で人間がやるべきことは、たったひとつ。「リライトすべき」とされた記事の中から、実際に手を入れるかどうかの判断をするだけ。
提案内容がイマイチなら無視してもいいし、「なるほど」と思えばそこから構成を直していけばいい。
重要なのは、"考える労力"をすべてAIに任せて、自分は判断に専念できるってところ。リライト対象を探す手間も、構成の抜けを分析する時間もゼロにできる。
n8nで全工程を自動化する方法
この仕組みのキモは、n8nを使って「全部自動でやらせること」にある。
自分でボタンを押したり、毎回手で確認したりするようじゃ仕組み化とは言えない。
だからこのパートでは、GA4からデータを取って、ChatGPTで評価して、それをNotionに流し込むまでの流れをすべてn8nに任せる方法について書いていく。
GA4 APIからPV・直帰率などを取得
まずやるのはGoogle Analytics 4からデータを引っ張ってくる部分。
使うのはGA4のData API。ここで取得するのはPV数、直帰率、平均滞在時間あたり。このへんを見れば「読まれてるか」「ちゃんと読まれてるか」「すぐ帰られてるか」がざっくりわかる。
n8nのHTTP RequestノードでGA4 APIを叩いて、プロパティIDとクエリパラメータを指定すれば、定期的に最新データを取れるようになる。
ChatGPTで「リライト要否」を判定させる
GA4で取れた各記事の数値を、ChatGPTに送って「これってリライトしたほうがいい？」って聞く。
ここで重要なのは、ただの感想を求めるんじゃなくて、「指標に基づいた判断」を出してもらうこと。
たとえばPVが下がってる、滞在時間が短い、直帰率が高い──そういう条件を渡して「それっぽい理由」と「改善すべきかどうか」の判断を返してもらう。
n8nではOpenAIノードかHTTPノードを使えば簡単にやれる。
Notionに提案結果を記録して可視化する
ChatGPTが返した判定とコメントは、そのままNotionのデータベースに書き込む。
ここで大事なのは、「読まなくても分かる構成」にしておくこと。
記事タイトル、リライト判定、理由、そしてステータス（要確認・除外・対応済など）を一覧にしておけば、見るだけで優先度がわかる。
Notion連携はn8n公式ノードで対応済みだから、データベースIDとプロパティ構造さえ把握してれば書き込みはすぐできる。
スケジューラーで週次自動実行
最後に、n8nのスケジュールノードを使って、これらの一連の流れを「毎週○曜日の朝8時」とかに勝手に動かす。
設定すれば、あとは一切触らなくても、毎週最新のリライト候補がNotionに並ぶようになる。
これが実現できれば、「何を直せばいいか？」を考える必要すらなくなる。あとはNotionを見て、対応するかスルーするかを決めるだけ。完全に自分の外に“編集判断”を出す状態がつくれる。
実現までにぶつかった壁と対応策
「AI編集長」の仕組みを考えるだけなら楽勝だった。
でも実際に動かそうとすると、あちこちで壁にぶつかった。
特にAPIの仕様制限とか、トークン制限とか、ノーコードなのに“構造の崩壊”が起きるあたりとか、いかにも現実的な難しさがあった。
このセクションでは、詰まったポイントと、そのときに取った対応を正直に書いていく。
ChatGPTトークン制限の現実的突破方法
一番最初に壁になったのがトークン数。PVや直帰率を何十件もまとめてChatGPTに投げると、トークン超過で止まる。
しかも、判断精度を上げようとするとプロンプトが長くなるから、さらに消費が増える。
対策としてやったのは、「1記事ずつ送る」方式への切り替え。
n8n側でループを作って、1記事ずつChatGPTに問い合わせるようにした。もちろんその分APIコール回数は増えるけど、エラーで止まるよりずっとマシ。
GA4 APIの仕様制限とその回避法
GA4のAPIは正直わかりにくい。使えるディメンションや指標に制限があるし、同時に使えない項目も多い。
「平均滞在時間」と「ページタイトル」が同時に取れない、みたいなケースが普通に出てくる。
ここでやったのは、「一度に全部取ろうとしない」って割り切り。
項目ごとにクエリを分けて、複数回APIを叩くようにした。データを1つのオブジェクトに統合する処理はn8n側でやる。これで回避できた。
n8nの分岐設計で起きた構造の崩壊
n8nって便利だけど、分岐ロジックが複雑になると一気に見通しが悪くなる。
今回も「リライトすべきかどうか」の判断をChatGPTから受け取って、YesならNotionへ、Noならスキップ──という分岐を作ったところで、全体の構造が破綻しかけた。
具体的には、途中でデータが片方にしか流れず、Notion側で必要なプロパティが不足してエラーになることが頻発した。
対応策としては、「分岐先で共通の空プロパティを補完する処理」を入れておくこと。n8nで分岐を使うときは、“どのルートでもデータ構造を揃える”ってのがかなり大事になる。
この仕組みがもたらす本質的変化
「AI編集長」を作ってみて思ったのは、これは単に“便利なツール”じゃなくて、ものの考え方自体を変えてくれる仕組みだったということ。
ただ作業を自動化しただけじゃなくて、「そもそも自分が判断する必要があるのか？」って視点すら変えてくれた。この章では、実際に運用してわかった3つの変化について書いていく。
「考えるべきか？」から「見るだけでいい」へ
今までは、記事のPVが落ちたときに「これって直すべきかな？」っていちいち考えてた。
でもこの仕組みを入れてからは、Notionを開くだけで“今週直すべき候補”が一覧で出てくる。つまり「考える」じゃなくて「見るだけ」になった。
自分で考えるフェーズをすっ飛ばして、判断そのものをAIに委ねられるようになると、精神的な消耗がまったく違う。判断にかかるコストがゼロになるって、実はすごい変化だった。
「書くべき記事」が明示される日常
もっと面白いのは、AIに任せると「読まれてない記事」じゃなくて「読まれてるのに直す余地がある記事」を拾ってくること。これって人間にはなかなか気づけない視点。
つまり「アクセスがある＝正解」じゃないってことを、数字と構成から判断してくれる。
これはもう、「何を書けばいいかわからない」って状態から脱却できる仕組みだった。新記事を書くより、既存記事をどう直すかに集中できるようになった。
ビープロが運用して得た副次的な効能とは？
実際にこの仕組みを回し始めてから、ブログに対するストレスがめっちゃ減った。
常に「どこを直すべきか？」っていう不安がなくなるし、やるべきことが明示されるから迷わない。
副次的な効果としては、「リライトしたくない記事は放置していい」って判断ができるようになったこと。
つまり“直すべき記事”だけを選んで、残りは無視できるようになる。この割り切りができるようになったのも、AIが前に出てくれたおかげだった。
