Codexでアプリ開発!非エンジニアが失敗を防ぐ実践7ステップ
コードを書けなくても、Codexで仕事に役立つアプリを作れるのかと迷っていませんか。
空のフォルダと1画面・3機能に絞れば、非エンジニアでも試作できます。ただし、作れることと使い続ける価値は別です。
本記事では、作業時間削減シミュレーターの開発手順と、検証・運用・保守・セキュリティの判断を解説します。
既存ツールの劣化版を作らず、AIエージェント活用や収益化まで見通せるアプリ開発の考え方を身につけましょう。

監修者
SHIFT AI代表 木内翔大
Codexでアプリを作るとき、つまずきやすいのは作る手順そのものではありません。
どこまでを自分で決め、どこからをAIに渡すかで進み方が変わります。これはCodexに限らず、ほかのAIエージェントでも変わりません。
ただし、記事を読んで分かったつもりのままでは、自分の手作業で全部こなす状態は明日も変わりません。
SHIFT AIでは、AIエージェント無料セミナーを週2回ほど開催しています。CodexかClaude Codeを自分のPCで動かすまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。
【7ステップ】CodexでローカルWebアプリを開発する手順
CodexでローカルWebアプリを作る手順は、次の7ステップです。

ターミナルや外部サービスを必須にせず、自分のPC内で動かすところまで進めます。
ステップ1:練習用の空フォルダを作ってCodexアプリで開く
最初は、デスクトップなどわかりやすい場所に練習専用の空フォルダを作ります。ChatGPTデスクトップアプリでそのフォルダを開き、Codexを選びます。
本記事でいうローカルWebアプリは、インターネットへ公開せず、自分のPC内でブラウザから使うアプリです。
仕事の資料や写真が入ったフォルダを開くと、想定外のファイルが変更されたときに判断しにくくなります。
- フォルダ名は「
codex-demo」など用途がわかる名前にする - 個人情報、社内資料、パスワードは入れない
- ChatGPTデスクトップアプリで開いた後、表示されたフォルダ名を再確認する
| 準備するもの | 用途 |
|---|---|
| ChatGPTデスクトップアプリ(Codex) | ファイルの作成と修正を依頼する |
| 練習用の空フォルダ | アプリのファイルを保存する |
| Chromeなどのブラウザ | 完成したアプリを確認する |
| 架空のテスト数値 | 計算結果を検算する |
空フォルダなら、作業前後の違いが明確です。失敗しても練習フォルダ内でやり直せます。
ChatGPTデスクトップアプリのインストールや、Mac・WindowsでCodexを使う初期設定は、Codexアプリの記事で画面付きで解説しています。
ステップ2:作業時間削減シミュレーターの要件を3機能に絞る
初回のアプリ開発は、入力・計算・リセットの3機能に絞ります。
機能を増やすほど、確認する組み合わせも増えます。コードを読まなくても結果を検算できる題材から始めましょう。
| 項目 | 仕様 |
|---|---|
| 利用者 | 自分一人 |
| 入力 | ・1日の作業時間(1〜24時間) ・1か月の作業日数 ・削減率(%) |
| 出力 | 1か月で削減できる時間と分 |
| 操作 | 計算ボタンとリセットボタン |
| 使わないもの | ・個人情報 ・会員登録 ・決済 ・外部API ・外部ライブラリ |
シミュレーターの目的は、「定型作業を改善したときに、1か月で何時間浮くかを検算する」と一文で定義できます。
目的と禁止事項が明確なら、Codexも余計な機能を足しにくくなります。後で機能を足す場合も、3機能だけの版と比べれば変更の影響を確認できます。
ステップ3:初回プロンプトで作業計画を依頼する
最初のプロンプトでは、実装より先に作業計画と変更対象を示すよう依頼します。
いきなり作成させると、不要なフレームワークや複数ファイルが追加されても、非エンジニアには必要性を判断できません。
練習用のローカルWebアプリを作りたいです。
目的:
定型作業を改善した場合に、1か月で何時間浮くかを計算する。
必要な機能:
1. 1日の作業時間(1〜24時間)、1か月の作業日数、削減率を入力する
2. 1か月で削減できる時間と分を表示する
3. 入力と結果をリセットする
条件:
・1画面で操作できる
・HTML、CSS、JavaScriptを1つのindex.htmlにまとめる
・外部API、外部ライブラリ、外部通信を使わない
・個人情報を入力・保存しない
・日本語で表示する
まだファイルを作成・変更しないでください。
最初に、作業計画、作成するファイル、計算式、確認方法を示してください。

Codexが示した作成ファイル、計算式、確認方法を最初の指示と1項目ずつ照合します。指示にない外部通信や機能があれば、作成前に削除を依頼してください。
不明な工程がある場合は、実装前に「何のための作業か」をCodexに説明させます。説明できない工程を残さないことが、完成後の修正をしやすくするポイントです。
ステップ4:計画と変更対象を確認してアプリ作成を依頼する
Codexの計画では、作成ファイルがindex.htmlだけかを確認します。
パッケージの追加、外部サーバーへの接続、会員登録などが提案されたら、練習の範囲を超えています。
- 対象フォルダは
codex-demoか - 作成ファイルは
index.htmlのみか - 入力・計算・リセットの3機能に収まっているか
- 外部通信や秘密情報が必要と書かれていないか
計画と変更対象を確認しました。
このフォルダ内にindex.htmlだけを作成してください。
提案した3機能以外は追加せず、外部通信なしで動くようにしてください。
完了後に、作成ファイルと確認した内容を報告してください。

自分が説明できない構成に広がったときは、実装を急がず簡略化を依頼するほうが、後の保守負担を抑えられます。
「なぜそのファイルが必要か」を説明させ、納得できた範囲だけ作れば、非エンジニアでも変更履歴を追えます。必要性を説明できない設定ファイルは追加せず、まず1ファイルで完成させましょう。
ステップ5:完成したindex.htmlをブラウザで開く
Codexの報告を確認したら、Finder(Mac)またはエクスプローラー(Windows)からindex.htmlをダブルクリックし、ブラウザで実際の画面を開きます。
ファイルを作成できただけでは、アプリが正しく動くとは限りません。まず画面と基本操作を目視します。
- 3つの入力欄がある
- 計算ボタンとリセットボタンがある
- 計算結果を表示する領域がある
- 日本語が文字化けしていない

画面が開かない場合は、表示されたエラーや起きたことをそのままCodexへ伝えます。原因を推測して言い換える必要はありません。
ブラウザを開いた後は、画面を見るだけでなく、すべての入力欄とボタンを一度ずつ操作します。見た目だけでは気づかない不具合も、実際に操作すれば見つけられます。
ステップ6:動作を確認して修正を1件ずつ依頼する
画面を開けたら、手計算で誤りを見つけ、修正は1件ずつ依頼します。
画面の見た目だけでは、計算式の誤りは判断できません。事前に正解がわかるテスト数値を入れると、コードを読まなくても正確性を判定できます。
今回の初回版では、1日20時間、月20日、削減率50%と入力すると、削減時間は200時間です。
| 入力 | 計算式 | 期待する結果 |
|---|---|---|
| 20時間・20日・50% | 20×20×0.5 | 200時間 |
| 2.5時間・20日・30% | 2.5×20×0.3 | 15時間 |

未入力時の案内は初回から正しく表示されたため、修正不要でした。今回は30分単位も扱えるよう、入力単位だけを次のように変えます。
次の1件だけを変更してください。
現在の動作:1日の作業時間を1〜24時間で入力する
期待する結果:1〜1,440分で入力でき、結果を時間と分で表示する
変更しないもの:画面の色、作業日数、削減率、リセット機能
変更後に、通常の計算、未入力時の案内、リセットを再テストしてください。
1件ずつ直せば、別の機能が壊れたときも原因を絞り込みやすくなります。修正後は、対象の1件だけでなく、通常計算とリセットも再テストします。
ステップ7:修正版をバックアップして運用前の確認へ進む
基本動作を確認したら、修正版のフォルダをコピーして保存します。
バックアップに日付を入れておくと、後の修正で壊れたときに、動いていた版へ戻れます。
保存前に計算とリセットをもう一度試し、「動作を確認した版」だけをバックアップにします。動作未確認のファイルを正常版として残さないためです。
| 用途 | 作業時間削減の試算 |
|---|---|
| 使う人 | 作成者本人 |
| 保存場所 | バックアップを含むフォルダ |
| 更新担当 | 作成者本人 |
| 使用しない情報 | 個人情報・社内機密・APIキー |

自分のPCだけで使うなら、インターネットへ公開する必要はありません。共有や公開は、用途と安全性を確認してから検討します。更新担当と保存場所を記録すれば、次回の修正時に迷いません。
Codexで作ったアプリを非エンジニア自身が検証する4項目
Codexで作ったアプリは、非エンジニア自身が次の4項目を検証します。

「動いた」と「正しく動いた」を分ければ、コードを読めなくても不具合を見つけられます。
計算結果:手計算と一致するか確認する
計算アプリでは、画面が整っていても、計算式が間違っていれば使えません。
結果が簡単な整数になる例と、分から時間への変換が必要な例を用意します。
| テスト | 期待する表示 | 確認方法 |
|---|---|---|
| 1,200分・20日・50% | 200時間0分 | 手計算とアプリの表示を比較する |
| 30分・20日・50% | 5時間0分 | 分から時間への変換も一致するか比較する |
テストごとに入力値と結果をメモすると、修正後も同じ条件で比較できます。テスト条件を変えないことが、修正の効果を判断するポイントです。
表の期待結果とアプリの表示が一致しなければ、使用を始める前にCodexへ修正を依頼します。計算ミスを残さないことで、試算を業務判断に使えます。
入力値:未入力・負数・極端な値を試す
正常な数値だけでなく、入力ミスを想定した値も試します。
未入力で0という結果を出したり、負数で負の削減時間を出したりすると、利用者は間違いに気づけません。
- すべて未入力
- 作業時間または作業日数が0
- 作業時間または作業日数が負数
- 削減率が100%を超える
- 現実には考えにくい極端に大きな数値
初回版は1〜24時間でしたが、30分など細かい作業を扱うため、検証前に1〜1,440分へ変更しました。
作業日数は1〜31日、削減率は0〜100%とします。範囲外は計算せず、どの値を直すか日本語で表示させましょう。
入力値の検証を追加してください。
・1日の作業時間:1〜1,440分
・1か月の作業日数:1〜31日
・削減率:0〜100%
未入力や範囲外の値では計算せず、
修正が必要な項目を日本語で表示してください。
正常値の計算とリセットは壊さないでください。

入力できる範囲と、範囲外の場合に表示する案内を先に決めると、必要な修正をCodexへ具体的に伝えられます。利用者も入力ミスにすぐ気づけます。
画面表示:ブラウザ幅を狭めても崩れないか確認する
通常のブラウザ幅で問題がなくても、幅を狭めると文字やボタンが重なる場合があります。
本記事のローカル構成では、スマートフォンでの公開URL確認を必須にせず、PCのブラウザ幅を狭めて確認します。

- 横スクロールが必要になっていない
- 入力欄が画面からはみ出していない
- ボタンの文字が切れたり、ボタン同士が重なったりしない
- 計算結果を画面内で読める
将来公開する場合は、実際のスマートフォンや複数ブラウザでのテストも追加します。
幅を狭めた状態で、入力、計算、リセットを順に試します。表示が崩れなくても、ボタンが押せないなら修正が必要です。
確認する幅を決めておけば、修正前後を同じ条件で比較できます。見た目と操作の両方を確認することが、公開前テストの基準になります。
ファイル変更:指定したフォルダ以外が変わっていないか確認する
最後にCodexへ、この作業で作成・変更したファイル一覧を出すよう依頼します。
一覧とFinder(Mac)またはエクスプローラー(Windows)のフォルダ内容を比べ、index.html以外のファイルがあれば、用途を確認します。
この作業で作成・変更したファイルをすべて一覧にしてください。
それぞれの用途と、指定したcodex-demoフォルダ外を変更したかも報告してください。
用途がわからないファイルを見つけても、自己判断で削除してはいけません。バックアップを残し、役割を確認してから対応します。
確認対象を練習フォルダに限定すれば、非エンジニアでも変更の全体を把握しやすくなります。変更範囲の確認方法を身につけると、次の開発でも判断基準として使えます。
Codexの機能と対応する作業の全体像は、OpenAI Codexの解説記事で整理しています。
Codexを使ったバイブコーディングで避けたい3つの失敗
Codexを使ったバイブコーディングでは、次の3つの失敗を避けます。

アプリを作れたという事実より、作る必要性と、作った後も安全に維持できるかが重要です。
既存ツールの劣化版:Notionやスプレッドシートで代替できないか確認する
アプリ開発を始める前に、既存ツールで十分ではないかを確認します。
Notionにデータを並べる、またはスプレッドシートに関数を入れるだけで解決するなら、自作する理由は弱くなります。
| 判断項目 | Notion | スプレッドシート | 自作アプリ |
|---|---|---|---|
| 向く用途 | 情報の整理・共有 | 表計算・集計 | 独自の操作・処理手順 |
| 始めやすさ | テンプレートから始めやすい | 関数と表を使える | 要件設計が必要 |
| 自由度 | 提供機能の範囲内 | 表形式の処理に強い | 用途に合わせて変えられる |
| 保守 | サービス側が基盤を管理 | サービス側が基盤を管理 | 作成者側が修正・テスト |
| 選ぶ基準 | ページとデータベースで足りる | 表と関数で足りる | 既存ツールで解決しにくい |
既存ツールと同じことを低い完成度で作り直す「車輪の再発明」は、開発時間と保守負担を増やします。
独自の計算、特定の業務手順、複数工程の自動化など、既存ツールで解決しにくい理由がある場合に開発を選びましょう。理由を一文で説明できないときは、先に既存ツールを試します。
運用設計の不足:更新担当と保守コストを先に決める
アプリは、完成した日で終わらず、使い続ける間の運用・保守が必要です。
業務ルールや入力形式が変われば、アプリ側も修正します。修正後は、元の機能が壊れていないか再テストが必要です。
- 要件や業務ルールが変わったときの更新
- 修正後の計算・入力・表示テスト
- 動作する版のバックアップ
- 利用者からの問い合わせと不具合対応
- 外部APIや有料サービスを使う場合の継続費用
「作った本人しか直せない」状態にすると、担当者の変更で使えなくなります。用途、仕様、確認項目、バックアップ先を文章で残します。
アプリで減らせる作業時間より、保守にかかる時間のほうが長いなら、自作を続ける価値は下がります。定期的に費用対効果を見直しましょう。
セキュリティ配慮の不足:機密情報を入れず外部送信の有無を確認する
ローカルで動くアプリでも、必ず安全とは限りません。
ファイルをクラウド同期したり、メールで共有したりすれば、データがPC外へ出る可能性があります。
- 個人情報、社内機密、APIキーをプロンプトやファイルに入れない
- 外部ライブラリやAPIの接続先と送信内容を確認する
- ファイルの共有先とクラウド同期設定を確認する
- 認証・決済・医療・金融を扱うなら専門家の確認を受ける
本記事のサンプルが外部通信なしに限定されているのは、初回の確認対象を減らすためです。
外部通信の有無、保存する情報、共有範囲を一つずつ確認すれば、安全に検証できる試作範囲を限定できます。判断できない情報を扱う場合は、公開や共有の前に専門家へ相談します。
バイブコーディングの危険性と安全な始め方は、以下の記事で詳しく解説しています。
Codexで開発したアプリを収益化につなげる3つの条件
Codexで開発したアプリを収益化するには、次の3つの条件が必要です。

試作のハードルが下がるほど、「作れる」という事実だけでは差がつきにくくなります。
差別化:作れるだけでは選ばれないため独自価値を決める
アプリの機能数より、誰のどの課題を解決するかを絞り込みます。
一般的なタスク管理や文章要約のように、既に選択肢が多い用途では、似た機能を追加するだけでは選ばれません。
- 現場の業務知識を反映した独自の手順
- 利用者が迷わず使える操作と画面
- 結果の正しさと安全性に対する信頼
- 導入後のサポートと改善
開発前に利用候補者へ聞き取りを行い、「誰が、何に困り、今はどう解決しているか」を確認します。
独自価値が言葉になれば、開発すべき機能と、作らない機能を分けられます。競合と機能が似ていても、対象業務や導入後の支援が明確なら、選ばれる理由を示せます。
価値:AIエージェントで提案から実行まで広げる
差別化を考えるときは、AIエージェントの2つの使い方を区別します。
| 使い方 | 役割 | 確認すること |
|---|---|---|
| 開発作業にAIエージェントを使う | 設計・ファイル作成・修正・テストを支援 | ・変更範囲 ・動作結果 ・保守方法 |
| 完成アプリにAIエージェント機能を入れる | 情報を整理し、提案や次の操作を実行 | ・権限 ・誤作動 ・外部送信 ・API費用 ・人の承認 |
単に計算結果を表示するだけでなく、結果から次の行動を提案し、承認後に必要な作業を進めると、利用者への価値は広がります。
一方、外部データや他サービスを操作させると、権限・失敗時の停止・コスト管理が必要になります。
本記事の練習用アプリには、AI機能を無理に入れません。基本動作を人が検証できてから、必要性のある機能だけを追加します。機能の目的が明確なら、価値とリスクを比較できます。
収益性:顧客が対価を払う成果か小さく検証する
収益化を目指すなら、利用候補者の「使ってみたい」ではなく、対価を払う成果かを確認します。
時間削減、売上向上、ミス削減など、導入前後で比較できる成果を一つ決めます。
| 収益化の方法 | 対価 | 主な継続コスト |
|---|---|---|
| 買い切り | アプリ自体の販売 | ・不具合修正 ・環境変化への対応 ・問い合わせ |
| 月額課金 | 継続的な利用と改善 | ・ホスティング ・API ・保守 ・サポート |
| 導入・運用支援 | 個別設定と継続サポート | ・作業時間 ・個別改修 ・利用者教育 |
試作を見せた後に、小規模の有料テストを行うと、実際の支払い意向と必要な改善を確認できます。
利益は売上だけでは判断できません。開発後の保守・API・集客・サポート費用を差し引き、継続できるかを確認します。有料テストの結果で要件と価格を見直し、開発し続けるかも判断しましょう。
検証にかける時間を確保できるかどうかが、作り切れるかの分かれ目になります。
人が決める部分と渡してよい工程を分けておくと、確かめる時間が残ります。
SHIFT AIでは、AIエージェント無料セミナーを週2回ほど開催しています。CodexかClaude Codeを自分のPCで動かすまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。
スキルゼロから始められる!
AIエージェントセミナーの日程を選ぶCodexのアプリ開発に関するよくある質問
Codexのアプリ開発に関する質問は以下の5つです。
- Codexのアプリ開発にターミナル操作は必要か
- 作ったアプリは公開しなくても使えるか
- ローカルWebアプリとChatGPT Sitesはどう使い分けるか
- CodexでiOSやAndroidアプリも開発できるか
- Codexは無料プランでも使えるか
記事の手順を自分の環境で試せるか判断する参考にしてみてください。
Codexのアプリ開発にターミナル操作は必要ですか?
本記事のように、単一のindex.htmlを作ってブラウザで開く手順なら、ターミナル操作は必須ではありません。
複雑なWebアプリでは、パッケージの導入、ローカルサーバーの起動、ビルドやテストのコマンドが必要になる場合があります。その段階で、ターミナルが登場します。
Codexにコマンド実行を任せる場合も、対象フォルダ、実行内容、エラー、テスト結果は人が確認します。理解できない操作は、実行前に目的と影響を説明させてください。
作ったアプリは公開しなくても使えますか?
自分のPC内で使うローカルWebアプリなら、インターネットへ公開しなくても使えます。公開URLも不要です。
index.htmlをブラウザで開き、入力・計算・リセットが動けば、本記事のサンプルは完成です。オフラインでも、ファイルがPCにあれば起動できます。
社内の複数人で使う場合や一般公開する場合は、ホスティングだけでなく、データの扱い、アクセス範囲、不具合時の対応を追加で決めます。共有する人が増えるほど、運用の責任も増えます。
ローカルWebアプリとChatGPT Sitesはどう使い分けますか?
個人の練習や非公開の試作はローカル、チームで使う社内ツールはChatGPT Sitesが選択肢です。
ChatGPT Sitesはマネージドホスティングを含み、焦点を絞った社内向けWebアプリの作成、テスト、共有に利用できます。自分だけで完結する練習に、必須の機能ではありません。
一般的なWebアプリを継続運用する場合は、Vercelなどのデプロイ先も候補です。用途、保存データ、共有範囲から選びます。
>ChatGPT Sitesの公式活用例はこちらから
CodexでiOSやAndroidアプリも開発できますか?
CodexはiOSやAndroidアプリの開発も支援できますが、本記事の手順に加えて追加の開発環境が必要です。
スマートフォン向けでは、OSごとに開発・テスト・配布の準備が増えます。
- iOS(SwiftUIの例):Mac、Xcode、署名、実機またはシミュレーターでのテスト、App Store配布手続き
- Android:Android StudioやExpoなどの開発環境、実機またはエミュレーターでのテスト、配布手続き
ストア配布を目指すなら、ブラウザとは別の確認工程も見込みます。配布後の更新対応も必要です。
初回はブラウザで確認できる小さなWebアプリで、要件設計と修正の型を練習してから、対応端末を広げます。
>公式活用例はこちらから
Codexは無料プランでも使えますか?
はい。2026年9月2日時点では、ChatGPT FreeプランにCodexが含まれます。短いコーディングタスクで試せますが、利用上限や対応機能はプランごとに異なります。
プラン名が同じでも、ローカルタスク、クラウドタスク、コードレビューなどで利用条件が異なる場合があります。利用回数の上限と対応機能も確認が必要です。
現行の料金プランと無料で試す方法は、Codexの料金記事で更新しています。古い料金表だけで判断しないでください。
>Codexの公式料金・プラン情報はこちらから
Codexのアプリ開発は小さく作り検証と運用まで設計しよう
Codexのアプリ開発は、空フォルダ・1画面・3機能から始めると、非エンジニアでも変更と結果を確認できます。
作業計画を先に確認し、作成後は計算、異常値、表示、変更ファイルを人が検証しましょう。
Notionやスプレッドシートで足りるなら、作らないことも正解です。開発するなら、保守とセキュリティまで設計します。
小さく作って検証する力が身についたら、次に必要なのは開発以外の工程もどこまで任せるかという判断です。そこを独学で詰めるのは遠回りになりがちです。
AIの使いどころが見えても、工程を前に進めるのは自分という点は変わりません。
SHIFT AIの無料オンラインセミナーでは、CodexかClaude Codeを自分のPCで動かすところまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。
スキルゼロから始められる!
AIエージェントセミナーの日程を選ぶ目次
執筆者
宇津木隼人
複数のAI系SEOメディアでライターの経験。
専門・得意な領域はSEO/GEO/コンテンツマーケ/アプリケーション開発。





スキルゼロから始められる!
AIエージェントセミナーの日程を選ぶ