AI受託開発会社の比較では、価格や有名サービス名だけを見ても自社に合うかは判断できません。必要なのは、現場で使う機能、連携するデータ、管理者が守るルール、導入後の改善指標を一つの要件一覧として整理することです。
AI受託開発の要件は、「必ず満たす要件」「点数で比べる要件」「受入（検収）の条件」の3つに分けて書きます。RAGやAIエージェントでは、受入条件に「自社の実例で作った評価データ」「権限を超える操作を試すテスト」「モデルや文書を変えた後の再評価」を入れておくと、試作は動いたのに本番で使えないという失敗を防げます。この3点は、契約前のRFPに書いておきます。
要点
- AI受託開発の要件は、必ず満たす要件、点数で比べる要件、受入の条件に分けて書くと、候補を絞りやすくなります。
- RAGやAIエージェントの受入条件には、自社の実例で作った評価データ、権限を超える操作のテスト、変更後の再評価を入れます。
- 公開後は、受入時と同じ評価データで品質を確かめられる状態にしておくと、改善の判断がしやすくなります。
AI受託開発会社の要件は「使う場面」から逆算する
AI受託開発会社を選ぶときに最初から製品名や料金表を見始めると、比較表は作れても判断がぶれやすくなります。先に決めるべきなのは、誰が、どのタイミングで、どのデータを使い、どの結果を次の業務へ渡すかです。ここが曖昧だと、導入後に「機能はあるが使われない」状態になります。
AI開発はデモが動くことと、業務で使い続けられることの差が大きい領域です。RAG、AIエージェント、業務アプリ連携では、開発会社がどこまで運用設計に踏み込むかが成果を左右します。そのため要件一覧では、機能の有無だけでなく、現場入力、管理者設定、外部連携、ログ、権限、評価指標を同じ表に入れて確認します。
| 要件 | 区分 | 確認ポイント | 不足したときのリスク |
|---|---|---|---|
| 業務要件定義 | 必須 | 対象業務、入力と出力、例外、成果指標を整理できるか | 試作で終わり、業務に載らない |
| データ連携 | 必須 | CRM、DB、Drive、APIとの接続方法と権限 | 手作業の転記が残る |
| セキュリティ・権限 | 必須 | 閲覧権限、ログ、データの保存期間、学習への利用の有無 | 社内審査で止まる |
| 受入評価 | 必須 | 評価データ、合否基準、権限を超える操作のテスト、変更後の再評価 | 不具合か仕様か判断できず、検収でもめる |
| 運用保守 | 必須 | 障害対応、改善、モデル変更時の対応の範囲と時間 | 公開後に直せず、使われなくなる |
| RAG設計 | RAGを作る場合は必須 | 文書の分け方、検索、権限、文書更新の手順 | 回答の品質が安定しない |
| AIエージェント設計 | エージェントを作る場合は必須 | 実行してよい操作、承認、止め方、人への戻し方 | 本番で動かせない |
| 内製化・引き継ぎ | 点数で比べる | 設計書、運用手順、教育を含むか | 特定の開発会社に頼り続ける |
| 費用の内訳 | 点数で比べる | 要件定義、開発、保守、AI・クラウドの利用料を分けた見積もり | 追加費用が読めない |
必須要件と任意要件を分ける
要件一覧を作る目的は、すべての機能を盛り込むことではありません。むしろ、外せない条件と後回しにできる条件を分け、候補を減らすことに価値があります。業務要件、データ、権限、受入評価、保守のどれかが欠けると、導入しても運用上の穴が残ります。
一方で、高度な分析、細かな自動化、複雑なカスタマイズは、初期導入時から必須にしすぎると比較が重くなります。まずは業務停止や情報漏れ、二重入力を防ぐ要件を必須にし、改善系の機能は点数で比べる要件に回す方が現実的です。
| 区分 | 入る要件 | 比較での扱い |
|---|---|---|
| 必ず満たす要件 | 業務要件定義、データ連携、セキュリティ・権限、受入評価、運用保守（RAG・エージェントを作る場合はそれぞれの設計も） | 満たせない会社は候補から外す |
| 点数で比べる要件 | 内製化・引き継ぎ、費用の内訳、類似テーマの経験、進行管理の体制 | 提案の具体性で点数をつける |
RAG・AIエージェントの受入条件に入れる3つのテスト
受入（検収）は、納品されたものが契約どおりに動くかを確かめる工程です。生成AIは同じ入力でも出力が揺れるため、何を入れて、何が出れば合格かを契約前に決めておかないと、検収の場で判断できません。
| テスト | RAGでの例 | AIエージェントでの例 | RFP・契約に書くこと |
|---|---|---|---|
| 評価データでの合否判定 | 過去の問い合わせから作った質問集で、正しい文書を根拠に答えられるか | 過去の実際の依頼から作った課題集で、決めた手順どおりに処理を終えられるか | 評価データを誰が用意するか、件数、合格とする割合、再試験の回数 |
| 権限を超える操作のテスト | 閲覧権限のない部署の文書が回答に出てこないか | 許可していない送信・更新・削除を指示されたときに止まり、人に確認を求めるか | 試す操作の一覧、止まらなかった場合は不合格とすること |
| 変更後の再評価 | 文書の追加や検索方法の変更の後に、同じ質問集で品質が落ちていないか | モデル、プロンプト、連携先の変更の後に、同じ課題集と権限テストを通るか | 再評価を行う変更の種類、誰が行うか、保守費に含まれるか |
評価データは、開発会社に任せきりにせず、自社の実例から作るのが基本です。権限の設計は AIエージェントの権限設計、危険な指示への耐性を試す方法は AIエージェントのプロンプトインジェクション耐性テスト で詳しく扱っています。
比較表・RFPに落とす確認項目
ベンダーへの質問は「できますか」ではなく「どの条件で、誰が、どこまで設定できるか」まで聞く必要があります。標準機能、上位プラン、個別開発、外部連携で実現方法が違うため、同じ丸印でも導入負荷は大きく変わります。
特にAI受託開発会社では、PoC環境から本番データ、権限、監査ログへ移すときの設計をデモで確認してください。デモ環境で見える画面がきれいでも、実データ、権限、承認、例外処理を入れたときに運用できなければ成果にはつながりません。
- PoCから本番に移すときに必要な追加作業は何ですか？
本番データ・権限・ログへの切り替えが見積もりに入っているかを見ます。 - 受入の評価データと合否基準は、どう決めますか？
自社の実例を使う提案か、件数と合格の割合を数字で示せるかを見ます。 - 権限を超える操作をどうテストしますか？
試す操作の一覧と、止まらなかった場合の扱いが答えられるかを見ます。 - モデルや文書を変えた後の再評価は、保守に含まれますか？
再評価の対象となる変更と、費用の扱いが明確かを見ます。 - 利用ログと操作の記録は、どこまで残せますか？
誰が、いつ、何を入力し、AIが何を実行したかを後から追えるかを見ます。
契約書で確認する項目は、経済産業省が2025年2月に公表した「AIの利用・開発に関する契約チェックリスト」が参考になります。Impress Watchの報道によると、提供するデータの利用範囲、AI生成物の利用条件、データが予期しない目的に使われたり第三者に提供されたりするリスクなどを、契約時に確かめる観点として整理しています。読み方は AIサービス契約前に確認すべきポイント で整理しています。
社内チェックリストに落とす
AI受託開発会社の要件を社内で使える形にするには、単なる機能表ではなく、選定時に確認する質問、デモで見る画面、導入後に測る指標を一つのチェックリストにします。これにより、経営、現場、管理部門、情報システムの見方が揃いやすくなります。
チェックリストには、必須要件を満たさない候補を早めに除外する欄と、点数で比べる要件を採点する欄を分けます。さらに、データ連携、セキュリティ、運用保守の範囲のように後から問題化しやすい論点は、費用やプラン名とは別の確認欄にしておくと、稟議時に説明しやすくなります。
- 比較表には、機能の有無だけでなく運用担当、設定権限、追加費用の欄を入れる。
- デモ確認では、理想的なサンプルではなく自社に近いデータや業務フローで試す。
- 稟議資料には、候補から外した理由も残し、価格だけで選んだように見えない形にする。
- 受入条件と公開後の評価指標を先に決め、納品の完了ではなく現場での利用と成果で判断する。
公開後に見る評価指標
要件一覧は選定時だけでなく、導入後の評価にも使います。システムを公開してから一定期間がたった時点で、現場が使っているか、入力や確認の手間が減ったか、管理者が改善判断に使えるデータを得られているかを確認します。初期設定が終わっただけでは、要件を満たしたとは言えません。
特に重要なのは、利用率、回答・処理の品質、人に戻した件数、権限・ログ、成果指標の5つです。品質が落ちたときに、受入時と同じ評価データで再評価できる状態にしておくと、開発会社との定例で原因を特定しやすくなります。導入後の評価項目を先に決めておくと、ベンダーとの定例会でも改善論点を具体的に話せます。
| 評価項目 | 見るべき状態 | 改善判断 |
|---|---|---|
| 利用率 | 対象の担当者が日常業務で使っている | 使っていない人の理由を聞き、画面や手順を直す |
| 回答・処理の品質 | 受入時の評価データで、品質が落ちていない | 落ちていれば、直前の変更を確認して再評価する |
| 人に戻した件数 | 例外として人へ戻した件数と理由が記録されている | 同じ理由が続くなら、業務ルールか承認条件を見直す |
| 権限・ログ | 操作の記録が残り、権限を超える操作が起きていない | 起きていれば、権限設定とテストを見直す |
| 成果指標 | 作業時間、対応時間、品質など契約時に決めた指標が測れている | 目標値と測り方を更新する |
導入後に見落としやすい運用要件
導入後に詰まる原因の多くは、機能不足ではなく運用要件の抜けです。誰がマスタを直すのか、例外時に誰が判断するのか、ログを誰が見るのか、現場からの改善要望をどこに集めるのかを決めていないと、利用開始後に責任が分散します。
契約前に、納品後の改善の進め方、障害時の対応、プロンプトや文書の更新を誰が行うかを確認します。要件一覧には、初期設定だけでなく、運用開始後の変更、教育、権限見直し、レポート確認の頻度まで入れておくと、ツール選定と定着施策を分けずに進められます。
- モデル名やデモ画面だけで会社を選ぶ。
- PoCと本番のデータ・権限差を見積に入れない。
- 保守運用と改善の責任を契約に書かない。
- 成果指標を精度だけにして業務効果を測らない。
よくある質問
AI受託開発の要件は何から決めるべきですか？
最初に決めるべきなのは、PoCから本番運用まで任せる範囲です。機能名から選ぶと比較表は埋まりますが、実際の利用場面、連携するデータ、運用責任が曖昧なままだと導入後に使われなくなります。
受入（検収）の条件には何を書けばよいですか？
自社の実例で作った評価データと合格とする割合、権限を超える操作のテストと不合格の扱い、モデルや文書を変えた後の再評価の範囲を書きます。生成AIは出力が揺れるため、数値や件数で決めておかないと検収の場で判断できません。
評価データは誰が用意しますか？
自社が用意するのが基本です。過去の問い合わせや処理の実例から、正解が分かるものを選びます。開発会社には、件数の目安と作り方の支援を依頼すると進めやすくなります。
RFPや稟議資料には何を書けばよいですか？
現状課題、必須要件、除外条件、比較軸、想定運用、費用の見方、受入条件と公開後の評価指標を書きます。製品名の比較より先に、なぜその要件が必要なのかを説明できる状態にすることが重要です。
