AI開発会社はどう選ぶ？技術名より実装範囲・評価・運用責任で比較

AI開発会社を選ぶとき、導入事例の数や「GPT、Claude、Geminiに対応」といったモデル名は、発注先を決める十分な根拠にならない。必要なのは、今回の業務で何を作り、どのデータで評価し、本番後に誰が責任を持つかを提案書から確認できることだ。

比較は5項目、各0〜2点の10点で行う。点数は会社の評判ではなく、今回提出された証拠の明確さに付ける。公開情報だけで会社をランキングするための表ではない。

提案書を10点で比べる

項目	0点	1点	2点
実装範囲	「AI導入」など抽象表現だけ	主な機能と成果物が書かれている	対象外、既存システムとの境界、引き渡し物、責任者まで書かれている
評価	デモ確認だけ	指標やテスト例がある	テストデータ、指標、閾値、許容失敗、再実行方法、結果ファイルが固定されている
データと安全性	「安全に対応」だけ	保存先やアクセス制御の説明がある	入力利用、保持、削除、権限、ログ、事故対応が契約案へ結び付いている
運用	納品後の記載なし	保守窓口や期間がある	監視、障害、モデル変更、再評価、終了・移管の担当と費用がある
費用	一式金額だけ	工程別の概算がある	前提数量、外部実費、変更条件、運用費、除外項目まで比較できる

同点だから安い方、とも決めない。0点がどこにあるかを見る。たとえば実装2点、評価0点の提案は、作る範囲が明確でも完成判定ができない。評価2点、運用0点なら、PoCは比較できても本番後の費用と責任が残る。

8点以上を自動合格にする表でもない。個人情報を扱う案件では、データと安全性が1点なら総合点が高くても候補から外す、といった必須条件を先に置く。

実装範囲は「何を作らないか」まで確認する

提案書の機能一覧だけでは、既存システムとの境界が分からない。チャット画面を作る提案でも、認証、文書取込、検索用データの更新、監査ログ、管理画面、利用者への説明まで含むとは限らない。

実装範囲では次を一つずつ確認する。

• 対象業務と利用者
• 画面、API、データ処理、外部連携
• 発注側が用意するデータと環境
• 納品されるソースコード、設定、設計書、テスト結果
• 提供会社のサービスとして残り、引き渡されない部分
• PoCに含む範囲と本番開発へ送る範囲

NTT DATAやPwCの現行サービスは、構想からPoC、実装、定着まで広い支援を掲げている。これは一社で一貫支援できる可能性を示す一方、個別契約で全工程が含まれる証明ではない。「ワンストップ」という語を2点の根拠にせず、成果物と担当者を提案書で確認する。

評価はモデルのベンチマークではなく業務テストにする

提案モデルの公開ベンチマークが高くても、自社の問い合わせ、文書、用語、失敗条件に合うとは限らない。NIST AI RMFは、目的に合う測定方法を選び、再現可能なテスト・評価・検証を文書化する考え方を示している。

提案には、少なくとも次を求める。

1. テスト対象となる業務例
2. 入力と期待結果を組にしたテストデータ
3. 正答率だけでなく、根拠、拒否、禁止出力などの評価軸
4. 応答時間と1件当たり費用
5. 合格閾値と重大失敗の許容回数
6. モデルやプロンプト変更後に同じテストを再実行する方法

AWSの評価パイプライン例では、少数例の手動確認と、正解データを持つテストセットでのオフライン評価を分け、出力、応答時間、費用を記録する。製品固有の構成をそのまま採用する必要はないが、デモと反復可能な評価を分ける考え方は提案比較に使える。

LLMを採点役に使う場合も、その点数を正解とみなさない。Google Cloudは、モデルによる評価指標を人が評価したデータと比較する手順を示している。自動採点を使う提案では、人の評価とのずれをどのように確認したかを質問する。

データと安全性は契約案へ落ちているか

「国内リージョン」「暗号化」「学習に使わない」といった単語が並んでいても、今回のデータ処理が分かるとは限らない。確認したいのは、入力がどこへ送られ、誰がアクセスし、どれだけ保持され、終了時にどう削除されるかだ。

経産省のAI契約チェックリストは、入力データ、処理成果、出力について、利用目的、外部提供、権利、サービス水準を契約前に確認する材料を示す。デジタル庁の2026年版調達ガイドも、契約書や仕様書で入力・出力、期待品質、事故時の対応、ログやアクセス制御を扱う。

民間案件では法務・情報セキュリティ担当と条件を決める。提案会社の一般的なセキュリティページだけで2点にせず、今回の構成図、データフロー、権限表、削除手順、事故時の連絡条件が契約案にあるかを見る。

運用責任はモデル更新後まで見る

本番化したAIシステムは、納品時の状態で固定されない。外部モデル、API、検索データ、社内文書、利用者の質問が変わる。初回テストが通っても、更新後に品質や費用が変わる可能性がある。

運用提案では、次の担当と費用を確認する。

• 稼働状況、品質、費用の監視
• 障害と誤出力の受付
• モデルやAPI変更時の再評価
• テストデータの追加と版管理
• 権限変更、ログ確認、データ削除
• 契約終了時のデータ・設定・ソースコード移管

AWSのPath-to-Valueは、データアクセス、連携、可観測性、拡張性、回復性、継続評価を本番化の論点として挙げる。これらを「運用保守一式」の一行にまとめず、誰が何を監視するかへ分ける。

見積は同じ前提数量へそろえる

安い提案が必要作業を除外しているだけなら、契約後の追加費用が増える。金額を比べる前に、次の数量をそろえる。

数量	例
利用者	試験利用者、本番利用者、同時利用数
データ	文書数、ページ数、更新頻度、個人情報の有無
評価	テスト件数、モデル候補、再実行回数、人の確認件数
連携	API、認証、データベース、業務画面の数
運用	対応時間、監視頻度、変更回数、保持期間

外部モデルのAPI料金、クラウド、評価実行、監視サービス、ライセンスが見積に含まれるかも分ける。PoC価格と本番運用費を一つにせず、初期費用、月額費用、利用量で変わる実費を別列にする。

0点を質問へ変えてから絞る

提案書を採点したら、0点項目をそのまま不合格理由にする前に、回答期限付きの質問へ変える。

たとえば評価が0点なら、「当社が提供する100件のテストセットについて、品質、応答時間、1件当たり費用の合格基準と結果ファイル形式を提示してください」と聞く。運用が0点なら、モデル更新時の再評価担当、対応時間、追加費用を確認する。

回答しても成果物、閾値、担当、費用が明確にならない提案は外す。反対に、公開事例が少なくても、今回の範囲を具体的に分解し、未知点を明示し、再現可能な評価と引き継ぎを示せる会社は候補に残せる。

発注先を決めるのは総合点ではなく、自社の必須条件を満たし、0点を解消した提案の中から選ぶことだ。値引き交渉は、その比較ができた後に行う。