「プロンプトを工夫しているのに、毎回微妙な回答が返ってくる」
その問題の9割は、プロンプトの書き方ではなく、仕事の定義が曖昧なことにある。
AIへの問い方を変える前に、やっている仕事を正確に言語化できているか——この視点から、プロンプト設計の本質を整理します。
プロンプトを磨いても改善しない理由
「同じ指示を入れているのに、毎回違う回答が返ってくる」という相談は、AIの使用頻度が上がるにつれ増えています。
ChatGPTのバージョンを変えるたびに「なんか前の方が良かった」という感覚もこれに近い。不安定さの原因をモデルに求めたくなりますが、実態は別のところにあることが多いです。
AIは文脈のない仕事を補完しながら回答します。指示が不完全なとき、AIは不足した情報を「それらしく」埋めようとします。そしてその補完は毎回少しずつ変わります。なぜなら、補完の余地が大きいほど、回答の揺れも大きくなるからです。
ここに根本的な問題があります。多くの人が「プロンプトが悪い」と思っていますが、本当の問題は「仕事の定義が曖昧なこと」にあります。
仕事の定義とプロンプトは別物です。「議事録を要約して」はプロンプトです。一方、「営業会議の議事録から、顧客への次のアクションと担当者・期限だけを箇条書き3点以内で抜き出す」は仕事の定義です。この違いが、回答の品質を根本的に左右します。
図1: 曖昧な指示と定義された指示の違い
Lat91では、AIエージェントを10体運用していますが、初期の失敗のほぼ全てがこのパターンでした。「良い出力が出ない」と感じたとき、プロンプトをいじる前に「この仕事の完成形が自分の頭の中にあるか？」を問い直すことで、問題が解決することが大半でした。
ここで一つの問いを立てます。あなたが今週AIに頼んだ仕事の中で、「アウトプットの定義を先に書いてから頼んだ」ものはいくつありましたか。おそらく多くのケースで、「何をしてほしいか」はぼんやりあるが、「どんな状態になれば完成か」を言語化せずに投げていたはずです。これが問題の正体です。
良いプロンプトの構造：4要素フレームワーク
仕事の定義ができていれば、プロンプトの構造はシンプルです。私たちが実際に使っているフレームワークを共有します。
Role（役割）：AIに何者として振る舞わせるか
「あなたはBtoBマーケターです」と役割を与えることで、AIの視点と語彙が変わります。ただし、役割は具体的であるほど効果的です。「あなたはプロのライターです」より、「あなたは従業員300名の製造業向けにSaaS製品を売る営業責任者です」の方が、出力の質が上がります。
Context（文脈）：背景情報と制約
AIが知らない情報を渡します。「当社は○○業界で、読者は意思決定権を持つ部長クラス、競合はA社とB社」といった情報が該当します。制約も文脈に含めます。「専門用語は使わない」「200字以内」「箇条書き禁止」など。
Task（タスク）：アウトプットの形式・粒度・禁止事項
ここが最も重要です。「何を書くか」ではなく「何がアウトプットとして手元に届くか」を定義します。形式（箇条書き・表・文章）、分量（文字数・項目数）、禁止事項（使わない言葉・含めない要素）をセットで書きます。
Verify（検証）：期待する品質基準を明示する
多くのプロンプトに欠けているのがこの要素です。「この出力を使う人が最初に確認するポイントは何か？」を先に書いておくと、AIはそれを満たそうと振る舞います。「経営者が読んで5分で意思決定できる内容か確認してから出力してください」のように使います。
実際のビフォーアフターを示します。Lat91が競合調査レポートを生成する際の例です。
改善前：「A社について調べてまとめて」
改善後：「あなたはIT企業のマーケティング責任者です。A社（BtoB SaaS、主要顧客は製造業の生産管理部門）について、以下の4点を調査してください。①主力製品の価格帯、②強みとしてアピールしているキーワード上位3つ、③最近6ヶ月以内の新機能・サービス変更、④Lat91の製品と比較したときの主な差異。出力は表形式で。各項目に情報源のURLを添付してください。情報が不明な場合は「要確認」と記載すること。」
改善後のプロンプトが長いのは当然です。仕事が定義されているからです。逆に言えば、短いプロンプトで良い出力が得られているとすれば、その仕事の定義はすでに自分の頭の中にあり、AIがたまたまそれを当てているに過ぎません。
業務タイプ別のプロンプト設計パターン
仕事の種類によって、4要素のどこに力を入れるべきかが変わります。
文書作成系（提案書・議事録・メール）
文書作成ではTaskの定義が最も重要です。特に「禁止事項」を明示することで品質が上がります。
月曜から試せるテンプレート：
役割：あなたは[業界]の[職種]として振る舞ってください。
文脈：この文書は[目的]のために[読者]が読みます。[制約条件]。
タスク：[入力内容]をもとに[文書形式]を作成してください。文字数：[上限]。禁止：[不要な要素]。
検証：[読者]が読んで[判断基準]を満たすか確認してから出力してください。
分析系（データ解釈・競合調査）
分析ではContextへの投資が回答精度に直結します。「どのデータを見て何を判断したいか」を具体的に書きます。「売上データを分析して」ではなく、「2025年Q1-Q4の製品別売上推移から、来期の重点製品3つを選ぶ根拠を示してください」という形です。
月曜から試せるテンプレート：
文脈：[データの背景]。この分析は[誰が][何の意思決定のために]使います。
タスク：[データ]を分析し、[意思決定の選択肢A/B]のどちらが支持されるか、根拠3点で答えてください。
検証：「なぜその結論か？」という反論に答えられるか確認してください。
コーディング系（Claude Code活用）
コーディングではRoleと検証が効きます。「シニアエンジニアとしてレビューしてください」という役割付与と、「このコードを本番環境に入れる前に確認すべきリスクを列挙してください」という検証指示を組み合わせます。
Claude Codeを使う場合、さらに一歩進んで「CLAUDE.mdに仕事の定義を書いておく」ことができます。プロジェクトのルール・制約・禁止事項をファイルに書くことで、毎回のプロンプトに同じ情報を書く手間が省けます。これはまさに「仕事の定義の外部化」です。
図2: タスクタイプ別プロンプト設計マップ
海外事例：Anthropic と大企業が示す設計思想の差
AnthropicはClaude向けのプロンプトエンジニアリング公式ガイドを公開しています。そこで強調されているのは「プロンプトの長さより構造の明確さ」という原則です。特にシステムプロンプトに「してほしいこと」だけでなく「してほしくないこと」を書くことが重要と明示されています。
Morgan Stanleyは2023年にChatGPTをファイナンシャルアドバイザーの業務支援に導入しました。同社が公開した事例では、約70,000本の社内調査レポートをベースとしたカスタムモデルを構築しましたが、最も時間を費やしたのはモデルのファインチューニングではなく「各業務におけるアウトプットの定義」だったと報告されています。つまり、「このレポートを使って何をする人が、何を必要としているか」を整理するプロセスに3ヶ月かけました。
Salesforceも同時期にEinsteinに生成AI機能を統合しましたが、顧客向けに公開したベストプラクティスガイドには「プロンプトを短くしようとするな。ビジネスコンテキストを惜しまず渡せ」と書かれています。これは日本企業のAI活用で見られる傾向——「なるべく短い指示で動かしたい」という考え方——と真逆です。
日本企業との違いを一言で言えば、設計思想の優先順位です。海外の先進事例は「仕事の定義→プロンプト」の順で考えます。一方で日本では「プロンプトを改善→なんとなく良くなった」というフィードバックループで止まっていることが多い。根本的な定義の作業を後回しにしたまま、表面の言葉を磨いている状態です。
もう一つ興味深い事例があります。Netflixは2023年に社内のコンテンツ分析業務にAIを本格導入しましたが、担当チームが公開したレポートによると、プロンプトの改善より「分析者が何を知りたいかを事前に構造化するプロセス」の設計に最も多くの時間を割いたとあります。分析者が自分の問いを言語化できて初めて、AIの回答が使えるものになると結論づけています。これは業界を問わず共通する構造です。
3年後の展望として、現在「プロンプトエンジニアリング」と呼ばれているスキルは、おそらく「業務設計スキル」に名前が変わります。AIモデルの性能が上がるにつれ、細かい指示の書き方よりも「何をインプットして何をアウトプットするか」を定義する力が競争優位の源泉になります。今、プロンプトを磨いている人が本当に磨くべきは、AIへの指示文ではなく自分たちの業務を言語化する力です。
よくある反論
「プロンプトをそこまで考える時間がない」
この反論には一理あります。毎回4要素を丁寧に書いていたら、AIを使う方が遅くなります。ただし、これは「毎回ゼロから書く」前提の話です。
仕事の定義は一度作れば再利用できます。同じ種類の仕事を週に5回するなら、最初の1回に30分かけて定義を作ることで、残り4回はそれを流用できます。Lat91では、よく使うプロンプトを.md形式でGitに保存しており、業務ごとに数百行の「仕事の定義集」が蓄積されています。最初の投資が積み上がるほど、後の速度が上がります。
「毎回テンプレを使うとAIっぽくなる」
テンプレートを使うとAIっぽくなるのは、テンプレートの問題ではなく「検証（Verify）」の省略が原因です。同じテンプレートを使っても、最後の検証指示に「この文章が自分の会社の経営者の口調に合っているか確認して修正してください」と加えるだけで、出力の個性は大きく変わります。
テンプレートは「型」であって「答え」ではありません。料理のレシピが同じでも、食材や火加減で味が変わるように、プロンプトのフレームが同じでも、Contextに何を入れるかで出力は変わります。
まとめ
プロンプト設計の本質は、AIへの指示文ではなく仕事の定義にあります。何をインプットして何をアウトプットするかを明確にできない仕事は、プロンプトをどれだけ磨いても改善しません。
今日から試せる一歩は、次にAIに何かを頼む前に「この仕事のアウトプットとは何か？」を紙に書くことです。それができれば、プロンプトは自然に書けます。書けないとしたら、プロンプトより先に仕事の定義を固める方が先決です。
AIの能力が上がれば上がるほど、問われるのは人間側のスキルになります。「どんな指示でも良い感じに解釈してくれるAI」が実現したとしても、「自分が何を望んでいるかを言語化できない人」の問題は解決しません。プロンプトエンジニアリングの本質は、AIへの指示技術ではなく、自分の仕事を言葉で定義する力です。それは今すぐ、明日の業務から磨き始められます。
Lat91では、AIエージェントの構築・運用を支援するコンサルティングサービスを提供しています。「自社の業務にどのようにAIを組み込むか」を一緒に考えたい方は、お気軽にご相談ください。