AI に記事を書かせる。
少し前までは実験的な話でしたが、現在は実際に運用している仕組みのひとつになっています。
僕は n8n とローカルLLM を組み合わせて、情報収集から WordPress への下書き投稿までを自動化しています。
RSS やメールで届く情報を取得し、AI が記事の下書きを作成する。
その後、WordPress に下書きとして保存されます。
現在は専用の WordPress アカウント「源勝0号」を作成し、Ollama 関連のニュース記事を中心に運用しています。
この記事では、実際にどのような構成で運用しているのか、なぜこの仕組みを作ったのか、そして運用を続ける中で感じたことを紹介します。
WordPress 自動投稿を試したかった理由
ローカルLLM を使い始めた頃から、「記事作成の一部を自動化できないだろうか」と考えていました。
ブログを書くこと自体は嫌いではありません。
むしろ日課のようなものです。
ただ、情報収集や要約、記事の下書き作成など、毎回似たような作業も少なくありません。
特に AI 関連のニュースは情報量が多く、新しいモデルやサービスが次々に登場します。
気になる情報を見つけても、
- 後で記事にしようと思って忘れる
- 下書きだけ作って公開しない
- 情報収集だけで満足してしまう
ということもよくありました。
そこで考えたのが、情報収集から下書き作成までを仕組み化することです。
ちょうどその頃は n8n や AI Agent を触り始めた時期でもありました。
せっかくなら実際に自分が使う仕組みを作った方が理解も深まります。
そう考えて、WordPress 自動投稿ワークフローの構築を始めました。
現在の構成
現在は以下のような構成で運用しています。
- RSS やメールで情報を取得
- スプレッドシートへ保存
- Tavily Extract で記事本文を取得（RSS の場合）
- gemma4:26b が記事の下書きを作成
- gemma4:26b が記事内容を再確認
- WordPress へ下書き投稿
記事生成にはローカル環境で動作する gemma4:26b を利用しています。
取得した情報はスプレッドシートで管理し、記事生成後は WordPress の下書きとして保存されます。
現在は AI ニュースサイトを作ることが目的ではなく、「ローカルLLM と n8n を使ってどこまで実用的な自動化ができるのか」を検証する実験環境として運用しています。
実際の処理の流れ
日常的な運用はほぼ自動です。
RSS やメールで新しい情報が届くと、n8n が定期的にチェックを行います。
RSS の場合は URL を取得し、Tavily Extract を利用して記事本文を取得します。
メールの場合は本文そのものを情報源として利用するため、追加の取得処理は行いません。
取得した情報はスプレッドシートへ保存されます。
投稿済みかどうかも管理しているため、同じ内容を何度も処理することはありません。
その後、gemma4:26b が記事の下書きを作成します。
単純な要約ではなく、
- 元記事の内容をできるだけ省略せず整理する
- 専門用語をわかりやすく説明する
- 利用者にとってのメリットをまとめる
- 誇張や推測を避ける
といったルールで記事化しています。
記事が生成されると、別の工程で内容を再確認します。
ここでは、
- 元記事の内容を正しく伝えているか
- 誤字や脱字がないか
- 誤解を招く表現がないか
- HTML 構造に問題がないか
などをチェックしています。
チェックが完了すると、記事は WordPress に下書きとして投稿されます。
公開前には僕自身も内容を確認しています。
特にメールを情報源にする場合は、
- Confidential
- 社外秘
- 限定公開
といった記載がないかを確認し、一般公開して問題ない情報だけを記事化しています。
技術的には公開まで自動化できます。
ただ、現在は最終的な公開判断だけは人間が行う運用にしています。
一度は実運用をやめた
実は、この仕組み自体は 2026 年 4 月頃には完成していました。
RSS を取得し、AI が記事を書き、WordPress へ投稿する。
技術的には当初の目的を達成していたのです。
ところが、実際に記事を生成してみると、どうもしっくりきませんでした。
記事は完成する。
WordPress にも投稿される。
それでも公開したいと思えなかったのです。
情報は整理されています。
内容も大きく間違ってはいません。
しかし、自分が普段書いている記事と比べると、どこか物足りなく感じました。
当時は下書きを作っては削除し、また生成しては削除することを繰り返していました。
また、公開前に内容を確認していると、「結局、自分で全部読んでいるな」と思うこともありました。
だったら最初から自分で書いた方が早いのではないか。
そう考えて、一時期はほとんど運用しなくなりました。
ただ、ワークフローそのものを捨てたわけではありません。
その後もプロンプトの調整やチェック工程の改善は続けていました。
そうしているうちに、自分の考え方も少し変わってきました。
問題は AI の性能ではなく、「AI に何を任せるのか」だったのではないか。
そう考えるようになったのです。
現在は、
- AI が情報を整理する
- AI が下書きを作る
- 人間が公開を判断する
という形に落ち着いています。
完全自動化ではありません。
それでも、情報収集や下書き作成にかかる負担は大きく減りました。
今振り返ると、技術的な課題よりも、AI と人間の役割分担を見つけることの方が難しかったように感じています。
現在は「源勝0号」で運用しています
現在は WordPress 内に「源勝0号」という専用アカウントを作成し、AI が作成した記事を投稿しています。
このアカウントでは主に、
- Ollama の RSS
- Ollama から配信されるメール
- 一般公開されている技術情報
をもとに記事を作成しています。
記事は AI が下書きを作成し、内容を確認したうえで公開しています。
そのため、完全自動運用というよりは半自動運用に近い形です。
実際に公開しているのは、
- Ollama のアップデート情報
- 新しいモデルの公開情報
- Ollama Cloud の変更内容
- 関連するオープンソースプロジェクト
といった内容が中心です。
これらの記事は自分でゼロから執筆しているわけではありません。
一方で、情報収集から公開までを完全自動化しているわけでもありません。
AI が下書きを作り、人間が最終確認を行う。
現在はそのような形で運用しています。
公開後は通常の記事と同じようにアクセス数も確認できます。
大規模なニュースサイトを目指しているわけではありませんが、実際に AI が作成した記事が読まれる様子を見るのはなかなか興味深い体験です。
現在の目的は、AI に記事を大量生成させることではありません。
ローカルLLM と n8n を使った記事作成が、実際の運用に耐えられるのかを試すことです。
その中で、読者に役立つ情報を届けられるのであれば、それもひとつの成果だと考えています。
AI 記事作成で感じた課題
実際に運用を続けてみると、AI による記事作成には便利な部分だけでなく、いくつか課題も見えてきました。
まず感じたのは、情報が正しくても記事として面白いとは限らないということです。
AI は情報整理が得意です。
元記事の内容をまとめたり、要点を整理したりする作業はかなり安定しています。
一方で、
- なぜその情報が気になったのか
- 実際に使ってどう感じたのか
- どこに面白さを感じたのか
といった体験に基づく部分は弱くなりがちです。
そのため、内容は正しくても、どこか無機質な文章になることがあります。
また、プロンプトを複雑にしすぎると品質が下がることもありました。
最初の頃は、
- SEO を意識する
- 読者メリットを書く
- ファクトチェックする
- 独自性を出す
- 構成を最適化する
など、多くの指示を詰め込んでいました。
しかし実際には、条件が増えるほど出力が不安定になることも少なくありませんでした。
現在は、まず元記事を丁寧に整理することを優先しています。
そして必要に応じて、人間が手を加える方針に落ち着きました。
もうひとつ感じたのは、AI が書いた記事は結局自分でも読むということです。
ファクトチェック用の AI を挟んでいても、公開前には自分でも確認したくなります。
特に技術記事の場合は、
- 解釈がズレていないか
- 誤解を招く表現になっていないか
- 公開して問題ない内容か
を確認する必要があります。
完全自動化を目指すよりも、人間が最後に確認する前提で運用した方が安心できると感じています。
実際に運用してみると、AI の得意なことと苦手なことが少しずつ見えてきました。
だからこそ現在は、AI に全部任せるのではなく、役割を分ける形で運用しています。
AI に全部任せない運用
この仕組みを運用していて感じるのは、AI にすべてを任せる必要はないということです。
AI 関連の話題では「完全自動化」が注目されることもあります。
しかし実際に運用してみると、必ずしもそこを目指す必要はありませんでした。
現在のワークフローでは、
- RSS やメールから情報を取得する
- AI が記事の下書きを作成する
- AI が内容をチェックする
- 人間が公開を判断する
という形にしています。
技術的には、そのまま自動公開することも可能です。
実際に WordPress への投稿までは自動化できています。
それでも現在は下書きとして保存し、最後は自分で確認しています。
AI が下書きを作ることはできますが、公開の可否を判断するのは運営者の役割だと考えています。
特にメールを情報源にする場合は、
- 公開して問題ない内容か
- 社外向けに公開してよい情報か
- 誤解を招く表現がないか
を確認する必要があります。
一方で、
- 情報収集
- 記事の下書き作成
- 記事構成の整理
- 誤字脱字の確認
といった作業は AI が非常に得意です。
以前は記事を書く前の準備だけでも意外と時間がかかっていました。
現在はその多くを AI が担当してくれています。
結果として、自分は「公開する価値があるか」を判断することに集中できるようになりました。
実際に運用を続けてみて感じたのは、「AI に全部任せる」よりも、「AI と役割分担する」方が現実的で続けやすいということです。
今のところ、この運用が自分には一番合っているように感じています。
まとめ
この WordPress 自動投稿の仕組みは、現在も継続して運用している AI 活用事例のひとつです。
技術的には、RSS やメールから情報を取得し、AI が記事を作成して WordPress へ投稿するところまで自動化できています。
ただ、実際に運用してみると、完全自動化が正解というわけではありませんでした。
記事を書くだけなら AI でもできます。
しかし、
- 内容が正しく伝わっているか
- 公開して問題ない情報か
- 読者にとって分かりやすい内容になっているか
といった部分は、最終的に人間が確認した方が安心できます。
そのため現在は、
- AI が下書きを作る
- AI が内容を確認する
- 人間が公開を判断する
という形で運用しています。
最初は「AI で記事を自動生成できるのか」を試したくて始めた仕組みでした。
しかし現在は単なる実験ではなく、実際に運用しているワークフローのひとつになっています。
もちろん、まだ改善したい部分はたくさんあります。
それでも、
- 情報収集
- 記事の下書き作成
- 記事構成の整理
といった時間のかかる作業を AI に任せられるようになったことで、以前より記事作成に取り組みやすくなりました。
今後も ローカルLLM と n8n を活用しながら、小さく改善を重ねていこうと思います。
