この記事の要点

• AI開発のフローは「発注前4工程＋発注後3工程」の計7工程で捉えると迷わない（詳細は最初のH2の一覧表）
• 従来のシステム開発との最大の違いは、PoC（実現性検証）が入ることと、完成基準が機能ではなく精度で決まること（H2-1で対比）
• 発注者が用意しないと必ず止まるのは〈データ／評価基準／現場担当者／意思決定者〉の4点（H2-4の宿題リスト表）
• 期間の目安は、既存AIサービス活用なら1〜3か月、基幹システム連携ありのスクラッチなら6〜12か月（H2-5のスケジュール表）

AI開発を、要件定義→設計→開発→テストという普通のシステム開発と同じつもりで進めると、多くの場合PoCの途中で止まります。原因はベンダーの技術力ではなく、発注側で「どこまで正解なら合格なのか」が決まっていないこと。この記事では、AI開発のフローを発注する側が使える手順として並べ、各工程で自社が何を出し、何を決めるのかまで書きます。

AI開発のフローは全体で7工程：まず全体像を押さえる

AI開発のフローは、「①課題定義②データ棚卸し③要件整理・RFP作成④ベンダー選定」の発注前4工程と、「⑤PoC⑥本番化の判断⑦実装・運用」の発注後3工程に分けると全体像がつかめます。発注前の4工程はベンダーではなく発注者が主担当。ここが曖昧なまま声をかけると、見積が各社バラバラになり比較できません。

工程	目的	主担当	期間目安	完了条件
①課題定義	何をAIに任せるか決める	発注者	1〜2週間	対象業務と成功数値がA4:1枚に書けている
②データ棚卸し	手元のデータで解けそうか確認	発注者	1〜3週間	所在・件数・社外提供可否が一覧化されている
③要件整理・RFP	比較できる見積を取る	発注者（必要なら外部支援）	1〜3週間	精度目標・連携先・予算レンジが明記されている
④ベンダー選定	進め方と体制で選ぶ	発注者	2〜4週間	PoC範囲を揃えた見積を2〜3社で比較できた
⑤PoC	目標精度への到達と業務適合の検証	ベンダー主導＋発注者協力	1〜3か月	精度数値と本開発の見積が出ている
⑥本番化の判断	投資判断（GO/NO GO）	発注者	1〜4週間	決裁が下り、次工程の予算が確保された
⑦実装・運用	業務システムに組み込み定着させる	ベンダー主導＋現場	2〜6か月＋運用継続	現場が日常業務で使い続けている

以降のH2は、この表の各行を発注者の視点で展開したものです。表だけ持ち帰って社内共有しても意味が通るように作ってあります。

従来のシステム開発フローと違う3点（PoC・精度・データ起点）

違いは3点です。要件定義の前にデータが要ること、PoCという実現性検証の工程が入ること、完成基準が「機能が動くか」ではなく「精度が業務で使える水準か」で定義されること。この3点が、契約の形にも影響します。

通常のシステム開発なら、要件が固まれば「その機能を作る」という約束ができます。AIは違います。同じ手法でも、データの質と量によって精度は変わります。作ってみるまで結果が分からない部分があるため、精度を事前に保証する契約は現実的ではありません。そのためPoCは準委任（作業の実施に対する契約）、精度の見通しが立った後の実装は請負、という分け方が一般的です。「精度〇%を保証します」と初回提案で言い切る会社があれば、その根拠を必ず確認してください。

期間や工数の見立てについては、システム開発全般の規模別実績値が公開されており、社内説明の材料になります^※1。AI固有のPoC工程はここに上乗せされると考えると、見積の妥当性を判断しやすくなります。

発注前フェーズと発注後フェーズの分かれ目はどこか

境目は、「解きたい課題と合格ラインが言語化され、手元のデータで解けそうだと確認できた時点」です。ここが済んでいれば、複数社に同じ条件で見積を依頼できます。済んでいないままRFPを出すと、各社が勝手に前提を置くため、金額も期間も比較不能になります。

発注前に自社で終わらせるべきなのは、対象業務の選定、現状の工数やミス率の把握、データの所在確認、予算レンジの合意。一方、指標の選び方（どの精度指標を使うか）、技術方式の選択、データ量が足りるかの判断は、ベンダーに相談しながらで構いません。この線引きが分かれば、社内の負荷は思ったより小さく収まります。

それでも発注前の整理に自信が持てない場合は、要件整理だけを1〜2週間の有償アセスメントとして依頼する方法があります。いきなり本開発を発注するより、データの実態を見てもらったうえでPoCの要否を判断するほうが、結果的に無駄が減ります。

生成AI活用とスクラッチ開発でフローはどう変わる？

既存のLLM（大規模言語モデル）をAPIやRAGで使う場合、学習データの収集と学習の工程が縮み、フローは「課題定義→プロンプト・RAG設計→検証→運用」と短くなります。対してスクラッチの機械学習開発では、学習データの整備と評価が工程の中心。同じ「AI開発」でも、必要な準備物が変わります。

類型	主な工程	期間目安	必要なデータ
①既存AIサービス・API活用	課題定義→設定・プロンプト設計→試用→運用	1〜3か月	評価用の実データ数十〜数百件
②RAG（社内文書検索・回答）	課題定義→文書整備→検索設計→精度検証→連携・運用	3〜6か月	社内文書一式＋想定質問と模範回答数十〜数百件
③スクラッチの機械学習開発	課題定義→データ整備・ラベル付け→モデル試作→評価→実装・運用	6〜12か月以上	タスクにもよるが正解ラベル付きで数百〜数万件

注意したいのは②のRAG。モデルを学習させないぶん簡単に見えますが、社内文書が古い・重複している・PDFが画像のままといった状態だと、文書整備に想定外の時間がかかります。工数はモデル側ではなくデータ側に出るという構造は、どの類型でも共通です。

※1 IPA「ソフトウェア開発分析データ集」リンク

【発注前】4工程の進め方：課題定義からRFP・ベンダー選定まで

発注前は「課題定義→データ棚卸し→要件整理（RFP）→ベンダー選定」の順で進めます。それぞれのアウトプットは、課題1枚・データ一覧・RFP・比較評価表の4つ。この4点が揃った状態でベンダーに渡すと、見積の精度と比較可能性が一段上がります。合計の所要期間は、社内調整を含めて1〜2か月が目安です。

工程1：課題定義（何をAIに任せるかを1枚に落とす）

課題定義では、対象業務・現状の工数やミス率・AI化後の理想状態・成功と言える数値の4項目をA4:1枚にまとめます。ここで数値が書けない案件は、後の工程で必ず揉めます。逆に1枚が書けていれば、相談の初回から具体的な会話ができます。

悪い例は「AIで業務を効率化したい」。良い例は「月2,000件の請求書のデータ入力を、1件3分から30秒に短縮する。読み取り結果は目視確認を残す」。後者は対象・量・目標・運用条件がすべて入っています。

投資判断の材料としては、簡単な試算で足ります。1件2.5分の削減×月2,000件で月あたり約83時間。人件費単価を3,000円とすれば月25万円、年間で約300万円の削減効果です。開発費が600万円なら、単純計算で回収に約2年。この数字が出れば、稟議の土台になります。ただし削減時間がそのまま人件費削減になるとは限らないため、社内では「他業務に振り向けられる時間」として説明するほうが通りやすいでしょう。

工程2：データ棚卸し（どこに・何件・どの形式であるかを確認する）

データ棚卸しでは、所在（システム／紙／Excel）・件数・対象期間・形式・個人情報の有無・社外提供の可否という6項目を一覧化します。この一覧があるだけで、ベンダー側の見積前提のブレが大きく減ります。

量の目安は、分類のようなタスクなら正解ラベル付きで最低でも数百件、安定を狙うなら数千件が一つの水準です。決定的に効くのはラベル（正解データ）の有無。ラベルが無ければ付ける作業が発生し、そこが工数の山になります。誰が付けるのか、判断が人によってぶれないか、社内で先に確認してください。

もう一つ、見落とされがちなのが社外提供の承認です。顧客情報や取引先情報を含むデータをベンダーに渡す場合、個人情報保護法上の委託先の監督や、社内の情報セキュリティ規程に基づく承認が必要になります^※2。この手続きに2〜4週間かかるケースは珍しくありません。生成AIサービスに機密データを入力する場合も、学習利用の有無や保存期間の条件を契約・設定で確認しておく必要があります。

工程3：要件整理とRFP作成（精度目標と業務フロー上の位置づけを書く）

RFPには、目的・対象業務・データ概要・精度や評価基準・既存システム連携・予算レンジ・スケジュール・体制の8項目を最低限記載します。AI案件で特に効くのが精度の合格ラインと、PoCと本開発を分けて見積してほしいという指定の2つ。この2行があるだけで、各社の提案が比較できる形に揃います。

合格ラインの書き方は、たとえば「正答率85%以上。誤検知は担当者が確認する運用で許容する」といった具合に、数値と運用条件をセットにします。数値だけ書くと、現実的でない目標に各社が合わせて高い見積を出してきます。

そしてRFP段階で書いておかないと後で揉めるのが、次の項目です。

• 学習済みモデルとソースコードの権利帰属
• 提供データの二次利用（他社案件への流用）の可否
• PoC後に本開発を別会社に依頼する場合の成果物の扱い
• 運用開始後の再学習を誰が、どの費用で行うか
• 精度が目標に届かなかった場合の扱い（追加費用の有無）
• API利用料など従量課金の負担者
• ログや推論結果の保存期間と保存場所
• 障害時の一次対応窓口と対応時間

工程4：ベンダー選定（AI開発で見るべき比較軸）

比較軸は、同業種・同タスクの実績、PoCの進め方と中止基準の説明、評価指標の提案力、運用フェーズ（再学習・監視）の対応範囲、体制と窓口の5点です。初期費用の総額だけで選ぶと、運用費が後から乗ってきて年間コストが逆転することがあります。

相見積は2〜3社が現実的。それ以上に増やすと、比較のための社内工数のほうが大きくなります。重要なのは社数より、PoCの範囲（使用データ・検証項目・期間）を各社で揃えること。範囲が違えば金額の差は当然出るので、比較の意味がなくなります。

面談で聞く質問は、次のあたりが判断材料になります。

• このデータ量で目標精度に届かない可能性はどこにありますか
• PoCで「うまくいかない」と分かった場合、どの時点でどう報告しますか
• 精度はどの指標で測る想定ですか。その指標を選ぶ理由は何ですか
• 運用開始後、精度が落ちたときの対応は契約範囲に入りますか
• 当社側で用意すべきものを、時期とセットで挙げてください

最後の質問への回答が具体的な会社は、進め方が固まっていると考えてよいでしょう。

RFPの書き方から相談できます。hikeに相談する

※2 個人情報保護委員会「個人情報保護法」リンク

【発注後】PoC・本番判断・実装運用の3工程で何が起きるか

発注後は、PoC（実現性と精度の検証）→やる/やめるの判断ゲート→実装・システム連携・運用開始、という順に進みます。ベンダーに任せきりにできる工程はありません。データ提供、精度評価への同席、現場テスト、業務フローの変更決定は、いずれも発注者側の作業です。

工程5：PoC（何を検証し、どこまでやったら終わりか）

PoCの目的は2つだけです。手元のデータで目標精度に届くか、そして業務フローに組み込めるか。開始前に期間（1〜3か月）・使用データ・合格ライン・中止条件の4点を合意しておけば、PoCは終わります。逆に、この合意がないPoCは終わりません。

中身は、データの前処理→モデルの試作→精度測定→現場での試用という流れ。成果物は検証レポート、精度の数値、次工程の見積の3点セットが標準です。現場での試用まで含まれているかは、契約前に確認してください。数値上は良くても、画面の操作が業務の流れに合わずに使われないケースがあります。

いわゆる「PoC疲れ」は、合格ラインを決めずに始めるから起きます。80%の精度が出たとき、それが合格なのか不合格なのかを決める基準がなければ、「もう少し上げてみよう」を繰り返すしかありません。実証段階にとどまる取り組みが少なくない状況は、公的な調査でも指摘されています^※3。技術の問題というより、終わり方を決めていない設計の問題です。

工程6：本番化するかの判断ゲート（判断材料と撤退基準）

判断は3点で決めます。目標精度に到達したか、届かない場合に人の確認工程で埋められるか、本開発費と年間の削減効果が釣り合うか。この3点をGO/NO GO/条件付きGOの3択に落とすと、経営層への説明がぶれません。

判断	条件	次のアクション
GO	目標精度に到達し、費用対効果も成立	本開発の見積確定と発注
条件付きGO	精度は未達だが、人の確認を挟む運用で業務が回る	対象範囲を絞って小さく本番化
NO GO	データ量や品質が不足し、改善の見通しが立たない	データ収集の仕組みづくりを先に実施

NO GOは失敗ではありません。「このデータ量では成立しない」と分かったこと自体が投資判断の成果です。数百万円の本開発に進む前に止められたなら、PoCは役割を果たしています。報告資料には、検証条件・使用データ・精度の実測値・未達の原因・次に必要な打ち手を並べておくと、次年度の再挑戦につなげやすくなります。

工程7：実装・システム連携・運用開始（リリース後にやることが残る）

本開発では、業務システムとの連携、画面（UI）、権限とログ、運用手順書の整備を行います。そしてリリース後も、精度のモニタリングと必要に応じた再学習が続きます。AI開発は納品して終わりにならない、という前提で予算を組んでください。

運用フェーズで発生する費用項目は、API利用料などの従量課金、インフラ費、監視・障害対応、再学習、問い合わせ対応。合計の年間保守費は、開発費の15〜20%程度をひとつの目安にしつつ、従量課金の想定利用量によって上下します。利用が増えるほどAPI費用も増える構造なので、月間の処理件数を見積前提として共有しておくことが大切です。

精度が時間とともに落ちる現象（データドリフト）も想定に入れます。取扱商品が変わる、帳票のフォーマットが変わる、問い合わせの傾向が変わる。こうした変化で、学習時の前提と現実がずれていきます。月次または四半期ごとに精度を測り、閾値を下回ったら再学習するといった運用ルールを決めておきましょう。AIの出力を人が確認する体制や、判断の記録を残す考え方は、国が示すガイドラインでも基本の一つとして整理されています^※4。

※3 IPA「DX白書」リンク

※4 経済産業省・総務省「AI事業者ガイドライン」リンク

工程ごとに発注者が用意するもの一覧（発注者の宿題リスト）

AI開発が止まる原因は、ほぼ「データ・評価基準・現場担当者・意思決定者」の4点が発注側で用意されていないことに集約されます。技術的に難しくて止まるケースより、この4点の未整備で止まるケースのほうが多いのが実情です。以下の表を、そのまま社内の準備チェックリストとして使ってください。

工程	発注者の提出物	決めること	必要な社内承認
①課題定義	課題整理シート1枚	対象業務と成功の数値	部門長の合意
②データ棚卸し	データ一覧、サンプル数十件	抽出担当者と抽出方法	情シスへの抽出依頼
③要件整理・RFP	RFP、既存システム構成の概要	精度の合格ラインと予算レンジ	予算枠の内諾
④ベンダー選定	比較評価表	選定基準と重み付け	選定の決裁
⑤PoC	本番相当データ、評価用データ	中止条件と検証スケジュール	データ社外提供の承認
⑥本番化の判断	PoC結果の社内報告資料	GO/NO GO/条件付きGO	本開発予算の稟議
⑦実装・運用	業務手順書、テスト担当者	変更後の業務フローと責任者	運用予算と体制の承認

データ：誰がどの承認を通して出すのかを先に決める

必要なのはデータそのものだけではありません。抽出できる人、抽出にかかる工数、社外提供の承認ルート。この3つを決めずにPoCを始めると、初月がまるごとデータ待ちで消えます。契約期間は進むのに、検証は止まったまま。よくある構図です。

典型的な詰まり方は、CSV抽出の依頼が情シスの通常業務の後回しになる、個人情報のマスキング作業の担当が決まっていない、紙の資料をスキャンする人手がない、基幹システムからの出力形式がベンダーの想定と違う、といったところ。どれも技術の問題ではありません。

対策はシンプルです。キックオフの前に、サンプルデータを数十件だけ出しておきましょう。少量でも実物が出れば、形式の問題も承認の壁も、契約前に見つかります。

評価基準：何%で合格かを決められるのは発注者だけ

精度の合格ラインは、業務上どこまで誤りを許せるかで決まります。これを知っているのは業務側であって、ベンダーではありません。「精度はどのくらい必要ですか」と聞かれて答えられないと、PoCはゴールのない検証になります。

決め方の手順は2段階。まず現状の人による作業の精度を測ります。人が98%の精度で処理している業務にAIで90%を求めても現場は使いません。逆に、人でも見落としが出ている業務なら85%でも十分な戦力になります。次に、見逃しと過検知のどちらが痛いかで指標を選びます。不良品検査のように見逃しが致命的なら再現率（リコール）重視。確認工数の削減が目的なら、無駄な検出を減らす適合率（精度）重視です。

どうしても数値が決められない場合は、現状のミス率を2週間ほど実測してからPoCを始める方法があります。基準がないまま走り出すより、着手が2週間遅れるほうがはるかに安全です。

現場の担当者と意思決定者：兼務のまま進めると必ず遅れる

必要な体制は2ロールです。業務を説明できる現場担当者（週2〜4時間の確保）と、費用と業務変更を判断できる意思決定者。この2人が確保できていないプロジェクトは、レビューと判断が滞ってスケジュールが伸びます。

現場担当者の役割は、業務の例外パターンを説明すること、検証結果を見て「これは業務で使える／使えない」と評価すること。この判断はベンダーにはできません。通常業務との兼務は前提として、週次30〜60分のレビュー会を固定枠で押さえておくと、確認待ちの停滞が減ります。

意思決定者について事前に確かめておきたいのが決裁ラインです。PoC後の本開発は追加投資になるため、稟議に1か月かかると、その間プロジェクトは完全に止まります。PoCの開始時点で「いくらまでなら誰の決裁か」「稟議に何週間かかるか」を確認し、スケジュールに織り込んでおきましょう。

AI開発のスケジュール目安と、遅れる原因・短縮する方法

期間の目安は、生成AI活用の小規模な案件で1〜3か月、PoC込みで業務システム連携ありなら6〜12か月。ここで押さえておきたいのは、遅延の大半がモデル開発ではなくデータ準備と社内承認で発生する点です。開発工数の見積が正確でも、そこ以外で数週間ずつ積み上がります。

工程	期間目安	発注者稼働の山場
①〜②課題定義・データ棚卸し	2〜5週間	データ抽出依頼と社内調整
③〜④RFP・ベンダー選定	3〜7週間	提案評価と予算確保
⑤PoC	1〜3か月	データ提供、評価会への同席
⑥本番化の判断	1〜4週間	稟議と決裁
⑦実装・運用開始	2〜6か月	受入テスト、業務手順の変更

規模別の工数や工期の実績値はシステム開発全般として公開されているため、自社の見積が極端に外れていないかの確認に使えます^※1。

規模別のスケジュール目安（1〜3か月／3〜6か月／6〜12か月）

類型ごとに、省略できる工程が違います。既存AIサービス・API活用なら1〜3か月、RAGや社内文書検索なら3〜6か月、基幹システム連携ありのスクラッチ開発なら6〜12か月以上が目安。いずれもデータの整備度によって前後2か月ほど動きます。

1〜3か月の類型では、学習工程がないぶんPoCが短く済み、時間は業務フローへの組み込みと運用ルールづくりに集中します。3〜6か月の類型では、文書の整理と検索精度の調整が山場。6〜12か月の類型は、データのラベル付けと既存システムとの連携仕様の確定に最も時間がかかります。「AIを作る期間」より「データを揃える期間」と「つなぎ込む期間」が長い、と理解しておくと計画が現実的になります。

スケジュールが遅れる典型パターン3つとその原因

遅延はほぼ3パターンで説明できます。データ提供待ち、合格ライン未定でPoCが終わらない、本番化の稟議待ち。どれも発注側の準備と意思決定に起因するもので、事前に潰せます。

• データ提供待ち（2〜6週間の遅れ）：抽出担当と社外提供の承認ルートを、契約前に決めておく。サンプルを先に出す
• PoCが終わらない（1〜3か月の遅れ）：開始前に合格ラインと中止条件を文書で合意する。「精度が出なければ終了」も正式な着地点として書いておく
• 稟議待ち（3〜8週間の遅れ）：PoC開始時に決裁ラインと稟議期間を確認し、報告資料の様式を先に決めておく

それぞれの遅れは単独では数週間でも、直列でつながると半年になります。逆に言えば、この3つを事前に潰すだけでスケジュールの信頼度は大きく上がります。

期間を短縮する進め方（並行作業と対象業務の絞り込み）

短縮策は4つ。対象業務を1つに絞る、データ準備と要件整理を並行させる、PoCの評価データを先に用意する、内製と外注の分担を決める。中でも効果が大きいのは、対象業務の絞り込みです。

スコープを広げると、検証の工数は業務の数だけ増えます。3業務を同時に対象にすれば、データ整備も評価基準も現場調整も3セット必要。しかも1つでも精度が出なければ、全体の判断が止まります。最初のリリースは1業務・1部署に限定し、そこで運用が回ってから広げるほうが、結果的に全社展開は早く着地します。

内製と外注の分担も期間に効きます。データ抽出とラベル付けを自社で担えるなら、その分の工数と待ち時間が減ります。逆に、ここを担当できる人がいないなら最初から外注範囲に含め、費用として見込むほうが確実です。社内にまだ何も準備がない状態なら、1〜2週間のアセスメントを依頼して現状のデータと課題を整理してもらうところから始める選択肢もあります。

※1 IPA「ソフトウェア開発分析データ集」リンク

まとめ：AI開発フローを発注者視点で押さえる要点

AI開発のフローは、発注前4工程（課題定義・データ棚卸し・要件整理とRFP・ベンダー選定）と発注後3工程（PoC・本番化の判断・実装と運用）の計7工程。発注前の4工程は自社が主担当であり、ここの完成度が見積の比較可能性とスケジュールの信頼度を決めます。

そして、工程が止まる原因は次の4点に集約されます。

• データ：誰が抽出し、どの承認を通して社外に出すのか
• 評価基準：何%で合格とするのか。見逃しと過検知のどちらを避けたいのか
• 現場担当者：業務を説明し、結果を評価できる人を週2〜4時間確保できるか
• 意思決定者：PoC後の追加投資を、何週間で決裁できるか

次のアクションは段階的に進めてください。まず課題整理シート1枚とデータ一覧を作ります。次に社内で合格ラインの仮案を決めます。その状態でベンダー2〜3社に相談します。この順番なら、初回の打ち合わせから具体的な話ができます。

逆に、課題やデータの整理段階で手が止まっているなら、要件整理から相談に乗れる開発会社に早めに当たるほうが手戻りは減ります。作るものが決まっていない段階でも、判断材料を揃えるための相談はできます。

よくある質問

AI開発はウォーターフォールとアジャイルのどちらで進めるべきですか

実務ではハイブリッドが現実的です。PoCは試行錯誤が前提なので短いサイクルで検証を繰り返すアジャイル的な進め方、精度の見通しが立った後の実装（画面・システム連携・権限管理）は要件を固定しやすいので請負契約でのウォーターフォール的な進め方、という分け方がよく使われます。契約形態もPoCは準委任、実装は請負と分けるのが一般的です。

PoCは必ず必要ですか

省略できる場合があります。既存のAIサービスをそのまま使う、前例が明確で同種のデータで実績がある、といったケースでは、小規模な試用で代替できます。逆に、自社固有のデータで学習させる、精度が業務判断に直結する、データ量に不安がある場合は、PoCを挟んだほうが結果的に安く済みます。判断基準は「精度が出なかったときの損失が、PoC費用より大きいかどうか」です。

データが足りない場合はどうなりますか

選択肢は3つです。データを集める工程を先に置く（数か月かけて蓄積の仕組みを作る）、学習済みの既存モデルやAPIを使って自社データへの依存を減らす、外部データを購入・利用する。どれを選ぶかは、業務の固有性で決まります。自社特有の判断が必要なタスクほど、自社データの蓄積から始める必要があります。

開発費用の目安はどれくらいですか

単一の金額では表せません。PoCは検証範囲と期間、本開発は連携先システムの数・データ整備の量・要件の固まり具合で大きく上下します。見るべきは総額より内訳で、データ整備の工数がどこに計上されているか、運用費（API利用料・再学習・監視）が別枠か込みかを確認してください。なお2026年時点では中小企業向けのIT導入補助金などの制度があり、対象や要件は年度で変わるため、最新の公募要領で必ず確認してください^※5。

社内に技術者がいなくても発注できますか

できます。発注側に必要なのは業務知識と意思決定であって、技術の詳細ではありません。業務の例外パターンを説明できること、精度の合格ラインを判断できること、データの所在を追えること。この3つがあれば進みます。技術的な翻訳や方式の選定はベンダー側の役割なので、専門用語のまま説明する会社より、業務の言葉に置き換えて話す会社を選ぶほうが安全です。

各工程ではどんな成果物が作られますか

発注前は課題整理シート、データ一覧、RFP、ベンダー比較表。発注後はPoC計画書、PoCレポート（精度の実測値と条件）、要件定義書、設計書、テスト結果、運用手順書、精度モニタリングの記録が標準的です。特にPoCレポートは、検証条件と使用データが明記されているかを確認してください。条件が書かれていない精度の数値は、本番環境での再現性を判断できません。

開発したAIモデルの権利は誰のものになりますか

契約で決まります。自動的に発注者のものになるわけではないため、RFPと契約書の段階で、モデル・学習データ・ソースコードそれぞれの権利帰属と再利用条件を明記してください。提供した自社データが他社案件の学習に使われないか、PoC後に別会社へ引き継げるかも、この段階で確認しておくべき項目です。

※5 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク

参考文献

• IPA「ソフトウェア開発分析データ集」リンク
• IPA「DX白書」リンク
• 経済産業省・総務省「AI事業者ガイドライン」リンク
• 個人情報保護委員会「個人情報保護法」リンク
• 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク