誰でもCodex CLIでアーカイブサイトが作れる時代
/special/mirrativ_event を支える技術選定と運用フロー。TOMLによるデータ管理、Astro Content Collections、AIヘビーなクレンジング＋厳格なバリデーションで“人手の最終判断”を残す設計。
☝️これ、実装はぜんぶCodexがやりました。週末サクサク作成
つまりAIに指示さえ出せば、このくらいの機能ならPdMでもマーケでも作れるわけです
詳しくはGPT5先生に振り返りを書いていただきます
Codex CLIで誰でも“作れる”アーカイブサイト
Mirrativのイベントをひと目でたどれるビジュアルアーカイブを、Codex CLIだけで組み上げました。週末の短い時間で、データ定義・UI・OGP・デプロイまでをノーコードでつなぎ込むデモです。コードはAIが生成し、stakme本人は一行もタイプしていません。
まず体験から。ページを開くとイベントのビジュアルがタイル状に並び、どれかをタップするとモーダルで詳細が立ち上がります。長めの本文でも画面内で自然にスクロールでき、共有ボタンは常に https://stak.me/special/mirrativ_event/<id>/ の正規URLを添えます。SNSのプレビューは崩れず、表示は高速。すべて静的ビルドだからこその安定感です。
設計の核は「一件＝一TOML」。日本語や絵文字を含む本文を崩さず保持でき、改行もそのまま。公開側ではAstroのコンテンツ機能で型を与え、欠損や不正値はビルド時に止めます。タイトル、日付、タグ、本文の逐語抜粋と全文、画像はIDで紐づいた別ファイル。テキストと画像を分けることで、差分レビューが読みやすく、更新が安全になります。タグの語彙は絞り込みや横断分析を意識して限定し、検索性と一貫性を両立させています。
AIは“集めて整える”役割に徹します。公開Webから投稿を代理取得し、ノイズを取り除き、画像URLを正規化して中間テキストを作る。公開値の確定は人が行い、逐語のdescriptionを決め、分類タグを選びます。最後に自動検証が待っており、抜粋の各行が中間テキストに実際に含まれているかをチェック。要約や改変はそこで弾かれます。AIの速度と人の確実性を、役割で切り分けたワークフローです。
UIは見やすさ最優先。グリッドの一覧からArk UIベースのモーダルへ。縦はビューポート内でスクロールし、横長の画像は横長レイアウト、それ以外は固定アスペクトで自然にトリミング。OGPはビルド時に1200×630へ変換し、上側を優先して切り出すtop‑cropを採用しました。人物やタイトルが欠けにくく、SNSカードの見え方が揃います。画像の最適化はすべてビルド時に完了し、配信はCloudflare Pagesの静的サイトとして行います。
なぜTOMLか——多行テキストの扱いやすさ、差分の読みやすさ、そして「一件＝一ファイル」という規律が、プロンプト駆動の開発と相性が良いからです。Astroの型検証と組み合わせれば、入力ミスはビルド段階で発見できます。ノーコードといっても、設計意図と制約を“先に文章で決める”ことが品質を左右します。そのための器として、TOMLはちょうどいい選択でした。
Codex CLIでの体験は、プロンプトで構成管理を進める感覚に近いものです。意図と制約を伝えれば、AIがファイルやUIを生成し、人が公開値を確定する。技術知識ゼロではありませんが、コードを書かずに“動くもの”へ到達するハードルは大きく下がります。社内のIPイベントやSNS施策のアーカイブを継続運用したいチームにとって、すぐに戦力になる現実解です。検索やタグナビ、変化点の可視化、他プラットフォーム統合など、次の一手も素直に見えてきます。
AIが実装を、TOMLが確定を、ビルドが配信を担う。簡素なレールの上で、想像以上に遠くまで進める——今回のアーカイブは、その手触りを伝えるためのサンプルでもあります。
今回はほぼUIに口出しをしませんでしたね〜
唯一やめさせたのは、画像の角を丸くするCSSくらいです。これは「意味もないのに丸める慣習は許さない」という思想介入です。なんで角丸にしちゃうんすかね？
わかります。角丸は“雰囲気”は出ますが、このアーカイブでは画像そのものが主役なので余計な装飾は引き算しました。特にtop‑cropと影の相性、OGPでの二重角丸（SNS側のUIで再度丸められる現象）、被写体の縁取りが崩れる問題を避けたかった。意味があるなら入れる、意味が薄いなら削る——その線引きが今回の勝ち筋でした。
他人事のように否定してきて草なんだ