本記事はOpenAIとの有償タイアップ（PR）記事です。
はじめに
最近、Claude CodeやCursorなど、AIを活用しながらコードを書くことがかなり当たり前になってきました。
自分自身も普段からAIを使って開発していますが、今回試してみたのがOpenAIのCodexです。
Codexを使っていて面白いと感じたのが、単に「コードを書いてもらう」だけではなく、
設計 → 実装 → テスト → コードレビュー
といった一連の開発タスクまで任せられること。
そこで今回は、自分がXで運用している「タランチュラ」のホームページを題材に、
30分間でWebサイトのMVPをどこまで作り、検証できるのか
を試してみました。
今回の30分では、Codexに主に以下の作業を任せています。
- Webサイトの構成・実装方針の整理
- DESIGN.mdの作成
- Webサイトの実装
- テストコードの作成・実行
- コードレビュー
- 指摘内容をもとにした修正
一方で、すべてをCodexに任せっぱなしにしたわけではありません。
自分は各工程で、
- 設計・計画の方向性が問題ないか確認する
- 実装されたデザインや画面を確認する
- テスト結果を確認する
- コードレビューの指摘内容を確認し、修正するか判断する
- 最終的な成果物を確認する
といった判断を行っています。
つまり今回試したのは、
Codexに作業を任せ、人間は方向性や成果物を確認・判断する
という開発スタイルです。
また、「30分で完成」といっても、本番公開できるWebサイトを完全に仕上げたという意味ではありません。
30分で、MVPの実装からテスト・レビュー・改善までの一連の開発フローをどこまで進められるのか、という検証になります。
実際にどこまで完成したのか、テストでは何を確認できたのか、コードレビューではどのような指摘が出たのかも含めて、順番に紹介していきます。
今回やること
今回は、CodexにWebサイト開発の一連の工程を任せて、30分でMVPをどこまで作り、検証できるのかを試してみます。
題材として作るのは、自分がXで活動している「タランチュラ」のホームページです。
進め方は、以下の4ステップです。
1. 設計
まず、作りたいWebサイトの要件をCodexに伝え、ページ構成や必要なコンポーネント、実装方針を整理してもらいます。
今回はplan modeを活用して、整理した内容を DESIGN.md にまとめてもらいました。
ここではCodexに計画を作ってもらうだけではなく、自分でも内容を確認し、作りたいサイトの方向性と合っているかを判断してから次の工程へ進みます。
2. 実装
DESIGN.md をもとに、CodexにWebサイトを実装してもらいます。
ページ構成やUIを実際のコードに落とし込んでもらい、ブラウザ上で表示された画面を自分でも確認します。
デザインや構成に違和感があれば、その都度追加の指示を出して修正していきます。
3. テスト
一通り実装できたところで、Codexにテストコードの作成と実行を依頼します。
単に画面が表示されるだけではなく、想定した実装になっているか、主要な処理に問題がないかを確認します。
テスト結果についても自分で確認し、問題が見つかった場合は修正を依頼します。
4. コードレビュー・改善
最後に、実装したコード全体をCodexにレビューしてもらいます。
コードの構成や可読性、重複した実装、改善できそうなポイントなどを確認してもらい、指摘内容を見ながら必要な修正を進めます。
この流れを30分間で実施し、
「設計 → 実装 → テスト → レビュー・改善」まで、どこまで進められるのか
を検証していきます。
なお、今回のゴールは30分で本番公開レベルのWebサイトを完成させることではなく、MVPの作成から検証・改善までの開発サイクルをどこまで回せるかを見ることとします。
Step1：まずは設計を整理する
いきなり実装を始めるのではなく、まずはCodexにWebサイト全体の設計を整理してもらいました。
今回作りたいのは、自分がXで活動している「タランチュラ」のホームページです。
最初に、
- どのようなページ構成にするか
- どんな情報を載せるか
- 必要なコンポーネントは何か
- どのような技術構成で実装するか
といった要件をまとめてCodexに渡しました。
今回はplan modeを活用して、整理した内容を DESIGN.md にまとめてもらっています。
DESIGN.md には、例えば以下のような内容を整理しました。
- ページ全体の構成
- Heroセクション
- 自己紹介
- 実績・活動内容
- SNSや外部リンク
- 各セクションで必要なUI
- 実装の進め方
ここで重要なのは、Codexが出した設計をそのまま採用したわけではない点です。
一度生成された内容を自分でも確認し、
「この情報は必要か」
「この構成で見やすいか」
「今回のMVPとして実装する範囲はどこまでか」
を判断したうえで、実装方針を決めました。
この工程を最初に挟んでおくことで、途中で「何を作るんだっけ？」となりにくく、後続の実装もかなり進めやすくなります。
個人的には、Codexにいきなりコードを書かせるより、
最初に設計を言語化してから実装に入る
方が、AIに開発を任せるときも扱いやすいと感じました。
この DESIGN.md をベースに、次は実際の実装へ進みます。
Step2：DESIGN.mdをもとに実装する
設計内容を確認したら、次は DESIGN.md をもとにCodexへ実装を依頼しました。
ここでは、先ほど整理したページ構成やコンポーネント、実装方針に沿って、実際のコードを書いてもらいます。
今回のMVPでは、主に以下のような部分を実装しました。
- ファーストビュー
- 自己紹介セクション
- 実績・活動内容の表示
- SNSや外部リンク
- 各セクションのレイアウト
- PC／スマートフォンを意識した基本的なレスポンシブ対応
実装そのものはCodexに任せつつ、生成された画面は自分でも都度確認しました。
例えば、
- 想定していたページ構成になっているか
- 情報の優先順位が分かりやすいか
- デザインに大きな違和感がないか
- MVPとして必要な要素が揃っているか
といった点を見ながら、必要に応じて追加の修正指示を出しています。
今回試してみて便利だと感じたのは、最初に DESIGN.md で方針を整理しておくことで、実装時の指示を細かく繰り返さなくても、ある程度まとまった形まで一気に進めやすかったことです。
一方で、Codexが生成したものをそのまま完成品として採用するのではなく、最終的なデザインや構成については自分で確認し、必要な修正を判断しています。
30分という限られた時間の中では、細部まで作り込むのではなく、まずは
「ホームページとして一通り見られるMVPを作る」
ことを優先しました。
この時点でWebサイトの基本的な形ができたので、次は実装した内容が想定通り動作するか、テストを行っていきます。
Step3：テストコードを作成して動作を確認する
実装が一通りできたら、次はCodexにテストコードの作成と実行を依頼しました。
今回は、単に画面が表示されるかを見るだけではなく、実装した内容が意図した通りに動いているかを確認するために、主要な部分を中心にテストしています。
例えば、
- 各セクションが正しく表示されるか
- ボタンやリンクが想定通りに動作するか
- 必要なコンポーネントが正しく描画されるか
- ページ表示時にエラーが発生しないか
といった点を確認しました。
Codexにテストコードを作成してもらったあと、そのままテストを実行。
テスト結果を確認し、問題が出た箇所については、原因を確認したうえで修正を依頼しました。
今回の検証では、主要な機能については想定通り動作していることを確認できました。
一方で、テストを通して初めて気づける細かな実装上の問題もあり、実装して見た目を確認するだけではなく、テスト工程まで含めて確認する重要性を改めて感じました。
また、テスト結果はCodexに任せきりにせず、自分でも内容を確認しています。
「テストが通ったからOK」とするのではなく、
- 何をテストしているのか
- テスト内容が今回の実装に対して十分か
- エラーが出た場合に修正が必要か
を確認しながら進めました。
今回のように短時間でMVPを作る場合でも、
実装 → テスト → 修正
まで一連の流れで進められるのは便利だと感じました。
次は、テストを通過したコードに対して、Codexにコードレビューを依頼していきます。
Step4：コードレビューで改善点を洗い出す
テストまで完了したら、最後にCodexへコードレビューを依頼しました。
今回は「動いているからOK」で終わらせず、実装したコード全体を見てもらい、
- コードの重複がないか
- コンポーネントの分け方に問題がないか
- 可読性を改善できる箇所がないか
- 今後修正しづらくなりそうな実装がないか
- レスポンシブ対応などに抜けがないか
といった観点で確認してもらいました。
例えば、レビューでは、
「同じようなUIの記述が複数箇所にあり、今後変更する際に修正箇所が増えてしまう」
といった指摘がありました。
そこで、重複していた部分を共通コンポーネントとして切り出し、再利用できる形に修正しました。
また、画面幅によってレイアウトが崩れる可能性がある箇所についても確認し、必要に応じてレスポンシブ対応を調整しています。
このように、
レビュー → 指摘内容を確認 → 修正
までを同じ流れで進められるのは、Codexを使っていて特に便利だと感じたポイントです。
もちろん、レビュー結果もそのまま採用するのではなく、
- 本当に修正が必要か
- 今回のMVPで対応すべき内容か
- 後回しにしても問題ないか
は自分で確認して判断しました。
AIにコードを書いてもらうだけではなく、
「実装したコードをレビューさせて、改善まで進める」
ところまで任せられると、短時間でも開発サイクルをかなり回しやすくなります。
今回の30分検証では、ここまでで
設計 → 実装 → テスト → コードレビュー → 改善
まで一通り進めることができました。
30分やってみた結果
今回、Codexを使って30分間で進めた内容は以下です。
- Webサイトの要件整理
-
DESIGN.mdの作成 - MVPの実装
- テストコードの作成
- テスト実行
- コードレビュー
- レビュー内容をもとにした一部修正
30分という短い時間でも、Webサイトの見た目を作るだけではなく、
設計 → 実装 → テスト → レビュー → 改善
まで、一連の開発フローを進めることができました。
一方で、30分ですべてを完成させられたわけではありません。
今回の時点では、MVPとしてページ全体の基本的な構成や主要なコンテンツは実装できましたが、
- 細かなデザイン調整
- 表示崩れの最終確認
- 追加のテストケース
- 本番公開を想定した最終チェック
などは、その後も対応が必要な部分として残っています。
そのため、今回の結果は「30分でWebサイトが完成した」というより、
30分でMVPを作り、テストとレビューまで含めた開発サイクルをどこまで回せるかを検証した
という表現が近いです。
特に印象的だったのは、実装だけでなく、その後のテストやコードレビューまで同じ流れで進められたこと。
実装したコードに対してテストを行い、さらにレビューで改善点を洗い出し、その指摘をもとに修正まで進められました。
短時間でまず形にして、その後に検証・改善していくようなMVP開発では、かなり相性が良いと感じました。
使ってみて感じたCodexの強み
今回使ってみて特に便利だと感じたのは、Codexを単なる「コード生成ツール」としてではなく、開発タスクをまとめて任せる相手として使えることです。
1. 設計から実装まで流れを切らずに進めやすい
最初に要件や実装方針を整理し、その内容をもとにそのまま実装へ進められるため、工程ごとに毎回ゼロから指示を出し直す必要がありません。
今回も DESIGN.md をベースに、
設計 → 実装
まで自然につなげることができました。
2. 実装後のテストやレビューまで任せられる
個人的に便利だと感じたのが、コードを書いて終わりではなく、
- テストコードを作る
- テストを実行する
- コードをレビューする
- 指摘内容をもとに修正する
といった後工程まで続けて依頼できることです。
AIコーディングというと「実装を速くする」というイメージが強いですが、実際にはその後の確認や改善まで含めて任せられる点に大きなメリットを感じました。
3. 人間は「判断」に集中しやすい
今回、自分が主に行ったのは、
- 設計内容が目的に合っているか確認する
- デザインや構成を判断する
- テスト結果を確認する
- レビューの指摘を採用するか判断する
といった部分です。
一方で、実際にコードを書く作業やテストコードの作成、レビューの実行などはCodexに任せました。
そのため、人間側は細かな実装作業よりも、
「何を作るか」「この結果で問題ないか」「どこを直すか」
といった判断に時間を使いやすくなります。
今回使ってみて、AIコーディングは「コードを書かせる」という使い方から、
人間が方向性を決め、AIに開発タスクを任せる
という使い方に変わってきていると感じました。
まとめ
今回は、Codexを使って30分間でWebサイトのMVP開発をどこまで進められるか試してみました。
結果として、
- 設計
- 実装
- テスト
- コードレビュー
- 一部改善
まで、一連の開発フローを進めることができました。
一方で、30分で本番公開レベルまで完成したわけではなく、細かなデザイン調整や追加テストなどはその後も必要です。
今回使ってみて感じたのは、Codexは単にコードを書かせるだけではなく、
人間が方向性を判断し、Codexに実装・検証・改善を任せる
という使い方と相性が良いということ。
特に、短時間でまずMVPを形にし、その後テストやレビューまで進めたい場面では、かなり使いやすいと感じました。
「AIにコードを書かせる」だけでなく、
「開発フローの一部を任せる」。
そんな使い方を試してみたい方には、参考になると思います。