WordPressを始めたいミカ
ミカ

ねぇねぇ、佐藤さん！自分のWordPressサイトを作ってみたいです。でもサーバーもまだ契約していないし、プログラムも分かりません。こんな状態からCodexに相談しても大丈夫ですか？

最初の一歩を案内する佐藤さん
佐藤さん

もちろん。最初は「どんな人に何を伝えるサイトを作りたいか」だけで大丈夫だよ。サーバーが必要な人、まずパソコンで試したい人、今あるサイトを直したい人で入口を分けよう。

安心して始めるミカ
ミカ

最初から専門用語を全部覚えなくても、作りながら必要なことを確認できるんですね。

完成まで寄り添う佐藤さん
佐藤さん

そうだよ。Codexと一緒に一段ずつ進めて、画面を確認しながら完成に近づけよう。契約や公開の前だけ、内容を一緒に確認すれば安心だよ。

Codexを使えば、WordPressサイトの構成を一緒に考え、必要なページを作り、パソコンやスマートフォンで確認しながら公開まで進められます。 プログラムを一から覚えてから始める必要はありません。

まだサーバーを契約していなくても大丈夫です。「新しくWordPressを始める」「現在のサイトを直す・移す」「まずパソコン上で試す」の3つから、自分に合う開始方法を選べます。

この記事は、Codexを使ったWordPressサイト作成の全体案内です。作業フォルダの選び方から、依頼文、テーマや固定ページの作成、表示確認、公開後の点検まで順番に説明します。まずは全体の地図を眺め、自分が今いる段階から読み進めてください。

「ChatGPTでもコードを作れるのに、なぜCodexを使うのか」から確認したい人は、先に Codexとは何かとChatGPTとの違い を読むと、相談と実ファイル作業の境界が分かります。

Codexの画面や利用できる機能は更新されます。操作名がこの記事と異なる場合は、 公式OpenAI DocsのQuickstart と実際の画面を優先してください。

まずは完成までの7段階を見てみよう

  1. 目的を決める： 誰に何を伝えるサイトかを一文にする。
  2. 環境を揃える： サーバー、ドメイン、WordPress、作業フォルダを確認する。
  3. 守る範囲を決める： バックアップを取り、変更禁止事項を書く。
  4. 現状を調査する： 新規か既存か、テーマ・プラグイン・公開方法を把握する。
  5. 小さく作る： 一度に全体を変えず、ページや機能単位で実装する。
  6. 表示と動作を検査する： PC、スマートフォン、リンク、画像、フォームを確認する。
  7. 公開後も確認する： 公開URL、キャッシュ、検索設定、エラー、復旧手順を見る。

一段ずつ確認してから次へ進めば大丈夫です。たとえばバックアップをまだ確認できていなければ、先に戻し方を確かめます。表示に問題があれば、公開前にその部分を直してもう一度確認します。

Codexが担当すること、人が担当すること

作業 Codexが支援できること 人が決めること
企画 要望の整理、ページ案、確認質問 サイトの目的、読者、掲載してよい情報
調査 ファイル構成、設定、既存機能、原因候補の確認 調査対象に含めてよいデータとサービス
制作 コードや文章の下書き、差分の提示、テスト デザイン、文言、公開品質の最終判断
公開 公開前検査、手順整理、許可後の操作 公開日時、外部への反映、費用が発生する操作
保守 不具合調査、更新差分、確認記録 更新の採用、停止、削除、復旧の判断

Codexは作業結果を説明できますが、その説明と実際の公開状態は別です。「変更しました」という返事だけで完了にせず、ファイル差分、テスト結果、ブラウザ表示の三つを確認します。

新規サイトか既存サイトかを最初に分ける

新規サイトは、まだ守る公開データが少ない代わりに、サイトの目的や構成を決める必要があります。既存サイトは、読者、URL、検索評価、問い合わせ、会員情報などを守りながら変更しなければなりません。

  • 新規サイト： 完成条件、必要ページ、公開前の非公開方法、初期デザインから決める。
  • 既存サイト： 現状のURL、使用中テーマ、プラグイン、PHP、データベース、公開方法を先に調べる。

既存サイトで「新しく作り直してください」とだけ依頼すると、残すべきURLや機能を見落とします。最初に「現在動いているものを壊さない」「URLを変えない」「調査だけでまだ修正しない」などの条件を伝えてください。

サイトの目的を一文で決める

目的は「おしゃれなサイト」ではなく、誰が、何を知り、次に何ができるサイトかで書きます。たとえば「地域の教室を探している保護者が、日時と料金を確認して体験を申し込めるサイト」のようにします。

目的が決まったら、次の五項目を書き出してください。

  1. 主な読者
  2. 読者が抱えている疑問
  3. 読後または閲覧後にできること
  4. 絶対に必要なページ
  5. 今回は作らない機能

「今回は作らない機能」を決めると、会員登録、予約、決済、多言語などが途中で増え続けるのを防げます。

Codexを使い始める準備

この記事では、パソコン上の作業フォルダを扱いやすいCodexのデスクトップアプリを中心に説明します。 公式OpenAI DocsのQuickstart を確認し、次の順で準備します。

  1. 自分のOSに対応したデスクトップアプリを公式案内から入手する。
  2. ChatGPTアカウントでサインインする。
  3. 新しいチャット、プロジェクト、作業フォルダのどれを使うか選ぶ。
  4. WordPress案件の作業フォルダを開く。
  5. 最初の依頼は修正ではなく、フォルダ構成と現状の説明にする。

Codex CLIやIDE拡張を使う方法もありますが、最初から複数の操作方法を混ぜる必要はありません。まず一つの環境で、対象フォルダ、変更差分、確認結果の関係を理解してください。

WordPress環境を用意する3つの方法

方法 向いている状況 最初に確認すること
新しいサーバーにWordPressを設置 初めてサイトを作る ドメイン、SSL、管理画面、ファイルへアクセスする方法
ローカル・検証環境を作る 公開前にデザインや機能を試す 本番との差、データの持ち込み、公開方法
既存サイトのコピーを使う 運営中サイトを安全に改修する コピー日時、個人情報の除外、本番へ戻す差分

新しくサーバーを選ぶ必要がある場合は、特定の商品を急いで契約せず、 WordPress用レンタルサーバーの選び方 で、新規・移行・複数サイトのどれかを先に決めてください。この記事では契約そのものではなく、WordPressへアクセスできる状態から先を扱います。

初心者が先に覚える6つの言葉

ローカル 自分のパソコン側にある作業環境です。変更しても直ちに公開サイトへ出ない構成があります。 本番 一般の利用者がアクセスする公開環境です。変更の影響が外部へ出ます。 検証環境・ステージング 本番へ出す前に、更新や表示を試すための環境です。 差分 変更前と変更後で、どのファイルのどこが変わったかを示す情報です。 デプロイ・配備 手元や管理場所の変更を、サーバーなどの利用環境へ反映する作業です。 ロールバック・復旧 問題が出た変更を戻し、確認済みの状態へ戻す作業です。

サイトによって、保存しただけで本番へ反映される場合と、別の公開操作が必要な場合があります。用語だけを覚えるのではなく、この案件では何がどの環境を指すか確認してください。

作業フォルダを選ぶミカ
ミカ

Codexでフォルダを開く時、WordPressが入っているサーバー全体を選べばよいですか。広い場所を選んだ方が、必要なものを全部見つけてもらえそうです。

範囲を注意する佐藤さん
佐藤さん

広すぎる場所には、別サイトやバックアップ、設定、秘密情報が含まれることがあるよ。今回変更するプロジェクトだけを作業フォルダにしよう。

権限を確認するミカ
ミカ

読むだけの調査と、実際に書き換える作業では必要な権限も違うのですね。

最小権限を示す佐藤さん
佐藤さん

最初は読み取り中心で現状を把握し、変更が必要な場所だけ書き込みを許す考え方が安全だよ。ネット接続や公開操作も、必要になった段階で判断しよう。

Codexで正しい作業フォルダを開く

公式OpenAI Docs では、デスクトップアプリでチャット、プロジェクト、フォルダを選び、選択したフォルダ内のファイルを読み書きできる流れが案内されています。したがって、最初の重要な判断は「どのフォルダを作業範囲にするか」です。

WordPress本体をすべて複製したフォルダを開く場合もありますが、テーマやプラグインだけを開けばよい案件もあります。次を確認してください。

  • フォルダの絶対パス
  • 本番、検証、バックアップのどれか
  • Git管理されているか
  • WordPress本体、テーマ、プラグインの配置
  • アップロード画像やデータベースが別管理か
  • 同じ階層に別サイトがないか

フォルダ名だけで本番と判断しないでください。「このフォルダは何のコピーか」「変更がどこへ反映されるか」を確認してから編集します。

権限は必要最小限から始める

Codexの権限は、ローカルコマンドが読める場所、書き込める場所、ネットワーク接続などの境界になります。 公式OpenAI DocsのPermissions でも、読み取り、書き込み、拒否を使い分け、タスクを完了できる最も狭い権限を選ぶことが案内されています。

初心者は、次の順番で考えると安全です。

  1. 構成確認だけなら、まず読み取りで調査する。
  2. 編集が必要になったら、対象プロジェクトだけ書き込み可能にする。
  3. 環境変数、認証情報、バックアップは対象外にする。
  4. インターネット接続は公式情報の確認など、目的を決めて使う。
  5. 公開、削除、契約など影響の大きい操作は実行前に確認する。

APIキー、FTPパスワード、WordPress管理者パスワードを依頼文へ直接貼らないでください。ログインが必要な画面は、自分でログインしてから必要な範囲の操作を依頼します。

変更前にバックアップと戻し方を確認する

既存サイトの変更前に保存対象と復元可否を判定する場合は、 WordPress作業前のバックアップ完全チェックリスト を使い、DB・ファイル・外部保管・復元入口を一組で確認できます。

バックアップは「あるらしい」では不十分です。何が保存され、どの日時へ、どの手順で戻せるかを確認します。

対象 確認する内容 戻した後の確認
データベース 投稿、設定、ユーザー、フォーム情報を含むか 管理画面と主要ページが開く
wp-content テーマ、プラグイン、uploadsが含まれるか 画像、デザイン、機能が戻る
設定ファイル wp-config.php、Webサーバー設定、転送設定 DB接続、HTTPS、旧URL転送が正常
コード差分 Gitまたは変更前コピーがあるか 変更したファイルだけ戻せる

バックアップ取得と復元可能性は別です。重要サイトでは、公開前に検証環境で復元手順まで確認してください。

Codexに最初に読ませる説明を用意する

毎回同じ条件を伝える代わりに、プロジェクトの説明ファイルを置く方法があります。 公式OpenAI DocsのAGENTS.mdガイド では、Codexが作業前にAGENTS.mdを読み、全体方針とディレクトリごとの指示を組み合わせる仕組みが説明されています。

WordPress案件では、少なくとも次を記録します。

  • サイトと作業フォルダの関係
  • 必読ドキュメント
  • 触ってよい場所・触らない場所
  • 本番公開に必要な許可
  • バックアップと復旧方法
  • 使用禁止の外部サービスや処理
  • 完了時に必ず行うテスト

長期作業では、完了済みと未実施を分けた現状ファイルも有効です。「原稿作成済み」と「本番公開済み」を同じ完了扱いにしないよう、状態を具体的に書きます。

最初の依頼文は6要素で作る

目的：地域の教室サイトのトップページを改善したい
対象：指定したWordPressテーマのトップページとCSS
現状：PCでは表示できるが、スマホで申込ボタンが見つけにくい
変更禁止：既存URL、問い合わせフォーム、公開中の記事は変えない
完成条件：390px幅で横スクロールがなく、申込ボタンへ進める
進め方：まず調査結果と変更案を示し、修正後にPC・スマホを確認する

「WordPressをよくしてください」だけでは、範囲と完成条件が決まりません。最初から完璧な依頼文を書く必要はありませんが、目的、対象、現状、禁止事項、完成条件、進め方の六つがあると、確認質問を減らせます。

依頼文を準備したミカ
ミカ

目的と禁止事項を書けました。次は、トップページ、固定ページ、記事、フォームをまとめて作ってもらえば早いでしょうか。

小分けを勧める佐藤さん
佐藤さん

最初に全体計画は作ってよいけれど、実装と確認は小分けにしよう。共通ヘッダーを直した後に全ページが崩れると、原因を探しにくいからね。

確認単位を考えるミカ
ミカ

一つ変更したら、関係するページを確認してから次へ進むのですね。

反復手順を示す佐藤さん
佐藤さん

調査、変更、テスト、ブラウザ確認を一組にしよう。合格した組だけ積み上げると、最後の修正量が小さくなるよ。

一度に全サイトを変更しない

全体設計はまとめて作っても、実装は小さな単位に分けます。おすすめの順番は、共通レイアウト、トップページ、固定ページ、記事テンプレート、フォーム、検索や絞り込み、細部の装飾です。

各単位で次を繰り返します。

  1. 変更前の状態を記録する。
  2. 対象ファイルと影響範囲を説明してもらう。
  3. 必要最小限の変更を行う。
  4. 構文検査やテストを行う。
  5. ブラウザで見た目と操作を確認する。
  6. 問題がなければ次の単位へ進む。

複数の不具合を同時に直す場合も、原因が別なら変更を分けます。後から一つだけ戻せる状態が理想です。

テーマ変更は構造を調べてから行う

WordPressの見た目は、クラシックテーマ、ブロックテーマ、子テーマ、独自テーマで変更場所が違います。最初にテーマ名だけで判断せず、テンプレート、テンプレートパーツ、functions.php、CSS、テーマ設定のどこが画面を作っているかを調査します。

既存サイトでは、親テーマを直接変更すると更新で消える場合があります。独自テーマでも、共通ヘッダーの変更が全ページへ影響します。詳しい判断は既存の WordPressテーマの選び方と変更リスク も参照してください。

プラグインは追加前に既存機能を調べる

欲しい機能があるたびにプラグインを追加すると、同じ機能の重複、表示速度、更新、競合、削除後のデータが問題になります。Codexへ「おすすめを入れて」ではなく、「この機能は既存テーマやプラグインにあるか。追加なしで実現できるか。追加する場合の影響は何か」を調べてもらいます。

追加が必要なら、検証環境で一つだけ有効化し、管理画面、公開ページ、フォーム、ログを確認します。詳しくは WordPressプラグインの選び方 で判断できます。

文章・画像・個人情報を分けて扱う

サイト制作では、コード以外の情報にも注意が必要です。

  • 文章： 事実、名称、住所、料金、日付を原資料と照合する。
  • 画像： 利用権、人物の同意、代替テキスト、容量を確認する。
  • 個人情報： 問い合わせ内容や顧客データを作業用サンプルへ使わない。
  • 認証情報： パスワード、秘密鍵、APIキーを記事やログへ残さない。

テスト用には架空の氏名、メールアドレス、内容を使います。本番データが必要な調査では、項目名や件数だけで判断できないか先に検討してください。

テスト完了を急ぐミカ
ミカ

ページが表示されたので完成だと思いました。でも、スマートフォンでは表が右にはみ出し、問い合わせの送信確認もまだです。

表示だけでは不十分と伝える佐藤さん
佐藤さん

一つのPC画面で開けることは、確認項目の一つにすぎないよ。見た目、操作、データ、検索設定を分けて確認しよう。

確認表を作るミカ
ミカ

ページごとに、PC、スマホ、リンク、画像、フォーム、タイトルを記録すれば漏れを見つけやすそうです。

合格条件を示す佐藤さん
佐藤さん

よい方法だね。確認した証拠が残れば、次の更新でも同じ基準を使えるよ。

PCとスマートフォンで表示を確認する

最低でもデスクトップ幅とスマートフォン幅で、次を確認します。

  • 横スクロールが発生していない
  • 見出しやボタンが画面外へ出ない
  • 画像がつぶれず、代替テキストがある
  • 表やコードが読める
  • メニューを開閉できる
  • フォーム項目とエラー文が見える
  • キーボード操作でも主要リンクへ進める

ブラウザの幅を変えただけでなく、可能なら実機でも確認します。ログイン中だけ表示される管理バーやキャッシュの影響にも注意してください。

リンク・画像・フォームを動作確認する

見た目が正常でも、リンク先が404、画像が読み込めない、フォームが送信されない場合があります。内部リンクと外部リンクのURL、画像のHTTP応答、フォームの入力エラー、完了画面、管理者通知を確認します。

フォームは、本番の相手へ誤送信しないテスト条件を決めてください。「送信完了」と表示されることと、メールが受信箱へ届くことは別の確認です。

公開前にSEOの最低限を確認する

検索順位を保証する作業ではなく、検索エンジンが誤ったURLや内容を受け取らないための確認です。

  • ページごとにtitleとH1が内容を表している
  • canonicalが正しい公開URLを示す
  • 公開するページがnoindexになっていない
  • 準備中・会員専用ページを誤ってindex対象にしない
  • sitemapに正しいURLだけが含まれる
  • 旧URLを変える場合は転送と内部リンクを確認する

検索に出ない時の切り分けは WordPress SEOの入口ガイド へ進んでください。

公開操作は明示的に分ける

ローカル保存、CMSの下書き保存、Revision保存、本番公開、サーバー配備は別の状態です。依頼文でも「保存して」と「公開して」を同じ意味で使わず、どこまで実施するかを書きます。

公開前には、対象、変更内容、戻し方、確認URLを一覧にします。外部へ見える変更、料金が発生する操作、データ削除、メール送信は、実行直前にもう一度確認する運用が安全です。

公開後の違いに気づくミカ
ミカ

下書きのプレビューは正常だったのに、公開URLでは古いCSSが残っていました。公開ボタンを押せば同じ表示になるわけではないのですね。

公開後確認を促す佐藤さん
佐藤さん

キャッシュ、CDN、書き出し処理、公開先の違いがあるからね。公開したURLを新しい条件で開き直して確認しよう。

周辺ページも見るミカ
ミカ

変更したページだけでなく、トップ、カテゴリ、サイトマップ、以前のURLも確認する必要がありますね。

公開完了を定義する佐藤さん
佐藤さん

そこまで確認して初めて公開完了と言えるよ。問題があれば、追加変更を重ねる前に原因を記録しよう。

公開後に必ず同じURLを開き直す

  1. 公開URLがHTTP 200で開く。
  2. タイトル、H1、本文、画像が最新版である。
  3. PCとスマートフォンで横幅超過がない。
  4. 主要リンクとフォームが動く。
  5. canonical、robots、OG情報が正しい。
  6. カテゴリ、トップ、sitemapなど必要な導線へ反映されている。
  7. 旧URLがある場合は、意図した転送または公開状態になっている。

キャッシュの疑いがある場合は、むやみに全削除する前に、どの層のキャッシュかを分けます。ブラウザ、WordPress、サーバー、CDNでは確認方法と影響が違います。

失敗した時は追加修正より先に止める

画面が白い、管理画面へ入れない、保存前と違うURLへ飛ぶなどの問題が出たら、推測で設定を重ねないでください。

  1. 追加の変更と公開を止める。
  2. 症状が出るURL、時刻、操作、エラー文を記録する。
  3. 直前に変えたファイルや設定を確認する。
  4. ログとHTTP状態を確認する。
  5. 一つの原因候補だけを検証する。
  6. 必要なら確認済みバックアップへ戻す。
  7. 復旧後に同じ確認表を実行する。

「とりあえずプラグインを全部停止」「設定を全部戻す」は影響が広すぎます。緊急時でも、対象と復旧確認を決めてから実施します。

作業記録を次のチャットへ引き継ぐ

長い作業では、会話だけを履歴にしません。次の内容をMarkdownなどの文書へ残します。

  • 完了した作業と確認結果
  • 保存したが未公開の作業
  • まだ実施していない作業
  • 触ってはいけない記事、URL、機能
  • 公開・配備・外部サービスの状態
  • 次に行う一つの作業

日付と状態を添えると、新しいチャットでも「公開済み」と「提案だけ」を混同しにくくなります。古い項目を消さず、後から完了記録を追加する方法も有効です。

全体工程を整理できたミカ
ミカ

Codexに全部任せる方法ではなく、私が判断しながら一緒に作る手順だと分かりました。次は何から始めればよいですか。

開始地点を選ぶ佐藤さん
佐藤さん

新規なら目的と必要ページ、既存ならバックアップと現状調査から始めよう。まだサーバーやWordPressがなければ、環境準備を先にするよ。

一つ目の依頼を作るミカ
ミカ

目的、対象、禁止事項、完成条件を書いて、まず調査だけお願いしてみます。

安全な一歩を確認する佐藤さん
佐藤さん

よい始め方だね。調査結果を読んで、変更範囲に納得してから最初の小さな実装へ進もう。

今日行う最初のチェックリスト

  1. 新規サイトか既存サイトかを決める。
  2. サイトの目的を一文で書く。
  3. 今回必要なページと、作らない機能を書く。
  4. Codexで開く作業フォルダの絶対パスを確認する。
  5. 本番・検証・バックアップのどれかを確認する。
  6. 既存サイトなら復旧できるバックアップを確認する。
  7. 変更してはいけない場所と操作を書く。
  8. 最初は「調査のみ」で現状を説明してもらう。
  9. 最初の変更単位と合格条件を一つ決める。

よくある質問

プログラミング経験がなくてもCodexでWordPressサイトを作れますか？

可能ですが、契約、個人情報、公開、削除などの判断まで任せきりにはしません。目的、変更範囲、完成条件を言葉にし、変更後の画面を確認できることが重要です。

WordPress管理画面のパスワードをCodexへ貼ってよいですか？

貼らないでください。必要な画面は自分でログインし、認証情報そのものを会話、記事、ログ、作業ファイルへ残さないようにします。

最初から本番サイトを変更してもよいですか？

重要な既存サイトでは推奨しません。バックアップと復元手順を確認し、可能なら検証環境またはローカルコピーで変更とテストを行います。

Codexの「完了しました」という返事で作業完了ですか？

返事は完了の証拠ではありません。ファイル差分、テスト結果、公開URLのブラウザ表示を確認し、合格条件を満たした時に完了とします。

テーマとプラグインを一度に変更できますか？

技術的に可能でも、問題が起きた時に原因を分けにくくなります。テーマ、プラグイン、フォームなどを小さな単位に分け、確認後に次へ進んでください。

AGENTS.mdには何を書けばよいですか？

プロジェクトの目的、必読文書、作業範囲、禁止事項、テスト、公開条件など、毎回守るルールを書きます。秘密情報は記載しません。

Codexにインターネットを自由に使わせる必要がありますか？

必須ではありません。公式情報の確認や依存関係の取得など、必要な目的と接続先を決め、タスクを完了できる狭い権限から始めます。

公開後に不具合が見つかったらどうしますか？

追加変更を止め、URL、時刻、症状、直前差分を記録します。原因候補を一つずつ検証し、必要なら確認済みバックアップへ戻してから再確認します。

まとめ：Codexと確認しながら一段ずつ作る

CodexでWordPressサイトを作る基本は、正しい作業フォルダ、必要最小限の権限、戻せるバックアップ、具体的な依頼文、小さな変更、ブラウザ確認です。 大きな一回の依頼より、合格した変更を一つずつ積み上げる方が、安全で説明可能なサイトになります。

新規サイトの人は目的とページ構成から、既存サイトの人はバックアップと現状調査から始めてください。まず自分とCodexの役割を整理したい人は、 CodexでWordPressサイト作成はどこまでできるか で、任せやすい作業・一緒に決める作業・本人確認が必要な作業を仕分けできます。

作業へ入る前に、 CodexでWordPressを始める前の準備 で、必要なアカウント、情報、権限を具体的な準備表へ分けてください。サーバー未契約、WordPress設置済み、既存サイト改修のどの入口かも確認できます。

作業フォルダの準備後に実装へ進む人は、 Codexで最初のWordPressトップページを作る実践 で、表示元の調査、入口部分の設計、PC・スマホ確認までを順番に進められます。

次に読むと理解しやすい記事

このカテゴリを順番に読む

このページを入口に、同じカテゴリの記事へ進めます。