なぜ「全部盛りプロンプト」がつらかったのか

以前はこんな考え方でした。

自身が出力して欲しい条件や注意点、仕様を全部書けば事故らないはず。

実際には、こんなことが起きがちでした。

正しそうだが、手を動かすと詰まる
理屈は合っている
網羅的で綺麗
でも
- 「で、最初に何をすればいい？」
- 「どこを直せばいい？」
  が分からない。

レビュー資料としては正しいけれど、作業メモとしては使いにくい状態です。
人間の会議でも、「最初に注意事項を20個読む会議」はだいたい進まないですよね。

試したこと：プロンプトを「参照付き設計メモ」に分ける

やったことはシンプルです。
プロンプトを次の3つに分けました。

1. 目的（What）

何をしたいのか。1〜2行。

2. 制約（Must / Must not）

守る条件を列挙。
優先順位を明示します。

3. 評価観点

出力をどうレビューするか。
ダメならどこを修正するか。

それぞれに番号を振り、参照関係が分かるように書くだけです。

書き方の例（イメージ）

[1] 目的
- PowerQueryの学習用に、実務寄りの例題を3問作る

[2] 制約（優先順）
- [2-1] 一次情報が無い断言は禁止
- [2-2] 抽象論だけで終わらせない
- [2-3] 実務で起きそうな前提を含める

[3] 評価観点
- [1]を満たしているか
- [2]の違反がないか
- 手を動かすイメージが湧くか

特別なツールは不要。テキストの書き方を変えただけです。

ミニ実験：同一タスクでの差分（短縮版）

タスク

PowerQueryの学習用に例題を作ってほしい

A. いつもの箇条書きプロンプト（抜粋）

PowerQueryの例題を3問
初学者向け
実務に使える内容で

体感

一般論が多い
「で、何をやればいい？」状態

B. 分解＋参照版（抜粋）

[1] 目的
- 実務でよくあるPowerQuery作業を体験できる例題を作る

[2] 制約（優先順）
- [2-1] 実在しそうな業務データを想定する
- [2-2] 手順が追える形で書く

[3] 評価
- [1]を満たすか
- 手順が省略されていないか

体感

例題が具体的
「この順で触ればいい」が見える
修正点も指摘しやすい
※あくまで体感です。LLM内部の挙動を説明するものではありません

なぜ分割した方が効いた「気がする」のか（仮説）

LLMが賢くなったというより 人間側の切り分けが明確になった
制約の優先順位を明示したことで レビュー軸が固定された
出力の良し悪しを 「感覚」ではなく「観点」で見られる

つまり、LLMの問題というより設計メモの書き方の問題だった可能性があります。

まとめ

プロンプトを 目的／制約／評価観点に分ける
制約には優先順位をつける
番号で参照関係を明示する
理論より、まず並べて比べる
「全部盛りでうまく行かない」と感じている人には、 一度試す価値はあるのではないでしょうか。

次は、

「作る工程と見直す工程を分ける」
「まず作って、あとから落ち着いて確認する」
あたりを整理して書く予定です。