プロンプト設計の修正を何回まで受けるか｜先に決めておく

2026年6月24日

丸山桃子

この記事のポイント

✓プロンプト設計の仕事で修正対応が無限に膨らむのを防ぐため
✓その前提になる合格基準の作り方を整理しました
✓修正と追加依頼の線引き

プロンプト設計の仕事で修正対応が終わらなくなる原因は、修正回数を決めていないことではありません。回数を決めていても終わらない案件はいくらでもあります。本当の原因は、「何をもって完成とするか」を決めずに始めていることです。

この記事では、プロンプト設計を請け負うときに、修正を何回まで受けるかをどう決めるか、そしてその回数が意味を持つために先に何を決めておく必要があるかを扱います。成果物の性質、合格基準の作り方、見積書への書き方、依頼を受け取った後の処理手順まで、受注後の実務として順番に整理します。

プロンプト設計の修正が、他の制作物より膨らみやすい理由

まず、なぜこの仕事だけ修正が終わらないのかを構造から見ます。原因は三つあり、どれも発注者の性格の問題ではありません。仕事の性質から来ています。

理由1：納品するのが「文章」ではなく「振る舞い」だから

バナーを納品するなら、納品物はその画像です。良し悪しの議論はあっても、モノは確定しています。プロンプトの場合、納品するのはテキストですが、評価されるのはそのテキストが生む出力です。つまり、納品物は静的なファイルなのに、検収の対象は動的な振る舞いになっている。

この構造だと、修正の起点が二つできます。プロンプトの記述そのものへの修正と、出力に対する不満から来る修正です。後者は入力データやモデルの状態によっても変わるため、切り分けをしないと、こちらの責任範囲を超えた修正まで抱え込みます。

理由2：発注者側に評価基準がないことが多い

プロンプト設計を外注する企業の多くは、その業務を初めて外注しています。だから「どうなったら完成か」を持っていません。持っていないまま検収に入るので、「もう少し自然にしてほしい」「うちの言い方と違う」といった主観的な指摘が繰り返されます。

これは発注者が悪いのではなく、基準を作る作業が発注の中に含まれていないだけです。だから、その基準作りを最初の工程として見積もりに入れるかどうかで、後の修正量が決まります。

理由3：同じプロンプトでも出力が毎回変わる

生成AIの出力には揺らぎがあります。同じプロンプトを5回実行すれば、5通りの文章が返ってきます。発注者が一度の実行結果だけを見て「うまくいかない」と判断すると、実際には十分な精度が出ているプロンプトでも修正扱いになります。

つまり、揺らぎを前提とした評価方法を最初に合意しておかないと、確率的な事象を毎回バグとして報告され続けます。これ、現場では本当によく起きています。

回数を決める前に、決めておくべき三つのこと

「修正は2回まで」と書いても、次の三つが決まっていなければ機能しません。逆に、この三つが決まっていれば、回数は自然に収まります。

決めること1：何を「1回の修正」と数えるか

最も揉めるのがここです。発注者は「気になった点を都度連絡すること」を修正と考え、受注者は「まとまった指摘をもとに直して再提出すること」を1回と考えている。この認識のずれが、回数制限を無意味にします。

決め方はシンプルです。「指摘をまとめて受け取り、修正版を提出するまで」を1回と定義する。修正版を出した後に新しい指摘が来たら、それが2回目です。この定義を先に共有しておくだけで、細切れの連絡が指摘の束にまとまります。

あわせて、指摘の受け取り方も決めます。チャットで思いついた順に流れてくる形だと、まとめる作業がこちらの負担になります。指摘は一つのシートかドキュメントに集約してもらう。この一手間を最初に頼んでおくと、後の工数がはっきり減ります。

決めること2：何が「修正」で、何が「追加依頼」か

線引きの基準は、合意した仕様の範囲内かどうかです。範囲内で期待どおりに動かないなら修正。範囲外の要求なら追加依頼です。

プロンプト設計の場合、追加依頼になりやすいのは次のようなものです。対象とする入力の種類が増える、出力の形式が変わる、使うモデルが変わる、想定していなかった業務が対象に加わる、多言語対応が加わる。これらはどれも、設計をやり直す規模の変更です。

線引きを書面にしておかないと、「フォーマットを表から箇条書きに変えてほしい」という一言が、無償の修正として処理されます。仕様変更なのか不具合なのかを、依頼を受けた時点で判定する習慣を持ってください。

決めること3：何をもって「完成」とするか

これが最も重要です。合格基準がないまま回数だけ決めると、上限に達した時点で「まだ使えないのに終わりにするのか」という話になり、結局こちらが折れます。

合格基準は、感想ではなく判定できる形で作ります。次の章で具体的に扱います。

合格基準の作り方。評価セットを最初に作る

プロンプト設計の検収を成立させる唯一の方法は、評価用の入力例と、その合否の判定基準を先に用意することです。ソフトウェアのテストケースと同じ考え方です。

手順1：実際の入力例を発注者から集める

架空の例では意味がありません。発注者の業務で実際に発生している入力を、20件前後集めます。問い合わせメールの文面、商品情報の元データ、会議メモ、顧客からの依頼文。ばらつきのある実物を集めることが重要です。

このとき、うまくいきそうな例だけを渡されることがあります。むしろ異常系を入れてもらってください。文字化けした入力、情報が足りない入力、想定外の依頼。ここで拾えなかったパターンが、納品後の修正依頼になります。

手順2：出力の合否を判定する項目を作る

集めた入力ごとに、出力がどうなっていれば合格かを箇条書きにします。判定は「良い・悪い」ではなく、有無で判定できる形にします。

たとえば商品説明文を生成するプロンプトなら、素材名が入っているか、サイズ表記があるか、禁止語が含まれていないか、指定の文字数の範囲に収まっているか、社名の表記ゆれがないか。こうした項目なら、誰が見ても同じ判定になります。

主観が入る項目、たとえば「ブランドらしい文体か」は、判定者を一人に固定してください。複数人が主観で判定すると、合格しない基準ができあがります。

手順3：合格ラインを割合で決める

揺らぎがある以上、全件合格は現実的な基準になりません。20件の入力例に対して、必須項目は全件を満たし、主観項目は8割を満たせば合格、という形で決めます。

この「割合で合格を定義する」ことを発注者に理解してもらう工程が、実は最も時間がかかります。ただ、ここを飛ばすと、残りの工程すべてが揉めます。生成AIの導入がうまくいかない企業の多くは、この評価の設計を飛ばしています。

McKinseyの調査（2026年1月公表）では、AIを定期的に業務利用する企業の割合は88%に達した一方、本番スケールに到達した企業はわずか23%。この65ポイントのギャップを埋めるカギが「プロンプト設計の型化」です。出典: uravation.com

試している企業は多いのに本番まで到達しない。この差は、プロンプトの巧拙よりも、評価と運用の型があるかどうかで生まれています。外注する側から見れば、評価の型を作れる相手は貴重です。だから、評価セットの作成を工程として見積もりに入れることは、値引きの理由ではなく差別化になります。

修正回数をどう決めるか

前提が整ったところで、回数の決め方です。

標準は2回。その理由

実務上の落としどころは2回です。理由は、修正の性質が回を追うごとに変わるからです。

1回目の指摘は、仕様の理解のずれが中心になります。想定していた業務の粒度が違った、出力形式の解釈が違った。ここは設計の修正で解けます。2回目の指摘は、細部の調整が中心になります。言い回し、語尾、項目の順番。ここも対応可能です。3回目以降に出てくる指摘は、多くの場合、発注者側の要望が変化したものか、評価者が交代したことによるものです。これは仕様変更なので、修正ではなく追加として扱うべき性質のものになります。

2回という数字自体に根拠があるというより、「設計の修正」と「細部の調整」の二段階で足りるという工程上の理由です。だから見積書には、回数だけでなくその趣旨も書いておくと納得されやすくなります。

回数ではなく期間で切る方法

もう一つの方法が、期間で区切るやり方です。「納品後14日間は修正対応を含む」という形にします。

この方式が向くのは、発注者側の運用がまだ固まっていない案件です。実際に業務で使ってみないと指摘が出せない場合、回数で切ると発注者は指摘を溜め込み、一度に大量の指摘を出してきます。期間で切ると、使いながら細かく相談してもらえるので、結果的に総工数が減ることがあります。

逆に、発注者側の関係者が多い案件では期間方式は危険です。関係者が順番に意見を出してくるため、期間内に終わりません。関係者が多い案件は回数方式、少ない案件は期間方式、と使い分けてください。

上限に達した後をどう扱うか

上限に達したら終わり、では実務が回りません。上限後の扱いを最初から決めておきます。方法は三つあります。

一つは、追加分を時間単価で受ける方式。作業時間を記録して精算します。もう一つは、月額の保守契約に切り替える方式。継続的に使うプロンプトなら、こちらが双方にとって合理的です。三つ目は、次のフェーズとして再見積もりする方式。仕様変更の規模が大きい場合はこれになります。

重要なのは、上限に達したときに初めて条件を話し始めないことです。最初の契約書に「上限を超えた分は時間単価で対応します」と書いておけば、その時点での交渉が要りません。

見積書と契約書にどう書くか

書き方の型を示します。次の五つの項目を、見積書の備考か仕様書に入れます。

第一に、成果物の定義。「業務Aに対応するプロンプト一式（システムプロンプト、入力テンプレート、想定される例外への対応指示を含む）」といった形で、納品する範囲を書きます。

第二に、合格基準。「事前に合意した入力例に対し、必須項目を全件、主観項目を8割以上満たすことをもって検収完了とする」と書きます。

第三に、修正の定義と回数。「指摘をまとめて受領し、修正版を提出するまでを1回とし、2回までを本見積もりに含む」と書きます。

第四に、追加依頼の扱い。「対象業務の追加、出力形式の変更、使用モデルの変更は仕様変更として別途お見積もりします」と書きます。

第五に、モデル更新時の扱い。「提供元によるモデル更新に起因する出力の変化への対応は、保守の範囲として別途ご相談します」と書きます。ここは後述しますが、書いておかないと無償の永久保守になります。

こうした条件を文書として整える力は、案件の成否に直結します。社外文書の型を体系的に確認したい場合は、ビジネス文書検定の出題範囲が実務の下敷きになります。条件の書き方が整っているだけで、相手の社内での通り方が変わります。

修正回数を伝えるタイミングと言い方

条件をいつ伝えるかで、相手の受け取り方が変わります。結論から言うと、見積もりを出す段階で、金額と一緒に伝えるのが正解です。

受注が決まってから条件を出すと、後出しに見えます。納品直前に出すと、防衛線を張っているように見えます。見積書に最初から書いてあれば、それは条件の一部であって、交渉ではありません。

言い方も重要です。「修正は2回までです」と制限として書くと、相手は不安になります。「本見積もりには、評価セットに基づく修正対応を2回分含みます」と、含まれているものとして書く。同じ内容でも、制限の提示か、提供範囲の提示かで印象がまったく違います。

さらに一歩進めるなら、「なぜ2回で足りるのか」を短く添えます。「1回目で仕様の理解のずれを解消し、2回目で細部を調整する想定です。これを超える場合は、多くが仕様の追加にあたるため、あらためてご相談させてください」。この説明があると、上限に達したときの会話が楽になります。

回数を伝えることを申し訳なく感じる必要はありません。発注する側も、際限のない対応より、範囲が決まっているほうが社内で予算を組みやすい。範囲が明示されている見積書のほうが、実際には通りやすくなります。

修正が発生しにくいプロンプトの作り方

修正対応の設計と同じくらい重要なのが、そもそも修正が出にくい作り方をすることです。構造の作り方で、後の修正量は大きく変わります。

出力形式を機械的に検証できる形にする

出力を自由文で返させると、評価が主観になります。項目ごとに区切った形式で返させれば、抜けの検出が機械的にできます。商品説明なら、見出し、素材、サイズ、注意事項、といった項目に分けて出力させる。分けておけば、「素材が抜けている」という指摘が「この項目が空だった」という事実になり、対応が明確になります。

自由文が必要な業務でも、内部的には項目に分けて生成し、最後に結合する構成にできます。この一手間が、検収の議論を減らします。

判断基準をプロンプトの中に文章で書く

「自然な文章にしてください」ではなく、「一文は60文字以内、専門用語には初出で短い説明を添える、断定を避ける表現は使わない」と条件を書く。条件が書かれていれば、発注者からの指摘があったときに、その条件を追加すればよいことになります。

条件が書かれていないプロンプトは、修正のたびに全体を書き直すことになります。条件が並んでいるプロンプトは、条件を足し引きするだけで直せます。保守性がまったく違います。

業務の文脈を、プロンプトの外に切り出す

同じプロンプトでも、業務の文脈が共有されていないと期待どおりに動きません。この点は現場でよく見落とされています。

100社以上の研修・コンサル経験から構成した想定シナリオですが、ある製造業の企画部門では、部長が個人的にChatGPTを活用して月20時間の資料作成時間を削減していました。ところが他のメンバーに「同じプロンプトを使って」と共有したところ、誰も同じ品質のアウトプットを出せなかった。原因はシンプルで、プロンプトだけを渡しても「業務の文脈」が共有されていなかったからです。出典: uravation.com

納品するときは、プロンプト本体と、業務の文脈を書いた前提資料を分けて渡す。前提資料には、対象業務、想定する利用者、入力データの出どころ、禁止事項を書きます。この資料があると、発注者側の別の担当者が使っても結果が安定し、「人によって結果が違う」という種類の修正依頼が減ります。

納品物一式に何を含めるか

修正対応を減らすうえで効くのが、納品物の構成です。プロンプトのテキストだけを渡すと、運用の中で必ず質問と修正が発生します。次の五点をセットで渡してください。

第一に、プロンプト本体。バージョン番号を付けます。第二に、業務の前提資料。前述のとおりです。第三に、評価セットと判定結果。どの入力例に対してどう判定したかの一覧です。第四に、想定される例外への対処手順。入力が不足しているとき、想定外の依頼が来たときにどうするかを書きます。第五に、変更履歴。何をなぜ変えたかの記録です。

この五点があると、発注者側で自走できる範囲が広がります。自走できれば、細かい相談が減ります。一見すると納品の手間が増えますが、修正対応の総量では確実に減ります。

なお、この納品物一式は、次の案件の提案資料としても機能します。同じ形式で納品している実績があること自体が、進行の予測可能性を示す材料になるからです。

修正依頼を受け取ったときの処理手順

依頼が来てから直し始めるのではなく、先に分類と切り分けをします。この手順を踏むかどうかで、修正にかかる時間が大きく変わります。

手順1：指摘を分類する

受け取った指摘を、四つに分類します。仕様の範囲内の不具合、仕様の解釈のずれ、仕様変更、AIの揺らぎによる単発の事象。分類してから返信すると、話が整理されます。

分類の結果は、修正に入る前に相手に共有します。「いただいた12件のうち、9件は今回の修正で対応し、2件は仕様変更にあたるため別途ご相談、1件は再実行で解消することを確認しました」という返し方をする。この一通で、無償で抱え込む範囲が確定します。

手順2：再現させる

指摘された事象を、自分の環境で再現します。再現しなければ、原因は入力データか実行環境にあります。プロンプト自体は正しく、発注者の使い方に原因があるケースは珍しくありません。

再現の記録は残しておきます。「同じ入力で10回実行し、指摘された現象は1回だけ発生しました」という記録は、揺らぎの説明に使えます。

手順3：原因を切り分ける

原因は四つのどれかです。プロンプトの記述、入力データ、モデルの特性、期待値の設定。切り分けずに直すと、プロンプトが不要に複雑になり、次の修正がさらに難しくなります。

とくに多いのが、期待値の設定に原因があるケースです。発注者が期待している出力が、そもそもそのモデルの得意分野から外れている。この場合、プロンプトをいくら直しても解決しません。モデルを変える、業務側の運用を変える、という提案が必要になります。この提案ができるかどうかが、プロンプト設計の仕事の本質的な価値です。

手順4：直した内容を記録する

何をどう直したかを、一行でよいので残します。プロンプトはテキストなので、変更の履歴が残りにくい。バージョンを分けて保存し、変更点をメモしておくと、後で「前のほうが良かった」と言われたときに戻せます。

モデルが更新されて出力が変わったときの扱い

これは受注後の実務で必ず遭遇します。提供元がモデルを更新すると、同じプロンプトでも出力の傾向が変わります。ときには、指定していた出力形式を守らなくなることもあります。

これを「納品物の不具合」として無償で直し続けると、永久保守になります。契約の時点で、モデル更新に起因する変化は保守の範囲であることを明記してください。そのうえで、保守を月額で受けるか、都度対応にするかを決めます。

保守を受ける場合、やることは決まっています。定期的に評価セットを流して合格率を確認する。合格率が落ちていたらプロンプトを調整する。この作業を月次で回す契約にすると、双方にとって予測可能な関係になります。継続案件の作り方については、Webマーケティングフリーランスで海外ノマド！年収、スキル、成功への道で扱われている、単発案件を継続契約に変えていく手順が参考になります。

修正にかかった時間を必ず計測しておく

回数の設定が妥当だったかどうかは、実測しないと分かりません。案件ごとに、修正対応にかかった時間を工程別に記録してください。指摘の整理、再現の確認、原因の切り分け、実際の修正、再提出と説明。この五つに分けて記録します。

記録すると、時間を食っている工程が見えます。多くの場合、実際の修正作業よりも、指摘の整理と再現の確認に時間がかかっています。ここが分かれば、次の案件で「指摘は一つのシートにまとめてください」「発生した入力と実行日時を添えてください」と最初に頼む理由が説明できます。

記録は、次の見積もりの根拠にもなります。「前回の同種案件では、修正対応に想定の倍の時間がかかりました」という事実があれば、次の見積もりで工数を増やす説明ができます。感覚で「今回は多めに」と積むより、記録に基づいた説明のほうが通ります。

また、修正対応が想定を大きく超えた案件は、原因を振り返ってください。合格基準を作らずに始めた、評価セットの入力例が少なすぎた、発注者側の関係者が想定より多かった。原因はたいてい、契約前の準備段階にあります。修正が膨らむ案件は、修正の場面で失敗しているのではなく、始まる前に失敗しています。

揉めやすい場面と、そこでの言い方

現場で衝突しやすい場面を三つ挙げ、どう返すかを書きます。

一つめは、「まだ完成していないのに修正回数の上限と言われても困る」と言われる場面。ここで回数の話を続けると平行線になります。返すべきは合格基準の話です。「事前に合意した評価セットでは合格ラインを満たしています。今回のご指摘は評価項目に含まれていないため、項目を追加する形でご相談させてください」と、判定の話に戻します。

二つめは、「一度実行したらおかしな出力が出た」という報告。ここでは、揺らぎの説明を先にします。「同じ入力で複数回実行した結果を共有します」と記録を出す。感覚の話を、確率の話に移します。

三つめは、担当者が交代して指摘がやり直しになる場面。これは仕様変更として扱う正当な理由があります。「前任の方と合意した基準はこちらです。基準を見直す場合は、あらためてお見積もりします」と、合意文書を根拠に線を引きます。合意文書がないと、この場面では必ず負けます。

いずれの場面でも、感情ではなく合意文書と記録で話す。それだけで、対立ではなく調整になります。

発注する側の事情を知っておくと、線が引きやすい

在宅・業務委託の市場を20年運営してきた立場から見ると、修正が膨らむ案件には共通点があります。発注者側の担当者が、社内で説明責任を負っているケースです。

担当者は、上司や現場から「AIを入れたのに使えない」と言われることを恐れています。だから、些細な違和感でも潰しておきたくなる。この心理を理解していると、指摘の受け止め方が変わります。修正を減らすために有効なのは、拒否することではなく、担当者が社内で説明できる材料を渡すことです。評価セットの合格率、揺らぎの実測結果、対応した項目の一覧。これらを整理して渡すと、担当者はそれを社内で使えるので、細かい指摘が減ります。

もうひとつ、長く続く人ほど、修正対応を「削るべきコスト」ではなく「関係を作る工程」として扱っています。ただし無償で抱え込むという意味ではありません。範囲を明示したうえで、その中では丁寧にやる。範囲外は堂々と見積もる。この線引きが明確な人ほど、次の依頼が来ています。

そして手数料の話です。同じ予算でも、間に仲介手数料が乗るかどうかで、受け手の手取りは変わります。手数料0%の直接取引なら、発注する側は同じ予算でより多くを依頼でき、受ける側は同じ金額でも手取りが厚くなる。修正の工数を吸収する余力は、この差から生まれます。運営者として見てきた限りでは、手取りに余裕がある人ほど、修正対応で無理な線引きをせずに済み、結果として関係が長く続いています。