OpenAI CodexでWordPressを構築｜MakeAIの実装・検証事例

OpenAI CodexでWordPressサイトを作るときは、サイト構成、テーマの実装、記事の管理、公開画面の確認を、一つずつ確かめられる工程に分けます。MakeAIでは、この進め方で自社サイトをWordPressへ移し、記事と相談への導線を整えました。

この記事は、MakeAI自身のサイト構築・運用準備の記録です。2026年9月8日までのファイルと確認記録に基づき、実装したもの、見つかった不具合、公開前に確認したことを紹介します。顧客の成果事例や、検索順位・問い合わせ増加の実績を示すものではありません。

何を作ったか：更新と相談がつながる法人サイト

出発点は、既存のサイトデザインをWordPressで使い、法人向けのサービス、制作例、実務記事を継続的に更新したいという要望でした。画像の動きや読みやすさに加え、記事から自社の課題に合った相談へ進める構成を目指しました。

対象	実装したもの	確認したこと
サイトの骨格	法人研修、AI導入支援、SEO・AIO、AI顧問のサービスページ	各ページの役割、見出し、相談先の対応
見た目と動き	WordPressテーマ、画像の緩やかな動き、中央部分の映像	文字とボタンの位置、スマートフォンでの読みやすさ
記事の運用	通常の投稿として編集できる本文と、固有のアイキャッチ	本文・画像・公開予定日時が管理画面と一致するか
記事間の導線	テーマごとの入口、基本記事と詳細記事の案内	未公開記事をリンク先に出さないか

実際の構成はサービス一覧とMakeAI実務ガイドで確認できます。記事本文を画像一枚にする方式にはせず、見出しや説明をWordPressのテキストとして残しました。文字入りのアイキャッチはGPT Image 2で制作しています。

CodexとGPT-6 Astraを、作業環境とモデルに分けて考える

ここでいうCodexはOpenAIの作業環境を指します。WordPressの旧ドキュメント名「Codex」とは区別してください。GPT-6 Astraは、その作業で利用するモデルの選択肢です。2026年9月8日に確認したOpenAIのモデル案内にも、コード・アプリ・調査を扱うモデルとして掲載されています。

サイトのファイルを編集する、検証用のWordPressを起動する、画面を開いて確認する、という仕事には、それぞれのツールと接続が必要です。モデルを選ぶだけで、サーバーや管理画面へ自動的に接続できるわけではありません。

今回の作業では、ローカルのファイル操作と検証環境、認証済みのWordPress管理画面、ブラウザーでの画面確認を組み合わせました。ブラウザーでページを表示し、操作して結果を確認する使い方は、OpenAIのBrowserドキュメントでも説明されています。使える機能とモデルは利用画面や設定により異なるため、自分の環境で確認します。

この事例は、Astraと他モデルの同条件比較ではありません。サイトの仕上がりを一つのモデルだけの性能として数値化せず、指示、実装、確認をどう組み合わせたかを記録しています。

構築を進めた五つの工程

1．ページごとの役割を決める

サービスの内容と相談を扱うページ、支援選びのガイド、日々の実務記事を分けました。似た検索語を別々の記事で取り合わないよう、主な疑問をどのURLで答えるかも管理します。ページ数を先に増やすより、読者が次に必要とする情報を整理する工程です。

2．元サイトをWordPressのテーマへ移す

既存のデザインと素材をもとに、共通ヘッダー、本文、フッターなどをWordPressで表示できる形にしました。ローカルのプレビューを確認し、運用先のConoHa WING上のWordPressへ反映しています。検証用URLと公開URLを区別し、メニューや画像がローカル環境を参照したままになっていないか確認しました。

3．読みやすさと動きを同時に確認する

画像が動いても、見出しや相談ボタンの位置は動かさない設計に調整しました。トップ画像は緩やかな常時の動きと、ポインターに反応する動きを持ちます。中央部分の映像と合わせ、画面外の動作や動きを減らす設定も確認しています。

この動作の確認記録には、画像の位置が変わった一方、見出しとボタンの位置は維持されたことを残しました。「アニメーションを入れた」という説明だけで終わらせず、読みにくさを増やしていないかを見るためです。

4．記事を編集・予約できる仕組みにする

記事の本文、説明、画像、公開日時を一記事ずつWordPressへ取り込む仕組みを作りました。複数記事の画像処理をまとめた際には処理時間の上限に達したため、一記事ずつ登録し、結果を管理画面で確認する方法へ変更しています。

予約したことと公開されたことは別に記録します。将来のURLがまだ開けないときは、認証済みのプレビューで内容を確認し、一般公開の画面から未公開記事へ誘導していないかも確かめます。

5．公開画面の確認結果を、修正へ戻す

代表的な記事をPC幅1280pxとスマートフォン幅390pxで確認し、画像、表、目次、相談リンクを見ました。コードが正しく動くことと、人が使えることを同じ確認項目にせず、それぞれの結果を残しています。

実際に見つかった不具合：目次から本文の見出しが抜けた

記事の自動目次で、本文の見出しに「調査」などの語が入ると、その見出しまで除外される問題が見つかりました。相談案内や出典の見出しを省くための判定が、本文にも広くかかっていたことが原因です。

確認した状態	修正した考え方	修正後の確認
本文に節があるのに、目次には出ない	見出しの語句で除外せず、相談案内・出典の枠に含まれる見出しだけを除く	該当記事の本文6節がすべて目次に出る
見出しは表示されても、移動先が正しいかは別問題	目次のリンクと本文の見出しIDを対応させる	本番の認証プレビューでリンクを押し、目的の節へ移動する

修正した記事運用プラグインを検証用WordPressで確認し、記事間リンクの13項目と目次の7項目、計20項目が合格した記録を残しました。その後、本番へ反映し、該当記事の目次を再確認しています。これは対象機能の検証結果であり、サイト全体の品質を認証するものではありません。

AIに依頼する際も、「目次を直して」だけでは再発条件が伝わりません。「本文の見出しは語句にかかわらず残す」「相談枠と出典枠だけを除く」「実際に押して移動先を見る」まで、合格条件を書いておくと確認しやすくなります。

自社の制作を依頼するときに渡したいメモ

次のメモは、この構築で必要になった条件を整理したMakeAIの依頼例です。実際の会話の転載ではありません。現在のファイル、対象のWordPress、変更範囲が分かる情報と一緒に渡します。

目的：法人向けサイトをWordPressで更新できる状態にする。
読者：［どの企業の、どの担当者か］
相談につなげる課題：［具体的な業務課題］

材料：現在のサイト、利用できる文章・画像、必要なページ一覧
成果物：テーマ、編集可能な記事本文、画像、公開手順、確認記録

確認条件：
・各ページから、内容に合った相談先へ進める。
・スマートフォンで本文、表、ボタンがはみ出さない。
・画像が動いても、本文とボタンの位置は安定している。
・目次の各項目が、本文の該当見出しへ移動する。
・未公開の記事を一般公開のリンクに出さない。
・登録した公開日時と画像を管理画面で照合する。

変更前に現在の状態を保存し、検証用の環境で確認してから本番へ反映してください。
未確認の項目は、確認できた項目と分けて報告してください。

公開できた後にも残る確認がある

ページの取得、目次、表示、予約状態を確認しても、検索順位や問い合わせの増加までは分かりません。MakeAIでも、Search Consoleの登録とサイトマップの処理は確認しましたが、この構築記録に検索集客の改善率は含めていません。

問い合わせフォームは、画面や入力項目の確認に加えて、実際の送信・受信を別の条件で確認する必要があります。今回の記事では本番のメール到達を検証済みとはしていません。制作を依頼する場合も、どの段階を完了とするか、公開後に誰が何を見るかを先に決めてください。

次に見直すのは、公開された記事が読者の疑問へ答えているか、サービスへの案内が適切か、実際の検索と相談のデータがどう変わるかです。記事の入口と事業ページの関係は、SEO・AIO支援でも説明しています。

同じ進め方を使うなら、変更対象と合格条件を対にする

ここまでの事例を自社へ置き換える際は、「サイトを作って」という依頼を、確認できる変更の単位に分けます。以下は既存の構築記録から整理した作業案です。新しく本番で実施した検証結果ではありません。ページ、記事、共通表示、公開状態を一つの完了報告へまとめず、それぞれの条件を明確にします。

変更単位	依頼する内容	確認してから次へ進む条件
サービスページ	対象者、支援範囲、相談先を整える	本文と相談先が対応し、実際に提供しない内容を含まない
記事一本	本文、画像、説明、公開日時を登録する	指定した内容と日時が対象の記事IDで一致する
共通表示	目次や関連記事の表示を変更する	代表記事だけでなく、見出しの数や状態が違う記事でも確かめる
予約状態	未公開の記事を公開予定に合わせて管理する	管理画面の状態と、一般公開の画面で見える範囲を区別する
フォーム	入力・受付・送信後の案内を整える	画面表示と、送信受付・メール到達を別々に確認する

WordPressでは、投稿の本文、状態、日時、スラッグなどは別の項目です。公式の投稿APIの項目定義でも区別されています。自動登録を組む場合も、返ってきた本文だけを見て公開日時まで正しいと判断せず、変更した項目を対象IDと対応させて照合してください。

更新前の記録には、戻す対象まで含める

変更前の保存では、画面のスクリーンショットだけでなく、元の本文、画像の対応、公開状態、使っているテーマや機能の状態を残します。何を変更したかが分からないままサイト全体を戻すと、別の担当者が進めた記事更新まで失う可能性があります。戻す範囲を、今回変更する範囲と合わせます。

WordPressの公式バックアップ案内は、データベースとファイルの両方を扱っています。記事本文だけの控えは、その記事の差し戻し材料にはなっても、サイト全体の復元手段と同じではありません。制作依頼では、どこまで保存し、どの手順で復元するかを運用担当と確認します。

更新前に残す確認メモ
対象：ページURL、記事ID、変更する機能
変更するもの：本文／画像／テーマ／表示ロジックなど
維持するもの：URL、公開日時、既存の資料リンクなど
保存した旧状態：内容と保存日時、参照できる場所
適用先：検証環境または本番
確認担当：表示、内容、運用の各担当
戻す条件：どの不具合が出たら差し戻すか
戻す範囲：今回の変更と、その影響箇所
未確認：公開後にしか確かめられない条件

このメモへ認証情報やパスワードを記載する必要はありません。作業に必要な接続は適切な管理方法で準備し、記事本文や公開する検証記録に含めないようにします。また、複数人で作業している場合は、適用直前に対象の内容が変わっていないか確認し、古い控えで新しい修正を上書きしない手順を置きます。

表示確認では、普通の例と境界の例を選ぶ

目次の不具合のように、一般的な一記事だけでは見つからない問題があります。確認する記事を選ぶ際は、見出しが多い、長い表がある、資料リンクがある、予約中、本文と出典に似た語があるなど、今回の変更へ影響する条件を選びます。すべての記事へ同じ確認を機械的に繰り返すより、何を確かめるためにその例を選んだかを残します。

目次なら、項目が出るかだけでなく、押したときに該当見出しへ移るか、固定ヘッダーで見出しが隠れないかを見ます。表なら、狭い画面で数字や列の対応が読めるか、横へ動かせる場合はその操作が分かるかを確認します。リンクなら、目的のページが開くかに加え、表示文と行き先の内容が一致するかを確認します。これらは追加の確認案であり、本事例の全ページで実施済みとするものではありません。

不具合を報告するときは、対象URL、画面幅、再現する操作、期待した状態、実際の状態を一組にします。「スマホで崩れる」だけでは、再現条件が不足します。修正後は同じ条件へ戻って確認し、関係する別の状態へ影響していないかを見ます。

公開後の引継ぎでは、実装した項目、確認済みの条件、未確認の条件、更新時に見る場所を分けます。例えば記事を予約できたことと、予定時刻に公開されたこと、検索に表示されたことは別の確認です。サイトを作る工程と、運用して成果を見る工程をつなぎながら、それぞれで確認した範囲を正確に残してください。