機械学習開発の修正を何回まで受けるか｜先に決めておく

2026年7月10日

長谷川奈津

この記事のポイント

✓機械学習開発の修正対応は「精度がもう少し」で無限に続きます
✓超過したときの追加見積もりまで
✓受注前に決めておく手順を実務ベースで整理しました

機械学習開発の修正対応で消耗している人は、たいてい同じ場所でつまずいています。納品したモデルに対して「精度がもう少し欲しい」「別の期間のデータでも試してほしい」という依頼が続き、どこまでが契約の範囲でどこからが追加なのか、誰も答えを持っていない状態です。結論から言うと、修正回数は受注後に交渉するものではなく、見積もりを出す段階で数字と条件をセットにして先に決めておくものです。この記事では、機械学習開発ならではの「終わりが見えない」構造を分解したうえで、修正・追加・瑕疵の切り分け方、回数の数え方、契約書に入れる文言、そして回数を超えた依頼を角を立てずに追加見積もりへ乗せる手順までを順番に整理します。

機械学習開発の修正対応が終わらない構造的な理由

一般的なシステム開発なら、修正対応は「仕様と違う挙動を仕様どおりに直す」作業です。仕様書という基準があるので、直したかどうかを判定できます。機械学習開発ではこの基準が最初から曖昧になりやすく、そこが修正の終わらなさを生みます。受注する側が最初に理解しておくべきなのは、これが担当者の性格や相性の問題ではなく、成果物の性質から来る構造的な問題だという点です。構造から来る問題は、話し合いの雰囲気では解決しません。契約の書き方で解決します。

成果物がコードではなく精度だから

Webアプリの開発なら「ボタンを押すと登録される」で完了を判定できます。機械学習開発の成果物は、学習済みモデルとその推論結果であり、良し悪しは連続した数値で表現されます。正解率が上がれば上がるほど良いという性質上、発注側から見れば「もう少し上がるのではないか」という期待がいつまでも残ります。ここに終点を置くには、受注側が「この数値に到達したら完了」という合格ラインを最初に文書化しておくしかありません。合格ラインを決めずに着手した案件は、精度が上がっても下がっても修正依頼が続きます。上がれば「この調子でもう一段」、下がれば「元に戻して」と言われるためです。

さらに厄介なのは、精度の指標が一つではないことです。正解率、適合率、再現率、誤検知の件数、処理速度、どれを優先するかで最適なモデルは変わります。発注側が「精度を上げて」と言うとき、実際には誤検知を減らしたいのか、取りこぼしを減らしたいのかが定まっていない場合が少なくありません。この二つは基本的にトレードオフの関係にあり、片方を追えば片方が悪化します。合格ラインを決めるとは、どの指標をいくつにするかを決めることです。

データが変われば同じモデルでも結果が変わる

納品したモデルに一切手を加えていなくても、入力されるデータの傾向が変われば出力の質は落ちます。季節性のある売上データ、商品構成が入れ替わるEC、担当者が変わって記入ルールが変わった業務ログ。どれも現場では日常的に起こります。発注側から見ると「納品されたものが壊れた」ように見えるため、瑕疵の主張として修正依頼が来ます。実際にはモデルの不具合ではなく、前提となるデータ分布が変わったことによる劣化です。

この区別を契約前に共有しておかないと、納品から半年経ってから無償対応を求められることになります。データの傾向が変わった場合の再学習は保守運用の領域であり、開発契約の修正対応とは別枠だと明記しておく必要があります。実務ではここを曖昧にしたまま「困ったら言ってください」と口頭で伝えてしまい、その一言が無期限の無償サポート契約として解釈されるケースが起きています。

発注側にも受注側にも完成の定義がないから

機械学習の導入を初めて行う企業では、発注側の担当者自身も「何ができたら成功なのか」を言語化できていないことがあります。上司からAI活用を指示され、とりあえず外部に相談してみた段階の依頼は珍しくありません。この状態で見積もりを出すと、途中から本来の目的が判明し、それに合わせて要件が動きます。要件が動けば当然、作り直しに近い修正が発生します。

受注側にとって重要なのは、この状況を「発注側が悪い」と切り捨てないことです。目的が固まっていない依頼は、固める工程そのものを有償の作業として設計すれば成立します。企業のAI活用を上流から支援する仕事の全体像はAIコンサル・業務活用支援のお仕事にまとまっており、要件を定義する工程自体が独立した役務として扱われていることが分かります。要件定義を無償のヒアリングとして飲み込むから、後工程の修正が無限に増えます。

修正・追加・瑕疵を切り分ける3つの区分

修正回数を決める前に、そもそも何を1回と数えるのかを定義しなければ意味がありません。実務では、寄せられる依頼を次の3種類に分類します。この分類を発注側と共有しておくと、依頼が来た時点で「これは修正の1回に数えます」「これは追加見積もりの対象です」と即答できるようになります。

瑕疵に当たるもの（無償で直す）

契約書や仕様書に書いた内容と、納品物の挙動が食い違っているものです。合格ラインとして定めた指標に到達していない、指定した環境で動かない、約束したAPIの形式になっていない、といったケースが該当します。これは修正回数のカウントに含めず、無償で直します。含めてしまうと、自分のミスを直す作業で回数を消費することになり、発注側から見れば理不尽です。信頼を失う契約設計は結局そのあとの単価に響きます。

注意したいのは、瑕疵の範囲を自分で広げないことです。「合格ラインには達しているが、一部のデータで期待した結果にならない」は瑕疵ではありません。合格ラインは統計的な基準であり、個別の入力に対する結果を保証するものではないからです。この点は契約書に一文入れておくと、後の議論が短くなります。

修正に当たるもの（回数の中で対応する）

合意した範囲内で、品質を調整するための依頼です。閾値の調整、特徴量の入れ替え、出力フォーマットの微修正、レポートの表現変更などが該当します。作業量としては小さいものから中程度のものまで幅があり、ここを何回まで受けるかが本題になります。

追加に当たるもの（別見積もりを出す）

当初の合意に含まれていない要求です。対象データの範囲を広げる、新しい分類カテゴリを増やす、別部署の業務にも展開する、リアルタイム推論に切り替える、といった依頼が該当します。作業量が当初の見積もりを大きく超えるため、回数の枠内で処理してはいけません。追加として見積もりを出し、発注側が判断できる形にします。この判断ができるかどうかで、案件の採算はほぼ決まります。

修正回数の決め方と数え方

区分ができたら、次は回数です。数字だけを決めても運用できません。「1回」の単位、期限、そして工程ごとの配分をセットで決めます。

工程ごとに回数を割り当てる

機械学習開発は、要件定義、データ整備、モデル構築、検証、システム連携という工程に分かれます。修正回数を「全体で3回」とまとめて決めると、序盤で使い切って終盤に身動きが取れなくなります。実務では工程ごとに割り当てます。たとえば要件定義の成果物であるレポートに対して2回、モデルの検証結果に対して3回、システム連携後の受け入れテストに対して2回、という配分です。工程が終わるごとに承認をもらい、承認済みの工程には戻らないという合意も同時に取ります。

この「戻らない」という合意が抜けていると、検証段階で要件定義そのものをひっくり返す依頼が来ます。機械学習開発ではデータを見て初めて分かることがあるため、後戻り自体は完全には避けられません。避けられない前提で、後戻りが発生したら追加見積もりになると先に決めておくのが現実的な設計です。

1回の単位を定義する

「修正3回まで」と書いても、発注側が1通のメールに15項目の指摘を並べてきたら、それが1回なのか15回なのかで揉めます。実務では次のどちらかの定義を採用します。一つは、指摘をまとめて受け取り、まとめて返す往復を1回と数える方法。もう一つは、作業時間で数える方法です。前者は運用が簡単ですが、1回あたりの作業量が読めません。後者は正確ですが、時間の記録と共有が必要になります。

現場で扱いやすいのは、往復を1回と数えたうえで「1回あたりの指摘は最大10項目まで、超える場合は2回分として扱う」といった上限を添える形です。数え方を決めておくと、依頼を受けた時点で「今回は2回分に相当します。残りは1回です」と伝えられます。残数を伝える運用にすると、発注側が指摘を整理してから送るようになり、結果的にやり取りの総量が減ります。

期限を付ける

回数と同じくらい重要なのが期限です。回数だけを決めて期限を決めないと、納品から数か月後に「あと1回残っていますよね」と連絡が来ます。その頃には環境もデータも変わっており、当時と同じ作業では済みません。修正依頼を受け付ける期間を「検収完了から14日以内」のように明記し、期間を過ぎた依頼は保守契約または追加見積もりの対象とします。

修正が集中しやすい工程を先回りで潰す

修正回数を決めるのは防御策です。あわせて、そもそも修正が発生しにくい進め方を組み込んでおくと、決めた回数の中に十分収まります。機械学習開発では、修正が集中する工程がある程度決まっています。

中間成果物を早い段階で見せる

最も多い失敗は、完成したモデルを最後にまとめて見せることです。発注側は途中経過を見ていないため、初めて見た成果物に対して思いつく限りの指摘を出します。この一括の指摘が、修正回数を一気に消費します。防ぐには、工程の途中で必ず中間成果物を出します。データ整備が終わった段階で、集計結果と欠損の状況をまとめた資料を共有する。モデルの候補が絞れた段階で、代表的な入力に対する出力例をいくつか見せる。この2回の共有があるだけで、最終段階の指摘は目に見えて減ります。

中間成果物は完成品である必要はありません。むしろ粗い状態で見せたほうが、発注側は遠慮なく方向性の疑問を出してくれます。方向性のずれは早いほど直す工数が小さく、遅いほど作り直しに近づきます。早い段階で見せることは、受注側の工数を守る行為です。

精度の限界を数字で共有しておく

発注側が「精度をもう少し」と言い続ける背景には、どこまで上がるのかが分からないという不安があります。ここに対しては、データの品質から見た上限の見立てを早い段階で共有します。ラベルの付け方に揺れがある、対象の事象そのものが少ない、説明変数が足りていない、といった制約はデータを見れば分かります。制約を先に説明しておくと、「これ以上はデータを増やさないと上がらない」という結論が、言い訳ではなく最初からの前提として受け止められます。

この説明を後出しにすると、能力不足を隠すための弁明に聞こえます。同じ内容でも、伝える順番が違うだけで受け取られ方が変わります。実務では、検証結果を出す前の段階で制約を書面に残しておくのが安全です。

判断を求める箇所を明示する

「ご確認ください」とだけ書いて成果物を送ると、発注側は何を確認すればよいか分からず、結果として全体に対する漠然とした感想が返ってきます。漠然とした感想は修正指示に変換しにくく、往復が増えます。送るときは、判断してほしい箇所を具体的に指定します。誤検知と取りこぼしのどちらを優先するか、出力の粒度は日次と週次のどちらか、といった二択の形にすると、返答が具体的になります。二択で返ってきた回答は記録として残せるため、後から「そんなことは言っていない」という議論にもなりにくくなります。

契約書と見積書に入れる文言

決めた内容は、口頭ではなく書面に落とします。見積書の備考欄と契約書の両方に、同じ趣旨の文言を入れておくのが安全です。以下は雛形として使える書き方です。実際の案件では業務内容に合わせて調整し、金額の大きい契約や責任範囲が広い契約では専門家の確認を受けてください。

見積書の備考欄には、次の要素を並べます。修正対応の回数と工程ごとの配分。1回の数え方。受付期間。合格ラインとして定めた評価指標とその値。データの傾向変化に伴う再学習は本見積もりに含まないこと。回数を超えた場合は別途見積もりとすること。この6点が揃っていれば、後の議論はほぼ書面の確認で終わります。

契約書側では、成果物の定義と検収の手続きを明確にします。「甲は成果物の受領後10営業日以内に検収を行い、合否を書面で通知する。期間内に通知がない場合は検収に合格したものとみなす」といった条項です。検収のみなし規定がないと、発注側が沈黙している間ずっと案件が閉じません。フリーランス保護新法では、発注者は受領日から60日以内に報酬を支払う義務を負いますが、検収が終わらない状態を放置すると支払いの起算点をめぐって話が複雑になります。取引条件を書面で明示する義務も含め、法令の枠組みは受注側を守る方向に働きます。制度の詳細は公正取引委員会の案内などで確認できます（https://www.jftc.go.jp/）。

書面を作る作業そのものが苦手だという声もありますが、ビジネス文書の型を体系的に学ぶ資格も存在します。文書の構成や敬語の使い方を整理したい人にはビジネス文書検定の出題範囲が実務的な参考になります。

修正依頼を受け取ってからの手順

回数を決めていても、依頼が来たときの対応がその場しのぎだと結局は消耗します。受け取ってから返すまでを固定の手順にしておきます。

手順1: 即座に着手しない

依頼メールを読んだ直後に手を動かすのが最も危険です。まず内容を3区分のどれに当たるかで仕分けます。仕分けの結果を、受領から1営業日以内に返信します。この返信には、区分の判定、想定される作業内容、残りの修正回数、完了予定日を書きます。作業を始める前にこの1通を出すだけで、認識のずれによる手戻りが大きく減ります。

手順2: 追加に当たるものは着手前に見積もりを出す

追加と判定した依頼は、金額と納期を提示し、承認をもらってから着手します。「小さい作業だから先にやっておこう」という善意が、次の依頼のハードルを下げます。無償で対応した実績は前例になり、次からは同種の依頼が無償の前提で来ます。判断に迷ったら、着手前に見積もりを出す側に倒します。

手順3: 対応内容を記録に残す

何回目の修正で何を直したかを、案件ごとに1枚の記録にまとめます。後から「あの変更はいつ入れたか」を追えるようにするためです。この記録は次回以降の見積もり精度も上げます。同種の案件で修正が何回発生したかが分かれば、次の見積もりに現実的なバッファを載せられます。

手順4: 回数を使い切る前に予告する

残り1回になった時点で、その旨を発注側に伝えます。「残り1回です」と伝えるだけで、発注側は最後の依頼に指摘を集約しようとします。使い切ってから通告すると、発注側には「打ち切られた」という印象だけが残ります。予告は関係を壊さないための実務です。

回数を超えた依頼を断り、追加見積もりへ乗せる書き方

回数を超えた依頼を断ること自体は、契約に沿った正当な対応です。それでも伝え方によって印象は大きく変わります。押さえるべきは、断りではなく選択肢の提示にすることです。

まず、依頼内容を実現できると認めます。次に、それが当初の合意範囲外であることを事実として示します。そのうえで、作業内容と金額と納期を提示し、進めるかどうかを相手に選んでもらいます。文面としては次のような形になります。「ご依頼の件、対応は可能です。ただし当初の合意では対象データを直近1年分としており、今回のご要望は3年分への拡張となるため、追加作業として見積もりをお出しします。作業内容はデータ整備とモデルの再学習、検証で、期間は2週間、金額は別紙のとおりです。ご確認のうえ進行のご判断をお願いします」。

この書き方には、相手を責める要素がありません。合意の内容を確認し、選択肢を出しているだけです。実務では、追加見積もりを出したうちの一定数はそのまま発注につながります。断ったつもりの対応が、次の受注になるということです。

修正対応を仕組みにするツールと運用

回数の管理を記憶に頼ると必ず崩れます。案件が複数走っているときはなおさらです。特別なソフトを導入しなくても、次の3つを用意すれば運用できます。

一つ目は、修正依頼の受付窓口を一本化することです。チャット、メール、電話、打ち合わせの口頭とばらばらに依頼が入る状態では、回数を数えられません。「修正のご依頼はこのメールアドレスにお願いします」と最初に決め、他の経路で来た依頼は「記録のため一度メールでお送りください」と丁寧に誘導します。

二つ目は、案件ごとの修正台帳です。日付、依頼内容、区分の判定、対応内容、残り回数を並べた表で足ります。表計算ソフトで十分機能します。

三つ目は、モデルとデータのバージョン管理です。機械学習開発では、コードだけを管理しても再現できません。学習に使ったデータの範囲、前処理の条件、ハイパーパラメータ、評価結果をセットで残します。これがないと、「前のバージョンに戻してほしい」という依頼に応えられません。バージョン管理の考え方や開発環境の作り方は、ソフトウェア開発全般の基礎と共通しています。開発職の仕事の広がりはアプリケーション開発のお仕事に整理されており、AI領域と周辺のシステム開発が地続きであることが分かります。

自動化の研究面でも、修正作業を機械に任せる方向は進んでいます。バグの検出と修正を学習させる取り組みは実用段階の検証に入っています。

研究者らが、Pythonのパッケージに存在する2374件の実際のバグからなるデータセットでテストを行ったところ、26％のバグが発見され、自動的に修正されたという。出典: japan.zdnet.com

この数字が示すのは、機械が拾えるのは今のところ全体の一部だということです。裏を返せば、残りは人が判断して直す領域として残ります。修正対応の設計が当面のあいだ受注者の実務として重要であり続ける理由がここにあります。

回数制限を設けるメリットとデメリット

回数制限は万能ではありません。導入する前に、両面を把握しておきます。

メリットは3つあります。第一に、採算が読めるようになります。修正にかかる工数の上限が決まるため、見積もりの精度が上がります。第二に、発注側の依頼が整理されます。回数が有限だと分かると、思いつきの指摘が減り、優先順位を付けて送られてくるようになります。第三に、案件が閉じます。終わりが定義されるため、次の案件に移れます。

デメリットもあります。制限を前面に出しすぎると、発注側に「融通が利かない」という印象を与えます。特に初回の取引では、条件の厳しさが信頼の薄さと受け取られることがあります。緩和策としては、回数を伝えるときに理由を添えることです。「品質を保つために、検証の工程に十分な時間を確保したいので、修正は工程ごとに区切って管理させてください」という説明があれば、制限は誠実さとして伝わります。

もう一つのデメリットは、回数の運用に手間がかかることです。台帳の更新、残数の通知、区分の判定はすべて作業です。ただしこの手間は、無限に続く無償修正と比べれば圧倒的に小さい投資です。

回数制限の設計を比較する

回数の決め方には複数の型があり、案件の性質で使い分けます。定額の請負契約で、要件が固まっている案件なら、工程ごとの回数制限が最も相性が良い設計です。要件が動く前提の探索的な案件では、回数制限ではなく期間契約や準委任契約に切り替えるほうが合理的です。準委任なら、作業時間に対して対価が発生するため、修正という概念自体が薄れます。

おすすめの判断基準は単純です。合格ラインを数値で書けるなら請負と回数制限、書けないなら準委任です。書けないのに請負で受けると、回数をどれだけ設定しても足りません。この判断を見積もり前に済ませておくことが、機械学習開発の修正対応で消耗しない最大の分岐点になります。AIの導入支援やセキュリティ領域を含む案件では契約形態が複雑になりやすく、周辺領域の仕事の切り分け方はAI・マーケティング・セキュリティのお仕事の分類が参考になります。

市場の側から見た修正対応の位置づけ

在宅ワークと業務委託の市場を20年見てきた立場から言えば、修正対応の条件を先に出す受注者ほど、同じ相手から次の仕事を受けています。条件を出さない人が優しく見え、出す人が身構えて見えるのは最初の数日だけです。実際には、条件が明示されている相手のほうが、発注側にとっては予算とスケジュールを組みやすい相手になります。社内の稟議を通す担当者にとって、範囲が確定している見積もりは通しやすい書類です。

もう一つ、長く続いている受注者に共通するのは、修正のやり取りを関係づくりの場として使っていることです。指摘を受けたときに、直した結果だけを返すのではなく、なぜその結果になったかを一言添える。この積み重ねが「この人に任せると判断が早い」という評価になります。仲介の手数料が乗らない直接取引では、同じ予算でも発注側はより多くを依頼でき、受け手の手数料0%の取引は手取りが厚くなります。金額が同じでも手取りが違えば、修正1回にかけられる時間の余裕が変わります。余裕は品質に直結し、品質は次の依頼につながります。この循環に入れるかどうかが、案件単位の勝ち負けより長期的には効いてきます。

エンジニア職の待遇水準を客観的に把握したい場合はソフトウェア作成者の年収・単価相場のような公的統計ベースのデータを見ておくと、条件交渉の際に自分の立ち位置を説明しやすくなります。海外の発注者と取引する場合は契約文化そのものが異なり、修正回数の考え方も国内とは違います。英語圏のプラットフォームでの立ち回りはUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法に整理されており、契約条項を先に固める文化の実例として読む価値があります。

修正対応は、技術力ではなく設計の問題です。何回まで受けるかを先に決め、区分を共有し、超えたら見積もりを出す。この3つを守れば、機械学習開発の修正対応は管理可能な作業になります。