基幹システムの入れ替えなら何度か発注したことがある。でも今回はじめてAIを使う仕組みを作らせることになった。いつものやり方――提案依頼書を出して相見積もりを取り、請負契約で総額を決めて、納品されたら仕様どおり動くかを確認する――が、そのまま通じるのだろうか。この不安はもっともです。結論から書くと、通じません。そして違いは技術的な話ではなく、発注の手続きそのものに出ます。調べると「ルールを人が書くか、データから学ばせるか」という説明はよく出てきますが、それが自分の見積書や契約書にどう跳ね返るのかまで書いてある記事は少ないです。この記事では、違いの根っこを1つに絞ったうえで、見積もり・契約・検収・社内稟議がどう変わるのかを並べます。
この記事のポイント
- 違いの根っこは1つで、仕様を先に書き切れるかどうかに集約される
- 仕様が書けないので見積もりは総額提示にならず段階提示になる
- 請負が使いにくく準委任になりやすいので検収の決め方も変わる
- 社内稟議は総額いくらの投資ではなく段階ごとの判断として通す
目次
AI開発とシステム開発の違いはどこにあるか
違いの根っこは仕様が書けるかどうか
先に一番大事なところを書きます。この2つを分けているのは、着手する前に「何を作るか」を文章で書き切れるかどうか、この1点です。
通常のシステム開発なら書き切れます。受注画面に項目が12個あって、在庫を引き当てて、この条件のときは警告を出す。全部を日本語で書けます。書けるから工数が計算でき、計算できるから総額を先に決められ、決められるから「仕様どおり動くか」で受け取れます。発注の手続きが成立しているのは、この最初の一手があるからです。
AIを使う仕組みは、ここが成立しません。たとえば伝票の読み取りを自動化するとして、「正しく読める」の中身が着手前には決まりません。手書きの崩れた文字はどうするのか、かすれた印影は読めたと言えるのか。やってみて結果を見るまで、どこまでできるか分からないのです。
この先に出てくる違いは、ほぼ全部この1点から派生します。技術の話として覚える必要はありません。「仕様が先に書けない」という前提が、見積もりと契約と検収を全部ずらしていく、と押さえておけば十分です。
できあがるものが確率で返ってくる
もう少し具体的に書きます。通常のシステムは、同じ入力を入れれば必ず同じ答えが返ります。返らなければ不具合です。
AIは違います。返ってくるのは「たぶんこれ」という確率です。100件のうち92件は正しく、8件は間違う。この8件は不具合ではなく、精度の問題として扱われます。ここが発注側にとって、いちばん飲み込みにくい部分だと思います。
飲み込みにくい理由は、いつもの発注だと「間違うなら直してもらう」で済んでいたからです。AIでは「どこまで間違ってよいか」を先に決める話になります。精度がどこまで上がるのか、なぜ100%にならないのかはAI開発の品質と精度が100%にならない理由で詳しく扱っています。
主役がコードではなくデータになる
通常のシステム開発では、腕のいい開発会社に頼めば良いものができます。腕がそのまま品質になります。
AIでは、結果を決めるのは自社が持っているデータです。どれだけ優秀な開発会社でも、材料が足りなければ精度は出ません。ここは発注側にとって重い話です。品質の一部を自分たちが握っているということですから。
そして、データは「ある」だけでは足りません。使える状態かどうかが問われます。部署ごとに入力形式が違う、紙が混じっている、過去1年分しか残っていない、どれが正しい処理だったかの記録がない。こうした状態だと、整えるところから始まります。
使える状態かどうかは、自分で確かめられます。対象の業務で使っている台帳から直近1か月分をそのまま出してみてください。列がそろっているか、空欄がどれくらいあるか、同じ意味の値が違う書き方になっていないか。それを見れば状態はだいたい分かります。半日で終わる作業ですが、開発会社との初回の打ち合わせの中身がまるごと変わります。
とくに見落としやすいのが正解の記録です。伝票の読み取りを自動化したいなら、「この伝票をどう処理したのが正しかったか」の記録がないと、精度を測る基準が作れません。記録が残っていなければ、現場の担当者に何百件か手作業で付けてもらうところから始まります。
この作業は開発会社に頼むこともできますが、中身を知っているのは自社の現場です。結果として自社側の宿題になり、工程表には載りません。
納品して終わりにならない
もう1つ、運用の形が変わります。
通常のシステムは、納品されたら安定稼働に入ります。保守は不具合対応と法改正対応が中心で、放っておいても性能は落ちません。
AIは、扱うデータが変われば精度が落ちます。取引先が増えた、伝票の様式が変わった、新しい商品カテゴリができた。こうした変化のたびに学習し直す必要があります。保守ではなく育成に近い作業です。
頻度の目安を持っておくと、開発会社との会話が具体的になります。扱うデータの変化が緩やかな業務なら年に1〜2回、取引先や様式が頻繁に変わる業務なら四半期ごとに見直す、といった形です。これも一般的な目安なので、実際の判断は個別の見積もりで確認してください。
ですから見積もりを取るときは、作る費用だけでなく「作ったあと誰がどのくらいの頻度で手を入れるのか」まで聞いてください。ここが空白のまま契約すると、精度が落ちた状態で使い続けることになります。
AI開発とシステム開発の違いで発注はこう変わる
見積もりが総額提示にならない
ここからが発注実務の話です。まず見積もりの形が変わります。
仕様が書き切れないので、開発会社は総額を出せません。出せたとしても、それは余裕を多めに乗せた金額か、範囲を極端に狭めた金額のどちらかです。実際には「まず検証に200万円、その結果を見て本開発の金額を出します」という段階提示になります。
発注手続きの違いを並べると、次のようになります。
| 項目 | 通常のシステム開発 | AIを使う開発 |
|---|---|---|
| 仕様 | 着手前に文章で確定できる | 精度が出るまで確定できない |
| 見積もり | 総額を先に固定しやすい | 段階ごとに提示される |
| 契約 | 請負を使いやすい | 準委任になりやすい |
| 検収 | 仕様どおり動くかで判定 | 先に決めた合格ラインで判定 |
| 社内稟議 | 総額いくらの投資として通す | 段階ごとの判断として通す |
段階提示を受けたときに確かめたいのは3つです。1つ目は、その段階で何が分かるのか。2つ目は、次の段階に進む条件は何か。3つ目は、進まないと判断した場合に何が残るのか（データの整備結果や検証の記録は手元に残るのか）。3つ目を聞いておくと、止めたときに何も残らないという事態を避けられます。
相見積もりの取り方も変わります。総額で並べて安い順に見ることができないので、「どの範囲をいくらでやるか」を同じ条件にそろえてから比べる必要があります。ここをそろえないまま比べると、範囲の狭い提案がいちばん安く見えてしまいます。
請負が使いにくく準委任になりやすい
契約の形も変わります。請負は「完成させること」を約束する契約なので、何が完成なのかを定義できないと使いにくいのです。
そのため、検証の段階は準委任で進めることが多くなります。準委任は作業を提供する契約なので、成果物の完成を保証しません。ここで発注側が身構えるのはもっともですが、仕様が書けない段階で請負を求めると、開発会社はリスク分を金額に乗せるか、範囲を極端に絞るかのどちらかになります。どちらも発注側の得にはなりません。
現実的な形は、検証は準委任で進めて、精度の見通しが立ってから本開発を請負にする、という切り替えです。請負と準委任のどちらをどの段階で使うかはAI開発の委託契約で発注者が損しない選び方で条項レベルまで整理しています。
検収が仕様どおりの確認にならない
検収のやり方も変わります。仕様書と突き合わせて○×を付ける、といういつもの方法が使えません。
代わりに必要なのは、着手前に合格ラインを決めておくことです。「この100件のサンプルで、正しく読める率が90%を超えたら合格」のように、判定できる形にしておきます。ここを決めずに始めると、結果が出たあとで「これは合格なのか」を社内で議論することになり、判断だけで1か月かかることも珍しくありません。
合格ラインを決めるときの落とし穴は、数字だけ決めて条件を決めないことです。どのサンプルで測るのか、誰が正解を判定するのか、届かなかったら何回までやり直すのか。ここまで書いて初めて検収の基準になります。
自社側の準備がどこまで整っているかを先に点検するなら、AI導入準備度チェックリスト（6領域50項目）でデータや運用の抜けを洗い出せます。見積もりを取る前に埋めておくと、開発会社との往復が減ります。
社内稟議の通し方を変える
最後に、社内での通し方です。ここを間違えると、途中で止められなくなります。
いつもの稟議は「総額3,000万円で3月納品」という形で通します。AIで同じ書き方をすると、検証と本開発をつなげた予定と金額を最初に承認してもらうことになります。すると、検証の結果が悪かったときに止めるという選択が取りづらくなります。すでに全体で承認されているからです。
私が勧めているのは、稟議を検証までで区切ることです。「まず3か月と200万円で、この条件に届くかを確かめる。届いたら本開発の予定と金額を改めて出す」という形にします。止める判断を最初から設計に入れておくわけです。
段階を区切ると期間の説明も変わります。稼働日を1つ約束するのではなく、検証の結果が出る日を約束する形になります。期間の目安と、なぜ読めない区間があるのかはAI開発の期間はどれくらいかにまとめています。
- Q. いつもの提案依頼書をそのまま使えますか？
- A. 骨組みは使えますが、2か所を足してください。1つは対象データの状態（形式・件数・過去何年分・正解の記録があるか）、もう1つは合格ラインの案です。この2つがないと、各社が別々の前提で見積もりを出してくるので比較になりません。
- Q. 準委任だと言われたら断るべきですか？
- A. 検証の段階なら不自然ではありません。むしろ仕様が書けない段階で請負を求めると、リスク分を金額に乗せられるか範囲を絞られるかになります。断るかどうかより、「次に進む条件」と「進まなかった場合に手元に残るもの」を契約書に書いてもらうかどうかで判断してください。
- Q. 通常のシステム開発の会社に頼んでもよいですか？
- A. 実績があるかどうかで判断してください。判定に使えるのは「精度が目標に届かなかった案件で、そのあとどうしたか」という質問です。届かなかった経験を具体的に話せる会社は、合格ラインの決め方や打ち切りの判断にも慣れています。
