Prompt を、動くものまで連れていく。

画面を作る前に、誰がどこで困っているのか、どんな状態なら助かったと言えるのかを、自分の言葉で書く。機能名だけでは、入力、応答、例外、終了条件がまだ言葉になっていない。

まずはブラウザで再現できる小さな場面まで課題を絞り、それから AI に案を出してもらう。その方が方向の違いを比べやすく、きれいな文章を動く成果物と見誤ることも減る。

本当に残したいのは Prompt そのものではなく、ほかの人が読み直して検証できる課題の記述だ。

Prompt の前に概念図

長い対話の中では、古い案と新しい決定が混ざりやすい。今採用していること、あえてやらないこと、まだ足りない検証を短い一覧にし、次の作業が同じ境界から始められるようにする。

このサイトの制作でも、AGENTS.md、DESIGN.md、content、messages、テストがそれぞれ異なる役割を担っている。これらを Agent に渡すのは、情報をすべて Context に流し込むためではなく、どこがルールで、どこが中身で、どこが検証かを伝えるためだ。

Context を整理する目的は推測を減らすことであり、誰も最後まで読まない仕様書を作ることではない。

見直せる作業メモ概念図

まずは最小で完結する一片から作る。入口が一つ、主動作が一つ、結果を確認できる場所が一つ。少量のデータで骨組みを確かめてから、長い文章、エラー状態、実機の画面幅を戻していく。

この段階で、筋が通って見えた Prompt が覆ることも多い。ボタンが押しにくい、見出しが不自然に折れる、情報の順序が違う――それは AI の文章ではなく、プロダクト自身が疑問に答えている瞬間だ。

だから最初のデモを成果物とはみなさず、次の問いを考えるための具体的な材料として扱う。

文字から画面へ概念図

BRIEF

課題と制約を言葉にする

SLICE

一続きの流れだけを作る

SCREEN

実際に動かして確かめる

AI は画面をカード、ボタン、section に分けるのは得意だ。難しいのは、いつ方向を示し、いつ細部を渡し、いつ判断を休ませるかというリズムを決めること。

KENLIN.CC では Work、Journal、Photography を入口として分け、それぞれの読む速さを残した。KIROKU では Discord の一言を整理、検索、振り返りへ戻す。

良い構成は、自分が部品でできていることを説明し続けない。次の動作が自然にわかる。

検証を層に分ける。Typecheck は型、Test は動作、Browser は実際の操作、Screenshot は読む感覚を見る。それぞれ違う問いに答えるので、一つで全てを代用しない。

三言語のサイトなら、日本語、繁体字、英語でも章の責任と証拠が同じように残っているかを見る。文字が翻訳されただけでは足りない。

そうすれば、どこを戻して直すかが分かり、曖昧な「たぶん大丈夫」で終わらない。

四層の受け入れ確認概念図

手順	TYPECHECK	TEST	BROWSER	PIXEL
データの形状が正しい	含む	含まない	含まない	含まない
振る舞いが契約通りである	含まない	含む	含まない	含まない
実際に操作できる	含まない	含まない	含む	含まない
読んでいて自然である	含まない	含まない	含まない	含む

すべての Prompt を一度で成功させたいわけではない。大切なのは、失敗したときにどの前提が違ったかを言えること、次にもっと正確に頼めること、そして結果が自分の仕事へ戻ること。

翻訳、Coding、このサイトの制作。AI は考える相手、実装する手、Review の別の目になった。位置が違えば、確認の仕方も違う。

完成は AI が言うものではない。自分が日常で使い続けられると決めたときに初めて残る。

先に、何を作るかを言葉にする。