AI開発会社は何を基準に選べばよいですか？
結論から言うと、「業務理解にどれだけ工数を割く体制か」と「できないことを先に言うか」の2点です。技術スタックや実績社数よりも、この2つのほうが導入後に使われるかどうかを左右します。
不動産・建設の業務は、同じ「契約書作成」「工事写真整理」でも、会社ごとに手順・帳票・チェック順序が違います。レインズの物件番号をどこに控えるか、マイソクの間取り図を誰が差し替えるか、グリーンファイルの提出先が元請ごとにどう違うか。この差分を拾わずに作られたシステムは、動くけれど使われません。
以下、発注前に確認すべき10項目を、確認する順序で示します。
発注前に確認すべき10のチェック項目は？
| # | チェック項目 | 相手に投げる具体的な質問 |
|---|---|---|
| 1 | 現場に来るか | 「実際の入力作業を横で見る時間は、見積のどこに入っていますか」 |
| 2 | 業務理解の工数が工程に入っているか | 「要件定義に何日、そのうち現場観察は何日ですか」 |
| 3 | できないことを先に言うか | 「この業務でAIが外すのはどのケースですか」 |
| 4 | 対象業務を絞る提案をするか | 「最初にやる業務を1つ選ぶとしたらどれで、理由は何ですか」 |
| 5 | 入力データの状態を確認したか | 「実際の帳票を10件見せたら、何件が非定型でしたか」 |
| 6 | 連携方式を具体的に言えるか | 「既存システムはAPIがありますか。無い場合の代替案は」 |
| 7 | 精度の合格基準を決めるか | 「何%を合格とし、その測り方は何件でどう検証しますか」 |
| 8 | 外れたときの人手フローを設計するか | 「AIが自信を持てない出力は、誰がどの画面で直しますか」 |
| 9 | 運用開始後の変更対応の体制があるか | 「帳票様式が変わったとき、誰が何日で直しますか」 |
| 10 | 権利とデータの扱いが明記されているか | 「ソースコードの帰属と、契約終了時のデータ返還形式は」 |
項目1〜3：業務理解のプロセスはどう確認しますか？
確認方法は「見積書の工程表に現場観察の日数が書かれているか」を見ることです。
会議室でのヒアリングだけでは、実務の分岐は出てきません。担当者は「いつもやっていること」を言語化できないからです。「その物件は特殊なんで手で直してます」という例外処理は、横で画面を見ていて初めて出てきます。
エクサテックが株式会社イーリアルティ様に構築した転記エージェントでも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。同社は業務マニュアルが未整備でしたが、転記そのものを自動化したことで、マニュアルを作る必要自体が減りました。「まずマニュアルを整備してから」と言われた場合、それが本当に必要かは疑ってよい論点です。
項目3（できないことを先に言うか）は、最も見分けがつきやすい指標です。 「AIで全部できます」と答える会社は、入力データを見ていない可能性が高いです。実務では、手書きメモ・FAX受信の物件概要書・元請ごとに様式が違う安全書類など、精度が落ちる領域が必ずあります。ここを最初に切り分けて説明できるかどうかで、後の手戻りが変わります。
項目4〜6：データと連携の現実はどう確認しますか？
発注側の準備として、実際の帳票・データを10〜20件、匿名化して提示してください。 提案の質はこれで一気に見分けられます。
確認すべき論点は3つです。
- 入力の形式：PDF（テキスト埋め込みあり／スキャン画像）、Excel、紙、FAX、メール本文のどれか。スキャン画像と手書きが混ざる場合、OCRの誤読前提の設計が必要になります。
- 様式のばらつき：同じ帳票でも取引先ごとに項目位置が違うか。10件見て何パターンあるかを数えてください。
- 連携先：基幹システム、kintone、Salesforce、自社Accessなど。APIの有無と、無い場合の代替案（CSVインポート、画面自動操作、DB直参照）を具体名で答えられるかを確認します。「連携できます」だけの回答は、調査していないサインです。
項目7〜8：精度と検証の設計はどう確認しますか？
「精度が高いです」と言う会社ではなく、「何を合格とするか」を発注側と一緒に決める会社を選んでください。
実務上決めるべきは次の4点です。
- 合格基準の対象（全項目一致か、金額・氏名・住所など重要項目のみか）
- 検証件数と検証時期（本番前に何件、稼働後1か月で何件）
- 自信度が低い出力の扱い（人手確認に回すか、そのまま出すか）
- 修正の導線（どの画面で、誰が、どれくらいの時間で直せるか）
特に重要事項説明書のような法定書面は、宅地建物取引業法第35条により宅地建物取引士の記名が必要です（2022年5月18日の改正で押印は不要となり記名のみ）。AIが下書きを作る場合も、最終的な内容の確認と責任は有資格者が負う設計にする必要があります。ここを曖昧にする提案は避けてください（法令解釈は個別案件ごとに専門家にご確認ください）。
工事写真の分類も同様です。国土交通省「デジタル写真管理情報基準」（令和5年3月）では、写真を「写真区分→工種→種別→細別」の階層で管理し、入力の要否は写真区分により異なります。AIで一次分類まで自動化できても、基準への適合可否の最終判断は発注者・監督員が行うという前提を、設計時に共有しているかを確認してください。
項目9〜10：運用と権利関係で何を聞きますか？
稼働後の変更対応の体制と、成果物の権利帰属を、契約前に書面で確認します。
不動産・建設の業務は、帳票様式・法令・元請の提出ルールが変わります。確認すべきは以下です。
- 様式変更時の対応窓口と、想定リードタイム
- 変更対応が保守契約の範囲内か、都度見積か
- ソースコードの著作権帰属
- 処理・学習に使った自社データの取り扱いと、外部サービスへの送信有無
- 契約終了時のデータ返還形式（CSV・データベースダンプ等）
また、「誰が使うか」を確認しているかも見てください。ベテラン事務担当者と、入社1年目のスタッフでは必要な画面が違います。使う人を特定せずに作られたシステムは、結局ベテランの手作業に戻ります。
提案書・見積書のどこを見ればよいですか？
比較の前に、全社に同じ前提条件を渡してください。 前提が違う見積は金額だけ並べても意味がありません。渡すべきは次の6点です。
- 対象業務名（例：レインズ登録用データの転記）
- 月間の処理件数
- 入力データの形式と実サンプル
- 連携先システム名とAPIの有無
- 精度の合格基準（決められなければ「一緒に決めたい」と伝える）
- 検証・修正を担当する人と、その人が割ける時間
そのうえで見積書の内訳を見ます。要件定義・業務調査の工数が全体の1〜2割未満しかない見積は、現場に入る前提になっていない可能性が高いです。逆に、保守・変更対応の条件が空欄の見積も、稼働後にトラブルになりやすい形です。
費用と期間の目安はどう考えればよいですか？
金額は、次の4つの変数でほぼ決まります。逆に言うと、この4つが決まらないうちの概算は幅が大きくなります。
| 変数 | 費用が上がる方向 |
|---|---|
| 対象業務の種類数 | 1業務→複数業務に広げると増える |
| 入力データの状態 | 定型Excel < 定型PDF < 非定型PDF < 手書き・FAX |
| 既存システム連携 | 連携なし < CSV連携 < API連携 < APIが無い基幹システム |
| 求める精度 | 人手確認前提 < 自動確定（検証工数が増える） |
小さく始めるなら、「件数が多く」「手順が固定されており」「間違えても取り返しがつく」業務を1つ選ぶのが定石です。契約書の最終版作成のような、誤りが即座に損害になる業務から始めるのは推奨しません。
この選び方でも防げないこと・AI開発の限界は？
チェック項目を満たしても、次のことは解決できません。発注前に理解しておいてください。
- 元データが存在しない業務は自動化できません。 担当者の頭の中にしかない判断基準（この客付業者は反応が早いから先に出す、等）は、まず言語化の作業が必要です。
- 手書き・FAX・崩れたスキャンの読み取りは100%になりません。 誤読を前提に、人が確認する導線を作るのが現実解です。
- 法的責任はAIに移せません。 重要事項説明書、建設業法上の契約書面、工事写真の基準適合判断など、資格者・監督員の確認が要る領域は、下書き作成までが自動化の範囲です。
- 入力の質が悪いまま自動化すると、間違いが速く増えるだけです。 転記元のデータが崩れている場合、先に入力側を直す必要があります。
- 使う人が決まっていない仕組みは定着しません。 これは開発会社側だけでは解決できず、発注側の担当者アサインが要ります。
まとめ
- AI開発会社の選定は、技術力より「業務理解の工数」と「できないことを先に言うか」で判断する
- 見積書に現場観察の日数が書かれているかを最初に確認する
- 相見積もりの前に、対象業務・件数・データ形式・連携先・精度基準・検証担当者の6点を全社に同じ条件で渡す
- 精度は「高い／低い」ではなく、合格基準・検証件数・外れたときの人手フローをセットで設計させる
- 法定書面や工事写真の基準適合は、最終判断を有資格者・監督員が行う設計にする（個別の法令解釈は専門家にご確認ください）
よくある質問
Q. AI開発会社を選ぶとき、最初に確認すべきことは何ですか？
A. 「業務の現場に来て、実際の作業を観察する工程が見積に含まれているか」です。不動産・建設の業務は会社ごとに手順が違い、ヒアリングだけでは実態が拾えません。現場観察の日数が提案書に書かれているかを最初に確認してください。
Q. 提案書で「できないこと」を書かない会社は避けるべきですか？
A. 避けたほうが安全です。AIは入力データの状態に精度が左右されるため、手書き・FAX・非定型帳票では必ず限界が出ます。限界と、外れたときの人手フローを最初に説明する会社のほうが、運用開始後の手戻りが少なくなります。
Q. 相見積もりを取るとき、何を揃えれば比較できますか？
A. 対象業務名・月間件数・入力データの形式（PDF/Excel/手書き/FAX）・連携先システム名とAPIの有無・精度の合格基準・検証担当者の4点を揃えて提示してください。この前提が揃わない見積は金額だけ見ても比較になりません。
Q. 大手のシステム会社と小規模な開発会社では、どちらが向いていますか？
A. 規模より「誰が現場に来るか」で判断してください。要件定義と実装の担当者が分かれる体制では、現場で見た違和感が実装に反映されにくくなります。設計者が自分で実装まで行う体制かどうかを確認するのが実務的です。
Q. 開発したシステムのソースコードやデータは自社のものになりますか？
A. 契約で決まるため、事前に確認が必要です。ソースコードの著作権帰属、学習・処理に使った自社データの取り扱い、契約終了時のデータ返還形式（CSV等）の3点を、発注前に書面で確認してください。
ご相談について
エクサテックは、不動産・建設業の現場に入り、仕組み設計からWebアプリ構築までを同一チームで担当しています。「どの業務から手をつけるべきか分からない」という段階でも構いません。実際の帳票やデータをお見せいただければ、自動化できる範囲とできない範囲を切り分けてお伝えします。
