AIシステム開発会社の選び方
AIシステム開発を頼みたい。何社か話を聞いて見積もりも集まった。でも金額も提案もばらばらで、どこがよいのか分からない。そんなときに役立つ見方をまとめます。
一番安い会社が、あとまで安いとは限りません。生成AIを使うシステムでは、開発後もデータ整備、回答の評価、人の確認、LLM API、保守が続きます。体制や機能が大きければ安心、というわけでもありません。
有名な会社より、今回の案件に合う会社
迷ったら、実績一覧を見る前に、次の順番で考えてみてください。
- AIを導入する業務と、現在の時間・費用・ミスを把握する
- パッケージ製品で足りるか、個別開発が必要かを判断する
- 案件の規模とリスクに合う会社タイプを選ぶ
- 各社に同じ依頼文と回答項目を渡す
- 初期開発費だけでなく、運用・社内工数・終了時の費用も比べる
- 担当者との相性は、短い共同作業で確かめる
- PoCの合格条件、本番へ進む条件、引継ぎ条件を契約前に決める
発注側でも、「何に使うか」「どこまでの失敗なら許容できるか」「誰が運用するか」は先に決めておきます。ここが決まっていないと、どの会社の提案も比べられません。
いきなり会社探しを始めない
会社のサイトを見ていると、技術や事例に目が向きます。先に、次の内容をA4用紙1枚ほどにまとめておきましょう。要件定義書までは要りません。
- どの部署のどの作業を変えたいか。今は何件を、どれくらいの時間で処理しているか
- 導入後に変えたいこと。時間、件数、品質など
- 誰が使い、AIと人がどこまで担当するか
- 使えるデータ、予算、時期、既存システム、最初は作らない機能
「社内問い合わせをAI化したい」だけでは、各社の想像がずれます。「総務の規程に関する質問に、参照元付きの回答案を出し、担当者が確認して返す」まで書けると、見積もりの前提が揃います。
大企業なら、情報システム、セキュリティ、法務、調達にも早めに見てもらいましょう。後から必須条件が増えると、選び直しになりやすいです。
作らない、という選択もある
費用対効果を考えるなら、既存のSaaSで足りないかを先に見ます。
議事録、要約、文書検索が中心で、独自の画面や複雑な連携がなければ、まずSaaSを試す方が早いことがあります。サービスの仕様に業務を合わせられるなら、なおさらです。
独自の承認フローが競争力に関わる、複数システムを権限付きでつなぐ、AIの出力を業務画面で確認して記録したい。そんな場合は、個別開発の方が合うことがあります。
既存サービスで足りるものを個別開発すると、保守まで自社で抱えます。無理にSaaSへ合わせると、転記や例外対応が残ります。「今回は作らない方がよい」と言える会社は、相談相手として信頼しやすいです。
会社の大きさより、役割で選ぶ
| 選択肢 | 合いやすい案件 | 選定時に確認すること |
|---|---|---|
| AI特化の小規模開発会社 | 対象部署を絞ったPoC、業務改善ツール、短い意思決定で進める案件 | 代替担当、保守時間、セキュリティ要件への対応範囲 |
| 中堅・大手SIer | 基幹連携、多部門展開、厳格な調達・監査、複数チームが関わる案件 | 実装担当者との距離、最小発注範囲、変更時の手続きと費用 |
| AIコンサルティング会社 | 全社方針、ユースケース選定、社内ルールの整備から始める案件 | 実装を誰が担うか、提言から検証へ進む条件、成果物の引継ぎ |
| SaaS・パッケージ提供会社 | 標準機能に業務を合わせ、早く利用開始したい案件 | データの持ち出し、連携範囲、解約時のエクスポート、追加費用 |
1部署の文書検索を試すのに、大規模な常駐体制は持て余します。複数部門の基幹連携を少人数だけに頼むと、監査や障害対応が細くなります。
「何ができますか」より、「この案件で、御社が担当しない方がよい範囲はどこですか」と聞いてみてください。向かない範囲を率直に話せるかも、判断材料になります。
見積もりの安さは、合計欄では分からない
長い目で見た費用は、次を足して考えます。
総費用 ＝ 要件整理・PoC ＋ 本番開発 ＋ データ整備 ＋ 社内の確認作業 ＋ クラウド・LLM API ＋ 保守改善 ＋ 終了・移行費用
見積もりが安くても、データ整備やテストが「発注側の作業」なら、社内の手間は増えます。保守が安くても、障害調査やモデル更新が毎回別料金なら、年間費用は読めません。
効果は、削減時間や外注費だけではありません。処理件数、手戻り、担当者の確認時間も見ます。回答が正確でも確認に時間がかかるなら、業務はあまり楽になりません。使い勝手のように金額にしにくいものは、無理に金額へ換算しなくて構いません。
費用の内訳はAIシステム開発の費用は何で決まるかで整理しています。
相見積もりは、同じ質問で取る
同じメールを送っただけでは、PoCだけの金額と本番込みの金額が並ぶことがあります。次を共通の回答欄にして渡します。
- 提案する範囲と、対象外
- PoCの成果物、評価方法、期間、本番へ進む条件
- 本番開発の概算と、金額が変わる条件
- 発注側と開発会社の作業分担
- 初期費用、月額費用、従量費用、追加開発の単価
- 利用するAIモデル、クラウド、外部サービス
- データの保存場所、保持期間、学習利用、再委託
- 保守時間、障害時の連絡、納品物、管理権限、終了時の引継ぎ
未確定の項目は空欄にせず、「PoCで決める」「別途協議」「対象外」のどれかを書いてもらいます。先に見たいのは、金額差より、含まれる作業の差です。
候補が多い場合は、まず対応できるかを聞いて2〜3社に絞り、その後に同じ条件で提案をもらうと比較しやすいです。
採点は、提案を受け取る前に決める
話しやすさや資料の見栄えに引っ張られないよう、配点は提案の前に決めておきます。
| 選定基準 | 配点例 | 確認する内容 |
|---|---|---|
| 業務理解と提案範囲 | 20 | 現行業務、利用者、例外、作らない範囲を理解しているか |
| PoCと評価設計 | 20 | 評価データ、合格条件、業務効果、本番へ進む条件があるか |
| 費用の透明性 | 15 | 初期・運用・従量・社内作業・追加費用を分けているか |
| データ・セキュリティ | 15 | 入出力、ログ、権限、保持、再委託、事故対応を説明できるか |
| 開発・運用体制 | 15 | 実担当、代替要員、品質管理、保守、改善方法が明確か |
| 引継ぎ・変更のしやすさ | 10 | ソース、文書、アカウント、データ出力、他社への移管が明確か |
| 進め方の相性 | 5 | 連絡頻度、説明、意思決定、問題の伝え方が合うか |
点数ですべて決められるわけではありません。顧客の権利や安全に関わる部分は、合計点が高くても必須条件から外さない方がよいです。匿名化したデータで試す社内PoCに、本番と同じ確認を全部求めると、費用も時間も膨らみます。影響の大きさと起こりやすさに合わせて、確認の重さを変えます。
デモの正しさより、評価の仕方
用意された質問に答えるデモだけでは、自社データで使えるか分かりません。実際の質問と、答えてはいけない質問の両方で試し、正答だけでなく、誤答、回答不能、参照元の誤りを分けて記録しているかを見ます。
「精度95%」なら、何件を、誰が、どの基準で採点したかも確認します。重大な誤りと、言い回しの好みを同じ不正解として数えていたら、その数字では決められません。モデルを変えたあとに同じ条件で測り直しているか、応答時間と1件あたりのAPI費用も見ておきましょう。
合格ラインの数値は業務によって違います。回答品質、参照元、修正率、処理時間、月額費用の見込みをセットで置くと、「なんとなくよさそう」で本番へ進みにくくなります。
認証の有無より、データの流れ
認証は確認材料になりますが、今回のデータがどこを通るかは別です。入力、参照文書、出力、ログを、誰が、どの国で扱い、学習に使うのか。保存期間、削除、問題が起きたときの連絡先まで聞いておきます。
一般向けのAIサービスとAPIでは、データの条件が違います。詳しくは生成AI APIを業務システムに組み込むときの注意点を参照してください。
相性は、少し一緒に働いてみる
話しやすさだけで本番を任せると、進め方が後からずれることがあります。短期間の要件整理やPoCを、本番とは分けた有償の仕事として頼んでみてください。
- 実装する人に直接話せるか
- 不要な機能を指摘し、分からないことは分からないと言うか
- 決まったこと、未決のこと、担当、期限が文書に残るか
- 問題の原因と選択肢を、早めに共有するか
発注側の準備も相性に入ります。窓口、業務の責任者、承認者が決まっていないと、どの会社でも進みにくくなります。
PoCで見るのは、動くかと、使う価値があるか
動くかどうかだけでなく、現場の作業時間や手戻りが減るかも見ます。人の確認を入れても効果が残るか、誰がデータと回答品質を更新するかもです。
データを更新する担当がいない、確認作業が増える、利用頻度が低い。そんな結果なら、そこで止めて構いません。PoCは本番へ進むための儀式ではなく、続けるか止めるかを決めるためのものです。
終わらせ方まで、契約に書いておく
見積もりで聞いたデータの扱い、納品物、アカウントの管理権限、終了時の返却や削除は、契約書にも残します。モデルの提供終了や料金が変わったときの対応も同じです。
ソースコードや知的財産を全部もらえれば安心、とは限りません。開発会社の汎用部品まで移転対象にすると、費用が上がることがあります。必要なのは、自社で運用を続け、必要なら他社へ渡せる利用権と管理権限です。判断が難しければ、契約書は専門家にも見てもらいましょう。
中小企業と大企業で、見る順番は少し違う
中小企業なら、経営者や現場が実装者と直接話せるか、小さく試せるか、月額と追加改修を見通せるかを優先します。担当者が休んだときの代わりも確認しておきましょう。
大企業の部門決裁なら、情報システム、セキュリティ、法務、調達の条件を満たせるかが先です。全社の既存基盤と重複しないか、部門のPoCを後から広げられるかも見ておきます。最初から全社システムにする必要はありませんが、本番データの利用条件は、小さく試す段階で確認した方があとが楽です。
まとめ
会社の知名度や見積もりの安さより、今回の課題に合う体制か、同じ条件で比べられているか、運用まで含めた費用が見えているかを見てください。
相性は商談だけでは分かりません。短い仕事を一緒にして、説明、記録、問題の伝え方を確かめてから決めると、発注後のすれ違いが減ります。
ウィステリアコードでは、AIシステム開発、AI活用・導入支援、PoC・MVP開発について、発注前の業務整理からご相談いただけます。「個別開発が必要か判断したい」「比較できるPoCの範囲を決めたい」という段階でも、お問い合わせからご連絡ください。