プロンプトエンジニアリングとは、生成AIから求める出力を安定して得るために、指示文(プロンプト)を書き、試して直すことです。プログラミングの知識は要りません。普段の日本語で「誰として」「何を」「どんな形で」答えてほしいかを書き分けるだけで、同じAIでも答えの質と手直しの量が大きく変わります。

この記事は、2026年10月時点のOpenAIとAnthropic(Claudeの提供元)の公式ドキュメントをもとにしています。画面や機能は変わることがあるため、使う前に各社の公式ドキュメントで最新の内容を確かめてください。

この記事の答え

  • プロンプトエンジニアリングは、生成AIへの指示文を書いて試し、直すことで、プログラミングの知識は要りません
  • 書き方より先に「どんな答えなら合格か」を決めておくと、直す方向がぶれません
  • よく使う業務1つで型を試し、確かめ方と一緒にひな形を社内で共有します

プロンプトエンジニアリングとは|生成AIへの指示文を設計し、試して直すこと

プロンプトエンジニアリングとは、ChatGPTやClaude、Geminiのような生成AIに渡す指示文を設計し、出力を確かめながら改善していく作業です。生成AIの中身は大規模言語モデルと呼ばれる仕組みで、渡された文章の続きとして最もありそうな答えを返します。指示があいまいだと、モデルは足りない部分を一般的な内容で埋めるため、自社の業務には合わない答えになりがちです。

指示文の書き方で、出力の質と手直しの量が変わる

指示文に書かなかった条件は、AIには伝わっていないと考えるのが基本です。たとえば「会議の内容を要約して」とだけ頼むと、文字数も書式も毎回ばらばらになり、受け取った人が整え直す手戻りが出ます。「決まったこと・担当・期限を表にして」と書き足すだけで、手直しはほとんど要らなくなります。

業務で使う場合、1回ごとのわずかな手直しも、件数が多いと大きな時間になります。指示文を一度きちんと作っておけば、同じ業務を誰が頼んでも同じ水準の答えが返るようになります。個人の工夫で終わらせず、社内で使い回す価値があるのはこのためです。

プログラミングの知識は要らない

指示文は普段の日本語で書けるため、プログラミングの知識がなくても始められます。必要なのは、業務の目的と「良い答え」の条件を言葉にする力です。業務をいちばんよく知っている現場の担当者が、もっとも良い指示文を書けることも珍しくありません。

求人では、指示文の設計を専門に担う「プロンプトエンジニア」という職種も見かけます。システムにAIを組み込む場面ではプログラムの知識も求められますが、社内の業務で生成AIを使う範囲なら、専任の職種を置かずに各部署の担当者が身につけるのが一般的です。

プロンプトエンジニアリングの代表的な手法|ゼロショット・フューショット・Chain of Thought

よく使われる手法は、例を付けずに頼むゼロショット、例を付けて頼むフューショット、考える順序を示すChain of Thoughtの3つです。どれか1つを選ぶものではなく、業務に合わせて組み合わせます。

手法 やり方 向いている業務
ゼロショット 例を付けず、指示だけで頼む 要約・翻訳など、答えの形が一般的に決まっている作業
フューショット 入力と望む出力の例を2〜3組付けて頼む 社内の書式や言い回しに合わせたい作業
Chain of Thought 答えを出す前に、確かめる順序を書いて頼む 条件の照合や計算など、途中の判断がある作業

ゼロショット:議事録の要約の例文

例を付けない分、出力形式と「やってはいけないこと」を言葉で細かく書くのがこつです。議事録の要約なら、次のように書きます。

あなたは社内会議の書記です。
次の会議メモを、社内の関係者に共有する議事録にまとめてください。
・「決まったこと」「担当者と期限つきのやること」「次回までの宿題」の3つの見出しに分ける
・やることは「担当者|内容|期限」の表にする
・メモに書かれていないことは書かず、不明な担当や期限は「未定」とする

■ 会議メモ
(ここにメモを貼る)

最後の行の「書かれていないことは書かない」は、AIがもっともらしい担当者や期限を補ってしまうのを防ぐための一文です。

フューショット:問い合わせへの返信の下書きの例文

フューショットは、入力と望む答えの例を付けて、書式や口調をまねさせる書き方です。社内の返信の型がある業務では、言葉で説明するより例を見せるほうが早く伝わります。英語ではFew-shotと書きます。

あなたはお客様窓口の担当者です。問い合わせへの返信の下書きを作ります。
・敬語で、1通200字以内にする
・回答できない内容は「担当部署に確認のうえ、改めてご連絡します」と書く
・下の例と同じ構成(お礼→回答→次の案内)にする

■ 例1
問い合わせ:請求書の再発行はできますか。
返信:お問い合わせありがとうございます。請求書の再発行は可能です。マイページの「請求書一覧」から発行いただけます。ご不明な点があればお知らせください。

■ 例2
問い合わせ:契約の途中で解約できますか。
返信:お問い合わせありがとうございます。解約の条件はご契約内容により異なるため、担当部署に確認のうえ、改めてご連絡します。

■ 今回の問い合わせ
(ここに問い合わせ文を貼る)

OpenAIの公式ガイドは、例を付けるときは入力のばらつきを幅広く見せるよう勧めています。答えられる質問と答えられない質問の両方を例に入れておくと、AIが答えられない問い合わせで回答を作ってしまうことが減ります。

Chain of Thought:資料の構成案の例文

Chain of Thoughtは、答えを出す前に考える順序を示し、途中の判断を飛ばさせない書き方です。資料の構成を考えるような、目的から逆算する作業で効果が出やすくなります。

あなたは社内向け資料の編集者です。
来期の業務改善の提案資料の構成案を作ります。次の順に考えてから、最後に構成案を出してください。
1. 資料を読む人(部長会)が判断したいことを1文で書く
2. その判断に要る情報を、下の背景資料から箇条書きで拾う
3. 拾った情報を、結論→理由→費用→進め方の順に並べる
出力形式:スライドごとに「見出し|載せる内容(2行まで)」の表。10枚以内

■ 背景資料
(ここに現状の数字や課題のメモを貼る)

考える力の強いモデル(推論モデル)は、指示しなくても内部で順序立てて考えます。OpenAIの公式ガイドは、推論モデルには目的を大まかに伝えるほうが良い結果になり、一般的なモデルには細かく正確な指示が向くとしています。使っているモデルで順序の指示が要るかは、同じ入力で両方を試して比べると分かります。

業務で使う指示文の書き方の型|役割・ルール・例・資料の順に書く

指示文は、役割と目的、守るルール、入力と出力の例、答えに要る資料の4つに分け、この順に書くと整理しやすくなります。OpenAIの公式ガイドが、指示文(開発者向けの指示)に入れる部分として挙げている順序です。

順番 書く部分 書くこと 議事録の例
1 役割と目的(Identity) AIに担ってほしい役割、答えの目的、口調 社内会議の書記として、関係者に共有する議事録を作る
2 守るルール(Instructions) 出力形式、文字数、やってはいけないこと 3つの見出しに分ける。メモに無いことは書かない
3 入力と出力の例(Examples) 望む答えの見本。2〜3組 過去の議事録のうち、出来の良かったもの
4 答えに要る資料(Context) 今回の材料、社内の資料、前提の数字 今回の会議メモ

資料は指示文の終わり近くに置く

長い資料は、指示文の終わり近くに置くのが基本です。OpenAIの公式ガイドは、答えに要る資料は指示文の終わり近くに置くのが通常は良いとしています。先に資料を貼り、そのあとに短い指示を書くと、指示が資料に埋もれて読み落とされやすくなります。

役割・ルール・例のように毎回変わらない部分を前に、毎回差し替える資料を後ろに置くと、ひな形として使い回しやすくなる利点もあります。

見出しや区切りで範囲を分ける

どこまでが指示で、どこからが資料かを、見出しや記号で分けておきます。例文では「■ 会議メモ」のような見出しを使いました。OpenAIの公式ガイドも、Markdownの見出しや箇条書き、<資料>〜</資料>のようなタグで範囲を区切る書き方を挙げています。範囲が分かれていないと、資料の中の文章を指示と取り違えることがあります。

出力を評価して直す手順|先に成功の基準を決める

指示文を直す前に、「どんな答えなら合格か」という成功の基準を決めておきます。Anthropicの公式ドキュメントは、プロンプトエンジニアリングを始める前提として、次の3つを用意するよう書いています。

  1. 業務ごとの成功の基準 「決まったことの抜けが無い」「表の書式が崩れない」「200字以内」のように、確かめられる形で書きます
  2. その基準で試す方法 過去の会議メモや問い合わせのような実例を5〜10件ほど集め、指示文を直すたびに同じ入力で流して基準を満たすか見ます
  3. 直す元になる最初の指示文 完璧でなくてよいので、4つの型に沿って一度書き切ります。直す元が無いと、何を変えたら良くなったのかが分かりません

基準を満たさない項目だけを直す

評価で落ちた項目に関わる部分だけを直し、一度に何か所も変えないようにします。書式が崩れるならルールか例を、事実の誤りが出るなら資料の渡し方を見直します。1か所ずつ直して同じ入力で試すと、どの直しが効いたかが分かり、ひな形を社内に配るときにも理由を説明できます。

遅さや費用は、モデルを選び直すほうが早い場合がある

すべての問題を指示文で直そうとしないことも大切です。Anthropicの公式ドキュメントは、答えが返るまでの遅さや費用は、別のモデルを選ぶほうが簡単に改善できる場合があるとしています。たとえば短い要約のような作業は軽いモデルでも基準を満たすことが多く、指示文を削って速くするより、モデルを替えて同じ試しの入力で確かめるほうが早く片づきます。

プロンプトエンジニアリングとコンテキストエンジニアリングの違い

プロンプトエンジニアリングは指示文そのものを工夫することで、コンテキストエンジニアリングはAIが答えるときに参照する情報全体(社内の資料、過去のやり取り、使える道具など)をそろえる仕組みを設計することです。指示文の書き方を直しても答えが良くならない業務は、書き方ではなく、渡している情報のほうが足りていないことが多くあります。

比べる点 プロンプトエンジニアリング コンテキストエンジニアリング
何を工夫するか 1回ごとの指示文の書き方 AIに渡す資料や記録をどう集め、どう渡すか
主に誰が行うか 業務でAIを使う担当者 仕組みを作る開発の担当者と業務の担当者
効く場面 書式・口調・考える順序がずれる 社内の規程や最新の数字を知らないために答えを誤る
必要なもの 型と、出力を確かめる基準 社内の資料の整理、検索の仕組み、業務システムとの連携

書き方で直らない業務は、資料を渡す仕組みを考える

社内の規程や顧客ごとの条件に沿って答えてほしい業務は、指示文に毎回資料を貼る運用では続きません。担当者が貼る資料を選び間違えたり、古い版を貼ったりするためです。こうした業務では、社内の資料を検索してAIに渡す仕組み(RAG)や、業務システムから必要なデータを取り出して渡す開発が要ります。社内データの渡し方には、検索して渡す方法とモデルそのものを追加で学習させる方法があり、多くの業務は検索して渡す方法から始めます。

型を当てても基準を満たさない業務が見つかったら、その業務は書き方の研修ではなく、資料を渡す仕組みや業務への組み込みとして進めるかを検討します。どの業務がどちらに当たるかの見極めは、社内で判断がつかなければ外部に相談するのも一つの手です。

自社で型を広めるか、支援を頼むかの判断 2つの問いで、自社で指示文のひな形を作って広めるか、研修や開発の支援を頼むかを決める ・上から順に答え、最初に分かれたところで決まります 型を当てて直すと、決 めた基準を満たす答え が出るか 資料を渡す仕組みを検討する ・業務への組み込みや開発の支援も検討 いいえ はい 各部署に、型で書ける 人がいるか 研修で書き方の基本をそろえる ・研修のあとに業務で使う場を作る いいえ はい 自社でひな形を作って広める ・確かめ方と一緒に共有する
型を当てても基準を満たさない業務は、書き方より渡す情報が足りていません。
その業務は資料を渡す仕組みづくりを検討します。

社内でプロンプトエンジニアリングの型を広める進め方

社内で広めるときは、よく使う業務を1つ選び、指示文のひな形を作り、出力の確かめ方と一緒に共有する順に進めます。個人がうまく書けた指示文をそのまま配っても、ほかの人は何を差し替えればよいか、出力をどう確かめればよいかが分からず、使われなくなります。

指示文のひな形を社内で広める流れ 業務を選び、ひな形を作り、確かめ方を決め、共有して直す4段階 ・よく使う業務1つから始め、確かめ方とセットで共有します 業務を選ぶ 回数の多い業務 ・議事録・返信など 良い答えの見本 ・過去のうまくいった例 ひな形を作る 型に沿って書く ・役割・ルール・例・資料 差し替える欄 ・【】で入力欄を示す 確かめ方を決める 成功の基準 ・抜け・誤り・書式 試す入力 ・5〜10件の実例 共有して直す 置き場所を1つに ・版と更新日を書く 社内で利用 ・直しの依頼を集める
ひな形は、出力の確かめ方と一緒に配ります。
使った人の直しを集めて版を上げます。

よく使う業務から、指示文のひな形を作る

最初の1つは、回数が多く、良い答えの見本が手元にある業務から選びます。議事録、問い合わせへの返信、定例の報告書がその代表です。ひな形では、毎回差し替える部分を【会議メモ】【問い合わせ文】のように括弧で示し、使う人が触るのはそこだけで済むようにします。

ひな形には、成功の基準と試しの入力も添えます。使った人が「基準を満たさなかった入力」を戻してくれれば、それが次の改善の材料になります。手順と資料をまとめて呼び出せる仕組みを使うと、共有と更新の手間を減らせます。

ひな形の置き場所は社内で1か所に決め、版と更新日を書いておきます。似たひな形が部署ごとに増えると、どれが最新か分からなくなるためです。直したときは「何を変えたか」「どの基準が満たせるようになったか」を1行で残すと、別の部署が使い回すときの判断材料になります。入力してよい情報の範囲(顧客名や個人情報を入れてよいか)は、ひな形を配る前に社内の利用ルールで決めておきます。

研修は、業務で使う場とセットにする

書き方の基本をそろえる研修は、受講後すぐに自分の業務で型を使う場とセットにすると定着します。研修には、オンラインの動画で学ぶ形から、自社の業務を題材に演習する形まであり、費用や助成金の使い方も種類によって違います。

書ける人を各部署に置き、その人たちがひな形を作って周りに広げる形にするなら、育てる人材像と段階を先に決めておくと進めやすくなります。

まとめ:プロンプトエンジニアリングは型と確かめ方をセットで広める

  • プロンプトエンジニアリングは、生成AIへの指示文を書き、試して直すことで、プログラミングの知識は要らない
  • 代表的な手法は、ゼロショット・フューショット・Chain of Thoughtの3つで、業務に合わせて組み合わせる
  • 指示文は役割と目的、守るルール、入力と出力の例、答えに要る資料の順に書き、資料は終わり近くに置く
  • 直す前に成功の基準と試す方法を決め、遅さや費用はモデルの選び直しも検討する
  • 書き方で直らない業務は、コンテキストエンジニアリング(資料を渡す仕組み)の領域として進める
  • 社内では、よく使う業務1つからひな形を作り、確かめ方と一緒に共有する

Augueでは、業務ごとの指示文のひな形づくりから、社内の資料をAIに渡す仕組みや業務に組み込むAIエージェントの開発まで、社内に作れる人を残す形で支援しています。ご興味がある方は是非ご相談ください。

社内でAIを使いこなせる人を育てませんか?

Augue AX サービス資料 Service Guide

研修だけで終わらせず、現場の業務で使い続けられる体制づくりまで伴走します。研修の内容と進め方は、サービス資料で紹介しています。

資料をダウンロードする無料相談に申し込む

よくある質問

社員に書き方を身につけさせるには、研修と業務のどちらから始めればよいですか?

研修だけで終わらせず、受講した週のうちに自分の業務で型を使う場を用意するのが近道です。研修で聞いた型は、手元の仕事で一度使わないと定着しません。全社で基本をそろえたいなら短い研修から入り、すでに使っている人が多い部署なら、よく使う業務のひな形を先に配って使い方を教えるほうが早く広がります。どちらの場合も、研修の前に「どの業務で使うか」を決めておきます。

書き方が身につくまで、どれくらいの期間がかかりますか?

一律の期間は出せません。人によって使う頻度と業務が違うためです。目安にするなら、期間ではなく「自分の業務の指示文を型に沿って書き、決めた基準で出力を確かめて直せるか」で見ます。たとえば、週に数回使う業務を1つ選び、ひな形を自分で直して手直しの量が減ったかを数週間記録すると、身についたかどうかを判断できます。

顧客名や社内の数字を指示文に入れてもよいですか?

自社がどのサービスのどのプランで、何の入力を認めているかで決まります。法人向けのプランでは入力したデータを学習に使わない設定が用意されていることが多い一方、個人のアカウントでは扱いが違う場合があります。入れてよい情報の範囲は社内の利用ルールで先に決め、ひな形にも「顧客名は【顧客A】のように置き換える」といった注意書きを入れておくと、迷う人が減ります。

同じ指示文を、ChatGPT・Claude・Geminiで使い回せますか?

役割・ルール・例・資料に分ける基本の型は、どのサービスでもそのまま使えます。ただし、同じ指示文でも答えの長さや書式の守り方はモデルごとに違います。使い回すときは、ひな形と一緒に配る試しの入力を新しいモデルでも流し、成功の基準を満たすかを確かめてから切り替えます。満たさない項目があれば、その項目に関わるルールや例だけを直します。