この記事で分かること
- 技術デモと実業務への適合性を分けて評価する考え方
- 業務理解と責任分界を面談・提案書で確かめる具体的な質問
- 見積りの前提、除外事項、変更時の扱いを比較する方法
- 契約、受け入れ、データ、知的財産、保守の確認ポイント
- 障害や精度低下が起きたときに説明できる体制の見極め方
- 候補会社を同じ条件で比較する評価表と選定手順
なぜ技術力だけの比較が危険なのか
技術力は重要ですが、発注者が買うものはモデルやライブラリ単体ではありません。現場の入力を正しく受け取り、判断の根拠を確認でき、担当者が使い続けられる一連の仕組みです。技術デモはその一部を切り取ったものなので、見栄えがよいほど評価の対象を狭く見積もる危険があります。
デモの成功条件と現場の成功条件は違う
デモでは、準備されたデータ、整った質問、説明しやすいシナリオが使われます。一方、現場には表記ゆれ、欠損、例外処理、権限の違い、繁忙期の処理量があります。担当者が入力を間違えた場合や、元データの更新が遅れた場合にどう扱うかまでデモで確認できなければ、実運用の品質は判断できません。提案の場では「このサンプルで動くか」だけでなく、「この条件が崩れたときに誰が検知し、誰が判断し、誰が直すのか」を尋ねる必要があります。
AIの精度と業務上の損失は同じ尺度ではない
精度の指標が提示されても、誤った回答が業務へ与える影響は処理ごとに異なります。確認者が一分で修正できる候補提示と、誤出荷や顧客への誤案内につながる自動処理では、許容できる失敗の範囲が異なります。会社選びでは、候補会社が指標を説明できるかに加え、業務ごとに人の確認を残す箇所、停止する条件、判断を記録する方法まで落とし込めるかを見ます。
導入後の問題は技術以外の境界で起きる
本番で困るのは、モデルの選択だけではありません。データを用意する部署、既存システムを管理する会社、利用者へ教育する部門、問い合わせを受ける窓口が複数に分かれていると、問題の切り分けが遅れます。納品時点では動いていても、担当者の異動、データ形式の変更、外部サービスの仕様変更が発生した後に相談先が分からないケースがあります。選定時から技術の担当範囲と業務側の担当範囲を言葉にすることが、発注の失敗を抑えます。
比較軸1：業務理解を提案の中で確かめる
業務理解は「御社の業界に詳しい」という自己紹介では測れません。候補会社が、作業の目的、判断者、例外、前後工程を質問し、提案内容へ反映しているかを確認します。最初の打ち合わせで技術の話ばかりが続く場合は、業務を整理する工程が見積りに含まれているかを尋ねましょう。
ヒアリングで確認したい四つの観点
- 目的：時間短縮、ミス削減、判断の標準化など、導入後に変えたい業務結果を言語化できているか。
- 利用者：誰が、どの頻度で、どの端末から使い、結果を誰が承認するのかを聞いているか。
- 例外：通常処理から外れる入力、保留、差し戻し、手作業へ戻す条件を確認しているか。
- 前後工程：AIの前に必要なデータ整備と、AIの後に必要な確認・登録・通知まで範囲に含めているか。
質問の数が多いこと自体が評価ではありません。回答を受けて、画面、権限、データ項目、運用手順のどこを変更したのかが提案書に残っているかが大切です。ヒアリング議事録に「要確認」と書かれた項目がある場合は、未確定のまま金額に含めたのか、別途調査にしたのかも確認します。
業務フローを候補会社に説明してもらう
発注者が一方的に説明するだけでなく、打ち合わせの終わりに「理解した業務を五分で説明してください」と依頼すると、認識のずれが見えます。よい説明は、業務の目的と制約、AIが支援する部分、人が残す判断、導入しない部分を分けます。専門用語を並べるだけで、現場の手順や例外へ戻れない説明は注意が必要です。
自社で整理が難しい段階では、要件定義・業務整理の相談を使い、発注前に業務の前提を整える方法もあります。業務の棚卸しを先に行えば、候補会社へ同じ資料を渡して比較しやすくなります。
比較軸2：責任分界を図と表で合意する
AIシステムには、アプリケーション、データ連携、モデルや外部API、認証、端末、業務判断など複数の責任領域があります。「一括で対応します」という説明だけでは、障害時の分担は分かりません。提案段階で、作業と責任者を一つずつ対応付けた表を作成してもらいましょう。
責任分界表に入れる項目
| 項目 | 確認する内容 | 決めておく境界 |
|---|---|---|
| データ | 収集、形式変換、欠損の補完、更新頻度、保管場所 | 発注者が用意するデータと会社が整備する処理 |
| モデル・外部サービス | 採用理由、料金変動、仕様変更、停止時の代替策 | 選定・契約・変更通知を担う主体 |
| 業務ルール | 自動化する判断、承認者、手動へ戻す条件 | システムで決めることと発注者が決めること |
| セキュリティ | 権限、ログ、バックアップ、漏えい時の連絡 | 環境設定と社内の運用管理の分担 |
| 運用 | 監視、問い合わせ、障害対応、精度の見直し | 受付時間、初動、復旧、再発防止の担当 |
表に「双方」「協議」とだけ書かれた項目は、重要な未決定事項です。双方が担当するなら、作業を分解して主担当と承認者を決めます。例えばデータの更新は発注者、連携処理のエラー検知は開発会社、業務への影響判断は発注者というように、成果物と判断者を分けて書くと契約へ反映しやすくなります。
責任を引き受ける範囲と引き受けない範囲
信頼できる会社は、できることだけでなくできないことも説明します。元データの正しさを保証できない、外部モデルの回答を完全には制御できない、業務判断そのものは発注者の承認が必要、といった制約を明示し、その代わりに検知・確認・停止の仕組みを提案できるかを見ます。責任を曖昧にして受注し、問題が起きてから「仕様外」とする会社は、技術の高度さに関係なくリスクが高い候補です。
要件定義の責任範囲をさらに確認したいときは、AIシステム開発の要件定義に関する記事も参照できます。自社の要件が未確定な場合は、確定作業そのものを見積りに含めるか、別工程として発注するかを比較してください。
比較軸3：見積りの透明性を金額以外で比べる
見積りを比べるとき、合計額だけを横並びにすると、含まれる作業の違いを見落とします。AI開発では、データの状態、検証回数、連携先、利用者数、外部サービスの料金など、前提が変わると金額も変わります。候補会社へ同じ質問をし、金額の根拠と不確実な部分を別々に示してもらいましょう。
透明な見積りに必要な三層
- 作業：業務整理、要件定義、データ準備、試作、評価、本番化、教育、保守を工程ごとに示す。
- 前提：対象データ量、連携方式、画面数、利用者、検証サンプル、納期など、金額を計算した条件を書く。
- 変動：前提が外れたときの追加作業、再見積りの条件、削れる機能、優先順位を示す。
例えば「AI機能一式」という一行では、何が納品されるか分かりません。「データ項目の確認」「検索・回答の試作」「評価用サンプルの作成」「利用者向け画面」「ログ確認」「操作説明」のように、成果物と検収の単位へ分解されているかを確認します。安価な見積りでも、データ準備や保守が除外されていれば、実際の予算は比較できません。
不確実性を隠さず段階化できるか
初期段階で精度や工数を断定することは難しい場合があります。そのときに、調査・小さな検証・本開発の段階へ分け、各段階の終了条件と次へ進む判断を置く提案は比較的説明しやすい形です。反対に、検証の目的や中止条件を示さず、全機能の完成を前提にした大きな見積りを急がせる場合は注意します。見積りの不確実性を、発注者が意思決定できる情報へ変換できることが重要です。
追加費用の起点を質問する
追加費用が発生すること自体が問題ではありません。要件追加、データ形式の変更、外部サービスの料金改定、検証回数の増加など、何を起点に協議するかが決まっていることが必要です。「想定外の場合」といった表現だけでなく、想定外の例、通知の時期、承認者、作業を止める条件まで確認します。金額の調整方法だけでなく、スケジュールや品質への影響も併記してもらうと、社内説明がしやすくなります。
比較軸4：契約と受け入れ条件を先に確認する
提案が魅力的でも、契約書で成果物と責任が定義されていなければ、完成の基準を巡って対立します。契約形式の名称だけで安心せず、実際の作業、成果物、承認の手順を確認しましょう。法務判断が必要な条項は専門家へ相談しつつ、発注担当者は業務上必要な条件を整理して渡します。
契約前にそろえる確認項目
- 成果物：ソースコード、設定、データ定義、評価結果、操作手順、運用手順、議事録などの納品範囲。
- 受け入れ：機能、処理時間、ログ、権限、評価方法、未達時の修正や再試験の扱い。
- 権利とデータ：発注者データの利用範囲、学習への利用可否、生成物やコードの権利、返却・削除方法。
- 秘密保持と安全管理：アクセスできる人、保管期間、再委託、事故時の連絡、終了時のアカウント処理。
- 変更と終了：仕様変更、予算上限、途中終了、引き継ぎ、第三者サービスの切り替え条件。
受け入れ条件は「精度○％」だけでなく、どのデータを使い、どの方法で測り、誤りをどう扱うかまで書きます。業務によっては、正解率よりも未確信時に人へ回す割合、根拠を確認できること、操作ログが残ることが重要です。候補会社が業務上の受け入れ条件を一緒に設計できるかを、契約前に確認してください。
契約条項のチェック観点を広げる場合は、AI開発会社と契約する前のリスクを整理した記事も役立ちます。関連記事の内容をそのまま契約書へ転記するのではなく、自社のデータ・業務・体制に合わせて確認項目を確定させます。
比較軸5：保守と運用を納品後まで想像する
AIシステムは、納品日に動けば終わる製品とは限りません。入力データの傾向が変わる、業務ルールが改定される、外部APIの仕様や料金が変わる、利用者が増えるなど、運用中に前提が変わります。保守費の有無だけでなく、何を見て、どの状態になったら、誰が対応するかを確認します。
運用設計で確認する項目
| 場面 | 確認する質問 | 残す成果物 |
|---|---|---|
| 通常運転 | 稼働状況、利用量、エラー、回答の傾向を誰が確認するか | 監視項目、定例報告、操作手順 |
| 精度の変化 | どの指標や現場の声をきっかけに再評価するか | 評価データ、判定基準、改善履歴 |
| 障害 | 受付窓口、一次切り分け、連絡時間、復旧目標は何か | 連絡網、対応フロー、障害報告 |
| 変更 | モデル、プロンプト、業務ルールを変える承認者は誰か | 変更記録、テスト結果、戻し方 |
| 終了・移管 | 別会社や内製へ移すとき何を返却してもらえるか | コード、設定、データ仕様、引き継ぎ資料 |
保守の説明で「都度対応します」とだけ言われた場合は、受付方法と対応時間、対象外の作業を具体化します。月額契約に含まれる監視と、別途見積りになる改善開発を分けることも必要です。発注担当者が社内の運用担当へ引き継げる資料が納品されるか、担当者が不在でも問い合わせが止まらないかも比較します。
比較軸6：説明力と意思決定支援を見極める
発注担当者は、経営層、現場、情報システム、法務、経理などへ同じ計画を説明します。候補会社が技術用語を説明できるだけでなく、判断材料を整理し、都合の悪い情報も共有できるかを確認しましょう。良い説明は、結論、根拠、前提、残るリスク、次の判断期限が分かれています。
面談で依頼できる説明テスト
- 同じ提案を、経営層向けに一分、現場責任者向けに三分で説明してもらう。
- デモが失敗したと仮定し、原因候補、切り分け、暫定対応、追加費用の有無を説明してもらう。
- 本番化を見送る条件と、見送った場合に残る成果物を確認する。
- 提案書の不確定事項を三つ挙げ、それぞれをいつどう確定するか聞く。
回答が毎回「技術的には可能です」で終わる場合、業務上の判断材料が不足しています。逆に、実現できない条件を理由付きで示し、代替案と判断期限を提案できる会社は、発注者のリスクを一緒に管理しようとしています。説明資料の読みやすさ、質問への回答期限、議事録の正確さも、契約後のコミュニケーションを予測する手がかりです。
候補会社を同じ条件で採点する方法
印象による選定を避けるには、候補会社へ同じ資料と質問を渡し、回答を証拠付きで記録します。点数を付けることが目的ではなく、点数の根拠が社内で説明できるようにすることが目的です。技術デモは評価項目の一つに留め、業務・契約・運用を含めた合計で判断します。
| 評価項目 | 確認する証拠 | 低評価になりやすい回答 |
|---|---|---|
| 業務理解 | 業務フロー、利用者、例外を反映した提案 | 技術構成は詳しいが、作業手順への言及がない |
| 責任分界 | 責任分界表、障害時の連絡・判断フロー | 「一括対応」「ケースバイケース」だけで終わる |
| 見積り | 工程、前提、除外、変更条件、成果物 | 一式金額で根拠や除外が分からない |
| 契約 | 受け入れ条件、データ利用、権利、終了・移管条件 | 契約は後で決めるとして具体化を避ける |
| 保守 | 監視、問い合わせ、改善、外部変更への対応 | 納品後は利用者側で判断する前提になっている |
| 説明力 | 議事録、制約の説明、失敗時の代替案 | 否定的な情報や不確実性を説明しない |
採点には、例えば「確認できた」「説明はあったが証拠がない」「未回答」のような段階を使うと、無理に数字へ換算せず比較できます。重要な項目に未回答がある場合は、平均点で埋めず、契約前の確認事項として残します。複数社を比較する場合は、会社名を隠して提案の一部を社内レビューする方法も、先入観を抑える助けになります。
選定から発注までの実務ステップ
1. 業務の目的と除外範囲を一枚にまとめる
まず、変えたい業務結果、対象利用者、現状の困りごと、守るべき制約、今回やらないことを書きます。技術方式を先に決めず、候補会社が同じ前提で提案できる資料にします。データの所在や更新者が不明なら、その不明点も明記します。
2. 同じ質問票と評価表を渡す
候補会社ごとに説明の粒度が違うと比較できません。業務フロー、責任分界、見積りの前提、契約、保守、説明方法について同じ質問をし、回答期限もそろえます。デモを実施する場合も、実データをそのまま渡せないなら、入力の種類と例外の条件を可能な範囲で再現します。
3. 提案後に確認会を設ける
提案書を受け取ったら、金額の比較だけで終わらせず、未確定事項と前提の差分を確認します。候補会社に自社の理解を説明してもらい、発注者側が想定していなかった作業を洗い出します。質問への回答を議事録に残し、口頭の約束を契約や仕様へ反映できるか確認します。
4. 小さな検証の終了条件を決める
検証を行う場合は、試す範囲、評価データ、現場での確認者、合格・中止の条件、次工程の見積りを先に決めます。検証に成功しても本番化しない選択肢を残しておくと、目的に合わない開発を続けるリスクを抑えられます。検証結果が期待に届かなかった場合の報告と、データや成果物の返却条件も契約前に決めます。
5. 発注後の会議体と変更手順を決める
発注後に誰が意思決定し、どの頻度で進捗・課題・リスクを確認するかを明確にします。変更要求は、目的、影響、金額、納期、受け入れ条件を一つの記録にまとめて承認します。担当者の交代に備えて、決定理由と未決定事項を残す運用にしておくと、会社選びの段階で合意した責任分界が崩れにくくなります。
AI開発を依頼する前に整理したいこと
AI開発を依頼する段階で、技術方式やモデル名が決まっていなくても問題ありません。重要なのは、どの業務を変えたいか、判断に必要なデータがどこにあるか、誤りを誰が確認するか、導入後に誰が運用するかです。これらを整理したうえで、候補会社に調査・検証・開発・保守の選択肢を出してもらうと、技術の競争だけになりにくくなります。
具体的な開発相談はAIシステム開発サービスの対象範囲を確認し、既存システムやデータの状態が不明な場合は開発前診断・ロードマップで論点を整理する方法があります。診断や要件整理を独立した工程にするか、開発会社の提案に含めるかも、候補会社を比べる項目の一つです。
また、会社選びの質問を作る際は、AI受託開発会社の選定とRFP項目に関する記事を補助資料として使えます。RFPの項目を増やすこと自体が目的ではなく、各社が同じ前提で業務理解・責任・金額を説明できる状態を作ることが目的です。
よくある質問
技術力はどのように評価へ入れればよいですか？
技術力を無視するのではなく、業務要件を満たすための手段として評価します。候補会社に採用技術の理由、制約、変更時の影響、運用者が扱える範囲を説明してもらい、デモの成功だけでなく本番運用の証拠とセットで採点します。
候補会社が見積りを一式でしか出してくれません。
工程、成果物、前提、除外、変更条件の五点を分けて提示できるか依頼します。分解が難しい段階なら、調査・検証を先行する小さな契約にして、次工程へ進む条件を決める方法があります。比較できない理由を記録し、安さだけで選ばないことが大切です。
AIの回答を完全に正しくできない場合、発注してはいけませんか？
完全性を前提にするのではなく、誤りが起きても業務上の損失を抑える設計にします。確認者を置く、根拠を表示する、確信度が低い場合は保留する、ログを残すなどの方法を候補会社と検討し、許容できる失敗と停止条件を受け入れ条件へ反映します。
保守費を払えば、運用上の問題はすべて対応してもらえますか？
保守契約に含まれる範囲は会社ごとに異なります。監視、障害対応、データ修正、モデル再評価、機能追加、利用者教育を分け、受付時間と対象外を確認してください。外部サービスの仕様変更や社内の業務変更が起きた場合の扱いも、契約前に決めておきます。
最終的に価格と実績のどちらを優先すべきですか？
価格と実績を単独で優先するのではなく、自社の業務リスクに対して必要な責任を引き受けられるかで判断します。実績があっても自社の業務・データ・運用体制へ適用する説明がなければ不十分です。価格差は、含まれる工程、保守、引き継ぎ、追加費用の条件までそろえて比較します。
まとめ：技術を業務の成果へつなげる会社を選ぶ
AIシステム会社選びで見るべきなのは、最新技術を披露できるかだけではありません。業務の目的と例外を理解し、AIが担う範囲と人が担う判断を分け、見積りの前提と変動を説明し、契約後の保守・移管まで設計できるかが重要です。
候補会社を比較するときは、同じ業務資料と質問票を渡し、提案書・責任分界表・見積り・受け入れ条件・運用設計を証拠として残します。不確実な事項を隠さず、できないことや中止条件まで説明する会社は、発注後の意思決定も支援しやすい傾向があります。技術デモを入口にしながら、最終判断は業務理解、責任分界、見積り透明性、契約、保守、説明力の合計で行いましょう。
自社だけで比較軸を整理しにくい場合は、現状の業務フローと候補会社の提案を並べ、開発・修正・保守のどこから始めるべきかを第三者に確認することも有効です。発注前に判断材料を整えれば、技術に詳しい人だけでなく、現場と経営の双方が納得できる選定になります。
