Claude CodeとCodexを併用してWebサイトを改善する実践フロー

この記事は誰向けか

サイトのコードを自分で管理していない場合、ここで書く運用は現時点では不要です。制作会社や担当者に依頼している方は、「変更内容を確認してから反映する」という考え方の部分だけ持ち帰っていただければ十分です。

自分でサイトのコードを触っている個人事業主やWeb制作者の方に向けて、実際にClaude CodeとCodexを併用してサイトを改善した流れを書きます。

結論：工程を分けると、確認する場所が減る

先に結論を書きます。調査・設計・実装・確認という工程ごとに担当を分けたら、自分が確認する場所が減りました。ただし、変更をまとめて反映するのはやめました。理由はあとで書きます。

AIが自動でサイトを直してくれるわけではありません。人が確認する工程は、今もはっきり残っています。

実践フロー5ステップ

実際に私がサイトを改善するときの流れは、次の5ステップです。

ステップ1 変更したいことを1つに絞る

まず、直したいことを1つだけに絞ります。複数を同時に進めると、あとで何が原因だったかが分かりにくくなるためです。

ステップ2 調べる・設計する

次に、どう直すかを調べ、設計します。この段階では、Claude Codeを使ってリポジトリの現状を調べることが多いです。以前、この前提確認を省いて、古い資料をそのまま根拠にしてしまい、実際の公開状態と食い違った判断をしたことがありました。それ以来、作業を始める前に、AIに渡す前に整理する5つの情報と、参照する資料が最新かどうかを確認する工程を必ず入れています。

考えを口頭で出してから設計の材料を整理したい場合は、短い一人会議で文字起こしとタスク抽出を確認したNottaの実機検証もあります。

ステップ3 作業用の場所を分ける

設計ができたら、本番とは別の作業用の場所（ブランチ、と呼ばれる区切り）を用意します。ここで作業しても、本番にはまだ影響しません。

ステップ4 実装を任せる

作業用の場所の中で、実際のコードの変更をCodexに任せます。ここが実装の中心の工程です。調べる工程と、実際にコードを変える工程を、あえて別のところで進めています。同じ流れの中で調査から実装まで一気に進めると、途中で前提が変わったことに気づきにくいためです。私の場合は、調べる側をClaude Code、変更する側をCodexに置いています。

ステップ5 自分で確認してから反映する

Codexが作った変更内容を、まず自分で読みます。そのあと、本番と同じ見た目で確認できる画面（Vercel Preview）で表示を確認し、問題がなければ本番へ反映します。

工程と担当の対応

「変更内容を読む」と「公開」は、どちらもツールに任せていません。ここは工程を分けたあとも変えていない部分です。

実際にやった改善の例

広告・アフィリエイトの開示ページを追加したとき

広告やアフィリエイトの扱いを説明する開示ページを追加した際は、まずページの内容を私が確認し、実装をCodexに任せ、Vercel Previewで表示を確認してから反映しました。変更内容は、PR（プルリクエスト＝変更をまとめて提案し、反映前に内容を確認するための仕組み）としてGitHub上に残しています。この改善はPR #5にあたります。

計測タグを入れたとき

サイトの利用状況を計測するためのイベント（クリック計測など）を追加したときも、同じ流れで進めました（PR #6）。この例だけは、見た目を確認するだけでは足りませんでした。確認用の画面で実際にクリックし、記録が残るところまで見ています。

古いURLの転送を設定したとき

以前使っていたURLから、現在のURLへ転送する設定を追加したときも同様です（PR #7）。転送が正しく設定されているかは、実際にアクセスして確認しています。

いずれの例も、この記事の目的はGitHubの操作手順を説明することではありません。工程を分け、どこを人が確認したかという運用の部分を伝えることが目的です。

まとめて反映するのをやめた

何をやろうとしていたか

ある時期、複数の変更（開示ページの追加、計測タグの設置、古いURLの転送設定）を、まとめて一度に進めようとしていました。

なぜ危ないと判断したか

まとめて進めると、あとで何か問題が起きたときに、どの変更が原因かを切り分けにくくなります。表示がおかしくなった、計測が動かない、といったことが起きたとき、原因がどこにあるか特定するのに時間がかかる状態でした。

1本ずつに変えて何が変わったか

そこで、変更を目的ごとに小さい単位に分け、1つずつ確認しながら進める形に変えました。1つを反映して本番で確認し、問題がないことを確かめてから次に進む、という順番です。マージ（本番への反映）の判断は人が行い、AIには任せていません。この変更によって、何か起きたときにどの変更が原因かを追いやすい状態を保てるようになりました。

運用を変更したあと、同じ問題は今のところ起きていません。変更を小さく分けたこと、反映前に必ず確認用の画面で見ること、そして最終的な反映判断を人が行うことを続けているためだと考えています。ただし、この運用に変更してから、まだ約2週間です。今後も同じ運用を続けながら様子を見ています。

任せてはいけないこと

公開の判断

どれだけ実装がうまくいっていても、本番へ反映するかどうかの判断は人が行います。

認証情報の扱い

パスワードやAPIキーなどの認証情報は、AIに読ませる資料やコード変更に含めないようにしています。

ブランド・カテゴリー・URL構造の変更

サイト全体の方針に関わる変更（ブランドの見せ方、カテゴリー分け、URLの構造など）は、実装以前の設計段階で人が判断する範囲としています。原本となる資料をどう扱うかについては、原本を作る（source of truth）でも触れています。

壊さないための3つの決めごと

作業場所を分ける

本番とは別の場所で作業し、確認が終わるまで本番には影響させません。

変更内容を必ず読む

どれだけ小さな変更でも、反映する前に内容を自分で読みます。

本番反映前に確認用の画面で見る

コードの内容を読むだけでなく、実際の見た目や動きを確認用の画面で確かめてから、本番へ反映します。公開後にあらためて確認したい項目は、ホームページを公開したら最初に確認したいことにまとめています。

向いている人・向いていない人

サイトのコードを自分で管理している方、月に数回以上サイトに変更を加える方には、この運用が向いていると思います。制作を外部に任せている方や、変更が月1回に満たない方には、今の段階では不要です。

これは不要です

サイトのコードを自分で管理していない場合

制作会社などに依頼している場合、この記事の運用をそのまま真似する必要はありません。確認の観点（変更内容を読む、反映前に見た目を確認する）だけ参考にしていただければ十分です。

変更が月1回未満の場合

サイトの変更頻度がそれほど高くない場合は、工程を分けるほどの仕組みは、今のところ必要ないはずです。

よくある質問

コードが読めなくても使えますか。 正直にお答えすると、コードが読めない場合は、任せる範囲を狭めたほうがよいと思います。変更内容を自分で判断できない部分は、無理に自分で確認しようとせず、信頼できる人に確認してもらう前提にするべきです。

壊れたら戻せますか。 本番とは別の場所で作業する仕組みにしているため、作業中の変更が直接本番に影響することはありません。ただし、「絶対に安全」ということではなく、確認の工程を経てから反映する、という運用で備えています。

両方（Claude CodeとCodex）を契約する必要がありますか。 必要ありません。まずはどちらか一方から、小さな変更で試してみることをお勧めします。

まとめ：まず1つの小さな変更で試す

工程ごとに担当を分けたことで、自分が確認する場所は減りました。それでも、「変更内容を読む」ことと「公開の判断」は、今も必ず人が行っています。実際に困った経験も、複数の変更をまとめて進めようとしたことが原因でした。

まずは、直したい箇所を1つだけ選び、作業用の場所を分けて試してみてください。変更内容を自分で読んでから反映する、という順番だけは省略しないことをお勧めします。

実践する道具も確認したい方へ。用途と確認方法からツールを探す