Codex時代のLive Runtime Buildingとは｜動いている現場から設計を作る

バイブコーディングの先にあるもの

CodexのようなAI coding agentを使うと、動くものを作る速度は上がります。画面、フォーム、検索、管理画面、コードのたたき台を、以前より短い時間で作れるようになりました。

「バイブコーディング」という言葉があります。雰囲気で作り、AIに投げ、動いたら試し、細部はあとで考える。以前なら雑に見えた作り方も、AIによって現実的になりました。

ただ、あるところまで行くと、それは単なるバイブコーディングではなくなります。実際に入力し、検索し、フォームを送り、管理画面でデータを直すと、画面上では動いているのに違和感が出てきます。

検索結果が出ない、逆に出すぎる、変なものが混ざる、入力はできるが保存してはいけない値がある。こうした違和感が、次の設計を引っ張ります。

「この項目が出ないから追加する」だけなら、ただの修正で終わります。しかし実際には、その違和感の奥に構造があります。

入力欄の問題なのか、検索条件の問題なのか、表示ルールの問題なのか、保存してよいデータなのか、公開してよい情報なのか、権限の問題なのか、次回も覚えてよい状態なのか。使って初めて、その境界が見えてきます。

同じ「おかしい」でも、原因は一つではありません。データが足りない場合もあれば、データはあるのに出し方が悪い場合もあります。入力できても保存してはいけない場合や、表示してよいが初期値にはしてはいけない場合もあります。

違和感を単なる不具合として処理すると、個別修正で終わります。違和感を構造として見ると、責務の分け方やデータの扱いが見えてきます。

Live Runtime Buildingとは、動いているものを実際に使い、その場で出た違和感をもとに設計を更新していく開発の考え方です。ここでは、Codex時代の開発を考える言葉として使っています。

仕様を完全に決めてから作るのではなく、実際の利用状態を観察しながら、責務の境界やデータの扱いを見つけていきます。もちろん、設計が不要という話ではありません。むしろ逆です。

実際の入力や操作から出てきた違和感を見て、どこで止めるべきかを考えます。入力欄で止めるのか、保存時に落とすのか、表示だけ変えるのか、権限で分けるのか、データ構造を変えるのか。判断の場所を見つけることが設計になります。

使いながら違和感を見つけ、原因を切り分け、実装してまた使う。この周期が短くなると、設計は会議室ではなく、動いている現場から生まれます。

Live Runtime Buildingは、雑に作ることではありません。むしろ、体験の粒度まで降りて、そこから構造を掘り出すことです。

検索フォーム、入力フォーム、管理画面、業務ツール、社内向けのデータ管理画面では、使った瞬間に違和感が出ます。その違和感は、単なる好みではありません。

項目の必須性、保存可否、表示範囲、権限、取り消し、復旧、次回状態の保持。こうした設計上の判断が、実際の操作の中で浮かび上がります。

入力UIや管理画面は、ただの見た目ではありません。業務のルール、権限、保存、表示、例外処理が集まる場所です。だからこそ、実際に使ったときの違和感は設計の材料になります。

Codexで実装が速くなるほど、実際に使って違和感を見る力が重要になります。動くものが速くできるほど、動いたことと正しく設計されたことを分けて考える必要があるからです。

使ってみると、入力欄が足りない、出してはいけない情報が出る、保存すべきでない値が保存される、検索結果が多すぎる、権限の境界が曖昧になる、エラー時の扱いが弱い、といった問題が見えてきます。

バイブコーディングが「動くものを速く作る」だとしたら、Live Runtime Buildingは「動いたものを使い、違和感から構造を見つける」ことです。

AIが作る速度を上げるほど、人間は動いたものを観察し、どこに責務を置くべきかを判断する役割に移っていきます。

Live Runtime Buildingでは、作ることと使うことが分かれていません。作ってから使うのではなく、使うことが次の設計を生みます。

実際の入力が仕様の穴を見つけ、違和感が責務の境界を教え、デバッグが抽象化の必要性を見せます。これは、会議や仕様書を否定する話ではありません。

ただ、実際に入力し、操作し、壊れ方を見るまで分からない仕様や責務があります。

その意味で、入力や操作は単なる利用行為ではありません。設計を発見するための観察です。

Live Runtime Buildingとは、動いているものを実際に使い、その場で出た違和感をもとに設計を更新していく開発の考え方です。

Codex時代の開発では、動くものを作る速度は上がりました。だからこそ重要になるのは、動いたものを実際に使い、違和感を見逃さず、構造に変えることです。

入力欄、検索フォーム、管理画面、業務ツールのように、使った瞬間に違和感が出る道具では、実際の利用状態が設計を引っ張ります。

ただの修正が設計になり、ただの画面調整が責務分離になっていく。その短い周期を、ここではLive Runtime Buildingと呼びたいと思います。