Codex時代の新たなバイブコーディングワークフロー (Before CodexとAfter Codex) (2025/10/01) Codex使ってみてどうだった？AIコーディングエージェント最前 線Lunch Talk #codex_findy Codex時代の新たなバイブコーディングワークフロー @erukiti 1 

自己紹介 erukiti (左が旧アイコン) 株式会社AlgomaticのAIエンジニア 「AI革命で人々を幸せにする」 「時代を代表する事業群を創る」という会社です アポドリとかリクルタとかAlgoGames（とか他いっぱい）やってます！ 2023年にできたスタートアップだけど、いま表に出てるカンパニーだけでも4つあって、全部売り 上げがたってて、全事業、全職種募集してます！生成AIで何か新しい事業をやりたい人も来てくだ さい（CEO人材も続々集まっています） 興味ある人は「Algomatic（アルゴマティック） 」で検索して！！！ https://recruiting.algomatic.jp/ 2023年から本当の意味で「LLMにAll in one」をやり続けてます。 興味ある人はnoteに書いた「Algomatic erukiti 入社エントリ」を探してみて AI革命(LLM)がもたらす未来にしか興味ないです LLMプロダクト専業で、チャット型とかRAGやAIエージェント作ったり、新規事業開発をやりつづけて ます Codex時代の新たなバイブコーディングワークフロー @erukiti 2 

アジェンダ 1. 放置プレイを軸とした開発ワークフロー 2. 軽量な動くモックを使った、全体ワークフロー Codex固有の話ではなく、Codexレベルの性能を前提とした話で す Codex時代の新たなバイブコーディングワークフロー @erukiti 3 

1. 放置プレイを軸とした開発ワークフロー Codex時代の新たなバイブコーディングワークフロー @erukiti 4 

Codexいいですよね。 旧Claude4よりも圧倒的に賢い。具体的にはコンテキストでいろいろ指示をしても 理解して考えてくれるので、無視される率が低い 旧Claude4よりも少ない手数でゴールにたどり着く 旧Claude4よりも嘘つき率が圧倒的に低い。旧Claude4はしれっと嘘をつくことが 多すぎた やりきり力も高い つまり旧Claude4よりも安心して放置プレイができる Codex時代の新たなバイブコーディングワークフロー @erukiti 5 

※ 極めて個人的な思想です Googleは金と技術力と人員と蓄積。OpenAIは金と技術力と人員と政治力がズバ抜 けすぎてる。Anthropic大変そう （9/30に出た）最新のClaude Sonnet 4.5 もベンチマークはCodex並に良さそうだ けど、個人的にはOpenAIの方が将来有望だと思う とはいえ、まぁSonnet 4.5を前提に考えるなら、今日の話は応用が効くかも。知ら んけど！ Codex時代の新たなバイブコーディングワークフロー @erukiti 6 

Vibe Kanban + Codex このネタで記事を書いたり、社内LTしたりで、布教してる https://note.com/erukiti/n/nbeb0c2b521b9 プロダクト開発でも使ってる CLIやVSCode拡張を直接触ってた時代にはもう戻れない 放置プレイと相性がめっちゃいい Codex時代の新たなバイブコーディングワークフロー @erukiti 7 

Codex時代の新たなバイブコーディングワークフロー @erukiti 8 

Vibe Kanban は弱点もある 今年6月に生まれたホットなプロダクトで、不安定なバージョンが続くことも多い DBのマイグレーションで問題生じたりとか、無限ローディングとか 過去のバージョンを使ったり、パッチ当てた自分用のnpm作ったりして運用 することもある そもそもタスク管理というメタファーは、ベストとは思えない が、ベターではある Vibe KanbanはCLIで使うよりもインタラクションが弱い 履歴を遡って修正ができない Codex時代の新たなバイブコーディングワークフロー @erukiti 9 

逆に考えるんだ！ Codex時代の新たなバイブコーディングワークフロー @erukiti 10 

制約を受け入れた方がいいことはよくある話 Codexは放置プレイでそれなりにいいところにいけるんだからインタラクション は不要 変にCLIであれこれできると、途中で止めたり、やり直ししたり、追加で投げまく るからサンクコストが増えてしまう だめだったら捨てればいい！！ チケット作りまくって放置プレイする方が効率的なのでは？ Codex時代の新たなバイブコーディングワークフロー @erukiti 11 

2. 軽量な動くモックを使った、全体ワークフローの改善 Codex時代の新たなバイブコーディングワークフロー @erukiti 12 

バイブコーディングが一番革命的なポイントは、非エンジニアが プログラムを作れるようになったこと！ ChatGPTを契約していればCodexを使えるので、 （コスト面だけなら）だれでもお 手軽に導入できる エンジニアがペアとかモブで、バイブコーディングを一緒にやってあげるのもい いのでは？お互い得るものが多い CSVを吐き出すとか、データ整形をするとか、今までならエンジニアに作業依頼 を出してたものを、好き勝手に自分で作れる！！！ Codex時代の新たなバイブコーディングワークフロー @erukiti 13 

最近、非エンジニアが動くモックをバイブコーディングする事例 を見聞きするようになった 1. プランナーが企画ものを自分でモックに起こして、デザイナーとエンジニアがさくっと形に した 2. PdMが2・3時間で作ったモックを、エンジニアが5時間くらいでCodexを使って完成させた 社内ツール（この事例ではPdMが作ったコードをそのままひきついだらしい） 僕がぱっと見た感じでは、全体で二週間くらいはかかりそうな分量のもの 3. ほか、諸事情で詳細は伏せるがゲーム業界でも似たような話を聞いた 4. ツイート(ポスト)したときも、 「うちでもやってます」みたいな反響あり みんなまだ手探りだけどやり始めてるっぽい！ Codex時代の新たなバイブコーディングワークフロー @erukiti 14 

PRDという悪習 ワードやパワポやExecl芸を駆使して作られる 動くモックであれば一瞬で伝わるものを、時間をかけて言語化して文章に書き起 こす（それを人間が頑張って解読する。 。 。あれ？） 逆に、デザイン素人が、Excel芸やパワポ芸やFigmaで中途半端にデザインに手を 出すことも多い（で本職が頭を抱える） PRDを作りたがる人、エンジニアを中途半端に経験してることも多い 非機能要件とかはさておく（というか棲み分け考えましょう！って話ではある） Codex時代の新たなバイブコーディングワークフロー @erukiti 15 

「軽量な動くモック」による意思疎通（によるワークフロー）を 提唱したい 1. 「軽量な動くモック」をプランニングの起点となる人が作る 2. 1で作られたモックを元に関係者で認識をすりあわせる 3. 実際に作る！ ※ もちろんこのすりあわせは、いつでも何度でもやっていい Codex時代の新たなバイブコーディングワークフロー @erukiti 16 

軽量な動くモック 軽量な動くモックは、すぐ作れる範囲が望ましい（理想をいえば10分でさくっと作る。せいぜい2時間 以内） 軽量な動くモックは、できうる限り最小限の仕様にしなければならない 軽量な動くモックは、不完全でも良い 軽量な動くモックは、デザインソースではない 軽量な動くモックは、PoCではない 軽量な動くモックは、ソースコードではない 軽量な動くモックは、成果物ではない 軽量な動くモックは、仕様についてのコミュニケーションツールである 軽量な動くモックは、心置きなく捨てられるものであるべき Codex時代の新たなバイブコーディングワークフロー @erukiti 17 

軽量な動くモックの作り方のおすすめパターン 「白黒、線画、アニメーションなし」という指示おすすめ モックはアブストラクトでよい サイズ感がちいさければHTML+CSS+JSで作るのがよい ある程度のサイズ感だとVite+React+TypeScriptで作らせる TSXファイルにはロジック禁止 適切な分割をさせる feature sliced directory(FSD)を採用させる Codex時代の新たなバイブコーディングワークフロー @erukiti 18 

軽量な動くモックを使った、全体ワークフローの改善 文字情報や中途半端なパワポ芸とかExcel芸よりも遙かに理解しやすいのが軽量な 動くモック (プロダクト品質じゃなければ)バイブコーディングは非エンジニアでもできる エンジニアが、設計のためにこういうのを作るというのもあり まだまだどの会社も模索中だけど、開発全体のワークフローを革命的に改善でき る可能性がある！ ※ こっちは旧Cluade4世代でも可能な話かもです！！！ごめん！！！ Codex時代の新たなバイブコーディングワークフロー @erukiti 19 

ご清聴ありがとうございました！ Codex時代の新たなバイブコーディングワークフロー @erukiti 20