- 公開日
一度よい回答が出た依頼文でも、資料が欠けたり、別の書き方になったりすると同じように使えるとは限りません。失敗に備えるには、欲しい答えに加えて、分からない項目の表示、確認先、続けてよい部分を指定します。そのうえで条件を変え、必要な情報を取り出す動作と、勝手に補わない動作の両方を確かめます。
「前はできた」の条件をほどく
回答が変わる理由は、依頼文の良し悪しだけではありません。OpenAIの評価設計ガイドは、同じ入力でも生成結果が変わり得ると説明しています。一回の成功は、その入力と環境で使える回答が得られた記録であって、どんな資料にも使えることの確認ではありません。
業務では、入力も少しずつ変わります。前の請求書には支払期限が明記され、今回は記載がないかもしれません。画像が不鮮明になった、複数ページのうち一枚が抜けた、会話履歴に別案件の条件が残っている、といった違いも候補です。モデルや利用設定が変わった場合も、以前の結果と同じ条件として扱えません。
こうした違いを確かめず「もっと正確に」と書き足すと、何を直そうとしているのかが曖昧なままになります。まず、元資料に答えがあるのに読み違えたのか、資料にない答えを作ったのか、必要な出力形式から外れたのかを分けます。読み取れない画像なら鮮明な資料の入手が必要で、欠けた期限なら確認先への照会が必要です。
ここでいう再現性は、文章を一字一句同じにすることではありません。言い回しが変わっても、請求金額が一致し、期限がないときは補わず、その後の確認へ回せることを重視します。何が同じなら仕事に使えるかを、先に決めておきます。
欠けた請求書で、期待する動作を比べる
架空の請求書に、次の内容だけが記載されているとします。これは依頼文を説明するための資料で、実在の取引やモデルの実測結果ではありません。処理は社内で確認する一覧の作成までとし、会計登録や支払いは行いません。
- 請求元：青葉企画
- 請求番号：A-104
- 請求日：2026年10月1日
- 請求金額：33,000円（税込）
- 支払期限：記載なし
元の依頼は「この請求書から請求元、請求番号、金額、支払期限を正確に整理してください」です。四つの項目は分かりますが、期限を見つけられないときの動作は示していません。「正確に」は目的を伝える語として使えても、空欄をどう扱うかまでは決められません。お願いの文と作業条件を分けて書く考え方は、プロンプトを作業条件として設計する――入力・制約・出力のつなぎ方で扱っています。
このとき避けたい出力の例は、「支払期限：2026年10月31日」です。月末という慣行を当てはめたとしても、この請求書からは裏付けられません。実際の期限が別の契約に書かれている可能性は残るため、「期限は決まっていない」と言い換えるのも行き過ぎです。
改善する依頼は、たとえば次のように書けます。
この請求書だけを根拠に、請求元、請求番号、請求金額、支払期限を整理してください。
書かれていない項目は「未確認」とし、理由を添えてください。
読めない場合も推測で補わず、その箇所を示してください。
確認できた項目は残してください。
支払期限が確認できない場合は「社内の経理担当へ確認」と記してください。
確認依頼の送信や登録、支払いは行わないでください。この依頼の意図は、答えを埋めることから、根拠のある欄と確認が必要な欄を分けることへ、完了条件を変えることです。「経理担当」はこの架空業務で指定した確認先であり、請求書から抽出した情報ではありません。実務では社内の手順で定めた窓口へ差し替えます。連絡先が分からなければ、AIに担当者名やメールアドレスを作らせません。
未確認を残した出力は、失敗とは限らない
改善後に期待する出力は、次のようになります。これは実際に生成して得た結果ではなく、原資料と照らして定めた期待例です。
| 項目 | 値 | 根拠・次の確認 |
|---|---|---|
| 請求元 | 青葉企画 | 請求元欄の記載 |
| 請求番号 | A-104 | 請求番号欄の記載 |
| 請求金額 | 33,000円（税込） | 請求金額欄の記載 |
| 支払期限 | 未確認 | 提示資料に記載なし。社内の経理担当へ確認 |
期限欄を未確認にしたからといって、抽出作業全体を失敗と扱う必要はありません。この業務の目的が確認用の一覧なら、不足が分かる形で残ることに意味があります。一方、その一覧だけで支払いの準備を確定するのは別の判断です。資料にない重要項目が埋まったとみなして先へ進めてはいけません。
Anthropicのハルシネーションを抑える指針も、不確かさを認める指示、資料に基づく回答、出典による照合を勧めています。同時に、対策をしても誤りが完全になくなるわけではなく、重要な情報は検証するよう求めています。「未確認と書いて」と加えたこと自体を、捏造防止の保証にはしません。
回答後は、請求元と番号を原文と見比べ、金額の税込表示が落ちていないかを確認します。期限については、提供された全ページの該当欄を見て、記載を見つけられない状態なのか、AIが記載を見落としたのかを分けます。別資料を確認する権限があれば参照し、なければ担当者へ必要な資料を求めます。未確認というラベルも、照合を終えた証拠にはなりません。
同じ目的のまま、条件を一つずつ変える
次は、成功しそうな資料だけでなく、判断の変わる資料を用意します。実データを使う場合は利用許可と情報管理の条件を先に確かめ、説明段階では架空の資料を使えます。比較では一覧作成という目的、出力項目、使うモデルと設定を揃え、まず資料の一条件だけを変えます。
期限が明記された資料なら、その日付が出ることを期待します。期限を削除した資料なら、他の三項目は残したまま期限を未確認にします。期限の文字を読み取れない状態にした場合は、記載なしではなく判読困難と説明する必要があります。異なる期限が二か所にあり、優先関係が分からなければ、どちらかを黙って選ばず矛盾を示して確認へ回します。
別の請求書のページが混ざり、どの取引の請求書か特定できない場合は、事情が変わります。期限の欠落なら他の項目を残して進められますが、対象を取り違えると一覧全体が誤るため、項目を混ぜて埋めず、先に対象の確認を求めます。一律に「不明なら止まる」と指示する必要はなく、欠けた範囲がどこまで結果に影響するかで、続けるか先に尋ねるかを分けます。
これらは、同じ「分からない」でも理由が違う入力です。理由を残すと、人は欠けたページを取り寄せるのか、鮮明な画像を求めるのか、請求元の説明を確認するのかを選べます。ただし、AIに照会先を表示させることと、実際に照会を送ることは分けて扱います。
依頼文の変更効果を比べる場合は、同じ資料を元の依頼と改善後の依頼へ渡す計画にします。入力もモデルも同時に変えると、何が違いを生んだか切り分けにくくなります。一つの資料を繰り返して出力の揺れを調べる確認と、別の資料で適用範囲を調べる確認も分けます。ここで述べた比較は未実施の計画です。
失敗を直しても、できていた部分を確かめ直す
判定では、元資料と値が一致すること、不足の理由が合っていること、確認先を勝手に増やしていないことを見ます。「何でも未確認にする」回答は補完を避けていても、書かれた項目を取り出せていないため、この業務では合格にしません。反対に、形式が整っていても期限を作れば不合格です。
修正後には、期限が書かれた通常の資料も再確認します。不足への対策を足した結果、確認できる日付まで未確認になるようなら、止める範囲を見直します。変更に使った資料だけでなく、別の架空資料でも確かめれば、特定の言い回しに合わせただけの修正を見つけやすくなります。
同じ不足が繰り返されるなら、依頼文へ注意書きを足す前に、資料の側を直せないかも考えます。支払期限の欄がない様式なら、請求書の受付時に期限を確認する手順を加える方が役立つ場合があります。
記録に残すのは、依頼文、資料の条件、利用した環境、期待結果、実際の回答、照合で分かった不一致、依頼文と資料のどちらを直したかです。確認できなかったものは合格へ含めず、理由を別に残します。小さな試行でよい結果が続いても、その範囲を超えた精度や完全性は約束できません。
日常の一覧作成なら、この程度の条件整理から始められます。出力を会計システムや支払いへ接続するなら、形式と意味の検査、操作権限、必要な人の承認を別に用意します。プロンプトを直すだけで、外部処理の許可や安全性まで得たことにはなりません。まず一つの困る失敗を選び、そのとき何を残し、誰へ何を確かめるかを書いてから、実際の資料と照合してください。
ロール指定で口調・観点・正確さがどう変わるかの確かめ方は「ロール指定で変わる口調・観点・正確さを分けて確かめる」、テンプレート運用の安定性からLLMを選ぶ方法は「業務要件とテンプレート運用の安定性でLLMを選ぶ」で解説しています。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
