AIチャットボット開発の修正を何回まで受けるか｜先に決めておく

結論から書きます。AIチャットボット開発の修正対応は、回数で決める前に「何を修正と呼ぶか」を決めないと機能しません。修正2回までと契約書に書いても、不具合の修正と仕様変更が同じ枠で数えられている限り、その枠はすぐに溶けます。

AIチャットボット開発は、他の受託開発と比べて修正が膨らみやすい構造を持っています。回答の良し悪しに客観的な合格ラインが引きにくく、依頼者の期待値が動きやすいためです。この記事では、修正対応の範囲をどう定義し、何回まで受けると決め、想定を超えたときにどう伝えるかを、受注後の実務手順として整理します。

AIチャットボット開発で修正が膨らむ構造

完成の定義が曖昧なまま走り出す

通常のシステム開発では、機能一覧に対して動くか動かないかで検収できます。AIチャットボットは違います。「質問にちゃんと答えられること」が要件になっている場合、ちゃんとの中身が人によって違うため、いつまでも完成しません。

現場でよく見るのは、依頼者が自分で思いついた質問を次々に投げて、期待した答えが返らないたびに修正依頼を出してくるパターンです。悪意はありません。依頼者にとっては、それが動作確認のつもりなのです。

この構造を放置すると、開発側の作業は無限に増えます。防ぐには、開発に入る前に「どの質問群に、どの水準で答えられれば完成なのか」を合意しておく必要があります。ここを飛ばした案件は、正直なところ、ほぼ確実に揉めます。

学習させれば直るという誤解

依頼者側に根強くあるのが、「データを追加で学習させれば精度は上がるはず」という理解です。実際には、回答が外れる原因は学習データの量だけではありません。想定質問の設計、検索対象の文書の構造、回答の温度設定、そもそもの前提知識の不足。原因は複数の層に散らばっています。

この誤解があると、修正依頼が「精度を上げてください」という粒度で届きます。何をどう直せばよいかが特定できない依頼は、調査に時間を取られ、しかも成果が見えにくい。時間だけが消えていきます。

対策は、依頼を受け取る形式を先に決めておくことです。どの質問を投げて、どんな回答が返って、どんな回答を期待していたか。この三点セットで報告してもらう運用にすると、原因の切り分けが一気に速くなります。

会話の分岐は無限に増やせる

チャットボットの設計には、際限なく作り込める性質があります。この質問のときはこう、その次はこう、と分岐を足していけば、いくらでも複雑にできます。

しかし、深く作り込むことが良い体験につながるとは限りません。

また、初めの質問から最終的な結論へ辿り着くまでには3〜5階層 以内に収めることをおすすめします。チャットボットとの会話が6回以上続くと、顧客はストレスを感じるでしょう。 出典: aisaas.pkshatech.com

分岐を増やす方向の修正依頼が来たとき、この観点を持っていると「増やす」以外の提案ができます。分岐を足すのではなく、階層を浅くして到達を早くするほうが、利用者の満足度は上がる。この提案ができる開発者は、修正の回数そのものを減らせます。

修正を三種類に分けて数える

不具合の修正

仕様として合意した動作が実現できていないもの。エラーが出る、想定した画面に遷移しない、指定した文書を参照していない。これは開発側の責任なので、回数に数えません。無償で直します。

ここを回数に含めてしまうと、依頼者との信頼関係が壊れます。バグを枠で数えるという発想は、受注側の都合でしかありません。契約書にも「不具合の修正は回数に含まない」と明記しておくべきです。

仕様どおりだが期待と違うもの

最も判断が難しいのがこれです。合意した仕様どおりに動いているが、依頼者が期待していた挙動とは違う。AIチャットボット開発の修正依頼の大半はここに入ります。

たとえば「問い合わせ内容を要約して担当者に転送する」という仕様に対して、要約の粒度が想定と違った場合。仕様には粒度が書かれていないので、どちらが正しいとも言えません。

この種類を、回数で管理する枠に入れます。「初回納品後の調整は2回まで」と決めておく対象は、この分類だけです。

仕様変更と機能追加

合意した範囲の外にある依頼。新しい質問カテゴリの追加、別システムとの連携、管理画面の機能追加。これらは修正ではなく新規の作業なので、回数の枠とは関係なく別途の見積もりになります。

問題は、依頼者がこれを「ちょっとした修正」として送ってくることです。悪気なく、本当に小さい依頼だと思っています。だから、受け取ったときに分類して返すのが実務になります。「こちらは仕様変更にあたりますので、別途お見積もりをお出しします」と、その場で伝える。あとから請求するより、圧倒的に角が立ちません。

何回まで受けるかの決め方

回数ではなく工程で切るのが基本

推奨するのは、回数ではなく工程で区切る方法です。具体的には、次の三段階に分けます。

第一段階はプロトタイプの確認。動く形を早めに見せて、方向性のずれを潰します。ここでの変更は回数に数えません。方向性の修正は早いほど安く済むので、むしろ積極的に出してもらいます。

第二段階は初回納品後の調整。合意した仕様に対して、実際に触ってみた結果の微調整です。ここに回数の上限を設けます。

第三段階は検収後。ここから先は運用フェーズなので、保守契約か都度の見積もりに切り替えます。

工程で切ると、依頼者にとっても分かりやすい。「今どの段階なので、この依頼はこう扱う」という説明が、毎回同じ論理でできます。

回数で切る場合の現実的な目安

工程での区切りが難しい小規模な案件では、回数で切ることになります。目安として、初回納品後の調整を2回、大規模なものでも3回程度に設定するのが一般的です。

重要なのは、回数の数え方を定義することです。「一度にまとめていただいたご依頼を1回と数えます」と書いておかないと、依頼者は思いついた順に一件ずつ送ってきます。十件の依頼が十回とカウントされると、依頼者にとって理不尽なので、まとめて送る運用を先に伝えておきます。

同時に、こちらの都合も伝えます。修正はまとめて着手するほうが効率が良く、結果として納期も早くなる。依頼者の利益になる説明を添えると、運用が定着します。

回数を設けない部分

すべてを枠に入れる必要はありません。回答内容の軽微な文言修正、誤字の訂正、既存カテゴリへの質問の追加といった、作業量が小さく判断も不要なものは、運用のなかで無償対応にしたほうが関係が円滑です。

線引きの基準は、作業時間ではなく判断の有無です。判断が要らない機械的な作業は無償枠、設計の判断が必要になるものは回数枠。この基準は説明しやすく、依頼者も納得しやすい。

契約前に固めておく項目

検収の基準を数字ではなく手順で決める

AIチャットボット開発で最も重要な合意事項が、検収基準です。回答精度を割合で決めるやり方は、一見明確に見えて実は揉めます。母数となる質問集合が定まっていないためです。

現実的なのは、テスト用の質問リストを事前に双方で作る方法です。想定される質問を一定数リストアップし、そのリストに対して合格とみなす回答の条件を決める。検収は、そのリストで実施します。

リストを作る作業自体を、開発の工程に入れて見積もります。ここを無償のサービスにしてしまうと、リストが曖昧なまま検収に入り、結局は修正の泥沼になります。

学習データと参照文書は誰が用意するか

AIチャットボットの品質は、参照する文書の質にほぼ規定されます。社内文書がばらばらの形式で、内容も古いまま渡された場合、どれだけ調整しても精度は上がりません。

だから、契約時に責任分界点を書きます。文書の準備と内容の正確性は依頼者側の責任、その文書を使って回答を生成する仕組みの構築が開発側の責任。この線が引かれていないと、文書の不備に起因する回答の外れが、すべて開発側の修正義務として扱われます。

あわせて、文書の更新をどうするかも決めます。運用開始後に元の文書が改訂されたとき、その反映は誰がやるのか。ここを決めておかないと、無償の永続的な作業が発生します。

期間の区切りを設ける

回数だけでなく、期間の上限も設けます。「初回納品から30日以内にいただいたご依頼を対象とします」といった形です。

期間を区切らないと、半年後に「あのとき修正が1回残っていた」と持ち出されることがあります。技術的な前提も変わっているので、当時と同じ工数では対応できません。期間の明記は、双方にとっての予測可能性を高めます。

契約書と見積書への書き方

見積書には、修正対応の条件を独立した項目として書きます。金額欄の下に注記として埋めるのではなく、作業項目のひとつとして並べる。そうすると、依頼者は条件を条件として認識します。

書き方の例を示します。

【修正対応の範囲について】
・仕様との不一致（不具合）の修正は、回数に含めず無償で対応いたします。
・仕様どおりの動作に対する調整は、初回納品後2回までを対象とします。
・複数のご依頼をまとめていただいた場合、1回として数えます。
・対象期間は初回納品日から30日間とします。
・仕様の変更および機能の追加は、別途お見積もりとさせていただきます。

この五行を入れておくだけで、後の会話が劇的に楽になります。揉めたときに参照できる文言があるかどうかで、話し合いの性格が変わります。

契約書に落とし込む場合は、検収の条項とセットで書きます。検収の合格条件、検収期間、検収後の扱い。この三点と修正条項が整合していることを確認します。

修正依頼が来たときの実務手順

受け取ったらまず分類する

依頼が届いたら、返信の前に分類します。不具合か、仕様内の調整か、仕様変更か。この判断を先にやらないと、返信の内容が決まりません。

判断の材料は、合意した仕様書とテスト用の質問リストです。仕様書に書かれている動作と違うなら不具合、書かれていないなら調整か変更。書かれていない領域の依頼が多い場合、そもそも仕様書の粒度が粗いという反省材料になります。

再現してから返信する

分類したら、実際に手元で再現します。依頼者の報告だけで判断すると、環境の違いや操作手順の差で認識がずれます。

再現できない場合は、その旨を伝えて追加情報を求めます。「こちらの環境では想定どおりの動作を確認しました。ご利用の環境と、実際に入力された文言をお知らせいただけますか」と、責めない形で聞く。ここで「そちらの操作ミスでは」と書いてしまうと、以降の協力が得られなくなります。

工数を見積もってから着手する

小さく見える依頼ほど、着手前に工数を見積もります。AIチャットボット開発では、一行の変更に見えて実は検索対象の再構築が必要になる、といったことが日常的に起きます。

見積もった結果、回数の枠内で収まらない規模だと分かったら、着手前に伝えます。着手してから「思ったより大きかったので追加でいただきたい」と言うのは、最も信頼を失う伝え方です。

対応後に何をしたかを書いて返す

修正が終わったら、何をどう直したかを一段落で書いて返します。「調整しました」だけの報告は、依頼者に何も伝わりません。

書く内容は三つ。何が原因だったか、どう直したか、同じ現象が他の箇所でも起きうるか。三つ目が特に価値があります。関連する箇所を先回りして直しておくと、次の修正依頼が減ります。

想定を超えたときの伝え方

枠を超える依頼が来たときの文面には型があります。断るのではなく、選択肢を示す形にします。

〇〇様

ご依頼ありがとうございます。内容を確認いたしました。

今回のご依頼は、当初ご合意いただいた仕様に含まれていない
新規の機能追加にあたります。
（合意仕様：△△／今回のご依頼：□□）

対応は可能ですので、進め方として2つご提案いたします。

1. 別途お見積もりのうえ、追加作業として実施
2. 現在の範囲で先に検収いただき、運用開始後の改善として実施

ご希望をお知らせいただければ、それぞれの内容をお出しします。

この文面のポイントは三つあります。まず、断っていないこと。次に、なぜ範囲外なのかを事実として示していること。最後に、選択肢を出して相手に決めてもらっていること。

拒絶と受け取られないためには、対応可能であることを先に書くのが有効です。条件の話をしているだけで、能力や意欲の話ではないと伝わります。

修正そのものを減らす設計

動く形を早く見せる

修正を減らす最も効果的な方法は、プロトタイプを早く出すことです。仕様書の文字だけで合意した内容は、実物を見た瞬間にずれが発覚します。そのずれを、開発の終盤ではなく序盤に出す。

粗くてかまいません。想定質問のうち数件だけが動く状態でも、依頼者は触った瞬間に多くのことを言い出します。その言葉こそが本当の要件です。

参照する文書を先に固める

開発に入る前に、参照する文書を確定させます。ここが揺れたままだと、開発中に文書が差し替わり、そのたびに調整が発生します。

文書の確定を工程として見積もりに入れ、依頼者側の作業として期限を設定します。「この日までに参照文書をご確定ください。以降の変更は仕様変更として扱います」と明記しておくと、依頼者の社内でも準備が進みます。

運用の主体を依頼者側に寄せる

長期的に修正を減らすには、依頼者が自分で調整できる範囲を広げることです。回答文の編集、質問カテゴリの追加、参照文書の差し替え。これらを管理画面から操作できるようにしておくと、細かい依頼が開発側に来なくなります。

導入後のサポート体制をどう組むかは、依頼者側も気にしている点です。

提供企業からのサポート体制が万全なら、導入や運用のアドバイスがもらえる場合があるため安心です。体験版を提供している作成ツールがあれば、なるべく利用して使用感を確かめることをおすすめします。 出典: aisaas.pkshatech.com

サポートを手厚くするほど信頼は増しますが、無償の範囲を広げすぎると疲弊します。だからこそ、無償で提供する部分と有償の部分を、最初に線引きしておく必要があります。

保守契約に移行する

検収が終わったら、都度の修正依頼を受け続けるのではなく、月額の保守契約に移行する提案をします。依頼者にとっては、依頼のたびに見積もりを取る手間がなくなる利点があります。

保守契約に含める範囲は、回答の微調整、参照文書の更新反映、動作監視、月次の改善提案あたりが標準的です。含めない範囲も明記します。新機能の開発、他システムとの連携追加、大規模な設計変更はここに入れません。

チャットボット開発を継続的な収入源にしている人ほど、この移行を早い段階で提案しています。AIチャットボット開発の案件全体の動き方や必要な技能についてはAIチャットボット開発のフリーランス案件｜必要スキルと単価にまとまっており、開発だけでなく運用まで含めた関わり方が見えてきます。

作り方によって修正の性質が変わる

作成ツールを使う場合

既存のチャットボット作成ツールを使って構築する場合、修正のほとんどは設定の調整になります。シナリオの分岐、回答文の編集、参照する文書の入れ替え。コードを書き換える作業は発生しません。

この場合のメリットは、修正の工数が読みやすいことです。設定変更にかかる時間はおおむね一定なので、見積もりの精度が上がります。デメリットは、ツールの仕様の外にある要望に応えられないことです。「ここをこう変えたい」と言われても、ツールが対応していなければ不可能です。

だから、ツールを使う案件では、契約時に制約を先に説明します。「このツールでは実現できない要望が出た場合、別の方法をご提案するか、対応を見送るかのご相談になります」と書いておく。これを言わずに進めると、できない要望が修正依頼として繰り返し届きます。

ツール選定そのものを依頼者に任せている場合は、選定の段階で関わるほうが後が楽になります。おすすめの選び方としては、体験版で実際の想定質問を投げてみて、目的の回答が返るかを確かめる方法が確実です。カタログの機能一覧だけで選ぶと、導入後に想定外の制約が出ます。

自社開発として組む場合

APIを組み合わせて独自に構築する場合、修正の自由度は高くなります。要望の大半は技術的には実現可能です。だからこそ、範囲の線引きが難しくなります。

自由度が高い分、依頼者の要望も広がります。「できるならやってほしい」という依頼が増え、それぞれは小さくても総量が膨らむ。ここで効くのが、工程で区切る運用です。技術的にできるかどうかと、この契約の範囲かどうかは別の話だと、繰り返し丁寧に分けて伝えます。

自社開発の案件では、もうひとつ注意点があります。基盤となるAIのサービス側が仕様を変更すると、それまで動いていた挙動が変わることがあります。これは開発側の不具合ではありませんが、依頼者からは不具合に見えます。契約書に「外部サービスの仕様変更に起因する調整は別途の対応とする」旨を書いておくのが実務的な備えです。

二つの方法の比較で説明する

依頼者に方法を選んでもらう場面では、修正のしやすさも比較の材料に入れます。ツールを使う方法は、初期構築が早く、運用の調整も依頼者側で完結しやすい。独自開発は、初期に時間がかかるが、独自の業務フローに合わせ込める。

この比較を、開発を始める前に文書で示しておくと、後の修正依頼の性格が変わります。制約を理解したうえで選んだ依頼者は、制約に起因する要望を修正として出してきません。説明の一手間が、修正対応の総量を減らします。

実際に起きるトラブルと対処

検収がいつまでも終わらない

最も多いトラブルです。依頼者が触るたびに新しい要望が出て、検収の判断が先送りされる。原因は、検収の基準が決まっていないことに尽きます。

すでに始まってしまった場合の対処は、基準を後から作ることです。「現時点で確認いただきたい項目を一覧にしました。この一覧に対する合否でご判断いただけますか」と、こちらから検収の枠組みを提示します。判断の対象を有限にするのが目的です。

あわせて、一覧に入らなかった要望は「運用開始後の改善候補」として別のリストに移します。捨てるのではなく、置き場所を変える。依頼者の要望を否定していないと伝わる形にします。

担当者が交代して要望が振り出しに戻る

企業案件では起こりがちです。前任者と合意した内容を、後任者が知らないまま新しい要望を出してくる。

備えは、合意事項を常に文書で残しておくことです。仕様書、検収基準、修正範囲の三点がファイルとして存在していれば、後任者に渡すだけで説明が済みます。口頭やチャットの流れだけで進めていた案件は、担当交代の時点で立て直しが必要になります。

想定していない使われ方で品質が問われる

公開後、開発時に想定していなかった質問が大量に投げ込まれ、外れた回答が並んでしまうケースがあります。とくに社外向けに公開したチャットボットでは、利用者が意図的に想定外の入力を試すことがあります。

これを不具合として扱うと、対応が無限に続きます。備えとして、開発時に「対応範囲外の質問が来たときの挙動」を仕様として決めておきます。分からない場合に何と返すか、有人の窓口へどう案内するか。この挙動が設計されていれば、範囲外の質問が来ること自体は問題になりません。

依頼者への説明も先にしておきます。すべての質問に正しく答えるものではなく、決めた範囲の質問に安定して答え、範囲外は適切に受け流す仕組みである。この理解が共有されていれば、公開後の評価軸がぶれません。

支払いが修正対応を理由に止まる

修正が終わっていないという理由で支払いが保留されるケースがあります。ここは契約の設計で防げます。着手金と納品時の分割にしておく、あるいは検収期限を設けて「期限内に異議がない場合は検収完了とみなす」条項を入れておく。

※ 支払いをめぐって当事者間で解決できない状況になった場合は、契約書の内容の解釈が絡むため、弁護士に相談してください。

隣接する領域への広がり

AIチャットボット開発の仕事は、単体で完結しないことがほとんどです。導入する側の業務そのものを整理しないと、そもそもチャットボットに何を答えさせるべきかが決まりません。この上流の整理を担当できるようになると、修正対応の位置づけも変わります。

業務の設計から関わる仕事はAIコンサル・業務活用支援のお仕事のような領域に広がっており、AI活用とマーケティングやセキュリティが交差する案件はAI・マーケティング・セキュリティのお仕事としてまとめられています。開発の実装部分に集中したい場合はアプリケーション開発のお仕事の範囲に近くなります。

上流から入ると、要件が固まった状態で開発に入れるため、修正の総量が減ります。修正対応の負担を減らす最終的な手段は、実は交渉術ではなく、関わる工程を前に伸ばすことです。技術系の職種としての報酬の水準感はソフトウェア作成者の年収・単価相場で確認できます。

修正対応の履歴を次の案件に生かす

案件が終わったら、修正依頼の履歴を見返します。どの分類の依頼が多かったか、どの工程で認識のずれが生まれたか。この振り返りが、次の見積もりと契約条件に直接効きます。

たとえば仕様変更に分類される依頼が多かった案件では、要件定義の粒度が粗かったことになります。次からは、その部分にヒアリングの時間を厚く配分します。仕様内の調整が多かった案件では、プロトタイプの提示が遅かった可能性があります。

振り返りで残すのは、一案件につき数行で十分です。分類ごとの件数、印象に残ったずれ、次に変えること。この三点だけを積み上げていくと、数件を経たところで自分の弱点が明確になります。

もうひとつ、修正依頼の文面そのものも資産になります。依頼者がどんな言葉で要望を伝えてくるかを蓄積しておくと、次の案件の要件定義で先回りして確認できます。「精度を上げてほしい」という依頼が繰り返し来るなら、契約前に精度の定義を合意する工程を組み込む。過去の依頼文は、次の契約書の材料です。

現場を見てきた立場からの観察

フリーランスと在宅ワークの市場を20年見てきた立場から言えば、修正対応で消耗する人と、しない人の差は、技術力ではなく最初の一週間の使い方に出ます。消耗しない人は、開発を始める前に検収の基準と修正の範囲を書面にしています。消耗する人は、良い関係を壊したくないという理由で、その会話を後回しにしています。

運営者として見てきた限りでは、条件を先に決めた案件のほうが、依頼者との関係も長続きしています。条件が曖昧なまま進んだ案件は、途中でどちらかが不満を溜め、静かに終わります。条件の明確化は、相手を疑う行為ではなく、関係を長持ちさせるための手続きです。

手取りという観点では、取引の構造も効いてきます。中間の手数料が乗らない直接取引では、依頼者は同じ予算でより多くを依頼でき、受け手は同じ発注額でも手取りが厚くなります。手数料0%という構造は、金額を吊り上げる仕組みではなく、双方の取り分を無駄に削らない仕組みです。そして直接取引では、修正の範囲を決める会話を仲介者に任せられません。自分で線を引き、自分で伝える必要があります。その手間を引き受けられる人が、結果として一件あたりの負担を軽くし、次の案件に進む余力を残しています。

修正を何回まで受けるか。この問いの答えは、回数そのものではなく、何を修正と呼ぶかを先に決めておくことです。定義が決まっていれば、回数は自然に決まります。定義がなければ、何回と書いても意味を持ちません。

よくある質問

Q. 修正回数は何回に設定するのが一般的ですか？

初回納品後の調整として2回、規模の大きい案件でも3回程度が目安です。ただし回数より先に、何を修正と数えるかの定義が重要になります。仕様との不一致である不具合は回数に含めず無償で直し、仕様変更や機能追加は別途の見積もりとします。回数の枠に入れるのは、仕様どおりに動いているが期待と違うという調整だけです。

Q. 依頼者が細かい依頼を何度も送ってくる場合はどうすればよいですか？

まとめて送っていただく運用を先に決めておきます。契約書や見積書に「複数のご依頼をまとめていただいた場合は1回として数えます」と明記し、その理由もあわせて伝えます。まとめて着手するほうが効率がよく納期も早くなるため、依頼者にとっても利点があります。理由まで説明すると運用が定着しやすくなります。

Q. 回答の精度が上がらないという依頼にはどう対応しますか？

まず依頼の形式を決めます。投げた質問、返ってきた回答、期待していた回答の三点を報告してもらう運用にすると、原因の切り分けが速くなります。回答が外れる原因は学習データの量だけでなく、想定質問の設計、参照文書の構造、前提知識の不足など複数の層にあります。参照文書の準備責任は契約時に依頼者側と決めておきます。

Q. 範囲を超える依頼が来たとき、どう伝えれば角が立ちませんか？

断らずに選択肢を示します。対応可能であることを先に書き、合意した仕様と今回の依頼の差分を事実として示したうえで、別途見積もりで追加作業として実施するか、先に検収して運用開始後の改善として扱うかの二案を出します。判断を相手に委ねる形にすると、条件の話であって能力や意欲の話ではないと伝わります。

Q. 検収の基準はどう決めればよいですか？

回答精度を割合で決めるのは避けます。母数となる質問集合が定まっていないため揉めやすいからです。現実的なのは、想定される質問のリストを事前に双方で作り、そのリストに対して合格とみなす条件を決める方法です。リストを作る作業自体を開発工程として見積もりに含めてください。無償で行うと基準が曖昧なまま検収に入ります。