LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム受託開発を担当

AI受託開発の会社選びが問われる理由——実装以前に発注側が整理すべきこと

AI受託開発の会社を選ぶ場面では、Webサイト制作や業務システムの保守を外注するときとは異なる判断軸が求められます。生成AIや機械学習を組み込んだシステムは、要件定義の段階でどこまで実現できるかが見えにくく、PoC(概念実証。本格開発の前に技術的な実現性を小規模に検証する工程)を経てから本番運用に進む段取りを踏むことが少なくありません。

総務省・経済産業省が策定した「AI事業者ガイドライン」では、AIに関わる立場を「AI開発者」「AI提供者」「AI利用者」の3つに整理しています^*1。発注側の企業は多くの場面で「AI利用者」に位置づけられますが、委託先が「AI開発者」「AI提供者」のどちらに近い役割を担うかによって、確認すべき責任範囲も変わってきます^*1。発注先を比較する前に、自社がどの立場で何を委託するのかを整理しておくと、提案内容の読み方が変わります。

本稿では、この6つの評価軸を順に整理し、RFP(提案依頼書)や見積り評価の場で確認すべき項目、費用感の見方、そしてよくある失敗のパターンを取り上げます。生成AI基盤の技術選定やRAG(検索拡張生成)の実装手順といった実装そのものの解説は範囲外とし、発注先をどう選び、どう比較するかに絞って解説します。

評価軸①実績・ドメイン適合——PoC実績と本番運用実績は別物として見る

PoC実績の確認ポイント

提案書に並ぶ実績件数だけを見て判断すると、比較の軸を見誤ることがあります。まず確認したいのは、自社と近い業種・データ特性の案件でPoCを実施した経験があるかという点です。画像認識と自然言語処理では扱うデータの性質もモデルの評価方法も異なるため、件数の多さより領域の近さを重視した方が、提案内容の妥当性を判断しやすくなります。

あわせて、PoCの目的をどのように設計したかも聞いておく価値があります。精度の目標値や評価データの分け方を事前に定義していたか、検証の条件をどこまで文書化していたかは、提案の丁寧さを見極める材料になります。

本番運用実績の確認ポイント

PoCで良好な結果が出ても、本番運用では入力データの傾向が変化したり、想定していないパターンの入力が増えたりする場面が生じます。そのため、PoCの実績だけでなく、本番運用まで進んだ実績が別にあるかどうかを分けて確認する必要があります。

本番運用に進んだ案件については、稼働してからどのくらいの期間、どのような体制で運用を継続しているかを尋ねます。加えて、委託先が元請（プライムベンダー）として一括で対応する体制なのか、複数の協力会社と分業する体制なのかも、トラブル時の責任範囲を考えるうえで確認しておきたい点です。分業体制の場合、データの受け渡しやモデルの引き継ぎがどの会社の役割になるかが曖昧なまま進んでしまうことがあります。

評価軸②技術体制——データサイエンティスト・MLエンジニア・MLOpsの有無

開発体制の役割分担を確認する

AI受託開発における技術体制は、Webシステムの開発体制と役割の区切り方が異なります。データの前処理や特徴量の設計を担うデータサイエンティスト、モデルの実装や既存システムへの組み込みを担うMLエンジニア、インフラ構築を担うエンジニアが、それぞれ専任で配置されているかどうかが、まず確認したいポイントです。一人の担当者が全工程を兼務している体制と、役割ごとに専任者がいる体制では、対応できる規模や障害発生時の切り分けの速さに差が出やすくなります。

IPAが公開している「AIを用いたソフトウェア開発」の調査では、要件定義段階での対話型AI活用やコード生成、レビュー、テストデータ作成の自動化など、開発プロセス自体にAIを組み込む動きが広がっていると整理されています^*5。委託先がこうした動向をどこまで自社の開発プロセスに取り込んでいるかも、技術体制の成熟度を見る一つの材料になります。

MLOps体制——本番運用を支える継続的な仕組み

MLOps(Machine Learning Operations。開発したモデルを本番環境で継続的に監視・更新していくための運用の仕組み)は、AI受託開発を評価するうえで見落とされやすい観点です。モデルは開発した時点の性能がそのまま維持されるわけではなく、入力データの傾向が変わることで精度が徐々に低下する場合があります。

比較の際には、モデルの精度をどのような指標で継続的に監視するか、精度低下を検知した際にどのような手順で再学習や再検証を行うかを、提案の時点で説明できるかどうかを確認します。この説明が本番開発の提案書に含まれていない場合、運用フェーズに入ってから追加の相談や追加費用が発生しやすくなります。

評価軸③データの取り扱い・セキュリティ・権利——契約前に確認すべき論点

学習データの利用範囲と権利帰属

AI受託開発では、委託元が提供するデータの利用範囲と、開発の過程で生成される学習済みモデルの権利帰属が契約上の論点になりやすい領域です。経済産業省の「AI・データの利用に関する契約ガイドライン」では、AI技術を利用したソフトウェアの開発・利用契約について、データの利用範囲や成果物の権利関係を事前に整理しておく考え方が示されています(経済産業省「AI・データの利用に関する契約ガイドライン」2018年6月)。

具体的には、提供したデータを他社案件の学習にも転用してよいか、契約終了後にデータや学習済みモデルをどちらが保持するか、といった点です。委託先を比較する際は、これらの論点についてひな形の条文を持っているか、案件ごとに個別協議する方針かを確認しておくと、契約交渉にかかる時間の見通しが立てやすくなります。

経済産業省は2025年2月に「AIの利用・開発に関する契約チェックリスト」も公表しています(経済産業省「AIの利用・開発に関する契約チェックリスト」2025年2月)。RFPの作成時や提案評価の場面で、このようなチェックリストを参考に自社の確認項目を整理しておくと、複数社の提案を横並びで比較しやすくなります。

セキュリティ・ガバナンス体制

IPAが公開している「テキスト生成AIの導入・運用ガイドライン」では、生成AIを組織で導入・運用する際に、利活用ルールやリスク管理体制を事前に整備しておくことの重要性が指摘されています^*6。同ガイドラインは、リスクマトリクスに基づく管理手法や、机上の検討だけでなく実装レベルでの検証結果を伴うセキュリティ対策の必要性にも触れています^*6。

委託先を比較する際は、こうした考え方に沿ったセキュリティ対策を、自社の言葉で説明できるかどうかを確認します。ISMSなどの認証の有無を尋ねるだけでなく、AI特有のリスク(学習データの漏えい、モデルへの不正入力など)への対応方針を具体的に説明できるかどうかが、比較の分かれ目になります。

評価軸④⑤PoCから本番化への提案力と契約・費用モデル

PoCから本番化への進め方——提案書で見るポイント

AI受託開発の提案でよく見落とされるのが、PoCの先にある本番化までの道筋です。PoCの提案だけを切り出して評価すると、検証コストは低く見えますが、本番運用に進める段階で追加の設計や再契約が必要になり、当初の想定より時間がかかることがあります。

比較の際は、PoC完了後にどのような判断基準で本番化の可否を決めるか、本番化する場合にどの工程が追加で必要になるかを、提案の段階で示してもらいます。精度指標をあらかじめ数値目標として提示しているか、評価データをどのように分けて検証するかが明確な提案は、本番化の判断がしやすい設計になっている傾向があります。

準委任・成果報酬・月額——契約形態の違いと見方

AI受託開発の契約形態は、フェーズによって適した形が異なります。要件が確定していないPoCの段階は、稼働時間に応じた対価を支払う準委任契約になりやすい領域です。要件が固まった本番開発フェーズに入ると、完成した機能や達成した指標に対して対価を支払う請負や成果報酬型の契約を組み合わせやすくなります。運用保守のフェーズは、モデルの監視や再学習対応を含めた月額の固定費で契約する形が一般的です。

システム開発契約全体の役割分担については、IPAの「情報システム・モデル取引・契約書(第二版)」が、プロジェクトマネジメント義務の明確化やセキュリティ対応など、ユーザー企業とITベンダーの双方の立場を踏まえた契約構造を整理しています^*4。AI受託開発に特化した契約ではありませんが、フェーズごとの役割と責任をどう切り分けるかという基本の考え方は共通する部分が多く、比較の際の参考になります。

費用の見積りを比較するときは、契約形態がフェーズごとに変わるかどうか、変わる場合の切り替え条件が明記されているかどうかを確認します。単一の契約形態だけで全フェーズをまとめて提案されている場合、要件変更やモデルの再学習が発生した際の追加費用の扱いが不明確になりやすい点に注意が必要です。

評価軸⑥保守運用・再学習——比較チェックリストとよくある失敗

ここまで整理した6つの評価軸を、RFPや提案評価の場で確認する項目として一覧にまとめます。

よくある失敗——PoC止まり・過大期待・データ不足

AI受託開発でよく見られる失敗のひとつが、PoCで検証を終えたまま本番化に進まない、いわゆるPoC止まりです。原因の多くは、PoCの段階で本番化の判断基準を決めていなかったことにあります。精度がどの程度であれば本番投入するのかを事前に合意していないと、検証結果をどう評価するかで議論が長引き、そのまま案件が停滞してしまいます。

もう一つの失敗パターンは、生成AI・機械学習に対する過大な期待です。これらの技術は入力データや学習内容によって出力の精度が変動するものであり、あらゆる業務課題を一律に解決できるわけではありません。要件定義の段階で「何を」「どの精度で」実現したいのかを具体的な指標に落とし込んでいない提案は、比較の対象として評価がしにくくなります。

三つめは、データ不足です。モデルの学習に必要なデータ量や品質を見積もらずに契約を進めると、開発が始まってからデータ整備に想定以上の時間がかかることがあります。委託先を比較する際は、自社が保有するデータの量と質を前提として、どの程度の精度が見込めるかを事前に説明できる提案かどうかを確認しておくと、着手後のギャップを減らしやすくなります。

まとめ：AI受託開発会社の選定で押さえる6つの判断軸

本稿ではAI受託開発の会社選びについて、公的なガイドラインを踏まえながら6つの評価軸で整理しました。要点は次の通りです。第一に、実績は件数ではなく、自社に近い業種でのPoC実績と本番運用実績を分けて確認する必要があります。第二に、技術体制はデータサイエンティスト・MLエンジニアの専任配置とMLOps体制の有無が、本番運用後の対応力を左右します。第三に、データの取り扱いや権利帰属は経済産業省のガイドラインやチェックリストを参考に事前整理しておくと交渉が進めやすくなります(経済産業省「AI・データの利用に関する契約ガイドライン」2018年6月)。第四に、PoCから本番化への道筋と契約形態の切り替え方を提案書の段階で確認しておくことが、追加費用や停滞を避ける手がかりになります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：総務省・経済産業省「AI事業者ガイドライン」（https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html）
2. *2　出典：経済産業省「AI・データの利用に関する契約ガイドライン」（2018年6月）
3. *3　出典：経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月）
4. *4　出典：IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日）（https://www.ipa.go.jp/digital/model/model20201222.html）
5. *5　出典：IPA「AIを用いたソフトウェア開発」（2023年12月20日公開、2025年5月16日更新）（https://www.ipa.go.jp/digital/ai/software-engineering.html）
6. *6　出典：IPA「テキスト生成AIの導入・運用ガイドライン」（2024年7月31日）（https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/generative-ai-guideline.html）

Tweet