「見積書のAI化」ではなく、「価格表（Excel）」「仕様書（PDF）」「図面（DXF/PDF）」「注文書（紙・FAX）」のどれをどの順で対象にするか、支援会社が具体物単位で確認してくるかを見ます。ここが曖昧なまま契約すると、後工程で「思っていたものと違う」というズレが発生します。

受発注システムや生産管理システムなど既存の基幹システムに対して、AI化した結果をどう連携するかの方針です。例えば「AIが読み取った見積データを基幹システムの受注登録画面にどう渡すか」「CSV出力して手動で取り込むのか、API連携で自動反映するのか」を確認しておく必要があります。

「一式○○万円」という提示ではなく、初期のデータ整備費、月額の利用料、契約後の伴走支援費が分かれて説明されるかを確認します。内訳が不透明だと、途中でのスコープ変更に対応できず追加費用が発生しやすくなります。

PoC（Proof of Concept、本格導入前の小規模な効果検証）を「何件のサンプルで」「どの精度で合格とするか」を事前に定義できるかどうかです。合格基準が曖昧なまま進むと、本番投入後に精度不足が発覚しても後戻りできません。

支援会社に運用を丸ごと依存し続けるのか、一定期間後に自社で運用できるように移管するのかは、最初に決めておくべき方針です。移管を前提にした設計と、丸投げを前提にした設計は、画面構成やドキュメントの残し方から異なります。

AIモデルの精度は運用しながら微調整が必要になることが多く、契約後の問い合わせ対応窓口や保守のSLA（サービス品質の保証水準）がどう定められているかを確認します。

最初から全部門・全帳票を対象にするのではなく、まず1つの業務（例：見積書の項目抽出）から始めて、精度と運用が安定したら次の帳票、次の部署へ横展開する計画があるかどうかです。