ブログを書いていると、記事の内容と同じくらい「見た目」が読者の印象を左右すると感じることがあります。その中でも特に影響が大きいのがアイキャッチ画像と配色です。

今回はこの2つのテーマについて、実際の色を使いながら整理してみました。

アイキャッチはなぜ重要か

「画像なんてなくても記事の内容が良ければいい」と思っていた時期もありましたが、実際はそうではありませんでした。

SNSシェア時のOGP画像になる

XやFacebookでブログのURLをシェアしたとき、表示されるカード画像がアイキャッチです。このカード画像のことをOGP（Open Graph Protocol）画像と呼びます。画像ありとなしでは、クリック率に明らかな差が出ます。WordPressにSEOプラグインを入れておけば、アイキャッチを設定するだけで自動的にOGP画像として使われる仕組みになっています。

ブログ内の回遊性に直結する

WordPressのテーマによっては、記事一覧がカード型で表示されます。このとき各カードに表示されるのがアイキャッチです。魅力的な画像があるほど「次もこの人の記事を読もう」となりやすいです。

ブログのブランド統一感をつくる

毎記事で配色やデザインに一貫性があると、読者に「このブログらしさ」が伝わります。継続して読んでもらうための地盤にもなります。

「いいな」と感じる配色の6原則

配色は個人のセンスによるところが大きいと思われがちですが、実際には知っているか知らないかの差の方が大きいと感じています。原則を押さえるだけで、見た目の印象は大きく変わります。

① 60-30-10ルール（黄金比率）

使う色の面積比を「メイン60%：サブ30%：アクセント10%」にすると、画面全体が自然と落ち着きます。

特にアクセントカラーは「小さく使うほど効く」というのがポイントです。目立たせたい要素にだけ使うことで、視線を自然に誘導できます。

② 彩度レベルを統一する

複数の色を組み合わせるとき、鮮やかな色と淡い色が混在すると落ち着かない印象になります。彩度のレベルを揃えるだけで、一気に統一感が出ます。

③ 色温度で「雰囲気」を決める

暖色・寒色・中性色にはそれぞれ伝わる印象があります。記事の内容と色温度を合わせると、読者が感じるトーンと実際の中身がズレなくなります。

④ テキストのコントラストを確保する

背景色と文字色の差が小さいと、内容が読めません。特にアイキャッチに文字を入れる場合は、コントラスト比の確保が必須です。

目安はWCAG（ウェブアクセシビリティのガイドライン）のAA基準である4.5:1以上です。迷ったら白か黒の文字を選ぶのが最も確実です。

⑤ 使う色は3色まで

色が多いほど散漫な印象になります。メイン・サブ・アクセントの3色に絞るだけで、まとまりが生まれます。

⑥ 白・グレー・黒を積極的に使う

無彩色は「どんな色とも喧嘩しない」という特性があります。迷ったらベースを白やグレーにして、1〜2色だけ差し色にするのが最短の解決策です。

参考になる本の紹介

配色を自力で考えるのはなかなか大変です。そんなときに役立つ本を紹介します。

　Color Design　（株）KADOKAWA(Googleリンク)

本とCanvaの間の小さなギャップ

この本に掲載されているカラー数値はRGB形式（例：R=83, G=74, B=183）です。一方CanvaでカスタムカラーはHEX形式（例：#534AB7）での入力が必要になります。

変換はGoogleの検索窓に以下のように入力するだけです。

検索結果の一番上に変換結果が表示されるので、コピーしてCanvaに貼るだけです。

まとめ

アイキャッチと配色についてまとめると、こうなります。

配色は「センス」という言葉で片付けてしまいがちですが、実は体系化されたルールがあります。原則を知ったうえで配色の見本帳を活用すれば、ブログのアイキャッチのクオリティは着実に上がっていくと感じています。

COLOR DESIGN カラー別配色デザインブック

¥2,200 （2026/05/03 07:50時点 | Amazon調べ）

Amazon

ポチップ

もくじ

1. はじめに
2. 会社でのファイル管理：連番＋アンダーバーの使い方
3. WordPressのスラッグはどうする？
4. AIに聞いてみた：ハイフンとアンダーバーの違い
5. まとめ：用途別の使い分けルール

Ⅰ. はじめに

ファイルの名前をつけるとき、単語の区切りに何を使っていますか？

よく使われるのが 「_（アンダーバー）」 と 「-（ハイフン）」 の2種類です。どちらも見た目はよく似ていますが、実は用途によって「正解」が違うことがわかりました。

今回は、会社のファイル管理やWordPressのスラッグを例に、この2つの使い分けについて整理してみました。

Ⅱ. 会社でのファイル管理：連番＋アンダーバーの使い方

会社でファイルを保存するとき、こんな名前をつけることが多いのではないでしょうか。

先頭に 「01_」「02_」のような連番 をつけることで、フォルダ内の並び順が崩れません。これはWindowsでもMacでも有効な整理方法で、多くの職場で自然と定着しています。

ここでアンダーバーが使われているのには理由があります。ファイル名にスペースを入れると、システムやスクリプトで扱う際にエラーの原因になることがあります。アンダーバーはスペースの代わりとして、ほぼあらゆる環境で安全に使えます。

Ⅲ. WordPressのスラッグはどうする？

WordPressでブログを書いていると、各記事に 「スラッグ（slug）」 を設定する場面があります。スラッグとは、記事URLの末尾に使われる文字列のことです。

以前の記事でも確認しましたが、スラッグは 短い英単語の組み合わせ がSEO上有利とされています。では複数の単語をつなげるとき、ハイフンとアンダーバーのどちらを使うべきか——ここで迷いが生じました。

Ⅳ. AIに聞いてみた：ハイフンとアンダーバーの違い

この疑問をAIに確認したところ、明確な答えが返ってきました。

URLにはハイフン、ファイル名にはアンダーバー

■ URLでハイフンが推奨される理由

Googleの検索エンジンは、ハイフンを「単語の区切り」として認識します。一方、アンダーバーでつないだ場合は、全体をひとつの単語として扱ってしまいます。

color-laser-printer　→「color」「laser」「printer」と3語に分解
color_laser_printer　→「colorlaserprinter」と1語扱い

SEOの観点では、ハイフン区切りの方が検索キーワードとマッチしやすく、有利になります。

■ ファイル名でアンダーバーが推奨される理由

ファイル名でハイフンを使うと、シェルスクリプトやプログラムで扱う際に「マイナス演算子」や「コマンドのオプション」と混同されるリスクがあります。

rm -myfile　→「-myfile」がオプションと誤認される可能性
rm my_file　→ 問題なく動作する

アンダーバーはほぼすべての環境で安全に使えるため、ファイル名では迷わずアンダーバーを選ぶのが無難です。

■ エラーになりやすいのはどちら？

ハイフンは変数名や関数名には使えない（Pythonなどではエラー）、コマンドラインでオプションと混同されるなど、場面によってリスクがあります。アンダーバーはほぼあらゆる場面で安全です。日常的なファイル整理では、アンダーバーの方が扱いやすいといえます。

Ⅴ. まとめ：用途別の使い分けルール

今回の調査で、用途ごとの使い分けがはっきりしました。

「ファイル名はアンダーバー、URLはハイフン」——この2つを覚えておくだけで、迷う場面がぐっと減りそうです。小さなことですが、知っておくと地味に役立つ知識でした。

ブログを立ち上げてしばらく経ったころ、「そういえばアクセス数ってどうやって確認するんだろう？」と気になり始めました。調べてみると、GoogleアナリティクスやSearch Consoleというツールの存在を知り、さらにGA4という新しい仕組みがあることもわかりました。

この記事では、それぞれのツールの違いを整理したうえで、ara-garage.com への実際のセットアップ手順をまとめました。同じような疑問を持っている方の参考になれば幸いです。

①ブログを立ち上げて気づいたこと

ara-garage.comを開設し、記事を書き始めてしばらくしたころ、ふと「どれくらいの人が読んでくれているんだろう？」と気になりました。記事を投稿しても反応がわからないのは少し心もとないものです。

調べてみると、Googleが無料で提供しているアクセス解析ツールがあることを知りました。その名も Google アナリティクス。さらに深掘りすると Search Console や GA4 という言葉も出てきて、最初は「どれが何なの？」と混乱しました。

②3つのツールの違いをざっくり理解する

まず整理しておきたいのが、それぞれのツールの役割の違いです。

簡単にまとめると、次のような違いになります。

③料理店で例えるとわかりやすい

ツールの違いをイメージしやすくするために、飲食店に例えてみます。

• GA4：お店の中に設置した監視カメラ。お客さんが来店後、どのテーブルに座り、何を注文し、どのくらい滞在したかがわかります。
• Search Console：お店の外にある看板や口コミ。どんなキーワードでお客さんが店を見つけたか、何人が看板を見てドアを開けたかがわかります。

両方あってはじめてブログの全体像が見えてくる、というわけです。

④ara-garage.comへのGA4設定

ara-garage.comはWordPressで構築しており、SEO SIMPLE PACKというプラグインを通じてすでにGA4のトラッキングタグが設置されていました。

GA4の管理画面でデータストリームを確認したところ、「過去48時間にトラフィックデータを受信しています」と表示されており、正常にデータが収集されていることが確認できました。

⑤Search ConsoleとGA4を連携する

Search Consoleはすでにara-garage.comに設定済みでしたが、GA4との連携はできていませんでした。連携することで、GA4の画面内でSearch Consoleのデータも一緒に確認できるようになります。

設定手順はとても簡単でした。

1. GA4管理画面 → 「サービス間のリンク設定」→「Search Console のリンク」
2. 「リンク」ボタンをクリック
3. Search Consoleのプロパティ（https://www.ara-garage.com/）を選択
4. ウェブストリーム（myblog）を選択
5. 「送信」で完了

設定完了後、「リンク作成済み」と表示されて無事に連携できました。

⑥これから確認できるようになること

GA4とSearch Consoleの連携が完了したことで、今後は以下のようなデータをGA4の画面だけで確認できるようになります。

• どんなキーワードで検索してブログに来たか
• どの記事が検索流入を集めているか
• クリック率・表示回数・検索順位の推移
• 訪問者数・滞在時間・デバイスの内訳

データは蓄積されるほど精度が上がります。しばらく運用しながら、どんな記事が読まれているかを確認しつつ、コンテンツの改善に活かしていきたいと思います。

はじめに ― Google Site KitでページタイトルがUnknownになっていた

ブログのアクセス状況を確認しようと、WordPress管理画面に入れているGoogle Site Kit（GA4連携プラグイン）を眺めていたところ、ページタイトルの一覧に不思議な表示を見つけました。

上位ページのほとんどはタイトルが正しく表示されているのに、1件だけ「(unknown)」となっていたのです。

該当のURLを確認すると、以前書いた「家庭の電気のしくみ」の記事でした。記事自体はきちんと公開されていて、アクセスも来ている。それなのになぜタイトルが取得できていないのか――そこから調べてみることにしました。

スラッグとは何か ― URLの末尾を決める識別子

調べるうちに浮かび上がったのが「スラッグ（slug）」というWordPressの設定項目でした。

スラッグとは、記事のURLの末尾部分のことです。たとえばこのブログであれば：

赤字の部分がスラッグです。URLを見ただけで記事の内容がわかるようにするためのもので、SEO的にも意味があるとされています。WordPressでは何も設定しないと、投稿タイトルがそのままスラッグとして使われます。タイトルが日本語であれば、スラッグも日本語になる――これが今回の問題の根本でした。

日本語スラッグが引き起こす問題 ― エンコードとGA4の誤認

URLに日本語をそのまま使うことは、技術的には推奨されていません。ブラウザやサーバーの内部では、日本語をパーセントエンコーディングと呼ばれる形式に自動変換して処理しています。

見た目はこうでも：

実際にシステムが処理するURLはこうなります：

この長い文字列を受け取ったGoogleアナリティクス（GA4）が、ページタイトルを正しく識別できなくなり、結果として「(unknown)」と表示されていたのです。さらに今回のスラッグには全角の縦線（｜）も含まれており、特殊文字の混在がGA4の誤認をより起きやすくしていました。

既存記事はどうする？ ― 変更リスクと判断基準

原因がわかったところで、「では今ある記事のスラッグを全部直すべきか？」という疑問が出てきました。

結論から言えば、基本的には既存記事のスラッグは変更しない方が無難です。スラッグを変えるとURLが変わるため、次のようなリスクが生じます。

• Googleが積み上げた評価がリセットされる可能性がある
• SNSでシェアしたリンクが無効になる
• 外部サイトからのリンクが404エラーになる

ただし今回の「電気のしくみ」記事は、公開からまだ日が浅く、SNSシェアも少ない状況でした。こういった場合はスラッグを英数字に変更してリダイレクト設定を行う価値があります。

スラッグ変更を検討してよいケース
・Googleアナリティクスでunknownが出ている
・公開から日が浅い（1〜2週間以内）
・SNSシェアがまだほとんどない

パーマリンク設定で自動化できないか検討した

「毎回手動で変えるのは面倒だ。WordPressの設定で日付や連番に自動変更できないか？」とも考えました。

WordPressには「設定 → パーマリンク」でURLの形式を変える機能があります。日付ベース（/2026/04/18/記事名/）や連番（/archives/123）なども選択できます。しかし調べてみると、これらはSEO的に推奨されない形式でした。

• 日付入りURL：時間が経つと「古い記事」と判断されやすくなる
• 連番URL：URLから内容がまったくわからない

パーマリンク設定自体を変えると全記事のURLが変わる影響があり、現実的ではありませんでした。今の「投稿名」形式のままにして、運用で解決する方が賢明という結論に至りました。

結論 ― 今後は公開前に手動で英数字スラッグを設定する

調べた結果、一番シンプルで確実な解決策は「公開前にスラッグを手動で英数字に書き換える」習慣をつけることでした。作業自体は30秒もあれば終わります。

スラッグの命名ルールは英数字とハイフンのみ・スペースなし・短めが基本です。たとえば「家庭の電気のしくみ」であれば katei-denki-shikumi のように設定します。記事数がまだ少ない今のうちに習慣化しておくと、あとで困らなくて済みます。

まとめ

Googleアナリティクスで「(unknown)」と表示されていた原因は、WordPressのスラッグに日本語が使われていたことでした。日本語URLはシステム内部でエンコードされ、GA4がページタイトルを正しく取得できなくなっていたのです。

• 既存記事は原則そのまま（URLを変えるリスクの方が大きい）
• 公開直後でGA4に問題が出ている記事は、英語スラッグに変更＋リダイレクト設定
• 今後の新記事はすべて公開前に英数字スラッグを手動設定する

地味な設定項目ですが、SEOやアクセス計測の精度に直結する大事なポイントでした。同じ状況になっている方の参考になれば幸いです。

目次

1. はじめに ─ ある日突然、管理画面にエラーが出た
2. エラーの内容 ─ Past-dueとは何か
3. WP Cronとは何か？
4. なぜ自宅NASで問題が起きやすいのか
5. 予約投稿が公開されなかった原因もこれだった
6. 一時的な解決策 ─ 手動実行する手順
7. 根本的な解決策 ─ cron-job.orgの設定
8. 設定結果の確認
9. おわりに

はじめに ─ ある日突然、管理画面にエラーが出た

自宅のSynology NASでWordPressを運用していると、ある日WordPress管理画面を開いたときに見慣れないエラー表示が出ていました。

画面には「Past-due」という表示とともに、見慣れない英語のアクション名が並んでいました。特に何か操作をした覚えもないのに、なぜこのようなエラーが出るのか、最初はまったく原因がわかりませんでした。

今回はこのエラーの原因を調べていくうちに、予約投稿が動いていなかった問題の原因まで同時に判明した経緯をご紹介します。

エラーの内容 ─ Past-dueとは何か

表示されていたエラーは以下のものでした。

これはWordPressのプラグイン管理機能「Action Scheduler」が処理すべきタスクを抱えたまま、実行されずに期限切れ（Past-due）になっている状態を示していました。

管理画面の「ツール」→「スケジュールされたアクション」→「Past-due」タブを開くと、このアクションが1件溜まっているのが確認できました。

WP Cronとは何か？

このエラーを理解するために、まず「WP Cron」という仕組みを知っておく必要がありました。

WP Cronとは、WordPressに組み込まれている「定期処理の仕組み」のことです。具体的には以下のような処理を自動で行っています。

WP Cronが担っている主な処理

• 予約投稿の自動公開
• プラグインの自動更新チェック
• Action Schedulerのキュー処理
• UpdraftPlusなどバックアッププラグインの定期実行

要するに、WordPressが「時間になったら自動でやっておく」と約束している処理は、すべてWP Cronが動いていることが前提になっていました。

なぜ自宅NASで問題が起きやすいのか

実はWP Cronには、一般的なレンタルサーバーとは異なる重大な特性がありました。

WordPressのWP Cronは、本来「誰かがサイトにアクセスしたタイミング」でこっそり裏側で処理を走らせる仕組みです。

自宅NASで運営している個人ブログはアクセス数が多くないため、何日もアクセスがない期間が続くと処理が溜まり続け、Past-dueエラーとして表面化することがわかりました。

予約投稿が公開されなかった原因もこれだった

このWP Cronの仕組みを理解したとき、「そういえば予約投稿が公開されていなかったことがあった」という記憶が蘇りました。

予約投稿の公開もWP Cronが担っています。つまり、WP Cronが動いていなければ、指定した時刻になっても記事は「予約中」のまま公開されません。

WP Cronが止まっていると起きること

• 予約した記事が時刻になっても公開されない
• Action Schedulerのアクションが溜まりPast-dueエラーになる
• バックアッププラグインが予定通り動かない
• プラグインの更新通知が遅れる

自宅NASブログで「予約投稿がなぜか反映されない」という経験がある方は、WP Cronが正しく動いていない可能性が高いです。

一時的な解決策 ─ 手動実行する手順

まず溜まっているPast-dueアクションを手動で実行して、エラーを消す作業を行いました。

手動実行の手順

1. WordPress管理画面にログイン
2. 「ツール」→「スケジュールされたアクション」を開く
3. 「Past-due」タブをクリック
4. 一覧に表示されたアクションにカーソルを合わせる
5. 表示された「実行」をクリック
6. Past-dueタブが空になればOK

実行後、Past-dueタブには「項目は見つかりませんでした。」と表示され、エラーは消えました。ただしこれはあくまでその場しのぎの対処であり、根本的な原因は解決していませんでした。

根本的な解決策 ─ cron-job.orgの設定

根本的な解決のために、外部サービス「cron-job.org」を使ってWordPressのCronエンドポイントを定期的に叩く設定を行いました。

cron-job.orgは無料で使えるCron実行サービスで、指定したURLを決まった間隔で自動アクセスしてくれます。

設定内容

• URL：https://www.***
• 実行間隔：15分おき
• タイムゾーン：Asia/Tokyo

この設定により、誰もブログにアクセスしていない時間帯でも、15分ごとにWP Cronが確実にトリガーされるようになりました。予約投稿の公開遅れや、Action Schedulerのエラーが再発しない環境が整いました。

設定結果の確認

設定後、最初の実行タイミングを待ってcron-job.orgの実行履歴を確認しました。

実行結果

• ステータス：Successful / 200 OK
• 処理時間：約1.95秒
• 以降15分おきに自動実行を継続

緑のチェックマークとともに「200 OK」が返ってきており、WP-Cronが正常にトリガーされていることが確認できました。

おわりに

今回の件で改めて実感したのは、自宅NASでのWordPress運用はレンタルサーバーとは異なる落とし穴があるということでした。

レンタルサーバーであれば当たり前に動いているWP Cronも、アクセス数の少ない自宅NASブログでは自力では動けない状況になっていました。

「予約投稿が動かない」「管理画面にエラーが出る」といった症状が出たときは、まずWP Cronの動作確認を疑ってみるのが近道だと思います。cron-job.orgの設定は無料でできますので、同じ環境で運用している方はぜひ試してみてください。

1. はじめに

自宅のNAS（Synology）でWordPressブログを運営しています。しばらくの間、SynologyのDDNSドメイン ara-garage.synology.me のままブログを公開していました。

「自分でサーバーを立てているし、まぁこれでいいか」と思っていたのですが、ふと気になったのが SEOへの影響 です。独自ドメインと比べてDDNSドメインは検索エンジンにどう評価されるのか、調べていくうちに独自ドメインへの切り替えを決意しました。

2. DDNSドメインとは？

DDNSとは Dynamic DNS（ダイナミックDNS） の略です。自宅のインターネット回線はプロバイダーから割り当てられるIPアドレスが定期的に変わります。そのたびにDNSの設定を自動で更新してくれる仕組みがDDNSです。

SynologyのNASを使っている場合、無料で ○○.synology.me というドメインが取得できます。設定も簡単で、NASのDSMから数クリックで完了しました。自宅サーバーを手軽に外部公開できる便利な機能です。

3. DDNSドメインとSEOの関係

DDNSドメインがSEOに不利とされる理由はいくつかあります。

独自ドメインであれば、これらの問題をすべて解決できます。長期的にブログを育てていくなら、早めに切り替えるほうが有利と判断しました。

4. 独自ドメインへの切り替え手順（概要）

実際に行った作業の流れをざっくりまとめます。

1. 独自ドメインの取得
   ドメイン登録サービスで .com ドメインを取得しました。
2. DNS設定
   取得したドメインのDNS設定で、自宅のIPアドレス（またはDDNSのCNAME）を指定しました。
3. WordPressのURL設定変更
   WordPress管理画面の「設定 → 一般」から、サイトURLを新しい .com ドメインに変更しました。
4. リバースプロキシの設定（Synology DSM）
   SynologyのDSMでリバースプロキシを設定し、新しいドメインへのアクセスをWordPressに正しく転送されるようにしました。
5. 動作確認
   ブラウザから新しいドメインでアクセスし、正常に表示されることを確認しました。

今回はClaudeにも手順を相談しながら進めましたが、スムーズに設定を完了することができました。

5. 切り替え後の変化・感想

切り替えてすぐに劇的な変化があったわけではありませんが、まずURLがすっきりして 見た目の信頼感が上がった のを実感しました。

また、Googleサーチコンソールに新しいドメインを登録し直すことで、今後のSEO効果がしっかりと新ドメインに蓄積されていく環境が整いました。

自宅サーバーでここまでできるのか、という達成感もありました。NASをフル活用している実感が持てた作業でした。

6. まとめ

DDNSドメインは手軽に使えて便利ですが、ブログを長期的に育てる観点からは独自ドメインへの切り替えをおすすめします。

• SEO評価が独自ドメインに蓄積される
• 訪問者からの信頼感が向上する
• ドメインの継続性・安定性が増す