AI業務活用支援の修正を何回まで受けるか｜先に決めておく

AI業務活用支援の仕事で消耗する原因は、技術力の不足ではありません。「どこまでが修正で、どこからが新しい依頼か」を、着手する前に文章にしていないことです。この分野の成果物は形を持たないものが多く、しかもAIの出力は毎回わずかに変わる。だから「まだ思っていたのと違う」がいつまでも成立してしまいます。この記事では、修正の範囲を先に決めるための線引きの基準と、それを契約書と連絡文にどう落とし込むかを、順番に書いていきます。

AI業務活用支援で修正が無限に増える3つの構造

まず、なぜこの分野で修正が膨らむのかを構造として押さえます。原因が分かると、対策が具体的になります。

成果物が形を持たない

Webサイトなら画面があります。印刷物なら現物があります。しかしAI業務活用支援の成果物は、業務フローの設計、プロンプトの設計、ツールの初期設定、手順書、そして社内で使える状態そのものです。手に取れるものが少ない。

手に取れないものは、完成の定義が曖昧になります。「使える状態になった」の判定基準を書いていないと、依頼者が「まだ使いにくい」と言った瞬間に、それが未完成の証拠として扱われます。これ、知らない人が本当に多いのですが、成果物が無形であるほど検収条件を文章にしておく必要が高まります。

AIの出力は毎回同じにならない

生成AIを使う支援では、同じ入力でも出力が揺れます。この性質を依頼者が理解していないと、「昨日はうまくいったのに今日はおかしい」という指摘が修正依頼として飛んできます。

これは不具合ではなく仕様です。しかし「仕様です」とだけ返すと、相手には突き放されたように聞こえます。必要なのは、出力の揺れをどう扱う設計にしているか、揺れが許容範囲を超えた場合に何を調整するかを、あらかじめ説明しておくことです。ここを説明していないと、揺れの調整が無限の無償作業になります。

依頼者側で期待が定義されていない

AI導入の相談は、多くの場合「何がどう改善されると成功なのか」が決まらないまま始まります。経営層は工数削減を期待し、現場は作業の楽さを期待し、情報システム部門は安全性を気にしている。この3者の期待が一致していない状態で成果物を出せば、誰かは必ず不満を持ちます。

そしてその不満は、修正依頼という形で作り手のところに届きます。本来は依頼者側の合意形成の問題なのに、技術的な修正の問題として扱われる。この誤配を防ぐには、着手前に成功条件を書き出し、関係者の合意を取っておく工程が要ります。

修正と仕様変更を、言葉で分ける

修正対応の話は、この線引きから始まります。線引きがないと、どんな回数制限を設けても意味がありません。

修正にあたるもの

合意した仕様に対して、成果物が達していない状態を直す作業です。手順書の誤記、設定値の入力ミス、想定していた入力に対して出力が明らかに条件を満たしていない場合。これらは無償で直します。当然の作業であり、回数に数えるべきものでもありません。

仕様変更にあたるもの

合意した内容そのものを変える依頼です。対象業務の追加、利用するAIツールの変更、想定利用者の変更、出力形式の変更、連携するシステムの追加。これらは修正ではなく、新しい依頼です。

判断が難しく見えますが、基準は明確です。着手前に合意した文書に書かれていた条件か、書かれていなかった条件か。書かれていなかったなら仕様変更です。

迷ったときの判定基準

グレーな依頼は必ず出ます。そのときは「作業をやり直す起点がどこまで戻るか」で判定します。文言の調整だけで済むなら修正、設計から引き直す必要があるなら仕様変更。この基準を相手にも先に伝えておくと、依頼が来た時点で相手側も予想がつくようになります。

なお、法令上も発注者が受領後に不当なやり直しをさせることは制限されています。2024年11月に施行されたフリーランス保護新法では、特定受託事業者に対する取引で、正当な理由なく給付内容を変更させたりやり直させたりすることが禁止行為として定められています。つまり、合意していない作業を無償で押し付けられる筋合いは、そもそもないということです。制度の詳細は公正取引委員会の案内で確認できます。ただし、個別の案件が違反にあたるかどうかの判断は事情によって変わるため、深刻な事案では弁護士に相談してください。

支援の型ごとに、修正の意味は変わる

AI業務活用支援と一口に言っても、提供する内容によって修正の性質がまったく違います。型ごとに、何を修正の対象とするかを決めます。

業務の棚卸しと診断

現状の業務を洗い出し、AIで置き換えられる箇所を特定する工程です。成果物は分析結果の資料になります。ここでの修正は、事実誤認の訂正と、記述の粒度の調整までを範囲とします。

一方で、追加のヒアリング対象が増える、対象部署が増えるといった依頼は、調査そのものが増えるので仕様変更です。診断の工程は範囲が膨らみやすいので、着手前に対象部署と対象業務を列挙して確定しておきます。

プロンプト設計とテンプレート整備

実際に業務で使うプロンプトや入力テンプレートを作る工程です。ここが最も修正が膨らむ箇所になります。

有効なのは、評価の方法を先に決めることです。用意したテスト用の入力に対して、期待する出力の条件を書き出し、その条件を満たすかどうかで合否を判定する。この形にすると、「なんとなく違う」という指摘が「どの条件を満たしていないか」に変わります。条件を満たしているのに変えたいという要望が出たら、それは好みの問題であり仕様変更として扱えます。

ツールの選定と初期設定

利用するAIツールを選び、アカウントや権限、連携の設定を行う工程です。修正の対象は設定の誤りに限定します。ツール自体を別のものに変える判断は、選定のやり直しであり、明確に別の依頼です。

この工程では、選定の理由を文書に残しておくことが防御になります。何を基準に比較し、なぜそれを選んだかが書かれていれば、後から「別のほうがよかったのでは」と言われたときに、判断の前提が変わったのか、単に気が変わったのかを切り分けられます。

手順書の作成と社内研修

作った仕組みを社内の人が使える状態にする工程です。手順書の記述の分かりにくさを直すのは修正、対象読者を変える、別部署向けの版を追加するのは仕様変更です。

手順書は書式の整った文書であるほど質問が減ります。文書設計の作法を体系的に押さえるならビジネス文書検定の範囲が実務に直結します。

運用の定着支援

導入後、現場で使われる状態に持っていく工程です。ここは性質上、期間で契約するのが適しています。回数ではなく期間と対応範囲で区切り、期間中に発生した調整は範囲内、期間後は別契約とする形です。

この分野の仕事の広がりはAIコンサル・業務活用支援のお仕事で確認できます。支援の型が複数あることを理解して契約を分けるだけで、修正の扱いはかなり整理されます。

契約の前に決めておく6項目

ここからが実務の中心です。次の6項目を、着手前の書面に必ず入れます。

回数の単位

「修正3回まで」と書いただけでは足りません。1回の定義が必要です。まとめて届いた指摘をひとまとめで1回と数えるのか、指摘1件を1回と数えるのか。ここを決めていないと、必ず解釈がずれます。

実務的には、こちらが用意した確認シートに記入して返してもらう形にし、そのシート1通を1回と数えるのが扱いやすい形です。

期限

修正の受付期限を決めます。納品から一定の日数を過ぎた指摘は、修正ではなく別途の依頼として扱う。期限がないと、数か月前の納品物についての指摘が突然届きます。

対象範囲

どの成果物についての修正かを明記します。診断資料、プロンプト、設定、手順書。それぞれ別の工程なので、まとめて「一式」と書かず、成果物ごとに回数を割り当てます。

受け付け方法

どの経路で受け付けるかを決めます。チャットの流れの中で口頭のように指摘されると、記録が散らばって回数が数えられなくなります。指定のフォーマットで、指定の窓口に、という形に統一します。

超過した場合の扱い

回数を超えた依頼をどう処理するかを書きます。追加作業として見積もりを出す、という一文があるだけで、超過時のやり取りが交渉ではなく手続きになります。

検収の条件

最も重要な項目です。次の見出しで詳しく書きます。

検収条件を書けるかどうかが本丸

無形の成果物では、検収条件がすべてを決めます。書き方には型があります。

まず、成果物ごとに「完了とみなす状態」を文章で定義します。プロンプト設計なら「指定した10件のテスト入力に対し、あらかじめ合意した出力条件をすべて満たすこと」。手順書なら「対象部署の担当者が、手順書のみを見て一連の作業を完了できること」。設定なら「指定したアカウントで、指定した機能が利用可能な状態になっていること」。

次に、検収の期間を決めます。納品からいつまでに確認し、いつまでに合否を通知するか。期間内に通知がなければ検収完了とみなす、という条項を入れておくと、確認が止まったまま支払いが遅れる事態を防げます。

そして、不合格とする場合の要件を書きます。「どの条件を満たしていないか」を明示してもらう形にします。これを書いておかないと、「イメージと違う」という理由で検収が止まります。ここは実際に相談が多い箇所です。感覚的な理由での支払い保留は、そもそも認められる筋合いのものではありません。取引条件の明示や報酬の支払期日については、フリーランス保護新法で受領日から60日以内という枠が定められています。関連する働き方のルールについては厚生労働省の案内も参照できます。

書面に落とすときの実務

条件が決まったら、書面にします。口頭やチャットの合意だけで進めると、後から確認できません。

書面といっても、契約書の形式でなくても構いません。業務委託の内容を整理した確認書、あるいは見積書の備考欄でも、双方が内容を確認して記録に残っていれば機能します。重要なのは形式ではなく、次の3点が揃っていることです。何をもって完了とするか、修正の範囲と回数と期限、超過時の扱い。

なお、業務委託をする側には取引条件を書面や電磁的方法で明示する義務があります。相手から条件が示されない場合は、こちらから確認書を送って内容の確認を求める形にします。相手が発行しないから記録がない、という状態を放置しないことです。

修正回数を使い切ったあと、どう伝えるか

ここでの言い方ひとつで、その後の関係が変わります。断る言い方ではなく、選択肢を出す言い方にします。

型はこうです。まず、依頼内容を自分の言葉で要約して確認する。次に、それが合意した範囲のどこに位置するかを示す。そして、追加作業として進める場合の作業内容と所要期間を提示し、判断を委ねる。

「対応できません」で終えると拒否になりますが、「追加作業としてお見積もりを出しますので、進めるかどうかご判断ください」で終えると手続きになります。見積もりを出すこと自体が意思確認として機能するため、多くの場合はその場で決着します。相手が本当に必要としている修正であれば追加で発注されますし、必須でなければ取り下げられます。どちらでも問題は解決します。

避けたいのは、その場の空気で無償対応してしまうことです。一度無償で受けると、それが基準になります。基準になったものを後から戻すのは、最初に線を引くより何倍も難しくなります。

依頼者の立場によって、修正の出方が違う

同じ支援内容でも、依頼者がどの立場にいるかで修正の出方が変わります。相手を見て備えを変えます。

経営層が直接の窓口になっている場合、指摘は抽象度が高くなります。「もっと業務全体が楽になるようにしてほしい」といった形で届く。この場合に必要なのは、抽象的な要望を具体的な条件に翻訳して確認し直すことです。「業務全体」の範囲を業務名で列挙し、「楽になる」を測れる形に置き換えて合意を取り直します。

現場の担当者が窓口の場合、指摘は具体的ですが件数が多くなります。使い勝手の細部に関する要望が次々に出る。この場合は、要望を集約する期間を区切り、まとめて受け取る形にします。都度対応すると、いつまでも終わりません。

情報システム部門が窓口の場合、指摘は安全性と運用管理に集中します。権限設計、ログ、データの保存場所。この領域は着手前に条件を確定させておかないと、完成後に差し戻しが起きます。技術的な要件はヒアリングの最初に確認するのが鉄則です。

着手前のヒアリングで確定させる項目

修正の回数を決める作業は、実はヒアリングの精度に大きく依存します。範囲が曖昧なまま回数だけ決めても、範囲の外から次々に依頼が来るからです。着手前に確定させる項目を並べます。

対象業務。どの業務を対象とするかを、部署名と業務名まで書きます。「営業事務の効率化」ではなく「営業部の見積書作成と問い合わせ一次対応」というところまで具体化します。

利用者。実際に使うのは誰か。何人か。ITツールの習熟度はどの程度か。ここで研修の必要量が変わります。

判断者。成果物の合否を判断するのは誰か。これを1人に確定させることが、後の揉めごとを最も減らします。複数の関係者がそれぞれ意見を出す構造だと、修正は永遠に終わりません。

扱うデータ。どのデータをAIに入力する想定か。社外に出せないデータが含まれるか。この確認を最初にしないと、完成後に利用そのものが止まる事態になります。

既存の仕組み。すでに使っているツールやシステムとの関係。連携が必要か、並行運用か、置き換えか。

成功の定義。何がどうなったら成功と呼ぶのか。作業時間の短縮か、品質のばらつきの解消か、対応の速度か。ここを言語化していない案件は、ほぼ確実に検収で揉めます。

判断者を1人に決めることの効果

この6項目のうち、実務上いちばん効くのが判断者の確定です。組織の中で意見が割れると、その調整が作り手のところに修正依頼として降りてきます。本来は依頼者側で解決すべき合意形成が、外注先の作業として処理されてしまう。

対策は単純で、契約前に「成果物の合否を判断する方を1名ご指定ください」と依頼します。指定してもらったうえで、確認や指摘はその方を通して届けてもらう形にします。この一手間で、修正の往復は目に見えて減ります。

見積もりの内訳を工程で分ける

修正の扱いを整理する副次的な効果として、見積もりが説明しやすくなります。工程で分けた見積もりは、修正の対象範囲とそのまま対応するからです。

分け方の目安は6項目です。現状の把握と要件の整理、設計、構築と設定、検証、文書化、引き渡しと説明。それぞれに含まれる作業と、含まれる修正の範囲を並記します。

こうしておくと、依頼者から「この工程は自社でやれる」という提案が出ることがあります。これは歓迎すべき反応です。総額の押し合いではなく、作業配分の調整に話が移ったということだからです。文書化を社内で担当してもらう代わりに、設計と検証に工数を寄せるといった組み替えができれば、双方にとって合理的な形に着地します。

逆に、総額だけの見積もりを出すと、依頼者は検討のしようがありません。判断できないものに対しては、人は保留か拒否を選びます。

進行中の記録の残し方

契約書を整えても、進行中の記録がないと結局は主張の根拠を失います。記録の残し方には最低限の型があります。

まず、決定事項は必ず文字で残します。打ち合わせで決まったことは、その日のうちに要点を箇条書きにして送り、認識に相違がないかを確認します。返信がないまま進めると、後から「そんな話はしていない」となったときに立証できません。

次に、変更の履歴を1本の文書にまとめます。いつ、誰から、どんな変更依頼があり、どう扱ったか。この記録があれば、修正回数のカウントも自動的に成立します。別々のチャットやメールに散らばった状態だと、数えることすらできません。

そして、検証の結果を残します。テスト入力に対してどんな出力が得られ、合意した条件を満たしていたか。これは検収の根拠そのものです。後から「精度が落ちた」と言われたときも、納品時点の状態を示せます。

問い合わせ対応にAIを取り入れた事例では、こうした記録と標準化の効果が数字にも表れています。

住民や顧客からの問い合わせ対応にAIを活用している自治体や企業は増加傾向にあります。たとえば、住民票や住民税の問い合わせ、補助金についての質問などにチャットボットを導入する自治体が増えています。そうすることで、24時間いつでも問い合わせに対応することができるので、住民の満足度も高まります。また、職員の業務負担も軽減されると同時に、職員によって対応の仕方が異なるといったサービスの不均一も解消できます。 出典: nttdata-kansai.co.jp

対応のばらつきが解消されるという効果は、裏を返せば、導入前の業務にばらつきがあったということです。そのばらつきをどこまで整理するかが、支援の範囲であり、修正の範囲でもあります。

相談の現場で見られる、典型的なつまずき

行政書士として業務委託の相談を受ける中で、AI活用支援に関して繰り返し見られるつまずきが3つあります。いずれも匿名化した典型例として整理します。

1つ目は、成果物の定義を「AIを使って業務を効率化する」とだけ書いていた事例です。この書き方だと、効率化の程度が達成されたかどうかで争いになります。効率化は結果であって成果物ではありません。成果物は、設計書、プロンプト、設定、手順書といった具体物で書く必要があります。

2つ目は、社内の関係者が途中で増えた事例です。当初は1部署が窓口だったのに、途中から別部署の要望が入り、要件が膨らんだ。この場合、増えた部分は仕様変更にあたりますが、契約書に対象部署が書かれていないと主張の根拠がありません。対象範囲は部署名まで書きます。

3つ目は、AIの出力の揺れをめぐる事例です。導入後しばらくして「精度が落ちた」という指摘が入り、無償の調整を繰り返す状態になった。これは運用支援の契約を別に結ぶべき局面でした。納品後の継続的な調整は、制作の契約とは分けます。

法律はあなたの味方です。ただし、味方になってもらうには、何を合意したかが記録として残っている必要があります。

20年この市場を見てきた立場からの観察

運営者として長くこの市場を見てきた立場から言えば、AI活用支援で長く続いている人には共通点があります。修正の回数を厳しく制限しているのではなく、修正が発生しない設計をしている点です。

具体的には、着手前の確認に時間をかけています。誰が使うのか、どの業務なのか、成功をどう測るのか。ここを詰めるほど、後工程の手戻りが減ります。逆に、早く着手して形を見せながら詰めていくやり方は、この分野では往復が増えやすい。無形の成果物は、見せられても判断がつかないためです。

もうひとつの共通点は、依頼者側の業務そのものを整理する提案をしていることです。AIを載せる前に、業務のばらつきをそろえる。この順番を守ると、導入後の不満が大きく減ります。

既存の業務を見直し、標準化を図ることで「ムラ」を解消できます。たとえば営業成績の良い、経験豊富な営業マンの業務フローを情報として共有できれば、経験が浅い営業マンであっても効率的で効果的な営業が可能になります。また、製品やサービスのムラがなくなれば、顧客満足度も高めることができ、生産性向上にもつながります。こうした 環境を整備するためには、既存業務の見直しと効率化が重要 です。 出典: nttdata-kansai.co.jp

標準化されていない業務にAIを載せると、ばらつきがそのまま出力のばらつきとして表面化します。そして依頼者はそれを、AIの不具合として、つまり作り手の責任として認識します。この誤解を防ぐには、業務の標準化が前提であることを提案段階で説明し、標準化そのものを工程として見積もりに入れることです。

額面の高さより、余計なやり取りに時間を奪われないこと。中間の手数料が乗らない直接のやり取りでは、依頼者は同じ予算でより多くを頼めるようになり、受け手の手取りも厚くなります。手数料0%の取引が意味を持つのは、条件を直接詰められるという質の部分と組み合わさったときです。

隣接する職種の契約実務から学べること

AI業務活用支援の契約実務は、開発の受託と近い性質を持っています。要件定義、実装、検収という流れも、検収条件を先に決める作法も共通です。開発案件の契約の型はアプリケーション開発のお仕事の周辺で扱われている考え方が参考になりますし、技術職の仕事の構造はソフトウェア作成者の年収・単価相場からも読み取れます。

一方で、AI活用支援に固有の難しさもあります。開発なら「動く」「動かない」で判定できる部分が、AI活用支援では「業務で使える」「使えない」という主観の入る判定になる。だからこそ、判定の条件を数え上げられる形にしておく作業が、他分野以上に重要になります。

セキュリティやデータの扱いに関する条件も、この分野では欠かせません。社内データをAIに入力してよいのか、どこまでの範囲か、ログはどう扱うか。この確認を怠ると、導入後に利用そのものが止まります。関連する領域の仕事の広がりはAI・マーケティング・セキュリティのお仕事で確認できます。

修正の回数を決めるという作業は、相手を制限するためのものではありません。どこまでやれば終わりなのかを、双方が同じ言葉で理解するための作業です。終わりが見えている仕事は、依頼する側にとっても頼みやすい。次の依頼で確認書を1枚用意するところから始めれば、その効果はすぐに実感できるはずです。

よくある質問

Q. 修正は何回までにするのが妥当ですか？

成果物ごとに分けるのが実務的です。診断資料、プロンプト、設定、手順書はそれぞれ別の工程なので、一式でまとめず個別に回数を割り当てます。回数だけを決めても1回の定義で揉めるため、こちらが用意した確認シート1通を1回と数える、という単位を同時に書いておきます。あわせて受付期限も決め、期限後の指摘は別途の依頼として扱います。

Q. 修正と仕様変更は、どこで線を引けばよいですか？

着手前に合意した文書に書かれていた条件かどうかが基準です。書かれていた条件を満たしていない状態を直すのが修正、条件そのものを変えるのが仕様変更になります。迷う依頼は、作業をやり直す起点がどこまで戻るかで判定します。文言の調整で済むなら修正、設計から引き直すなら仕様変更です。この基準は相手にも先に伝えておきます。

Q. 「イメージと違う」と言われて検収が止まったらどうしますか？

検収の不合格要件として「どの条件を満たしていないかを明示する」と書面に入れておくのが根本の対策です。感覚的な理由での支払い保留は正当な理由になりません。フリーランス保護新法では受領日から60日以内の報酬支払いが定められており、正当な理由のないやり直しの要求も禁止されています。深刻な事案では弁護士に相談してください。

Q. AIの出力が毎回変わることを、どう説明すればよいですか？

不具合ではなく性質であることを、提案の段階で説明しておきます。そのうえで、テスト用の入力と期待する出力の条件を先に合意し、条件を満たすかどうかで判定する形にします。条件を満たしているのに変えたいという要望は好みの問題であり、仕様変更として扱えます。納品後の継続的な調整が必要なら、運用支援として別契約に分けます。

Q. 回数を超えた修正を頼まれたら、どう伝えればよいですか？

断る言い方ではなく選択肢を出す言い方にします。依頼内容を自分の言葉で要約して確認し、合意範囲のどこに位置するかを示したうえで、追加作業として進める場合の作業内容と所要期間を提示して判断を委ねます。見積もりを出すこと自体が意思確認になるため、多くの場合その場で決着します。空気で無償対応すると、それが次の基準になります。