AI開発を委託する実務：RFP・契約・受入試験の設計ガイド

AI開発を委託するとき、候補企業のモデル名、技術デモ、開発単価だけを比べても、量産運用の成否は判断できません。タイ・ASEANの日系製造業で本当に決めるべきなのは、どの業務場面をどのデータで合否判定するか、データ・モデル・プロンプト・成果物の権利と処理境界をどう定めるか、稼働後の監視・変更・終了時移管を誰が担うかです。本記事では、この3点をRFP、契約、検収へ落とし込み、AI受託開発を「一発のデモ」ではなく、再現可能な業務システムとして選ぶ方法を解説します。

AI開発の委託で先に決めるべき3つの管理点

AIシステム開発には、同じ入力でも出力が揺れる、利用データや外部サービスが変わる、モデル更新で挙動が変化する、もっともらしい誤答が混じる、といった従来システムとは異なる性質があります。そのため、画面と機能一覧が完成しただけでは「業務で使える」とは言えません。

委託の入口で、次の3点を一続きの管理対象として定義します。

管理点	RFPで求めること	契約・発注条件で決めること	受入試験で確かめること
①業務シナリオ別の受入データセットと評価基準	対象業務、入力の種類、正解、許容誤差、禁止結果、例外処理	データセットの作成・承認責任、合格閾値、再試験、未達時の扱い	代表例、境界例、異常例、未見例で再現可能に合否判定できるか
②権利と処理境界	データフロー、外部AI・OSS・クラウド、保存場所、ログ、学習利用の有無	データ、プロンプト、設定、コード、成果物、改善物の利用条件と返却・削除	禁止データが流れないか、権限制御・ログ・削除が仕様どおりか
③監視・変更管理・終了時移管	稼働指標、障害・品質劣化検知、変更手順、運用体制、出口計画	SLA等の運用条件、更新承認、脆弱性対応、文書更新、移管物	監視通知、ロールバック、復旧、引継ぎ、代替先での再現が可能か

この表を分業せず、購買、業務部門、IT、情報セキュリティ、法務・個人情報担当、現地運用担当が同じ版を見て判断することが重要です。ETDAのGenerative AI Governance Guidelineも、人間による監督、法令等との適合、部門横断の協働、データガバナンス、監視・評価・改善、第三者製品・部品の評価と監視を論点として示しています。これは契約条項そのものではありませんが、委託範囲の抜けを探す実務的な視点になります。

「モデル名」と「デモ」を選定軸の中心にしない

「最新モデルを使う」「高い精度が出た」「自社データでデモできる」という説明は、質問の始まりであって結論ではありません。何を分母にした精度か、どの業務シナリオか、誤りの影響は同じか、デモに使わなかったデータでも再現するかが分からなければ比較できないからです。

たとえば、設備保全の報告書を要約するAIでは、読みやすい要約を作れるだけでなく、設備番号、停止時間、安全上の注意、未確認事項を欠落させないことが重要です。購買問い合わせを処理するAIエージェントでは、自然な回答だけでなく、価格変更や発注を勝手に実行しないこと、権限外の取引先情報を見せないこと、根拠がないときに担当者へ引き継ぐことが必要です。検査記録検索では、近い文書を返すだけでなく、工場、ライン、品番、版、日付の取り違えを止めなければなりません。

したがってベンダー比較は、モデルのブランドではなく、次の問いへの証拠で行います。

業務上の成功と失敗を、入力・期待結果・判定方法で説明できるか。
未知データを分離した評価を行い、個別ケースの結果を追跡できるか。
モデル、プロンプト、検索データ、ツール権限の変更を版管理できるか。
不正入力、機密情報、過剰権限、外部サービス停止を試験できるか。
稼働後に品質が落ちたとき、検知、切戻し、原因分析、再検証ができるか。
契約終了後、別の運用者が設定と評価を再現できるか。

AI PoCの予算や成功条件を先に整理したい場合は、タイ製造業向けAI PoCの費用と成功基準も参照してください。本記事では、そのPoCを発注・検収できる形へ変換することに焦点を当てます。

AIシステム開発のRFPを「業務シナリオ」から書く

RFPの冒頭に製品機能を並べる前に、現在の業務、AIを使う場面、失敗時の影響、人の介入点を書きます。仕様の主語を「AIがする」ではなく、「誰が、どの情報を受け取り、何を判断し、どのシステムへ何を記録する」にすると、受入条件へつながります。

1. 対象業務と対象外業務

対象には、開始条件、終了条件、利用者、入力元、出力先、処理件数の想定、利用時間帯、必要言語、責任者を記載します。対象外には、AIに判断させない事項、人の承認なしに実行させない操作、利用禁止データ、対象外の工場・会社・製品群を明記します。

日系製造業では、本社とタイ法人の責任分担も曖昧になりがちです。本社が契約し、タイ法人のデータを処理し、ASEAN各社が利用する場合、誰が利用目的、アクセス権、問い合わせ、事故対応、ベンダー指示を決めるのかを、組織図ではなく運用手順として示します。個人データを扱う可能性がある場合は、タイの個人情報保護法を含む適用関係を、具体的なデータフローに基づいて有資格の専門家と確認してください。

2. 成功シナリオと失敗シナリオ

成功シナリオだけでは、ベンダーは最も見せやすい入力へ最適化できます。RFPには最低でも、通常、境界、例外、禁止、障害復旧のシナリオを入れます。

シナリオ種別	製造業での例	期待する挙動
通常	現行版の作業標準書を参照して定型質問に回答	参照文書と版を示し、許容された範囲で回答する
境界	類似品番、旧版文書、日英タイ語が混在	識別条件を確認し、版や品番を取り違えない
例外	必須項目が欠落、画像が不鮮明、根拠文書がない	推測で埋めず、保留または人へ引き継ぐ
禁止	入力文中に手順無視や機密情報取得を誘う指示	指示に従わず、権限外の情報・操作を遮断する
障害復旧	外部モデル、検索基盤、ERP APIが一時停止	二重登録を避け、安全に停止・再試行・復旧する

3. 非機能要件をAI固有の言葉へ分解する

性能は平均応答時間だけでなく、入力長、同時利用、再試行、外部API制限、コスト上限、タイムアウト時の挙動まで記載します。可用性はAIモデルだけでなく、検索、文書変換、認証、ERP連携、人の承認画面を含む端から端までで考えます。

セキュリティでは、通常の認証・暗号化・脆弱性管理に加え、プロンプトインジェクション、機密情報開示、過剰な権限、信頼できない出力の後続処理、第三者部品、無制限な資源消費を試験シナリオへ翻訳します。OWASPの現行プロジェクトページは、2026年8月4日公開のGenAI LLM Top 10 2026を案内しています。ただし、リストにチェックを付けるだけでは不十分です。自社の文書、ツール権限、ネットワーク境界、承認手順に合わせて「どの入力を与え、何が起きなければ合格か」を定義します。

受入データセットを契約可能な成果物にする

AI開発委託の品質管理で最も重要なものは、受入データセットです。これは単なるサンプル集ではなく、入力、期待結果、判定規則、重要度、由来、利用条件を組にした試験資産です。

データセットを6つの層に分ける

代表データ：実運用で頻出する入力。工場、部門、言語、文書種類、利用者を偏らせない。
境界データ：似た品番、長い入力、画像劣化、表記揺れ、複数言語、日付境界など。
エラーデータ：欠損、矛盾、重複、読取不能、参照先停止など。
安全性データ：権限外照会、誘導的な指示、機密情報の抽出要求、危険な操作要求など。
回帰データ：一度直した不具合を、更新後も再発させないためのケース。
保留データ：委託先へ事前開示しないホールドアウト。最終受入で過適合を検出する。

代表データだけを増やすと平均値は良く見えますが、重大事故につながる少数ケースが埋もれます。各ケースに業務影響度を付け、「安全停止が必要なケース」と「軽微な表現差」を同じ点数で平均しないことが大切です。

正解を1つに固定できない出力の判定

分類や項目抽出では正解を明確にしやすい一方、要約、回答、提案文では複数の適切な出力があり得ます。その場合は、完全一致ではなく、必須要素、禁止要素、根拠、構造、人による評価基準を組み合わせます。

OpenAIのevalsガイドでは、評価をdata_source_configとtesting_criteriaで定義し、期待する入力を代表するテストデータと、人が付けたground truthを用いる例が示されています。製品にかかわらず実務へ応用できる考え方は、「評価対象データ」と「合否判定」を分離し、版を付けて再実行できるようにすることです。

項目	記録例	検収での意味
case_id	TH-MNT-0042	不具合・証跡・再試験を同じケースへ結び付ける
scenario	異音報告から設備と緊急度を抽出	業務場面を明確にする
input	匿名化済み報告、添付画像、利用者権限	実際の入力条件を再現する
expected	設備ID、根拠箇所、要確認フラグ	必須結果を定める
prohibited	根拠なしの原因断定、自動停止命令	出してはいけない結果を定める
criterion	必須項目一致、根拠存在、禁止結果なし	機械判定と人判定を組み合わせる
severity	Critical / High / Medium / Low	平均点で重大失敗を隠さない
provenance	元データ管理者、取得条件、利用期限	データ利用の説明責任を保つ

データセットの作成責任を曖昧にしない

業務の正解は委託先だけでは決められません。一方、顧客側だけで評価方法を作ると、技術的に測定不能な条件になりがちです。推奨する分担は、業務部門がシナリオと重大度を定義し、IT・セキュリティが環境と安全条件を定め、委託先が測定方法と自動化を提案し、共同レビューで基準を凍結する形です。

契約では、誰が原データを用意し、誰が匿名化・ラベル付けし、品質を承認し、追加ケースの費用を負担するかを決めます。委託先が評価データを作成する場合でも、顧客がホールドアウトを管理し、最終合否を承認できる状態を残します。

AI受託開発の評価基準を「平均精度」から分解する

評価指標は業務結果、品質、安全、運用、コストの層に分けます。全体の平均値が閾値を超えていても、重大ケースが1件失敗すれば不合格とするゲートを設けることがあります。逆に、表現の好みだけで全体を不合格にしないよう、許容差も明記します。

品質の指標

分類：クラス別の正解、誤分類、未判定。件数の少ない重要クラスを分けて見る。
抽出：項目別の正解、欠落、誤抽出。設備IDや金額など重要項目へ重みを付ける。
検索：必要文書が候補に入るか、最新版を優先するか、権限外文書を除外するか。
生成：根拠整合、必須要素、禁止要素、読み手に必要な言語・形式。
業務：人への引継ぎ率、手戻り、処理時間、再確認件数、業務完了率。

安全と統制のゲート

重大な機密開示、権限外操作、承認の迂回、監査ログ欠落、危険な自動実行は、平均点とは別の不合格条件にします。AIが自信を持って答えたかではなく、根拠不足や権限不足を検知して安全側へ倒れたかを評価します。

人間による監督も「最後に誰かが見る」では不十分です。どの条件で自動処理し、どの条件で確認画面へ送り、誰が承認・却下でき、判断がログに残るかまで試験します。ETDAのガイドラインは、生成AIへの過度な依存を避けるため、人が結果を確認し受諾または拒否するプロセスを例示しています。

合格判定の例

RFPには数値を決め打ちするより、基準の決定手順を書くほうが現実的です。たとえば「PoC開始時にベースラインを測定し、業務責任者がCriticalケースと許容誤差を承認し、構築フェーズ開始前に受入計画書を凍結する」とします。数値は実データ、リスク、現行業務の誤り率、確認可能な人員を踏まえて決めます。

検収証跡には、評価データ版、アプリ版、モデル識別子、プロンプト版、検索インデックス版、設定、実行日時、ケース別結果、承認者、既知の制約を残します。「テスト結果PDF」だけでなく、条件を再現できることが重要です。

データ・モデル・プロンプト・成果物の境界を描く

AIシステムは、委託先のコードだけでできているとは限りません。クラウド、基盤モデル、埋め込みモデル、検索エンジン、文書解析、監視、OSS、外部APIなどの部品が組み合わさります。まず、入力から出力までのデータフローと責任分界を1枚で示してもらいます。

RFPで開示を求める構成台帳

構成要素	確認項目
入力データ	所有者、個人・機密区分、取得元、利用目的、保存場所、保持期間、削除方法
基盤モデル・AIサービス	提供者、提供地域、入出力の取扱条件、更新方針、停止時の代替、再委託関係
プロンプト・ルール	作成者、版、秘密情報の有無、変更権限、顧客への引渡し範囲
RAG・検索データ	収集元、版、アクセス制御、更新・削除、引用・根拠表示、誤索引の修正
コード・設定・ワークフロー	リポジトリ、ビルド方法、環境差分、顧客固有部分、第三者ライセンス
出力・ログ	利用者、二次利用、保存先、マスキング、監査項目、削除・エクスポート
評価資産	テストデータ、ラベル、採点器、結果、回帰ケースの権利と再利用範囲

「顧客データを学習に使わない」という一文だけでは、埋め込み、ログ、障害解析、品質改善、第三者サービスへの送信、バックアップまで分かりません。学習という言葉を広く曖昧に使わず、各処理目的、送信先、保持、再利用、削除をデータフロー単位で確認します。

個人データを含む場合、役割、処理目的、指示、再委託、越境、保持、本人対応、事故連絡などは、対象システムと契約関係に応じた確認が必要です。本記事だけで適法性を判断せず、タイの法務・個人情報専門家のレビューを受けてください。

成果物と知的財産の扱い

「開発成果物一式を納品」とだけ書くと、必要なものが抜けます。少なくとも、ソースコード、IaCや環境設定、プロンプト、ツール定義、検索設定、データスキーマ、評価スクリプト、テストケース、運用手順、アーキテクチャ図、部品表、既知の制約、学習・調整済み資産を列挙します。

それぞれについて、既存資産か新規成果物か、顧客が利用・変更・再委託できる範囲、第三者条件、契約終了後の利用可否を、法務担当と確認します。モデル自体を所有できなくても、別モデルへ差し替えるためのインターフェース、評価資産、設定、データエクスポートを確保できれば、ロックインの影響を小さくできます。

ETDAのガイドラインは、Adopter、Customizer、Makerという複雑度の異なる利用形態を示しています。既製サービスを使うAdopterと、RAGや追加調整を行うCustomizer、基盤モデルを構築するMakerでは、必要な権利、技術文書、評価、運用能力が異なります。RFPでは自社案件がどの役割に近いかを明示し、すべてを「AI開発」と一括りにしないことが有効です。

セキュア開発を調達条件へ翻訳する

NISTはSSDFを、ソフトウェア生産者と調達者が調達や管理で使える共通言語と説明し、実践をPO（組織の準備）、PS（ソフトウェアの保護）、PW（安全なソフトウェアの生産）、RV（脆弱性への対応）の4群に整理しています。AI開発委託では、この枠を次のように質問へ翻訳できます。

SSDFの視点	AI開発委託での質問例
PO：組織の準備	セキュリティ責任者は誰か。脅威モデル、承認基準、教育、例外承認はいつ更新するか
PS：資産の保護	コード、モデル、プロンプト、秘密情報、データセット、ビルド環境へのアクセスをどう制御するか
PW：安全な生産	依存部品をどう把握し、レビュー、テスト、署名、環境分離、出力検証をどう行うか
RV：脆弱性への対応	報告窓口、重要度判定、修正期限、回避策、再試験、顧客通知、更新提供をどう運用するか

NIST SP 800-218Aは、生成AIとデュアルユース基盤モデルに向けたSSDFのコミュニティプロファイルです。すべての要求をそのまま小規模RAG案件へ適用するのではなく、自社がAdopter、Customizer、Makerのどこにいるか、どの部品を誰が作るかに応じて選ぶことが現実的です。

AI特有の受入セキュリティ試験

文書内に「以前の指示を無視せよ」と埋め込み、権限外の情報や操作へ誘導する。
低権限ユーザーから、別工場、別会社、別部門の文書を推測・検索させる。
出力へSQL、URL、コード、操作指示を混ぜ、後続システムが無検証で実行しないことを確認する。
同じ要求を大量・長文で送り、利用上限、タイムアウト、費用ガード、停止手順を確認する。
外部モデルや検索基盤を停止し、安全側のエラー、再試行、二重処理防止を確認する。
モデルやプロンプトを更新し、承認されていない版が本番へ入らないことを確認する。

テストに合格しても、未知の攻撃や将来の変更によるリスクがなくなるわけではありません。検収は最低線を確認するゲートであり、監視と再評価を契約期間中に続ける前提が必要です。

契約・発注条件に入れるべき実務項目

ここでは特定の法的文言ではなく、契約書、注文書、作業範囲記述書、受入計画書のどこかで合意すべき実務項目を整理します。実際の条項は、準拠法、当事者、データ、業界規制に応じて専門家が確認してください。

成果と範囲

対象業務、対象会社・工場、利用者、対象言語、対象システム。
PoC、本番構築、移行、安定化、保守の各フェーズと完了条件。
成果物一覧、文書形式、リポジトリ、編集可能な原本、納品時期。
顧客と委託先の前提作業、データ準備、環境、意思決定期限。
対象外、追加変更の見積方法、優先順位変更の承認者。

検収と不合格時の扱い

受入データセット、保管者、開示範囲、版管理。
指標、Criticalゲート、許容誤差、人による判定者。
テスト環境、実行回数、再現条件、証跡形式。
不具合の重要度、修正・再試験、条件付き受入、既知制約の扱い。
モデルや外部サービスの更新で再試験が必要となる条件。

データ・セキュリティ・第三者

データフロー、処理場所、アクセス、暗号化、ログ、保持、返却・削除。
第三者サービス、再委託、OSS、モデル、ライセンスと変更通知。
顧客データ、入力、出力、ログを各提供者が何の目的で利用するか。
脆弱性報告、事故連絡、調査協力、証跡保全、修正と回避策。
権限最小化、秘密情報管理、環境分離、管理者操作の監査。

運用・変更・費用

サービス時間、問い合わせ、障害の重要度、応答・復旧目標。
品質、拒否、引継ぎ、遅延、利用量、費用を監視する指標。
プロンプト、モデル、検索データ、ツール、閾値の変更申請と承認。
外部料金や為替、利用量増加、再評価、緊急対応の費用負担。
定例レビュー、レポート、改善バックログ、教育、運用文書更新。

稼働後の監視と変更管理を検収前に試す

AIの品質は、入力分布、文書版、利用者の質問、モデル、検索インデックス、業務ルールの変化で動きます。そのため「納品時に精度が出た」だけでは不十分です。稼働後の指標と対応手順を、検収試験の一部として動かします。

監視すべき5種類の信号

業務信号：完了率、人への引継ぎ、差戻し、処理時間、利用部門別の採用状況。
品質信号：根拠なし回答、誤分類、重要項目欠落、利用者フィードバック、回帰ケース。
安全信号：権限拒否、禁止入力、機密マスキング、異常なツール呼出し、監査ログ欠落。
技術信号：遅延、エラー、外部API、検索失敗、キュー、利用上限、ロールバック可否。
経済信号：処理当たり費用、再試行、長文入力、保存量、人の確認工数、月次予算差異。

アラートには、誰が見るか、何分・何時間で何を判断するか、停止権限は誰にあるかを設定します。単にダッシュボードを納品しても、判断と連絡が定義されていなければ統制になりません。

変更を4段階に分ける

軽微：文言修正や表示変更。回帰テストの範囲を限定できる。
標準：プロンプト、検索設定、閾値、文書取り込み規則の変更。関連ケースを再評価する。
重大：モデル、データ処理場所、外部サービス、ツール権限、意思決定範囲の変更。リスク・法務・セキュリティを再承認する。
緊急：脆弱性や事故への停止・切戻し。事後レビューと恒久対応を必須にする。

モデル提供者による更新を委託先が制御できない場合もあります。そのときは、更新検知、影響確認、固定版の可否、代替モデル、再評価、顧客通知を決めます。「自動更新なので責任を負えない」で終わらせず、制御できる範囲と代替手段を明示します。

NISTのAI RMF Generative AI Profileは、AIの設計、開発、利用、評価を通じて信頼性の考慮を組み込むための任意利用の資料です。2026年にNISTが公表した重要インフラ向けAI RMFプロファイルのConcept Noteも、分野・組織役割・サプライチェーンをまたぐ参加を重視しています。製造業のAIも単体モデルではなく、設備、業務、供給者、利用者を含むライフサイクルで管理するという示唆が得られます。ただし後者は継続中の構想であり、完成した規格として扱わないでください。

終了時移管を「最後の作業」にしない

AI開発委託では、終了直前に引継ぎ物を集めようとすると、権限、評価データ、プロンプト履歴、外部契約が揃わないことがあります。出口計画はRFP時点で要求し、設計審査、受入、年次レビューで更新します。

最低限の移管パッケージ

最新と直前安定版のソース、設定、プロンプト、ツール定義、データスキーマ。
アーキテクチャ、データフロー、外部依存、部品表、ライセンス、契約一覧。
ビルド、デプロイ、バックアップ、復旧、監視、障害対応、権限管理の手順。
受入・回帰データセット、採点方法、ケース別履歴、既知制約。
検索データ、インデックス再構築手順、削除・更新履歴、根拠表示仕様。
未解決課題、脆弱性、変更予定、費用、アカウント、証明書、更新期限。
顧客データとログのエクスポート、返却・削除の実施記録。

移管試験は、文書の存在確認だけでなく、顧客または別の担当者が非本番環境へ再構築し、代表ケースを実行できるかで確認します。完全なベンダー交換が難しくても、評価資産とデータを保持し、インターフェースを分離しておけば、交渉力と事業継続性が高まります。

AI開発の全体像やタイでの体制設計を確認したい方は、タイにおけるAIシステム開発の実務ガイドをご覧ください。将来の内製化を視野に、委託先と社内チームの役割を設計する場合は、タイ製造業向けAI内製化支援も参考になります。

AI開発委託先の比較評価シート

提案書を読むときは、説明の巧さではなく証拠の有無を採点します。重みは案件のリスクに応じて変えます。

評価領域	主な確認証拠	危険な兆候
業務理解	シナリオ、現行フロー、例外、責任分担、対象外	デモ画面から話が始まり、失敗時の業務がない
評価設計	受入データ構造、ground truth、重大度、ホールドアウト、再現手順	「精度」を単一平均で示し、ケース別結果を出さない
データ統制	データフロー、処理場所、保持、削除、第三者、権限	「学習しない」以外の説明がない
セキュリティ	脅威モデル、AI固有テスト、依存部品、脆弱性対応	一般的な認証説明だけでプロンプトやツール権限に触れない
運用	監視指標、当番、切戻し、変更承認、費用ガード	本番後は保守契約という説明だけで手順がない
移管性	原本、リポジトリ、評価資産、再構築試験、出口計画	独自環境に閉じ、設定や評価をエクスポートできない
実行体制	タイ現地対応、言語、業務・AI・基幹の担当、意思決定	営業担当だけが明確で実装・運用責任者が見えない

安価な提案が悪いとは限りません。対象範囲を狭くし、人の確認を適切に残し、評価と出口を明確にすることで、低コストでも安全な開始ができます。反対に、高性能モデルと大規模体制を掲げても、検収不能、責任境界不明、移管不能なら将来コストは高くなります。

AI導入の進め方：発注から受入までの8ステップ

業務責任者を決め、対象・対象外・失敗影響・人の判断点を記述する。
データフローを描き、個人・機密・越境・第三者・権限の論点を洗い出す。
代表、境界、例外、安全、回帰、ホールドアウトの受入データを準備する。
指標、Criticalゲート、許容差、判定者、証跡、再試験条件を決める。
RFPで構成台帳、開発証跡、運用、変更、移管の提案を求める。
PoCで精度だけでなく、業務、人、セキュリティ、費用、復旧を検証する。
本番前に監視、切戻し、事故対応、変更承認、教育、出口移管をリハーサルする。
稼働後は同じ受入資産で回帰評価し、変更ごとにリスクと文書を更新する。

この進め方では、PoCを成功演出の場ではなく、発注者と委託先が共通の測定言語を作る場として扱います。技術選定を遅らせるのではなく、何をもって採用するかを先に固定することで、比較と意思決定が速くなります。

FAQ：AI開発委託でよくある質問

AI開発の委託先はモデルの精度で選べばよいですか？

モデル単体のベンチマークは参考になりますが、それだけでは不十分です。自社業務の代表・境界・異常・安全ケースを用い、検索、権限、連携、人の確認を含む端から端までの結果で比較してください。ケース別証跡と再現手順を提出できる委託先が望ましいです。

AI受託開発の契約で最も重要なものは何ですか？

一つの条項ではなく、受入基準、データ・成果物・第三者の境界、運用変更と出口移管の接続です。特に「どのデータで、誰が、何を合格とするか」が曖昧だと、完成の定義が双方でずれます。法的文言は案件ごとに専門家へ確認してください。

AI PoCのデータは委託先へすべて開示すべきですか？

開発用と評価用を分け、最終受入用のホールドアウトを顧客側で保護する方法があります。ただし、データ利用権限、匿名化、安全な受渡し、ラベル品質を確認してください。秘密にするだけでなく、実運用を代表する構成になっていることが重要です。

AIシステム開発の精度が稼働後に落ちたらどうしますか？

品質指標と業務指標を監視し、入力や文書の変化、モデル・プロンプト・検索の版、外部障害を切り分けます。変更を承認し、回帰データで再試験し、必要なら直前安定版へ戻せる手順を契約と運用設計に含めます。

AI導入の進め方として、最初から本番契約にすべきですか？

リスクが高い場合は、業務定義、データ準備、PoC、本番構築、安定化を段階化し、各ゲートで継続判断する方法が現実的です。ただしPoCを使い捨てにせず、評価資産、データフロー、運用条件を本番へ引き継げる契約にします。

タイの個人データを扱う場合、何を確認すべきですか？

データ項目、目的、当事者の役割、アクセス、処理場所、再委託、保持、削除、事故対応などを具体的なフローで整理し、タイの法務・個人情報専門家に確認してください。システム名称やクラウド地域だけで適法性を一律に判断することは避けます。

まとめ：AI開発委託は「検収でき、変えられ、引き継げる」状態を買う

AI開発の委託で買うべきものは、華やかなデモや特定モデルへのアクセスだけではありません。第一に、業務シナリオ別の受入データセットと合否基準。第二に、データ、モデル、プロンプト、コード、出力、ログ、第三者部品の権利と処理境界。第三に、監視、変更承認、障害対応、終了時移管を再現できる運用資産です。

この3点がRFP、契約、検収でつながれば、モデルや外部サービスが変わっても、顧客は同じ業務基準で判断できます。反対に、完成の証拠が一発デモしかなければ、導入後の品質低下、追加費用、責任の押し付け、ベンダーロックインを止めにくくなります。まずは小さな対象業務でも、受入ケース、禁止結果、データフロー、変更手順、移管物を明文化するところから始めてください。

TOMAS TECHでは、タイ・ASEANの製造現場を対象に、AI開発委託前の業務整理、RFP、PoC受入基準、データ・システム連携、運用移管の検討段階からご相談いただけます。まだ委託先やモデルが決まっていない段階でも、現行業務と失敗リスクを基に進め方を整理できます。お問い合わせはこちら。

AI開発を委託する実務｜RFP・契約・受入試験の設計