ただ一方で、PC表示のときに
・クリックしても意味がない
・誤ってクリックされる
・リンク色や下線が不自然
と感じたことはないでしょうか。

この記事では、
「スマホでは電話リンクを有効にし、PCでは無効にする方法」をHTMLは変えず、CSSだけで実現する方法を解説します。

※コードに関するご質問や修正の依頼はお受けいたしかねます。
　もし、修正が必要ならChatGPTに聞くのが良いです。

やりたいことの整理

まず、今回実現したい状態を整理します。

・スマホ表示
　→ 電話番号をタップすると発信できる

・PC表示
　→ 電話番号は表示されるが、クリックできない
　→ 見た目も普通の文字と同じにする

この条件を満たす方法を考えます。

HTML

HTMLは、よくある電話リンクの形です。

<a class="tel-number" href="tel:09000000000">090-0000-0000</a>

<a class="tel-number" href="tel:09000000000">090-0000-0000</a>

ポイントは、
class に tel-number を付けていることです。

この class を目印にして、CSSで制御します。

CSS

/* PC表示のときだけ電話リンクを無効化 */
@media screen and (min-width: 768px) {
  a.tel-number {
    pointer-events: none;   /* クリック無効 */
    color: inherit;         /* 文字色を通常の文字と同じに */
    text-decoration: none;  /* 下線を消す */
    cursor: default;        /* マウスカーソルを普通に */
  }
}

/* PC表示のときだけ電話リンクを無効化 */
@media screen and (min-width: 768px) {
  a.tel-number {
    pointer-events: none;   /* クリック無効 */
    color: inherit;         /* 文字色を通常の文字と同じに */
    text-decoration: none;  /* 下線を消す */
    cursor: default;        /* マウスカーソルを普通に */
  }
}

CSSの内容をひとつずつ解説

min-width: 768px
→ 画面幅が768px以上のとき（PC・タブレット想定）だけ適用されます。

pointer-events: none
→ クリックやタップを受け付けなくします。
　これにより、PCでは電話リンクが無効になります。

color: inherit
→ 親要素と同じ文字色にします。
　リンク特有の青色を消すためです。

text-decoration: none
→ リンクの下線を消します。

cursor: default
→ マウスを乗せたとき、指マークではなく通常の矢印にします。

考え方（なぜCSSでできるのか）

スマホとPCの違いは「画面の横幅」です。

CSSには
「画面幅が〇px以上のときだけ、このスタイルを適用する」
という指定ができます。

この仕組み（メディアクエリ）を使えば、

・画面が小さい → スマホ想定
・画面が大きい → PC想定

として、見た目や挙動を切り替えられます。

スマホではどうなるのか

このCSSは
「画面幅が768px以上のときだけ」効きます。

そのため、

・スマホ表示
　→ CSSは適用されない
　→ tel:リンクはそのまま有効

という状態になります。

HTMLを分けたり、JavaScriptを使う必要はありません。

画面幅の調整について

768px は一例です。

例えば、
・PCのみを対象にしたい場合 → 1024px
・タブレットも含めたい場合 → 768px

など、サイトに合わせて調整できます。

まとめ

・HTMLはそのまま
・CSSだけでスマホとPCの挙動を切り替え可能
・スマホでは電話リンク有効
・PCではクリック無効＆見た目も自然

電話番号を安心して掲載したい場合、
シンプルで使いやすい方法なのでおすすめです。

The post PCでは無効・スマホでは有効にする電話リンクの作り方（CSSだけで対応） first appeared on hiro's note.

必要な方がいらっしゃいましたらお気軽にご利用ください。

動作としては、特定のidに差し掛かったら自動的に表示されるという動きです。

※コードに関するご質問や修正の依頼はお受けいたしかねます。
　もし、修正が必要ならChatGPTに聞くのが良いです。

実際の動き

右側の部分をスクロールすると、セクション２に差し掛かったタイミングでLINEに送るためのブロックが表示されます。

See the Pen Untitled by sakabonji (@-hiro60) on CodePen.

HTML

<!--  LINEに送る  -->
    <div class="line-reminder line-reminder--mobile">
        <button type="button" class="line-reminder__close" aria-label="このメッセージを閉じる">×</button>
        <p class="line-reminder__title">
            見出し的な部分
        </p>
        <p class="line-reminder__text">
            説明的な部分
        </p>
        <a
                href="LINEのシェアURL"
                class="line-reminder__button"
                target="_blank"
                rel="noopener"
        >
            LINEで自分に送る
        </a>
        <p class="line-reminder__note">
            ※ご自身のLINEに、このページのURLだけが送信されます。こちらから営業メッセージが届くことはありませんのでご安心ください。
        </p>
    </div>

CSS

/* =====================
 LINEに送る
 ===================== */
/* 基本は非表示にしておく（PCなど） */
.line-reminder {
    display: none;
}

/* スマホでだけ表示 */
@media (max-width: 768px) {
    .line-reminder--mobile {
        display: block;
        padding: 14px 16px 12px;
        background-color: #fff;
        border-radius: 12px;
        border: 1px solid #e5e5e5;
        box-shadow: 0 4px 12px rgba(0, 0, 0, 0.08);
        font-size: 13px;
        line-height: 1.6;
        box-sizing: border-box;
        opacity: 0;
        transform: translateY(20px);
        pointer-events: none;
    }

    .line-reminder__title {
        margin: 0 0 6px;
        font-size: 14px;
        font-weight: 600;
    }

    .line-reminder__button {
        display: block;
        padding: 10px 14px;
        text-align: center;
        font-size: 13px;
        font-weight: 600;
        text-decoration: none;
        border-radius: 999px;
        background-color: #06c755; /* LINEっぽいグリーン */
        color: #ffffff;
        box-shadow: 0 3px 8px rgba(0, 0, 0, 0.12);
    }

    .line-reminder__button:hover {
        opacity: 0.95;
    }

    .line-reminder__button:active {
        transform: translateY(1px);
        box-shadow: 0 2px 5px rgba(0, 0, 0, 0.16) inset;
    }

    .line-reminder__note {
        margin: 0;
        font-size: 11px;
        color: #777777;
    }

    .line-reminder__close {
        position: absolute;
        top: 6px;
        right: 8px;
        border: none;
        background: transparent;
        font-size: 16px;
        line-height: 1;
        padding: 0;
        color: #999;
    }

    .line-reminder__close:active {
        transform: scale(0.95);
    }

    /* is-floating 状態では position: fixed で画面下に固定される */
    .line-reminder--mobile.is-floating {
        position: fixed;
        left: 12px;
        right: 12px;
        bottom: 12px;
        margin: 0;
        z-index: 50;
        opacity: 0;
        transform: translateY(16px);
        transition: opacity 1.00s ease, transform 1.00s ease;
        pointer-events: none;
    }

    .line-reminder--mobile.is-floating.is-visible {
        opacity: 1;
        transform: translateY(0);
        pointer-events: auto;
    }
}

JavaScript

// LINEに送るブロック
document.addEventListener('DOMContentLoaded', function () {

    const reminder = document.querySelector('.line-reminder--mobile');
    const trigger = document.getElementById('表示基準となるid名');

    // 安全チェック
    if (!reminder || !trigger) return;

    // スマホのみ
    if (window.innerWidth > 768) return;

    // まず固定表示モードにする（透明）
    reminder.classList.add('is-floating');

    let shown = false;

    function checkShow() {
        if (shown) return;

        const triggerRect = trigger.getBoundingClientRect();
        const winHeight = window.innerHeight;

        // 表示基準となるid名の上部が画面内に少し入ったら表示
        if (triggerRect.top < winHeight - 50) {
            reminder.classList.add('is-visible');
            shown = true;
        }
    }

    // スクロール時にチェック
    window.addEventListener('scroll', checkShow, { passive: true });

    // リロード後の位置でもチェック
    checkShow();

    // ×ボタンで閉じる
    const closeBtn = reminder.querySelector('.line-reminder__close');
    if (closeBtn) {
        closeBtn.addEventListener('click', function (e) {
            e.preventDefault();
            reminder.classList.remove('is-visible');
        });
    }
});

The post 特定の位置で「LINEに送るブロック」を表示 first appeared on hiro's note.

プラグインでできる作業ではありますが、何かしら制限で導入できない場合は、自分でPHPで実装する必要があります。

ChatGPTに確認しながらコードを実装したので備忘録として残しておきます。

もし、同じ状況にある人でPHPで実装する必要がある場合は参考になると嬉しいです。

できること

• 投稿の編集画面に「キャンペーン終了日」を入力する欄が出ます。
• その日時になると自動で非公開（private）に切り替わります。
• ついでにタイトルの末尾へ「（YYYYMMDD非公開）」を一度だけ追記します。
  例）多言語化について（20251227非公開）

前提と注意

テーマの子テーマの functions.php に追記して使います
もし、親テーマに直書きする場合はアップデートで消えます。
特に理由がなければ子テーマで実装してください。

WordPressのタイムゾーンは「設定 → 一般」で正しく設定（日本なら東京）。

WP-Cronを使用。
これはあらかじめ予定していたイベントを「誰かがサイトへアクセスしたとき」に動かす仕組み。
確実にしたいならサーバーのcronで wp-cron.php を定期実行する必要があるそうです。

キャッシュ系プラグイン（WP Super Cache）を使っていたのですが、一覧に古い表示が残ることがありました。
設定で記事の更新のタイミングでキャッシュ削除を行うように変更しました。

完成コード（コピペOK・子テーマの functions.php に貼る）

/**
 * キャンペーン投稿の自動非公開化 & タイトル自動追記
 *
 * 概要:
 *  - 投稿編集画面に「キャンペーン終了日（datetime）」メタボックスを追加します。
 *  - 保存時に終了日時を投稿メタへ保存し、WP-Cron の単発イベントをスケジュールします。
 *  - 終了日時に達したら自動的に該当投稿を「非公開 (private)」へ変更し、
 *    タイトル末尾に「（YYYYMMDD非公開）」を一度だけ付与します（重複追記を防止）。
 *  - 終了日時が過去の場合は保存直後に即時処理されます。
 *
 * 主なフック:
 *  - add_meta_boxes: 終了日時入力UI（メタボックス）を追加
 *  - save_post: 終了日時の保存／WP-Cron 単発ジョブの登録・置き換え
 *  - campaign_expire_post（カスタムフック）: 期限到来時の非公開化＆タイトル更新を実行
 *
 * 使い方:
 *  1) 本コードをテーマの functions.php またはサイト専用プラグインに配置します。
 *  2) 投稿編集画面のサイドバーに出る「キャンペーン終了日」を設定して更新します。
 *  3) 期限に達すると自動で非公開化され、タイトル末尾に日付付きの注記が追加されます。
 *
 * 注意事項:
 *  - サイトのタイムゾーン（一般設定）に基づいて処理します。日本時間ならそのまま入力でOK。
 *  - WP-Cron を無効化している環境では、OSの cron から wp-cron.php を定期実行してください。
 *  - 対象は post（投稿）のみ。必要に応じて post_type 条件を調整してください。
 */
// 終了日時メタボックスを追加
add_action('add_meta_boxes', function () {
  add_meta_box('campaign_expiry', 'キャンペーン終了日', function ($post) {
    $ts = (int) get_post_meta($post->ID, 'campaign_expiry', true);
    $val = $ts ? wp_date('Y-m-d\TH:i', $ts, wp_timezone()) : '';
    wp_nonce_field('save_campaign_expiry', 'campaign_expiry_nonce');
    echo '<p><label for="campaign_expiry_input">終了日時</label><br>';
    echo '<input type="datetime-local" id="campaign_expiry_input" name="campaign_expiry" value="' . esc_attr($val) . '" /></p>';
    echo '<p><small>この日時を過ぎると自動で<strong>非公開</strong>になります。</small></p>';
  }, 'post', 'side', 'default');
});

add_action('save_post', function ($post_id, $post, $update) {
  if (!isset($_POST['campaign_expiry_nonce']) || !wp_verify_nonce($_POST['campaign_expiry_nonce'], 'save_campaign_expiry')) return;
  if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return;
  if ($post->post_type !== 'post') return;

  // 既存ジョブを一旦解除
  if ($ts = wp_next_scheduled('campaign_expire_post', [$post_id])) {
    wp_unschedule_event($ts, 'campaign_expire_post', [$post_id]);
  }

  // 入力 → サイトのタイムゾーンでタイムスタンプ化
  $timestamp = 0;
  if (!empty($_POST['campaign_expiry'])) {
    $dt = date_create(wp_unslash($_POST['campaign_expiry']), wp_timezone());
    if ($dt) $timestamp = $dt->getTimestamp();
  }

  if ($timestamp) {
    update_post_meta($post_id, 'campaign_expiry', $timestamp);
    if ($timestamp > time()) {
      wp_schedule_single_event($timestamp, 'campaign_expire_post', [$post_id]); // 期限に実行
    } else {
      // すでに過去なら即時で非公開処理
      campaign_expire_post_callback($post_id);
    }
  } else {
    delete_post_meta($post_id, 'campaign_expiry');
  }
}, 10, 3);

add_action('campaign_expire_post', 'campaign_expire_post_callback');
function campaign_expire_post_callback($post_id) {
  $expiry = (int) get_post_meta($post_id, 'campaign_expiry', true);
  if (!$expiry || time() < $expiry) return;

  $p = get_post($post_id);
  if (!$p) return;

  // 1) タイトル末尾に（YYYYMMDD非公開）を付与（重複防止）
  $date_str = wp_date('Ymd', $expiry, wp_timezone());
  $title    = preg_replace('/（\d{8}[^）]*）\s*$/u', '', $p->post_title); // 既存の似た括弧表記を除去
  $title   .= '（' . $date_str . '非公開）';

  // 2) 非公開化 & タイトル更新（スラッグはそのまま）
  wp_update_post([
    'ID'          => $post_id,
    'post_status' => 'private',
    'post_title'  => $title,
  ]);
}

使い方

1. 子テーマの functions.php に上のコードを貼る
2. 投稿の編集画面 → 右側に「キャンペーン終了日」が出るので、日時を入力して更新
3. 期限が来ると自動で非公開になり、タイトル末尾に日付が付く

どう動いているか

• 終了日を保存するたびに、「〇月〇日〇時になったらこの投稿を処理してね」という1回きりの予約を入れます。
• 時間が来ると、WordPressの「WP-Cron」がそれを見つけて非公開へ変更し、タイトルに日付を追記します。
• 予約を入れ直す時は、前の予約を必ずキャンセルしてから新しい予約を入れるので、二重実行になりません。
• 不正な保存（外部からの勝手送信）を防ぐために、nonce（1回限りの合言葉）をチェックしています。

ちょいカスタマイズ

• 非公開ではなく下書きに戻す：'post_status' => 'draft' に変更
• 固定ページやカスタム投稿にも使う：add_meta_box() と save_post の投稿タイプ条件を追加
• タイトル追記の表記を変える：'（' . $date_str . '非公開）' を好みの文言に

免責事項

自己責任でお願いします。
利用する場合も、まずは検証環境で試してから本番へどうぞ。

各自のサイト状況（プラグインやキャッシュ構成）で動作が変わることがあります。

まとめ

• functions.phpだけで期日で自動非公開は十分実現できました。
• 仕組みは「期日の単発予約 → 到達したら非公開＋タイトル追記」。
• 実運用ではキャッシュとWP-Cronだけ意識しておけばOK。

The post 投稿をあらかじめ決まった日付で非表示にする（プラグイン使用なし） first appeared on hiro's note.

GTMやGA4は利用してアクセス数などは見る方法は知っていますが、クリックイベントを設定する方法がよくわからなかったので、以下のサイトを参考に設定しました。

GA4でクリックイベントを計測する方法｜計測設定から探索レポートでの確認方法まで解説 | GTMの設定 | やさしいGoogleアナリティクスブログ

Googleアナリティクス4（GA4）でクリックイベントを計測する方法、計測したクリックイベントを探索レポートで確認する方法を解説した記事です。拡張計測機能による離脱クリックやファイルダウンロードの計測、GTM (Google Tag Ma...

blog.siteanatomy.com

概ね手順通りでうまくいきましたが、一箇所だけうまくいかないところがあったので備忘としてメモを残しておきます。

その場所とは「トリガー」設定の「クリック」についてです。

手順では以下のようになっていたので、『リンクのみ』としました。

「リンクのみ」を選択する　
※対象のボタンやリンクがaタグ、areaタグでない場合は「すべての要素」を選択してください。

一応、aタグのクラス名を指定して設定を行っているので良いかと思ったのですが、発火テストの時点でボタンをクリックしてもタグが配信されませんでした。

調べたところ、aタグはdivタグの中に存在しているのですが、クリックが <a> に届いていない可能性があるとのことでした。

そのため、「クリック」を『すべての要素』としたところ、正常にタグが配信されるようになりました。

もし、同じくタグが配信されないで悩んでいる方は、トリガーの設定を見直すと良いかもしれません。

The post GTMを使ってGA4でクリックイベントを計測する first appeared on hiro's note.

本記事では、ドメインを先に取得することで得られる3つの大きなメリットや、それをした方がよい人、注意点までわかりやすく解説します。

難しい用語は使わず、初心者でも理解できるように書きますので、参考になれば幸いです。

なお、以降は「ホームページ」ではなく、「サイト」という表現を使います。

ちなみに、２つの言葉の意味は以下のようになります。

『本』に例えると、サイトは“本そのもの”で、ホームページはその“表紙”と考えるとわかりやすいです。

サイトを作る前にドメインだけ取得するのはアリ？

サイトをまだ作らない人が抱えるよくある疑問

「まだサイトを作る予定はないけど、ドメインだけ先に取っておく意味ってあるのかな？」

そう思ったことがある方は意外と多いのではないでしょうか。

ホームページやブログを始めようと思っても、すぐに作業に入れないこともありますよね。

時間が取れなかったり、まだ内容が決まっていなかったり…でも名前だけは決まっている！ということも。

そんなときに「ドメイン（URL）だけ先に取っておく」という選択は、とても現実的でメリットのある判断なんです。

実際、「サイトがなくてもドメインって取得していいの？」「取ったあと放置しても大丈夫？」という声もよく聞きます。

この記事では、そうした不安をひとつひとつ解消していきます。

初心者が知っておきたいドメインの基本知識

まずは、ドメインってそもそも何でしょうか？

ドメインとは、インターネット上の住所のようなものです。

たとえば「example.com」や「sample.jp」のような形で、あなたのサイトにアクセスするためのURLに使われます。

ホームページは建てる（作る）のに時間がかかるかもしれませんが、住所（ドメイン）は先に決めておけるんです。

そして、ドメインは早い者勝ち。

誰かが先に取得してしまうと、同じ名前は使えません。

たとえサイトの中身がまだなくても、将来的に使う予定があるなら早めに取っておくのが安心です。

ちなみに「ドメインだけ持ってて、サイトがない状態」もまったく問題ありません。

運用開始は後からで大丈夫です。

ドメインを先に取っておく3つのメリット

希望する名前を確実に確保できる

最大の理由はこれ。

「欲しい名前は早い者勝ち」です。

「fight.com」「sample.jp」など、短くて覚えやすいドメインはとても人気があります。

あとで考えてもすでに誰かが取得してしまっていた…というのはよくあること。

ブランド名や活動名、屋号、SNSアカウント名などと統一されたドメインは、印象にも残りやすく、信頼感もアップします。

特に将来、教室やサービスを広げていきたい方なら、ドメインの「名前取り」は早めに済ませておきましょう。

SEOにも有利になる可能性がある

Googleなどの検索エンジンは、ドメインが「どれだけ長く存在しているか」をひとつの信頼指標としています。

つまり、今のうちにドメインを取得しておいて、ちょっとしたブログ投稿や更新を始めておくだけで、将来のSEO（検索で上位に表示されること）にプラスになる可能性があるんです。

これは「ドメインエイジ」と呼ばれる考え方。

特に競合が多い分野では、小さな積み重ねが後で大きな差になることも。

まだ本格的なサイトは作れなくても、「少しだけ動かしておく」ことが未来につながります。

後からサイトを作るときの準備がスムーズ

ドメインが決まっていると、サイトのデザインや構成を考えるときにもブレが出にくくなります。

名刺やSNSプロフィールにも先に記載できるので、全体のブランディングが整いやすくなります。

また、ドメインがあればメールアドレスも先に使えるようになります。

たとえば「 info@sample.com 」など、自分専用のアドレスで連絡が取れると、信頼感もアップしますよね。

ホームページはまだでも、こうした準備だけでも一歩前進です。

どんな人が「ドメインだけ取得」に向いているのか

まだ事業や活動を始めていない人

「まだ準備中だけど、いずれは何か始めたい」と考えている方にとって、ドメインだけ取得しておくのはとても有効です。

たとえば、語学教室を開きたい、ネットショップを始めたい、オンラインで講座をしたい…そんな方は、今すぐサイトを作らなくても「自分の名前やブランドに合うドメイン」を確保しておくことで、安心して準備を進めることができます。

実際の作業に取りかかれるのは半年後でも1年後でも構いません。ドメインさえ取っておけば、「名前が使えなくなっていた！」というリスクは避けられます。

ただし、取得費用と年単位の更新費用はかかりますので、その点は注意が必要です。

サイト制作を自作・外注か迷っている人

ホームページを自分で作るか、誰かに依頼するか悩んでいる場合でも、ドメインだけは先に決めておくとスムーズです。

というのも、ドメインが決まっていれば、制作を外注する際に業者へ伝える情報がクリアになりますし、自作する場合でもテンプレートやテーマを選ぶ判断軸ができます。

また、ドメイン取得は制作とは別の手続きなので、悩んでいる期間中にも“確保”だけは済ませられるのが強みです。

自分でやれば数千円で済む作業も、業者に依頼をすれば人が動くことになるため、数倍のコストがかかるのは当たり前です。

ブログやSNSを先に始めている人

すでにInstagramやYouTube、X（旧Twitter）などで発信を始めている人は、活動名と一致するドメインを持つことで、より強いブランドが築けます。

たとえば「example」という名前でYouTubeをやっているなら、「example.com」というドメインを持っておくことで、将来サイトを開設したときに違和感なくつながります。

また、SNSのプロフィール欄にリンクを貼ることもでき、そこから将来のホームページや簡易ブログに誘導することができます。

ドメインだけ取得しておくときの注意点

取得には費用がかかることを理解しておこう

ドメインを取得するには、少額ながら費用が発生することを知っておきましょう。

一般的に、.comや.netなどのドメインは年間1,000円〜2,000円程度、.jpなどの日本向けドメインはやや高めで3,000円〜4,000円ほどかかることがあります。

費用は「ドメインの種類（トップレベルドメイン）」や「取得先のサービス（レジストラ）」によって異なります。

また、レジストラによってはキャンペーンでドメイン取得費用が無料または割引になることもあります。

放置せず最低限の活用を

ドメインを取得しただけで安心して、そのまま放置してしまうのはもったいないです。

もちろん、本格的なサイトをすぐに作る必要はありませんが、最低限「簡単なブログを作って月に1回更新する」「SNSリンクだけ貼った簡易ページにする」など、少しだけでも動かしておくと、SEOや検索の信頼性が上がります。

Googleも「全く使われていないドメイン」より「少しでも更新されているページ」を好む傾向があります。

毎年の維持費や更新を忘れずに

ドメインには年単位での更新費用がかかります。

一般的には年間1,000円〜3,000円程度が相場です（.comや.jpなどによって異なります）。

大切なのは、「更新を忘れて失効してしまうと、他人に取られてしまう可能性がある」という点。

そのため、クレジットカードでの自動更新を設定しておくか、更新時期が近づいたら通知メールを見落とさないようにするのが大事です。

取得先（レジストラ）選びも重要

ドメインを取得するサービス（レジストラ）は多数あります。

有名どころでは「お名前.com」「ムームードメイン」「Xserverドメイン」などがありますが、選ぶ際は料金だけでなく、サポート体制や管理画面の使いやすさも考慮するとよいでしょう。

特に初心者の方には「料金が明瞭で、余計なオプションに自動で申し込まれない」サービスを選ぶのがおすすめです。

個人的にオススメするのは「Xserverドメイン」です。

よくある質問（Q&A）

Q1. ドメインを取ったのに使わなかったらどうなりますか？

A. 取得したドメインを使わなくても、特に問題はありません。

ただし、使わない期間も維持費は毎年発生します。

更新を忘れて期限が切れると、他人に再取得されてしまうこともあるため、管理は必要です。

「将来使うかも」と思っているなら、簡単なページを表示させておくのもおすすめです。

Q2. サイトを持っていない状態でドメインだけ持っていると、信用が下がったりしませんか？

A. 基本的に信用が下がることはありません。

ただし、外部からリンクを貼るなどの用途がある場合、何も表示されないと「アクセスできないサイト」と思われてしまう可能性があります。

トップページだけでも「準備中」「近日公開予定」などの表示をしておくと、印象は良くなります。

Q3. どのタイミングで本格的にサイトを作り始めるのがベストですか？

A. 明確なタイミングは人それぞれですが、目安として「サービスの方向性が定まり始めたとき」や「SNSなどでの活動が軌道に乗り始めたとき」がおすすめです。

その頃には発信したい内容や見せたい雰囲気も具体化してきているので、スムーズに制作に移行できます。

焦らず、今できる準備から始めましょう。

まとめ

• 希望の名前を取っておくことが一番の価値
• 放置ではなく“軽く動かしておく”ことで将来に活かせる
• 迷っている人こそ、まずは一歩踏み出して

「まだサイトを作る予定はないけれど…」という方でも、ドメインだけ先に取得しておくことにはしっかり意味があります。

希望の名前を確保できるだけでなく、将来的にサイトを立ち上げる際の土台にもなります。

更新や活用方法に気をつけながら、今できる一歩から始めてみましょう。

超初心者向け｜ドメイン移管基礎知識

「ドメイン移管って聞いたことあるけど、実際何をどうすればいいの？」そんな疑問を抱えていませんか？この記事では、初心者でも安心して理解できるように、ドメイン移管の意味や考え方を中心に、サーバー移転との違いなどを解説しています。やり方などは他の...

hiro60.com

2025.06.24

The post サイト作成前の準備！ドメイン取得のススメ first appeared on hiro's note.

そんな疑問を抱えていませんか？

この記事では、初心者でも安心して理解できるように、ドメイン移管の意味や考え方を中心に、サーバー移転との違いなどを解説しています。

やり方などは他のサイトで読んだけど、そもそも書かれている意味が理解できない。という方は、まずはこの記事から始めることをオススメします。

ドメイン移管とは何か？基本のキ

ドメイン移管とは、今使っているドメイン（例：www.example.com）を、別の会社に管理を移すことです。

たとえば、お名前.comからエックスサーバーにドメインの管理先を変えるといったことがこれに当たります。

これは「サーバーを引っ越す」のとは違い、ドメインという“住所”の管理者を変えることです。

難しそうに聞こえますが、基本の流れを押さえれば初心者でも十分に対応できます。

この章では、まず「ドメイン移管ってなに？」という基本から、似た言葉との違いまでを優しく解説していきます。

サーバー移転との違いとは

「ドメイン移管」と「サーバー移転」はよく混同されがちですが、実はまったく別のことです。

• ドメイン移管：ドメインの管理を行う会社（レジストラ）を変更すること
• サーバー移転：ホームページの中身（ファイルやデータベース）を引っ越すこと

ドメインは「住所」、サーバーは「建物」と考えるとわかりやすいです。

住所の管理先を変えても、建物そのものには影響しません。

この違いを理解することで、移管時の混乱を避けられます。

ドメインとサイトのサーバーが別ってどういうこと？

ドメインを管理しているサーバーと、サイトを管理しているサーバー。
実はこの2つ、役割も場所も違う別物です。

まず、「ドメインを管理しているサーバー」は、あなたが持っているURL（たとえばwww.example.com）を管理しているサーバーのことです。

これは、ドメイン登録業者（レジストラ）が用意しているもので、DNS情報（インターネット上で住所のようなもの）を保存しておく場所です。

一方、「サイトを管理しているサーバー」は、あなたのホームページの中身（文章、画像、プログラムなど）を保管している場所です。

実際にページが表示されるためのデータがここに入っています。

つまり、

• ドメインのサーバーは「住所録」
• サイトのサーバーは「家の中身」

と考えると、とてもわかりやすいです。

サーバーが違う場合の例

• ドメインは「お名前.com」などのドメイン業者が管理
• サイトは「エックスサーバー」や「さくらインターネット」などのレンタルサーバーが管理

というように、別会社で管理されていることがあります。

この場合は、ドメインの新規取得が安いから「お名前.com」で取得したけど、サイトは自分が前から契約しているエックスサーバーにしたかった。といったような事情が考えられます。

もちろん、両方を同じ会社でまとめることもできます。

たとえば「エックスサーバー」でドメインもサイトもまとめて管理すれば、更新作業がラクになりますし、DNS設定も簡単にできます。

初心者のうちは、「ドメイン＝URL」「サイト＝中身」とざっくり覚えるだけでも十分です。

そして、どちらもインターネット上で正しくつながって初めて、あなたのホームページが表示されるという仕組みです。

不安な方は、「ドメインはどこで取った？」「サーバーはどこを使っている？」という2点を整理するだけで、状況がグッとわかりやすくなります。

「移管」と「新規取得」はどう違う？

「新規取得」は文字通り、まだ誰も使っていないドメインを新しく登録することです。

一方「移管」は、すでに使っているドメインを別の管理会社に移す作業になります。

よくある勘違いとして、「移管すればドメインの使用期間がリセットされるのでは？」という声がありますが、実際には残りの有効期間はそのまま引き継がれ、1年延長されるのが一般的です。

※管理会社によって異なることもありますし、移管の際に１年分の更新料を支払う必要があるケースもあります。

そもそもなぜドメインを移管するの？

よくある移管の理由3つ

ドメイン移管を考える理由にはいくつかありますが、多いのは次の3つです。

• 管理費用が今より安くなるから
• サーバーとドメインを同じ会社でまとめて管理したいから
• サポート対応や管理画面がわかりにくいから

例えば「ドメインはお名前.com」「サーバーはエックスサーバー」で別々になっていると、管理が煩雑になります。

まとめることで毎年の更新がラクになり、料金も一括でわかりやすくなります。

移管によって何が変わるのか

移管をしても、ドメインのURL自体が変わることはありません。

ですが、次のようなことが変わります。

• 契約更新のメールが届く相手先
• 支払い先と料金体系
• 管理画面の操作方法

また、移管時にトラブルがあると一時的にサイトが見られなくなるケースもあるため、タイミングと事前準備が大切です。

ドメイン移管の仕組みを簡単に図解

レジストラってなに？

レジストラとは、ドメインを管理・登録している公式の会社のことです。

たとえば「お名前.com」「ムームードメイン」「エックスサーバー」などが有名なレジストラです。あなたがドメインを取得すると、このレジストラがその情報をICANN（国際機関）などに登録してくれています。

移管とは、つまり「Aというレジストラから、Bというレジストラにドメインを引っ越すこと」です。

認証コード（AuthCode）の役割とは

ドメイン移管時に必要になるのが「認証コード（AuthCode）」です。オースコードと読みます。

これはそのドメインの持ち主しか知らない“鍵”のようなもので、移管時に本人確認のために使います。

このコードは、今使っているレジストラ（移管元）で取得できます。

セキュリティの観点からも重要で、これがないと他人に勝手にドメインを移されてしまうリスクを防げます。

AuthCodeを入力して初めて移管申請がスタートするので、事前に確認しておくことが大切です。

まとめ

ここに書かれているようなことを基礎知識として抑えておくと、実際の手順を解説しているサイトの内容がおぼろげながらでもわかってくると思います。

もし、追加で知りたいことがあったら解説を追記しますので、お気軽にコメントください。

サイト作成前の準備！ドメイン取得のススメ

「ホームページを作りたいけど、まだ早いかな…」と思っている場合でも、ドメインだけを先に取っておくことをオススメします。本記事では、ドメインを先に取得することで得られる3つの大きなメリットや、それをした方がよい人、注意点までわかりやすく解説し...

hiro60.com

2025.06.26

The post 超初心者向け｜ドメイン移管基礎知識 first appeared on hiro's note.

・・・はい、それをやらかしました＾＾；

この記事では、同じように困ってしまった方のために、自力でログイン画面にたどり着く２つの方法を紹介します。

方法１：/wp-admin にアクセスして自動リダイレクトを利用する

もっとも簡単なのがこの方法。

手順

１．ブラウザで以下にアクセスします。

サイトのURL/wp-admin

例）https:sample.com/wp-admin

２．ログインしていなければ、SiteGuardで設定したカスタムURLに自動リダイレクトされます。

３．表示されたログイン画面のURLをブックマークするか、メモに控えます。

これはSiteGuardの仕様で、未ログイン状態でwp-adminにアクセスすると、現在有効なログインURLに転送されるためです。

方法２：FTP経由でSiteGuardプラグインを一時停止する

もし、/wp-admin にアクセスしてもリダイレクトされない場合は、SiteGuardプラグインを一時的に無効化する方法もあります。

手順

1. FTPソフトやサーバーのファイルマネージャーで WordPressの wp-content/plugins にアクセス
2. 「siteguard」フォルダをリネームします（例：siteguard_backup）
3. これでSiteGuardが無効化され、ログインURLが wp-login.php に戻ります
4. ログイン後、リネームした名前を戻します。（設定をそのまま使えます）

「ログインURLがわからなくなった！どうしよう！」と焦る前に、上記を試してみてください。

WordPressやそれ以外で作成されているサイトのトラブル全般を解決できます。

お困りのことがありましたら、お気軽にご相談ください。

The post SiteGuardでログインURLを忘れたときの復旧方法２選 first appeared on hiro's note.

この記事では、実際に私が使用している docker-compose.yml を例に、その役割や各項目の意味を初心者向けにわかりやすく解説していきます。

そもそも docker-compose.yml って何？

Docker Compose は、複数のコンテナ（WordPress・MySQL・phpMyAdmin など）をまとめて管理するためのツールです。

その設定ファイルが docker-compose.yml です。

このファイルに「どのサービスを使うか」「どうつなぐか」「どのファイルと同期するか」などを記述します。

基本的にはこのファイルがあれば、ターミナルで以下の1行を入力するだけでローカル環境を立ち上げられます。

docker compose up -d

使用している docker-compose.yml

状況によって内容を書き換える必要がありますが、ひとまず以下の内容で動かしています。

services:
  db:
    image: mysql:5.7
    container_name: sample_wp_mysql
    #restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wp_db
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: root
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:php8.2-apache
    container_name: sample_wp
    depends_on:
      - db
    ports:
      - "8204:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: root
      WORDPRESS_DB_NAME: wp_db
      WORDPRESS_DEBUG: 1
    volumes:
      - ./public_html:/var/www/html

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin_sample_ingrid
    depends_on:
      - db
    ports:
      - "8205:80"

volumes:
  db_data:

各記載の意味

db（MySQL）

WordPressが利用するデータベースです。

• image: 使用するDockerイメージ（ここではMySQL 5.7）
• restart: コンテナが何らかの理由で停止した場合に自動的に再起動させるためですが、意図しない再起動が起こらないようにコメントアウトしています。
• container_name: コンテナに付ける名前。サイト名を半角英字で入力することが多いです。
• environment: DBの初期設定（rootパスワード、DB名、ユーザー名など）。基本変えません。
• volumes: データ保存先を指定して中身を永続化（消えないように）しています。

永続化については、データベースが消えてしまうことがあってから入れるようにしました。詳しくは以下の記事の「作業中に発生したトラブルと対処方法」をご覧ください。

WordPress本番サイトをローカル環境で復元する方法（PHPのバージョンを合わせる）

WordPressで作成されたサイトのデータを、ローカル（または他のドメイン）に再現するのはカンタンです。「Updraftplus」というプラグインを使えば、メディアやプラグインなどを含めたすべてのデータをバックアップしてくれます。そして、...

hiro60.com

2025.05.23

wordpress

WordPress本体です。

• image: PHP8.2が使えるWordPressイメージ。作成したい環境によって変える必要があります。
• depends_on: dbより後に起動するよう依存関係を定義
• ports: ローカルの8204番ポートでアクセスできるように設定（http://localhost:8204）。コンテナごとに変える必要があります。
• environment: WordPressがDBと接続するための情報
• volumes: ローカルの public_html フォルダと同期（ファイル編集が即反映される）

image は、とりあえずローカル環境を作りたいという場合は、wordpress:latestでOKです。
これは、WordPressの公式Dockerイメージの中で「最新安定版」を自動的に取得する設定です。

wordpress:latest
    image: mysql:5.7 ← この記述は削除する

phpmyadmin

ブラウザ上でDBを操作できる便利ツールです。

• image: phpMyAdmin の公式イメージ
• depends_on: dbが先に起動するように設定
• ports: ローカルの8205番ポートでアクセス可能（http://localhost:8205）

ボリューム db_data について

最下部の volumes: セクションで db_data を定義することで、MySQLのデータを保存するボリューム（外部ストレージのようなもの）を作っています。

これがあることで、コンテナを停止・再起動してもデータベースの中身が保持されます。

volumes:
  db_data:

詳しくは以下の記事の「作業中に発生したトラブルと対処方法」をご覧ください。

WordPress本番サイトをローカル環境で復元する方法（PHPのバージョンを合わせる）

WordPressで作成されたサイトのデータを、ローカル（または他のドメイン）に再現するのはカンタンです。「Updraftplus」というプラグインを使えば、メディアやプラグインなどを含めたすべてのデータをバックアップしてくれます。そして、...

hiro60.com

2025.05.23

補足：ボリューム名の自動命名について

Docker Compose は、volumes: に名前だけを指定した場合、自動的にボリューム名を次のように変換して保存します。

[プロジェクト名]_[ボリューム名]

たとえば、プロジェクト名が sample の場合、実際に作成されるボリュームは：

sample_db_data

この名前はターミナルから docker volume ls で確認できます。

注意：ボリュームの「残骸」について

volumes: セクションで db_data を定義しない場合、環境を構築するつど自動的にボリュームが作成されます。

開発中だと何度かコンテナを作り直すこともありますが、docker compose down コマンドでコンテナを削除しても、ボリュームは削除されません。

そのため、プロジェクト名やボリューム定義が変わるたびに新しいボリュームが作成され、古いボリュームが残ってしまうことがあります。

これにより、知らず知らずのうちにローカルに使われていないボリュームが蓄積される可能性があります。

その場合は、以下のコマンドで確認や削除が行えます。

現在使われていないボリュームを確認するには、

docker volume ls

不要なボリュームを削除するには、

docker volume rm ボリューム名

または、未使用ボリュームをまとめて削除するには、

docker volume prune

このようにして、環境をクリーンに保つことができます。

まとめ

docker-compose.yml を使って、WordPress・MySQL・phpMyAdmin の3つのコンテナを一括で構築・管理できます。

この記事が、これからDockerでWordPressのローカル環境を構築したい方の参考になれば嬉しいです。

The post docker-compose.ymlの解説（WordPressのローカル環境構築） first appeared on hiro's note.

私も、ドメインを変えて移行する場合は必ずこのプラグインを使っていました。

なぜなら「自動でドメインの書き換えをしてくれる」からです。

たとえば、旧サイトが https://example.com、新しい環境が http://localhost:8080 のような場合、 記事内リンクや画像のパスなどが旧ドメインのままだと正常に表示されません。

All-in-One WP Migrationはそのあたりを自動で置換してくれるので、復元後に“元のサイトが表示されてしまう”といったミスが起きにくかったのです。

しかし、バックアッププラグインである「UpdraftPlus」でも、いつのまにかこのドメイン書き換えができるようになっていました。

私はもともとUpdraftPlusを“バックアップ専用”として使っていましたが、気づいたら移行先での復元でもドメインの置換がされるようになっていて、ちゃんと新しい環境で動くようになっていました。

結局、All-in-One WP MigrationとUpdraftplusのどっちが良いのか、私自身の体験とあわせて、以下で詳しく解説します。

サイト移行で必要な「ドメインの書き換え」って何？

まず、今回キモとなるドメインの自動書き換え機能について解説します。

WordPressは記事データや設定情報の多くをデータベースに保存しています。

ここには、以下のように「旧ドメイン」の情報が埋め込まれています。

• サイトURL（トップページ）
• 投稿本文の中のリンク
• 画像やファイルのパス
• メニュー、ウィジェットの設定
• カスタムHTMLやショートコード内のURL など

このままだと、新しいドメインに移行しても「リンクをクリックすると元のサイトに戻ってしまう」「ログインすると旧サイトに飛ぶ」といった問題が発生します。

だからこそ「自動でドメインを書き換えてくれる」機能が重要になるわけです。

UpdraftPlusでもドメイン置換されるように

以前のUpdraftPlusでは、復元後も旧ドメインが残ってしまい、 ローカルで復元したのにログインすると本番サイトにリダイレクトされてしまったり、 画像がうまく表示されなかったりすることがありました。
↑実際に私が知識がない頃に、「本番サイトをバックアップして、復元すればその環境で使えるでしょ」と思ってやった失敗です。。。

でも今のUpdraftPlusは、「復元先のドメインが元と違う」と判断してくれるようになっており、復元時のオプションで自動的にデータベース内のURLを書き換えてくれるようになっています。

以下の画像の確認画面が表示されるので、「データベース内のサイトの場所を検索して置換する (移行)」にチェックを入れて、復元すればドメインの書き換えを行ってくれます。

なので、「バックアップ＋移行」両方の用途をこれ1つでカバーできるようになっています。

どっちを使うか？

All-in-One WP Migrationは「簡単に丸ごと移せる」「書き換えも自動でやってくれる」など便利ですが、 無料版ではインポートサイズに上限（512MBなど）があるのが難点です。

大きめのサイトになると有料アドオンが必要になります。

その点、UpdraftPlusにはサイズの上限はありません。

バックアップファイルはデフォルトで約400MBごとに自動で分割されるため、大容量サイトでも対応できます。

また、バックアップの保存先もGoogle DriveやS3などのクラウドを選べるので、 ディスク容量の制限も回避できます。

日常的に運用するならUpdraftPlusのほうが柔軟性があります。

なので私は今、「移行も含めて、UpdraftPlusで十分」と考えています。

手動で行うなら「Better Search Replace」

自分でドメインの書き換えを行うこともできます。

その場合は、Better Search Replace というプラグインを使って、 復元後に自分で「旧URL → 新URL」の置き換えを実行することができます。

操作はとても簡単で、検索キーワードと置換キーワードを入力して、チェックボックスでどのテーブルを対象にするか選ぶだけ。

最初は「ドライラン（テストモード）」で何件置換されそうかを確認することもできます。

まとめ

• 今のUpdraftPlusは、ドメインが変わっても自動で置換してくれるようになっている
• All-in-One WP Migrationは便利だが、サイズ制限がネック
• UpdraftPlusなら大容量でも自動分割で対応可能
• 普段からUpdraftPlusでバックアップしておけば、移行もそのまま対応できる
• 「自動処理が不安」なら、Better Search Replaceで手動チェックもできる

The post UpdraftPlusでWordPress移行は完結する？旧定番との違いを解説 first appeared on hiro's note.

「Updraftplus」というプラグインを使えば、メディアやプラグインなどを含めたすべてのデータをバックアップしてくれます。

そして、ローカルに構築したWordPressにも同じく「Updraftplus」をインストールして復元するだけで他の環境にサイトを移行することが可能です。

ただ、本番環境とローカルでWordPressのバージョンが違ったり、PHPのバージョンが違ったりすることで、移行後に正しく動作しないなんてこともあるので、そういった点に注意する必要があります。

今回は作業の中で、そういった操作が必要になったため、備忘として記録を残しておきます。

同じような操作を初めて行う方や慣れていない方の参考になればと思います。

行った手順

1. DockerでローカルWordPress環境を構築しました

PHPのバージョンが異なる

元々DockerでWordPress環境は用意してあり、「 wordpress:latest 」イメージを使用していました。

これは、WordPressの公式Dockerイメージの中で「最新安定版」を自動的に取得する設定です。

しかし、かなり前に構築した環境だったために、復元元の本番環境とPHPのバージョンが異なっているという警告が表示されました。

本番と復元先でPHPのバージョンが異なる場合の対処方法

そのため、本番環境と合わせるために明示的に php8.2-apache を指定するようにしました。

  wordpress:
    image: wordpress:php8.2-apache

PHPのバージョンが異なると、次のような問題が発生する可能性があります：

• テーマやプラグインが正しく動作しない
• 警告やエラー（たとえば Deprecated や Fatal Error）が発生する
• セキュリティや互換性の問題が発生する可能性がある

一般的には、本番環境と同じ、あるいはより新しいPHPバージョンに合わせるほうが安全で推奨されます。

なお、「新しいPHPバージョン → 古いPHPバージョン」へ戻す場合は、対応していないコードが原因で動作しなくなることがあるため、十分な注意が必要です。

Dockerの設定変更内容は以下のとおりです（再掲）

wordpress:
  image: wordpress:php8.2-apache

その後、次のコマンドで再起動を行いました。

docker compose down
docker compose up -d

• down は既存のコンテナを停止・削除するために実行します。
• up -d は新しいイメージに基づいて再構築・バックグラウンドで起動するために使用します。
• Dockerでは、image を変更しただけではコンテナの中身が自動的に更新されないため、一度 down してから up -d する必要があります。

2. UpdraftPlusによる復元作業を実施しました

WordPressの管理画面にログインし、UpdraftPlusを使って本番サイトのバックアップを復元しました。

php8.2に合わせたことで、PHPのバージョンに関する警告は表示されなくなり、問題なく復元が完了しました。

作業中に発生したトラブルと対処方法

トラブル①：docker compose down 実行後にDBが初期化されてしまった

• 原因：docker-compose.yml に volumes: の記述がなく、down でコンテナを削除した際にMySQLのデータも消えてしまったようです。
• 対処方法：以下のように volumes: を追加し、データベースの永続化を実装しました。
  ※データベースの永続化のメリット・デメリットは後述

volumes:
  - db_data:/var/lib/mysql

volumes:
  db_data:

この記述をする前の動きとしては、

1. docker compose down
   → コンテナは完全に削除（ただし -v を付けなければボリュームは残る）
2. docker compose up -d
   → volumes: が未定義だったため、既存のボリュームと接続されず、新しい空のボリュームが自動作成された

つまり、downで箱（コンテナ）を壊し、upで新しい箱を作ったが、中身の保存場所が変わってしまったという状態。

そのため、それまでにあったWordPress環境やデータベースが見られなくなってしまった。

ボリューム db_data について

最下部の volumes: セクションで db_data を定義することで、MySQLのデータを保存するボリューム（外部ストレージのようなもの）を作っています。

これがあることで、コンテナを停止・再起動してもデータベースの中身が保持されます。

ということで試してみました↓↓↓

検証結果

１．再度、down でコンテナを停止・削除してから、up -d でコンテナ再構築。（volumes:の記載あり）
※この操作でMySQLのデータを保存するボリュームが作成される。
※ただし、Docker内（仮想環境）に作成されるので、Finderからは見えない。

２．WordPressの「ようこそ」が表示され、WordPressインストールし直し。

３．インストール後は、データが空っぽな状態。Updraftplusで改めて復元。

４．再度、down でコンテナを停止・削除してから、up -d でコンテナ再構築。

結果、WordPressの再インストールなしで、直前の状態から始められました。

トラブル②：WordPressで「データベース接続確立エラー」が表示された

• 原因：MySQLが初期化されていたことと、WordPressが以前の wp-config.php を読み込んでいたことによるものです。
• 対処方法：public_html フォルダを一度空にして、WordPressの初期インストール画面から再構築を行いました。

運用時の注意点と学び

データベースは常に消える可能性がある前提で運用する

• データを保持したい場合は、volumes: による永続化設定を忘れないようにする。

逆に、ボリュームを消したい場合は、

• docker compose down に -v オプションを付ける

docker compose down -v

補足：「ボリュームごと削除」には注意

Dockerにおける「ボリューム」は、データベースの中身（投稿、設定、ユーザーなど）を保存している実体です。

通常の「 docker compose down 」ではコンテナ（アプリの箱）だけが削除されますが、「-v 」オプションを付けるとその中の「データ（ボリューム）」まで一緒に消えてしまいます。

そのため、誤って「 -v 」を付けたまま実行すると、保存していたWordPressのデータベースが完全に初期化されてしまうリスクがあります。

学習環境ではやり直しで済みますが、本番データや作り込んだ検証環境では大きな損失になります。

ボリュームを削除してリセットしたい場合は、バックアップを取った上で意図的に「 -v 」を使うようにしましょう。

補足：データベース永続化のメリットとデメリット

メリット：

• docker compose down や再起動をしてもデータベースの中身が保持されるため、意図せずデータが消えることがありません。
• 本番に近い継続的な検証が可能になり、作業効率が向上します。
• 定期バックアップと組み合わせることで安全性が高まります。

デメリット：

• クリーンな状態でやり直したい場合に手間がかかります（ボリュームを明示的に削除する必要あり）。
• データベース構成が古いまま残ると、意図しない挙動が起きることがあります。
• ホストマシン上にデータが残り続けるため、ストレージを圧迫することもあります。

ローカル環境をどう活用するか

ローカル環境を構築したら、その使い途としては以下のようなものがあります。

① 本番反映前の検証環境として使う

使い方：

• 本番のバックアップ（UpdraftPlus など）をローカルに復元
• プラグインやテーマのアップデート前に動作確認
• CSSやPHPの修正を事前にチェック

メリット：

• 本番にデプロイするよりも確認が早い
• 本番での不具合を未然に防げる
• 安心して改修作業ができる

② 新機能の開発・テスト

使い方：

• 新しいカスタム投稿タイプ、ショートコード、テーマ機能などを追加
• 本番と同じデータがあるから挙動の再現性が高い

メリット：

• 「動くと思ったのに動かない…」を減らせる
• 複数人での共同開発にも役立つ（Git連携＋ローカル開発）

③ 本番環境のトラブル再現・原因調査

使い方：

• 本番で発生したエラーを、ローカル環境で再現して検証
• wp-config.php の設定を一時的に変えて詳細ログを出力

メリット：

• 安全に試行錯誤できる
• 本番に影響を与えないので安心

④ WordPressの学習やスキルアップにも最適

使い方：

• テーマ自作やプラグイン開発の練習用
• データベース構造の理解にも役立つ（phpMyAdmin付き）

メリット：

• 失敗してもやり直せる
• サンドボックス環境として自由度が高い

注意点と運用のコツ

The post WordPress本番サイトをローカル環境で復元する方法（PHPのバージョンを合わせる） first appeared on hiro's note.