提案書に並ぶ導入実績は、そのままでは自社の判断材料になりません。確かめるべきは件数や企業名ではなく、「その案件は自社と近い条件だったか」の一点です。データの量と汚れ方、使う人の習熟度、業務の締切、運用を誰が担ったか。この4つが違えば、同じ技術でも結果は別物になります。本記事では、商談の場でそのまま使える7つの質問と、返ってきた答えの読み方をまとめます。
「実績が豊富」はなぜ判断材料にならないのか
AIの受注開発（ベンダーに業務用のAIシステムを作ってもらうこと）の提案書には、たいてい「導入実績◯◯社」「大手製造業A社様」といった記載が並びます。ここで起きがちなのが、件数の多さを実力と読み替えてしまうことです。
しかしAIの成否を分けるのは、技術力よりも前提条件の一致であることが多いのが実情です。たとえば次のような場面を考えてください。ある開発会社が、10万件の整形済みデータを持つ企業で文書分類の仕組みを作り、うまくいった。その同じチームが、紙とExcelが混在し、項目名が部署ごとに違う3,000件のデータしか無い会社で同じ成果を出せるかというと、話は別です。前者で効いたのは、データがすでに整っていたという条件のほうかもしれないからです。
つまり実績は「この会社はできる」の証明ではなく、「どういう条件なら、この会社はできた」の記録です。読み方を変えるだけで、商談の質問が変わります。
「自社と近い条件」とは何を指す？
近さを感覚で判断すると、業種が同じというだけで安心してしまいます。確認すべき軸を分けておくと、提案書を見る目が揃います。
| 軸 | 確かめること | ずれると何が起きるか |
|---|---|---|
| データの状態 | 件数、形式（紙・PDF・表計算・基幹システム）、表記ゆれの有無 | 前処理の工数が見積もりから膨らむ |
| 使う人 | 職種、PCの習熟度、1日あたりの操作回数、交代制かどうか | 作ったが使われない、入力精度が落ちる |
| 業務の制約 | 締切の厳しさ、ミスが許されない度合い、記録の保存義務 | 検証や差し戻しの手順が足りなくなる |
| 運用の担い手 | 導入後に誰が直すか（自社の情報システム部門か、ベンダーか） | 運用費が想定外に増える、改善が止まる |
| 既存システム | 連携先の有無、API（外部から機能を呼び出す仕組み）の提供状況 | 連携部分が後出しで追加費用になる |
この5軸のうち、3つ以上が自社と大きく違う実績は、参考情報として扱うにとどめるのが無難です。
提案書の実績に投げる7つの質問
商談で使う質問を、答えにくい順ではなく、流れが自然な順に並べました。すべてを一度に聞く必要はなく、気になった実績1件に絞って掘るほうが実りがあります。
- その案件で扱ったデータは、何件で、どんな形式でしたか。紙のスキャンが混ざっていたか、入力ルールが統一されていたかまで聞きます。
- 前処理にかかった工数は、全体の何割でしたか。ここが小さすぎる回答は、データが最初から整っていた可能性を示します。
- 実際に毎日使っていたのは、どんな職種の何人でしたか。管理職だけが使うツールと、現場の全員が使うツールでは設計が違います。
- 稼働後、最初の3か月で出た不具合や苦情の上位3つは何でしたか。答えられない会社は、納品後に関わっていない可能性があります。
- 精度はどう測り、どの水準で合格としましたか。「精度90%」のような数字が出たら、母数と測定方法を必ず聞きます。
- その後、どこまで自社側で改修できるようになりましたか。引き継ぎの成否は、運用費に直結します。
- 同じ構成で、うまくいかなかった案件はありますか。理由は何でしたか。これが最も情報量の多い質問です。
5番目の精度の扱いについては、「精度◯%向上」を自社に当てはめる5つの確認点で詳しく整理しています。提案書の数字をそのまま信じない読み方は、実績確認でもそのまま使えます。
返ってきた答えは、どこを見れば良し悪しが分かる？
質問そのものより、答え方のほうが情報を持っています。目安は次の3点です。
- 固有名詞ではなく、条件を語るか。「大手の◯◯様で」ではなく「月間2万件の問い合わせログを、3か月分遡って使いました」のように条件で答える相手は、案件を自分の手で触っています。
- 失敗を言えるか。7番目の質問に「特にありません」と返る場合、関与が浅いか、あるいは振り返りをしていないかのどちらかです。うまくいかなかった理由を具体的に話せる会社は、自社の案件でも早い段階で問題を言ってくれる可能性が高くなります。
- 自社との違いを先に指摘するか。「御社はデータが紙中心なので、この事例とは前処理の工数が変わります」と向こうから言う会社は、見積もりのぶれが小さい傾向があります。
逆に注意したいのが、他社の事例を「手順」としてではなく「成果」として語るパターンです。成果は条件に依存しますが、手順は移植できます。この見方については大企業のAI事例は「手順」だけ真似るでも触れました。実績確認でも、聞き出したいのは成果の数字ではなく進め方です。
「守秘義務で答えられない」と言われたらどうする？
正当な理由で詳細を話せない案件はあります。その場合でも、顧客名を伏せたまま条件だけを語ることはできるはずです。次の聞き方に切り替えます。
- 「社名は不要です。業種、データ件数、利用者数の3つだけ教えてください」
- 「直近1年で、紙の帳票を扱った案件はありましたか。何件規模でしたか」
- 「実際に担当した方に、この場に同席していただくことはできますか」
3つ目は特に有効です。営業担当者が語る実績と、開発担当者が語る実績では、出てくる話の粒度が変わります。提案時のメンバーがそのまま開発に入るとは限らないため、誰が実際に手を動かすのかを確認する機会にもなります。
なお、ベンダーとのやり取りで扱うデータの権利関係や責任分担については、経済産業省が公表している「AI・データの利用に関する契約ガイドライン」が参照先になります。また、開発や提供の進め方全般については、総務省と経済産業省による「AI事業者ガイドライン」が公開されています。契約書の文言に迷ったとき、これらの名称を出して「どの考え方に沿っていますか」と聞くだけでも、相手の準備度合いが見えます。
実績の確認を、契約条件にどうつなげる？
聞いて終わりにせず、分かったことを契約前の取り決めに落とし込みます。実務的には次の3点です。
1. 近い実績が無い領域は、小さく試す段階を分ける。 いきなり本開発に入らず、自社の実データで小規模に検証する期間を設けます。検証の合格基準は、着手前に文書で合意しておきます。検証データの揃え方はAIの検収は自社データ100件で足りるにまとめています。
2. 聞き出した条件差を、見積もりの前提として明記させる。 「データ前処理は、表記ゆれが◯種類以内であることを前提とする」のように書いてもらえば、後から追加費用が出たときに話が噛み合います。
3. 運用フェーズの体制を、実績の中身と突き合わせる。 「納品までは得意だが運用は別会社」という構成なら、月額費用の内訳を先に確認します。
まとめ
提案書の実績を確かめる作業は、相手を疑うためではなく、自社の条件を言語化するためにあります。データの状態、使う人、業務の制約、運用の担い手、既存システム。この5軸で自社を説明できれば、質問は自然に出てきますし、答えの良し悪しも判断できます。
明日からできることは3つです。第一に、提案書の実績欄から1件選び、上記7つの質問のうち3つだけメールで投げてみる。第二に、自社の5軸を1枚にまとめ、商談の冒頭で相手に渡す。第三に、返ってきた答えのうち「条件を語ったもの」と「成果だけを語ったもの」を分けて記録する。この3つを2〜3社で繰り返すと、会社ごとの違いが比較できる形で残ります。実績の件数ではなく、条件の近さで選ぶ。それが、後から揉めない開発の出発点になります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
