2026年7月11日

Apache .htaccessの書き方と活用方法｜構文の基本・効く範囲・httpd.confとの使い分け

Webサーバー・Apache

.htaccess は「そのディレクトリ以下にだけ Apache の設定を追加するファイル」で、書ける内容はサーバー側の AllowOverride で決まり、置いた階層から下のディレクトリすべてに効きます。この記事では、.htaccess の構文の基本、効く範囲と優先順位、500エラーになったときのログの読み方、そして「.htaccess に書くべきか、サーバー設定に書くべきか」の判断基準を説明します。

WordPress のセキュリティ向けの具体的な書き方（重要ファイルの保護など）は別の記事で扱っているため、ここではどんな設定を書く場合にも共通する土台に絞ります。

.htaccessが読まれる仕組み

Apache はリクエストを処理するとき、対象ファイルに至るまでの各ディレクトリに .htaccess があるかを探し、見つかったものを上の階層から順に読み込みます。たとえば /var/www/html/blog/wp-content/uploads/a.jpg へのリクエストなら、/var/www/html/.htaccess、/var/www/html/blog/.htaccess……と順にたどります。

ここから次の性質が導かれます。

下の階層ほど優先される: 親ディレクトリの設定は子に引き継がれ、子の .htaccess で同じ種類の設定を書けば上書きされます。
リクエストのたびに読まれる: 再起動なしで反映される反面、毎回ファイルを探して解釈するぶん処理が増えます。
書いた瞬間から本番に効く: 書き間違えると、保存した直後からそのディレクトリ以下が 500 エラーになります。

例外として、mod_rewrite のルールは既定では親から子へ引き継がれません。サブディレクトリに別の .htaccess を置いて RewriteEngine On を書くと、親側のリライトルールはそのディレクトリでは使われなくなります。WordPress をサブディレクトリに置いたときにパーマリンクが崩れる原因の1つです。

AllowOverrideで書ける範囲が決まる

.htaccess に何を書けるかは、サーバー設定（httpd.conf やバーチャルホスト）の <Directory> にある AllowOverride で決まります。Apache 2.4 では既定値が None で、この場合 .htaccess はそもそも読まれません。

主な値と、それで許可されるディレクティブの例は次のとおりです。

AuthConfig: ベーシック認証など（AuthType、AuthUserFile、Require など）
FileInfo: リライトやリダイレクト、ヘッダー、エラーページなど（RewriteRule、Redirect、Header、ErrorDocument など）
Indexes: ディレクトリ一覧の表示方法など
Limit: アクセス元による許可・拒否（古い Order・Allow・Deny 系）
Options: Options ディレクティブ（ディレクトリ一覧の有効・無効など）
All: 上記をすべて許可

WordPress のパーマリンクを動かすには、少なくとも FileInfo が必要です。レンタルサーバーでは All になっていることが多く、自分で管理する VPS では初期状態が None のことがあるので、「.htaccess に書いたのに何も起きない」場合はまずここを確認します。

# バーチャルホスト側の設定例（.htaccess ではなくサーバー設定に書く）
<Directory /var/www/example.com/public>
    AllowOverride FileInfo AuthConfig Indexes Options
    Require all granted
</Directory>

構文の基本ルール

.htaccess の文法は Apache のサーバー設定と同じで、1行に1ディレクティブを書きます。つまずきやすい点をまとめます。

**ファイル名は先頭のドットを含めて .htaccess**: Windows で作ると拡張子が付いて .htaccess.txt になることがあります。FTP クライアントによってはドットで始まるファイルが既定で非表示なので、「隠しファイルを表示」の設定を確認してください。
文字コードは UTF-8（BOMなし）、改行は LF が無難: BOM 付きで保存すると、1行目が不正なディレクティブとして扱われて 500 エラーになることがあります。
**# で始まる行はコメント**: Apache のドキュメントでは、ディレクティブと同じ行にコメントを書くことはできないとされています。コメントは独立した行に書きます。
**Apache 2.4 では Require を使う**: アクセス制御は Require all denied や Require ip 203.0.113.0/24 の形で書きます。2.2 時代の Order deny,allow と Deny from all は互換モジュール（mod_access_compat）がないと動かず、新旧の書き方を混ぜると意図しない結果になりやすいです。
**モジュールに依存する設定は <IfModule> で囲む**: たとえば Header は mod_headers、ExpiresByType は mod_expires が読み込まれていないと「Invalid command」でエラーになります。囲んでおけば、モジュールがない環境でもサイトは止まりません。

# モジュールがない環境でもサイトが止まらないように囲む例
<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 month"
    ExpiresByType text/css "access plus 1 week"
</IfModule>

# ディレクトリ一覧を表示しない（AllowOverride に Options が必要）
Options -Indexes

# 独自のエラーページ（パスはドキュメントルートからの指定）
ErrorDocument 404 /errors/404.html

ただし、<IfModule> は「書いた設定が効いていないこと」に気づきにくくする面もあります。キャッシュやセキュリティヘッダーのように効いていないと困る設定は、書いた後に実際のレスポンスで確認してください。

よくある活用例と注意点

.htaccess でよく使われる設定を、用途ごとに整理します。

リダイレクト: ドメイン変更や URL の整理。単純な転送なら mod_alias の Redirect 301 /old/ https://example.com/new/ で足ります。条件分岐が必要なら mod_rewrite を使います。
ブラウザキャッシュの指定: mod_expires や Header set Cache-Control で静的ファイルのキャッシュ期間を伸ばします。ファイル名を変えずに中身を更新するとキャッシュが残るので、CSS や JS にはバージョン番号付きの URL を使う運用と組み合わせます。WordPress の wp_enqueue_style() などは ver パラメーターを付けてくれます。
アクセス制限: 管理用ディレクトリを IP アドレスで制限したり、ベーシック認証をかけたりします。
PHP の設定変更: php_value memory_limit 256M のような書き方は、PHP が mod_php で動いている場合にしか使えません。PHP-FPM（多くのVPSや一部のレンタルサーバー）では 500 エラーになるため、.user.ini やサーバー側の設定、あるいはホスティング会社の管理画面を使います。

WordPress の環境では、# BEGIN WordPress から # END WordPress までは WordPress がパーマリンク設定の保存時などに書き換える領域です。自分の設定はこのブロックの外、多くの場合は上に書きます。リダイレクトのように「WordPress に処理が渡る前に判定したい」ものはブロックより上に置かないと効きません。

編集するときの手順と確認方法

.htaccess は保存した瞬間に本番へ反映されるため、次の順で作業すると安全です。

現在の .htaccess をダウンロードし、日付付きの名前で手元に保存する
変更は少しずつ加え、1か所変えるたびにサイトを表示して確認する
500 エラーになったら、すぐに保存しておいた版をアップロードし直す

反映の確認には、ブラウザよりも curl -I https://example.com/ でレスポンスヘッダーを直接見るほうが、ブラウザキャッシュの影響を受けずに判断できます。リダイレクトなら Location ヘッダー、キャッシュなら Cache-Control や Expires、セキュリティヘッダーならその名前が返っているかを見ます。

500 エラーになったときは、サーバーのエラーログに原因が出ています。代表的なメッセージは次の2つです。

Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration: そのディレクティブを提供するモジュールが読み込まれていない、または綴りの誤りです。
xxx not allowed here: AllowOverride で許可されていない種類のディレクティブを書いています。

エラーログが見られない環境では、直前の変更を取り消して切り分けます。

.htaccessとサーバー設定の使い分け

サーバー設定（httpd.conf やバーチャルホストのファイル）を編集できるなら、Apache の公式ドキュメントも、可能な限り .htaccess ではなくサーバー設定に書くことを勧めています。理由は、リクエストごとの探索と解釈がなくなることと、設定が1か所にまとまって管理しやすくなることです。

一方で、次のような場合は .htaccess が適しています。

レンタルサーバーなど、サーバー設定を編集する権限がない
WordPress やプラグインが .htaccess に書き込む前提で動いている（パーマリンク、キャッシュ系プラグインなど）
再起動の権限がない担当者が、特定のディレクトリだけを調整したい

VPS で性能を詰めたい場合は、WordPress の書き出す内容をバーチャルホストに移して AllowOverride None にする方法もあります。ただし、プラグインなどによる .htaccess への書き込みが効かなくなる点を運用者間で共有しておく必要があります。

まとめ

.htaccess は置いた階層から下に効き、下の階層ほど優先される。リライトルールは既定では引き継がれない。
書ける範囲はサーバー側の AllowOverride で決まる。Apache 2.4 の既定は None。
UTF-8（BOMなし）で保存し、2.4 では Require を使い、モジュール依存の設定は <IfModule> で囲む。効いているかは curl -I で確認する。
500 エラーはエラーログの「Invalid command」「not allowed here」で原因がほぼ分かる。編集前のバックアップを手元に残す。
サーバー設定を編集できるならそちらが基本、権限がない場合や WordPress が書き込む領域では .htaccess を使う。モジュール名やディレクティブは Apache 2.4 系を前提にしています（2026年10月現在）。