AI内製化支援の選び方｜タイ拠点で自走する90日実践ガイド

タイ拠点でAI活用を進めたいものの、PoCが担当者任せになり、外部ベンダーなしでは改善も運用もできない。そんな状態を変えるための選択肢が「AI 内製化 支援」です。本記事では、外注をゼロにすることを目的にせず、社内が価値・リスク・評価・変更の判断を握りながら、必要な専門性だけを外部と組み合わせる方法を解説します。

AI内製化支援とは何か：外注ゼロではなく意思決定能力を社内に残す

AI内製化は、モデル、クラウド、すべてのコードを自社だけで作ることではありません。むしろ重要なのは、業務オーナーが「どの課題を解くか」「どの品質なら現場で使えるか」「どのリスクを受容しないか」を判断でき、社内チームがデータ、アクセス権限、評価基準、変更管理、運用記録を握っていることです。外部支援会社は不足する専門性や立ち上げ速度を補いますが、判断の主体は企業側に残します。

この定義に立つと、内製化の成否をPoCの本数や生成AIアカウントの利用者数だけで測ることはできません。再利用できる評価データセット、誰でもたどれる運用手順、権限設計、引継ぎ可能なコードと設定、意思決定ログ、停止条件、そして支援会社から卒業する条件まで残っているかが重要です。

OpenAIが企業のAI活用を整理した資料では、ツール導入より文化を先に整えること、ガバナンスを利用抑制ではなく拡大の基盤にすること、利用するだけでなく業務成果のオーナーシップを持つこと、規模より品質を先に確立することなどが反復して観察されたパターンとして紹介されています。これは全社に同じ因果関係を保証するものではありませんが、「ライセンスを配れば自動的に価値が出る」という前提を見直す材料になります。

また、OpenAIが2026年8月に公表した企業顧客データでは、月次利用上位10%のfrontier firmsはtypical firmsに比べ、アクティブユーザー当たり8.3倍の出力トークンを生成していました。ただし、これは利用深度の代理指標であり、生産性やROIが8.3倍という意味ではありません。内製化の目標は利用量を競うことではなく、業務に接続した再現可能なワークフローを増やすことです。

外注・共同運用・内製をどう使い分けるか

選択肢は「全部外注」か「全部内製」かの二択ではありません。AI導入の成熟度、データの機密性、社内人材、求める速度によって、適切な境界は変わります。

多くのタイ拠点にとって現実的なのは共同運用です。たとえば、現地の業務担当者が対象プロセスと受入基準を定義し、日本本社のITまたは地域統括がセキュリティと共通基盤を管理し、支援会社が初期アーキテクチャや評価設計を伴走します。運用のたびに支援会社へ依頼するのではなく、定型変更は現地チーム、高リスク変更は共同レビュー、基盤変更は地域ITという境界を決めます。

内製化の度合いは、技術スタックの所有割合より「変更を自社判断で安全に進められる範囲」で測ると実態に合います。プロンプトの修正、ナレッジ更新、ユーザー追加、評価ケース追加、障害の一次切り分け、ロールバックのうち、どこまでを社内で完結できるかを棚卸しすると、次に移管すべき能力が見えます。

最初に決めるべき対象業務と成功条件

社内AI構築の第一歩はモデル選定ではなく、業務の切り分けです。「生成AIを導入する」では広すぎます。問い合わせ一次回答、設備保全記録の検索、見積仕様の確認、品質報告書の下書きなど、入力・判断・出力・責任者を説明できる単位に分けます。

候補業務は、価値、実現可能性、リスク、学習効果の4軸で比較します。頻度が高く、正解や良い出力の例を集めやすく、誤りを人が発見できる業務は最初の候補に向いています。一方、誤答が人身安全や重大な契約判断へ直結し、レビューできる専門家も不足する業務は、早期の自動化対象にしません。

成功条件は少なくとも次の層に分けます。

• 業務成果：処理時間、手戻り、リードタイム、問い合わせ解決率など
• 品質：正確性、根拠提示、必須項目充足、言語別の自然さなど
• 安全性：権限外情報の非表示、個人情報の扱い、禁止回答、監査可能性など
• 定着：対象者の継続利用、例外処理、問い合わせ件数、人による上書き率など
• 内製移管：社内で評価、設定変更、リリース、一次対応を実行できる割合

「利用者100人」「質問1万件」といった量だけでは価値の証明になりません。OpenAI AcademyのWorkflow Adoption Plannerも、開始や利用回数を採用・価値の証拠として扱わず、品質、人による上書き、例外、サポート需要、ユーザー体験を追い、継続・修正・一時停止・中止・拡大の判断基準を定める考え方を示しています。

AI活用伴走支援を受けるためのCoEとRACI

AI CoEは大人数の専門部署である必要はありません。重要なのは、業務、IT、データ、セキュリティ、法務・コンプライアンス、人材育成の判断経路が見えることです。タイ拠点では日本語・英語・タイ語が混在しやすいため、会議言語だけでなく、要件、評価データ、運用手順、障害連絡の正本言語も決めます。

最小構成では、Executive Sponsor、Business Product Owner、AI/IT Lead、Data Owner、Security/Privacy担当、Local Championを置きます。人が兼務しても構いませんが、責任まで曖昧にしないことが大切です。

Aは最終説明責任、Rは実行責任、Cは相談先、Iは情報共有先を表します。支援会社だけをRにしたままにせず、90日終了時には社内のRを増やします。特に評価セット、一次障害対応、ユーザーと権限の管理、定型的なナレッジ更新は、内製化の成果として社内へ移管しやすい領域です。

ChatGPT Enterpriseの管理者向けクイックスタートでも、本格展開前にowner/admin、導入範囲、identity、SSO/SCIM、groups/RBAC、security/compliance controlsを決め、導入後はanalyticsやimpact surveyで採用と摩擦を追うことが案内されています。特定製品の採用にかかわらず、責任者、ID、権限、計測を先に決めるという順序は応用できます。

タイ拠点で見落とせない多言語・データ・ガバナンス

タイの工場や販売会社では、作業標準はタイ語、設備仕様は英語、本社承認資料は日本語という構成が珍しくありません。単に多言語モデルを選べば解決するわけではなく、言語ごとに用語、略語、日付・単位、敬称、承認表現が異なります。評価セットは日本語原文を機械翻訳して終わらせず、現地担当者が実際に使う質問と望ましい回答を各言語で用意します。

データについては、何をAIへ送るかだけでなく、どの国・リージョンで処理・保存されるか、ログへ何が残るか、誰が閲覧できるか、削除や保持期間をどう扱うかを確認します。個人情報、顧客秘密、設計情報、輸出管理対象となり得る情報を分類し、用途ごとに許可、条件付き許可、禁止を決めます。

ETDAの組織向けGenerative AI Governance Guidelineは、生成AIの便益と制約を理解したうえで、privacy、data security、従業員や社会への影響などのリスクを扱い、関係者の参加を伴うバランスある導入を重視しています。NIST AI RMFも、AIシステムの設計・開発・利用・評価に信頼性を組み込むための自主的フレームワークです。どちらも法務助言そのものではありませんが、リスクの棚卸しと役割設計の共通言語として利用できます。

World BankのThailand Digital Data Infrastructure Roadmapは、タイでクラウド・AI利用とデータインフラ投資が進む一方、skills、governance、interoperability、institutional coordinationの基盤ギャップが便益を制約すると整理しています。したがって、AI導入相談ではアプリだけでなく、データ責任者、共有ルール、連携方式、現地運用能力まで範囲に含める必要があります。

なお、PDPAや契約、越境移転への具体的な対応は、データ、利用目的、契約関係によって異なります。本記事は一般的な実務整理であり、法律相談の代替ではありません。必要に応じてタイの法務・プライバシー専門家へ確認してください。

90日で進める社内AI構築と内製移管ロードマップ

90日は「全社AIを完成させる期間」ではなく、限定した業務で価値とリスクを検証し、社内チームが次の改善を自ら回せる状態を作る期間です。各段階に継続条件と停止条件を置きます。

1〜15日：発見と基準線

業務観察、関係者インタビュー、現状時間の計測、データ棚卸し、リスク分類を行います。対象を1〜2ワークフローに限定し、誰が最終確認するかを決めます。既存の良い出力と悪い出力、例外、禁止事項から初期評価セットを作ります。この段階で「AIを使う前の基準線」がなければ、後から改善効果を説明できません。

成果物は、対象業務図、課題仮説、基準線、データ一覧、初期RACI、リスク登録簿、評価計画です。システムを作り始める前に、スポンサーが対象範囲と停止条件を承認します。

16〜35日：安全な試作と評価設計

最小限の接続でプロトタイプを作り、代表ケース、難しいケース、拒否すべきケースを評価します。正解が一つでない文章生成では、必須要素、禁止要素、根拠、スタイル、人による採点基準を組み合わせます。検索やRAGを使う場合は、関連性だけでなく権限継承と引用元の正しさも確認します。

企業内データを使う生成AIでは、まずデータの権限と鮮度を整える必要があります。具体的な構築論は、関連記事「企業向けRAG導入の実践ガイド」も参照してください。

36〜60日：限定運用と現場学習

対象ユーザーを限定して実データに近い環境で運用します。出力をそのまま採用させず、人によるレビュー、上書き理由、例外、サポート問い合わせを記録します。週次で評価セットへ失敗例を追加し、プロンプトだけでなく入力データ、業務手順、権限、UIのどこに原因があるかを切り分けます。

この時期から支援会社の画面共有を見学するだけでなく、社内担当者が設定変更、評価実行、リリースノート作成、障害一次切り分けを実際に担当します。支援会社は答えを代行するのではなく、レビューとフィードバックへ比重を移します。

61〜75日：運用設計と教育

監視項目、アラート、問い合わせ窓口、変更申請、承認、ロールバック、インシデント連絡を定めます。日常運用、月次レビュー、重大変更を分け、それぞれの責任者を明記します。ユーザー教育は一般的なプロンプト講座だけでなく、対象業務の良い例、使ってはいけないデータ、検証方法、誤りを見つけたときの報告経路を含めます。

AI人材育成を役割別に設計する方法は「タイ製造業のAI研修設計ガイド」で詳しく解説しています。全員を開発者にするのではなく、経営、業務オーナー、現場利用者、IT運用者で必要能力を分けることが定着につながります。

76〜90日：受入試験、引継ぎ、次判断

凍結した評価セットで受入試験を行い、品質、安全性、運用性、内製移管の基準を判定します。社内担当者だけで定型変更と一次対応を実行するリハーサルも行います。未達項目は、追加改善、範囲縮小、運用条件付き承認、停止のいずれかに分類します。

最後に、継続、修正、一時停止、中止、拡大を決めます。「90日経ったから本番化」ではなく、事前に合意した基準に基づいて判断します。拡大する場合も、次の業務へ評価資産と運用テンプレートを再利用できるかを確認します。

AI内製化支援会社を比較する評価表

提案の華やかさではなく、移管可能性と検証可能性で比較します。候補会社へ同じ質問をし、回答だけでなくサンプル成果物や作業方法を確認すると差が見えます。

特定クラウドやモデルの認定資格は参考になりますが、それだけで伴走能力は判断できません。対象業務に近い経験、評価の厳密さ、セキュリティチームとの協働、教える力、引継ぎへの姿勢を組み合わせて見ます。顧客名を出せない場合でも、匿名化した成果物の構成や評価手順を説明できるかは確認できます。

RFP・契約で明確にする成果物、知財、データ、セキュリティ

RFPは実装機能の一覧ではなく、解く業務、受入基準、責任境界、移管条件を伝える文書です。現状の制約や不明点も書き、提案者が前提を明示できるようにします。

最低限、次を含めます。

1. 対象業務、利用者、言語、拠点、業務責任者
2. 現状指標、期待する改善、品質・安全性の最低基準
3. 利用可能データ、禁止データ、ID・権限・ログの条件
4. 既存クラウド、ネットワーク、業務システム、運用制約
5. 作業範囲、対象外、顧客側の前提作業、依存関係
6. 評価方法、受入試験、障害・性能・セキュリティ要件
7. コード、設定、プロンプト、評価データ、文書の納品形式
8. 知財、既存資産、第三者サービス、再利用部品の扱い
9. 教育、ペア作業、引継ぎ、サポート、卒業条件
10. 変更要求、料金への影響、終了時のデータ返却・削除

契約では、顧客データを学習やサービス改善へ利用できるか、下請けや外部APIは何か、生成物とカスタムコードの権利、オープンソースの管理、脆弱性対応、ログ保管、インシデント通知、終了支援を確認します。これらは法域と契約内容により判断が変わるため、具体条項は専門家へ確認してください。

費用を比較するときは総額だけでなく、discovery、data readiness、identity/permissions、prototype、evaluation set、integration、monitoring、training、change management、supportへ分解します。安価な試作でも、評価と引継ぎが含まれなければ本番化の段階で追加負担が増えます。逆に、すべてを最初から作り込む提案は、価値が未確認の段階で固定費を抱える恐れがあります。

Evals：AIの品質を感想から再現可能な判断へ変える

AIの出力は同じ質問でも揺らぐため、担当者が「良さそう」と感じるだけでは受入判断になりません。Evalsは、実際の業務ケースをもとに、変更前後の品質を同じ物差しで比較する仕組みです。

評価セットには、通常例だけでなく、表記揺れ、情報不足、矛盾、古い文書、権限外情報、悪意ある入力、回答不能、言語混在を含めます。各ケースに望ましい挙動、許容範囲、重大度を付けます。自動採点が難しい場合は、人によるルーブリック評価と組み合わせます。

評価セットは一度作って終わりではありません。障害、ユーザーの上書き、問い合わせから新しいケースを追加します。モデル、プロンプト、データ、検索設定、外部ツールを変更するたびに回帰評価を実行し、改善した点と悪化した点を記録します。

運用監視と変更管理を最初から設計する

PoCでは動いても、本番ではデータ更新、権限変更、利用増、外部API障害、モデル更新が起きます。内製化を目指すなら、誰が平常時の状態を見て、どの条件で止めるかを決めます。

監視対象には、システム稼働、応答時間、エラー、利用量、コストだけでなく、品質サンプル、拒否、権限違反、人による上書き、ユーザー問い合わせを含めます。すべての会話を無制限に保存するのではなく、目的、閲覧権限、保持期間、マスキングを設計します。

変更はリスクで分類します。文言修正やFAQ追加など低リスク変更は社内担当者がチェックリストで実施し、データ接続や権限変更はIT・データ責任者がレビューし、モデルや自動実行範囲の変更はセキュリティを含む承認へ回します。各変更に、理由、変更者、評価結果、承認者、ロールバック手順を残します。

AIエージェントがメール送信、発注、データ更新などを実行する場合は、閲覧型のAIより強い統制が必要です。最小権限、操作ごとの許可、人の承認、実行ログ、件数・金額などの上限、緊急停止を設けます。OpenAIの企業活用に関する示唆でも、エージェントを業務文脈やツールへ接続すると同時に、明確な権限、レビュー、ガバナンスを置くことが強調されています。

教育は一般講座より役割別の実地演習にする

内製化の教育を、全社員向けのプロンプト入門だけで終わらせないことが重要です。経営層には投資判断とリスク受容、業務オーナーには対象選定と受入基準、利用者には検証と報告、ITには権限・監視・変更管理、開発担当には評価駆動の改善が必要です。

現地チャンピオンには、タイ語で同僚を支援し、よくある失敗を収集し、中央チームへ改善提案できる権限を与えます。研修後のクイズより、実際の業務ケースを使った演習、誤答の発見、エスカレーション、設定変更の実演を評価します。

支援会社から社内への移管は、説明、共同作業、社内主導、支援会社の観察という順に進めます。録画やマニュアルだけでは、判断が必要な例外対応は移りません。なぜその設計を選んだか、どの選択肢を捨てたかを意思決定記録に残すと、担当者変更後も改善を継続できます。

成果物・受入基準・卒業条件を最初から合意する

卒業条件がなければ、伴走支援はいつまでも終わりません。契約開始時に「何ができれば支援を縮小できるか」を決め、月次で達成状況を確認します。

支援会社がいなくても全変更をできる必要はありません。高難度のモデル評価、セキュリティレビュー、基盤刷新は外部へ依頼し続けても構いません。重要なのは、社内が依頼の要否を判断し、成果を受け入れ、ベンダー変更時にも資産を引き継げることです。

AI内製化で起きやすい失敗パターン

PoCの完成を内製化の完成と考える

デモは価値仮説を見せますが、権限、監視、例外、サポート、教育までは証明しません。PoC終了条件と本番受入条件を分け、運用リハーサルを必須にします。

プロンプト技術だけを移管する

品質はプロンプトだけで決まりません。データ、検索、UI、業務手順、権限、モデル、レビュー方法の組み合わせです。問題の切り分け方を移管しなければ、社内チームは改善を続けられません。

兼務者一人を「AI担当」にする

業務知識、技術、データ権限、リスク承認を一人で持つことは困難です。小さくてもRACIを作り、少なくとも業務オーナーとIT責任者を分け、代替要員を育てます。

利用数を成功指標にする

利用が多くても、誤答確認や手戻りが増えれば価値は出ません。業務成果、品質、安全性、レビュー負荷、内製移管を一緒に追います。

翻訳だけで多言語対応を終える

工場用語、製品名、単位、敬称、承認表現は現場文脈で変わります。言語別の代表ケースを作り、現地業務担当者の受入を得ます。

卒業条件を後で決める

支援会社が主導している状態が長引くほど、移管時間を確保しにくくなります。契約初期から社内担当者の実演日と支援縮小基準を工程に入れます。

AI内製化支援の費用と効果をどう考えるか

AI内製化支援の費用は、対象業務、データ準備、既存システム連携、権限、評価、言語数、教育、運用要件で大きく変わります。根拠のない市場相場だけで判断せず、どの能力と成果物を買うのかを分解してください。

効果試算も仮定を明示します。たとえば、対象30名、一人当たり月20時間がAI支援対象、削減率15%、人件費600 THB/時と仮定すると、月間削減時間は30×20×15%=90時間、金額換算は54,000 THB/月です。これは一般相場でも成果保証でもありません。支援費、API・クラウド費、運用費、人によるレビュー時間、教育時間を差し引き、品質やリードタイムなど非金銭効果も含めて判断します。

さらに、内製化には「次の案件が速くなる」というオプション価値があります。評価テンプレート、権限設計、運用手順、教育教材を再利用できれば、二つ目以降の業務の立ち上げ負担を下げられます。ただし再利用可能性を成果物として設計しなければ、この価値は自然には生まれません。

FAQ：AI内製化支援のよくある質問

AI内製化支援とは何ですか？

企業がAIの対象選定、評価、データ、権限、変更、運用を自ら判断できるよう、外部専門家が設計・実装・教育・移管を伴走する支援です。すべてを自社開発することや、外部ベンダーを完全に排除することとは異なります。

AI活用の伴走支援はどこまで依頼できますか？

課題整理、データ棚卸し、RFP、プロトタイプ、評価設計、システム連携、ガバナンス、教育、運用設計、引継ぎまでが候補です。依頼範囲よりも、各工程で社内が何を担当し、いつ移管するかを明確にすることが重要です。

社内AI構築には専任のCoEが必要ですか？

必ずしも大規模な専任組織は必要ありません。兼務でも、業務オーナー、IT、データ、セキュリティ、現地チャンピオンの責任経路を明確にし、意思決定と運用を回せることが必要です。

AI内製化支援の費用はどのように比較すべきですか？

総額だけでなく、発見、データ準備、試作、評価、連携、監視、教育、変更管理、支援へ分解し、成果物と受入基準を揃えて比較します。未検証の市場相場ではなく、自社のスコープと前提に基づく見積を取ります。

90日で本番運用まで可能ですか？

限定した業務と利用者であれば、価値検証、運用設計、受入試験まで進められる場合があります。ただし、データ品質、連携、セキュリティ審査、関係者調整によって変わります。90日という期間そのものではなく、合意した受入基準で判断します。

タイPDPAに対応するには何を確認すべきですか？

利用目的、データ分類、処理・保存場所、第三者提供、アクセス、ログ、保持・削除などを確認します。実際の義務は状況により異なるため、本記事を法律相談の代替にせず、社内担当者や専門家へ確認してください。

支援会社から卒業できたと判断する基準は何ですか？

社内担当者が、評価ケース追加、回帰評価、定型変更、リリース、一次障害対応を手順に沿って実演でき、成果物と意思決定記録へアクセスできることが一つの目安です。高難度課題を外部へ依頼していても、依頼と受入を社内で判断できれば内製化は進んでいます。

まとめ：AI導入相談では「作るもの」より「社内に残す能力」を決める

AI内製化支援を選ぶときは、PoCの速さや機能数だけでなく、評価資産、権限設計、運用手順、教育、意思決定記録、卒業条件が社内に残るかを確認してください。タイ拠点では、日本語・英語・タイ語の現場運用、PDPAを含むデータガバナンス、現地担当者への権限移管が特に重要です。限定した業務で基準線を置き、90日で価値・安全性・運用性・移管度を測れば、拡大・修正・停止を感覚ではなく証拠で判断できます。

TOMAS TECHでは、対象業務のスコープ整理、RFP作成、90日PoC、内製移管計画の検討段階からご相談いただけます。社内に残す能力と外部へ任せる専門性を一緒に整理したい場合は、お問い合わせフォームからお気軽にご連絡ください。

参考情報

• OpenAI: From assistance to execution: How enterprises put AI to work
• OpenAI: How enterprises are scaling AI
• OpenAI Help Center: ChatGPT Enterprise admin quickstart
• OpenAI Academy: Workflow adoption planner
• NIST: AI Risk Management Framework
• NIST: Generative Artificial Intelligence Profile
• ETDA: Generative AI Governance Guideline for Organizations
• World Bank: Thailand Digital Data Infrastructure Roadmap