［新さくらのブログ〔有料〕］には記事のエクスポート機能がないようだ

動的CMSと静的サイトジェネレータ〔SSG〕の使い分け

• 動的CMSであるWordPressはアンセキュアであり、Hugo等の静的サイトジェネレータ〔ＳＳＧ〕のほうがセキュアである。
• 要は、WordPressはセキュリティ面で弱い、ということだ。
• Hugo等の静的サイトジェネレータで生成された記事は、HTML・CSS・JavaScriptだけしかなく、脆弱性を見つけるのが難しい。
• 動的CMSは、ログインやユーザー認証を伴う会員制サイト、ECサイト、SNSなど、ユーザーごとに異なる情報や操作が必要な場合に不可欠である。
• 一方、ブログのように一方的な情報発信が主体のサイトであれば、ＳＳＧで十分に対応可能である。
• ＳＳＧは、あらかじめHTMLページを生成して配信するため、以下の利点を提供する。
  • 高速な表示速度:アクセス時の動的処理が不要なため、表示が速くユーザー体験が向上する。
  • 高いセキュリティ:データベースや動的処理が存在しないため、攻撃リスクが極めて低い。
  • 運用コストの低減:サーバー負荷が低く、メンテナンスやアップデートの手間も少ない。
• 現代のSSGは、外部サービスやAPIとの連携により、フォームやコメント機能といった動的要素も実装可能である。したがって、ブログ運営に必要な双方向性も一定程度カバーできる。
• 静的サイトは［セキュリティ上の穴がほぼない］と評価される一方、動的CMSはその豊富な機能ゆえに、厳格な管理とセキュリティ対策が求められる。
• 結論として、単純な情報発信を目的とするサイトにはSSGの採用が技術的に妥当である。

動的CMSと静的サイトのセキュリティリスク

WordPressのような動的CMSは、PHPやMySQLといった多層的なソフトウェアによって構成されており、その複雑さゆえにセキュリティリスクを内包している。 不正アクセスや情報漏洩、サイト改ざんといった攻撃事例が多数報告されており、その脅威は現実のものである。

一方、HugoやJekyllといった静的サイトジェネレータが生成するウェブサイトは、実行時に動的な処理を伴わず、データベースも存在しない。 このため、攻撃対象が極めて少なく、実質的にはファイルサーバーとしてのみ機能する。 結果として、バックエンドの脆弱性を突かれるリスクは大幅に低減されるのである。

静的サイトの活用とCMSの適切な運用

したがって、保守・運用のリソースが限られている場合や、セキュリティを最優先する案件においては、静的サイトの選択が極めて合理的である。

ただし、大規模な動的コンテンツ管理やユーザー参加型機能が必須である場合、CMSの利用は不可避である。 その際は、徹底的なアップデートの実施、WAF〔Web Application Firewall〕の導入、不要なプラグインの排除といった、十分なセキュリティ対策を講じることが不可欠となる。

じつはWordPressで困るのはプラグインのセキュリティ

WordPressのプラグインは、善意のプラグインだけではない。 WordPressのプラグインそのものが、悪意をもって作られている危険性が否定できない。 プラグインの危険性を評価する手間だけでも、かなりバカバカしい。

［新さくらのブログ〔有料〕］には記事のエクスポート機能がないようだ

• これは新さくらのブログにエクスポートする機能がないので、今回の場合はそれしかないのだが20記事ほどなので今のうちの決定でもある。継続するなら移設するしかないという決定。

  引用元: 新さくらブログからWordPressへ - ポスト by ペコネット

• したがって、［新さくらのブログ〔有料〕］はおすすめできない。
• 更新料が安いXserverドメインで［.com］のドメインを取得して、HugoまたはWordPressでブログを運営するのが無難な線であると私は思う。

WordPressは、記事の更新だけは簡単だけれども、多面的な意味で非推奨

WordPressは、ブログの引っ越しをプロの業者に頼む必要がある

WordPressは記事の更新自体は容易であるが、サーバーAのWordPressからサーバーBのWordPressへの引っ越しや、他のCMSへの記事移行は技術的に難易度が高いことで知られている。

その理由は、WordPressが単なる静的ファイルではなく、コアシステム、データベース、テーマ、プラグインなど複数の要素で構成されているためである。

したがって、単にファイルをコピーしただけでは正常に動作せず、データベースの移行や設定の調整が必要となる。

サーバー間移行には以下のような手順が必要であり、特に技術的な専門知識が求められる。

1. 旧サーバーのWordPressファイル一式とデータベースをエクスポート・ダウンロードする。
2. 新サーバーにファイルをアップロードし、データベースをインポートする。
3. 新サーバーでの動作環境〔PHPやMySQLのバージョンなど〕を整え、設定の修正〔wp-config.phpのデータベース情報書き換えなど〕を行う。
4. 動作確認のためのhostsファイル編集など、ドメインに依存した設定を調整する。
5. DNS〔ネームサーバー〕設定の変更によるドメインの切り替えを行う。

このような作業は手動で行う場合、処理の中身が明確になるためトラブル発生時の原因特定がしやすいが、エンジニア向けの高難度作業である。

プラグインを利用して簡単に移行する方法も存在するが、それでも不具合発生のリスクがあり、移行先の環境に依存する問題も存在する。

また、WordPressから他のCMSへ記事を移行する場合は、WordPressのデータ構造と他CMSの仕様が異なるため、同様に技術的難易度が高く、専用ツールやカスタムスクリプトの作成などが必要となる。

以上のように、WordPressのブログやサイトのサーバー間移行、あるいは他CMSへの移行は単純ではなく、一定の技術的知識と手順の理解が求められるものである。

WordPressは更新に追われる

WordPressを運用していく上で避けて通れないのが［更新作業］である。 WordPressを使うには、MySQLの更新、PHPの更新、WordPress本体の更新、テーマの更新、そしてプラグインの更新など、複数の種類のアップデートが必要となる。 それぞれの更新には役割があり、サイトの安全性や機能性を維持・向上させるために非常に重要である。 しかし、それぞれの更新がサイト全体に影響を及ぼす可能性があるため、十分な理解と準備が求められる。

■MySQLの更新

WordPressのデータはすべてMySQLなどのデータベースに保存されている。 MySQLの更新によって、処理速度の向上やセキュリティホールの修正が行われる一方で、バージョンによっては古い構文や機能が非推奨・削除されることもある。 そのため、MySQLのバージョンアップに際しては、WordPressやプラグインが対応しているかどうかを事前に確認することが不可欠である。 つまり、WordPressが初心者向きだというのは［表向きの顔］にすぎず、WordPressを背景で支えるMySQLのことも、少しは勉強しなければならない。

■PHPの更新

PHPはWordPressの基盤となるプログラミング言語である。 最新のPHPに更新することで、処理の高速化や脆弱性の修正などのメリットが得られる。 しかし、古いテーマやプラグインが新しいPHPバージョンに対応していない場合、エラーが発生する可能性がある。 特に大きなバージョンアップ〔例：PHP 7.x→PHP 8.x〕では注意が必要で、更新前にテスト環境での動作確認が推奨される。 結局、WordPressを最新に保つために、WordPressが記述されている言語であるPHPをバージョンアップする必要がある。 しかし、新バージョンのPHPによって、WordPressが正常動作するか否かは、やってみるまでわからない、という問題がある。 WordPressを使うと、常にPHPのバージョンアップとWordPress本体の正常動作という危ない橋を渡らされる。

■WordPress本体の更新

WordPressのコア〔本体〕の更新は、新機能の追加、バグの修正、セキュリティ向上などを目的として定期的に行われます。 自動更新機能も備わっていますが、大きなバージョン変更では互換性の問題が発生することがあります。 特にプラグインやテーマが最新の本体に対応していない場合、レイアウトの崩れや動作不良の原因になります。 ここまでを振り返ると、MySQL・PHP・WordPress本体の３者が積み重なって、やっとWordPressが動くことがわかる。 しかしまだ安心できない。 WordPressの［デザイン］や［使い勝手の部分］を担当するテーマもまた更新されるからだ。

■テーマの更新

テーマの更新では、デザインの改善や機能追加、脆弱性の修正が行われる。 テーマはサイトの見た目だけでなく、内部の処理にも関わるため、更新内容によってはサイトのレイアウトやユーザーインターフェースに影響を及ぼすことがある。 また、テーマのカスタマイズを直接行っている場合、更新によって変更内容が上書きされてしまうこともあるため、子テーマの利用が推奨される。

WordPressにおける［テーマ］と［子テーマ］の関係

WordPressでは、テーマ〔親テーマ〕がサイト全体のデザインやレイアウト、基本的な機能を構成している。 ただし、テーマを直接カスタマイズしてしまうと、後でそのテーマにアップデートがあった際に、自分で加えた変更がすべて上書きされて失われてしまうというリスクがある。 この問題を回避するために使われるのが、［子テーマ］という仕組みである。 子テーマとは、親テーマの機能やデザインを継承しつつ、必要な部分だけを上書き・追加してカスタマイズできるサブテーマです。

親テーマの更新と子テーマへの影響

通常、親テーマを更新しても、子テーマで行ったカスタマイズは失われない。 これは、WordPressが子テーマを優先して読み込む仕組みになっているためである。

親テーマと子テーマとが不整合を起こすケース

しかし、以下のようなケースでは、親テーマと子テーマの関係性がうまく機能しなくなったり、意図した表示や動作をしなくなることがある：

ケース1：親テーマ側の構造が大きく変わった

親テーマのアップデートで、テンプレートファイルの構成や関数の定義方法が大幅に変わった場合、子テーマでオーバーライドしていたファイルやコードが機能しなくなることがある。 たとえば、親テーマのheader.phpにあった要素が新しいバージョンでは別ファイルに分割された場合、子テーマで旧構成を前提にしていると、表示が崩れる・読み込まれないといった不具合が起こる。

ケース2：親テーマの関数名やフック〔フィルター／アクション〕が変更された

親テーマが提供している関数やフィルター／アクションフックの名称が変更された場合、それを子テーマで利用・上書きしていたコードが正しく動作しなくなることがある。

ケース3：親テーマのスタイルシート〔CSS〕の構造が変更された

子テーマで親テーマのCSSを部分的に上書きしている場合、親テーマ側のCSSのクラス名や階層構造が変更されると、子テーマのスタイル指定が効かなくなることがある。

■プラグインの更新

プラグインはWordPressに様々な機能を追加する重要な要素ですが、最もトラブルが発生しやすいのもこのプラグインの更新である。 特に複数のプラグイン間での相性問題や、WordPress本体・PHPとの互換性の問題が原因で、サイトに不具合が起きるケースが少なくない。 そのため、更新前にはプラグインの変更履歴〔changelog〕を確認し、場合によってはテスト環境で動作検証を行なうと安心である。 ここまでを振り返ると、MySQL・PHP・WordPress本体・テーマ〔親テーマ／子テーマ〕・プラグイン〔複数ある〕の５者〔プラグインが複数あることを除く〕が積み重なって、やっとWordPressが動くことがわかる。 WordPressは、こうした重層的な構造の上に成り立っているので、そのメインテナンス〔更新と再調整〕は、バカバカしいほど面倒くさい。 私はかつて、Twenty Fourteenというテーマを使って、このサイトを維持していたけれども、更新が面倒くさいのでHugoでBlackburnというテーマを使うように切り替えた。

■Twenty Fourteen | WordPress テーマ | WordPress.org 日本語
■GitHub - yoshiharuyamashita/blackburn: A Hugo theme built using Yahoo's Pure CSS

■WordPressは複数のソフトウェアの累積的なサービスである

• MySQL→ごくたまに更新される
• PHP→ごくたまに更新される
• WordPress本体→ごくたまに更新される
• テーマ→たまに更新される
  • 親テーマ
  • 子テーマ
• プラグイン→しょっちゅう更新される〔複数のプラグインを入れるのが標準的〕
• WordPressは更新が面倒で、記事の執筆に集中できない。
• Hugoの場合は、記事全体を文字置換するなどが容易であり、ブログの引っ越しも容易である。

■更新作業における注意点

これらの更新は、基本的には機能の改善やセキュリティ対策のために必要不可欠である。 しかし、更新内容やその組み合わせによっては、予期せぬエラーや表示崩れ、機能停止といった問題を引き起こすことがある。 そのため、更新作業を行う際には以下の対応が非常に重要です。 事前のバックアップ〔ファイルとデータベース両方〕 ステージング環境〔検証環境〕での動作確認 更新内容の確認と記録 更新後の動作テストとログの確認 更新は［やれば終わり］ではなく、［安全に完了させること］が目的です。 面倒に感じるかもしれませんが、トラブルが発生してから対応するよりも、事前の準備に時間をかける方が結果的には効率的です。

まとめ

WordPressの更新作業は、サイトの安全性・機能性を保つために欠かせません。 しかし、更新による不具合のリスクも同時に存在するため、慎重かつ計画的な対応が求められます。 とくにプラグインの相性問題には細心の注意を払い、更新前のバックアップと動作確認を習慣化することが、安定した運用への第一歩となるでしょう。 必要であれば、この内容をブログ記事やマニュアル用にアレンジすることも可能です。 ご希望があればお知らせください。

Hugoは非力なサーバーでも大丈夫

• Hugoは、HTMLファイルをCSSでレイアウトし、JavaScriptで機能を付け加えたサイトを、並行処理で短時間に大量に出力するフリーウェアである。
• つまり、ふつうのHTMLファイルをサーバーに上げただけ〔静的サイト〕なので、動作が軽い。
• WordPressはPHPを使って、その場で記事を動的に生成しているので、動作が重たく、そのため、高性能なサーバーを必要とする。
• 現在のサーバーは、WordPressを動かす目的で、過剰に強化されており、そのために多大な電力を無駄にしているといえる。
• PHPを使った動的サイトというのは、ECサイト以外では、原則としてやめたほうがいい。
• AIによると、5000記事程度のサイトなら、Hugoでも、WordPressでも大丈夫であるようだ。
• ただし実際には、記事が5000もあると、WordPressは重たくなるので、相当な高性能サーバーを使わなければならない。
• Hugoは記事が5000あろうとも、静的サイトなので、記事数が多くからといって、重たくなるとはいえない。
• Hugoで重たくなるのは、記事が長い、記事に写真がたくさん貼ってある、などの場合である。
• ただし実際には、記事が5000もあると、記事が埋もれていく。
• これはYouTubeも同様であり、動画が1000もあり、適切なタグ付けがなされていないと、動画が埋もれていく。過去動画には、ほぼアクセスがない。
• 埋もれたYouTube動画を掘り起こすためには、自分でサイトを立ち上げ、１記事１動画の原則を貫くとともに適切なタグ付けをして、文字検索に応答する体制を敷く必要がある。
• さらにいえば、情報発信を動画で行なうことそれ自体が、情報拡散の効率を下げる。
• YouTube動画の再生数が伸びないのは、動画を消費するスピードが、動画の標準速の４倍速程度までが上限なので、人間〔視聴者〕の可処分時間を考慮すると、早い段階で可処分時間を使い切ってしまうからだ。
• またＡＩによる検索、ウェブ検索エンジンによる検索は、あくまでも文字ベースであるがゆえに、文字で検索されないコンテンツは、存在しないコンテンツ、という図式が成り立つ。
• 結局、情報発信はブログ記事を主軸として、動画はそのブログ記事のサブという位置づけにするのが正解であろう、ということになる。
• WordPressの使い方を勉強するよりも、Hugoの使い方を勉強したほうがラクであり、実質的であろうと私は思う。
• それはHugoが、あくまでもHTMLファイルを原則として、タグやカテゴリーやセクションを作り、静的サイトとしてのブログとしての体裁を整えるソフトウェアだからである。
• Hugoの記事〔以下がひな形〕は、Windowsの場合、［UTF8〔BOMなし〕、CR+LF］のMarkdown〔.md〕ファイルである。
• Hugoは結局、コンパイル型のソフトウェアで、必要な記事ファイル群〔Markdownファイルが中心〕を与えると、CPUのコア・スレッドを複数使うことで並列処理を行ない、何百という記事を１０秒以内に生成する仕組みである。
• Hugoを実行させると、CPUのファンがフォーンと回り、記事をたくさん生成するためにCPUがフル稼働していることがわかる。
• ゲーム用ほど強いCPUである必要はないけれども、第12世代のCore i5、最近のRyzen 5、最近のRyzen 7あたりは必要だと思う。
• 私のPCは旧型〔Core i7-6700K 4.00GHz〕なのでWindows 10のサポート終了にともない買い換える必要がある。それでもHugoは動いている。

+++
date = "2025-08-10T09:46:35+09:00"
slug = "2025-08-10-09-46-35-09-00"
categories = ["●●●カテゴリー"]
tags = ["●●●タグ"]
title = "●●●タイトル"
+++


## ●●●タイトル

無料ブログの問題点

• 【1】サービスが終了するリスクがある。
• 【2】自分のブログ記事が運営側の意向で突然消される心配が常にある。
  • 安定して長期間にわたり発信を続けたい場合は、安価な有料ブログサービスの利用が適切と考えられる。
  • 有料ブログサービスは、原則として、自分のブログ記事が運営側の意向で突然消される心配はない。
  • 有料ブログは運営の継続性が比較的確保されやすく、独自ドメインやバックアップ機能も充実していることが多く、安心して情報発信が可能である。

【1】サービスを終了した無料ブログ〔有名どころ〕｜2025-08-10T06:31:34+09:00

• 2009年
  • Doblog：5月30日終了、NTTデータ運営。システムの安定性問題やユーザー数の減少が背景。
  • livedoor nowa：3月31日終了、ライブドア運営。ライブドアブログへの統合が主な理由。
• 2010年
  • CURURU：3月31日終了、運営はNTTレゾナント。ソーシャル要素を重視したサービスだったが、需要低下で終了。
• 2011年
  • Windows Live Spaces：3月31日終了、マイクロソフト運営。WordPress.comへの移行を推奨し、ブログ機能は終了。
  • au oneブログ：3月31日終了、KDDI運営。モバイル向けブログサービスとして展開したが、競争激化で終了。
• 2012年
  • pixivブログ：2月29日終了、pixiv運営。イラスト投稿プラットフォームへの特化に伴い終了。
  • ワブログ：7月31日終了、運営は不明〔おそらくGMO関連〕。情報が少なく、マイナーなサービス。
  • maglog：5月17日終了、ベクター運営。ゲーム関連のブログサービスだったが、利用低迷で終了。
• 2013年
  • COGブログ：6月27日終了、カプコン運営。ゲームファン向けだったが、運営コストの課題で終了。
  • フォレストブログ：6月25日終了、運営はフォレストページ。無料ブログの競争激化で終了。
• 2014年
  • OCNブログ人：11月30日終了、NTTコミュニケーションズ運営。ユーザー数の減少と運営方針変更が理由。
  • LOVELOG：6月30日終了、KDDI運営。au oneブログの後継サービスだったが、短期間で終了。
• 2019年
  • Yahoo!ブログ：12月15日終了、Yahoo! JAPAN運営。Yahoo!知恵袋の終了と同時期に、サービス縮小の一環で終了。
  • はてなダイアリー：2月28日終了、はてな運営。はてなブログへの統合を目的に終了。
  • Decooブログ：9月2日終了、Decoo運営。モバイル向けサービスだったが、利用者減少で終了。
• 2020年
  • ヤプログ!：1月31日終了、GMOメディア運営。長期間運営されたが、SNS台頭で終了。
  • 魔法のiらんどブログ：3月31日終了、KDDI運営。ケータイ小説ブームの立役者だったが、時代変化で終了。
• 2022年
  • CROOZブログ：5月31日終了、クルーズ運営。ギャル文化と結びついたが、SNS人気に押され終了。
• 2023年
  • ウェブリブログ：1月31日終了、BIGLOBE運営。長寿サービスだったが、運営コストと需要低下で終了。
  • Decolog：9月1日終了、ミツバチワークス運営。女性向けだったが、InstagramなどSNSにシェアを奪われ終了。
  • LINE BLOG：6月29日終了、LINE運営。有名人向けプラットフォームだったが、収益性の問題で終了。
• 2025年
  • SSブログ：3月31日終了、Seesaa運営。事業終了に伴いサービス終了。
  • gooブログ：11月18日終了予定、NTTレゾナント〔NTTドコモ傘下〕運営。長期間運営されたが、サービス縮小で終了予定。