この記事の目的
※本文は AI が Web 制作者のよしあきさんに代わって、実際の手順や割り切り方を整理し、読者向けに紹介する形で書いています（内容はよしあきさん本人の実務に基づく）。
WordPress サイトを制作するとき、よしあきが 手順とルール（とくにエンドクライアントから要件として明示が無いときのよしあき個人のルール）として決めていることを言語化しておく。一般解の教科書ではなく、よしあきが実際に踏んでいる順番と判断の軸のメモである。
よしあきの対応範囲は実装部分のみである（コーディング、テーマの組み立て、ビルド、検証環境・デプロイとの連携など）。制作会社やフリーランスの Web ディレクターの方と一緒にお仕事することが多く、要件の整理・スケジュール・エンドクライアントとの調整はディレクター側を主とする前提で書いている。そのため記事の見出しも、実装側が着手しやすい順番と割り切りに寄せている。
用語: よしあきにとっての クライアント（契約・連絡の窓口）は主に ディレクターである。一方、サイトの発注者・公開後の運用で管理画面に触る側を エンドクライアント と書き分ける。
要件整理
まず「何を決めれば手が動くか」を整理する。キックオフ前にディレクターや実装側でそろえておくとよい論点は人それぞれだが、よしあきはだいたい次の棚で漏れを確認している。
共通で頭に置く論点
- 案件の性質 … 新規かリニューアルか、既存サーバーやドメインの引き継ぎ範囲、リニューアル時は URL・パス変更やリダイレクトの方針。リニューアルのときは、現行サイトの本文・メディア・構造をどこまで引き継ぐか（丸ごと移行か、一部のみか、書き起こしか）も早めに確定しておく。ここが曖昧だと実装の後半で手戻りが大きくなりやすい。
- 技術・環境・ルール … 静的か WordPress か、本番・検証 URL、Basic の有無、PHP・WP のバージョン、コーディング規約や Git のブランチ方針。
- スケジュール・デザイン … デザイン FIX の定義と期限、ページ単位の提出順、実装納期や中間確認の回数。
- フォント・アセット … フォントの種類とライセンス、自ホストか Web フォントサービスか、画像・動画・ロゴの支給主体と形式。
- その他よく詰まる論点 … アクセス解析・タグ、フォームとメール、多言語、DNS・SSL、アクセシビリティの目標レベルなど。
WordPress 案件だけ追加で
- 投稿をどこで使うか、アーカイブや一覧の要否。投稿本文をブロックで書く前提なら、一覧・詳細テンプレとフロント側の体裁をどこまでテーマで固定するかも含めて決める。
- 固定ページを PHP テンプレ中心で組むか、ブロックエディタで組むか。後者の場合は、テーマ側がブロックスタイルやパターンで「選べるパーツ」を限定する（自由度は下げつつ体裁をそろえる）前提になることが多いので、ディレクター・エンドクライアントと期待値をそろえておく。
- 投稿以外で管理画面から触らせたい範囲（固定のみか、カスタム投稿やフィールドまでか）。
- 権限とプラグイン（必須・禁止、新規導入の可否）。
論点のうち、着手前に合意しておかないと手戻りが大きいものと、キックオフで詰めきらず実装側の判断で進めてよいが、初稿提出時に報告するものとを分けるやり方も、よしあきは併用している（後者は別紙の報告テンプレで「何をよしなにしたか」を書く）。
よしあきルール：管理画面から更新できる箇所は最小限にしたい
よしあきがサイト公開後の更新を想定するとき、いちばん多いのはエンドクライアント側の担当者が本業を持ちながら、業務の合間に管理画面を開くという運用である。この前提では編集できる箇所を増やすほど、覚えることが増えて負担になると見える。そのため「ブロックやフィールドで全部差し替え可能にする」より先に、テーマ側のテンプレとコンポーネントで体裁を固定し、本当に差し替えが必要になったところから管理画面に載せる順番を好み、必要に迫られてから編集可能な範囲を広げる、という割り切りをしている。
一方で、固定ページや投稿本文をブロックで組む案件では「編集できる面を広げる」のではなく、テーマが用意したブロックスタイルやパターンのなかから選んで並べる形に寄せることがある。編集者には自由度が下がるが、許容される見た目のバリエーションをテーマ側で限定できるので、「最小限にしたい」と矛盾しないレールの敷き方としてよしあきは併用している。
よしあきルール：PHP にコンテンツを寄せて進めることが多い（フルサイト編集との対比）
固定ページなどのマークアップや文言を PHP のページテンプレート側に近い形で持つ進め方と、フルサイト編集のようにコンテンツやサイト構造を DB 側に置く進め方の両方がありうる。どちらを採用するかはエンドクライアントが判断するが、よしあきが実装として手を動かして進めるのは 前者が多い。
運用上の理由は、直前の「管理画面から更新できる箇所は最小限にしたい」の冒頭で述べた想定（エンドクライアント側が本業を持ちながら合間に管理画面を開く、など）とつながる。テーマ側で体裁を固定し、更新は必要最小限に寄せやすい進め方と相性がよい。
あわせて、フルサイト編集を前提にした制作フローを、実務で深く扱った経験がまだ薄いことも理由になっている。選択肢として知っておきたい気持ちはある一方で、PHP 側にコンテンツを寄せる進め方に比べて立ち上げや調整に工数がかかりやすいイメージを持っており、現状は要件として強く求められる場面は多くないという印象でもある。
よしあきルール：制作の目的を確認する
サイトやページの目的（何を達成したいサイトか）を一言でもよいから確認しておくと、その後何か判断するときの基準の1つになる。デザインカンプの再現だけに視野が狭まりにくい。
よしあきルール：納品前の品質チェックリストを二段にする
毎回確認するベースのチェックリストに、その案件だけの項目を追記したリストを納品直前に使う。ベースはブラウザ確認・リンク切れ・フォーム・表示崩れ・SEO・セキュリティ設定のざっくりした棚などをよしあき個人用に固定し、案件固有は「多言語がある」「特定プラグインを触る」などだけ足すイメージである。
調査・検証
よしあきが未経験の実装（インタラクションやプラグイン連携など）は、いきなり本番のページに載せず、デモページや検証用の画面をテーマまたはテンプレート側で用意して試す。試した結果はテンプレートリポジトリ側に残す（案件リポジトリだけだと次に再利用しにくいため）。
環境構築・初期設定
- ローカルでは Local で WordPress を動かす。
- テスト環境ではホスティングの WordPress 簡単インストール を活用する（API やパネルから）。
- リポジトリは、手元の WordPress テーマのテンプレートリポジトリから複製する。クラシックテーマ（PHP テンプレート中心）を前提としている。
- サブドメイン作成・サブ FTP・GitHub リポジトリ作成・短文指示での一式セットアップなどは、よしあきは Cursor の Agent Skills と Bash スクリプトで自動化している（手元のプロジェクトルールとスクリプトに依存する）。全体の流れは次の記事にまとめてある。
→ Cursorへの短い指示で、テスト環境（サブドメイン作成・WordPressインストール・GitHubリポジトリ作成）を自動化した話
続いてテーマ側の初期セットアップの例。
- フォントの設置（自己ホストする場合の手順の整理）は、別記事にまとめている。
→ Webフォントを自己ホストする手順と理由：ダウンロード〜body 適用、Skill 化まで
- カスタムプロパティ（
:rootの変数）を登録する。 - 共通のコンテンツ幅と、その左右の余白（コンテナーの決め方）を決める。
- 固定ページのスラッグを運用で追いやすい名前で登録する。
- 投稿まわりは、必要なら デモコンテンツのインポートで一覧・詳細の見え方を先に固める。
構築
- 複数ページで共通になるブロックは、テーマ側で
get_template_partなどを使ったコンポーネント化に寄せる（マークアップとスタイルの重複を減らす）。 - テーマ独自の関数には
ty_接頭辞を付ける。ty_get_nav_items()やty_img()のようにしておくことで、WordPress 本体やプラグインが用意する関数と見分けやすくし、名前の衝突も避けやすくしている。 - 固定ページや投稿本文をブロックエディタで組む方針のときは、フロントの CSS に加えて、編集画面でも体裁が近いように見えるよう
enqueue_block_editor_assetsでエディタ用スタイル（例: テーマ内のcss/admin-style.css）を読み込む。またregister_block_styleでコアブロック（core/group・見出し・リスト・表など）に、デザインに合わせたスタイル変種（背景・枠・下線・リスト装飾など）を登録し、運用側が事前に用意した選択肢のなかからページを組めるようにする。PHP のまとめ役としてfunctions-lib/func-admin-styles.phpのようなファイルに寄せることもある。投稿に力を入れる案件では、アーカイブ・単一投稿のラッパーはテーマのテンプレで固めつつ、本文エリアは同じブロックスタイルで統一しやすい。 - サイト内ナビは
functions-lib/func-nav-items.phpで項目を配列として一元管理し、ヘッダー・ドロワー・フッターなどはty_get_nav_items()をループして描画する。リンクの追加や並び替えを 一か所 にまとめ、ヘッダーだけ直してドロワーが更新されないといった漏れを防ぐ。 - 会社情報・SNS の URL・地図埋め込み用の HTML 断片など、テーマ全体で繰り返し参照する値は
functions-lib/func-constants.phpの定数に寄せる。テンプレートへ出力するときは、esc_html()・esc_url()・wp_kses()を用途ごとに使い分ける（ファイル先頭のメモと、許可タグまわりはfunctions-lib/func-kses-allowed.phpでそろえている）。 - SEO は All-in-One SEO でサイト全体・主要ページの設定を行う（案件やポリシーでプラグインが決まっている場合はそれに従う）。コーダーの担当範囲とテンプレ側の土台の棚卸しは SEO対策の全体像 と WordPress版 にまとめている。
- 画像: **静的サイト（型録のビルド）**では 圧縮に加え AVIF など別フォーマットの生成までビルドに寄せている。WordPress ではテーマの
npm run buildは圧縮を主とし、アップロードされたメディアの WebP／AVIF などフォーマット最適化は EWWW Image Optimizer などプラグインに任せる、という分担にしている。静的との対比や索引は、個人用ナレッジの Wiki 「資産の圧縮・最適化（導線）」 にも書いてある。
デプロイ
- テーマファイル（クラシックテーマ由来の PHP と、
npm run buildなどのビルド成果を含む）については、よしあきは GitHub Actions による自動デプロイを使っている。git pushをきっかけにテスト環境のサーバーへ転送する形で、手元からの手動アップロードと比べて反映の再現性を確保しやすくしている。 - テスト環境へデプロイし、エンドクライアントやディレクターに見せる URL をそこに固定する。
- 管理画面から触る設定や固定ページの本文などは、テスト環境側で済ませる運用に寄せる（本番で初めて触らせない）。
仕上げ
- セキュリティは SiteGuard で各種設定を行う（ログイン制限やファイル名の露出対策など、プラグインの範囲でできること）。
- WordPress が 自動生成するアーカイブや添付の permalink のうち、公開したくないものは 404 に寄せる（テーマの
func-no-auto-generate.phpなどで制御する。WordPress版の SEO 整理 も参照）。案件ごとに「出してよい／だめ」を決める。
ページ構成と固定ページのスラッグが固まったあと（仕上げの工程）、よしあきはテーマ側で管理画面の左メニューを整える（WordPress テーマでは functions-lib/func-admin-menu.php で実装している）。「編集できる場所は増やさない」方針とセットで、公開後にエンドクライアント側が運用で触る機会が多いページだけは、左メニューからすぐ編集画面へ進めるようにしておくイメージである。
- 使わないメニュー（例: コメント）は
remove_menu_pageで一覧から外す（投稿一覧を消すかどうかは、別途「お知らせ」用に投稿ラベルを変えている場合などとの兼ね合いで調整する）。 - エンドクライアントが運用で更新することが多い固定ページは スラッグで指定し、左メニューのトップレベルに「そのページの編集」へのショートカットを足す。ページ ID ではなくスラッグにしているのは、ローカル・検証・本番で投稿 ID がずれても同じコードが効くようにするためである。
- ショートカットは、そのページを編集できるユーザーにだけ表示する。
- プラグインなどが壊れた形式のメニュー項目を追加し、管理画面側でエラーになることがある。そのため
admin_menuの終盤でメニュー配列を検査し、必要なキーが欠けた項目だけ取り除く処理も入れている。
公開
- 本番ドメイン側で WordPress をインストールする（またはホストの手順に従う）。
- テスト環境から All-in-One WP Migration でデータを移行する（ファイルサイズやプラグイン制約は公式ドキュメントとホスト制限を確認）。
- 表示確認（主要ページ・投稿・アーカイブ・404）。
- フォームの送信確認（本番の送信先・スパム対策）。
- 必要なら
.htaccessでリダイレクト（旧 URL、www 有無、HTTPS など）。
あとがき
ここまでが、よしあきにとって「だいたいこの順で、こう割り切っている」という個人用の地図である。案件ごとに、要件整理の棚をチェックリストやスプレッドシートに写して穴埋めするだけでも漏れは減りやすい。よしあきは長い表は非公開メモに逃がしているが、読者側ではこの記事の見出しをそのまま自分用のチェックリストの骨格にしてよい。
関連記事
- SEO対策の全体像と、コーダーが担う範囲 … 静的テンプレの SEO 土台
- SEO対策の全体像（WordPress版） … WP テンプレとプラグインの分担、自動生成 URL の 404 化