---
title: コツ集を保存してもプロンプトを書き直す夜に、前提3行を先頭に貼る
date: 2026-09-18
description: プロンプトの書き方のコツを保存しても、AIの出力は結局書き直しになる。コツ集が運んでいないのは、誰に出すか・何が禁止か・過去の決着という自社の前提だ。前提3行を固定資産にして依頼文の先頭へ貼るだけの運用に変える設計を渡す。
categories: [AI武装]
tags: [AI活用, 課長の時間術, 認知負債]
source: https://ai.work.naenote.net/posts/prompt-kotsu-zentei-3gyo/
---


「プロンプト 書き方 コツ」で検索して保存したページが、ブックマークフォルダに何十本も並んでいる。役割を与える、出力形式を先に固定する、Few-shotで例を渡す——どれも試した。

それでも今夜も、AIが返してきた資料を結局書き直している。コツは全部正しい。効かないのは、別の場所に穴があるからだ。

{{< mermaid >}}
flowchart TD
    A[コツ集適用] --> B[出力生成]
    B --> C[前提の抜け]
    C --> D[結局書き直す]
{{< /mermaid >}}

## コツを増やしても書き直しが減らない理由

役割を与え、出力形式を指定し、期待する結論の型まで先に渡した。それでもAIが返す文章は、役員向けの資料なのに現場向けの説明口調で書かれていたりする。

社内でとっくに使わなくなった言い回しをそのまま使ってくることもある。数字自体は合っているのに、出してはいけない他部署との比較をあっさり載せてくることさえある。

さらに厄介なのは、半年前に部内で決着した論点を、AIがまた俎上に載せてくることだ。担当者にとっては終わった話でも、AIにとってはこの依頼が初対面にすぎない。指摘するたびに「それはもう議論済みです」と打ち返す一手間が挟まる。

[人間用のフローにAIを差し込んだだけ](/posts/chatgpt-workflow-rakuni-naranai/)という設計のズレは、こういう場所からも起きる。この繰り返される書き直しと説明は、管理職にとっては無給労働として積み重なっていく。[AIに投じた燃料が回収されない](/posts/ai-kacho-daitai-funou-nenryokei/)という落とし穴も、ここで明らかになる。コツ集のどの項目にも、この3つの不具合を防ぐ手順は書かれていない。

## コツ集が運んでいないのは、依頼の外側にある3つの前提

プロンプトのコツ集が教えているのは、依頼1回分の書き方だ。役割・出力形式・例——どれも「今回何を頼むか」の技術で、毎回書き直す部分にしか効かない。

OpenAI公式のプロンプト設計ガイドは、依頼を組み立てる要素を役割・規則・例・文脈に分けたうえで、メッセージの権限をdeveloperとuserの2層で説明している。developerメッセージは開発側が渡すルールで、プログラムでいう関数の定義にあたる。userメッセージはその関数に渡す引数にあたる、とガイドは書く（出典: [OpenAI「Prompt engineering」](https://developers.openai.com/api/docs/guides/prompt-engineering)）。

依頼のたびに書き換わる「今回のタスク」と、書き換わらない「この組織のルール」は、もともと別の層にある。コツ集が鍛えているのはほぼ引数側の技術で、関数定義に相当する部分——誰に出すか・何が禁止か・過去の決着——は、書く場所も決まっていなければ、書くこと自体が習慣になっていない。だから毎回、頭の中から引っ張り出し、しかも省いてしまう。

私も同時に複数の案件を抱えていた時期、案件ごとの背景をAIに毎回説明し直していた。あるとき、文脈をAIに持たせるのをやめ、自分がアクセスできる場所にまとめて置き、依頼のたびにそこから該当分を引いて貼る設計に変えた。前提を「その都度思い出して書くもの」から「引いて貼るもの」に変えただけで、[説明という無給労働](/posts/unpaid-labor-kacho/)がそのまま減った。

同じ抜けを毎回埋め直す手間は、[『認識負債』という借金](/posts/ai-ninshiki-fusai/)の別の顔でもある。依頼文を読み返して、読み手・禁止・決着のどれか1つでも書いていなければ、そこがコツ集で埋まらない穴だ。1回分の依頼の型そのものは[手戻りを断つ依頼の型3つ](/posts/ai-kata-638/)に書いたが、今回の話はその手前——依頼を書く前に固定しておく前提の話になる。

## 前提3行を固定資産にする

前提3行に入れるのは3つだけだ。読み手・禁止・決着。多く見えても、実際に書くのは3行で足りる。

```
【前提】
1. 読み手: （誰が読み、何を決めるための文書か）
2. 禁止: （この組織で使えない言い回し・出せない数字・NG事例）
3. 決着: （すでに合意済みで蒸し返さない論点。決定日と結論を一言で）
```

効くのは**3行目の決着**だ。ここに決定日を添えておくと、その論点がまだ有効かどうかを自分でもすぐ判定できる。読み手と禁止の2行は一度書けば当分変わらない。決着だけが増えていく。

毎回使い回す内容は依頼の先頭に置くと、プロンプトキャッシュが効いてコストとレイテンシの節約になる、とOpenAIのガイドも明記している。前提を後から付け足すのではなく、先頭に固定する設計は、コツの寄せ集めとは違う層の話だ。

## 貼るだけの運用にする

前提3行は、書いた後の置き場所で効き方が決まる。メモアプリでもAIツールのカスタム指示欄でも構わない。依頼を書くたびに、その画面を経由してから本文を打つ。

```
【前提】
1. 読み手: 常務・部長級。数字より結論を先に読む
2. 禁止: 他部署の実名比較、未確定の予算数字
3. 決着: A案の再検討はしない（8/20に部内で決定）

役員会向けに、A案の見送り理由をまとめて
```

貼るだけで完結させる発想自体は、[週次報告のコピペプロンプト](/posts/shuji-hokoku-ai/)と同じだ。作るのは一度、あとは呼び出すだけにする。

決着の日付が古くなっていたら、そこだけ疑う。前提3行を作り直すのではなく、古い1行だけ更新すればいい。作り直す手間がないぶん、更新は続く。

## 前提3行を書く余力がない日の逃げの一手

3行すべてを埋める余力がない日は、禁止の1行だけ先頭に置く。読み手や決着を書き忘れても被害は小さいが、**禁止事項の抵触は後始末が一番重い**。出してはいけない数字や実名がそのまま資料に載れば、直すのは文章ではなく謝罪になる。

それでも危ういと感じたら、前提3行そのものを疑っていい。決着の日付が半年以上前なら、書き直す前にまず本人に「まだこの決定は生きているか」を確認する。AIの出力を鵜呑みにしない一点だけ死守すれば、前提が古びても致命傷にはならない。

## まとめ：コツはレシピ、前提3行は仕込みだ

プロンプトのコツ集はレシピの改良にすぎない。仕込みにあたる前提3行を先頭に固定しないかぎり、レシピをいくら増やしても書き直しの夜は終わらない。

{{< ai-disclaimer >}}


---
### AI Agent Context & Resources
- **Author**: NAE
- **Source**: https://ai.work.naenote.net/posts/prompt-kotsu-zentei-3gyo/
- **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP)
- **Contact/Inquiry**: https://x.com/naework