ブログの更新が、「書いて、指示して、確認する」だけになった話。

文章を自分で書き、ChatGPTに更新を指示し、ブログの公開結果を確認する3段階の流れ 写真・デザイン・Web

先日、ブログをリニューアルしました。

デザインや記事の見せ方については前の記事で書いたんですが、実は今回、それ以上に大きく変わったことがあります。

ブログの「運用の仕方」です。

これが、もう別物と言っていいくらい変わりました。

例えば、これまでブログに記事をひとつ投稿するには、こんな作業が必要でした。

【これまでのブログ更新】

  1. 書く内容を考える
  2. 文章を書く
  3. ブログ用に文章や見出しを整える
  4. WordPressの管理画面を開く
  5. 記事を作成し、本文を入力・装飾する
  6. 写真をアップロードして配置する
  7. アイキャッチやカテゴリー、タグ、SEO関連の情報を設定する
  8. プレビューで確認して公開する

記事の内容によって増減はありますが、大体こんな感じ。

僕はWeb制作もしているので、このあたりの作業は別に苦ではありません。

ただ、記事をひとつ公開するだけでも、書くこと以外に結構な手間がかかるんですよね。

それが、今回の仕組みではこうなりました。

【いまのブログ更新】

  1. 記事を考えて、書く
  2. ChatGPTに更新を指示する
  3. 公開された記事を確認する
以前の手動更新と、いまの文章執筆・ChatGPTへの指示・公開確認の比較図
記事を書くことはそのまま。公開までの操作をまとめて実行できるようにしました。

ここで重要なのは、文章を書くという部分は以前と変わっていないことです。

何を書きたいのか、どういう言葉で表現するのか、何を残しておきたいのか。そこは僕の仕事です。

変わったのは、その文章をブログとして公開するまでの作業。

しかも、ここでいう「指示する」というのは、WordPressに貼り付けるためのHTMLを用意するという話ではありません。

実際にWordPressへ記事を登録し、画像やカテゴリーなどを設定し、公開して、結果を確認するところまで実行できるようにしたんです。

つまり、僕がWordPressの管理画面を開かなくても、記事の更新ができる。

これが今回、最も大きく変わった部分です。

ChatGPTが、そのままブログを更新する

例えば、映画を観て感想を書いたとします。

以前なら、その文章をWordPressへ持っていき、作品情報やポスターを配置して、カテゴリーを選び、アイキャッチを設定して……と、自分で編集する必要がありました。

いまは、書いた文章をもとに「この感想を、いつもの映画レビューの形式でブログに掲載して」と指示できます。

すると、あらかじめ決めてあるルールに従って、記事の登録に必要な作業を進められます。

例えば、作品の原題や監督、出演者、上映時間などの確認。公式ポスターの配置、カテゴリーやタグの設定、公開日の調整などです。

舞台の記事なら、公演期間、劇場、キャスト、スタッフといった情報も大切になります。

こうした記事の種類ごとの掲載ルールも、共通の資料として管理しています。

毎回、最初から説明し直す必要がありません。

もちろん、必要な情報が見つからなかったり、画像の確認が必要だったりすれば、途中で判断することもあります。

何でも無条件に公開するわけではなく、指示した範囲で処理し、その結果を確認する仕組みです。

でも、「文章を書くこと」と「文章を公開するための操作」を切り離せたのは、本当に大きい。

書き終わった文章を公開するために、もう一度別の仕事を始める必要がなくなったわけです。

どうやってWordPressを自動で更新しているのか

では、何を使ってこれを実現しているのか。

中心となっているのは、WordPress、ChatGPT、GitHubの3つです。

  • WordPress:記事を保存・公開する場所
  • ChatGPT:僕の指示をもとに、必要な調査や作業を進める
  • GitHub:更新処理のプログラムや変更履歴を管理する
本人、ChatGPT、GitHub Actions、WordPressによる更新作業の流れ
記事の登録はWordPress REST API、実行や変更履歴の管理にはGitHubの仕組みを使います。

ここで使っているのが、WordPressの「REST API」という仕組みです。

簡単に言うと、WordPressの管理画面を人間が操作しなくても、外部のプログラムから記事の登録や更新ができる機能です。

例えば、管理画面で公開ボタンを押す代わりに、プログラムから公開処理を実行できます。

GitHub Actionsという自動実行機能を組み合わせることで、指定した更新処理を実行し、その結果を記録できるようにしています。

なので、

僕が指示する → 更新処理が実行される → WordPressに反映される → 結果を確認する

という流れになります。

実際の更新方法は記事とサイト本体の変更で少し異なりますが、基本的な考え方は同じです。

以前は、僕自身がWordPressの画面でひとつずつ操作していた部分。

それを、ひとまとまりの作業として実行できるようにしたんですね。

ちなみに、WordPressの管理画面を廃止したわけではありません。必要なときは従来どおり使えます。

普通に記事を書く仕組みは残しつつ、別の更新方法を追加したということです。

デザインの修正も、ほぼ同じ考え方

便利になったのは記事の投稿だけではありません。

サイトのデザイン変更や、不具合の修正も同じように進められます。

例えば、

「スマホの記事一覧で、画像をもっと大きくしたい」

「縦長の舞台フライヤーは、切り抜かずに全部見せたい」

「人気記事の表示を、ページ移動なしで切り替えたい」

そんな指示を出すと、現在のサイトの仕組みを調べ、必要なプログラムの修正やテストを進めることができます。

変更内容はGitHubに保存されるので、何を変更したかもわかる。

さらに、公開前のバックアップ、テスト、公開後の確認といった作業も、ある程度自動化しています。

以前のように、CSSを何度も書き換え、画面を確認して、また直して……という操作を僕が全部担当する必要はありません。

もちろん、最終的に「このデザインがいいかどうか」は自分で判断します。

そこはAIが決めることではないと思うので。

ただ、思いついた改善を、実際のサイトへ反映するまでの距離が圧倒的に短くなったのは確かです。

20年以上の記録も、まとめて扱えるようになった

もうひとつ、大きく変わったのが過去の記録の扱いです。

このブログは2004年から続いています。

記事の数も相当なものになっていますし、ブログ以外にもXなどで書いてきた文章が大量にあります。

昔の映画の感想、観劇の記録、日々の考えごと。

こういうものを、ひとつずつ探してコピーし、WordPressに登録していくのは、なかなか現実的ではありません。

そこで、Google Driveに元の記録を整理し、WordPressと照合しながら、ブログに残しておきたいものをまとめて扱えるようにしました。

実際、2026年10月末の作業では、224件の候補を整理・照合し、そのうち206件を新しいブログ記事として公開しています。

既存記事と重複するものは、別の記事を増やすのではなく、既存の記録と統合したり、必要な情報を補ったりしています。

重要なのは、単に大量の記事を追加することではありません。

過去の文章や出来事を、当時の記録として残すこと。

さらに作品名や出演者、劇場、カテゴリーなどを整理することで、あとから情報を探しやすくすることです。

新しい記事を書くことだけでなく、昔の記録を活用することも、ずいぶんやりやすくなりました。

アクセス解析も、確認するだけから「改善する仕組み」へ

Google AnalyticsやSearch Consoleは以前から使っていました。

どの記事が読まれているか、どんな検索キーワードで見つけてもらえているか。

ただ、データがあることと、それを継続的に活用できることは別の話です。

以前は、気になったときに管理画面を開いて調べる、という使い方が中心でした。

今回はGoogle Apps Scriptを使い、アクセスや検索のデータを定期的に取得して、スプレッドシートへ蓄積する仕組みを整えました。

これによって、例えば検索結果に表示されているのにクリックされていない記事や、昔の記事なのに現在も検索されているページなどを調べやすくなっています。

さらに、どの記事を修正したのか、修正前後でどんな変化があったのかを、一定の期間で比較できるようにしています。

これを「Search Intelligence」という考え方で管理しています。

ブログの公開、アクセスデータの取得、分析、改善を循環させる仕組み
公開して終わりではなく、読まれ方を調べて次の改善につなげます。

名前はちょっと大げさですが、やっていることは単純です。

調べる → 改善する → 結果を確認する。

この流れを、勘や気分だけではなく、データも使って継続していこうという仕組みです。

もちろん、検索順位が上がったからといって、すべてが修正のおかげとは限りません。

効果の検証には時間も必要ですし、まだデータを集めている段階のものもあります。

アクセスが少ないから価値がない、という判断をするつもりもありません。

あくまで、ブログをより良くするための判断材料を増やしたということです。

メリットばかりではありません

ここまで便利になったことを書いてきましたが、もちろんデメリットもあります。

まず、裏側の仕組みが複雑になりました。

WordPressだけでなく、GitHubやGoogleのサービスも使っているので、どこに何が保存されているのか、どの情報が最新なのかを管理する必要があります。

また、AIは普通に間違えます。

存在しない問題を指摘することもありますし、すでに終わった作業をもう一度やろうとすることもあります。

便利だからこそ、結果の確認が必要です。

今回の運用では特に、「作業した」と「実際に反映された」を区別するようにしています。

プログラムを修正しただけでは完了ではありません。

公開サイトに反映され、必要な部分が正常に動いていることを確認して、初めて完了です。

自動化したからといって、何でも完全に放置できるわけではありません。

サービス同士の認証が切れて、処理が止まることもあります。実際、アクセスデータの定期取得では復旧作業が必要になったこともありました。

それでも、一つひとつの作業を自分で操作していた頃と比べれば、できることは格段に増えています。

ただ、ひとつ問題もあって。

作業が簡単になったぶん、今度は「あれも直したい」「これも改善したい」と、やりたいことが次々に増えるんですよね。

効率化したはずなのに、結局いつまでもブログをいじっている。

これはもう、仕組みの問題じゃなくて僕の問題かもしれません(笑)。

作業を減らすことと、考えることを減らすのは違う

今回のリニューアルを通じて感じたのは、AIによる効率化は、単に作業時間を短縮するだけのものではないということです。

これまでは「何をやりたいか」を考えるだけでなく、「それを実現するために何を操作するか」まで、自分で考えて実行する必要がありました。

いまは、やりたいことを伝えれば、実現方法を調べ、必要な作業を進めるところまで任せられるようになっています。

文章を書くことは、変わりません。

でも、書き終わった文章をブログに登録するための作業は、大幅に減らすことができました。

記事を公開するための操作に時間を使うより、どんな文章を残したいのかを考える。

デザインの変更方法を調べ続けるより、どうすれば読者が読みやすくなるのかを考える。

アクセスの数字を集めることより、その数字から何を読み取るかを考える。

人間が考えるべきことに、もっと時間を使えるようになった。

これが、一番のメリットなのかもしれません。

このブログは、20年以上にわたって僕が書いてきた文章の蓄積です。

それをこれからも残し、育てていくために、技術の力を借りる。

そう考えると、AIを使うこと自体が目的ではなく、やりたいことを実現するための手段なんですよね。

もっとも、作業が簡単になればなるほど、やりたいことが増えてしまうわけですが。

……結局、考えることは減らないんですね。

まぁ、それはそれで、悪くないと思っています。

コメント

ちょっと、寄り道。

昔の文章から、今日の一篇。

日記・考えごと

AM 4:32

もう一篇、見つける