AI を使った業務システムの引き合いが増え、提案書には「AI で自動化できます」「精度 95% です」といった言葉が並ぶようになりました。しかし発注側から見ると、その言葉が実現可能性のある約束なのか、デモ環境限定の話なのかを判断する材料がありません。価格と納期だけで比べると、安く見えた提案が後から追加費用で膨らむことも起こり得ます。
ここでは、提案を見比べるときに「聞けば差が出る」質問を、デモと本番の差・精度の根拠・データの扱い・保守の範囲の4領域に絞って整理します。技術に詳しくなくても使える質問ばかりです。
なぜ「AI でできます」は確かめにくいのか
従来の業務システムは、仕様書に書いた動作が「その通りに動くか」で合否を判定できました。入力 A に対して出力 B が返る、という決まった対応関係があるからです。
一方、生成 AI や機械学習を使った機能は確率的です。同じ入力でも出力が揺れますし、学習に使われていない種類のデータが来れば精度が落ちます。つまり「できる／できない」の二択ではなく、「どういう条件で、どれくらいの割合で、どこまでできるか」という幅のある話になります。
この幅を提案書に書かないベンダーは、悪意がなくても後で揉めます。発注側がやるべきことは、幅を言語化させることです。以下の質問は、そのための道具だと考えてください。
デモと本番の差を聞く
提案時のデモは、たいてい最も条件の良いデータで作られています。きれいにスキャンされた帳票、整った日本語の問い合わせ文、代表的な5件のサンプル。本番で流れてくるのは、手書きの追記が入った FAX、途中で切れた音声、社内でしか通じない略語です。
聞くべきはこの3つです。
- 「このデモで使ったデータは、弊社の実データですか。何件ですか」 — 自社データを渡していないなら、デモの結果は参考値にすぎません。
- 「うまくいかなかったケースを見せてください」 — 失敗例をすぐ出せるベンダーは、既に境界を把握しています。「ほぼ失敗しません」という回答が返ってきたら、検証量が足りていない可能性が高いと考えられます。
- 「本番相当のデータで試すには、何を渡せばよいですか」 — 着手前に小規模な検証を挟む提案ができるかどうかで、実務経験の差が出ます。
この段階での見極めは、AI の PoC が本番に乗るかどうかは、着手前に決める 3 つのことで ほぼ決まるで整理した観点とも重なります。小さく試す工程を提案に含めているかは、ひとつの判断材料になります。
精度の根拠を聞く
「精度95%」という数字そのものには、ほとんど情報がありません。確かめるべきは、その数字がどうやって算出されたかです。
- 「何件のデータで測りましたか。その内訳は」 — 20件で19件正解でも95%です。件数と、どんな種類のデータが何件ずつ入っていたかを聞きます。
- 「正解をどう定義しましたか。誰が判定しましたか」 — 要約や分類のように正解が一意でない業務では、判定基準そのものが成果物の一部です。
- 「間違える方向はどちらですか」 — 見逃し（本当は該当するのに拾わない）と、過剰検出（該当しないのに拾う）では、業務への影響がまったく違います。請求の検品なら見逃しが致命的、問い合わせの振り分けなら過剰検出が現場の負担になります。
- 「納品後、精度が落ちたことをどう検知しますか」 — 測る仕組みが提案に入っていなければ、劣化は誰も気づきません。
精度を継続的に測る土台として、評価用のデータセットを納品物に含めるかどうかは必ず確認したいところです。考え方はAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用にまとめています。
データの扱いを聞く
ここは技術の話というより、契約と責任分界の話です。曖昧なまま進めると、後から情報システム部門や取引先の監査で止まります。
| 確認項目 | 聞き方の例 | 危ない回答 |
|---|---|---|
| 学習への利用 | 入力したデータが、提供元のモデル学習に使われない設定になっていますか | 「大丈夫です」だけで、設定名や契約上の根拠を示せない |
| 保存場所 | データはどの国のどのサービスに、何日間残りますか | 「クラウドなので安全です」 |
| 再委託先 | どの事業者を経由しますか。一覧を出せますか | 一覧が出てこない、または「弊社が全部やります」の一点張り |
| 個人情報 | 個人情報を含む場合の取り扱いは、委託契約でどう定めますか | 個人情報保護法上の位置づけに触れられない |
| ログ | 入出力のログは誰が見られますか。削除依頼に応じられますか | ログ設計の話が出ない |
国内では個人情報保護法のほか、事業者が参照できる指針として総務省・経済産業省による AI 事業者ガイドラインが公表されています。発注側がこれらを読み込む必要はありませんが、「どの指針を参照して設計しましたか」と一言聞くだけで、整理している会社とそうでない会社の差が出ます。回答で名称が出てくるかどうかを見てください。
保守の範囲を聞く
AI 機能の保守は、従来のシステム保守と性質が違います。コードを変えていないのに、外部モデルの更新で挙動が変わることがあるからです。提供元がモデルを新版に切り替えたり、旧版の提供を終了したりするのは珍しくありません。
そこで、次の4点を見積もり段階で確認します。
- モデルが更新・終了したときの対応は、保守費に含まれますか、別見積もりですか
- 切り替えのとき、以前と同じ結果が出るかをどう確認しますか（確認用のテスト一式が納品物にあるか）
- 精度が下がったときの改善は、何回まで、どこまでが範囲ですか
- 利用料（API の従量課金など）は誰が契約し、誰が監視しますか
特に1と3は、同じ「月額保守」でも会社によって中身がまったく違う部分です。この論点はAI機能の保守費は「モデルが変わる日」を先に見積もるで詳しく扱っています。
たとえば次のような場面です。契約1年目は問題なく動いていたが、外部モデルの旧版提供終了が告知され、切り替え後に出力の書式が微妙に変わって後続処理がエラーになる。このとき「保守に含む」と書いてあれば追加費用は発生しませんが、「別途お見積もり」なら想定外の支出になります。契約書の文言を先に読み合わせておくだけで防げます。
提案を横に並べて比べる
質問は多いほどよいわけではありません。回答が返ってきたら、次の軸で整理すると差が見えます。
| 軸 | 良い提案の特徴 |
|---|---|
| できないことの明示 | 対象外の書類・ケースを具体的に列挙している |
| 測り方 | 合否の判定方法と件数が書かれている |
| 人の関与 | AI の出力を誰がどの段階で確認するかが設計に入っている |
| 段階分け | 検証→小規模導入→拡大、と工程が分かれている |
| 費用の変動要因 | 処理件数や文字量で費用がどう変わるかを説明できる |
「できないこと」を自分から言うベンダーは、一見すると弱気に見えます。しかし発注側にとっては、境界を把握している相手のほうが見積もりの精度が高く、結果として総額が読みやすくなります。
まとめ
AI を使った受注開発で発注側が確かめるべきことは、技術の優劣ではなく幅の言語化です。どの条件で動き、どこから外れ、外れたときに誰が何をするか。この3点が提案書に書かれていれば、その会社は本番運用を経験しています。
最後に、発注前に必ず聞きたい質問を再掲します。
- デモは自社データで、何件試したか。失敗例を見せられるか
- 精度の数字は、何件のデータで、誰がどう正解を判定したか
- 間違える方向（見逃しか過剰検出か）はどちらか
- データの保存場所・学習利用の可否・再委託先を書面で出せるか
- モデルが更新・終了したときの対応は保守費に含まれるか
- 精度低下をどう検知し、誰が直すか
どれも専門知識がなくても聞けます。そして、この6問に具体的に答えられるかどうかで、提案の中身は驚くほどはっきり分かれます。価格表を比べる前に、まずこの質問を投げてみてください。