はじめに
非プログラマの私が、朝晩Codexに指示をして、あとはほったらかしで、Codexにコーディングしてもらう方法を見つけましたので、ここにメモを残しておく趣旨です。
以下の記事に記載した、１ヶ月間、Codexでソフトを作ってみて得られた知見です。
これらの手法を取ることで、長いと３日から４日程度の間、一切プロンプトに戻らず、延々とCodexが動き続けることが、できました。
真似をして、大事なファイルが破壊された、大事な情報が流出した、システムが起動しなくなったとしても、責任を負いませんので、自己責任にてお願いいたします。
課題１：できるだけほったらかしで進めておいてほしい。
できるかぎり、朝晩に短時間で指示をし、仕事に出ている昼間と、寝ている間に、コーディングをしてもらいたいのですが、１０分コーディングして止まっていたのでは、ちっとも進みません。いちいち停止してどうするかプロンプトに聞いてこられるのでなかなかアプリの作成が進まないという課題があります。
かといって、権限を与えると、ファイルを壊したり、データ流出させたりしてしまうおそれが出てきます。
そこで、まず、個人情報がはいっておらず、ファイルサーバなどにも接続されていないPCを、用意します。
用意できない場合には、仮想マシンなどでホストから分離したサンドボックス環境を用意します。
例えば、Windows10,Windows11のpro版であれば、下記の方が記事にまとめてくれているように、サンドボックス環境を作る。
サンドボックスを破棄すると作ったファイルもすべて破棄されてしまうので、以下の方がやっているように、ホスト側の特定のディレクトリだけ
<ReadOnly>true</ReadOnly>
の行は削除して書き込めるようにするなど。
あるいはWindows Home版の方などは、VirtualBoxなどの仮想マシン上にOSをインストールするなど。
こちらの方がまとめてくれています。
あるいはWSL2でLinuxをうごかすなど。
Macであれば、VirtualBuddyなど。
ターミナル（コマンドプロンプト、パワーシェル、bash、cshその他）では、以下のオプションを付けて起動する。Windowsでは管理者権限でターミナルを起動すると完全に必要なソフトのインストールなど管理者権限が必要な操作も自動でやってくれて、Codexがいちいち聞きにこなくなる。
codex --dangerously-bypass-approvals-and-sandbox --search
以下codex --helpで表示される--dangerously-bypass-approvals-and-sandboxの説明です。確認のプロンプトに戻らない。ただし EXTREMELY DANGEROUS 極めて危険と記載あり。
このオプションをつけることで、確認をしてきにくくなり、長時間に渡ってコーディングをしてくれます。
また--searchを付けて起動すると、codexがネット検索することができます。
そのため、「わからないことがあったらネット検索して調べて進めて」と入れるだけで、質問に戻ってこなくなります。
また、管理者権限でのターミナル起動＋--dangerously-bypass-approvals-and-sandbox ＋--searchのコンボにより、環境構築も自動的にやってくれます。デプロイも自動的にやってくれますし、Githubへのアップも自動的にやってくれます。
指示例「gitをインストールして適切に使用して手戻りできるようにしつつ進めて、最後にgithubにアップして。必要なコマンドは検索してインストールして進めて」
課題２：Codexが作ったソフトの実行結果がわからず止まる（プロンプトに戻って聞いてきてしまう）
Codex自体に実行結果を見せる環境を作ってもらって、実行結果を見て進めてもらうように指示する。
Webアプリを作っているなら、「実行後にブラウザのスクリーンショットをとって、またブラウザの内容を確認して、正常に動作するまで、繰り返し実行・内容確認・修正を繰り返して。できあがったらプロンプトに戻ってきて。必要なツールはWebから持ってきてインストールして進めて」のような指示。
Androidアプリを作っているなら、「Androidの開発に必要な環境をWeb検索して整備して。実行画面のキャプチャ、実行時のログを自動的に参照してできるように環境整備して。コーディングができたら自動的にビルドして実行して、内容を確認することを、正常に動作するまで、繰り返して。ビルド・実行・内容確認・修正を繰り返して。できあがったらプロンプトに戻ってきて。必要なツールはWebから持ってきてインストールして進めて。」のような指示。
「適切なデバック用のコードを埋め込んでその結果を見て修正して」のような指示や、「テストコードを書いて確かめて」のような指示も連続実行しなくなったときに有用。
課題３：成果物が妥当かの検証が素人にはできない
動作するものができたら、新たなセッションで、新たな言語モデルを選択して、「このフォルダ配下のコードの妥当性を一般的なソフト開発の検証項目で検証し、１００点満点でレポートしてください。」のような指示をしてAIに検証させる。コード品質、セキュリティなど各項目でだしてくれるので「１００点満点になるように修正して」のような指示で品質を高める。
できたらまた別のセッションで、新たな言語モデルを選択して繰り返すなど、AIに相互評価させる。
課題４：他の環境への移植が素人にはできない
Windows版のソフトを作った後、Mac版を作る場合などでは、まずWindows版の方のCodexに「このソフトをMac側のCodexでMac版としてビルドするためのプロンプトを出力して」として、出力されたプロンプトをMac側のCodexに貼り付ける。
課題５：Webアプリの配布が難しい
単にアプリの仕様を指示するだけだと、実行環境がサーバーサイドを含む形（Streamlit, Vercelなど）を生成しがち。そうすると、メールで添付して配布などがやりづらい。
そこで魔法の呪文「◯◯をするアプリをhtmlファイルで生成して」とすると、htmlファイルをブラウザで開くだけで実行可能なアプリが生成される。
まとめ
以上、プログラマの方からみると、邪道かもしれないですが、ハンドアセンブルしていた時代→アセンブラに任せる時代→コンパイラにまかせる時代→「日本語」まかせる時代 への変化が始まったところ、バイブコーディング元年として、メモとして記しました。
最後まで御覧いただきありがとうございました。