この記事で分かること
- 提案や実績紹介からは分かりにくいAI開発会社のリスク
- 精度・費用・データ・権利について契約前に合意する内容
- 担当者への質問を、判断できる証拠や成果物につなげる方法
- 未解決事項を残したまま本番開発へ進めないための進め方
会社の印象ではなく、確認可能な約束で判断する
「大手だから安心」「担当者が技術に詳しい」「価格が高いから品質も高い」といった印象は、発注判断の一部にすぎません。会社としての実績が十分でも、今回の案件に参加する人や利用する仕組みが違えば、確かめるべき内容も変わります。反対に、小規模な会社でも、担当範囲と限界を説明し、引継ぎや復旧まで準備できるなら、検討に値する場合があります。
見たいのは、質問への返事の速さだけでなく、その返事を仕様書や見積条件へ反映できるかです。「できます」という回答には、対象データ、必要な準備、できない処理、費用に含む範囲を添えてもらいます。まだ分からないことを認め、確認方法を提案する姿勢も判断材料になります。
以下の8項目は、特定企業の良し悪しを決めつけるものではありません。各項目に未確認事項があるとき、誰がいつまでに何を示せば解消するのかを整理するための見方です。契約条項の法的な意味や責任範囲は、実際の契約案と業務内容に合わせて法務担当者などと確認してください。
リスク：実績の見せ方と実際の担当能力が一致しない
完成した画面より、担当範囲と運用後の経験を聞く
立派なデモでも、公開データを使った試作品なのか、顧客が日々使うシステムなのかで意味が違います。実績紹介では、開発会社が担当した部分を尋ねましょう。画面の制作、AIモデルとの接続、データ整備、権限設計、運用保守のうち、どこまで自社で担ったかを分けると、今回必要な能力との違いが見えてきます。
例えば社内文書検索を依頼するなら、回答文の自然さに加え、退職者の利用停止や部署別の閲覧制限を扱った経験を聞きます。顧客名を出せない場合でも、匿名化した構成図や、発生した問題と修正内容の説明はできるか相談できます。守秘義務で公開できないこと自体を危険と決めつけず、別の方法で能力を確認するのが公平です。
商談には、契約後に設計を担当する人の同席を求めてみてください。営業担当者の説明と設計担当者の認識が食い違うなら、開始前にそろえる必要があります。提案書には主要担当者の役割、参加する工程、交代時の手順を記載してもらい、人物への信頼をチームとしての約束に変えます。
開発のどこまでを依頼するか整理できていない場合は、AI受託開発・生成AI導入支援の対応範囲を参考に、検証、既存システム連携、本番開発、運用を分けて相談すると比較しやすくなります。
リスク：精度の説明が曖昧で、検収時に合意できない
正解率だけでなく、重大な失敗と評価条件を定義する
「高精度です」という表現だけでは、自社業務で使えるか判断できません。例えば問い合わせ回答支援で、文章が読みやすくても返品条件を取り違えるなら、その誤りは見逃せません。挨拶の表現が多少違うことと、金額や期限を誤ることを同じ重さで数えると、平均値のよさに重要な問題が隠れます。
契約前に、評価する質問、参照してよい資料、正しい回答の条件、回答できないときの動作を決めます。例として、一般的な質問、資料に答えがない質問、古い規程が混ざった質問、権限外の情報を求める質問を用意すると、普段のデモでは見えない違いを比較できます。これは検証用の設計例であり、すべての案件に共通する合格基準ではありません。
開発調整で繰り返し使った問題だけで最終評価をすると、その問題に合わせた改善の影響を受けます。調整用と最終確認用のデータを分け、誰が回答を採点するかも合意しましょう。データの持ち出しに制限があるなら、発注側の環境で評価する段取りを先に用意します。
検収条件には、対象機能、利用人数や同時利用の条件、応答時間の測り方、再試験の扱いを含めます。検証段階で目標へ届かなかった場合の成果物や終了条件と、本番開発で完成を求める範囲は分けてください。検証契約だから何も残らなくてよいわけではなく、評価結果、失敗例、次の改善案が判断材料になります。
リスク：データの行き先と利用範囲が分からない
入力から削除まで、保存先ごとに確認する
「学習に使わないので安心」という説明だけでは、データ管理の確認は終わりません。学習への利用と、処理のための送信、ログの保存、障害調査時の閲覧は別の論点です。自社の文書がどのサービスを通り、誰の契約で利用され、どこに複製が残るかを構成図にしてもらいます。
具体的には、元のファイル、検索用に分割した文章、検索用のデータ、入力した質問、生成した回答、操作ログを対象にします。「ファイルを削除した」ときに検索用データも更新されるのか、バックアップに残る分はどう扱うのかまで確認すると、退職者情報や終了した案件の資料を消す運用を設計できます。
文書検索では、ログインできるかだけでなく、利用者ごとに見せてよい文書を絞れるかが重要です。画面に原本が表示されなくても、回答に権限外の内容が混ざれば情報は伝わってしまいます。検索対象を選ぶ段階で権限を反映する設計と、権限のない利用者からの試験を依頼しましょう。
また、取り込む文書や検索結果に悪意ある指示が含まれ、AIがそれに影響される攻撃も確認対象です。対策は注意書きだけに任せず、AIから実行できる操作を制限し、重要な処理は人の承認を挟むなど、業務への影響を抑える設計を検討します。安全性について「絶対に起きない」と言うより、想定する攻撃と残るリスクを説明できる会社かを見てください。
リスク：初期見積は安くても総費用が読めない
利用量と変更内容を分けて、追加費用の条件を明示する
AIシステムの費用比較では、開発費だけを横に並べると判断を誤る場合があります。見積にデータ整理、既存システムの接続、利用者管理、監視、操作説明が含まれるかを確かめます。同じ「文書検索」という名称でも、対象ファイルの形式や更新方法が違えば作業量は変わります。
運用費は、固定費と利用量で増える費用に分けて提示してもらいましょう。AIへの問い合わせ、文書の読み取り、検索基盤、ログの保存など、どこで課金が生じるかを把握します。通常時に加え、部署追加や大量の文書更新がある場合の試算を依頼すると、使い始めてからの予算調整がしやすくなります。
費用の上限を決めるなら、超過を知らせるだけか、処理を止めるかも選びます。上限到達で全員が利用できなくなると困る業務では、優先する利用者や代替手順が必要です。金額の設定だけで終わらせず、現場の動きとセットで考えてください。
追加開発は、依頼前に影響範囲、金額、納期を提示し、承認後に着手する流れを文書化します。「この程度なら含まれると思った」という行き違いを減らすには、初期対象外の機能を明示するのが有効です。詳しい見積項目を整えるときは、AI受託開発会社の選定でRFPに入れるべき項目も合わせて確認できます。
リスク：成果物の権利と利用条件が曖昧なまま残る
所有するものと、利用許諾で使うものを分ける
「納品物は御社のものです」と言われても、それだけで他社への保守移管や改変が可能とは限りません。アプリケーションのコード、設定、プロンプト、評価データ、設計書、学習済みモデルなど、何を引き渡すかを一覧化します。汎用部品や外部サービスを利用する場合は、その部分の権利や条件を分けて確認します。
発注者がすべての権利を取得することだけが正解ではありません。開発会社の既存部品を利用することで費用や期間を抑えられる場合もあります。ただし、その部品を契約終了後も使えるか、別の保守会社に必要な範囲で扱わせられるか、利用料が追加で発生するかを合意しておきます。
自社が提供するデータについても、今回の開発以外への利用、別案件への転用、評価結果の実績公開を別々に扱ってください。機密情報を含む入力や出力を、開発会社の改善用途へ使ってよいかは、納品物の権利とは異なる問題です。利用目的、対象、期間、許可する相手を明記すると確認漏れを減らせます。
生成した文章や画像を社外へ出す予定なら、外部AIサービスの利用条件に加え、公開前に誰が内容を確認するかを決めます。権利侵害がないことを一律に保証する説明をうのみにせず、問題の申立てがあったときの連絡、調査協力、利用停止の扱いも契約案で確認しましょう。
リスク：再委託や担当者への依存が見えない
会社の人数より、知識と権限の引継ぎ方を確かめる
提案時には窓口が一人でも、設計、開発、データ加工を別会社が担当することがあります。再委託そのものを避けるのではなく、担当範囲、情報へアクセスする人、品質確認の責任者を把握します。委託先の変更時に通知されるか、機密情報を扱う条件が引き継がれるかも確認事項です。
特に注意したいのは、設定や運用手順を一人だけが理解している状態です。その人の不在時に、誰が障害を調べ、どの記録から復旧するかを質問してください。設計書が存在するという返答に加え、変更のたびに更新する担当者と保管先まで聞くと、書類が形だけになっていないか判断できます。
管理者アカウントを個人のメールアドレスで作り、その人しか支払い情報や復旧手段を知らない構成も避けたいところです。発注側が管理すべきアカウント、開発会社に委ねる権限、緊急時にアクセスを解除する手順を整理しましょう。共有パスワードを配るのではなく、個人別の権限と操作記録を持てる方法を検討します。
リスク：稼働後の誤回答や障害の責任が宙に浮く
保守の「対応します」を、連絡と復旧の手順にする
AIシステムでは、画面が正常に表示されていても、参照文書の更新漏れなどで回答品質が悪化することがあります。サーバーの稼働監視と、業務で使える回答が出ているかの確認は分けて考えます。利用者が誤回答を報告する入口と、報告を見て改善対象を決める担当者を設けましょう。
保守契約では、受付時間、初動連絡の目安、調査範囲、暫定対応を確かめます。初動の速さと復旧までの時間は同じではありません。原因が外部AIサービスの停止にある場合、開発会社ができることとできないことを説明してもらい、手作業へ戻す手順や機能の一時停止を用意します。
また、外部モデルの変更や参照文書の更新を、誰の判断で本番へ反映するかも決めます。変更前後の評価をせず切り替えると、以前は答えられた質問で挙動が変わる可能性があります。対象となる変更、試験項目、承認者、元に戻す条件を整理すれば、運用のたびに判断をやり直さずに済みます。
業務への影響が大きい出力は、当面、人が確認してから確定する設計も選択肢です。誰が何を確認するかを決めないまま「最終判断は人」とだけ記載しても運用は回りません。金額、契約条件、顧客への回答など、確認する項目を画面や手順に落とし込みます。
リスク：契約を終えたくても移行できない
出口の条件を、開始前の納品物に含める
解約できる条項があっても、データや設定を取り出せなければ、別の会社へ切り替える作業は進みません。元データの出力形式、設定情報、操作ログ、環境の再構築手順など、移行で必要なものを先に決めます。発注者のデータと開発会社の独自資産が混ざる部分は、何をどの形式で渡せるか具体的に確認します。
例えば文書検索なら、検索用データをそのまま移せるかだけでなく、元文書から作り直せる手順が残るかが判断点です。利用する検索技術を変える場合には、そのまま使えないデータもあり得ます。抽出や分割の条件、対象文書の一覧、権限の対応表があれば、移行先が必要な作業を見積もりやすくなります。
引継ぎ支援の期間と費用、データの受領確認後に削除する順序、契約終了後の問い合わせ窓口も整理してください。解約直後に環境が消え、バックアップの復元可否を調べられない事態を避けるためです。既存の仕組みを継続するか入れ替えるか迷う場合は、開発前診断・ロードマップで現状と変更範囲を整理する方法があります。
契約前の確認結果を、一枚の判断表にまとめる
面談中にすべてを決める必要はありません。重要なのは、未回答の項目を「確認済み」と混同しないことです。下表のように証拠となる資料を定め、候補会社の回答を同じ粒度で並べます。点数の合計だけで決めず、自社が受け入れられない条件が残っていないかを先に確認しましょう。
| 確認するリスク | 残しておく資料 | 判断の要点 |
|---|---|---|
| 実績と能力 | 担当範囲付きの実績、今回の体制表 | 今回必要な設計と運用を担えるか |
| 精度と検収 | 評価計画、合格条件、未達時の扱い | 業務上の重大な失敗を判定できるか |
| データ管理 | データフロー、保存・削除・権限の一覧 | 情報の行き先と利用目的を把握できるか |
| 総費用 | 見積前提、利用量別試算、変更承認の手順 | 増額する条件と承認者が明確か |
| 権利と利用条件 | 成果物一覧、権利区分、利用許諾条件 | 必要な利用・改変・引継ぎが可能か |
| 再委託と属人化 | 委託範囲、引継ぎ手順、権限管理表 | 特定担当者の不在時も継続できるか |
| 運用保守 | 連絡体制、停止・復旧・再評価の手順 | 問題発見後の判断担当が決まっているか |
| 契約終了と移行 | データ出力仕様、移行支援と削除の条件 | 必要な情報を受け取って切り替えられるか |
回答が不十分な項目には、追加資料の提出期限と判断者を置きます。精度など事前には決めきれない点は、小さな検証の目的として切り出す方法があります。一方、機密情報の送信先やデータの利用許可が不明な状態では、実データを渡す前に整理が必要です。未確定事項の性質に応じて、止める工程を変えてください。
よくある質問
契約前に質問が多いと、開発会社に嫌がられませんか？
質問の目的と判断期限を共有し、重要な項目からまとめて聞くと進めやすくなります。無制限の無償調査を求めるのではなく、回答に調査費が必要なら範囲と成果物を確認します。曖昧な点を早く見つけることは、双方の手戻りを減らすことにもつながります。
PoCで成果が出たら、そのまま本番契約を結んでよいですか？
検証で確認した利用条件と本番の条件を比べてから判断しましょう。利用者数、権限、文書更新、障害時の対応など、検証に含めなかった項目が残っていないか確認します。成功したデモに、本番運用の準備がすべて含まれるとは限りません。
ソースコードを納品してもらえば、会社を変更できますか？
コードに加え、実行環境、設定、必要なサービス契約、データ、利用条件を確認してください。第三者が手順書を使って環境を再構築できるかを納品確認に含めると、引継ぎ可能性を具体的に確かめられます。
不安を質問に変え、回答を契約と運用へつなげる
信頼できるAI開発会社かどうかは、良い話だけでなく、未確定な点や対応できない範囲を説明できるかにも表れます。実績、評価、データ、費用、権利、体制、保守、移行を確認し、自社の担当者が判断できる資料へ落とし込んでください。未解決事項が残る場合は、先に検証や業務整理を行い、本番開発の範囲を決める進め方が現実的です。
