AI開発をいつ止めるか。撤退基準を契約前に決める3つの線と、止めるときにかかる5つの費用

AI 開発の失敗として語られるものの多くは、始めたことではなく止められなかったことである。

精度が目標に届かない。現場が使わない。効果の数字が出ない。そこまでは分かっているのに、半年、1 年と続いてしまう。そして最後は予算が尽きて終わる。止める判断そのものが下されないまま終わるので、社内には「AI は使えなかった」という感想だけが残り、何が原因だったのかは誰も整理しない。

この記事では、止める条件を契約前に決めておくための線の引き方と、実際に止めるときに何の費用が発生するかを整理する。

1. 止める判断が遅れる理由は、技術ではなく社内にある

現場で聞く限り、判断が遅れる理由はだいたい次の 3 つに収まる。

すでに使った金額が惜しい。 500 万円かけた案件に、あと 200 万円で形になると言われれば、多くの人が出す。だが、その 500 万円は出しても出さなくても戻らない。判断に使ってよいのは「これから出す 200 万円で、これから得られるもの」だけである。

稟議を通した人が言い出しにくい。 社内で予算を取った担当者にとって、中止の提案は自分の判断の否定に見える。ここが最大の壁になる。だから、止める条件は担当者ではなく、稟議の時点で決裁側が決めておく必要がある。AI開発の予算を社内で通す方法。稟議で問われること で書いた稟議書に、中止条件の 1 行を入れておくだけで、後の負担がまるで違う。

判定する材料が無い。 「精度が上がってきている」「もう少しで実用域」という説明を否定できるだけの指標が用意されていない。これは合格ラインを事前に決めていなかったことの結果である。

3 つとも、開発が始まってからでは手当てできない。止める話は、発注前にしかできない。

2. 契約前に決める 3 つの線

決めるのは 3 つだけでよい。多いと運用されない。

線	決めること	決め方
合格ライン	この数字に届かなければ次の工程へ進まない、という値	業務が回るかどうかで決める。技術的な精度指標そのものではなく、「人が手直しする件数」「対応にかかる時間」など、業務側の数字に翻訳する
期限	いつの時点で判定するか	開発の完了日ではなく、判定日を別に置く。工程が延びても判定日は動かさない
予算上限	ここを超えたら止める、という累計額	初期費用だけでなく、社内の工数と運用費を含めた累計で置く

合格ラインの置き方でつまずく場合は、AIの精度をどう評価するか。発注者が知るべき指標と落とし穴 と PoCの設計方法。何を検証すれば判断できるか に、業務側の数字への翻訳のしかたをまとめてある。

重要なのは、この 3 つを見積書と同じ紙に書いておくことである。別の文書にすると参照されない。

「止める」と「作り直す」を分ける

判定日に届かなかったとき、選択肢は中止だけではない。

• 範囲を狭めて続ける（対象業務を絞る、自動化の範囲を下げる）
• 方式を変えて続ける（作らずに既製品で済ませる、人の運用に戻す）
• 止める

判定日に決めるのは「続けるか止めるか」ではなく、**「この範囲・この方式で続けるか」**である。範囲を狭める選択肢を最初から用意しておくと、全損か続行かの二択にならずに済む。安くできる部分と削ってはいけない部分の切り分けは AIエージェントを安く作れるか。自律度を下げる設計 の考え方が近い。

3. 止めるときに実際にかかる費用

「止める＝これ以上払わない」ではない。止める側にも費用が出る。主なものは次の 5 つで、いずれも契約の書き方で大きさが変わる。

費用	中身	契約で効く条項
着手済み工数の精算	判定日までに実施済みの作業分	準委任か請負か。準委任は実施分の支払いが原則、請負は完成物の扱いで揉めやすい
解約の予告期間	通知から契約終了までの期間の費用	中途解約条項。1 ヶ月前・3 ヶ月前で金額が変わる
クラウド・ライセンスの残契約	年契約で確保した基盤やツールの残り	誰の名義で契約したか。ベンダー名義だと発注側から解約できない
データと成果物の返還作業	渡した業務データの返却・削除、作りかけの成果物の引き渡し	権利帰属と返還の条項。作業費が別途になっていないか
社内側の後始末	移行を止める連絡、現場への説明、元の業務手順への戻し	契約外。社内工数として見ておく

3 番目のクラウド・ライセンスは見落とされやすい。ベンダーが自社名義で年契約した基盤の残債は、案件を止めても消えない。誰の名義でどの期間の契約をするかは、AI開発の契約書で確認すべき12項目 に沿って発注前に確認しておく。

契約の型そのものについては 請負と準委任、AI開発はどちらで契約するか に整理がある。止めやすさという観点だけで見れば、フェーズを分けて契約を切り直す形がいちばん止めやすい。1 本の長い契約にすると、途中で降りる場所が無くなる。

4. フェーズを分けると、止める費用は設計できる

PoC・MVP・本番運用をまとめて 1 本で発注すると、判定日が来ても契約上は止められない、という状態になる。フェーズごとに契約を切ると、次のフェーズを発注しない、という形で止められる。

発注のしかた	止めるときにできること
一括で 1 本	中途解約条項に従って解約する。精算額の交渉が必要になる
フェーズごとに分割	次を発注しない。追加の精算は原則として発生しない

分割には手間もある。都度の契約事務が増え、フェーズ間で体制が切れるリスクもある。PoCから始めるか、直接開発するか。判断の基準 で書いたとおり、要件が固まっている案件では分割の利点が小さい。要件が固まっていない案件ほど、分割の価値は止めやすさとして返ってくる。

5. 止めても残る 4 つの資産

止めた案件が全損になるかどうかは、契約の書き方で決まる。次の 4 つは、止めても手元に残せる。

1. 整備した業務データ — 分類し直した文書、表記を揃えたマスタ、タグ付けした事例。次に別の方式で作るときも使える。AI開発のデータ準備。品質・量・権利の実務 に整備の単位をまとめてある
2. 要件定義と業務の棚卸し結果 — 何をどこまで自動化したかったのか、現場の手順はどうなっていたのか。これ自体が業務改善の材料になる
3. 評価用データと合格ラインの定義 — 何をもって使えると判断するかの基準。次の発注でそのまま提示できる
4. エージェント向けの開発ルール文書 — AI 駆動開発を使った案件では、プロジェクト固有の決まりを書いた文書が作られている。納品物に含めておけば次の会社がそこから始められる

4 つとも、納品物一覧に書いてあれば渡り、書いていなければ渡らない。止める話をしない発注では、この一覧が作られないまま進む。

6. 発注前に確認する 5 点

止める前提の確認事項として、商談で聞くのは次の 5 つで足りる。答えにくそうな顔をされる質問ではない。まともな会社ほど明確に答える。

聞くこと	意図
「判定日を工程表のどこに置けますか」	判定の場が工程に組み込まれるか
「合格ラインは何の数字で置きますか」	業務側の数字に翻訳できるか
「中途解約の予告期間と精算方法を教えてください」	止める費用の大きさ
「クラウドとツールは誰の名義で、何ヶ月契約ですか」	残債の所在
「止めた場合、何が納品物として渡りますか」	残る資産の範囲

この 5 点の答えは、そのまま見積書と契約書に書いてもらう。口頭の合意は、止める局面でいちばん役に立たない。

受け取った見積書にフェーズの区切りや解約の条件が書かれていない場合は、見積書チェックで共通の指標に当てて不足している項目を確認できる。これから予算を組む段階であれば、費用診断で分野とフェーズごとの目安を出し、フェーズごとの金額に割ってから稟議に載せる順番にしておくとよい。

まとめ

• 止める判断が遅れる原因は技術ではなく、使った金額への未練・言い出しにくさ・判定材料の不在の 3 つ
• 決めるのは 合格ライン・判定日・予算上限の 3 つだけ。見積書と同じ紙に書く
• 判定日に決めるのは続行か中止かではなく、この範囲・この方式で続けるか
• 止めるときの費用は 5 つ（着手済み工数・予告期間・クラウドとライセンスの残債・返還作業・社内の後始末）。ベンダー名義の年契約の残債が見落とされやすい
• フェーズごとに契約を切ると「次を発注しない」で止められる。要件が固まっていない案件ほど効く
• データ・要件定義・評価基準・開発ルール文書は、納品物一覧に書いてあれば止めても残る