評価軸 1 - 目的の明確さ – してほしいことを、はっきりと伝える
LLMはエスパーではありません。「目的」こそがすべての土台です。ここを間違えると、どんなに美しい形式を指定しても無駄になってしまいます。
AIはテキスト内のパターンを認識して動作します。プロンプトが曖昧だと、モデルは「最も一般的で平均的な意味合い」を勝手に予測して回答を構築しますが、それは往々にしてユーザーが本当に求めているものとは異なります。明確なゴールを示すことで、AIが進むべき正しい方向を定められます。タスクが具体的であればあるほどモデルの「推測」を減らすことができ、より正確でブレのない回答が安定して得られるようになります。
特に重要な場面
- AIに特定の記事、プログラミングコード、データ分析、要約などの具体的なアウトプットを作成させる場合には、目的の明確さが特に重要になります。また、1つの言葉が複数の意味を持つ場合(例: 「ルビー」が宝石なのかプログラミング言語のRubyなのか)や、事前に期待しているクオリティと結果を照らし合わせて採点・評価したい場合にも必須です。プロンプトが曖昧だと、返ってきた回答が良いものなのか悪いものなのか、客観的に判断することすら難しくなるためです。
緩めても問題ない場面
- 自由なアイデア出し(ブレインストーミング)の段階では、厳密なプロンプトは必ずしも必要ありません。むしろ、意図的に多くの異なる視点や方向性を探ることが目的だからです。また、AIとチャット形式で雑談しながら、複数回のラリーを通じて自然に回答を洗練させていく場合も、最初から目的を絞りすぎる必要はありません。
悪い例
マーケティングについて教えて。
- 「マーケティングについて教えて」は非常に曖昧なプロンプトです。「マーケティング」というテーマは広大すぎるため、どのような回答を求めているのかが一切分かりません。AIは、初心者のための基本概念の解説なのか、SNSの集客テクニックなのか、それともマーケティングの歴史なのか、あなたが求めている内容を不必要に推測しなければならなくなります。
良い例
「初めて起業する人に向けて、ブランドマーケティングとパフォーマンスマーケティングの違い、およびそれぞれの使い分けのタイミングを解説したA4用紙1ページ分のガイドを作成してください」
- 動詞(「作成してください」) + 具体的な成果物(「A4用紙1ページ分のガイド」)。
- テーマがシャープ:ブランド対パフォーマンスの「使い分け(意思決定)」に焦点を絞っています。
- 読み手がその成果物の質をすぐに客観評価できるクリアな条件が含まれています。
よくある落とし穴: 1つのプロンプトに複数の異なる目的を詰め込むこと(例: 「要約し、翻訳し、それを詩の形式に書き換えて」)。複数のタスクは同時に要求せず、1つずつステップを分けるかプロンプトを分割しましょう。さもないと、AIはすべての指示を中途半端にしかこなせなくなります。
評価軸 2 - 文脈 – 「誰が」「なぜ」「どこで」使うかを教える
「文脈」こそが、ネットに転がっているようなありきたりな回答と、あなたの状況に本当に役立つ回答を分ける境界線です。
AIはデフォルトで「インターネット上の平均的な読者」に向けて文章を書こうとします。誰に向けた回答なのか、なぜそれを必要としているのかを伝えなければ、回答は当たり障りのない機械的なトーンになってしまいます。適切な文脈(コンテキスト)を加えることで、AIはターゲットに響くトーン、適切な用語選択、適切な詳細度へとアウトプットを自動的にチューニングしてくれます。
特に重要な場面
- 回答が特定の聞き手(役員、エンジニア、子ども、各分野の専門家など)に紐づいている場合には、文脈の設計が不可欠です。また、特殊な業界用語や専門知識、業界規格が重要なウェイトを占める分野や、AIの出力結果を後から別の大きな業務フローやシステムに組み込むため、あらかじめ決まった前提要件を守らなければならない場面でも重要になります。
緩めても問題ない場面
- 単純な事実確認(「地球から月までの距離は?」など)、一般的な定義、あるいはごく基礎的なテキスト変換(誤字脱字の修正など)では、文脈はほぼ不要です。タスクそのものの意味が、追加情報なしでも1つに特定できるからです。
悪い例
データベースについて説明して。
- 「データベースについて説明して」が不十分なのは、誰がその説明を読み、どのような目的で使うのかがAIに伝っていないためです。読み手が子どもなのか、プログラミング初心者なのか、熟練のシステム管理者なのかによって、適した説明内容は180度変わります。AIは知識レベルや用途を推測できないため、教科書的な退屈な解説を出力し、結果として実務には使えない回答になりがちです。
良い例
初めてシンプルなCRUDアプリを作ったばかりのジュニアバックエンドエンジニアに向けて、リレーショナルデータベースとドキュメント型データベースの違いを説明してください。今回は、マルチテナント対応のSaaS開発におけるデータストアの選定という文脈で、彼らが開発開始から「最初の6ヶ月以内」に直面するであろう、具体的なメリット・デメリットに焦点を当てて説明してください。
- ターゲット層と、その現在のアウトプットレベル(スキル感)が特定されています。
- 明記された目的(SaaSの選定)により、回答の深さと方向性がしっかりと固定されています。
- 「最初の6ヶ月以内」という明確な時間軸の指定により、AIが何を優先して解説すべきかが判断しやすくなっています。
よくある落とし穴: 関係のない自分自身のプロフィールや長々とした前提話をダラダラと書き連ねること。文脈は回答を「鋭く研ぎ澄ます」ためのものであり、プロンプトの文字数を無駄に増やすためのものではありません。それを削除しても回答結果が変わらないような不要な一文は、すべてカットしましょう。
評価軸 4 - 制約条件 – 回答の周りに「柵」を立ててはみ出さないようにする
制約条件は、AIに「してほしくないこと」を明記するテクニックです。これは時に、「してほしいこと」を伝えるよりも強力に回答の質をコントロールできます。
明確な境界線やルールが与えられないと、AIは「無難で、一般的な、長ったらしい、言い訳がましい表現」をデフォルトとして選択しがちです。文字数や単語数の上限、特定のトピックの排除、禁止ワード、文章スタイルのルール(制約条件)をあらかじめ敷いておくことで、後から人間が手作業で編集し直す手間が一切いらない、実用的なアウトプットを直接手に入れることができます。
特に重要な場面
- 文字数制限、最大単語数、あるいはプログラム開発で「特定のライブラリやツールしか使えない」といった物理的な限界がある場合には、制約条件が生命線になります。また、AIにありがちな過剰な前置き(「AIとしてお答えします…」など)や、不要な謝罪、過度な絵文字の多用、余計なMarkdown装飾などを防ぎたい場合にも制約条件が非常に役立ちます。
緩めても問題ない場面
- アイデア出しの初期段階(ブレインストーミング)では、あまり多くの制約を課さないほうが良いでしょう。制約は思考の枠を狭めるため、まずは自由に選択肢を広げ、後から条件を絞っていくほうが面白いアイデアにたどり着きやすくなります。また、常識的に考えて当たり前のルールをわざわざ言葉で書く必要はありません。
悪い例
アプリのLP用の、魅力的なキャッチコピーを書いて。
- 「魅力的な」というのは制約条件ではなく、単なるユーザーの希望(願望)です。長さの限界も、想定読者も、禁止ワードの指定もありません。結果として、AIにありがちな「AIの力であなたの業務プロセスに革命を!…」のような、ありきたりで退屈なコピーが出力され、使えずにがっかりすることになります。
良い例
開発者向けのシステム監視(オブザーバビリティ)ツールのLP用キャッチコピーを5パターン作成してください。制約ルール:「最大8単語(英語の場合は8単語)以内」「マーケティングの誇大表現(革命、シナジー、解き放つ、最大化など)は使用禁止」「疑問文は使わない」「開発者にとっての具体的なメリット(開発効率の向上、エラー検知の高速化、アラート数の削減など)を必ず1つ含めること」「末尾に『!』を使用しないこと」。
- 生成数(5個)、長さ(8単語以内)、および明確な「NGワードリスト(禁止表現)」が用意されています。
- 「メリットを含める」というプラスの制約と、「!を使わない」というマイナスの制約がバランスよく設計されています。
- AIが陥りがちな典型的な失敗パターンを、プロンプトの段階で先回りして封じ込めています。
よくある落とし穴: 制約を大量に盛り込みすぎて、条件同士が矛盾してしまうこと。すべての指示を同時に成立させることが不可能なプロンプトを受け取ると、AIは「どのルールを無視するか」を勝手に決めて実行してしまいます。制約はシンプルかつ現実的な範囲に留め、重要度の高い順に並べて記述しましょう。
評価軸 5 - 具体例 – 言葉で長々と説明する代わりに、「実物」を見せる
「プロ風に書いて」「クリエイティブに」「自然に」といった抽象的な形容詞を100文字重ねるよりも、理想的な「実例」を1つ見せるほうがはるかに効果的です。AIは例からパターンを驚くべき速さで学習し、忠実に再現します。
この手法は「Few-Shotプロンプティング」と呼ばれます。例は、難しいスタイル、変換、スキーマ、境界ケースに役立ちますが、代表性が必要です。指示だけで結果が明確な場合には不要です。
特に重要な場面
- 口調(トーン)や独自の文章スタイルなど、言葉では説明しにくいものの「見れば一発で分かる」ようなニュアンスをAIに真似させたい場合に、具体例は最大の効力を発揮します。また、複雑な形式変換タスクや、イレギュラーな入力データ(欠損値やエラーなど)が含まれる場合にAIをパニックに陥らせず、冷静にエラー処理させたい場面でも非常に有効です。
緩めても問題ない場面
- 1回限りのごくシンプルな作業(「この文章を英語にして」など)で、わざわざ手本を作る手間のほうが、出力された結果を後から手作業で修正する手間よりも大きくなってしまう場合には、例を用意する必要はありません。指示がシンプルで、解釈の余地が1つしかない場合も同様です。
悪い例
私の商品の説明文を、もっと高級感のある雰囲気書き換えて。
- 「高級感」という定義は人によってバラバラです。Appleにとっての高級感と、高級時計ブランド、あるいは高級ステーキハウスにとってのそれは全く異なります。Before(書き換え前)とAfter(書き換え後)のお手本が1つもないため、AIは「高級感」の意味を自分勝手に推測してしまい、あなたの望みとはズレた無意味な美辞麗句を並べ立てることになります。
良い例
商品の説明文を、ミニマルで洗練された高級インテリアブランド(いわゆるクワイエット・ラグジュアリー)のようなトーン&マナーに書き換えてください。以下の変換パターンを忠実に真似してください。
Before: 「超柔らかいコットン100%Tシャツ!毎日の普段着に最高に気持ちいい1着です!」
After: 「風をまとうような軽やかなコットンTシャツ。静かで穏やかな午後の時間にふさわしい1着。」
では、上記と同じトーンで、以下の商品説明文を書き換えてください: [書き換えたいリスト]
- Before / Afterの具体的な実例により、どのような変換処理を行えばよいかが完璧に図示されています。
- 「高級感」という抽象的な表現を使わず、実際のお手本の文章を通じて、言葉の選び方や空気感を直接伝えています。
- AIは提示されたBefore / Afterのパターン構造を自動的に抽出し、あなたが送った実務用のリストにそのパターンを正しく適用します。
よくある落とし穴: 書いたルールと例が矛盾していること。モデルはルールより提示されたパターンに従う場合があるため、各例が本当に望む動作を示しているか確認しましょう。