AIに毎回同じような作業を頼んでいるのに、「仕上がりが毎回微妙に違う」と感じたことはありませんか。
先週はいい感じだったのに、今週は形式が崩れている。原因はシンプルで、作業のルールがあなたの頭の中にしかないからです。毎回その場で思い出しながら指示するので、指示自体が毎回微妙に変わり、出力もそれに引きずられてブレる。
今回紹介する Specification Layer(仕様書レイヤー) は、頭の中のルールを「仕様書」という1枚の文書に固定して、毎回の作業の起点にする型です。第4章「コンテキストを環境として設計する」の最終回です。
Specification Layerとは?
Specification Layerは、一言でいうと「作業の品質基準・ルール・形式を仕様書として文書化し、毎回それを起点に作業させる」手法です。
たとえると、飲食チェーンの調理マニュアルです。どの店舗の誰が作っても同じ味になるのは、レシピと手順が文書として固定されているから。属人的な「勘」を文書に置き換えることで、再現性が生まれます。あなたとAIの間にも、この文書を1枚作ります。
これまでの章で紹介した型との関係を整理すると、こうなります。Day 6のテンプレ固定は「出力の形」、Day 17の3層指示は「指示の高度」、Day 19の判断基準は「価値観」。仕様書はこれらを1枚に統合した、いわば「あなた専用の取扱説明書」です。プロンプトを毎回書く人から、仕様書を1枚持っている人へ。この型は特定の研究ではなく、繰り返し作業を安定させるための実務的な設計パターンです。
なぜ効くのか
①指示のブレが構造的になくなる
毎回その場で書く指示は、その日の記憶力と気分に左右されます。仕様書を貼るだけの運用にすれば、指示は毎回一言一句同じ。入力が同じなら、出力のブレは大幅に減ります。
②改善が「上書き」で蓄積される
頭の中のルールは、思いついた改善をすぐ忘れます。仕様書があれば、気づいた改善点をその場で1行追記するだけで、次回から全作業に反映されます。作業するたびに仕様書が賢くなっていく。この蓄積が最大の資産です。
コピペOKプロンプト
まず仕様書をこのテンプレートで作り、メモアプリに保存します。
【○○作業の仕様書 v1】
■目的:この作業で達成したいこと
■出力形式:形・長さ・構成の指定
■品質基準:必ず満たすべき条件(3〜5個)
■禁止事項:やらないでほしいこと
■判断基準:迷ったときの優先順位作業を頼むときは、仕様書を貼ってこう伝えます。
今後この作業は、以下の仕様書を起点として実行してください。
仕様書の範囲外の判断が必要になった場合は、
推測せず必ずわたしに確認してください。
【ここに仕様書を貼る】
今回の依頼:［ ］「範囲外は推測せず確認してください」の一文が安全装置です。仕様書に書いていないケースでAIが勝手に判断して暴走するのを防ぎます。
実践例:before / after
「毎週金曜に書く仕事の週報作成」で試してみました。毎週発生する定番作業の代表格です。
🔴 before:毎回その場で指示した場合
毎週「今週やったことを箇条書きで送るので週報にまとめて」と頼んでいました。ある週は丁寧な長文、ある週は簡素な箇条書き。上司から「先週と形式が違うね」と言われて、毎回微調整する時間が発生していました。「300字くらいで」「成果を先に」と毎回言っているつもりでも、言い忘れる週があったのが原因です。
🟢 after:仕様書を起点にした場合
【週報作成の仕様書 v2】
■目的:上司が1分で今週の状況を把握できる週報
■出力形式:「成果→進行中→来週の予定→相談事項」の4項目。全体300字以内
■品質基準:①数字で言える成果は必ず数字で書く
②進行中の項目には進捗率をつける ③相談事項がなければ「なし」と明記
■禁止事項:「頑張りました」等の感想表現/1文60字超え
■判断基準:迷ったら「上司が読む時間の短さ」を最優先→ 結果:どの週も同じ構成・同じ密度の週報が出てくるようになりました。やることは箇条書きのメモを貼るだけ。3週目に「相談事項は箇条書きではなく1文で」と気づいて仕様書に1行足したところ、それ以降ずっと反映されています。「v2」とバージョンをつけているのは、この育てていく前提の表れです。
使いどころと注意点
✅ こんな場面で使う
- 週次・月次で繰り返す定型作業(週報・議事録・家計まとめ)
- 仕上がりのブレに悩んでいる作業
- 「前回どう頼んだっけ?」と思い出す時間が発生している作業
❌ これには向いていない
- 1回きりの作業(仕様書を作るコストが回収できない)
- 毎回内容が大きく変わる創作系のタスク
注意点として、最初から完璧な仕様書を作ろうとしないでください。v1は5分で書ける粗いもので十分です。運用して不満が出たら1行足す。この繰り返しでv3くらいになった頃には、実用に耐える仕様書に育っています。
🔧 上級者向け:仕様書の作成自体をAIに手伝わせる
ここは応用の話なので、読み飛ばしてOKです。
「仕様書に何を書けばいいかわからない」場合は、過去のやり取りをAIに見せてこう頼みます。
以下は、わたしが過去にこの作業を頼んだときのやり取りです。
わたしが繰り返し指示・修正していた内容を抽出して、
仕様書のテンプレート(目的/出力形式/品質基準/禁止事項/判断基準)
の形にまとめてください。過去の訂正履歴は、あなたのこだわりの記録そのものです。それを仕様書に変換させれば、v1がゼロから書くより速く、正確に仕上がります。Day 5のMeta-Promptingと組み合わせて、仕様書自体を定期的に改良させるのも効果的です。
まとめ
- Specification Layerは「マイ仕様書を毎回の作業の起点にする」型
- 「範囲外は推測せず確認」の一文が安全装置
- v1は5分の粗さでOK。運用しながら1行ずつ育てる
これで第4章「コンテキストを環境として設計する」は完結です。配置(Day 16)、高度(Day 17)、渡し方(Day 18)、判断基準(Day 19)、仕様書(Day 20)。プロンプトの「中身」ではなく「周辺の設計」だけでここまで変わる、というのがこの章のメッセージでした。毎週の定番作業がある方は、まず仕様書v1の5分から始めてみてください。
⚠️ この記事の情報は執筆時点(2026年6月)の内容です。AIツールの仕様・挙動はアップデートで変わることがあります。最終確認は各サービスの公式サイトや一次情報でお願いします。
次回予告
次回から第5章「AI内部の仕組みに合わせる」に入ります。1本目は「Stable Prefix First(固定プレフィックス優先)」。AIの内部で動く「キャッシュ」の仕組みに合わせてプロンプトの置き方を変えると、応答速度や使用枠の減り方まで変わる、という話です。
👉Stable Prefix Firstとは?変わらない前提を冒頭に固定するプロンプト術
コメント