Prompt Engineering ガイド 第7回（全10回）。応用編です。第1〜6回の基礎を前提にしています。初めての方は 第1回：プロンプトエンジニアリングとは何か、なぜ重要か からどうぞ。
オフィスワークの多くは「読むこと」です。要約・表作成・文書分析のためのAIプロンプトは本シリーズでも特に実用的なスキルですが、重要な数字を落とした要約や写し間違えた数値など、雑なプロンプトが静かに害を及ぼす領域でもあります。
要約やアクション抽出から数値の検証、契約書レビューまで、8つの作業にそのまま使えるプロンプトを、出力例と「なぜ効くのか」とともに紹介します。
ChatGPT、Claude、Geminiのいずれでも動作します。区切り（<document> のようなタグ）と出力形式の明示を多用するので、初めての方は先に プロンプトの構造：5 つの構成要素 をお読みください。
要約プロンプト：読み手・長さ・形式・焦点を指定する
要約は特定の読み手にとってしか役に立ちません。「これを要約して」だけでは、モデルは読み手を推測し、無難な概要を返します。代わりに次の4つを指定しましょう。読み手、長さ、形式、焦点です。
文書を先に、指示を後に置きます。Anthropic のプロンプトガイド も長い文書は質問より上に置くことを推奨しています。以下は本記事で通して使うサンプル文書です。
2026年第3四半期 運用レポート：サポートプラットフォーム
チケット件数は18,400件で、第2四半期（16,430件）から12%増加しました。7月に週末シフトを追加した結果、初回応答時間の中央値は3.1時間から2.4時間に短縮しました。顧客満足度（CSAT）は91%で横ばいです。クラウド費用は42,800ドルで、予算39,300ドルを9%超過しました。主な原因は、ログの保存量が計画を上回るペースで増えたことです。稼働率99.9%のSLAを下回るインシデントが2件発生しました（8月14日のデータベースのフェイルオーバー47分、9月3日のDNS障害22分）。人員はエージェント14名で変わりませんが、9月にシニアエージェント1名が退職し、現在募集中です。来四半期は30日より古いログをコールドストレージへ移す予定で、月額約3,000ドルの削減を見込んでいます。テンプレートです。波括弧の4項目を書き換えてください。
<document>
{ここに文書を貼り付け}
</document>
上の文書を要約してください。
- 読み手：{誰が読むか、何を知っているか}
- 長さ：{例：箇条書き3点、または80字以内}
- 形式：{例：箇条書き、1段落、短いメール}
- 焦点：{読み手が気にすること。それ以外は省く}
文書に書かれている事実だけを使ってください。数値は書かれているとおりに残してください。
この読み手に必要な情報が文書に欠けている場合は、最後に「不足：」で始まる1行で指摘してください。CFO（最高財務責任者）向けに記入した例（読み手：「スマホで読むCFO」、長さ：「箇条書き3点、150字以内」、形式：「各項目を短いラベルで始める」、焦点：「予算比のコスト、削減策、財務リスク」）：
- 予算超過：第3四半期のクラウド費用は42,800ドルで、予算39,300ドルを9%超過。主因はログ保存量の想定以上の増加。
- 削減計画：来四半期に30日超のログをコールドストレージへ移し、月額約3,000ドルの削減を見込む。
- リスク：99.9%のSLAを下回るインシデントが2件（47分・22分）。シニア職1名が欠員。
不足：SLA違反により顧客へのクレジット（返金）が発生するかどうかは記載がありません。出力例：文言は実行ごと・モデルごとに変わります
ポイント：「数値は書かれているとおりに残す」の一文は重要です。これがないと数値が丸められがちで（「約4.3万ドル」）、転送されるレポートでは誤りになります。
議事メモから決定事項とアクションを抽出する
議事メモには、決定事項、誰がいつまでに何をするか、未解決事項の3つが混在しています。固定のスキーマで別々に出力させ、空欄のルールを1つ加えます。担当者や期限がなければ「未定」「期限なし」と書かせることです。そうしないと、モデルはもっともらしい推測で埋めます。「根拠」列があれば、裏付けのない行をすぐ削除できます。
{notes} を手元のメモやメールスレッドに置き換えてください。
<notes>
{notes}
</notes>
上のメモから、次の3つのセクションを作成してください。
## 決定事項
合意された内容を箇条書きで。1項目1行。
## アクションアイテム
Markdownの表。列は「担当者 | タスク | 期限 | 根拠」。
- 担当者と期限はメモに書かれているものだけを使う。書かれていなければ「未定」「期限なし」と書く。推測は禁止。
- 根拠：その行を裏付けるメモからの短い引用（20字以内）。
## 未解決事項
話題に上がったが結論が出ていないもの。試すためのサンプルメモ：
運用定例 10/7 ミン、サラ、ケンジ、ラン
- ログのコールドストレージ化：全員OK、ケンジがライフサイクルルールを設定、10月中が目標
- 週末シフトは効果あり、Q4も継続
- シニアエージェント採用：サラが今週中に求人票を出す。予算は？経理に確認
- DNS障害のポストモーテムがまだ書かれていない
- ラン：影響を受けた3社にSLAクレジットを出すべき？結論出ず## 決定事項
- 古いログをコールドストレージへ移す。
- 週末サポートシフトを第4四半期も継続する。
## アクションアイテム
| 担当者 | タスク | 期限 | 根拠 |
|---|---|---|---|
| ケンジ | コールドストレージ用のログのライフサイクルルールを設定 | 10月中 | 「ケンジがライフサイクルルールを設定」 |
| サラ | シニアエージェントの求人票を公開 | 今週中 | 「サラが今週中に求人票を出す」 |
| 未定 | DNS障害のポストモーテムを作成 | 期限なし | 「ポストモーテムがまだ書かれていない」 |
## 未解決事項
- シニアエージェント採用の予算はいくらか（経理に確認）。
- 影響を受けた3社にSLAクレジットを出すか。出力例：文言は実行ごと・モデルごとに変わります
長い文書を「中盤の取りこぼし」なくアウトライン化する
40ページの規程や仕様書では、要約だと情報が失われすぎます。アウトラインなら構造を保てます。現在のモデルは数十万トークン規模の入力を受け付けますが、すべての部分を均等に扱うわけではありません。Lost in the Middle という研究（Liu ほか、2023年）では、関連情報が入力の冒頭か末尾にあると性能が高く、中盤にあると低下する傾向が示されました。そこで、セクションごとに順番に処理させ、各要点の根拠となる文を引用させます。引用はモデルを本文に繋ぎ止める効果もあります。
<document>
{ここに長い文書を貼り付け}
</document>
上の文書のアウトラインを作成してください。
1. 冒頭から順に、セクションごとに処理する。中盤の短いセクションも含め、どのセクションも飛ばさない。
2. 各セクションについて、見出しと要点を2〜4個。
3. 各要点の後に、根拠となる原文を［］で引用する（30字以内、原文どおり）。
4. 最後に「相互参照」として、あるセクションが別のセクションに依存している箇所や矛盾している箇所を挙げる。1. 対象者
- 試用期間を終えた社員は、週3日までリモート勤務が可能。［試用期間を満了した後、週3日を上限として］
2. 機器とセキュリティ
- 顧客データにアクセスできるのは会社支給のPCのみ。［私物の端末で顧客データにアクセスしてはならない］
…（一部省略）
相互参照
- 第5章（経費）は自宅のインターネット代を補助するが、第2章には自宅ルーターがセキュリティ要件を満たす必要があるかの記載がない。出力例：文言は実行ごと・モデルごとに変わります
表作成プロンプト：文章をMarkdown・CSV・JSONの表にする
モデルは段落を、そのままExcel、Googleスプレッドシート、スライドに貼れる表に変えてくれます。質を左右するのは、多くのプロンプトが書き忘れている「読み手がその表で何をしたいか」です。「表にして」だけだと汎用的な「指標 | 値」の一覧になり（下図の左側）、比較は読み手任せです。目的を伝えれば、問いに答える列を選んでくれます。
<report>
{第3四半期レポートを貼り付け}
</report>
このレポートを5分で経営陣に報告します。経営陣が知りたいのは、前四半期から何が変わったか、何に対応が必要かです。
Markdownの表を作成してください。列は「指標 | Q2 | Q3 | 変化 | ステータス」。
- Q2：レポートに記載がある場合のみ値を入れ、なければ「n/a」と書く。
- 変化：レポート内の数値だけから計算する。
- ステータス：「順調」「注視」「要対応」のいずれかと、15字以内の理由。
「要対応」の行が先頭に来るように並べてください。| 指標 | Q2 | Q3 | 変化 | ステータス |
|---|---|---|---|---|
| クラウド費用（対予算） | n/a | 42,800ドル（予算39,300ドル） | 予算比9%超過 | 要対応：ログ保存量が想定以上に増加 |
| 稼働率SLA（99.9%） | n/a | 違反2件（47分、22分） | n/a | 要対応：2件のインシデントでSLA違反 |
| チケット件数 | 16,430件 | 18,400件 | +12% | 注視：人員横ばいで需要増 |
| 初回応答時間の中央値 | 3.1時間 | 2.4時間 | -0.7時間 | 順調：7月に週末シフト追加 |
…（一部省略）出力例：文言は実行ごと・モデルごとに変わります
別のツールで使う場合は、出力の指示だけを差し替えます。
使い先 | 表の指示をこれに置き換える |
|---|---|
ExcelやGoogleスプレッドシート | 「ヘッダー行付きのCSVで出力。区切りはカンマ、数値に桁区切りは入れない」 |
スクリプトやAPI | 「JSON配列のみを出力。各オブジェクトのキーは metric（文字列）、q2（数値またはnull）、q3（数値）、unit（文字列）」 |
スライド | 「最大5行×4列。短いラベルのみ、文章は書かない」 |
ポイント：JSONをプログラムで処理するなら、APIのJSONモードや構造化出力（structured output）を使いましょう。例で形式を固定する方法は ゼロショット・ワンショット・フューショット で解説しています。
モデルが写した数値はすべて検証する
モデルはたいてい数値を正しく写すため、人は確認をやめ、誤りがすり抜けます。注意すべきは転記ミス（桁の脱落、行の入れ替わり）と派生値のミス（割合や合計の計算誤り）です。LLM の仕組み で解説したとおり、モデルは文章を予測するもので、計算するわけではありません。表を作った直後に、同じチャットで次を実行します。
今作った表をレポートと照合してください。
表の数値1つにつき1行で出力してください。
セル | 表の値 | レポートからの原文引用 | 一致？（はい／いいえ／派生）
- 「派生」＝レポートになく計算で求めた数値。計算式を示す。
- コードを実行できる場合は、派生値をすべてコードで再計算する。
最後に「修正：」に続けて変更が必要なセルを挙げる。なければ「なし」。| セル | 表の値 | レポートからの原文引用 | 一致？ |
|---|---|---|---|
| チケット件数・Q3 | 18,400件 | 「チケット件数は18,400件」 | はい |
| クラウド費用・変化 | 予算比9%超過 | 「予算39,300ドルを9%超過」 | はい |
| 初回応答時間・変化 | -0.7時間 | （なし） | 派生：2.4 - 3.1 = -0.7 |
…（一部省略）
コード検証：(42800 - 39300) / 39300 = 0.0891、つまり8.9%で「9%」と整合。
修正：なし出力例：文言は実行ごと・モデルごとに変わります
注意：自己チェックは証明ではありません。誤りを犯したモデル自身が確認しているからです。取締役会資料、請求書、契約書の主要な数値は、自分で照合するか表計算で確認してください。
学習を速める：文脈に沿った用語解説とセルフクイズ
2つのプロンプトで、チャットボットは学習パートナーになります。用語を出てきた文脈で説明させるもの（分野で意味が変わる用語は多いため）と、自分のノートからクイズを出させるものです。
用語を文脈の中で説明させる
次の文章を読んでいます。
"""
{用語を含む段落を貼り付け}
"""
この文章における「{用語}」の意味を説明してください。
- 平易な1文、この分野の具体例、似た用語と混同しやすい点を1つ。
私は {自分の背景。例：決済の経験がないサポートエンジニア} です。「同じ Idempotency-Key ヘッダーを付けてリクエストを再試行してください。サーバーは最初のリクエストの結果を24時間保存して返すため、決済が二重に請求されることはありません」というAPIドキュメントと、用語 Idempotency-Key を指定した場合：
平易な意味：Idempotency-Key（冪等キー）は、同じリクエストの繰り返しをサーバーが見分け、一度だけ処理するための一意のIDです。
具体例：キー 7f3a… を付けて「50ドルを請求」を送信し、通信が切れて同じキーで再試行しても、サーバーは二重に請求せず最初の結果を返します。
混同しやすい点：APIキーのような認証用キーではありません。識別するのは1つの操作なので、新しい決済には新しいキーを使います。出力例：文言は実行ごと・モデルごとに変わります
自分のノートからセルフクイズを作る
自分で答えるまで正解は見ないこと。1問ずつ出題させます。{notes} を自分の教材に置き換えてください。
以下は私の学習ノートです。
"""
{notes}
"""
このノートの内容で、1問ずつクイズを出してください。
- 選択肢A〜Dの選択問題にする。ノートの内容だけを根拠にする。
- 誤答の選択肢は、冗談ではなく、ありがちな間違いにする。
- 私の解答を待ち、正誤を伝え、2文で解説し、根拠となるノートの行を引用する。
- 5問終わったら、間違えたトピックを一覧にして復習できるようにする。
では第1問から始めてください。第1問（全5問）
ノートによると、インシデント管理の主な目的は何ですか。
A) すべてのインシデントの根本原因を特定する
B) 通常のサービスをできるだけ早く復旧する
C) 今後のインシデントをすべて防止する
D) すべてのユーザー要求をチケットシステムに記録する
A、B、C、Dのいずれかで答えてください。出力例：文言は実行ごと・モデルごとに変わります
選択問題：信頼できる答えを得るには
モデルは見た目ほど選択問題に強くありません。Zheng ほか（2023年） は20種類のLLMを検証し、内容に関係なく特定の選択肢記号（Aなど）を好む「選択バイアス」を確認しました。Pezeshkpour と Hruschka（2023年） は、選択肢の順序を入れ替えるだけで約13%〜75%の精度差が生じることを示しました。有効な習慣は4つです。
- 答える前に推論させる。推論（reasoning）モデルは内部で行っています。通常のチャットモデルでは、段階的に解く指示が今も有効です（Kojima ほか、2022年）。
- すべての選択肢を評価させる。選択肢ごとの判定で推論の誤りが見えます。
- 並べ替えて再質問する。順序で選ばれる内容が変わるなら、モデルは推測しています。
- 公式を与え、計算をモデルの頭の外に出す。ルールを示し、先に式を書かせるか、コードを実行させます。PAL の論文（Gao ほか、2022年）は、インタプリタに計算させる方が文章で解くより正確だと示しました。
次の選択問題に答えてください。
問題：月間稼働率99.9%のSLAが設定されたサービスがあります。30日の月に許容される最大停止時間はどれですか。
A) 4.32分
B) 43.2分
C) 1.44分
D) 7.2時間
参考ルール：許容停止時間 = 期間の総分数 ×（1 - SLA）
1. ステップごとに解く。計算する前に式を書く。
2. 次に、選択肢を1行ずつ評価する：正しいか誤りか、その理由。
3. 最終行：「答え：<記号>」1. 30日の総分数：30 × 24 × 60 = 43,200分
許容停止時間：43,200 ×（1 - 0.999）= 43,200 × 0.001 = 43.2分
2. A) 4.32分：誤り（99.99%の場合）。
B) 43.2分：正しい。
C) 1.44分：誤り（30日ではなく1日分）。
D) 7.2時間：誤り（99%の場合）。
答え：B出力例：文言は実行ごと・モデルごとに変わります
続いて、選択肢を並べ替えた同じ問題を新しいチャットに貼り付けます。答えは記号ではなく内容に従うはずです。
契約書・社内規程の文書分析
注意：これは法的助言ではありません。モデルは条項を読み違えたり、存在しない法律を説明したりします。Mata v. Avianca 事件（米ニューヨーク南部地区連邦地裁、2023年6月）では、ChatGPTが捏造した判例を引用した弁護士らに5,000ドルの制裁金が科されました。AIは質問の準備に使い、答えは弁護士に求めてください。
リスクの低い順に、条項の理解、要注意条項の洗い出し、弁護士レビュー用の初稿作成の3つです。
条項を平易な言葉で説明させる
この契約条項を、{自分の立場。例：ベンダー契約に署名するIT部門のマネージャー} 向けに平易な言葉で説明してください。
条項：
"""
{条項を貼り付け}
"""
次の3部構成で答えてください。
1. 何が書かれているか（法律用語を使わずに2文で）。
2. 誰が、何を、いつまでにしなければならないか。
3. 自社にどう影響しうるかを示す、現実的なシナリオ。
条項が法的に有効かどうかについての意見は述べないでください。SaaS契約によくある自動更新条項（期間満了の90日前までに書面通知がなければ12か月ごとに自動更新）の場合：
1. 契約は期間満了ごとに自動で12か月延長されます。止めるには、終了の90日前までに書面で通知が必要です。
2. どちらかの当事者が終了日の90日以上前に書面で通知しない限り、新たな12か月が始まります。
3. シナリオ：期間が12月31日に終わり、10月中旬に乗り換えを決めた場合、期限の10月2日を過ぎているため、さらに1年分の費用が発生します。出力例：文言は実行ごと・モデルごとに変わります
再確認すべき条項を洗い出す
弁護士への質問を準備するのを手伝ってください。あなたは法的助言をするわけではありません。
<contract>
{契約書を貼り付け}
</contract>
私たちは{顧客／ベンダー／従業員}の立場です。私たちの側から表を作成してください：
条項 | 原文引用（50字以内） | 私たちにとってのリスク | 重大度（高／中／低） | 確認すべき質問
- 本文に存在する条項だけを、原文どおりに引用する。
- 高 = 多額の費用、データ、または契約から抜け出す自由を失う可能性があるもの。
その後、一般的にあるはずなのに見当たらない保護条項を挙げてください。| 条項 | 原文引用 | 私たちにとってのリスク | 重大度 | 確認すべき質問 |
|---|---|---|---|---|
| 3.2 変更 | 「ベンダーは、更新後の規約を自社ウェブサイトに掲載することにより、いつでも本規約を変更できる」 | 同意も通知もなく条件が変わりうる | 高 | 変更時の書面通知と、こちらの解約権を求められるか |
| 9.1 責任 | 「責任の上限は、請求前3か月間に支払われた料金を超えないものとする」 | データ漏えいの損害は3か月分の料金をはるかに超えうる | 高 | 上限を12か月分にし、データ漏えいを上限の対象外にできるか |
| 12.1 更新 | 「12か月ごとに自動的に更新される」 | 90日前の通知期限は見落としやすい | 中 | 通知期限を30日にできるか、ベンダーから事前連絡をもらえるか |
見当たらない条項：契約終了後のデータ返還・削除、稼働率の保証。出力例：文言は実行ごと・モデルごとに変わります
合意事項から初稿を作り、弁護士に渡す
NDAのような一般的な文書なら、合意事項から実用的な初稿を作れます。前提を置いた箇所を明示させると、弁護士のレビューが重要な点に集中します。
以下の合意事項をもとに、双方向の秘密保持契約書（NDA）の初稿を作成してください。
- 当事者：{A社} と {B社}
- 目的：{例：ソフトウェア開発における協業の検討}
- 契約期間：{例：2年}。秘密保持義務は終了後 {例：3年間} 存続
- 準拠法：{法域}
- {その他の合意事項}
平易な日本語で条番号を付けてください。一覧にない前提を置いた箇所は［要確認：理由］と記し、最後にすべて一覧にしてください。
この初稿は、使用前に資格を持つ弁護士がレビューします。秘密保持契約書
第1条（目的）…（一部省略）
要確認項目：
1. 口頭で開示した情報に書面確認を要するか。
2. 従業員だけでなく業務委託先にも開示できるか。
3. 紛争時の管轄裁判所または仲裁地。出力例：文言は実行ごと・モデルごとに変わります
よくある失敗と安全のためのチェックリスト
失敗の多くは、決まった習慣から生まれます。どれも簡単に直せます。
よくある失敗 | 起きること | 対策 |
|---|---|---|
読み手を決めずに「要約して」 | 無難な要約になり、不要な細部が残る | 読み手・長さ・形式・焦点を指定する |
空欄をモデルに埋めさせる | 担当者・期限・数値が捏造される | 「記載がなければ未定／n/aと書く」と指示する |
計算された数値を信じる | 割合や合計が間違う | 引用と照合し、コードや表計算で再計算する |
契約レビューを法的助言とみなす | 義務の見落としや読み違い | 質問の準備に使い、判断は弁護士が行う |
機密ファイルを個人アカウントに貼る | 会社が承認していない形でデータが扱われる | 承認済みの業務用ツールを使い、識別情報を伏せる |
プライバシーについては送り先を確認しましょう。たとえば OpenAI は、ChatGPT Business、Enterprise、APIのデータは既定で学習に使わず、個人アカウントは「設定 > データコントロール」でオフにする必要があると説明しています。迷ったら［取引先A］のようなプレースホルダーを使いましょう。AIの要約を転送する前には最終確認を行います。
要約を共有する前に、文書と照合してください。
1. 要約の中で、文書が直接裏付けていない記述をすべて挙げ、理由を説明する。
2. 文書にある重要な点のうち、要約から抜けているものを挙げる。
3. 修正が必要なら修正版の要約を示す。不要なら「変更なし」と答える。1. 裏付けのない記述：なし。
2. 抜けている点：初回応答時間が3.1時間から2.4時間に短縮、CSATは91%で横ばい（指定の焦点外）。
3. 変更なし出力例：文言は実行ごと・モデルごとに変わります
よくある質問
ChatGPTやClaudeには、どのくらい長い文書を貼り付けられますか？
現在のモデルは数十万トークン規模を受け付け、長いレポートや契約書も収まります（上限はモデルやプランで異なります）。文書を先に置き、セクションごとの処理と引用を求めましょう。文書ライブラリ全体が対象なら検索（リトリーバル）を使います。ナレッジベース・チャットボット（RAG）の構築 をご覧ください。
契約書をAIチャットボットにアップロードしても安全ですか？
アカウントと社内ルール次第です。主要ベンダーの業務用プランやAPIは既定で学習に使わないのが一般的ですが、個人アカウントは限りません。承認済みツールを使い、不要な情報は削除してください。
AIが表の数値を間違えるのはなぜですか？
モデルはテキストを1トークンずつ生成しており、計算はしていません。転記はたいてい正確ですが、割合・合計・差分で誤りが出ます。式を書かせ、コードや表計算で再計算しましょう。
参考資料
- Learn Prompting: Text Summarization
- Learn Prompting: Table Generation
- Learn Prompting: Multiple Choice Questions
- Learn Prompting: Study Buddy
- Learn Prompting: Legal Documents
- Anthropic: Prompting best practices（長文コンテキストのプロンプト）
- Liu ほか（2023年）Lost in the Middle: How Language Models Use Long Contexts
- Zheng ほか（2023年）Large Language Models Are Not Robust Multiple Choice Selectors
- Pezeshkpour & Hruschka（2023年）LLMs Sensitivity to the Order of Options in Multiple-Choice Questions
- Kojima ほか（2022年）Large Language Models are Zero-Shot Reasoners
- Gao ほか（2022年）PAL: Program-aided Language Models
- Mata v. Avianca, Inc. 制裁に関する意見と命令（2023年）
- OpenAI: How your data is used to improve model performance
Prompt Engineering ガイド 全記事
← 前の回：第6回：技法の組み合わせ・プライミング・反復改善 · 次の回：第8回：メール・ブログ・マーケティングのプロンプト →
第1〜6回は前の回を前提にしているため、順番にお読みください。第7〜10回は基礎を押さえた後なら、どの順番でも読めます。
この分野でお困りですか？
本記事に関連する iPlus Solution のサービスをご覧ください。
