プロンプトとは、AIへ渡す指示や質問のことです。仕事で使うときは、目的、読み手、使う資料、出力形式、不明点の扱いを分けて書き、返された内容を元資料と照合します。
最初は、担当者が正誤を確かめられる下書きや要約を一つ選んでください。資料を渡すだけで、AIが社内の受付条件や承認の手順まで知っているとは考えません。
どの業務から試すかは生成AIの業務活用で、自社が検索でどう説明されるかの調査はChatGPTの検索確認で扱います。ここでは、選んだ仕事をどう依頼し、依頼文をどう直すかに絞ります。
公式ガイドの共通点は？
各社の原文を読むと、特別な決まり文句より、何をしてほしいかと、どんな材料を使うかを明確にする説明があります。製品ごとの操作やデータの保存条件とは分けて読みます。
Anthropicは明確な指示を求める
Anthropicの指示設計ガイドには、次の見出しがあります。
Be clear and direct
明確に、直接的に伝えるという意味です。望む出力を具体的に指定する説明が続きます。業務の背景を知らない相手へ渡しても、何を作るか分かる文にします。
「見積もりをいい感じに」では、返信文なのか、条件整理なのか、金額計算なのかが分かりません。「見積もり前に確認する不足項目を抜き出す」と、動作を示す言葉へ変えます。
Googleは出力例を使う
Googleのプロンプトガイドは、出力の形を例で示す方法を説明しています。書式に関する節の見出しは次のとおりです。
Consistent formatting
例の構造と書式を揃えるという説明です。毎回同じ欄で受け取りたい仕事なら、欄名を列挙するだけでなく、短い記入例を添えます。正解を持たない内容を、もっともらしい例で埋める作業ではありません。
たとえば、資料に材質の指定がない場合の例を「材質：記載なし」と示せます。空欄を推測で埋めない形式を、実際の出力でも守ったか確かめます。
Microsoftは要素を分ける
Microsoftの依頼文のガイドは、目的、背景、情報源、期待する応答を挙げています。目的の説明には次の問いがあります。
What do you want Copilot to do?
何をしてほしいか、という問いです。全部の欄を長く埋めること自体が目的ではありません。結果を使う人が、必要な作業と材料を確認できるようにします。
以下の型は、これらの説明を踏まえて私たちが整理した実務用の例です。各社共通の公式書式や、正答を保証する方法ではありません。
依頼文をどう組み立てる？
本文を一段落へ詰めず、項目を分けます。社内の仕事を説明するときも、目的と材料と納品形式が分かれていれば、足りない条件を見つけやすくなります。
| 項目 |
書くこと |
| 目的 |
何を終えたいか |
| 読み手と用途 |
誰が何の判断に使うか |
| 資料 |
使ってよい情報の範囲 |
| 出力 |
返してほしい欄や文章の形 |
| 制約 |
補わない情報と確認へ戻す条件 |
たとえば、技術資料の要約なら、短くしてほしいだけで終えません。設計者が材料を比較するためなのか、営業が確認先を決めるためなのかを伝えます。残すべき条件が変わるからです。
資料と指示の境目も明確にします。「ここから資料」「ここまで資料」のように区切れば、どこが依頼でどこが材料かを確認できます。公開済みの資料でも、入力に使ってよい範囲かは先に確認します。
出力の欄には、人が照合する順番を使います。材質、適用条件、例外、資料の箇所の順なら、担当者が原文を読みながら確認できます。見栄えのよい長文を受け取ってから、確認用の表へ作り直す負担を減らします。
見積もりの下書きを頼む
次は製造業の受付を想定した練習用の依頼文です。顧客案件や私たちの導入実績ではありません。実際の顧客名、図面、価格を入れず、業務の形式を試します。
目的：樹脂部品の見積もり前に使う確認文を下書きしてください。
読み手：仕様を確認する営業担当です。外部への送信はしません。
資料：この後に渡す、公開済みの受付案内だけを使ってください。
出力：分かっている条件、不足項目、社内で確認する項目、返信文案に分けてください。
制約：単価、金額、納期、対応可否は作らないでください。資料にない事項は確認待ちとし、相手へ約束する文を書かないでください。
この型では、見積金額の確定を依頼していません。何を聞けば見積もれるかという文章の準備です。返信文案に「対応可能です」が混ざったら、指示を守っていない出力として差し戻します。
確認する人は、不足項目が本当に受付案内に沿っているかを見ます。資料に数量の指定が必要とあっても、AIが独自に最低数量を作っていたら採用できません。項目が必要なことと、その値が決まっていることは違います。
不足が多いなら、文章を整える前に確認項目だけを作らせる方法もあります。人が必要な質問を確定してから、その内容で返信文を作ります。一度の依頼へ、確認と承認と送信まで詰め込まないようにします。
技術資料の要約を頼む
材料や製品を比較するための要約では、短さより条件を残すことを優先します。次は、利用を認められた公開資料を使う練習用の型です。
目的：技術資料から、材料の適用条件を確認するための要約を作ってください。
読み手：材料選定を検討する設計担当です。
資料：渡した資料だけを使ってください。資料名と版は入力時に示します。
出力：対象、数値と単位、試験条件、適用範囲、例外、確認が必要な点を分けてください。各項目に根拠の頁か見出しを付けてください。
制約：記載がない欄は記載なしとしてください。資料の測定値を、別の材料や自社製品の保証値へ広げないでください。
出力を受け取ったら、値だけでなく、対象グレード、単位、測定条件を原文と照合します。根拠の頁が付いていても、別の材料の表を指していれば誤りです。
断片的な抜粋しか渡していなければ、その範囲での要約と扱います。資料全体を読んだ結果として報告しないでください。長い資料を分けて扱うときは、どの部分を渡したかも記録します。
自社の技術記事が要約されるときに条件を落とさせない書き方はAI要約への備えで扱います。ここで残すのは、渡した資料の範囲と出力の根拠です。
結果が違ったらどう直す？
長い注意書きを追加する前に、失敗の種類を分けます。出力形式が違うのか、材料が不足したのか、資料にない説明を足したのかで、直す場所が変わります。
書式が違うなら、正しい欄の短い例を添えます。条件が落ちたなら、残す項目と根拠欄を明示します。資料にない値が出たなら、その値を埋める作業を止め、不明点の一覧へ戻します。
一度に指示全体を変えると、どの変更で改善したか分からなくなります。失敗した箇所と変更した文を対応させ、元の入力でもう一度確かめてください。成功した出力だけでなく、失敗した例も保存します。
プロンプトエンジニアリングは、このように望む結果に合わせて指示を設計し、出力を確かめながら改善する作業です。専門家の役割を名乗らせたり、指示を長くしたりすることだけを指しません。
条件を渡したことと、結果がその条件を守っていることは別です。依頼したから守ったはず、と確認を省かないようにします。
型を社内で使い回すには？
固定する指示と、毎回入れ替える資料を分けます。固定するのは作業の目的、出力欄、確認へ戻す条件です。資料名、版、対象製品、今回の用途は入力ごとに確かめます。
依頼文と一緒に、確認済みの入力例、出力例、採用しなかった理由を保存します。担当が替わっても、何を正解として扱うかが分かる形です。古い資料へ新しい依頼文を付けても、情報自体は新しくなりません。
サービスや機能を変えたときは、保存した例で再確認します。同じ指示でも同じ結果を返す前提にせず、資料の条件と出力欄を確認します。利用する会社のデータ規程はAIの社内ルールへ進めます。
指示文は契約や権限を変えない
秘密にするよう書いても、サービスの保存・共有条件は変わりません。社外秘や個人情報を試行へ入れず、会社が認めた資料とアカウントを使います。
完了をどう判断する？
依頼文が完成したことと、業務で使える結果が出たことを分けます。元資料と一致し、不明な条件を勝手に埋めず、担当者が使う形へ整ったかを確認してください。
見積もりの文案なら、営業や技術が内容を確定し、人が送信します。技術要約なら、設計者が原文へ戻れることを確認します。出力の自然さや、AIが付けた自信の評価を承認の代わりにしません。
自社サイトのAI活用につなげる場合も、試す作業、公開してよい資料、確認する人を一組にして相談してください。依頼文の型を、会社として答えを確定する工程へ組み込めます。
仕様・出典の確認日：2026年10月23日。
