ChatGPTでもClaudeでもGeminiでも、「思ってたのと全然違う答えが返ってきた」という経験、誰しも一度はあると思います。実はそれ、AIの性能の問題じゃなくて、大抵はプロンプト（指示文）の書き方に原因があります。今回は、初心者がやりがちな「悪いプロンプト」の具体例と、それをどう直せば「良いプロンプト」になるのかを、実際に僕がやらかした失敗も交えながらまとめていきます。
プロンプトって「AIに賢く聞けばうまく返してくれる」みたいな話じゃなくて、ぶっちゃけ「新人に指示を出す作業」に近いんですよね。曖昧な指示を出せば、曖昧な仕事が返ってくる。それだけの話だったりします。
そもそもプロンプトが「悪い」とはどういうことか
結論から言うと、悪いプロンプトのほとんどは「情報が足りない」か「指示が曖昧」かのどちらかです。AI側が忖度して補完してくれることもありますが、その忖度が自分の意図とズレた瞬間に「使えない回答」が返ってきます。
Anthropic（Claudeの開発元）が公開しているプロンプトガイドでは、Claudeのことを「優秀だけど記憶喪失の新人社員」だと思って接するようにと書かれています※1。どんな新人社員に対しても、こちらの前提や好みのやり方を説明しないと正しく動いてもらえないのと同じで、Claudeも規範やスタイルの前提知識を持っていないので、明確な指示が必要だという考え方です。この例えが本当にしっくりきていて、「あれ、よろしく」で通じる相手じゃないんですよね。
OpenAIの公式ドキュメントでも、指示は具体的であればあるほど良いという方針が明記されています※2。望ましいコンテキストや結果、長さ、フォーマット、スタイルなどを、できるだけ具体的・説明的・詳細に書くことが推奨されているんです。要は、どこの国のAI企業も「察してちゃんNG、具体的に喋れ」という結論に至っているわけです。
【悪い例①】主語も目的も曖昧な一行プロンプト
一番やりがちなのがこれです。僕も駆け出しの頃、まさにこの一行だけで会議資料を作らせようとして、見事に的外れな出力をもらったことがあります。
✕ 悪い例
ブログ記事を書いて
◯ 良い例
Web制作フリーランス向けに、「請求書の書き方」をテーマにしたブログ記事を書いてください。読者は開業1年目のフリーランスエンジニアを想定し、専門用語には簡単な補足を入れてください。文字数は2000字程度、見出しはh2・h3構成でお願いします。
「ブログ記事を書いて」だけだと、AIは「誰に向けて」「何文字で」「どんなトーンで」の全部を自分で決めることになります。その”AI任せの部分”が多ければ多いほど、思っていたものとズレる確率が上がるというだけの話です。
Google Cloudの公式ガイドでも同様の指摘があります※3。優れたプロンプトエンジニアになるのにコーディング経験は必要なく、重要なのは最も伝えたい内容や情報を明確に書くことだとされています。特別なスキルというより、「ちゃんと言葉で説明する」というシンプルな話なんですよね。
【悪い例②】指示と情報がごちゃ混ぜになっている
実務でコードレビューを頼むときによくやりがちなミスです。「指示」と「対象データ」を分けずに投げると、AIがどこまでが指示でどこからが処理対象なのか誤読することがあります。
✕ 悪い例
このコードをレビューしてバグを直して console.log(‘test’) function foo(a,b){return a+b} このコメントも消してもいいけど残しといて
◯ 良い例
以下のJavaScriptコードをレビューし、バグがあれば修正してください。デバッグ用のconsole.logは削除してかまいませんが、それ以外のコメントは残してください。
コード：
“`
function foo(a, b) { return a + b }
console.log(‘test’)
“`
OpenAIのベストプラクティスでも「指示とコンテキストは記号で明確に区切るべき」とされています※2。指示をプロンプトの先頭に置き、### や “”” を使って指示とコンテキストを分離することが推奨されているんです。Claudeを使う場合はXMLタグ（<instruction>や<data>のようなタグ）で区切るのも有効で、これはAnthropicの公式ドキュメントでも紹介されているテクニックです。
実際にやらかした話
以前、CMS案件のコード修正をAIに丸投げしようとして、修正指示と既存コードをベタ打ちで一つの文章にまとめて投げたことがあります。結果、AIが「コメント」だと思っていた部分を実行コードとして解釈してしまい、意味不明な差分が返ってきました。指示とコードは分けて書く、ただそれだけのことで無駄なやり取りが3往復くらい減ります。
【悪い例③】「いい感じにして」系の丸投げ
地味にこれが一番厄介です。「いい感じ」の基準は人によって全然違うので、AIからすると「いい感じ」ほど困る指示はありません。
✕ 悪い例
このLPのコピーをもっといい感じにして
◯ 良い例
このLPのキャッチコピーを、「情報量を減らして一目で価値が伝わる」方向に3案作ってください。ターゲットは30代の個人開発者で、権威性より親しみやすさを重視したトーンでお願いします。
Anthropicのガイドでは、この手の曖昧さを避けるための基準として「同僚チェック法」を紹介しています※1。自分のプロンプトを、そのタスクについて前提知識がほとんどない同僚に見せて、指示に従ってもらう。もし相手が混乱するなら、Claudeもおそらく同じように混乱する、という考え方です。これ、地味に効きます。自分のプロンプトを声に出して読んでみると、「いい感じ」がいかに何も説明していないかよく分かります。
【悪い例④】例を見せずに独自フォーマットを期待する
地味にハマりがちなのが「出力フォーマット」の伝え漏れです。頭の中でイメージしている表形式やJSON構造を、文章の説明だけで伝えようとすると、高確率でズレます。
✕ 悪い例
この文章から会社名と人名を抜き出して
◯ 良い例
この文章から会社名と人名を抜き出し、以下の形式で出力してください。
会社名: [社名]
人名: [氏名]
複数ある場合は改行で列挙してください。
OpenAIも公式に「出力フォーマットは例で示すのが一番伝わる」としており※2、望ましい出力フォーマットを例を使って明示することが、効果的なプロンプトの条件として挙げられています。これはfew-shotプロンプティング（少数例を見せる手法）と呼ばれる考え方で、Google DevelopersのMLガイドでも※4、高品質な入出力の例を提供することで、モデルがユーザーの意図をより正確に理解できるようになるとされています。
画像生成AIのプロンプトにも同じ原則が効く
ここまではテキスト生成AIの話でしたが、Midjourneyやnanobanana、Stable Diffusionのような画像生成AIでも構造はまったく同じです。「なんとなくいい感じの猫」より、「被写体・構図・光・スタイル」を要素分解して伝えたほうが圧倒的に狙い通りの絵が出ます。
悪い例
猫のイラストを描いて
↑ 悪い例（要素が少なすぎて毎回結果がブレる）
良い例（日本語プロンプト）
窓辺で日向ぼっこをする白い長毛猫、柔らかい午後の光、水彩画風のタッチ、パステルカラー、背景はぼかし気味、正方形構図
↑ 日本語プロンプト
良い例（英語訳プロンプト・海外サイト用）
A white long-haired cat basking in soft afternoon sunlight by a window, watercolor style, pastel color palette, blurred background, square composition
↑ 英語プロンプト（Midjourneyなど海外サービス向け）
「被写体→状況→光の質→画風→配色→構図」の順で要素を並べるだけで、同じツールでも出力のブレ幅がかなり小さくなります。悪い例のように単語一つだけを投げると、AI側の”解釈の余地”が広すぎて、毎回違う絵が出てきてしまうわけです。
良いプロンプトの型を1つ覚えておく
毎回ゼロから考えるのは面倒なので、僕は実務では大体次の型に当てはめて書いています。役割・目的・条件・出力形式の4点セットです。
役割：あなたは○○の専門家です 目的：○○について、○○してください 条件： ・対象読者は○○ ・文字数は○○程度 ・トーンは○○ 出力形式： ・見出しはh2/h3構成 ・まとめは最後に400字程度で
↑ 汎用プロンプトテンプレート
Google Cloudのガイドでも、プロンプトの構造化について同様の考え方が示されています※3。プロンプトを構造化する際は、まずロールを定義し、コンテキストや入力データを提供したうえで、指示を与えることが推奨されているとのこと。「役割→コンテキスト→指示」の順番、というのは国内外問わずほぼ共通の型になっているようです。
ステップバイステップで考えさせるのも効果的
複雑なタスクの場合、いきなり答えを求めるのではなく、「まず手順を整理してから、それに沿って実行して」と一段階挟むだけで精度が上がることがあります。DataCampの解説記事でも※5、初期のルールベース手法では人間の言語の複雑さや微妙さの扱いに苦戦していたものの、統計的手法やトランスフォーマーモデルの登場によって文脈理解が大きく進化してきたという歴史的経緯が紹介されており、モデル自体が「段階的に考える」ことと相性の良い設計になってきていることが分かります。
参考・引用元
※1 Anthropic公式「Be clear, direct, and detailed」https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/be-clear-and-direct
※2 OpenAI公式「Best practices for prompt engineering with the OpenAI API」https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
※3 Google Cloud「生成AIのプロンプトエンジニアリング」https://developers.google.com/machine-learning/resources/prompt-eng?hl=ja
※4 HackerNoon「An Intro to Prompting and Prompt Engineering」https://hackernoon.com/lang/ja/an-intro-to-prompting-and-prompt-engineering
※5 DataCamp「What is Prompt Engineering? The Future of AI Communication」https://www.datacamp.com/ja/blog/what-is-prompt-engineering-the-future-of-ai-communication
まとめ
AIプロンプトの悪い例に共通しているのは、「主語がない」「指示とデータが混在している」「フォーマットの例がない」「いい感じで丸投げしている」の4パターンでした。逆に言えば、①誰に向けて②何を③どんな条件で④どんな形式で出してほしいか、の4点さえ言語化できれば、それだけでAIからの回答の質は劇的に変わります。テキスト生成でも画像生成でも原則は同じで、「察してもらう」のではなく「言葉で設計する」意識を持つことが、結局いちばんの近道です。今日紹介したテンプレートをコピーして、自分の定型文として育てていくのがおすすめです。
