LLM活用で成果が出るプロンプト設計のやり方

LLM活用で「成果が出ない」よくある原因はプロンプト以前にある

LLM（大規模言語モデル）を業務に使い始めたのに「回答が薄い」「ミスが多い」「結局手直しに時間がかかる」と感じるケースは珍しくありません。多くの場合、原因は“プロンプトの書き方”だけではなく、LLMに何を任せ、何を人が担保するかの設計が曖昧なことにあります。

特に情シスや管理部門が導入を主導する場合、現場の業務が複雑だったり、例外処理が多かったりして、LLMに一発で答えを出させようとすると破綻しがちです。LLMは万能な「自動化ロボット」ではなく、文章・要約・分類・案出しなどの“言語処理が得意な道具”です。得意領域に寄せて設計すると、少ない工数でも成果が出やすくなります。

本記事では、開発知識がなくても進められる「成果が出るプロンプト設計」を、業務例とテンプレート付きで解説します。結論から言うと、プロンプトは「指示文」ではなく「業務プロセスの設計図」として作ると、LLM活用の再現性が上がります。

プロンプト設計の基本：良い指示文より「条件」と「評価」を先に決める

プロンプト設計を始めると、多くの人が「どう書けば賢く答えるか」に集中します。しかし実務では、何を満たせば“合格”か（評価基準）を先に決めるほうが重要です。評価基準が決まれば、必要な情報（前提・制約・出力形式）が自然に見えてきます。

例えば「社内問い合わせ対応」をLLMに手伝わせたい場合、評価は次のように分解できます。

• 正確性：社内規程と矛盾していないか
• 網羅性：確認事項（氏名、部署、期日等）を漏らしていないか
• 安全性：機密情報の扱いに配慮し、勝手な断定をしないか
• 効率：現場がコピペで使える文章になっているか

この評価基準があると、プロンプトには「参照すべき根拠（規程の抜粋）」や「分からない場合の聞き返し」や「出力フォーマット（結論→根拠→次アクション）」を入れるべきだと分かります。逆に評価がないと、LLMは自然文として“もっともらしい回答”を生成しやすく、事故や手戻りにつながります。

また、LLM活用では「1回で完璧」を目指すより、業務を小さなタスクに分け、段階的に品質を上げるのがコツです。たとえば「提案書作成」をいきなり全部任せず、論点整理→構成案→文章化→校正という工程に分けると、プロンプトも短く安定し、チェックもしやすくなります。

成果が出るプロンプトの型：目的・前提・制約・出力・例・確認の6要素

ここからは、LLMに安定して働いてもらうための「プロンプトの型」を紹介します。社内で横展開しやすいよう、汎用的な6要素にまとめます。重要なのは、“書き方”ではなく“欠けると破綻する要素”を埋めることです。

例えば「議事録要約」でも、この型を入れるだけで品質が上がります。目的は“共有しやすい要約”、前提は“部門長が読む”、制約は“決定事項とToDoを分ける”、出力形式は“決定事項／宿題／論点”、例は“長い発言→短い要約”、確認は“不明な用語はそのまま残す”などです。

特に中小企業や情シスでは、メンバーごとにプロンプトがバラバラになりがちです。そこで、社内テンプレとして以下のような「空欄を埋めるだけ」の形にすると運用が楽になります。

あなたは社内業務アシスタントです。
【目的】（例：社内問い合わせへの返信文を作る）
【前提】（対象：誰／文体：丁寧／参照すべきルール：社内規程）
【制約】（断定しない／根拠がない推測をしない／機密は出さない）
【入力】以下の情報を使う：
- 問い合わせ本文：
- 関連ルール（貼り付け）：
【出力形式】
1) 結論（1〜2文）
2) 根拠（箇条書き）
3) 確認したい点（不足があれば質問）
4) 次アクション（担当者がやること）

LLM活用の現場では、プロンプトが長文化して読みにくくなることもあります。その場合は、目的と制約だけは短く固定し、前提・ルール・例を「差し替えブロック」にして管理すると、再利用性が高まります。つまり、プロンプトを“部品化”して資産にする発想が効きます。

業務で使えるプロンプト例：問い合わせ対応・文書作成・データ整形

ここでは、非エンジニアでもすぐ試せるLLMプロンプト例を、業務シーン別に紹介します。ポイントは「LLMに任せる範囲」を明確にし、必ず人が確認できる形（根拠・確認事項つき）で出力させることです。

社内問い合わせ（総務・情シス・経理）返信文の作成

あなたは社内ヘルプデスク担当です。
【目的】社内問い合わせに対し、規程に沿った返信案を作る
【前提】読み手は一般社員。専門用語は避け、必要なら補足する
【制約】
- 規程の記載がないことは断定しない
- 推測で回答しない。情報不足は質問する
- 個人情報・機密は本文に書かない
【入力】
- 問い合わせ本文：{ここに貼る}
- 関連ルール（抜粋）：{規程やFAQを貼る}
【出力形式】
1) 返信文（そのまま送れる文章）
2) 根拠（規程のどの記載に基づくかを箇条書きで）
3) 追加で確認したい点（あれば）
4) 代替案（例：例外対応が必要な場合のエスカレーション先）

この形だと、LLMが勝手に作り話をするリスクを下げられます。情シスなら「VPN接続」「アカウント発行」「SaaS申請」など、定型の問い合わせに特に効きます。

社内文書（稟議・提案・規程改定）たたき台作成

あなたは社内文書の作成支援者です。
【目的】稟議書のたたき台を、読みやすい構成で作る
【前提】決裁者は役員。結論→効果→リスク→費用の順で読む
【制約】
- 数値は入力にない限り「仮置き」と明記
- リスクと対策を必ずセットで書く
【入力】
- 施策の概要：
- 期待効果（定性でも可）：
- 想定コスト（不明なら空欄）：
- 関係部門：
【出力形式】
見出し付きで：背景／目的／現状課題／施策内容／期待効果／リスクと対策／費用／スケジュール／体制

LLM活用で「文章が整う」だけでも、資料作成の時間が大きく減ります。さらに、リスクと対策まで出させると、社内説明の質も上がります。

Excel・CSVの整形方針（データクレンジングの指示書）作成

LLMはデータそのものを直接加工できない場面でも、「整形ルール」や「チェック観点」を作るのが得意です。現場が迷いがちな名寄せ・表記ゆれ・欠損などを、ルール化してもらえます。

あなたはデータ整備のアドバイザーです。
【目的】顧客リストCSVを、分析・配信に使える形へ整える手順を作る
【前提】作業者はExcelを使えるが、プログラミングはしない
【制約】実行手順は、Excelの操作で実現できる内容にする
【入力】
- 列名一覧：
- 現状の問題（例：会社名の表記ゆれ、電話番号のハイフン有無）：
【出力形式】
1) 整形方針（全体像）
2) 具体手順（Excel操作を箇条書き）
3) チェックリスト（NG例とOK例）
4) 迷った時の優先順位（何を正とするか）

この用途は「すぐ自動化」ではなく、作業の標準化と属人化の解消に効きます。結果的に、データ品質が上がり、後続の分析や営業活動が楽になります。

運用で差がつく：プロンプトを改善する評価手順とガードレール

LLM活用は、導入初期よりも運用で差が出ます。なぜなら業務は例外が多く、最初のプロンプトだけでは取りこぼしが必ず出るからです。そこで、改善サイクルを“軽量に回せる形”にすることが重要です。

評価は難しく感じるかもしれませんが、ポイントは「正解データを大量に用意する」ことではありません。まずは「社内で困っている典型ケース」を少数集め、合格基準を言語化するだけで十分です。情シスなら、パスワード初期化、アカウント申請、端末紛失など、頻出の問い合わせから始めると効果が見えやすいでしょう。

また、ガードレール（安全策）を入れると、現場が安心して使えるようになります。

• 不確実性の扱い：「分からない場合は質問する」「仮定は仮定と明記」をプロンプトに入れる
• 参照優先：社内規程・手順書がある場合はそれを優先し、矛盾があれば指摘させる
• ログと監査：誰が何に使ったかを残す（少なくとも業務利用の範囲では）
• 機密・個人情報：入力しないルール、伏字ルール、利用可能な環境の整理

特に機密の扱いは、プロンプトだけで解決しません。利用するLLMの提供形態（法人向けプラン、閉域、データ保持の設定等）や社内ルールがセットです。言い換えると、プロンプト設計は「業務設計・リスク設計」と一体である、ということです。

導入を成功させるロードマップ：PoCで終わらせない進め方

予算はあるが詳しくない、という組織が最もつまずきやすいのが「PoC（試験導入）で止まる」状態です。LLM活用は試すだけなら簡単ですが、継続的な成果（時間削減・品質向上）にするには、対象業務の選び方と、運用ルールまで含めた設計が必要です。ここでは、開発なしでも進めやすい現実的なロードマップを示します。

1. 業務棚卸し：「文章・分類・要約」が多い業務を洗い出す（問い合わせ、稟議、議事録、FAQなど）
2. 対象選定：頻度が高く、失敗しても影響が小さいものから（まずは“補助”用途）
3. 合格基準：削減時間、品質（誤り率）、確認工数などを簡単に決める
4. プロンプトテンプレ化：本記事の6要素でテンプレを作り、社内配布する
5. 運用設計：入力して良い情報、レビュー担当、保存先、問い合わせ窓口を決める
6. 横展開：類似業務にテンプレを流用し、例（サンプル）だけ増やす

「開発をしないとLLM活用はできない」と思われがちですが、最初はプロンプトと運用だけでも十分成果が出ます。むしろ、いきなりシステム化すると要件が固まらず、手戻りが増えます。まずは“手順書＋テンプレ＋評価”で勝ち筋を作り、その後にシステム連携へ進むのが堅実です。

なお、将来的に社内文書検索やナレッジ参照までやりたい場合は、RAG（社内文書を参照して回答する仕組み）などの検討が必要になります。ただしそれも、最初に「参照すべき文書が整っているか」「更新ルールがあるか」が成否を分けます。技術より先に、情報の置き場と更新責任を決めておくと成功確率が上がります。

まとめ

LLM活用で成果を出すプロンプト設計は、気の利いた言い回しを探すことではありません。目的・制約・評価基準を先に決め、業務を小さなタスクに分解し、確認可能な形式で出力させることが最短ルートです。

• 成果が出ない原因は、プロンプト以前に「任せる範囲」と「評価」が曖昧なことが多い
• プロンプトは6要素（目的・前提・制約・出力形式・例・確認）で安定する
• 運用で差がつく。代表ケース10件で評価し、失敗理由を分類して改善する
• PoCで終わらせないために、テンプレ化とガードレール（機密・監査）を整える

「どの業務から始めるべきか」「社内ルールや情報管理まで含めて設計したい」「プロンプトを資産化して横展開したい」といった場合は、伴走支援が有効です。