プロンプトの書き方【2026年】毎回書くのをやめてルール化した実録

プロンプトの書き方の基本は、目的と理由を具体的に伝え、例を見せ、望む形を言い切ることです。ただ実務では、毎回うまく書くより、何度も言っていることを1回だけファイルに書き、AIに毎回読ませるほうが効きました。僕の会社が社内ルールをどう書き、どう育て、どこで書きすぎたかを公開します。

プロンプトの書き方の基本は？公式ガイドが共通して勧めること

プロンプトの書き方の基本は、AnthropicとOpenAIの公式ガイドでほぼ共通しています。目的と制約を具体的に書くこと、その指示の理由を添えること、望む出力の例を見せること、指示と資料を区切って構造を分かるようにすること、の4つです。どれも「文脈を知らない新人に仕事を頼むときの書き方」と同じだと考えると覚えやすくなります。

プロンプトとは、AIに作業を頼むときに渡す指示文のことで、依頼内容だけでなく、前提・条件・出力の形までを含みます。AIは会話の外にあるあなたの事情を知らないので、書かれていないことは推測で埋めるしかありません。良いプロンプトは、この推測の余地を減らす文章です。

Anthropicの公式ガイドには、Claudeを「優秀だが、あなたの会社のやり方をまだ知らない新入社員」と考えるよう書かれています。さらに「文脈を知らない同僚にそのプロンプトを見せて、同僚が迷うならClaudeも迷う」という確かめ方が、黄金律として紹介されています。

2026年10月時点で僕が確認した、公式ガイドの主な推奨を表にまとめます。

OpenAIの公式ガイドも、指示文を「役割」「指示」「例」「前提」の順に分けて書く構成を示しています。

理由を1文添えるだけで変わる

この中で僕がいちばん効果を感じているのは「理由を添える」で、社内のルールにも必ず理由を書いています。Anthropicのガイドには、「省略記号（…）を使うな」とだけ書くより、「読み上げソフトで音声にするので、発音できない省略記号は使わないで」と理由を書くほうが効く、という例が載っています。理由が分かれば、AIはルールに書いていない似た場面にも同じ考え方を当てはめます。

公式の推奨は「毎回書く」前提になっている

公式の推奨はどれも効きますが、役割も理由も例も毎回書いていたら、依頼文が依頼の何倍にも膨らみます。そこで僕の会社は、変わらない部分を毎回書くのをやめました。

AIに役割を分けて仕事を任せる方法はAIエージェントの作り方に、2つのAIの使い分けはChatGPTとClaudeの比較にまとめました。

なぜ「毎回うまい指示を書く」のをやめたのか？

毎回うまい指示を書く方式は、書く人の集中力に依存するので続きませんでした。同じ前提を何十回も打ち直し、打ち忘れた日に限ってAIが的外れな成果物を出す。これを繰り返したあと、僕の会社は「何度も言っていることは1回だけファイルに書き、AIに毎回読ませる」方式に切り替えました。

僕の会社はエンジニアのいないマーケティング支援の会社で、広告運用から請求書の下準備まで、実務をAIに任せています。使っているのは主にClaude Codeで、始め方はClaude Codeの使い方（非エンジニアの始め方）にまとめています。

困っていたのは、指示の「中身」より「抜け」でした。記事なら、一人称は「僕」、数字は出典つき、クライアント名は出さない、という前提を毎回言う必要があります。急いでいる日は1つ落ち、落ちた前提はAIには分かりません。うまくいった指示も、会話を閉じると消えてしまいます。

毎回書く方式とファイル方式の違い

この切り替えで、僕の仕事は「指示を書く人」から「ルールを直す人」になりました。出力がおかしければ、ルールに足りなかった1行を足します。次の会話からは、その1行が勝手に効きます。

AIに毎回読ませる「ルールファイル」とは？僕の会社の構成

ルールファイルとは、AIが作業を始める前に毎回自動で読み込む、会社の前提や判断基準を書いたテキストファイルのことです。Claude Codeでは CLAUDE.md という名前のファイルがこの役割を持ちます。僕の会社では、CLAUDE.mdを入口にして、テーマ別のルールと「指摘の記録」を3層で読ませています。

CLAUDE.mdとは、Claude Codeが毎回の会話の開始時に読み込む指示ファイルで、プロジェクトの決まりごとや作業の前提を書いておく場所です。公式ドキュメントによると、置き場所は4種類あります。全プロジェクト共通の ~/.claude/CLAUDE.md、プロジェクトごとの ./CLAUDE.md、自分だけのメモ用の ./CLAUDE.local.md、そして組織のIT部門が配る管理用のファイルです。

公式ドキュメントは、CLAUDE.mdに書き足すタイミングとして「同じ間違いを2回したとき」「前回の会話で打ったのと同じ訂正を、また打っているとき」「新しく入った人にも同じ説明が要るとき」を挙げています。僕の会社がたどり着いた運用も、ほぼこの通りでした。

僕の会社の構成を、2026年10月1日時点のファイル数と行数で表にします。数字は社内のフォルダを wc コマンドで数えたものです。

社内フォルダの CLAUDE.md の冒頭は、実際にはこうなっています（抜粋）。

## 最重要ルール

1. 迷ったら、売上・ブランド・継続性・工数削減の順で判断する
2. 「普通の正解」より「UrakaTAらしい勝ち筋」を優先する
3. 提案には必ず、目的・KPI・工数・担当・次アクションを含める
4. 良い発見・判断・ミス・プロジェクト状態はObsidianへ保存する
5. 佐藤さんの時間を奪わない。選択肢を整理し、意思決定しやすくする

この仕組みを会社の記憶として育てる話は、Claude Codeで会社を「第二の脳」にする経営者向けガイドとObsidianの使い方（Claude Codeに読ませる始め方）に詳しく書いています。

この記事の依頼文そのものも「型」でできている

いま読んでいるこの記事も、同じ仕組みで書いています。記事を書くAIは、毎回「コラムのマスタープロンプト」というファイルを全文読んでから書き始めます。そこには、H1の直下に120〜160字の結論を置く、質問形の見出しの直下に100〜180字の答えを置く、出典のない統計は書かない、といった決まりが並んでいます。

その日の依頼で僕が書くのは、狙うキーワード、記事の角度、使ってよい素材の場所くらいです。文体や構成や禁止事項は、毎回ファイルが補ってくれます。依頼文が短くても品質が揃うのは、前提をファイル側に持たせているからです。

1回の指示とルールファイルはどう使い分ける？

使い分けの基準は「2回以上言ったかどうか」です。その仕事だけの条件、たとえば今回の締切や今回のテーマは、その場の指示に書きます。どの仕事でも同じ前提、たとえば文体、判断の優先順位、やってはいけないことは、ルールファイルに書きます。2回目に同じことを打ち込んだ時点で、ファイルに移す合図です。

迷いやすいものを早見表にしました。僕の会社で実際にどちらに置いているかで分けています。

指摘を受けたらルールを1行足す運用とは？

指摘の運用とは、AIの出力に僕が「違う」と言ったとき、その指摘を会話の中だけで終わらせず、次から効くルールとして書き残すやり方です。1回の言い直しは1回しか効きませんが、ルールに1行足せば以後のすべての会話に効きます。僕の会社では、指摘の記録が39件たまっています。

記録は決まった形で書きます。「何をするか」に加えて「なぜそうするか（Why）」と「どう当てはめるか（How to apply）」を必ず添えます。理由を書いておくと、AIはルールに書かれていない似た場面でも、同じ判断をしやすくなります。

実例1：AIっぽい文面をやめる（2026年9月15日の指摘）

取引先に出すメールの下書きで、AIが「お願いを2つ取り下げます」と宣言し、箇条書きと見出しで整えた文面を出してきました。内容は正しいのですが、読んだ瞬間に人間が書いていないと分かります。このとき記録に足したのは、事務的な宣言、宣言から箇条書きへ流す構成、同じ文末の繰り返しをやめること。理由は、内容が正しくても型がAIだと「この人が書いていない」と伝わり、信頼を作っている途中の相手ほど致命的だからです。当てはめ方として、普通の手紙として一度書き切ってから削り、「自分が口で言うならどう言うか」で読み返す、と書きました。

実例2：やると言ったら同じ返答の中で動く（2026年7月10日の指摘）

AIが「これから確認します」と書いたまま、実際には何も実行せずに止まることが続きました。僕が「どうなってる？」と聞くまで誰も気づきません。この指摘は記録に残しただけでなく、rules/07 という独立したルールファイルになり、CLAUDE.md の最重要ルールにも1行で入りました。

このように全部の仕事に効く指摘は、記録からルールファイルへ、さらに CLAUDE.md の入口へと格上げします。

実例3：調べれば分かることを相手に聞かない（2026年9月15日の指摘）

ある取引先へのメールで、AIが「認証は取得されていますか」と質問しようとしました。ところが、その認証の取得状況は相手の公式サイトに公開されていました。調べれば5分で分かることを聞くと、相手に手間を押し付ける会社に見えます。

記録には「質問を入れる前に、公開情報で埋まらないかを先に確かめる。埋まるなら質問を消し、『調べた結果こうでしたよね』と書く」と残しました。

1行の書き方の型

指摘を記録するときの型は、次の4点です。

書きすぎるとどうなる？強い言葉と長すぎるルールの失敗

書きすぎると、AIはルールを守りすぎたり、ルール同士の矛盾で迷ったりします。僕の会社でも、旧モデル向けに強い言葉で書いたルールが残り、長くなった前提が読み込みのたびに費用を食っていました。2026年9月3日に全ルールを棚卸しし、語調を平常に戻し、重複と矛盾を削りました。

強い言葉の扱いは、公式ガイドにもはっきり書かれています。Anthropicのガイドは、Claude Opus 4.5と4.6を例に、新しい世代のモデルはシステムプロンプトへの反応が以前より敏感で、旧モデル向けに強めに書いた指示では動きすぎることがあると説明しています。対処として、「CRITICAL: You MUST use this tool when...」を「Use this tool when...」のような普通の書き方に戻すよう勧めています。同じガイドには、手書きの段取りを並べるより「よく考えて」のような一般的な指示のほうが良い結果になりやすい、という記述もあります。

OpenAIのGPT-5向けガイドにも、同じ方向の注意があります。矛盾や曖昧さを含む指示は、指示に忠実なモデルほど悪影響が大きく、矛盾を解消する方法を探すのに推論を使ってしまう、という説明です。ある開発ツール会社の事例として、徹底的に調べるよう強く促した指示が、小さな作業でも検索を繰り返させる原因になり、語調を和らげて解決したことも紹介されています。

失敗1：「絶対」「禁止」を重ねた実行ルール

先ほどの rules/07 は、最初はかなり強い言葉で書いていました。2026年7月の初版の見出しは「絶対原則」で、本文には「禁止」が2回出てきます。さらに、毎回の返答で4項目のセルフチェックをさせていました。

## 絶対原則
1. テキストだけで止まらない。
   ……宣言だけして終わるのは禁止。
## 再発時のセルフチェック（毎回）
- [ ] やると言ったことを、このターン内で実際にツールで着手したか
  ……（計4項目）

棚卸しでは、5つの原則の中身は残し、語調だけを平常に戻しました。毎回のセルフチェックは、原則の5番目に1行で畳んでいます。早期に止まる問題は今のモデルでも起きるので、ルール自体は削っていません。削ったのは「圧」の部分です。

1. 「やる」と言ったら同じ応答内で着手する。
2. 空振り・失敗は自分で即やり直す。
3. 完了は検証してから言う。
4. バックグラウンド処理は自分で追う。
5. 応答を返す前に最終段落を見る。

失敗2：手順の振り付けと、ルール同士の矛盾

同じ棚卸しで、外部から導入したデザイン用の指示ファイル（87.6KB）も見直しました。中身を調べると、同じ禁止事項が最大5か所に繰り返し書かれ、互いに矛盾する指示が2組ありました。1組は「47.2%のような生っぽい数字を使え」と「作り込んだ精度の数字はAI臭いので禁止」です。

矛盾したルールを渡されると、AIは聞き返さず、黙ってどちらかに倒します。重複を1か所にまとめ、矛盾を解消し、一般知識の説明を別ファイルへ移した結果、本体は約55KBになりました。

失敗3：長いルールは毎回の読み込みで費用を食う

ルールファイルは「毎回読まれる」のが強みですが、それは毎回の費用でもあります。2026年9月16日に、直近7日間の201セッションの会話ログを集計したところ、僕が1文字も打つ前の時点で、AIはすでに中央値で約9万トークンを読み込んでいました。トークンとは、AIが文章を数える単位で、文字数とおおむね比例します。

この中には、ルールファイルのほか、指摘の記録の索引（当時36KB・約16,500トークン）も入っていました。ルールは足すほど効きますが、足すほど重くなります。

失敗4：誤読から間違った禁止ルールを作った

いちばん反省したのは、指摘を誤読して、間違ったルールを作ってしまった例です。2026年9月30日の深夜、社内で作っているアプリのデモについて、僕が「音出してテストしないで。今夜中だよ？」と送りました。僕の本意は「音を出して確認して。今夜中に仕上げる」でしたが、AIは「深夜だから音を出すな」と読み、音を止めたうえで無音ルールまで作りました。

直したルールには、「指示の読みが割れたら、禁止ルールを作る前に一言確かめる」という1行を足しています。指摘をルールにする運用は強力ですが、誤読したまま書くと、間違いが毎回効く形で残ります。

書きすぎないための見直し基準

CLAUDE.mdの書き方は？今日から始める最小構成

CLAUDE.mdは、短く、具体的に、矛盾なく書くのが基本です。公式ドキュメントは1ファイル200行未満を目標にするよう勧め、長いほど読み込みの負担が増え、守られにくくなると説明しています。最初は「2回以上言ったこと」を5〜10行書くところから始め、指摘を受けるたびに1行ずつ足していけば十分です。

公式が勧める書き方の要点

Claude Codeの公式ドキュメントで確認できた書き方の要点を、僕の会社での当てはめ方と並べます。

フックとは、Claude Codeの作業の決まったタイミングで、指定したスクリプトを自動で実行する仕組みのことです。CLAUDE.mdが「お願い」なら、フックは「仕組み」です。CLAUDE.mdに「日本語で」と書いても英語に戻る問題を、この2つを重ねて止めた実例はClaude Codeが英語で返してくる時の直し方にまとめました。

育て方のコマンド

公式ドキュメントで確認できた、CLAUDE.mdを作って育てるための手段は次の通りです。

• /init：プロジェクトを読んで、CLAUDE.mdのたたき台を自動で作る。既にある場合は上書きせず改善案を出す
• /memory：読み込まれているCLAUDE.mdやメモの一覧を開いて、その場で編集する
• 会話で「これをCLAUDE.mdに追加して」と頼む：そのまま追記してもらえる
• /context：今の会話にどのCLAUDE.mdが読み込まれているかを確かめる
• /doctor prompt-audit：古くなった指示、存在しないファイルへの参照、ファイル同士の矛盾を洗い出す

最小構成のひな形

最初のCLAUDE.mdは、このくらいの分量で十分です。僕の会社の構成を、一般的な会社向けに縮めたものです。

# 会社と役割
- あなたは〇〇株式会社の実務アシスタント。読み手は中小企業の経営者

# 判断の基準
- 迷ったら「売上に近いか」「手間が減るか」の順で判断する

# 書き方
- 結論を先に書く。理由は1〜2文で添える
- 数字は出典を書く。出典がない数字は書かない（信用を失うため）

# やらないこと
- 個人情報と取引先の名前は外に出す文書に書かない（許可を取った場合を除く）

# 指摘の記録
- 指摘を受けたら rules/feedback.md に「ルール・理由・当てはめ方・日付」で1行足す

ポイントは、最後の「指摘の記録」の行です。これがあると、AIが自分でルールを育てる側に回ります。Claude Codeには、訂正された内容を自動でメモに残す仕組みもあり、公式ドキュメントではこの種類のメモを「feedback」と呼んでいます。僕の会社の39件の記録も、この種類のメモとして残しています。

テーマごとの細かい手順は、毎回読むCLAUDE.mdではなく、必要なときだけ読まれる「スキル」に分けると軽くなります。スキルの作り方はClaude Skillsとは？作り方と社内の実例に書きました。最新モデルでの指示の効き方はClaude Fable 5.1の実録にまとめています。

弊社では、こうしたルールファイルの設計から、指摘を記録して育てる運用づくりまで、AI活用の立ち上げを支援しています。詳しくはウラカタのサービス一覧をご覧ください。

まとめ

• プロンプトの書き方の基本は、目的と理由を具体的に伝え、例を示し、望む形を言い切ること
• 2回以上言った前提は、その場の指示ではなくルールファイルに書いてAIに毎回読ませる
• 指摘を受けたら、ルール・理由・当てはめ方・きっかけの4点で1行足す
• 「絶対」「禁止」を重ねた強い言葉や、長く重複したルールは逆効果になる。語調は平常に、入口は短く
• ルールは書いた時点の事実なので、定期的に棚卸しして矛盾と古い記述を消す