md サブドメインの DNS と Bootstrap installer

md サブドメイン (md.example.com 等) を実際にブラウザから到達可能にするための DNS 設定と、md ホスト用 index.php を管理画面から自動生成する Bootstrap installer の使い方を、サーバ環境別に詳細解説します。

md サブドメインとは

本プラグインの中核コンセプトは「メインサイト (www.example.com) の HTML 出力には一切手を入れず、専用サブドメイン (md.example.com) で AI クローラ向けの Markdown 並行版を配信する」ことです。詳細は 基本概念 を参照してください。本ページではサーバ側のセットアップに集中します。

md サブドメインの 3 つの構成要素

• DNS レコード — md.example.com をサーバ IP に向ける A / CNAME レコード
• SSL 証明書 — md.example.com 用の TLS 証明書 (Let's Encrypt ワイルドカード等)
• DocumentRoot と index.php — md ホストへのリクエストを WordPress に橋渡しする入口

このうち 3 つ目の「index.php 配置」を管理画面から自動化するのが Bootstrap installer です。SSH/FTP が使えない環境でも、ボタン 1 つで md ホストを動かせます。

DNS 設定の基本

DNS レジストラ (お名前.com / VALUE-DOMAIN / Cloudflare / Route 53 等) の管理画面で、md サブドメイン用のレコードを追加します。サーバ構成によって A レコードか CNAME レコードかが変わります。

A レコードの場合

サーバが固定 IP を持つ場合 (専用サーバ / VPS / 一部の共有レンタルサーバ) は A レコードを使います。メインサイトの A レコードと同じ IP を指す形が一般的です。

CNAME レコードの場合

マネージド PaaS (Heroku / WP Engine / Kinsta 等) ではホスト名 (例: your-site.kinsta.cloud) を割り当てられることが多く、IP が動的に変わるため CNAME を使います。

Cloudflare 等の CDN 経由

Cloudflare をフロントに置く場合、DNS レコードはオレンジ雲 (Proxy ON) にすることで CDN を経由します。Universal SSL も自動発行されるため、別途 Let's Encrypt 等を用意する必要はありません (詳しくは下記「SSL 証明書の取り扱い」を参照)。

SSL 証明書の取り扱い

md サブドメインも HTTPS で配信するのが原則です。本プラグインの Bootstrap installer の verify 機能 (ksmd_bootstrap_verify()) は home_url() の scheme を継承するため、メインサイトが HTTPS なら md サブドメインも HTTPS で疎通確認します。

Let's Encrypt のワイルドカード証明書

もっとも一般的な選択肢です。*.example.com 用のワイルドカード証明書を取得しておけば、md / blog / app 等の任意のサブドメインがすべて 1 枚でカバーされます。

# certbot DNS-01 challenge の例 (DNS API 連携必須)
sudo certbot certonly --manual --preferred-challenges=dns \
  -d 'example.com' -d '*.example.com' \
  --agree-tos --email admin@example.com

Cloudflare Universal SSL

Cloudflare 経由 (オレンジ雲) なら、サブドメイン分も含めて Universal SSL が自動発行されます。設定は不要です。Cloudflare ダッシュボードの「SSL/TLS → Edge Certificates」で発行状況を確認できます。

サブドメイン単位の証明書

「md サブドメインのみ」を別途発行することもできます。Apache/Nginx の VirtualHost 設定で md サブドメイン用の証明書ファイルパスを指定します。

md ホスト用ドキュメントルート

DNS と SSL が揃ったら、Web サーバ (Nginx / Apache / コントロールパネル) で md サブドメインの「ドキュメントルート」を決めます。Bootstrap installer がサポートするのは以下の 2 構成のみです (includes/md-bootstrap-installer.php:108)。

• sibling (兄弟構成): WP 本体 (ABSPATH) と同じ親ディレクトリにある md ディレクトリ
• subdir (ABSPATH 直下サブディレクトリ構成): ABSPATH の直下に md ディレクトリ (XServer 標準)

パターン A: Xserver 等の ABSPATH 直下構成 (subdir)

Xserver の標準は WP 本体が /home/user/example.com/public_html/ にあり、サブドメインは「サブドメイン作成」機能で /home/user/example.com/public_html/md/ のようにディレクトリを切るタイプです。

/home/user/example.com/public_html/        # ABSPATH (= WP 本体)
├── wp-config.php
├── wp-blog-header.php
├── wp-admin/
├── wp-content/
├── wp-includes/
└── md.example.com/                          # md サブドメイン用 DocumentRoot (subdir)
    └── index.php                             # ← Bootstrap installer が生成

この構成では、md.example.com ホストへのリクエストは md.example.com/index.php を実行し、その中で __DIR__ . "/../wp-blog-header.php" = /home/user/example.com/public_html/wp-blog-header.php を require することで WordPress を起動します。

パターン B: Bedrock 流の兄弟構成 (sibling)

Bedrock や WP-CLI 標準の「web/wp/ に WP 本体、web/ をドキュメントルートに」とする構成では、web/ の直下に md ディレクトリを切る形になります。Bootstrap installer の sibling パターンが該当します。

/srv/example.com/web/                       # 親ディレクトリ
├── wp/                                      # ABSPATH (= WP 本体)
│   ├── wp-config.php
│   ├── wp-blog-header.php
│   ├── wp-admin/
│   ├── wp-content/
│   └── wp-includes/
└── md/                                      # md サブドメイン用 DocumentRoot (sibling)
    └── index.php                             # ← Bootstrap installer が生成

生成される index.php の require は __DIR__ . "/../wp/wp-blog-header.php" となり、basename(ABSPATH) を埋め込みます。

パターン C: 標準 WP の別ドキュメントルート

VirtualHost を完全に分離して、たとえば /var/www/md.example.com/ のような別パスをドキュメントルートにする構成は Bootstrap installer の対象外です。realpath() で解決した md ディレクトリの親が ABSPATH か ABSPATH の親と一致しないため、validate_path() 内で gate #4-#5 が失敗します。

// includes/md-bootstrap-installer.php より
if ( $md_parent === $abs_real_norm ) {
    // ABSPATH 直下サブディレクトリ構成 (XServer 標準)
    $layout_type = 'subdir';
    // ...
} elseif ( $md_parent === $abs_parent ) {
    // 兄弟構成 (target-v3 互換)
    $layout_type = 'sibling';
} else {
    // ABSPATH の孫以下 / 非関連パス (Bedrock 等) / その他 = 拒否
    $result['errors'][] = sprintf(
        __( 'md ドキュメントルートが WP 本体の兄弟ディレクトリでも ABSPATH 直下サブディレクトリでもありません ...', ... ),
        ...
    );
    return $result;
}

このような構成では SSH 経由で手動配置することになります。詳しくは「インストールされる index.php の中身」セクションを参照してください。

Bootstrap installer とは

md ホスト用の index.php (= WP の入口となる 3 行 PHP) を、管理画面から 1 クリックで配置・削除・復元できる機能です。includes/md-bootstrap-installer.php に実装されており、診断タブの下部に UI が出ます。

解決する問題

• SSH/FTP が使えない (or 苦手な) ユーザでも md ホストを動かせる
• 「index.php に何を書けばいいか」を間違えるリスクをなくす (テンプレが固定)
• WP コアファイル (wp-admin/index.php 等) を誤って上書きする事故を gate #4 で防ぐ
• 削除時は 24h バックアップを保持し、ワンクリック復元できる (F5)
• verify (HTTP リクエストでの疎通確認) を HMAC トークン付き wp_remote_get で実施 (F12)

解決しない問題 (= 範囲外)

• DNS レコードの自動作成 (DNS は手動で行う必要があります)
• SSL 証明書の自動発行 (Let's Encrypt 等の手段に委ねます)
• Web サーバの VirtualHost 設定の書き換え (DocumentRoot は手動で設定済みであることを前提)
• Bedrock や ABSPATH 孫以下の構成 (validate で拒否)

Bootstrap installer の使い方

Bootstrap installer の使用フローは以下の 4 ステップです。診断タブの下部「md ホスト ブートストラップ」セクションで操作します。

ステップ 1: md ホストパスを入力する

<input type="text" name="ksmd_bootstrap_path"
       placeholder="/home/user/public_html/md.example.com"
       class="regular-text" style="width:30em;" />

ステップ 2: パスを保存する

function ksmd_sanitize_bootstrap_path( $raw ) {
    $p = sanitize_text_field( (string) $raw );
    $p = trim( $p );
    if ( $p === '' ) {
        return '';
    }
    // 絶対パスのみ許可
    if ( substr( $p, 0, 1 ) !== '/' ) {
        return '';
    }
    // 末尾スラッシュ除去
    $p = rtrim( $p, '/\\' );
    return $p;
}

ステップ 3: 「状態を再確認」で 8 段検証を走らせる

ステップ 4: 「index.php を生成」を実行

ステップ 5: verify で疎通確認

インストールされる index.php の中身

Bootstrap installer が配置する index.php はテンプレートとして ksmd_bootstrap_generate_template() 関数で生成されます (includes/md-bootstrap-installer.php)。

テンプレート (subdir 構成)

<?php
/**
 * KSMD-BOOTSTRAP-MARKER v1
 * Generated by wp-plugin-kashiwazaki-llmo-md-subdomain on 2025-04-30T12:00:00Z
 * Do not edit manually. Use plugin admin UI to regenerate or remove.
 */
define( "WP_USE_THEMES", true );
require __DIR__ . "/../wp-blog-header.php";

テンプレート (sibling 構成)

<?php
/**
 * KSMD-BOOTSTRAP-MARKER v1
 * Generated by wp-plugin-kashiwazaki-llmo-md-subdomain on 2025-04-30T12:00:00Z
 * Do not edit manually. Use plugin admin UI to regenerate or remove.
 */
define( "WP_USE_THEMES", true );
require __DIR__ . "/../wp/wp-blog-header.php";

違いは require 行の path だけです。sibling 構成では basename(ABSPATH) (例: wp) を埋め込み、subdir 構成では __DIR__ . "/../wp-blog-header.php" を直接呼びます (ksmd_bootstrap_generate_template():340)。

なぜこれで動くのか

1. md.example.com へのリクエストが Web サーバ経由で /md.example.com/index.php を実行する
2. require で WP の入口 wp-blog-header.php が読み込まれる
3. wp-blog-header.php は wp-load.php 経由で wp-config.php を読み、WordPress を完全初期化する
4. 初期化の途中、template_redirect アクションが priority -1 で発火する
5. 本プラグインの ksmd_handle_subdomain_request() が $_SERVER['HTTP_HOST'] を見て md ホストと判定 → Markdown を返してそのまま exit

つまり「index.php は単なる WordPress 入口であり、md/seo の判定はプラグインが行う」というアーキテクチャです。詳しくは アーキテクチャ ページを参照してください。

WP_USE_THEMES が true の理由

テンプレートでは define( "WP_USE_THEMES", true ); としています。これは「WP の通常の template_redirect ライフサイクルを通す」という意味であり、本プラグインの template_redirect priority -1 フック発火を保証するために必要です。false にしてしまうと template-loader.php がスキップされ、本プラグインの介入機会も失われます。

Bootstrap installer 復元 / アンインストール

生成した index.php は管理画面から削除と復元ができます。両者の使い分けを把握しておきましょう。

「index.php を削除」(uninstall)

診断タブの「index.php を削除」ボタンで ksmd_handle_bootstrap_uninstall が呼ばれ、内部で ksmd_bootstrap_uninstall() が動作します。動作内容は次の通りです。

• 削除前に識別 3 重検証 (marker / sha256 / version) を実施 (ksmd_bootstrap_existing_is_safe_to_overwrite())
• 3 重一致した場合のみ unlink、不一致なら警告して中断 (= 手動編集された可能性)
• unlink 直前に削除内容を ksmd_bootstrap_last_removed_backup オプションに 24h 保存 (F5)
• ksmd_bootstrap_meta オプションを削除

function ksmd_bootstrap_uninstall( $verified_dir ) {
    // ...
    // 削除前 backup を保存 (24h TTL)
    $backup_content = @file_get_contents( $target );
    if ( $backup_content !== false ) {
        update_option( KSMD_BOOTSTRAP_BACKUP_OPTION, array(
            'content'    => $backup_content,
            'sha256'     => @hash_file( 'sha256', $target ),
            'target_dir' => $verified_dir,
            'removed_at' => time(),
        ) );
    }
    // unlink
    if ( ! @unlink( $target ) ) {
        // ...
    }
    delete_option( KSMD_BOOTSTRAP_META_OPTION );
}

「直前の削除を元に戻す」(restore)

削除後 24 時間以内なら、状態カードに「直前の削除を元に戻す (残り約 N 時間)」ボタンが表示されます。ksmd_handle_bootstrap_restore が ksmd_bootstrap_restore() を呼び、ksmd_bootstrap_last_removed_backup オプションから内容を復元します。

• backup の removed_at から DAY_IN_SECONDS 経過していたらバックアップ削除して中断
• 復元先で再度 validate_path() を走らせ、validation OK なら atomic rename で書き戻し
• ksmd_bootstrap_meta を再構築 (restored_from_backup => true マーカ付き)
• 復元成功後、backup オプションを削除

使い分けの指針

Bootstrap installer のセキュリティ

Bootstrap installer は md ホストのドキュメントルートに PHP ファイルを書き込む機能なので、以下のセキュリティ対策が施されています (includes/md-bootstrap-installer.php)。

admin 経由のみ動作

機能ファイル md-bootstrap-installer.php は kashiwazaki-llmo-md-subdomain.php の ksmd_bootstrap_plugin() 内で is_admin() ガード付きでのみ require_once されます。フロントエンドの opcode footprint を増やさないだけでなく、フロントエンドからは関数自体が見えないことになります。

if ( is_admin() ) {
    $admin = KSMD_PLUGIN_PATH . 'admin/admin-loader.php';
    if ( file_exists( $admin ) ) {
        require_once $admin;
    }

    // F9: md ホスト ブートストラップ機能は admin 限定で読み込む
    $bootstrap = KSMD_PLUGIN_PATH . 'includes/md-bootstrap-installer.php';
    if ( file_exists( $bootstrap ) ) {
        require_once $bootstrap;
    }
}

nonce 保護 (F7: action と 1:1 対応)

5 種のアクションすべてに wp_nonce_field() + check_admin_referer() が掛かっており、action 名と nonce action 名が 1:1 対応するよう揃えられています。

// admin/admin-loader.php
add_action( 'admin_post_ksmd_bootstrap_save_path', 'ksmd_handle_bootstrap_save_path' );
add_action( 'admin_post_ksmd_bootstrap_check',     'ksmd_handle_bootstrap_check' );
add_action( 'admin_post_ksmd_bootstrap_install',   'ksmd_handle_bootstrap_install' );
add_action( 'admin_post_ksmd_bootstrap_uninstall', 'ksmd_handle_bootstrap_uninstall' );
add_action( 'admin_post_ksmd_bootstrap_restore',   'ksmd_handle_bootstrap_restore' );

書き込み権限チェック (gate #3, gate #8)

パス検証では静的判定 (is_writable()) と動的判定 (probe ファイル書き込み) の両方を実施します。これは open_basedir 制約 / SELinux / chrooted PHP-FPM 等で is_writable() が真でも実際には書けない環境への対策です。

// gate #8: probe ファイル書き込みテスト
$probe_name = '.ksmd-write-probe-' . uniqid( '', true );
$probe_path = $real . '/' . $probe_name;
$probe_ok   = @file_put_contents( $probe_path, 'probe' );
if ( $probe_ok === false ) {
    $result['errors'][] = sprintf(
        __( 'probe ファイルの書き込みに失敗しました ...', 'kashiwazaki-llmo-md-subdomain' ),
        $real
    );
    return $result;
}
$unlink_ok = @unlink( $probe_path );
if ( ! $unlink_ok ) {
    @unlink( $probe_path );
    $result['errors'][] = sprintf(
        __( 'probe ファイルの削除に失敗しました ...', 'kashiwazaki-llmo-md-subdomain' ),
        $probe_name
    );
    return $result;
}

WP コアディレクトリ拒否 (gate #4-b)

md ディレクトリの basename が wp-admin / wp-includes / wp-content と一致 (case-insensitive) すると拒否します。WP コアの index.php を上書きする事故を防ぎます。

// gate #4-b: ABSPATH 直下の WP コア dir を md として指定するのは禁止
$core_dirs       = ksmd_bootstrap_wp_core_dirs(); // ["wp-admin","wp-includes","wp-content"]
$md_basename_lc  = strtolower( $md_basename );
$core_dirs_lc    = array_map( 'strtolower', $core_dirs );
if ( in_array( $md_basename_lc, $core_dirs_lc, true ) ) {
    $result['errors'][] = sprintf(
        __( '指定パスが WordPress コアディレクトリ (%2$s のいずれか) と一致しています: %1$s ...', ... ),
        $md_basename,
        implode( ' / ', $core_dirs )
    );
    return $result;
}

TOCTOU 対策 (F1)

rename 直前と直後の 2 回 realpath() を再検証し、間に攻撃者がディレクトリを symlink にすり替えたケースに対応します。tempnam() も「指定ディレクトリ内に作成されたか」を検証します。

verify は HMAC ヘッダ + sslverify フィルタ付き (F12 / F13)

verify では ksmd_generate_test_token('/') で HMAC-SHA256 トークンを生成し X-Ksmd-Test-Token ヘッダに乗せて送信します。受信側は core-functions.php:112 でトークンを検証してキャッシュ bypass。SSL 検証は ksmd_bootstrap_sslverify フィルタで上書き可能です。

$args = array(
    'timeout'     => 8,
    'redirection' => 0,
    'sslverify'   => apply_filters( 'ksmd_bootstrap_sslverify', true ), // F13
    'headers'     => $headers,
    'user-agent'  => 'KSMD-Bootstrap-Verify/' . KSMD_VERSION,
);

DNS 反映確認

DNS レコードを設定してから実際にブラウザから到達できるまでには TTL に応じた時間 (数分〜数時間) が必要です。コマンドラインで反映状況を確認できます。

dig コマンド (Linux / macOS)

dig md.example.com

# ;; ANSWER SECTION:
# md.example.com.    3600    IN    A    192.0.2.10

ANSWER SECTION に期待した IP が出ていれば反映済みです。反映前は ANSWER SECTION が空、もしくは古い値が返ります。

nslookup コマンド (Windows)

nslookup md.example.com

# Server:  192.168.1.1
# Address: 192.168.1.1#53
#
# Non-authoritative answer:
# Name:    md.example.com
# Address: 192.0.2.10

Cloudflare のキャッシュ

Cloudflare 経由 (オレンジ雲) の場合、Cloudflare のエッジキャッシュも考慮する必要があります。ダッシュボードの「Caching → Configuration → Purge Everything」でエッジキャッシュをパージできます。

TTL の注意点

• 新規にレコードを追加する場合は TTL を一時的に短く (60-300 秒) しておくと、変更時のロールバックが容易です
• 本番運用が安定したら TTL を 3600 秒以上に戻すと、DNS クエリが減って応答速度が向上します
• 古いキャッシュが残っている可能性のある OS / ブラウザでは ipconfig /flushdns (Windows) や sudo dscacheutil -flushcache (macOS) でクリアします

よくある DNS トラブル

md サブドメイン到達時のトラブルでよくあるパターンを表でまとめます。

まとめ

本ページでは md サブドメインを実際に到達可能にするための DNS / SSL / DocumentRoot / index.php について、Bootstrap installer の自動化機能と合わせて解説しました。

• DNS は A / CNAME / Cloudflare 経由の 3 パターン。md サブドメインのレコードを追加
• SSL は Let's Encrypt ワイルドカード or Cloudflare Universal SSL を推奨 (HTTPS 必須)
• DocumentRoot は (a) ABSPATH 直下サブディレクトリ (XServer 標準) or (b) WP 本体の兄弟ディレクトリ (Bedrock 流) のどちらか
• Bootstrap installer は管理画面 1 クリックで index.php を atomic に生成、削除時は 24h バックアップ付き
• 検証は 8 段 hard gate + verify (HMAC + sslverify フィルタ)
• DNS 反映は dig / nslookup で確認、TTL は短めに

次は具体的な設定タブの詳細に進みます。最初は「一般タブ」です。