1000行のプロンプトを作って分かった。AI活用の本質は「固定と探索」だった
1000行のプロンプトを作って、盛大に破綻した。
あれもこれも例外対応を追加して、最後には私自身、何をさせたいのか分からなくなった。
その時に気づいた。
AI活用の本質は、アジャイルかウォーターフォールかではない。
上級者ほど、
「何を固定するか」と「何を探索するか」
を分離している。
この記事は、その答えに至るまでの記録であり、これから1000行のプロンプトを作る人への注意書きだ。
AIは事前設計だけでは扱えない
まず認めるべきことがある。
生成AIは従来のソフトウェアとは違う。
LLMは確率的なシステムだ。同じ目的を与えても、予想もしなかった解釈や振る舞いを見せることがある。
だから真面目な人ほど、想定ケースを洗い出す 完璧な仕様を書く 例外を先回りして潰すことに時間を使う。
しかし、多くの場合は裏切られる。
本当に必要な仕様は、机上で見つからないからだ。
実際には、動かす 観察する 問題を見つける 制約を追加するというプロセスを通じて初めて、AIはどこで誤解するのかが見える。
この意味で、アジャイル的な実験は不可欠だ。
ここまでは間違いない。
問題は、その次だ。
しかし探索だけでは必ず破綻する
アジャイルが強力なのは事実だ。
だからといって、ずっと試して直し続ければいいわけではない。
対話のたびに場当たり的な修正を重ねると、数か月後にはこうなる。
指示が肥大化する 例外ルールが乱立する 初期の意図が見えなくなる 再現性が失われる。
いわゆる「プロンプトのスパゲッティ化」だ。
私自身、気づけばシステムプロンプトが1000行を超えていた。
指示を1つ追加すると、別の3つの挙動が壊れる。
そして愛着が湧いていて、捨てて書き直せない。
技術的負債そのものだ。
例えば、
丁寧に
でも簡潔に
初心者にも分かるように
でも上級者も唸るように
ユーモアも入れて
でもふざけないで
こんな指示を優秀な部下に渡したら、3日後に退職届が届きそうだ。
AIも同じだ。
どんなモデルでも、矛盾した100ページの仕様書を完璧には処理できない。
本当に重要なのは「固定」と「探索」の分離
AIを使いこなしている人は、アジャイルかウォーターフォールかを選んでいるわけではない。
探索にはアジャイルを使い、運用にはウォーターフォールを使っている。
違うのは手法の選択ではなく、「何を固定し、何を探索対象として残すか」の設計だ。
実態はこうだ。
探索（アジャイル）
↓
知見の抽出
↓
仕様化
↓
運用（ウォーターフォール）
まず探索する。
AIは何を誤解するのか どんな制約が必要か どこが本質なのかを実験によって発見する。
そして十分な知見が集まったら、それを仕様として固定する。
重要なのは、この切り替えだ。
とくに難しいのは「知見の抽出」。
「なんとなくこの言い回しが効く」
という感覚的な発見を、誰が使っても再現できる形に変換する作業だ。
これはプロンプト執筆というより、要件定義に近い。
固定すべきもの（ブレさせない）：
目的（なぜやるか）
権限（何をさせないか）
安全制約（何を禁止するか）
評価基準（何が良い出力か）
探索させるもの（AIに任せる）：
表現方法（どう伝えるか）
実行手順（どう進めるか）
アイデア（何を提案するか）
構成（どう並べるか）
上級者ほど、固定する階層を高く、探索させる階層を低く設計している。
言い換えると、「目的・評価基準」は固定し、「表現・手順」は固定しない。
この境界線の引き方が、そのままAI活用の質になる。
判断に迷ったら、1つだけ問いを持っておくと便利だ。
この要素が変わったら、目的は壊れるか？
壊れるなら固定。
壊れないなら探索。
まずはこの基準で十分だ。
そしてモデルの進化や用途の変化に合わせて、その境界線を引き直してほしい。
昨日まで固定だったものが、明日には探索可能になることもある。
結論
AI活用の本質は、完璧主義を捨てることではない。
アジャイルを信仰することでもない。
不確実なシステムだから、まずは探索が必要になる。
しかし、探索で得た知見をいつまでも対話の中に閉じ込めておけば、やがて複雑性に飲み込まれる。
大事なのは、探索によって固定すべきものを発見し、それを仕様として固定すること。
あなたの今のプロンプトや指示書は、どこまでが「固定」で、どこからが「探索」だろうか。
もし全部が探索になっているなら、そろそろ仕様化するタイミングかもしれない。
