Claude CodeかCodexで、コードを書かせたことはある。でも「Webサイトを1本、頭から終わりまでどう回すか」は決まっていなくて、工程ごとに別のチャットへ貼り直している。そういう人に向けて、私がいまWebサイト制作で使っている流れを、工程の順に書きます。

先に結論を書くと、私はClaude Code(要件定義・システム設計・ワイヤーフレーム)→ Codex(デザイン、画像とパーツの書き出し)→ Claude Code(コーディング、SEO・AIO)→ 自分の手でアップロード、の順で作っています。AIの受け渡しは3回。自分の手に残しているのは、工程ごとの採否と、最後のサーバーへのアップロードです。

この記事は連載「Claude Code×Codex 実践」の第1回で、流れの全体を1本で見せます。各工程の細かい依頼文や採否の基準は、第2回以降でひとつずつ掘り下げます。ツール名・提供形態・料金プランは2026年10月時点のものです。ツールは変わっていきますが、「工程で分ける」という考え方は残ると思っています。

CONTENTS目次
  1. 結論:7つの工程を、3回の受け渡しで回す
  2. 工程1〜2:要件定義・設計・ワイヤーフレームはClaude Code
  3. 工程3〜4:デザインと素材の書き出しはCodex
  4. 工程5〜6:コーディングとSEO・AIOは、Claude Codeに戻す
  5. 工程7:アップロードだけは、手で残している
  6. この流れで変わったこと、変わらなかったこと
  7. まとめ

結論:7つの工程を、3回の受け渡しで回す

工程 任せるAI 渡すもの 返ってくるもの 自分がすること
① 要件定義・システム設計 Claude Code 事業内容・目的・ページ構成の希望・参考サイト 要件定義書・サイトマップ・設計 抜けを足す、優先順位を決める
② ワイヤーフレーム Claude Code ①の設計 各ページのワイヤー(HTMLの素組み、またはPDF) 構成の採否
③ デザイン Codex ワイヤー・トーンの指示 画面デザイン 採用・却下・修正指示
④ 画像・パーツの書き出し Codex 採用したデザイン 画像・アイコン・パーツ 書き出し単位の確認
⑤ コーディング Claude Code デザイン・書き出した素材・設計 HTML/CSS/JavaScript 表示確認、コードを読む
⑥ SEO・AIO Claude Code ⑤のコード タイトル・メタ・構造化データ・OGP・llms.txt など 公式の仕様とツールで照合
⑦ アップロード 自分 完成ファイル ― FileZillaでレンタルサーバーへ

Webサイト制作の7工程。要望からClaude Codeが要件定義・設計とワイヤーフレーム、Codexがデザインと画像・パーツの書き出し、Claude Codeがコーディングと SEO・AIO を担当し、工程ごとに私が採否・修正指示・確認を入れ、アップロードだけは自分の手で行う流れ図

ひとつ補足があります。前回の記事「AIエージェントの種類まとめ」では、私の分担を「Claude Codeに設計、Codexに実装」と書きました。あれはWebアプリの話です。Webサイトでは、コーディングをClaude Codeに戻しています。設計はClaude Code、デザインはCodexまでは同じで、違うのはコーディングの担当だけです。理由は後半の工程5〜6のところで書きます。

工程1〜2:要件定義・設計・ワイヤーフレームはClaude Code

最初の依頼文(事業内容・見せたい表示・サービス内容・ページ構成・jQuery不使用・更新部分はCMS・SEO/AIO考慮)をClaude Codeに渡すと、HTMLの素組みのワイヤーフレームと要件定義書・サイトマップが返ってくるイメージ図

最初の依頼文に入れていること

最初の依頼文で、わかっている範囲のことをまとめて渡します。入れているのは次の項目です。

  • 会社の事業内容
  • メインに出したい表示やタイトル(いちばん見せたいもの)
  • サービスの内容
  • ページ構成の希望
  • 技術の要件:jQueryは使わず、素のJavaScript(バニラJavaScript)で書くこと。ブログなどの更新がある部分は、WordPressのようなCMSを使うこと
  • SEO・AIOを考慮した構成にすること

ポイントは、技術の要件を最初の依頼文に入れてしまうことです。「jQueryを使わない」「更新部分はCMS」「検索を意識した構成」は、あとから足すとワイヤーや設計を作り直すことになります。最初に言っておけば、要件定義の段階から、その前提で構成が組まれます。

要件定義の段階でClaude Codeを使う理由は、前回の記事にも書いたとおり、自分の頭の中にある構成を聞き出しながらまとめてくれるからです。依頼文に書いていない「抜け」を質問で埋めていくので、返ってきた要件定義書を読んで、足りない点を足し、優先順位を決める、という作業が自分の側に残ります。

ワイヤーフレームはHTMLの素組みか、PDF

ワイヤーフレームは、HTMLの素組みか、PDFなどの画像で出させています。HTMLの素組みは、ブラウザで開けばそのまま画面の幅に合わせて確認でき、次の工程(Codexにデザインを依頼する)にファイルのまま渡せます。PDFや画像は、人に見せて構成の確認を取るときに向いています。どちらにするかは、そのワイヤーを誰に見せるかで決めています。

この工程では、デザインの良し悪しは見ません。見るのは、ページの構成と、各ページに置く要素の過不足です。ここで構成を固めておかないと、デザインを直しても戻ってくることになります。

使う形はデスクトップアプリ

要件定義・設計・ワイヤーの工程は、Claudeのデスクトップアプリの「Code」タブで進めています。文章の資料を往復しながら作る工程なので、ターミナルより、画面で見ながら直せるほうが合っています。Claude Codeはこのほか、ターミナル、VS CodeやJetBrainsの拡張、Webからも使えます(有料プラン向け。2026年10月時点の公式ドキュメントによる)。

工程3〜4:デザインと素材の書き出しはCodex

固まったワイヤーフレームをCodexに渡して、画面のデザインを作ってもらいます。渡すのは、ワイヤーと、トーンの指示(業種、色の方向、参考にしたいもの、やってほしくないこと)です。Codexをデザインに使っているのは、前回の記事にも書いたとおり、「AIが考えそうな構図」を超えたものを出してきた経験があるからです。ワイヤーのとおりに要素を並べるだけでなく、構図の案として採用できるものが返ってきます。

デザインが決まったら、同じCodexで、コーディングに必要な画像やパーツを書き出してもらいます。ヒーロー画像、アイコン、セクションごとの背景のように、コードの中で画像として扱うものがここで揃います。Codexには画像生成の機能が組み込まれているので(2026年10月時点、公式ドキュメントによる)、デザインの文脈のまま、合う画像を作らせることができます。この工程の自分の仕事は、デザインの採用・却下・修正指示と、書き出された素材が次のコーディングで使える単位になっているかの確認です。

この工程もデスクトップアプリ(ChatGPTのデスクトップアプリの中のCodex)で進めています。画面を見ながら「ここを直して」と言える工程なので、ターミナルより向いています。Codexはこのほか、ターミナルで動くCodex CLI、エディタ拡張、クラウド実行があり、ChatGPTの各プランに含まれています(2026年10月時点の公式ドキュメントによる)。ワイヤーの渡し方、依頼文、採否の基準は第2回で詳しく書きます。

工程5〜6:コーディングとSEO・AIOは、Claude Codeに戻す

なぜコーディングをClaude Codeに戻すのか

Webアプリでは、設計をClaude Code、コーディングをCodexに任せています。WebサイトでコーディングをClaude Codeに戻しているのは、どちらが上手いかではなく、契約しているプランの都合です。

私はClaudeをMaxプラン(月100ドルのほう)、ChatGPTをPlusプラン(月20ドル、日本のアプリ内課金では3,000円)で使っています。Claude Codeの利用量はMaxの上限から、Codexの利用量はPlusの上限から消費されます。しかもCodexの画像生成は、公式ドキュメントによると画像を使わない作業より3〜5倍速く上限を消費します。デザインと画像の書き出しでPlusの上限をすでに使っているところへ、往復の多いコーディングまで寄せると、サイト1本の途中で上限に当たる可能性がある。だから上限に余裕のあるClaude Code側にコーディングを置いています。それだけの理由なので、プランの組み合わせが逆の人なら、分担も逆でよいと思います(料金と上限の仕様は2026年10月時点のClaude・Codexの公式ページによります)。

WebサイトとWebアプリの分担の対比。要件定義・設計はどちらもClaude Code、デザインはどちらもCodex、コーディングはWebサイトではClaude Code、WebアプリではCodex。理由は契約プランの利用上限

Codexには、採用したデザインと書き出した素材をファイルで渡します。Claude Codeには、そのデザインと素材、そして工程1で作った設計を一緒に渡してコードを起こしてもらいます。設計を書いたのと同じAIがコードを書くので、ページ構成や「jQueryを使わない」といった最初の要件が、コードの段階でも守られやすいのも、サイトではClaude Codeに戻す理由のひとつです。

SEO・AIOは「指示して終わり」にしない

コードができたら、同じClaude Codeに、SEOとAIO(AI検索への最適化)の項目を指示します。このブログで実際にやっている項目は、次のとおりです。

  • ページごとのタイトルとメタディスクリプション
  • 見出し構造(h1はページに1つ、h2・h3で話の順番がわかる)
  • OGPとXカード(SNSで共有されたときの表示)
  • 構造化データ(JSON-LD。パンくず・FAQ・記事など)
  • サイトマップとrobots.txt
  • llms.txt(サイトの要約と主要ページの一覧)
  • 画像のalt、WebP化、遅延読み込み

コーディング後にClaude Codeへ指示するSEO・AIOの7項目と、それぞれを自分で確かめる方法(ブラウザでの表示、リッチリザルトテスト、Search Console、PageSpeed Insightsなど)の一覧表

ここで大事にしているのは、AIに指示したあとに自分で確かめることです。構造化データはGoogleのリッチリザルト テストに通す、OGPは実際に共有してプレビューを見る、サイトマップはSearch Consoleに送って受理されたかを見る。このブログも、一度まとめて監査したときに、OGPが1つも出ていない、llms.txtが404になっている、という状態が見つかりました。AIに「対応して」と言った記憶があっても、出力されているとは限りません。

AIOについては、ひとつ注意があります。llms.txtは2024年に提案された仕様で、2026年10月時点でも標準にはなっておらず、Googleは公式のガイドで「Google検索はllms.txtを無視する」と明記しています。なので、「llms.txtを置けばAI検索に載る」という期待はしていません(置いて害があるわけでもないので、このサイトには置いています)。同じガイドでGoogleが書いているのは、AIの機能向けに特別なことは要らず、検索向けの基本をやればよい、ということです。構造が正しく、文章が明快で、公式の仕様に沿っていること。AIO向けの対策というより、SEOでやるべきことを丁寧にやる、に近いです。タイトルとメタディスクリプションの考え方は、Webデザイン連載の第4回にも書いています。

コーディングとSEOの工程は、ターミナルのCLIとデスクトップアプリの両方を使います。ファイルを直接直してもらう作業はCLI、出力を見ながら直す作業はデスクトップ、という使い分けです。指示の出し方と確認の順番は第3回で書きます。

工程7:アップロードだけは、手で残している

完成したファイルをサーバーに上げる作業は、FileZillaで自分の手でやっています。エックスサーバーのようなレンタルサーバーはFTPが入口なので(公式の設定手順があります)、特別なことをしているわけではなく、昔からの方法のままです。

手で残している理由は2つあります。ひとつは、AIに本番サーバーの鍵を渡していないこと。AIエージェントはファイルを書き換え、コマンドを実行します。手元の作業フォルダでそれをやる分には、失敗してもやり直せます。本番サーバーに同じ権限を渡すと、やり直しが利かない失敗が起こりえます。だから、本番に触れる鍵は自分の手元にだけ置いています。

もうひとつは、上げる直前に自分の目を通すためです。FileZillaでファイルを選んで上げる、という一手間があることで、どのファイルを差し替えるのかを自分で確認することになります。手元の表示を見て、差し替えるファイルの一覧を見て、上げてから本番の表示を見る。この流れを機械に渡していません。

補足すると、このブログ自身はWordPressなので、記事の投稿は管理画面からで、FTPは使いません。公開済みページを直すときは、Claude in Chromeに管理画面を操作させることもあります。その話は第5回で書きます。

この流れで変わったこと、変わらなかったこと

変わったのは、工程の間の「貼り直し」がなくなったことです。以前は、要件定義のチャット、デザインのチャット、コードのチャットがばらばらで、前の工程の結果をコピーして次に貼る作業を自分がやっていました。いまはファイルのまま次のAIに渡します。デザインの当たりが早く出るようになったのと、SEOの項目を工程として固定したことで、抜けに気づくのが早くなったのも変化です。

変わらなかったのは、判断の時間です。要件定義書を読んで足りない点を足す、デザインを採用するか却下するか決める、コードを読んで設計どおりか確かめる。ここはAIに渡していないので、時間も残っています。読めないコードを採用はできないので、この流れは「コードが読めること」の上に成り立っています。基礎が大切な理由は別の記事に書きました。

うまくいかないこともあります。前回の記事にも書きましたが、指示が伝わらずにAIが同じ修正を繰り返すことがあり、そういうときは同じAIに言い直しを重ねるより、別のエージェントに切り替えて同じ依頼を出したほうが早く抜けられました。それから、このブログの運用で一度、公開の直前に、別のタブで開いていた古い下書きが最新の本文を上書きしていたことがあります。公開してから気づいて直しました。AIの作業そのものではなく、自分の確認の手順の問題でしたが、「最後に自分が見る」工程を残しておいてよかった、と思った場面です。

まとめ

  • Webサイトは、Claude Code(要件定義・設計・ワイヤー)→ Codex(デザイン・素材の書き出し)→ Claude Code(コーディング・SEO・AIO)→ 自分(アップロード)の順で回している
  • 最初の依頼文に、事業内容・見せたいもの・ページ構成と一緒に、技術の要件(jQueryを使わない、更新部分はCMS、SEO・AIOを考慮)を入れておく
  • Webアプリとはコーディングの担当が逆。理由は得意不得意ではなく、契約プランの利用上限
  • SEO・AIOは指示して終わりにせず、公式のツールで自分が確かめる。アップロードと本番の鍵は自分の手元に残す

次回(第2回)は、工程2〜3の「ワイヤーフレームからデザインへ」を取り上げます。Claude Codeが作ったワイヤーをCodexにどう渡しているか、依頼文の骨子、画像とパーツを書き出す単位、採用・却下の基準まで書く予定です。