WordPressは長く使ってきました。テーマをカスタマイズし、更新しやすいサイトを作る仕事でもお世話になっています。今もWordPressで動いているサイトはたくさんありますし、使う理由も十分にあります。
それでも、自分のブログを作るときには、別の方法を選んでみました。記事はファイルで管理し、AIと相談しながら書いています。このブログ自体を実験台にした記録です。
長年WordPressを使ってきた理由
WordPressのテーマをカスタマイズし、サイトを更新するCMSとして導入してきて約10年になります。今も現役で使い続けている会社のサイトがあります。
プラグインは豊富で、必要なら自作もできます。分からないことをWebで調べると、同じところで困った人の情報が見つかることも多いです。有志が作ったカスタムフィールドのプラグインには、何度も助けられました。
利用者が多いからこそ、情報が集まり、問題への対応も続いています。仕事でサイトを作り、運用していく上では大きな強みだと思います。これからも、WordPressが合うサイトでは使っていくつもりです。
それでも、自分のブログの作り方を見直した理由
一方で、利用者の多い仕組みは攻撃の対象にもなりやすいです。WordPressを使うなら、本体だけでなくテーマやプラグインの更新にも目を配る必要があります。WordPress公式のセキュリティガイドも、継続的な更新を基本としています。
更新そのものが嫌なわけではありません。ただ、自分のブログでやりたいことは、記事を書いて公開することが中心です。そのために管理画面やプラグインを持ち続け、更新のたびに動作を確認する必要があります。ひとつひとつは小さくても、続けるとなると手間がかかります。
WordPressが危険だからやめた、という話ではありません。自分のブログに必要な機能と、引き受ける管理の量を見直した結果です。
このブログを実験台にして作った仕組み
新しいブログでは、記事をMarkdownファイルで保存しています。サイトはNext.jsで作り、公開用には静的なページを書き出します。出来上がったファイルをVPSへ配置して、Webサーバーから配信する構成にしました。
記事の原稿と公開するページを分けて管理しています。図は構成を簡略化したものです。
記事を書く流れも変わりました。まず、サイトで伝えたい方向性をAIに共有し、記事の案や構成を出してもらいます。そこから自分で文章を書き、AIに加筆や校正を頼みます。直した原稿を確認して、公開する記事だけをサイトに反映します。
管理画面から「投稿」を押す形ではないので、誰にとってもこちらが簡単とは言えません。自分の場合は、サイトのコードと記事を一緒に扱えること、AIにファイルの修正まで頼めることが合っていました。
静的なページにしたからといって、管理がなくなるわけでもありません。VPSやWebサーバー、サイトの依存パッケージは今後も手入れが必要です。ただ、記事を見せるために常時動くWordPressの管理画面とデータベースは、このブログには置かずに済みました。
AIと一緒に、公開まで進めてみた
この原稿も、AIに構成を考えてもらい、自分で最初の文章を書いたところから始まりました。WordPressを使ってきた理由や、更新の負担をどう感じたかは、自分の言葉で残しています。その続きをAIに書いてもらい、表現も整えているところです。
今回の記事づくりの流れ。公開判断までを自動化した仕組みではなく、会話しながら手作業で進めています。
サイトの公開では、まず別の記事を1本だけ公開することにしました。この「WordPressをやめて」の記事は、まだ下書きとして保管しています。完成していない原稿が、サイトの公開と一緒に出てしまわないようにするためです。
公開作業では、書き出したサイトをVPSに置き、表示を確認してから切り替えました。SSHのパスワードをチャットに書くことはせず、鍵で接続しました。切り替え前に確認し、最後の判断は自分で行いました。AIが変更案を作り、人が確かめて本番へ反映する流れを、まずは会話と手作業で試した形です。
実際にやると、記事とサイトのファイルを置くだけでは終わりませんでした。チャットボットの接続先がHTTPのままだと、HTTPSのブログから読み込めません。そこでDify側にもドメインとHTTPSを設定しました。以前のサイトで使っていたアクセス解析とタグマネジャーも、新しいサイトへ引き継ぎました。
公開後は、トップページと記事が表示されること、下書きの記事が表示されないこと、チャットボットと計測用のタグが読み込まれることを確認しました。この時点で公開した記事は1本です。この原稿は、その後に書き進めている下書きです。
公開には、サイト以外の準備もあった
今回、自分のサイトだから決められたことも多くありました。それでも公開まで進めると、記事やデザイン以外に、誰が何を管理し、いつ切り替えるかを一つずつ確認する必要がありました。企業のサイトを担当するとしたら、制作前に聞いておきたいこととして整理してみました。
| 項目 | 今回やったこと | 企業サイトなら確認したいこと |
|---|---|---|
| サーバーへの接続 | VPSへSSH鍵で接続しました。パスワードはチャットに書きませんでした | 接続方法、権限を持つ担当者、作業できる時間帯 |
| 公開先と切り替え | 新しいファイルを別の場所に配置し、表示を確かめてからWebサーバーの設定を切り替えました | 現行サイトの設置場所、切り替え手順、戻すときの手順 |
| ドメインとDNS | チャットボット用のサブドメインを設定し、反映を待って確認しました | DNSを管理する会社・担当者、レコード変更の依頼先と反映時間 |
| HTTPS | チャットボット側にも証明書を設定し、HTTPSのブログから読み込めるようにしました | 証明書の取得・更新方法と、外部サービスの接続先 |
| アクセス解析 | 以前のサイトで使っていたタグマネジャーと解析設定を引き継ぎました | 計測ID、管理権限、切り替え後に確認する指標 |
| 公開する内容 | 記事は1本だけ公開し、この原稿は下書きのままにしました | 公開するページの一覧、原稿・画像の確認者、公開日の判断 |
| 公開後の確認 | ページ表示、下書きの非表示、チャットボットと計測タグの読み込みを確認しました | 確認する端末・機能、不具合時の連絡先と対応する人 |
SSHのパスワードが必ず必要というわけではなく、今回は鍵で接続できました。企業サイトでも、認証情報をチャットに貼る前提にはしません。必要な権限だけを、管理者が決めた方法で受け渡してもらうことになります。
こうした確認事項は、サイトの見た目にはほとんど出てきません。でも、担当者や承認者が増えるほど、先に整理しておかないと公開直前に止まる部分だと思いました。
やってみて分かったこと
AIに任せて便利だったのは、記事の案出しや構成、書いた文章の整理です。最初から完成した文章を出してもらうより、自分の経験を書いてから手伝ってもらう方が、何を伝えたいかを見失いにくいと感じました。
一方、公開するかどうかの判断や、書かれた事実の確認は自分の仕事として残ります。とくにこの話では、「WordPressをやめた」と言っても、すべての仕事で使わなくなったわけではありません。自分のブログでは別の方法を選んだ、という範囲をはっきりさせておきたいです。
サイトを公開する作業にも、文章だけでは分からない確認がありました。HTTPS、チャットボット、アクセス解析、下書きの扱いなどです。AIに手伝ってもらえる部分は多いですが、実際の表示を見て初めて分かることもあります。
まずは、自分のブログをこの方法で運用しながら、記事を書き、直し、公開する流れを確かめていきます。WordPressを長く使ってきたからこそ、別の作り方の良いところも、面倒なところも、自分のサイトで試していきたいです。
