この記事の要点
- AIシステム開発とは、予測・分類・文章生成といったAIの推論機能を、既存の業務システムや業務フローに組み込む開発のこと
- 従来のシステム開発との差は「精度を事前に確約できない」「データ整備が開発より先に来る」「評価基準を決めないと検収できない」の3点
- 進め方は課題定義→データ棚卸し→PoC→本開発→運用の5ステップ。PoCで続行か中止かを判断する点が従来開発と大きく違う
- 費用はPoCで数十万〜数百万円、本開発で数百万〜数千万円が目安。契約は準委任を軸にフェーズを分けるのが実務的
「AIで何かできないか」と言われたものの、何から手を付ければいいか分からない。その状態のまま開発会社に相談すると、話が技術の説明に流れてしまい、判断材料が増えないまま時間だけが過ぎます。この記事は技術解説ではありません。発注する側が社内検討と外注先の比較にそのまま使える判断軸をまとめたものです。AIシステム開発が従来開発と何が違うのか、その違いが見積もりと契約にどう跳ね返るのか。そこを押さえておくと、提案書の読み方が変わります。
目次
AIシステム開発とは？従来のシステム開発と違う3つのポイント
AIシステム開発とは、AIによる予測・分類・文章生成などの推論機能を業務システムに組み込む開発を指します。従来のシステム開発との違いは、精度を事前に確約できないこと、データ整備が開発に先行すること、評価基準を決めないと検収できないことの3点です。この差がそのまま契約形態・見積もり・検収条件に跳ね返ります。
| 比較軸 | 従来のシステム開発 | AIシステム開発 |
|---|---|---|
| 成果物の性質 | 仕様どおりに動くプログラム | 確率的に出力するモデルと、それを組み込んだ仕組み |
| 要件定義のしかた | 画面・機能・処理を事前に確定できる | 目的と合格ラインを先に決め、精度は作りながら確かめる |
| 必要な前工程 | 業務ヒアリング | 業務ヒアリングに加え、データの棚卸しと整備 |
| 完成の判定 | 仕様書どおり動けば検収 | 事前合意した指標と合格ラインを満たすかで判定 |
| 契約形態 | 請負が中心 | PoC・モデル構築は準委任、周辺実装は請負と使い分け |
| 運用後の作業 | 障害対応・機能追加 | 精度の監視、再学習、プロンプト調整、モデル更新への追随 |
AIシステム開発の定義と、生成AI活用型・予測モデル構築型の違い
AIシステム開発とは、学習済みモデルや自社データで作ったモデルの判断を、業務の流れの中で使えるようにする開発です。実務上は生成AI活用型と予測モデル構築型の2つに分かれ、どちらを想定しているかで期間も費用も進め方もまったく変わります。
生成AI活用型は、既存の大規模言語モデルをAPI経由で呼び出し、社内文書の検索、文章の要約、問い合わせへの一次回答などに使う形です。学習データの準備が比較的軽く、短期間で試作できます。一方の予測モデル構築型は、自社に蓄積したデータを学習させて需要予測・異常検知・スコアリングを行う形です。データの量と質が成否をほぼ決めるため、期間も費用も重くなります。
相談の入口で「うちはどちらの話をしているのか」を先に決めておくと、開発会社との会話がかみ合います。逆にここが曖昧だと、提案書の前提がバラバラになり、相見積もりの比較が成立しません。
違い①精度は事前に確約できない（100点にはならない前提で設計する）
AIの出力は確率的なので、開発前に「精度98%を保証します」と約束することは原理的にできません。発注側がやるべきことは精度を保証させることではなく、「精度が何%なら業務が回るか」を先に決めることです。この順序が逆になると、検収の段階で必ずもめます。
たとえば請求書の読み取りで精度95%が出たとします。残り5%は誤読するわけですから、誰がどのタイミングで確認するのか、誤りを見つけたらどう修正して基幹システムに戻すのかを決めておかないと、現場は使ってくれません。問い合わせ対応AIも同じで、AIが答えられなかったとき、確信度が低いときに、どの窓口へどう引き継ぐかまでが設計範囲です。
AI事業者ガイドラインでも、AIの利用にあたって人間による関与や適切なリスク管理の重要性が示されています※1。つまり「AIが間違えたときのリカバリ導線」は、おまけではなく本体の一部だと考えてください。ここを見積もりに含めていない提案は、後から追加費用が発生しやすい構造になっています。
違い②データ整備が開発より先に来る（データがないと着手できない）
AIシステム開発では、プログラムを書く前にデータの所在・量・質・権利関係を確認する必要があります。この前工程が全体工数のかなりの割合を占めることも珍しくありません。データが揃っていない状態での見積もりは、前提が空欄のまま出された数字だと考えたほうが安全です。
発注前に自社で確認しておきたい観点を挙げます。
- 対象データがどこにあるか（基幹システム、Excel、紙の帳票、担当者の記憶）
- 機械が読める形式か（PDFの画像スキャンだけ、という状態は要注意）
- 過去何年分・何件分あるか
- 正解にあたるラベル（結果・判定・処理区分）が付いているか
- データの表記ゆれや欠損がどの程度あるか
- 個人情報や取引先情報が含まれていないか、含まれる場合の利用目的は整理できているか
- 社外のクラウドや外部モデルに送信してよいデータか
- データの更新頻度と、更新を誰が担当しているか
個人情報を含むデータを扱う場合は、利用目的の特定や第三者提供の考え方など、個人情報保護法の枠組みを踏まえた確認が必要になります※2。「紙とExcelしかない」というケースでは、デジタル化とデータ整備そのものが最初のプロジェクトになります。この場合、AI開発の見積もりを取る前に、データ整備の範囲を切り出して考えたほうが判断しやすくなります。
違い③評価基準を決めないと検収できない（何をもって完成とするか）
従来のシステム開発は仕様どおり動けば検収できます。AIは動いても「使えるかどうか」が別問題になるため、着手前に合格ラインを数値で合意しておかないと、検収の場で「思っていたのと違う」という水掛け論になります。
着手前に合意しておきたい項目は次のとおりです。
- 評価に使うテストデータを誰がいつ用意するか（本番と同じ性質のデータであること）
- 評価指標を何にするか（正答率、再現率、適合率、業務KPIによる代替指標）
- 合格ラインの数値（例：仕分け精度90%以上、確認工数を月40時間削減）
- 合格ラインを満たさなかった場合の扱い（追加チューニングの回数上限、打ち切り条件）
- 評価を実施する主体と、判定に立ち会う社内の責任者
ここで見落とされやすいのが、指標の選び方です。見逃しが致命的な検査業務なら再現率を重視し、誤検知が現場の手間を増やす業務なら適合率を重視する、という具合に、業務の性質で見るべき数字が変わります。「正答率90%」だけを条件にすると、業務上いちばん困る間違いを見逃す設計になりかねません。評価基準の設計こそ、発注側が主導すべき領域です。
※1 経済産業省・総務省「AI事業者ガイドライン」リンク
※2 個人情報保護委員会「個人情報保護法」リンク
AIシステム開発で何ができる？向いている業務・向かない業務
AIシステム開発が効くのは、判断基準を過去データから学べて、処理件数が多く、間違いを人が拾えるフローがある業務です。逆に、判断根拠の説明責任が重い業務や、そもそもデータが蓄積されていない業務は向きません。向き不向きの見極めを飛ばすと、PoCで止まる確率が上がります。
業務別のAIシステム活用例（問い合わせ・書類処理・予測・社内検索）
代表的な適用領域は、問い合わせの一次対応、書類の読み取りと基幹連携、需要や受注の予測、社内ドキュメント検索の4つです。いずれも「全部を自動化する」のではなく、人が判断する部分を残す設計が前提になります。
- 社内問い合わせ・カスタマーサポートの一次回答：定型質問への回答を自動化し、判断が要る案件は担当者へ引き継ぎます。効果は一次対応件数の削減率で測るのが分かりやすい形です。
- 請求書・申込書・図面などの読み取り：帳票から項目を抽出し、基幹システムへ登録します。人は例外や読み取り信頼度の低いものだけを確認します。効果測定は1件あたりの処理時間と修正率で行います。
- 需要予測・在庫最適化・受注予測：過去の販売実績や季節要因から数量を予測します。予測をそのまま発注に使うのではなく、担当者が調整する運用から始めるケースが一般的です。
- 社内ドキュメント検索（RAG）：規程やマニュアル、過去案件の資料を横断的に探し、根拠となる原文を提示します。回答の正しさは出典の提示で担保します。
いずれも効果は「削減できた時間×人件費単価」か「処理できる件数の増加」で見ます。導入前に現状の数値を取っていないと、後から効果を説明できなくなる点には注意してください。
AIに向かない業務の見分け方（この3条件に当てはまるなら見送る）
判断根拠を100%説明する必要がある業務、月間の処理件数が少なく費用対効果が出ない業務、判断基準が担当者ごとにバラバラでデータ化されていない業務。この3つのいずれかに当てはまるなら、現時点でのAI化は見送る判断が妥当です。
説明義務がある領域とは、人事評価や与信、安全に直結する判定など、なぜその結論になったかを第三者に示す必要がある業務を指します。説明可能性を担保する仕組みまで作るとコストが跳ね上がります。処理件数が少ないケースは単純な採算の問題で、月に数十件の処理のために数百万円をかける合理性はありません。判断基準がデータ化されていない場合は、そもそも学習させる正解が存在しない状態です。ベテランの頭の中にしかない基準は、まずルール化とデータ化から始まります。
また、AI以外の手段のほうが早いケースも多くあります。入力と転記の繰り返しならRPAや既存SaaSの連携機能で足りますし、そもそも承認フローを減らせば済む話もあります。AIを使わない判断も、立派な検討結果です。
効果が出る案件・出ない案件を分ける「業務量×許容誤差」の考え方
AI化の投資対効果は、対象業務の処理件数（量）と、間違いをどこまで許容できるか（許容誤差）の掛け算でおおよそ決まります。この2軸に自社業務を置くだけで、優先順位はかなり整理できます。
| 許容誤差が大きい（人が直せる） | 許容誤差が小さい（間違えると重大） | |
|---|---|---|
| 処理件数が多い | 最優先。効果が出やすく、投資回収も読みやすい | 人のチェックを併用し、一部工程だけに適用する |
| 処理件数が少ない | 見送り、またはSaaSやRPAで代替 | AI化は非推奨。業務フロー自体の見直しを検討 |
自社業務を当てはめる手順は次のとおりです。
- 対象候補の業務について、月間の処理件数と1件あたりの所要時間を実測します。
- その業務で誤りが出たときに誰がいつ気づけるかを確認します。気づける仕組みがあれば許容誤差は大きいと判断できます。
- 削減見込み時間に人件費単価を掛け、想定投資額と比べます。
この手順で数字が合わない業務は、いったん候補から外して構いません。
AI開発の進め方は？発注から本番運用までの5ステップ
AI開発は、課題定義、データ棚卸し、PoC（実証）、本開発と業務組み込み、運用と再学習の5ステップで進みます。従来開発と最も違うのはPoCを挟み、そこで続行するか中止するかを判断する点です。最初から本番開発の一括発注に飛ばない進め方が、結果的に無駄を減らします。
| ステップ | 期間の目安 | 発注側の作業 | 成果物 |
|---|---|---|---|
| 1. 課題定義 | 2週間〜1ヶ月 | 対象業務の特定、現状工数の数値化 | 目的と成功判定の数値 |
| 2. データ棚卸し | 2週間〜1ヶ月 | データの所在・形式・権利の確認 | データ一覧とサンプル |
| 3. PoC | 1〜3ヶ月 | 評価への立ち会い、業務側の意見出し | 精度評価レポートと続行判断 |
| 4. 本開発 | 3〜6ヶ月 | 連携先の仕様提供、受入テスト | 本番システムと運用手順 |
| 5. 運用・再学習 | 継続 | 精度と利用状況のモニタリング | 改善サイクル |
STEP1-2：課題定義とデータ棚卸し（発注前に自社でやること）
最初にやるのはAIツール選びではありません。対象業務の特定と、成功と判断する数値の設定、そして使えるデータの所在確認です。ここが曖昧なままRFPを出すと、開発会社はリスクを織り込むため見積もりが跳ね上がります。
発注前に用意しておきたい情報は次のとおりです。現状の業務フローと月間処理件数、その業務にかかっている工数とコスト、達成したい数値、データの保管場所と形式と保有期間、そして社内で誰が予算と要件の判断権を持つのか。特に最後の判断権は忘れられがちですが、PoCの結果を見て続行か中止かを決める人が不在だと、プロジェクトはその場で止まります。
この段階は自社だけで完結できます。期間は2週間から1ヶ月程度を見ておくと現実的です。
STEP3：PoC（実証実験）で精度と費用対効果を見極める
PoCは、小さなデータで実際に精度が出るかを確かめ、本開発に進むかを判断する工程です。期間は1〜3ヶ月、費用は数十万円から数百万円規模が目安になります。ここで「進まない」と決めることも、正しい成果のひとつです。
PoCの前に必ず決めておく項目は、評価指標、合格ライン、テストデータの3つ。逆に、PoC倒れになる案件には共通のパターンがあります。目的が「AIを試すこと」になっている、評価基準を結果が出てから決めている、本番と性質の違うきれいなデータだけで検証している、という3つです。特に3つ目は要注意で、整った過去データでは高精度が出ても、現場の実データでは表記ゆれや例外が多く精度が落ちます。
なお生成AI活用型の場合は、大がかりなPoCではなく数週間の短期プロトタイプで見極められることもあります。どちらの型かによってPoCの重さが変わる点は、提案を受ける際に確認してください。
STEP4：本開発と既存システムへの組み込み
本開発では、AIそのものより周辺の作り込みのほうが工数を占めることが多くあります。既存システムとの連携、画面、権限管理、ログ、例外時の運用フロー。ここを軽く見積もった提案は、後半で必ず膨らみます。
確認しておきたいのは、連携先システムの数と種類（基幹、販売管理、グループウェア、クラウドストレージなど）、応答速度や同時利用数といった非機能要件、機密データの保管場所、監査ログの要否です。ソフトウェア開発の工数と規模の関係については、IPAが規模別の実績値を公開しており、周辺システムの規模感を見積もる際の参考になります※3。
あわせて、AIが誤った出力をしたときに人が介入する導線を業務フローに埋め込みます。確信度が一定を下回ったら人の確認に回す、修正内容を記録して次の改善に使う、といった仕組みです。期間の目安は3〜6ヶ月ですが、連携先の数と社内の意思決定スピードで前後します。
STEP5：運用・精度モニタリング・再学習（作って終わりにならない）
AIは業務やデータが変われば精度が落ちます。稼働後も精度の監視と再学習、プロンプトの調整が必要になるため、その運用費を初期の見積もり段階で織り込んでおく必要があります。運用費を計上していない計画は、稼働後に予算が付かず放置される典型パターンです。
監視する指標は、正答率の推移、人による修正率、そして実際の利用率の3つ。利用率が下がっているなら、精度以前に業務フローへの組み込み方に問題があります。再学習の頻度は業務の変化速度によって変わり、季節性のある予測業務なら数ヶ月ごと、社内文書検索なら文書追加のたびに更新する形が一般的です。
外部モデルを使う場合は、提供事業者のバージョン更新への追随も必要になります。運用費は初期開発費の年10〜20%程度を目安として置き、対象範囲を契約書で明確にしておくと安全です。金額は監視項目や対応時間帯によって上下します。
※3 IPA「ソフトウェア開発分析データ集」リンク
AIシステム開発の費用と契約はどう決まる？見積もりの読み方
費用の目安は、PoCで数十万〜数百万円、本開発で数百万〜数千万円です。精度という成果を事前に確約できない性質上、契約は請負一本ではなく準委任が選ばれやすく、フェーズを分けて契約するのが実務上の主流になります。金額そのものより、見積もりの前提条件がどこまで書かれているかを見てください。
フェーズ別の費用目安（PoC・本開発・運用）
費用はフェーズごとに性質が異なります。下表は前提を「対象業務が1つに絞られている」「連携先システムが1〜2件」とした場合の目安で、データ整備が未着手ならこれに整備費用が上乗せされます。
| フェーズ | 期間の目安 | 費用の目安 | 主な作業 |
|---|---|---|---|
| 課題定義・データ棚卸し | 1ヶ月前後 | 数十万円規模、または自社対応 | 業務整理、データ調査、要件の骨子作り |
| PoC | 1〜3ヶ月 | 数十万〜数百万円 | データ加工、モデル試作、精度評価 |
| 本開発 | 3〜6ヶ月 | 数百万〜数千万円 | システム連携、画面、権限、運用フロー実装 |
| 運用・保守 | 継続 | 初期開発費の年10〜20%程度 | 精度監視、再学習、モデル更新追随 |
生成AI活用型は既存モデルを使うため、予測モデル構築型より初期費用が抑えられる傾向があります。ただし従来開発にはない費目として、API利用料や推論基盤の利用料といったランニングコストが発生します。処理件数に比例して増える費目なので、想定件数が2倍になったときにいくらになるかを、提案時点で試算してもらってください。
請負と準委任、AI開発ではどちらの契約が適切か
精度という成果を事前に確約できない以上、PoCやモデル構築は準委任、仕様が確定した周辺システムの実装は請負、とフェーズごとに契約を分けるのが現実的です。全工程を一括請負で受ける提案は、開発会社側がリスク分を上乗せしているか、精度リスクを理解していないかのどちらかである可能性があります。
契約時に確認したい条項を挙げます。
- 成果物の定義（モデル、ソースコード、評価レポート、ドキュメントの範囲）
- 学習済みモデルと学習データの権利帰属
- 提供したデータを他社案件や事業者側の学習に使わせない旨の取り決め
- 精度が合格ラインに届かなかった場合の対応範囲
- 追加チューニングの回数上限と、それを超えた場合の費用
- 運用保守の対応時間帯と、対応する障害の範囲
- 再委託の可否と、データを扱う範囲
特に見落とされやすいのがデータの権利と機密の扱いです。自社の業務データを渡す以上、どこに保存され、誰がアクセスでき、契約終了後にどう消去されるのかを書面で確認してください。個人情報を含む場合は、委託先の監督義務も踏まえた整理が必要になります※2。
見積もりが跳ね上がる3つの要因と、事前に抑える方法
見積もりが膨らむ主因は、データが整備されていないこと、既存システム連携の要件が後から増えること、合格ラインが決まっておらず作り直しが発生することの3つです。いずれも発注側の準備で相当程度抑えられます。
データ整備については、サンプルデータを事前に提供するだけで見積もりの精度が上がります。数十件でも実物を見せれば、開発会社は加工工数を具体的に読めるからです。連携要件については、連携先システムの仕様書やAPI仕様の有無を最初に伝えてください。仕様書がない古い基幹システムは、調査工数そのものが費用に乗ります。合格ラインについては、評価指標と数値を発注側から提示するのが最も効果的です。
相見積もりを取るときは、各社に同じ前提条件（対象業務、件数、データの状態、合格ライン、連携先）を渡してください。前提が揃っていない見積もりを金額だけで比べても、安い提案が本当に安いのかは判断できません。
見積もりの前提が揃っているか、一緒に確認します。hikeに相談する
※2 個人情報保護委員会「個人情報保護法」リンク
内製と外注どちらを選ぶ？AI開発会社の見極めチェックリスト
AI人材とデータ基盤が社内にあり、継続的に改善する体制を持てるなら内製、初回導入で判断基準がない段階なら外注が現実的です。外注先はAIの技術力よりも、業務を理解して評価基準を一緒に決められるかで選んでください。技術だけで選ぶと、使われないシステムが残ります。
内製・外注の判断軸（人材・データ・スピード・継続性）
判断軸は、人材の有無、データ基盤の整備状況、立ち上がりのスピード、改善を続けられる体制の4つです。下表で自社がどちらに寄るかを確認してください。
| 比較軸 | 内製 | 外注 |
|---|---|---|
| 初期コスト | 採用・育成の先行投資が必要 | プロジェクト単位で発生し、予算化しやすい |
| 立ち上がりスピード | 体制構築から始まるため遅くなりやすい | 経験のある体制をすぐ確保できる |
| ノウハウの蓄積 | 社内に残る | 意識的に引き継がないと残らない |
| 改善の継続性 | 担当者がいる限り小回りが利く | 都度の契約が必要で、機動力は落ちる |
| 失敗時のリスク | 人件費が固定費として残る | フェーズ単位で止められる |
IPAのDX白書では、DX推進やデジタル人材の確保が国内企業の課題として継続的に取り上げられています※4。人材確保が難しい中小企業では、初回は外注し、運用フェーズで監視や軽微な調整を社内に寄せていくハイブリッドが現実解になりやすい構図です。その場合は、契約時にドキュメントと運用手順の引き渡しを成果物に含めておいてください。
発注先を選ぶときに確認したい7つの質問
開発会社の良し悪しは、精度の話を安請け合いしないか、評価基準を一緒に決めてくれるかで見分けられます。次の7つを同じ順番で各社に聞くと、比較がしやすくなります。
- 同じ業種・同じ業務での実績はありますか（実績の有無と、その業務の何が難しかったか）
- 精度の合格ラインはどう設定しますか（指標の選び方の説明があるか）
- データが不足していた場合、どう進めますか（代替案を示せるか）
- PoCで中止になった場合、成果物と費用の扱いはどうなりますか
- 既存システムとの連携実装まで対応できますか（AI部分だけの会社か）
- モデルと学習データの権利はどちらに帰属しますか
- 運用保守の範囲と費用はどこまで含まれますか
逆に警戒したいサインもあります。精度を数値で安易に保証する、PoCを挟まず全工程を一括請負で提案する、業務の話を聞かずに技術構成の説明ばかりする、運用費の話が見積もりに出てこない。いずれも、稼働後に負担が発注側へ戻ってくる可能性があります。
発注前に社内で決めておく3つのこと（そのままRFPに使える）
発注前に決めるべきは、対象業務と現状の工数、成功と判断する数値、使えるデータの所在と形式の3点です。これが揃うと見積もりの精度が上がり、複数社の比較検討も成立します。次の項目を埋めて、そのまま相談資料に使ってください。
- 対象業務名：（例）受注データの入力と照合
- 月間処理件数：（ ）件／担当者数：（ ）名
- 現状の月間工数：（ ）時間／おおよその月額コスト：（ ）円
- 達成したい数値：（例）確認工数を月（ ）時間削減
- 合格ラインとする精度：（ ）%／その指標を選ぶ理由
- 使えるデータの保管場所：（基幹／Excel／紙／その他）
- データの形式と保有期間：（ ）年分・（ ）件
- 社外への送信可否：（可／不可／条件付き）
- 社内の意思決定者と、稼働後の運用担当者
この9項目が埋まっていれば、開発会社は前提を揃えた見積もりを出せます。埋まらない欄がある場合、そこがプロジェクトのリスクだと考えて先に潰しておくと、後工程が楽になります。
※4 IPA「DX白書」リンク
まとめ：AIシステム開発は「評価基準を先に決める」ことから始まる
AIシステム開発とは、AIの推論機能を業務システムと業務フローに組み込む開発です。従来開発との差は、精度を事前に確約できない、データ整備が開発に先行する、評価基準を決めないと検収できない、の3点。この差が契約形態と見積もりの読み方に直結します。
進め方は課題定義、データ棚卸し、PoC、本開発、運用の5ステップ。PoCで止める判断も成果のひとつです。費用はPoCで数十万〜数百万円、本開発で数百万〜数千万円が目安で、API利用料と運用費という従来にない費目が加わります。契約はフェーズごとに準委任と請負を使い分けるのが実務的です。
次のアクションはシンプルです。対象業務を1つに絞り、現状の処理件数と工数を数値化し、使えるデータの所在を確認します。この3つが揃った状態で複数社に相談すれば、比較検討が成立します。要件が固まりきっていない段階でも、対象業務の候補が挙がっていれば、どこから整理すべきかの相談は可能です。
よくある質問
AIシステム開発の期間はどれくらいかかりますか？
小規模な生成AI活用型で2〜3ヶ月、自社データを使う予測モデル構築を伴う場合は半年〜1年が目安です。期間を左右するのはAIそのものより、データ整備の状況と既存システム連携の数。データが整っていない場合は、整備工程で数ヶ月が加わることもあります。
データが少なくてもAI開発はできますか？
生成AI活用型であれば、少量の社内文書からでも成立する場合があります。一方で予測モデル構築型は、季節変動を捉えるために数年分など一定量のデータが必要です。判断は件数だけでなく、正解ラベルの有無と表記の揃い方にも左右されるため、まずデータ棚卸しから始めてください。
PoCだけを依頼することはできますか？
可能です。むしろPoC単体で発注し、結果を見てから本開発を判断する進め方が一般的になっています。その際は、PoCの成果物（評価レポート、使用データ、試作コードの扱い）と、中止した場合の権利関係を契約書で明確にしておいてください。
社内の機密データを外部のAIに渡しても大丈夫ですか？
契約と構成次第です。事業者側の学習に利用させない設定、データの保存期間、リージョンの指定、閉域構成やオンプレミス構成といった選択肢を提案時に確認してください。個人情報を含む場合は、利用目的や委託先の監督といった個人情報保護法上の整理も必要になります※2。
AIシステム開発に補助金は使えますか？
ソフトウェア導入やシステム開発を対象とする制度が該当する場合があります。たとえばIT導入補助金は、対象となるツールや事業者の要件が定められています※5。本記事は2026年時点の情報で、要件や補助率は年度ごとに見直されるため、必ず最新の公募要領で対象範囲と申請時期を確認してください。
AI開発は失敗しやすいと聞きますが、原因は何ですか？
最も多いのは、目的と評価基準が曖昧なままPoCに入るケースです。何%で合格かを決めていないため、結果が出ても判断できずに止まります。対象業務を1つに絞り、合格ラインと未達時の扱いを事前に合意しておくだけで、この失敗はかなり防げます。
※2 個人情報保護委員会「個人情報保護法」リンク
※5 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク