80/20エンジニアリング：私が週末でサイトを再構築した方法

秘密を教えましょう：私が個人サイトを週末で書き直せたのは、特別にコーディングが速かったからではありません。ほとんどコーディングをしていなかったからです。

代わりに、ほとんどの開発者がまるで疫病のように避ける「準備」に時間を費やしました。ドキュメント作成。書き残すこと。そしてついにエディターを開き、OpenAIのCodexと一緒に作業を始めたら、実際の実装はまるでリハーサル済みの手品のようにあっという間に終わりました。

これは、コードを一行も書く前に80％の作業を終わらせることがいかに効果的で、すべてを変えたかの物語です。

なぜサイトを書き直したのか？

私のサイトはQwik v3で動いていました。技術的には堅実で良かったのですが、特にルーティングの柔軟性をもっと求めていました。そこでReact Routerのフレームワークモードに乗り換えました。単なるリファクタリングではなく、完全な再構築です。新しいアーキテクチャ、すっきりしたファイル構造、最新のスタイリング（Tailwind v4を導入）、そして真っ白なキャンバスです。

驚いたことに、実際のコーディングは2〜3時間程度で終わりました。最初から最後までです。そして一発で動きました。

では残りの5時間は何をしていたのでしょう？

80％の部分：コンサルタントが提案資料を準備するようにCodexを準備する

作業の大半は「メガプロンプトシステム」を作ることに費やしました。華やかなUIではなく、プロジェクトフォルダ内で行いました。Codexにコンポーネントを書かせる前にやったことは以下の通りです：

React Routerのドキュメントを丸ごとダウンロードし、/guides ディレクトリに保存しました。
Tailwind CSS v4も同様に対応し、Firecrawlを使って関連ページをMarkdownに変換しました。
プロジェクトの概要を記した PROMPT.md ファイルを作成しました：
- 「レガシーコードは / にあり、新しいコードは /app に書く」
- 「UIは最小限に、ビジネスロジックに集中する」
- 「Tailwind v4を使用し、React Routerはフレームワークモードに固定する」
- などなど

これはただの無駄な作業ではありませんでした。これは実務上のコンテキスト情報です。新規チームメンバーに初日に渡すような詳細な指示書のようなもの。Codexは私の望みをただ推測していたわけではありません。リポジトリ内にドキュメントがあり、英語で明確なルールと制約が定義されています。

ついにこう入力した時：

「PROMPT.mdを読んで。まず全ルートを新しいappに移行して。」

Codexはまるでこの任務をずっと待ち望んでいたかのように反応しました。

メガプロンプトがもたらす最小限の幻覚

結果は驚異的でした。Codexは指示に忠実に従い、幻覚（誤った内容）を起こしませんでした。勝手な創作をせず、「UIに拘るな」という指示を守り抜きました。サーバーロジックの移行は精密で、ルート設定はまるで自分が辛抱強いコンパイラになったかのようでした。

これは単なる「プロンプトエンジニアリング」ではありません。Codexを現実的かつ最新の仕様でしっかりと基づかせることでした。あいまいなタスクや機能の希望リストではなく、構造化された入力、明確な例、そして必要なドキュメントへのローカルアクセスです。

時間がかかったのはコードではない

基盤ができた後、作業は2つの明確なフェーズに分かれました：

Codexモード – 素早く、構造的で繰り返し可能な実行。移行、ロジック、レイアウトのスケルトン作成まで、ほぼ完璧な精度でした。
デザイン探索モード – ゆっくりで手作業、自由な試行錯誤。ここは人間の仕事：ビジュアルスタイルを選び、レイアウトを試し、コンポーネントを試作し、 workableなビジュアルスタイルができたらまたCodexがパターンを伝播してくれました。

本当の遅れは、どう「見た目にしたいか」を私自身がはっきり決められなかったことからきています。「どう動かすか」ではなくてです。