AIコーディングで作ったWebサイトの品質チェックリスト｜公開前に確認する表示・SEO・保守性
VIEW →
CodexをWeb制作で使う方法｜要件整理・実装・品質確認・CMS更新の実務フロー
私はWebサイトの制作と運用で、要件整理、既存コードの調査、実装、品質確認、CMS更新までCodexを使っています。
Codexはコードを書くだけのツールではありません。ローカルのリポジトリを調べ、必要なファイルを編集し、ビルドなどのコマンドを実行できます。MCPで外部サービスと接続すれば、CMSに保存されているデータの確認や更新も同じ作業の中で進められます。
ただし、依頼を一文だけ渡して、出力されたコードをそのまま公開しているわけではありません。変更する範囲と完成条件を先に決め、既存の実装を確認してから手を入れ、コード・画面・公開ページをそれぞれ確認します。外部サービスへの書き込みや公開は、ローカルでの作業とは分けて指示しています。
この記事では、当サイトの制作と運用で実際に行っている流れをもとに、CodexをWeb制作へ組み込む方法を紹介します。特定の機能だけを取り上げるのではなく、依頼を出してから公開後の状態を確認するまでを一つの流れとして扱います。
先に結論：Codexには実装だけでなく、調査と確認まで任せる
私がCodexを使うときは、作業を次の7段階に分けています。
- 目的、対象、完成条件を決める
- 既存のコードとデータを調べる
- 対応方針を決め、対象を限定して実装する
- 差分、ビルド、画面、生成結果を確認する
- 必要な場合だけCMSへ下書きや更新を反映する
- 公開前に文章、表示、SEO、公開NG情報を確認する
- 明示的な公開判断の後、公開ページを確認する
Codexへ任せる工程を増やしても、サイトの目的やデザイン、掲載する情報、公開の可否まで自動的に決めてもらうわけではありません。現在の役割分担は次のとおりです。
工程 | Codexで行うこと | 私が判断すること |
|---|---|---|
要件整理 | 依頼を対象、制約、確認項目へ分解する | 目的、優先順位、完成条件 |
調査 | 関連ファイル、既存実装、CMSの構成、公式資料を確認する | どの仕様や設計を採用するか |
実装 | 対象ファイルやコンテンツを変更する | デザインや内容が意図に合っているか |
品質確認 | 差分、ビルド、HTML、リンク、画面を検証する | 公開できる品質か |
CMS操作 | データ取得、下書き作成、指定した記事の更新を行う | 書き込む対象と公開の可否 |
重要なのは、AIに任せる作業と、人が責任を持って決めることを混ぜないことです。
今回紹介する利用環境
この記事は、2026年8月29日時点の当サイトの制作・運用環境をもとにしています。
項目 | 内容 |
|---|---|
フロントエンド | Next.js 15.4.10 |
CMS | microCMS |
ホスティング | Cloudflare Pages |
Codexで扱う範囲 | コード調査、実装、テスト、記事制作、CMS操作、公開確認 |
作業ルール | リポジトリ内のSkillとして管理 |
CMSとの接続 | microCMS公式MCP |
OpenAIのCodex CLI公式ドキュメントでも、ローカルのリポジトリを調べ、ファイルを編集し、インストール済みの開発ツールを実行できると説明されています。
ここからは、私がどの順序で使っているかを具体的に説明します。
1. 依頼は「対象・現状・完了条件・禁止事項」に分ける
Codexへ依頼するときは、実装方法を細かく指定する前に、何のための変更かを伝えます。
最低限決めているのは、次の4点です。
- 対象：変更するページ、機能、記事
- 現状：起きている問題、参考にする既存ページや仕様
- 完了条件：ビルド、画面、HTML、CMSなど、どこまで確認するか
- 禁止事項：変更しない範囲、許可していない更新や公開
依頼するときは、次のような形に整理しています。
目的:
- この変更で解決したいこと
対象:
- 変更するページ、機能、記事
現在の状態:
- 起きている問題
- 参考にする正常なページや既存実装
完了条件:
- 実行するテスト
- 確認する画面や生成結果
禁止事項:
- 変更しないファイルやデータ
- 許可していない作成、更新、公開、削除
すべての依頼で長いテンプレートを書く必要はありません。ただし、本番サイトや外部サービスへ影響する作業ほど、対象と禁止事項を具体的にします。
「実装が終わること」と「目的を満たしたこと」も分けます。たとえばtitleの修正であれば、コードを変更しただけでは完了にせず、生成されたHTMLの<title>やOGPまで確認します。フォームの修正であれば、見た目だけでなく入力、エラー表示、送信後の挙動までを完了条件に含めます。
2. 新しいコードを書く前に、既存の仕組みを調べる
既存サイトの修正では、すぐにコードを書き始めるよりも、現在の設計を把握する方が先です。
私が実装前に確認しているのは、主に次の内容です。
- 関連するページとコンポーネント
- データを取得している箇所
- 同じ処理を実装済みのページ
- CMSのAPIとフィールド構成
- 使用しているパッケージとバージョン
- 作業前から存在する未コミットの変更
当サイトのカテゴリーページでtitleが正しく出力されていなかったときも、修正自体は既存の共通コンポーネントへカテゴリ名を渡す1行の変更でした。先にデータ取得とほかのページを確認したことで、専用処理やCMSのフィールドを増やさず、既存の仕組みに揃えられました。
この例で重要なのは変更量ではなく、原因を調べてから最小限の修正を選んだことです。Codexにはコードの生成だけでなく、関連箇所の検索、処理の流れの整理、既存実装との比較も任せています。
3. 繰り返す判断基準はプロジェクト専用のSkillへまとめる
毎回同じ指示を長いプロンプトへ書くと、伝え忘れや作業ごとの差が出ます。そこで、繰り返し使う手順や品質基準は、プロジェクト専用のSkillへまとめています。
OpenAIのSkills公式ドキュメントでは、Skillはタスク固有の指示、参照資料、任意のスクリプトをまとめる仕組みとして説明されています。リポジトリ内の.agents/skillsへ置けば、そのリポジトリで使うルールとして管理できます。
当サイトでは、記事作成用のSkillを次の構成にしています。
ファイル | 定義している内容 |
|---|---|
| 記事作成の手順、品質基準、CMS操作の境界 |
| 口調、構成、断定と留保の基準 |
| 一次情報の優先順位、確認方法、公開条件 |
ここには、一次情報を優先すること、実体験と公式仕様を分けること、AIらしい過度な保険表現を加えないことも定義しました。公開品質は曖昧な免責文で担保せず、事実確認と公開前レビューで担保します。
また、「記事を書いて」という依頼だけではCMSを更新せず、「入稿して」「公開して」といった指示がある場合だけ該当する操作を行うようにしています。
Skillには共通ルールを置き、今回だけの目的や完了条件は依頼ごとに伝える。この分け方にすると、指示を短くしても基準を維持できます。
4. 実装後は、差分・実行結果・画面を別々に確認する
Codexが変更内容を説明しても、その説明だけでは完成と判断しません。
変更後は、次の順序で確認します。
git diffで変更したファイルと内容を確認する- lint、テスト、ビルドのうち、変更に対応する確認を実行する
- 開発環境やプレビュー環境で画面と操作を確認する
- titleやcanonicalなど、画面だけで分からない項目は生成されたHTMLを確認する
- 公開後にしか確認できない項目は、公開URLでも確認する
これらは同じ確認ではありません。ビルドが成功しても、スマートフォンで余白やメニューが崩れていることがあります。画面上の見出しが正しくても、<head>内のtitleが古いままのこともあります。CMSで公開済みになっていても、静的サイトの再ビルドが終わるまでは公開ページへ反映されません。
デザインカンプとの差分、レスポンシブ表示、操作性、SEO、保守性まで含めた確認項目は「AIコーディングで作ったWebサイトの品質チェックリスト」へまとめています。本記事ではチェック項目を重複させず、Codexを使った作業の中で、いつ確認するかに焦点を当てます。
5. MCPでCMSのデータも同じ流れに含める
Web制作では、コードだけでなく、CMSに保存されたページや記事、カテゴリーなども扱います。テーマやフロントエンド側で決めたslugと、CMS側のデータが分かれていると、転記や確認の作業が増えます。
MCP（Model Context Protocol）は、Codexから外部のツールや情報へ接続する仕組みです。OpenAIのMCP公式ドキュメントでは、Codexから外部のドキュメントや開発ツールへアクセスできると説明されています。
当サイトではmicroCMS公式MCPを接続し、次の操作を実際に確認しました。
- 利用可能なAPI一覧の取得
- コラムAPIのフィールド構成の取得
- 記事一覧と記事詳細の取得
- 検証用記事の下書き作成と更新
- 記事本文、カテゴリー、slugの入稿
- 明示的な指示後の公開
microCMSの公式MCP Serverドキュメントでも、コンテンツの取得、作成、更新などのツールと、利用するAPIに対応した権限設定が案内されています。
接続方法やリッチエディタへの入稿結果は「microCMS公式MCPをCodexで使う方法」で詳しく紹介しています。ここでの要点は、コード作業とCMS作業を無条件に一体化することではありません。同じ文脈でデータを確認しながら、書き込み操作だけを明確に分けることです。
6. 取得・作成・更新・公開・削除を分けて指示する
CMSへ接続した後も、すべての操作を常に許可する必要はありません。
私の運用では、依頼内容ごとに次のように分けています。
依頼 | 許可する操作 | その時点では行わない操作 |
|---|---|---|
接続確認 | API、スキーマ、記事の取得 | 作成、更新、公開、削除 |
原稿作成 | ローカル原稿と調査記録の作成 | CMSへの書き込み |
入稿 | 新規記事の下書き作成 | 公開、他記事の更新、削除 |
記事修正 | 指定した記事とフィールドの更新 | 他記事の変更、削除 |
公開 | 確認済み記事の公開 | 別の記事の公開、削除 |
書き込み前には、対象の記事タイトルだけでなくコンテンツIDも確認します。APIキーやアクセストークンは、記事本文、コード例、Gitで管理するファイルへ含めません。CMS側のAPIキーも、必要な操作に対応する権限だけを付けます。
Codex自体にも、ファイルやコマンドの実行範囲を制御するサンドボックスと、実行前に確認を求める承認設定があります。詳しい仕組みはOpenAIのAgent approvals & securityで確認できます。
自然言語で「公開しない」と伝えることに加え、CMS側の権限、Codex側の実行範囲、操作ごとの指示を組み合わせています。
7. 記事制作でも、調査から公開確認まで同じ考え方で進める
今回の記事制作でも、最初から本文を書き始めたわけではありません。
まずmicroCMSを読み取り専用で確認し、公開済みの記事26件から、Codex、AIコーディング、microCMSに関連する記事のタイトルと役割を整理しました。その結果、本記事はツール比較やMCPの接続方法ではなく、Web制作全体の流れを扱う記事として位置づけています。
次に、OpenAI、microCMS、Google Search Centralの公式資料を確認しました。公式仕様と、私が当サイトで行った作業を分けて原稿へ反映しています。
原稿を作成した後は、次の点を確認します。
- 既存記事と同じ説明を繰り返していないか
- 導入から結論まで話題が自然につながっているか
- 本人の体験として書いた内容に根拠があるか
- 外部仕様のリンクが直前の主張を支えているか
- APIキー、管理画面URL、ローカルの絶対パスなどが含まれていないか
- 未確認の文言や仮URLが残っていないか
CMSへ入稿するときは、microCMSのリッチエディタに合う形式へ変換し、外部リンクの開き方も設定します。公開後はCMSのステータスだけでなく、Webサイトの本文、title、canonical、構造化データ、内部リンクを確認します。
静的サイトで公開内容が反映されるまでの流れは「microCMSの記事が反映されない原因」で、SEO設定の実装と確認方法は「microCMSのSEO対策チェックリスト」で詳しく紹介しています。
デザインと公開判断は人が持つ
Codexへ調査、実装、検証を任せる範囲は広がりました。それでも、次の判断は私が行います。
- Webサイトで何を達成するか
- どの情報を掲載し、何を掲載しないか
- デザインとして採用できるか
- 確認結果を踏まえて公開できるか
Codexは、関連情報を探し、変更し、確認結果をまとめるところまで進められます。一方で、サイトの目的やブランドに合っているか、公開してよい情報かという判断には、制作する側の責任が残ります。
デザインについても、私はCodexだけへ統一していません。文章、構成、ワイヤー、コード編集はCodexを中心にし、デザインの案出しや調整にはGoogle Antigravityも使っています。両者の使い分けは「CodexとGoogle AntigravityをWeb制作で比較」でまとめました。
よくある質問
CodexはWeb制作のどの工程で使えますか？
要件整理、既存コードの調査、実装、テスト、差分レビュー、公式資料の確認に使えます。MCPでCMSと接続すれば、コンテンツの取得、下書き作成、更新も同じ作業の流れに含められます。
Codexへ毎回詳しい指示を書く必要がありますか？
繰り返し使うコーディング規約や品質基準は、AGENTS.mdやSkillとしてプロジェクトへ保存できます。ただし、今回変更する対象、目的、完成条件、外部サービスへ許可する操作は依頼ごとに伝えます。
CodexからmicroCMSへ記事を入稿できますか？
できます。当サイトではmicroCMS公式MCPを接続し、APIとスキーマの取得、記事取得、下書き作成、更新、公開まで確認しました。利用できる操作は、MCPが提供するツールとmicroCMS側のAPIキー権限によって決まります。
Codexが作ったコードや記事はそのまま公開できますか？
私はそのまま公開していません。コードでは差分、ビルド、画面、生成されたHTMLを確認し、記事では事実、文章、リンク、SEO情報、公開NG情報を確認します。最終的な公開判断は人が行います。
microCMSへ接続し、取得・下書き作成・更新を分けて検証した内容は、microCMS公式MCPをCodexで使う方法で紹介しています。
実装後の表示、SEO、デバイス差、保守性を確認する具体的な項目は、AIコーディング後の品質チェックリストにまとめています。
構成・デザイン・コード編集でツールを使い分けた結果は、CodexとGoogle Antigravityの比較で紹介しています。
Codexで要件、コード、CMSを一続きにする
CodexをWeb制作で使う目的は、コードを速く書くことだけではありません。
目的と完成条件を整理し、既存の実装を調べ、必要な箇所だけを変更する。変更後は差分と動作を確認し、必要な場合だけCMSへ反映する。公開前後の確認まで同じ文脈で進められることが、私が実際に使って感じている利点です。
そのためには、Codexへ任せる範囲を広げるだけでなく、変更対象、権限、確認項目、公開判断を明確にする必要があります。
私は、調査・実装・検証をCodexで進め、サイトの目的、デザイン、掲載情報、公開の可否は自分で判断しています。この役割分担が、現在のWeb制作と運用で最も進めやすい形です。
- 執筆者 | 西條輝
- 1995年生まれ。
Web業界は8年目です。それ以前は、実製品の品質管理などを5年ほど担当していました。
生成AIの進歩で「作ること自体のハードル」は下がったからこそ、現場の課題を丁寧に言葉にし、Webというカタチに落とし込むことが、これからますます重要になると感じています。
X（Twitter）
お問い合わせはこちら