AI開発会社の選び方2026｜AI受託開発の契約・見積で外す急所

「AI開発会社 おすすめ」で検索すると、25社比較・50社比較といった一覧記事が並びます。ところが一覧を見比べて選んだのに、PoCで止まった、検収で揉めた、モデルの権利が自社に残らなかった——という話は珍しくありません。本記事の立場は明快です。AI開発の発注の成否は、会社の比較ではなく、契約類型・段階の切り方・検収条件・権利帰属の設計でほぼ決まります。タイ・ASEANで操業する日系製造業の方に向けて、発注前に決める順序を整理します。

なぜAI開発は「完成」を約束しにくいのか

一覧比較型の記事が暗黙に置いている前提があります。「良い会社を選べば、頼んだものは完成する」という前提です。従来型のシステム開発であれば、この前提はおおむね成り立ちます。仕様書に書かれた画面と機能を作り切れば完成です。ところがAIモデルを含む開発では、この前提が構造的に崩れます。

経済産業省が2025年（令和7年）2月18日に公表した「AIの利用・開発に関する契約チェックリスト」は、性能・精度についてこう整理しています。AIモデルは学習データに基づく帰納的な手法で開発されるため、学習データそのものに精度の限界が内包されてしまっている可能性がある、と。その結果として、完成義務や性能保証の設定が困難である、という位置づけになります。

これは「ベンダーの腕が悪いから完成しない」という話ではありません。手元にあるデータが持っている情報量以上のことは、どんなに優れたエンジニアが取り組んでも出てこない、という話です。工場の現場に置き換えると分かりやすいでしょう。過去3年分の検査記録に「不良」としか書かれておらず、不良の種別・発生工程・作業者・環境条件が記録されていなければ、そのデータから「どの条件で不良が出るか」を当てるモデルは作れません。作れないことは、着手して数週間データを触ってみて初めて分かります。

だからこそ、発注側が最初にやるべきことは「良い会社を探すこと」ではなく、「完成しないかもしれない前提で、どこまで払い、どこで止められるようにしておくか」を決めることになります。

まず自社の案件がどの類型かを判定する

同じチェックリストは、AI利活用の契約を3つのユースケース類型に分けています。自社が検討している案件がどれに当たるかで、詰めるべき論点も、そもそも契約書が必要かどうかも変わります。

チェックリストは「AI利活用に関する契約に際して考慮すべき論点の所在を示すもの」という位置づけで、インプット関連14項目、アウトプット関連14項目という構成を取っています。インプット側は、ユーザがベンダに提供するデータの定義・利用目的・利用条件・管理体制・保持期間や消去といった項目群。アウトプット側は、完成義務・提供条件・利用目的・利用条件・セキュリティ管理といった項目群です。

ここで発注側が最初にやるべき作業は、この28項目のチェックリストを自社の案件に当てて、「自社が答えを持っていない項目」を洗い出すことです。AI開発会社に相談する前にこれをやっておくと、商談の質がまるで変わります。「うちのデータをそちらが他案件に使うことは想定していますか」「消去はいつ、どういう手続きでやりますか」といった質問が、思いつきではなく網羅的なリストから出てくるようになるためです。

なお、この3類型の判定は「どこまで自社でやり、どこから外に出すか」という内製と外注の線引きとも直結します。層ごとに持ち場を分ける考え方はAI内製化支援の記事で詳しく整理しているので、あわせてご覧ください。

探索的段階型開発方式——契約を4段階に切る

「完成を約束しにくい」なら、どう発注すればよいのか。この問いに対する日本の公的な回答は、2018年6月に公表され2019年12月に一部改訂された経済産業省「AI・データの利用に関する契約ガイドライン」にあります。同ガイドラインのAI編は、探索的段階型と呼ばれる開発方式を提唱しています。

考え方はシンプルです。最初に全体を一括で契約せず、開発プロセスを段階に分けて、段階ごとに契約を結び直す。各段階の終わりに「次に進むか、ここで止めるか」を判断する。ガイドラインが示す段階は、アセスメント段階／PoC段階／開発段階／追加学習段階の4つです。以下の表のうち段階名はガイドラインの記載ですが、「何をやるか」「発注側が段階末に得るもの」の欄は、実務上の一般的な理解に基づく筆者の整理です。

ガイドラインは各段階における契約方式・考慮要素・契約条項例を示しています。また、AIモデル単体の開発がデータに依存する帰納的手法でなされることを踏まえ、その開発には準委任契約が親和的である旨を整理しています。

段階を切る本当の意味は「打ち切れる場所を作る」こと

段階分けというと「進め方の話」に聞こえますが、発注側にとっての実利はそこではありません。契約上、正当に打ち切れるポイントを作ることが本質です。

一括契約でプロジェクトを走らせると、途中で「どうやら難しそうだ」と分かっても、契約が残っているために止められません。止めれば契約不履行の議論になり、続ければ見込みのない投資が続きます。これが「PoCで止まったまま、なぜか費用だけかかり続ける」という状態の正体です。段階契約であれば、アセスメント段階の終わりに「本件は現時点のデータでは難しい」という結論が出た場合、その段階の対価を払って終了できます。この「終了できる」ことに価値があります。

ここで一点だけ強調しておきたいことがあります。アセスメント段階で「難しい」という結論が出たとき、それは失敗ではありません。調査段階の費用だけで、本格投資の判断を回避できたという意味では、むしろ成功です。発注側の社内で「PoCは成功しなければならない」という空気を作ってしまうと、現場は無理筋の案件を延命させます。段階契約を導入するときは、契約書と同時に、社内の評価の仕方も設計してください。

段階ごとに「入口条件」と「出口条件」を書く

段階を切っただけでは足りません。各段階について、入口条件（この段階を始めてよい条件）と出口条件（この段階を終えたと言える条件）を契約書または個別合意書に書きます。

たとえばPoC段階の入口条件は「アセスメント段階のレポートで、対象データに識別に足る情報が含まれると判断されたこと」、出口条件は「検証データセットに対する業務指標が別紙の水準を満たすか、満たさない場合はその原因分析レポートが提出されたこと」といった書き方になります。満たさなかった場合の成果物も出口条件に含めておくのがコツです。これがないと、うまくいかなかった段階で何も残らないという事態になります。

請負か準委任か——「成果完成型の準委任」という折衷案

段階を切ったら、次は各段階をどの契約類型で結ぶかです。特許庁のIP BASEは、AI開発の契約類型を次のように整理しています。

この違いは大きく、ここを曖昧にしたまま進むとトラブルの温床になります。発注側は「頼んだのだから完成するはずだ」と思い、ベンダー側は「精度が出るかはデータ次第だと説明したはずだ」と思う。両者の認識のズレが、検収の場で初めて表面化します。

準委任型の2つのバリエーション

準委任型はさらに2つに分かれます。

• 履行割合型：委任された事務を履行した場合に、委任者に報酬の支払義務が発生する
• 成果完成型：成果の引き渡しと引き換えに報酬の支払義務が生じる

履行割合型は、平たく言えば「作業した分だけ払う」形です。アセスメント段階やPoC段階のように、そもそも何が出てくるか分からない探索的な作業には馴染みます。一方、発注側からすると「何も出てこなくても払う」ことになるため、金額が大きくなるほど社内説明が難しくなります。

成果完成型は、あらかじめ定義した成果の引き渡しがあって初めて報酬の支払義務が生じる形です。発注側からすると「何も渡されなければ払わない」という整理ができるため社内説明はしやすくなりますが、完成義務まで負うわけではない点は変わりません。したがって、何をもって「成果」とするかを書面で定義できるかどうかが、この型を選べるかの分かれ目になります。定義できるのであれば発注側に有利ですが、定義が曖昧なまま成果完成型を選ぶと、引き渡しの成否をめぐって履行割合型より深刻な争いになります。

ベンダは請負を避ける傾向がある、という前提を持っておく

AIの精度が学習データに依存する性質から、ベンダは請負型を避ける傾向があります。これは不誠実だからではなく、第1章で見たとおり完成義務を負えない構造的な理由があるためです。この前提を知らずに交渉に臨むと、「請負にしてくれないなら信用できない」という筋の悪い議論になります。

折衷案として提案されているのが「成果完成型の準委任型契約」です。完成義務までは負わないが、合意した成果の引き渡しと引き換えに報酬が発生する、という中間的な形になります。ただし、この形を採る場合には「完成」の定義について専門家との協議が必須とされています。ここが本記事の中核とつながります。何をもって成果の引き渡しとするか——つまり検収条件——を書き切れなければ、成果完成型は機能しません。

段階と契約類型の組み合わせ方（考え方の整理）

以下は、ガイドラインの考え方を踏まえた整理であり、個別案件の適法性や妥当性を保証するものではありません。

③開発段階については、AIモデル部分と周辺システム部分を分けて考えると設計しやすくなります。画面、権限管理、既存システムとの連携、帳票出力といった部分は仕様を確定できるため、従来型の請負に切り出せる余地があります。逆にモデル部分は準委任に残す。この切り分け自体を見積依頼の段階で相手に伝えておくと、提案の質が上がります。

なお、本章は契約類型の一般的な整理であり、法律相談ではありません。実際に契約書を作成・締結される際は、必ず弁護士等の専門家にご確認ください。特にタイ現地法人を契約主体とする場合、準拠法・裁判管轄・タイ法上の取り扱いが日本法の整理とそのまま一致するとは限りません。

見積を5層に分解して読む

ここまでの設計ができると、見積書の読み方が変わります。よくある質問に「AI開発の費用相場はいくらか」がありますが、本記事では金額のレンジを示しません。公開されている相場情報の多くはAI開発会社の自社メディア由来で、算出根拠が開示されていないためです。根拠不明の数字を判断材料にすると、かえって危険な意思決定を招きます。

代わりに提案したいのは、見積を5つの層に分解し、各層が見積書のどの行に対応するかを発注側が自分で突き合わせるという手順です。相場を知らなくても、層の欠落は自分で見つけられます。

5つの層

「安い見積」は多くの場合④と⑤が抜けている

複数社から見積を取ると、金額に大きな開きが出ます。このとき「安いほうが良心的だ」と判断するのは早計です。構造的に見て、金額差が生まれる主因は技術力や単価の差というより、④既存システム連携と権限設計、⑤運用・再学習が見積範囲に含まれているかどうかという範囲の差です。

なぜこの2層が落ちやすいのか。④は発注側の既存システムの中身を見ないと工数を出せないため、提案段階では「別途お見積り」になりがちです。⑤は稼働後の話なので、初期投資の議論からは自然に外れます。しかし工場でAIを使う場合、④が無ければモデルは業務に届きませんし、⑤が無ければ半年後に精度が落ちた時点で誰も直せません。

思考実験：層の欠落が見積をどれだけ安く見せるか

以下は仮定値による思考実験であり、実データでも相場でもありません。 読者ご自身の案件の数値に置き換えて検算していただくための例です。

前提値（すべて仮定）：

計算します。

• ①〜④をすべて含む初期構築の工数：10 + 25 + 30 + 20 = 85人日
• ④が見積から抜けている場合の見積上の工数：10 + 25 + 30 = 65人日
• 見た目の割安率：(85 − 65) ÷ 85 = 20 ÷ 85 ≈ 0.235 → 約23.5%安く見える
• 3年間の総工数（①〜④ ＋ ⑤を3年分）：85 + 12 × 3 = 85 + 36 = 121人日
• ④⑤を欠いた見積65人日が3年総工数に占める割合：65 ÷ 121 ≈ 0.537 → 約53.7%

つまりこの仮定のもとでは、④と⑤を欠いた見積書は、3年間で実際に必要になる工数のおよそ半分しか映していないことになります。A社65人日、B社85人日という2枚の見積が並んだとき、B社が高いのではなくA社が④を含んでいないだけ、という可能性を先に潰す必要があるわけです。

繰り返しますが、上記の人日は説明のために置いた仮定値です。実際の値は対象業務、データの状態、連携先システムの本数によって大きく変わります。重要なのは数値そのものではなく、5層のどこが自社の見積書に対応行を持っていないかを、自分の手で突き合わせるという作業です。

突き合わせの実務手順

1. 見積書の全行を、上の5層のいずれかにタグ付けする（どの層にも入らない行があれば内容を確認する）
2. どの行も割り当てられなかった層を洗い出す
3. 空欄になった層について、「範囲外なのか、無償なのか、そもそも想定されていないのか」を書面で質問する
4. 「別途お見積り」と回答された層について、概算の前提条件（連携先システム数、想定インターフェース本数、想定運用時間帯など）を先に握る
5. 3年分の総額に引き直して社内稟議にかける

特に④の見積精度を上げたい場合は、既存システム側の構成を先に整理しておくと効果的です。タイでシステム開発会社を選ぶ際の一般的な確認手順はタイのシステム開発会社の選び方にまとめています。また⑤の効果が説明できないと3年分の稟議は通らないため、効果の測り方はAI導入の効果測定・ROIの記事を先に読んでおくことをおすすめします。

検収条件の設計——「精度99%」で受けてはいけない

契約類型を決め、見積の層を揃えたら、次が検収条件です。本記事でもっとも実務的な影響が大きいのがこの章だと考えています。

提案書に「精度99%」と書かれていたとき、発注側が最初にすべき質問は「本当ですか」ではなく、「その99%の分母は何ですか」です。

分母が変われば、必要な確認工数が変わる

たとえば帳票をAIで読み取る案件を考えます。「精度99%」には少なくとも3通りの読み方があります。

同じ「99%」でも、分母が違えば人手で確認しなければならない件数が桁で変わります。しかも通常、提案書には分母が書かれていません。

思考実験：分母の違いで人手確認の工数はどう変わるか

以下は仮定値による思考実験であり、実データではありません。 誤りの発生が項目間で独立であるという単純化も置いています（実際の帳票では誤りが特定の項目や特定の帳票種別に偏るため、この単純化は現実と一致しません）。

前提値（すべて仮定）：

ケースA（項目単位99%）

• 月間の総項目数：1,000枚 × 20項目 = 20,000項目
• 誤り項目数の期待値：20,000 × 1% = 200項目
• 1帳票の20項目すべてが正しい確率：0.99の20乗 ≈ 0.8179（約81.8%）
• 少なくとも1項目に誤りがある帳票の割合：1 − 0.8179 = 0.1821（約18.2%）
• 人手確認が必要な帳票数：1,000枚 × 18.2% ≈ 182枚／月
• 確認工数：182枚 × 3分 = 546分 ≈ 9.1時間／月

ケースB（項目単位99.9%）

• 誤り項目数の期待値：20,000 × 0.1% = 20項目
• 1帳票の20項目すべてが正しい確率：0.999の20乗 ≈ 0.9802（約98.0%）
• 少なくとも1項目に誤りがある帳票の割合：1 − 0.9802 = 0.0198（約2.0%）
• 人手確認が必要な帳票数：1,000枚 × 2.0% ≈ 20枚／月
• 確認工数：20枚 × 3分 = 60分 = 1.0時間／月

項目単位で見れば「99%」と「99.9%」は0.9ポイントの差にすぎません。しかしこの仮定のもとでは、人手確認が必要な帳票数は182枚と20枚、確認工数は9.1時間と1.0時間で、約9倍の開きが出ます。1帳票あたりの項目数を20項目から40項目に増やすと、同じ計算で確認が必要な帳票は約331枚と約39枚になり、枚数の差そのものは162枚から292枚へ広がります（倍率のほうは約9.1倍から約8.4倍にわずかに縮みます）。項目数が多い帳票ほど、分母の取り違えが現場の負担に直結すると考えてください。

この計算の含意は明快です。契約書に「精度99%」とだけ書いてはいけない、ということです。分母が書かれていない精度指標は、検収の場で必ず解釈が割れます。

検収指標は「読めたか」ではなく業務指標で書く

推奨したい書き方は、AIの性能指標ではなく業務指標で検収条件を定義することです。

ポイントは3つです。第一に、検収用データセットを別紙で固定すること。母集団が動けば数字も動きます。第二に、項目ごとに重み付けをすること。品番や金額の誤りと備考欄の誤りでは業務影響がまったく違います。第三に、残った作業量で書くこと。「読めた率」ではなく「人が触らなければならない件数」が、発注側にとっての本当の指標です。

精度の分母をどう詰めるかについては、AI-OCRの比較記事で製品ごとの考え方を含めて掘り下げています。検収条件を書く前に一読しておくと、質問の解像度が上がります。

検収に落ちたときの取り扱いも先に書く

もう一つ忘れられがちなのが、検収基準を満たさなかった場合の取り扱いです。以下を契約書または個別合意書に書いておきます。

• 再チャレンジの回数と期間（無償での改善対応を何回まで、何週間まで行うか）
• 再チャレンジしても満たさない場合の措置（減額、当該段階での終了、次段階への不進行）
• その時点で発注側に引き渡されるもの（中間成果物、データ、ドキュメント、学習済みモデルの扱い）
• 発注側が提供したデータの消去手続きと証跡

3番目が特に重要です。検収に至らなかった場合でも、整備済みのデータやアノテーション結果が手元に残れば、次の取り組みの出発点になります。逆にここを書き忘れると、費用を払ったのに何も残らないという最悪の結末になります。

権利帰属——学習済みモデルは誰のものになるのか

検収条件と並んで揉めやすいのが権利帰属です。経済産業省の契約チェックリストは、フォアグラウンドIP（新規開発成果）とバックグラウンドIP（既存資産）を区別し、事前に明確化する必要があるとしています。

フォアグラウンドIPとバックグラウンドIP

• バックグラウンドIP：契約前から各当事者が持っていた資産。ベンダー側であれば既存のライブラリ、汎用モデル、社内フレームワーク。発注側であれば自社の業務データ、既存システム、ノウハウ。
• フォアグラウンドIP：本件契約のもとで新たに生み出された成果。

実務でこじれるのは、両者が混ざったときです。ベンダーの汎用モデルに発注側の現場データを追加学習させた学習済みモデルは、どちらの資産でしょうか。この問いに契約書が答えを持っていないと、稼働後にベンダーを乗り換えたい、あるいはグループの他工場に横展開したい、という段階で必ず止まります。

分けて考えるべき4つの対象

権利帰属を議論するときは、「AIモデル」とひとくくりにせず、次の4つに分けます。

チェックリストは、開発型契約においてベンダによるインプット利用の許可範囲と具体的条件を明確に定める必要があるとしています。これは裏返せば、何も書かなければ範囲が不明確なまま進むということです。

必ず契約書で確認すべき一文

日系製造業の発注者に、必ず確認していただきたい論点があります。

自社の現場データで学習したモデル（およびその派生モデル）を、ベンダーが他社案件に流用することを認めるか。認める場合、その条件は何か。

多くのAI開発会社は、汎用的な知見の蓄積を事業モデルの一部にしています。それ自体は悪いことではありません。問題は、発注側が「自社専用のモデルができた」と思っている一方で、契約上はベンダーが同業他社に同じモデルを提供できる、という状態が生じうることです。競合他社が同じ工業団地にいるASEANでは、この差は経営的に無視できません。

書き方としては、次のような選択肢があります。

1. 完全に禁止する：本件データおよび本件データに由来する学習済みモデル・派生モデルの第三者提供を禁止する
2. 同業種を除いて許容する：特定の業種・特定の競合企業リストへの提供のみ禁止する
3. 期間を切って独占する：稼働後◯年間は独占、その後は非独占に移行する
4. 抽象化した知見のみ許容する：個別データやパラメータではなく、一般化された手法・ノウハウの再利用は認める

1は最も安全ですが、ベンダー側の見積が上がる可能性があります。3や4は現実的な落としどころになりやすい形です。いずれにせよ、この論点を提案依頼書（RFP）の段階で提示することをおすすめします。契約直前に持ち出すと、金額と納期の再交渉になるためです。

引き渡し形態も具体的に書く

「モデルは発注側に帰属する」と書いても、実際に何が渡されるかが曖昧だと意味がありません。

• 学習済みモデルのファイル形式とバージョン
• 学習に用いたスクリプト、前処理コード、ハイパーパラメータ設定
• 再学習を自社または第三者が実施できるだけのドキュメント
• 依存するライブラリとそのライセンス（OSSライセンスの制約を含む）
• 推論に必要な実行環境の仕様

将来の内製化や第三者への移管を視野に入れるなら、ここまで書き切っておく必要があります。自社データを繋ぐ層をどう設計するかについてはRAG構築の記事も参考になるはずです。

タイ拠点から発注するときに追加で決まること

ここからはタイ・ASEANで操業する企業に固有の論点です。同じAI開発の発注でも、契約主体をどこに置くかで税務と法務の扱いが変わります。

契約主体を日本本社にするか、タイ現地法人にするか

まずこの判断が入口です。日本本社が契約すれば日本法・日本の税務で完結しやすい一方、実際にシステムを使うのはタイの工場です。タイ現地法人が契約すれば現地の予算と決裁で回せますが、タイの税制が適用されます。ジェトロの情報によれば、タイの法人所得税は2016年1月1日以降開始の会計年度から原則恒久的に20%、VATは現在7%です（法律上の原則税率は10%ですが勅令により7%に引き下げられています）。

タイ国内のベンダーに発注する場合

タイ国内のサービス提供者に支払うサービス料には、源泉徴収税（WHT）がかかります。一般企業による支払い時は3%（受取人が非恒久的な外国企業支店の場合は5%）。法人への支払いの申告書はPND53で、支払月の翌月7日までに申告・納税します。

さらに注目すべき制度が、e-Withholding Tax の軽減税率1%です。タイ内閣は電子源泉徴収の軽減税率の延長を承認し、当初2025年末で終了予定だったものが遡及適用のうえ2027年末まで継続されることになりました。通常の5%・3%・2%から引き下げられた1%のままで、適用期間は2026年1月1日〜2027年12月31日です。対象は法人（財団・協会を除く）および個人への課税所得の支払いで、e-Withholding Tax システムを使うもの。サービス料、専門職報酬、賃貸料、広告料、著作権料、販促費、賞金などが含まれます。

あわせて、e-Tax Invoice / e-Receipt システムへの投資、e-Withholding Tax システムへの投資、これらの利用に係るサービス提供者費用、ETDA を通じた情報システム評価サービスについて、法人所得税の追加損金算入も承認されました（同じく2026年1月1日〜2027年12月31日）。これらは2025年12月31日に失効していたものが延長された形です。

思考実験：源泉徴収の違いで送金額はどう変わるか

以下は仮定の金額を用いた思考実験であり、実際の取引条件や税務判断を示すものではありません。 税率のみFACTSに基づく公表値を用いています。

前提（金額は仮定）：タイ現地法人が、タイ国内のAI開発会社にサービス料 100,000 THB（税抜）を支払う。

計算：100,000 + 7,000 − 3,000 = 104,000。100,000 + 7,000 − 1,000 = 106,000。

支払総額（サービス料＋VAT）は同じですが、源泉徴収して国に納める分と、ベンダーに直接渡る分の配分が変わります。ベンダー側から見れば手元に入るキャッシュが増えるため、e-Withholding Tax への対応を交渉材料にできる場合があります。なお、VATの取り扱い（仕入税額控除の可否や時期）および源泉徴収税の還付・充当については個別の判断が必要ですので、必ず税務専門家にご確認ください。

国外の業者に発注する場合——リバースチャージVATとPND54

日本のAI開発会社に発注する場合、あるいはシンガポールや欧米のベンダーに発注する場合、追加で考えるべき論点があります。

タイ国外の企業が海外から役務提供を行い、そのサービスがタイ国内で使用される場合、タイ国内でサービス提供をしているとみなされ、7%のVATが発生します。この場合、国外の役務提供者に代わって、サービスを受けたタイ法人が P.P.36 という申告書で納税申告をする必要があります。いわゆるリバースチャージです。

さらに、タイ国外への支払いは同時に源泉税（PND54）の対象となる可能性が高いとされており、事前に専門家の助言を受けることが推奨されています。具体的な税率や租税条約の適用可否は案件によって異なるため、本記事では断定しません。

実務上の含意は次の通りです。日本のベンダーに発注したほうが安く見えても、タイ側で発生する申告実務とコストを含めると評価が変わりうる、ということです。そして重要なのは、これらの申告義務は「知らなかった」では済まないという点です。契約交渉の段階で、次の3点を必ず社内の経理・税務担当と握ってください。

1. 契約主体をどちらにするか（日本本社／タイ現地法人）
2. サービスの「使用地」がどこと整理されるか
3. VATおよび源泉税を、契約金額に含めるのか別途負担とするのか（グロスアップ条項の有無）

3番目は契約書の文言の問題です。「金額には税金を含まない」とだけ書かれていると、後から誰が負担するかで揉めます。

タイAI法は未成立——だからこそ契約に書いておく

もう一つ、時限性の高い論点があります。タイ電子取引開発機構（ETDA）が2026年7月2日に人工知能法（Draft Act on Artificial Intelligence）の新版ドラフトを公開し、約30日間の公開意見聴取を実施しました。この意見聴取の窓は2026年8月初旬に閉じたとみられます。本記事の執筆時点で同法は成立していません。

現時点で同法は未成立であり、成立時期は確定していません。 したがって本記事は「タイAI法に対応せよ」とは言いません。しかしドラフトの内容には、発注側が今のうちに手を打っておくべき要素が含まれています。

ドラフトはEUのAI Actからリスクベースの構造を借りつつ、タイ独自の要素を持っています。具体的には、AI関連損害についての厳格責任、外国提供者に対する国内代理人の設置義務、AI生成コンテンツの表示義務です。リスク階層としては、禁止リスクAI（サブリミナル手法による認知・行動操作、不公正で広範な差別を生じさせるAIシステム）と、高リスクAI（勅令で指定。国家安全保障、健康、環境、エネルギー、電気通信、運輸に影響するもの）が置かれています。後続の勅令によって、一定のAIシステムについて展開前の規制当局への届出・登録・ライセンスが追加で求められる可能性もあります。

ここから導かれる実務論は一つです。成立時に誰が対応するかを、いま契約に書いておくこと。具体的には次のような条項を検討します。

これらは「法令が成立したら別途協議する」という一文だけでも、まったく書かないよりはるかにましです。理想は、協議の枠組み（誰が、いつまでに、どういう基準で費用を分担するか）まで書いておくことです。タイでのAI導入における国別の実務差についてはタイのAI導入の記事でも触れています。

なお、税務についても法制についても、本記事は一般的な情報提供にとどまります。実際の判断にあたっては必ず税務専門家・法務専門家にご確認ください。

AI開発会社に必ず聞く10の質問

ここまでの整理を、商談の場で使える質問リストに落とします。各質問に「なぜ聞くのか」と「どんな答えが危険信号か」を添えます。

1. 本件はチェックリストの3類型（汎用的AIサービス利用型／カスタマイズ型／新規開発型）のどれに当たると考えますか。

なぜ聞くか：類型が違えば詰めるべき論点が違います。相手が類型を意識しているかで、契約実務の練度が測れます。

危険信号：「全部オーダーメイドで作ります」と即答する。既成サービスで足りる部分まで新規開発に寄せている可能性があります。

2. 探索的段階型のように、段階ごとに契約を分ける進め方は可能ですか。

なぜ聞くか：打ち切れる場所を作れるかどうかの確認です。

危険信号：「一括のほうが安くなります」で押し切ろうとする。安さと引き換えに撤退の自由を失います。

3. アセスメント段階で「難しい」という結論になった場合、何が納品されますか。

なぜ聞くか：失敗しても手元に何が残るかの確認です。

危険信号：明確に答えられない。あるいは「そういうケースはありません」と言う。

4. 各段階の契約類型は請負ですか準委任ですか。準委任なら履行割合型ですか成果完成型ですか。

なぜ聞くか：完成義務の有無を明示させる質問です。

危険信号：「準委任ですが実質請負と同じです」といった曖昧な説明。法的にはまったく違います。

5. ご提案の精度指標の分母は何ですか。文字単位ですか、項目単位ですか、帳票単位ですか。

なぜ聞くか：第5章で見たとおり、分母で必要工数が桁違いになります。

危険信号：即答できない。「一般的には99%程度出ます」と分母抜きで答える。

6. 検収用データセットはどう決めますか。何件、どういう内訳にしますか。

なぜ聞くか：母集団が固定されなければ検収は成立しません。

危険信号：「実際に動かして問題なければ」で済ませようとする。

7. 検収基準を満たさなかった場合、再対応は何回・何週間まで無償ですか。その後はどうなりますか。

なぜ聞くか：うまくいかなかったときの出口の確認です。

危険信号：「満たすまでやります」と期限を切らない。無限責任は現実には履行されません。

8. 弊社のデータで学習した学習済みモデルおよび派生モデルを、他社案件に流用することはありますか。

なぜ聞くか：第6章の中核論点です。

危険信号：「一般化した知見としては使わせていただくことがあります」で終わり、範囲の定義に進まない。

9. 既存システムとの連携と権限設計は今回の見積に含まれていますか。含まれない場合、何が確定すれば見積が出せますか。

なぜ聞くか：第4章の④層の欠落を潰す質問です。

危険信号：「連携部分は御社側でご対応ください」と範囲外にしたまま、条件を示さない。

10. 稼働後の再学習は誰が、どの頻度で、どういう体制でやりますか。契約主体はタイ法人ですか日本法人ですか。

なぜ聞くか：⑤層と、第7章の税務・法務の入口を同時に確認します。

危険信号：運用体制の話になると急に人が変わる、あるいは「保守は別会社です」と初出の情報が出てくる。

この10問を、できれば書面で質問し、書面で回答をもらってください。口頭の説明は契約書に残りません。回答文書を提案書に添付してもらえば、後の検収の場で共通の参照点になります。

よくある失敗パターン6つ

実務でよく見る失敗を、原因と対策の形で整理します。

パターン1：PoCで止まって、そのまま塩漬けになる

原因：PoCの出口条件が「やってみて感触を掴む」レベルでしか定義されていない。次の段階に進む判断基準がないため、誰も判断できない。

対策：PoC開始前に「どの数値がどうなれば開発段階に進むか」を書面で合意する。進まない場合の終了手続きも同時に書く。

パターン2：検収で「精度」の解釈が割れる

原因：契約書に分母のない精度指標だけが書かれている。

対策：検収用データセットを別紙で固定し、業務指標（残る人手作業の件数・時間）で書く。

パターン3：モデルはできたが、業務システムに繋がらない

原因：見積の④層（既存システム連携と権限設計）が範囲外だった。稼働後にCSVを手作業でやり取りする運用が残る。

対策：見積の突き合わせを5層で行い、④の欠落を発注前に潰す。連携先システムの一覧と本数を先に自社で作る。

パターン4：半年後に精度が落ち、誰も直せない

原因：⑤層（運用・再学習）の体制が契約に含まれていない。開発したエンジニアが別案件に移り、再学習の手順が残っていない。

対策：追加学習段階を最初から契約に含める。再学習に必要なスクリプトとドキュメントの引き渡しを検収条件に入れる。

パターン5：ベンダーを乗り換えられない

原因：学習済みモデルの帰属が曖昧、あるいは実行環境がベンダー固有で、引き渡し形態が定義されていない。

対策：第6章の引き渡し形態リストを契約書に落とす。バックグラウンドIPとフォアグラウンドIPを分けて記載する。

パターン6：稼働直前に税務の問題が出る

原因：国外ベンダーへの支払いに伴うリバースチャージVATやPND54の論点が、契約締結後に発覚する。グロスアップ条項がなく、負担者で揉める。

対策：契約主体の決定を交渉の最初に置く。経理・税務担当を見積比較の段階から巻き込む。

6つに共通しているのは、いずれも技術の問題ではなく、事前の取り決めの問題だという点です。だからこそ、会社の一覧比較では防げません。

90日の進め方

最後に、実行のロードマップを示します。以下は標準的な進め方の例であり、案件の規模やデータの状態によって前後します。

この90日のうち、AI開発会社と話している時間は実質2〜3週間であることに注目してください。残りは自社の中で決めるべきことを決める時間です。順序を逆にして、まずベンダー訪問から始めると、自社の未決事項を相手に決めてもらうことになり、その決定は必ず相手に有利な形になります。

第5〜6週のデータ棚卸しが遅れると全体が遅れます。ここが最も工数を読みにくいため、余裕を持って着手してください。第12週の専門家レビューも、外部の予定に依存するため早めの打診が必要です。

よくある質問（FAQ）

AI開発会社とAIコンサルティング会社は何が違う？

明確な業界標準の定義はありませんが、実務的には力点の置き所が違います。AIコンサルティングを名乗る会社は、第4章の①課題定義・データ調査の層に強く、どの業務にAIを当てるかの見極めや、投資対効果の整理を担うことが多い形です。AI開発会社は③モデル／アプリ構築の層が中心になります。問題は、②データ整備、④既存システム連携、⑤運用の3層がどちらの守備範囲にも入らず宙に浮くケースがあることです。両方に相談する場合は、5層のどこを誰が持つかを最初に紙に書いてください。なお、コンサルティングだけを別契約にすると、その成果物が開発会社にそのまま渡せる形になっているかも確認が必要です。

AI受託開発の見積はなぜ会社ごとに大きく違う？

主因は単価差ではなく、見積範囲の差です。第4章で見たとおり、④既存システム連携と権限設計、⑤運用・再学習が含まれているかどうかで総額は大きく変わります。加えて、②データ整備の前提が違うことも大きな要因です。「データは整備済みの前提」で見積る会社と、「表記ゆれの補正から着手する前提」で見積る会社では、同じ案件でも工数が別物になります。比較する際は金額の大小を並べるのではなく、5層のタグ付けを行い、同じ範囲に揃えてから比べてください。範囲を揃えると、多くの場合、金額差は想像していたより小さくなります。

AI開発の外注と内製はどちらが得？

二択で考えないほうが良い問いです。第4章の5層のうち、①課題定義と⑤運用は自社側に寄せ、②〜④のうち技術的に重い部分を外に出す、という層別の分担が現実的です。理由は2つあります。第一に、①は自社の業務理解がなければ精度が上がりません。第二に、⑤を完全に外注すると、精度劣化の検知が遅れ、契約が切れた瞬間に何もできなくなります。逆に、③モデル構築を最初から内製しようとすると、人材の確保と維持に時間がかかりすぎます。層ごとの持ち場の分け方はAI内製化支援の記事に詳しくまとめています。

AI システム開発の契約は請負にできない？

「できない」わけではありませんが、AIモデル部分について請負を求めると、ベンダーが受けないか、リスク分の上乗せが入るのが一般的です。AIの精度が学習データに依存する性質から、ベンダは請負型を避ける傾向があるとされています。現実的な設計は2つです。ひとつは、AIモデル部分と周辺システム部分を分け、仕様が確定する周辺システムだけを請負に切り出すこと。もうひとつは、成果完成型の準委任型契約という折衷案を採ることです。ただし後者を採る場合、「完成」の定義について専門家との協議が必須とされています。定義を書き切れないなら、成果完成型は形だけのものになります。契約類型の最終判断は必ず弁護士にご確認ください。

AI開発 費用のどこが一番ぶれる？

②データ整備と④既存システム連携の2層です。②は、着手してみるまでデータの実態が分からないためにぶれます。「3年分のデータがあります」と聞いていたのに、途中でフォーマットが変わっていた、担当者ごとに入力ルールが違った、というのはよくある話です。④は、連携先システムの本数とインターフェースの仕様によって工数が線形以上に増えます。この2層のぶれを抑える最善の方法は、アセスメント段階を独立した契約にして、そこでデータと既存システムの現況を確定させてから、③以降の見積を取り直すことです。段階契約は撤退の自由を作るだけでなく、見積の精度を上げる装置でもあります。

AI導入の相談はどの段階でしてよい？

構想段階で問題ありません。むしろ、RFPを書き上げてから初めて相談すると、5層のうち②と④の前提が現実と合わないまま固まってしまうことがあります。ただし、相談の前に自社で用意しておくと話が早く進むものが3つあります。ひとつめは対象工程の候補（3つ挙げて1つに絞ったもの）、ふたつめはデータの現況（所在・件数・期間・欠損状況）、みっつめは効果の測り方の仮説です。3つめについてはAI導入の効果測定・ROIの記事が参考になります。この3点があれば、初回の打ち合わせで実現可能性の見立てまで踏み込めます。

まとめ

本記事の主張を最後にもう一度整理します。

AI開発は、学習データに基づく帰納的な手法で行われるため、学習データそのものに精度の限界が内包されている可能性があり、完成義務や性能保証の設定が困難です。つまり「良い会社を選べば完成する」という前提が構造的に成り立ちにくい。だからこそ、会社の一覧比較よりも先に、次の4点を設計する必要があります。

1. 契約類型：請負か準委任か。準委任なら履行割合型か成果完成型か。「完成」の定義を書き切れるか
2. 段階の切り方：アセスメント／PoC／開発／追加学習の4段階に分け、各段階に入口条件と出口条件を置く。打ち切れる場所を作る
3. 検収条件：精度の分母を明示し、検収用データセットを別紙で固定し、業務指標（残る人手作業の件数・時間）で書く
4. 権利帰属：フォアグラウンドIPとバックグラウンドIPを区別し、生データ・学習用データセット・学習済みモデル・派生モデルの4つに分けて定める。他社案件への流用可否を必ず確認する

タイから発注する場合は、これに契約主体の選択、WHT・VAT・リバースチャージの取り扱い、そして未成立のタイAI法が成立した場合の対応分担が加わります。税務と法務は必ず専門家にご確認ください。

そして90日ロードマップで見たとおり、この設計作業の大半はAI開発会社に会う前に、自社の中で終わらせられるものです。順序を守るだけで、選定の失敗はかなりの部分が防げます。

TOMAS TECHはタイ・バンコクを拠点に、日系製造業の工場向けにIT・OT領域のシステムを手がけています。「まだ構想段階で、どの工程に当てるかも決まっていない」「他社から届いた見積書の読み方を一緒に整理してほしい」といった段階でのご相談も歓迎です。発注先を決める前の壁打ちとしてお使いいただければと思います。ご相談はお問い合わせフォームからお気軽にどうぞ。

参考情報

• 経済産業省「AI・データの利用に関する契約ガイドライン」（2018年6月公表、2019年12月一部改訂）AI編 — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20180615001-3.pdf
• 経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月18日公表）原資料PDF — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20250218003-ar.pdf
• 同上 プレスリリース — https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html
• 契約ガイドライン概要資料（2021年1月 経済産業省情報経済課） — https://www.jftc.go.jp/cprc/conference/index_files/21011902.pdf
• ロジットパートナーズ法律会計事務所「AIの利用・開発に関する契約チェックリスト」解説 — https://partners.logit.jp/ai-checkliist-meti/
• 特許庁 IP BASE「AI開発の契約類型」 — https://ipbase.go.jp/learn/point/ai/page05.php
• ジェトロ「タイ 税制」（法人所得税20%、VAT 7%、源泉徴収税） — https://www.jetro.go.jp/world/asia/th/invest_04.html
• HLB Thailand「Cabinet Approves Extension of Tax Measures to End of 2027」（e-Withholding Tax 軽減税率1%、2026-01-01〜2027-12-31） — https://www.hlbthai.com/cabinet-approves-extension-of-tax-measures-to-end-of-2027-to-promote-adoption-of-electronic-tax-systems/
• Mahanakorn Partners「Thailand Approves Two-Year Extension of Electronic Tax System Incentives」 — https://mahanakornpartners.com/thailand-approves-two-year-extension-of-electronic-tax-system-incentives/
• JGA「国外業者への支払いとリバースチャージVAT（P.P.36）」 — https://jga.asia/?p=1241
• Mondaq「Thailand Releases New Draft Artificial Intelligence Act」（ETDA 2026年7月2日ドラフト公開、未成立） — https://www.mondaq.com/it-and-internet/1811290/thailand-releases-new-draft-artificial-intelligence-act
• Tilleke & Gibbins「Thailand’s AI Governance Framework」 — https://www.tilleke.com/insights/comprehensive-policy-thailands-ai-governance-framework/