Codexを使ってWebアプリを作ったり直したりしたいけれど、依頼文に何を書けばいいのか分からない。

保存機能を追加したい。
スマホ表示を直したい。
ボタンの動きを変えたい。
ローカルで出ているエラーを見てほしい。

こういう場面で、いきなり「直してください」と頼むだけだと、どこが変わったのか分からず不安になることがあります。

この記事では、CodexでWebアプリ開発を頼むときに、初心者が依頼文へ入れておきたい項目と具体例を整理します。

なお、この記事はCodex全般の使い方ではなく、自分用Webアプリを作る・修正する場面での依頼文に絞って説明します。

CodexでWebアプリ開発を頼むときは、依頼文の範囲を決める

Codexに依頼するときは、「何をしてほしいか」だけでなく、「どこまで触ってよいか」も書いた方が確認しやすくなります。

たとえば、次のような依頼文があります。

保存機能を追加してください。

これだけでも意味は伝わります。

ただし、この依頼文だけだと、情報が少なすぎます。

どの画面の保存機能なのか。
どのファイルを変更してよいのか。
見た目まで変えてよいのか。
保存後に何を見れば成功なのか。
ログインやクラウド同期まで追加してよいのか。

Codexが補って作業してくれることもありますが、初心者にとっては、補われた内容を確認するのが難しくなります。

だから、Webアプリ開発でCodexに頼むときは、次の2つをセットで伝えるのが大事です。

  • 何をしてほしいか
  • どこまで触ってよいか

依頼文は、Codexを動かすためだけのものではありません。
作業後に、自分が確認するための地図でもあります。

Codexへの依頼文に入れておきたい5つの項目

Webアプリ開発でCodexに依頼するとき、最初から完璧な文章を書く必要はありません。

ただ、次の5つを入れておくと、作業結果をかなり確認しやすくなります。

  1. 目的
  2. 対象ファイル
  3. 触らないファイル・箇所
  4. 確認方法
  5. 完了条件

順番に見ていきます。

1. 目的を書く

まず、何をしたいのかを書きます。

悪い例は、次のような依頼です。

保存機能をいい感じにしてください。

これだと、何をもって「いい感じ」なのか分かりません。

もう少し具体的にすると、こうなります。

保存ボタンを押したときに、入力したテキストが保存されるようにしたいです。

さらに、Webアプリでの使い方まで書くと分かりやすくなります。

日記アプリで、本文を入力して保存ボタンを押したら、次に画面を開いたときも本文が残っているようにしたいです。

目的を書くときのポイントは、「機能名」だけで終わらせないことです。

「保存機能を追加」よりも、
「保存ボタンを押したら、入力内容が残るようにしたい」
の方が、Codexにも自分にも分かりやすくなります。

Webアプリ開発では、同じ「保存」でも意味がいくつかあります。

  • 画面上に一時的に表示する
  • ブラウザ内に保存する
  • ファイルとして書き出す
  • サーバーに保存する
  • クラウド同期する

初心者が最初の自分用Webアプリを作るなら、まずはブラウザ内保存で十分な場合もあります。
そのため、「何をどこに保存したいのか」まで書けると、依頼のズレが減ります。

2. 対象ファイルを書く

次に、変更してほしいファイルを書きます。

たとえば、次のように書けます。

変更していいのは src/App.tsx だけです。

または、

保存処理に関係するファイルだけを変更してください。
必要なファイルを変更する前に、どのファイルを触る予定か教えてください。

初心者の場合、どのファイルを触るべきか分からないこともあります。

その場合は、無理にファイル名を指定しなくて大丈夫です。
代わりに、Codexに先に確認してもらいます。

どのファイルを変更する必要があるか、先に確認してください。
変更する前に、触る予定のファイル名と理由を説明してください。

これなら、ファイル名が分からない状態でも、いきなり広い範囲を変更されるのを防ぎやすくなります。

Webアプリでは、1つの修正でも複数のファイルに関わることがあります。

たとえば、Reactアプリなら、

  • src/App.tsx
  • src/main.tsx
  • src/App.css
  • package.json
  • vite.config.ts

のように、役割の違うファイルがあります。

初心者のうちは、複数ファイルが一度に変わると、何が起きたのか追いにくくなります。
だからこそ、変更してよいファイルや、先に確認してほしいことを書いておくと安心です。

3. 触らないファイル・箇所を書く

変更してほしい場所だけでなく、触ってほしくない場所も書きます。

たとえば、次のように書けます。

今回は見た目を変えたくないので、CSSファイルは変更しないでください。

または、

GitHub Pagesの設定には触らないでください。

自分で整えた見た目や、すでに動いている設定がある場合、そこを勝手に変えられると確認が大変になります。

Webアプリ開発では、特に次のようなものは不用意に変えない方がいいことがあります。

  • すでに動いている画面構成
  • CSSやレイアウト
  • package.json
  • vite.config.ts
  • GitHub Pages関連の設定
  • データ保存まわり
  • サンプルデータ
  • 本物の個人データ

もちろん、必要があれば変更することもあります。
ただ、初心者の最初の1個では、毎回広く触るより、必要最小限に絞った方が確認しやすいです。

「ここは触らないでください」と書くのは、Codexを疑うためではありません。
作業の範囲をはっきりさせるためです。

4. 確認方法を書く

Codexに依頼するときは、作業後に何を確認すればよいかも書いておきます。

保存機能なら、次のように書けます。

保存後にページを再読み込みして、入力した内容が残っていれば成功です。

スマホ表示の確認なら、こうです。

Chromeの開発者ツールでスマホ幅にして、横スクロールが出ていないことを確認してください。

ローカル起動なら、こう書けます。

npm.cmd run dev で起動し、ブラウザで画面が表示されることを確認してください。

確認方法がないと、「動いたっぽいけど、これで合っているのか分からない」という状態になりやすいです。

Codexが「完了しました」と言っても、最後は自分の画面で確認する必要があります。
そのときに、何を見ればよいかが決まっていると迷いません。

5. 完了条件を書く

確認方法とあわせて、完了条件も書いておくとさらに分かりやすくなります。

たとえば、保存機能ならこうです。

エラーが出ずに保存できて、ページを再読み込みしても保存内容が表示されることを完了条件にしてください。

スマホ表示なら、こうです。

スマホ幅で横スクロールが出ず、主要なボタンが押せる大きさになっていることを完了条件にしてください。

完了条件は、「どこまでできたら今回の作業は終わりか」を決めるものです。

完了条件がないと、作業が広がりすぎることがあります。

保存機能だけでよかったのに、ついでに見た目も変わる。
入力項目も増える。
ログイン機能や同期機能まで提案される。

こうなると、確認する範囲が増えます。

初心者ほど、完了条件を小さく決めておく方が進めやすいです。

悪い依頼文と良い依頼文の例

ここで、Webアプリ開発でCodexに依頼するときの悪い例と良い例を比べてみます。

悪い依頼文の例

日記アプリに保存機能を追加してください。
いい感じにお願いします。

この依頼文は短くて楽ですが、情報が少なすぎます。

どのファイルを変えるのか。
どの入力内容を保存するのか。
保存先はどこなのか。
保存後に何を確認するのか。
見た目を変えてよいのか。

このあたりが分かりません。

良い依頼文の例

日記アプリに保存機能を追加したいです。

## 目的
本文入力欄に書いた内容を、保存ボタンで保存できるようにしたいです。
保存した内容は、ページを再読み込みしても残るようにしてください。

## 対象ファイル
まず、変更が必要なファイルを確認してください。
変更前に、触る予定のファイル名と理由を説明してください。

## 触らないでほしい範囲
今回は見た目を変えたくありません。
CSSファイルとレイアウト構造は変更しないでください。

## 今回やらないこと
ログイン機能、クラウド同期、通知、外部API連携は追加しないでください。

## 確認方法
保存ボタンを押したあと、ページを再読み込みしても本文が残っているか確認してください。

## 完了条件
エラーが出ずに保存でき、再読み込み後も保存内容が表示されること。

## 作業後に教えてほしいこと
変更したファイル、変更内容、確認方法を初心者向けに説明してください。

この依頼文は少し長いですが、作業範囲と確認方法がはっきりしています。

大事なのは、きれいな文章を書くことではありません。

Codexが作業しやすく、自分が確認しやすい状態にすることです。

ファイル名や確認方法が分からないときの書き方

初心者の場合、ファイル名や確認方法が分からないこともあります。

その場合は、分からないまま適当に指定するより、Codexに確認してもらう方が安全です。

たとえば、こう書けます。

初心者なので、どのファイルを変更すればよいか分かっていません。

まず、今回の修正に関係しそうなファイルを確認してください。
変更する前に、触る予定のファイル名と理由を説明してください。

そのうえで、必要最小限の範囲で修正してください。

確認方法が分からないときは、こうです。

作業後に、私がどこを見れば成功と判断できるか教えてください。
初心者でも確認できる手順にしてください。

「分からないから全部任せる」ではなく、
「分からないので、先に確認してから進めてください」
と頼むのがポイントです。

この書き方なら、Codexに調べてもらいながら、作業範囲を広げすぎずに進められます。

初心者がCodexにWebアプリ開発を頼むときの注意点

CodexでWebアプリ開発を進めるとき、初心者が特に気をつけたいのは次の3つです。

一度に頼みすぎない

一度の依頼に、あれもこれも詰め込みすぎない方がいいです。

たとえば、

保存機能を追加して、デザインも整えて、スマホ対応して、GitHub Pagesにも公開してください。

このように頼むと、変更範囲がかなり広くなります。

最初は、

  • 保存機能だけ
  • 表示崩れだけ
  • スマホ幅の横スクロールだけ
  • エラー原因の確認だけ
  • GitHub Pages公開前の設定確認だけ

のように、ひとつずつ分けた方が確認しやすいです。

「今回はやらないこと」も書く

依頼文では、追加してほしくない機能も書いておくと安全です。

今回はログイン機能、クラウド同期、決済、通知、外部API連携は追加しないでください。

Codexは便利ですが、依頼が曖昧だと親切に広げて提案してくれることがあります。

最初の1個を小さく作りたい場合は、やらないことも明記します。

作業後に説明してもらう

作業後には、何を変更したのか説明してもらうと確認しやすくなります。

作業後に、変更したファイル、変更内容、確認方法を初心者向けに説明してください。

これを書いておくと、結果を見たあとに「何が変わったのか分からない」という状態を減らせます。

CodexでWebアプリ開発を頼むときの依頼文テンプレート

最後に、初心者向けのテンプレートを置いておきます。

以下のWebアプリ修正をお願いします。

## 目的
（何をできるようにしたいかを書く）

## 今の状況
（現在どうなっているかを書く）

## やってほしいこと
（今回頼みたい作業を書く）

## 対象ファイル
（分かる場合はファイル名を書く）
分からない場合は、変更が必要なファイルを先に確認し、変更前に理由を説明してください。

## 触らないでほしい範囲
（変更してほしくないファイル・設定・見た目を書く）

## 今回やらないこと
（ログイン、クラウド同期、通知、外部APIなど、今回は入れないものを書く）

## 確認方法
（作業後に何を見ればよいかを書く）

## 完了条件
（どうなれば今回の作業は完了かを書く）

## 作業後に教えてほしいこと
- 変更したファイル
- 変更した内容
- 確認方法
- 次に私が見るべきこと

最初から全部を埋める必要はありません。

まずは、

  • 目的
  • やってほしいこと
  • 触らないでほしい範囲
  • 確認方法

だけでも十分です。

慣れてきたら、対象ファイルや完了条件も足していけば大丈夫です。

まとめ：CodexでWebアプリ開発を頼むときは、作業範囲と確認方法を書く

CodexでWebアプリ開発を頼むときは、「何を頼むか」だけでなく、「どこまで触ってよいか」「どう確認するか」まで書くと、作業結果を確認しやすくなります。

初心者ほど、依頼文が曖昧だと不安になりやすいです。

まずは、

  • 目的
  • 対象ファイル
  • 触らないファイル・箇所
  • 確認方法
  • 完了条件

を意識してみてください。

依頼文は、Codexをうまく動かすためだけのものではありません。
作業後に、自分が迷わず確認するためのメモでもあります。

きれいな文章でなくても大丈夫です。
「何をしたいか」「どこまで触っていいか」「どうなれば成功か」が書けていれば、CodexでのWebアプリ開発はかなり進めやすくなります。