ChatGPTやClaudeに仕事を手伝ってもらうとき、プロンプトの型を調べて、条件も細かく書いた。なのに、仕上がりが「それっぽい」ところで止まってしまう。そんな経験はないでしょうか。
僕自身は、AIで資料や文章をそれなりに作れるようになってきました。振り返ると、それはプロンプトを長くしたからではありません。「何を優先して、何を捨てるか」をAIに渡すようになったからだと思っています。
この記事では、その「判断基準」とは何か、どう書けばAIに伝わるのかを、実際の例を使って説明します。ChatGPTでもClaudeでも、考え方は同じです。
条件を足しても、仕上がりが「平均点」から動かない
AIの出力に物足りなさを感じると、多くの人は条件を足します。「300文字で」「丁寧な口調で」「箇条書きで」「専門用語は使わずに」。条件が増えるほど、プロンプトは長くなっていきます。

条件を足すと、守ることは増える。でも「どれを優先するか」は決まらない
条件を足すと、AIが守ることは確かに増えます。文字数も口調も、ある程度そろってきます。
ただ、条件同士がぶつかったときにどちらを取るかは、条件をいくら並べても決まりません。たとえば「分かりやすく」と「300文字以内」は、内容によっては両立しません。説明を削れば短くなりますが、そのぶん分かりにくくなる。どちらを優先するかは、頼んだ人の頭の中にしかありません。

迷ったとき、AIは無難な答えを選びやすい
優先順位が分からないとき、AIはどの条件もそこそこ満たす、角の立たない答えを出しがちです。間違ってはいないけれど、誰に向けたものなのかが見えない。「それっぽい」の正体は、多くの場合これです。
人に仕事を頼むときも同じですよね。「いい感じにまとめておいて」とだけ頼まれた新人さんは、無難にまとめるしかありません。
足りないのは「指示」ではなく「判断基準」
指示と判断基準は何が違う?
この記事では、2つを次のように分けて考えます。
| 指示 | 判断基準 | |
|---|---|---|
| 伝えること | やってほしいこと | 迷ったときの決め方と、その理由 |
| 例 | 分かりやすく書いて | 読むのは専門用語が通じない経営者。判断してもらうための文書なので、本人が答えられる形にして |
| AIにできること | 言われたことを守る | 書いていない場面でも、同じ考え方で判断する |
指示は「何をするか」。判断基準は「なぜそうするのか」「迷ったらどちらを取るのか」です。判断基準を渡しておくと、プロンプトに書いていない場面でも、AIが同じ方向で考えやすくなります。
公式のガイドにも「理由を伝える」と書かれている
これは僕の感覚だけの話ではありません。Claudeを開発しているAnthropicの公式ガイドにも、近いことが書かれています。
ガイドでは、Claudeを「優秀だけれど、あなたの職場のやり方をまだ知らない新人」のように考えて、してほしいことを具体的に伝えるようにすすめています。さらに、指示の背景や「なぜそれが大事なのか」を伝えると、目的に合った答えが返ってきやすくなる、とも説明されています。
出典:Prompting best practices(Anthropic公式・英語)
新人に仕事を頼む場面で考えると、分かりやすいと思います。手順だけを渡された新人より、「このお客さんは納期をいちばん気にしているから、連絡は早めに」と理由まで聞いた新人のほうが、想定外のことが起きてもうまく動けます。
実例:判断基準を渡すと、何が変わったか
文章:内容は正しいのに、伝わらなかった設計書
自社で企画しているWEBサービスの設計書を、Claudeに作ってもらったときの話です。
できあがった設計書は、技術的には正しい内容でした。その中には、僕が判断しなければいけない質問が5つありました。ところが読んでみると、5つのうち3つは、何を聞かれているのかがよく分かりませんでした。「MVP」をはじめとした開発の専門用語が、説明なしで使われていたからです。
「もっと分かりやすく書いて」と頼み直すこともできました。でもそれだと、次に別の文書を作ったとき、また同じことが起きます。そこで伝えたのは、要約するとこういうことです。
読むのはデザイナー兼経営者で、エンジニアではない。
開発の専門用語は通じない。
この文書の目的は、本人に判断してもらうこと。
だから、判断をお願いする質問は、本人が答えられる言葉にする。
これで、設計書の書き方が変わりました。冒頭に用語集が付き、章の頭には「ひとことで言うと」という短い要約が入りました。開発のときにしか使わない細かい仕様は、「読み飛ばしてOK」と分けて書かれるようになりました。
質問の聞き方も変わりました。「この章のデータベース設計でよいか」のような聞き方ではなく、「イベントの数は全国でも数万件まで、という見込みで合っているか」のように、僕が答えられる形になっています。
一つひとつは小さな工夫です。ただ、どれも「読むのは専門用語が通じない人で、判断してもらうための文書」という前提から出てきたものです。

「分かりやすく」は、読む人によって意味が変わります。
「誰にとって分かりやすいのか」まで渡すと、AIの迷いが減ります。
資料:「何を大きく見せるか」をルールにする
資料づくりでも同じです。KAKERUデザインでは、普段デザインで使っている判断を、Claudeが読める形のルールにまとめています。1ページで伝えることは1つにする、数字は大きく見せる、比べるものは左右に並べる、流れは図にする、といった判断です。

「きれいな資料を作って」と頼むだけでは、この判断は伝わりません。企画書を例にした詳しい話は、こちらの記事に書いています。
→ AIで作った企画書がダサくなる5つの理由|デザイナーが見る改善ポイント
→ Claudeで企画書を作る方法|構成からデザインまで実例で解説
記事:このシリーズも、ルールを渡して作っている
このKAKERU Designingの記事も、書き方のルールをClaudeに渡し、キャッチボールを続けながら作っています。どの経験を書くか、どこまで言い切るかは、そのやり取りの中で僕が決めています。
ルールには、「専門用語を使ったらすぐに説明する」「大げさな言葉を安易に使わない」「筆者が話していない体験や数字は書かない」といった項目が入っています。どれも「こう書いて」という指示というより、読む人にとってどういう記事であるべきかを言葉にしたものです。
判断基準は4つに分けると書きやすい
判断基準と言われても、何を書けばいいのか迷うと思います。書き出すときは、次の4つに分けると整理しやすくなります。
① 誰のためのものか(読む人・使う人は誰か)
② いちばん大事なこと(条件がぶつかったら何を取るか)
③ やらないこと(と、その理由)
④ OKの例とNGの例(言葉にしにくい「らしさ」を伝える)
① 誰のためのものか
読む人や使う人を、できるだけ具体的に書きます。「社内向け」だけでは足りません。「パソコンに詳しくない社員が、朝礼前にスマホで流し読みする」くらいまで書くと、AIが言葉の選び方や長さを判断しやすくなります。
② いちばん大事なこと
条件がぶつかったとき、どちらを取るかを先に決めておきます。たとえば「短さより、読み違えがないことを優先する」。これが1行あるだけで、先ほどの「分かりやすく」と「300文字以内」のような迷いがなくなります。
③ やらないこと(と、その理由)
禁止することには、理由を添えます。「専門用語は使わない」だけより、「読む人は専門用語が分からず、そこで読むのをやめてしまう。だから使うときは言い換える」と書くほうが伝わります。
理由が分かっていると、リストに書いていない言葉が出てきたときも、AIが同じ考え方で判断しやすくなります。
④ OKの例とNGの例
「うちの会社らしい言い回し」のように、言葉で説明しにくいものは例で見せます。先ほどのAnthropicのガイドでも、例を見せることは、出力の形式や口調をそろえるための確実な方法の一つとして紹介されています。
記入例:社内のお知らせ文を作ってもらう場合
4つを実際に書くと、たとえばこうなります。
【誰のためのものか】
全社員向け。パソコンに詳しくない人も多く、朝礼前にスマホで流し読みする。
【いちばん大事なこと】
「何を・いつまでに・どうするか」を読み違えないこと。
丁寧さより、分かりやすさを優先する。
【やらないこと】
・前置きのあいさつを長くしない(最初の数行で用件が分からないと、読まれないため)
・「適宜」「など」のような、あいまいな言葉を使わない(人によって受け取り方が変わるため)
【OKの例】
9月30日(火)までに、勤怠アプリの更新をお願いします。所要時間は3分ほどです。
【NGの例】
平素よりご協力いただきありがとうございます。さて、このたび勤怠アプリにつきまして……
この4つをプロンプトの最初に置き、その下に「今回お願いしたいこと」を書きます。条件をただ並べるより、目的に沿った文章が返ってきやすくなります。
最初から完璧に書かなくていい|判断基準は、直した回数だけ育つ
引っかかったところを、理由つきで1行ずつ足す
判断基準を、最初から全部書き出せる人はいません。僕がClaudeに渡しているルールも、はじめから今の形だったわけではありません。
AIの出力を見て「ここが違う」と感じたら、その場で直して終わりにせず、なぜ違うのかを1行足しておきます。先ほどの設計書の話も、つまずいたあとに「読むのは専門用語が通じない人」という前提を足したものです。それからは、設計書や提案をまとめてもらうときも、最初からこの前提で書かれるようになりました。


うまくいかなかった回ほど、判断基準を足すチャンスです。
直した理由を残しておくと、同じつまずきを繰り返さなくなります。
毎回貼るのが面倒になったら、保存しておく
判断基準が育ってくると、毎回プロンプトに貼るのが面倒になってきます。そうなったら、AIのサービス側に保存しておける機能を使うのがおすすめです。2026年9月時点では、次のような機能があります。
| サービス | 機能 | 向いている使い方 |
|---|---|---|
| ChatGPT | カスタム指示 | すべての会話に共通する前提(自分の立場、口調の好みなど) |
| ChatGPT | プロジェクト | 案件や用途ごとの判断基準。参考資料もまとめて置ける |
| Claude | プロジェクト | 案件や用途ごとの判断基準。参考資料もまとめて置ける |
| Claude | Skill(スキル) | 決まった作業の手順や判断基準をまとめたもの。必要なときにClaudeが読み込む |
使えるプランや細かい仕様は変わることがあります。使う前に、公式のヘルプで最新の情報を確認してください。
参考:ChatGPT カスタム指示/ChatGPT プロジェクト/Claude プロジェクト/Claude Skill(いずれも英語)
KAKERUデザインでは、資料づくりの判断基準をClaudeのSkillにまとめて使っています。そのときの話は、Claudeで企画書を作ったら、ここまでできたに書きました。
AIに任せていいこと、人が決めること
ここまで読むと、「判断基準さえ渡せば、あとはAIに任せられる」と感じるかもしれません。でも、そうではありません。
AIに任せやすいこと
案をたくさん出す。文章や資料の形を整える。決めたルールを守りながら、同じ品質で何度も繰り返す。こうした作業は、判断基準があるとAIがかなり頼りになります。
人が決めること
誰に向けて作るのか。何を捨てるのか。できあがったものを、これで出していいのか。ここは人が決めるところです。
見方を変えると、判断基準を書くこと自体が、「人が決める部分」を先に言葉にしておく作業だとも言えます。
判断基準を渡しても、もっともらしい間違い(ハルシネーション)は防げない
もう一つ、正直に書いておきたいことがあります。AIは、事実と違うことを、もっともらしく書いてしまうことがあります。これを「ハルシネーション」と呼びます。

正直、AIを使っていて怖いのは、ハルシネーションに気づかないときがあることです。
判断基準で減らすことはできます。KAKERU Designingのルールにも、「確認できないことは『確認できない』と書く」「推測と事実を混ぜない」という項目を入れています。
Anthropicの公式ガイドでも、分からないときは「分からない」と答えていい、とAIにはっきり伝えることが、間違いを減らす方法の一つとして紹介されています。ただし同じガイドには、こうした工夫をしてもハルシネーションは完全にはなくならないので、大事な情報は必ず確認するように、とも書かれています。
出典:Reduce hallucinations(Anthropic公式・英語)
だからこそ、人が必ず確かめる場所を決めておきます。
数字(金額・日付・割合・件数)
固有名詞(会社名・商品名・人名・地名)
変わりやすい情報(サービスの仕様・料金・法律や制度)
出典を示している部分(「〇〇によると」「調査では」など)
AIを「間違えない道具」として使うのではなく、「ときどき間違えるけれど、仕事の早い相棒」として付き合う。そう考えておくほうが、安心して任せられる範囲はむしろ広がると思います。
まとめ|長いプロンプトより、「迷ったときの決め方」を渡す
AIの仕上がりが「それっぽい」ところで止まるとき、足りないのは多くの場合、条件の数ではありません。迷ったときにどちらを取るか、という判断基準です。
誰のためのものか。いちばん大事なこと。やらないことと、その理由。OKの例とNGの例。この4つを書き出し、AIの出力で引っかかるたびに1行ずつ足していく。それだけでも、AIとのやり取りは変わってくると思います。
そして、事実の確認と「これで出していいか」の判断は、人の仕事として残しておく。AIに任せることと人が決めることを分けておくのが、AIと長く付き合うコツだと考えています。
まずは、いつもAIに頼んでいる仕事を1つ選んで、「誰のためのものか」を1行書き足すところから試してみてください。
※このカードのリンクはアフィリエイトリンクです。リンクから購入されると、KAKERUデザインに紹介料が入ります。






















プロンプトの型を覚えるのが悪いわけではないんです。
ただ、型だけだと「平均点の答え」から先に進みにくいんですよね。