社内AI構築ガイド2026｜内製・SaaS・ハイブリッドの選び方と費用

「ChatGPTの法人契約は入れた。それで、次は何をすればいいのか」。タイに製造拠点を持つ日系企業から、2026年に入って最も多く寄せられる相談がこれです。汎用チャットは動くが、自社の図面も作業手順書も不良履歴も読んでくれない。かといって、すべてを自前で作る体力はない。社内AI構築という言葉が指す範囲は広く、内製とSaaSとハイブリッドでは投資額も体制も一桁違います。本記事では、作るべきか買うべきかの判断軸、段階を追った構築ロードマップ、層ごとの費用構造、そしてタイ拠点に固有の論点を、プロジェクトを起こす順番どおりに整理します。

社内AI構築は「試すか」から「どう作るか」へ移った

数字が示す現在地

生成AIの社内利用は、実験の段階を越えつつあります。産業分野のAI導入実態をまとめた2026年の統計では、製造業の55%が少なくとも1つのAIユースケースを本番運用に載せたと報告されています。ただし業種による差は大きく、本番展開率は自動車・航空宇宙が85%、石油ガス・エネルギーが78%、食品飲料が60%に対し、一般製造業は45%にとどまります。同じ調査では、産業向けAIのパイロットのおよそ30%が最初の1設備から先へ広がらないまま終わり、一方で64%の組織が12か月以内にプラスのROIを報告しているとされています。

この2つの数字を並べると、社内AI構築の本質が見えてきます。12か月で回収できる案件と、1年かけて1台分の実験で終わる案件が、同じ「AI導入」という名前で並走している。差を生んでいるのはモデルの性能ではなく、プロジェクトの組み立て方です。

タイ市場に目を向けると、製造業向けAIの市場規模は2025年の11.5億米ドルから2031年に48.0億米ドルへ、年平均26.6%で成長すると予測されています。タイの日系製造拠点にとって、これは競合他社と現地サプライヤーが同時にAIへ投資し始める時期に入ったということでもあります。

本記事が扱う範囲と扱わない範囲

社内AI構築というテーマは広いため、本記事の立ち位置を先に示します。ここで扱うのは、プロジェクトとしての意思決定です。すなわち、そもそも自社で作るべきか、作るなら何をどの順番で作り、いくらの予算をどの層に配分し、誰が使う権限を持つのかという設計判断です。

生成AI導入そのものの全体像や社内ルールの整備手順は生成AI導入の進め方と費用で扱っているため、本記事では重複を避け、構築プロジェクトの意思決定に絞ります。

そもそも社内AI構築とは何を作ることなのか

5つの層に分けて捉える

「社内AI」という言葉が会議で使われるとき、参加者が思い浮かべているものは往々にしてバラバラです。ある人は社内向けチャットボットを、ある人は基幹システムに埋め込まれた要約機能を、ある人は自社サーバーで動くモデルそのものを想像している。この食い違いが予算の議論を空転させます。

議論を噛み合わせるために、社内AIを5つの層に分解します。

• 実行基盤層。モデルをどこで動かすか。クラウドのAPI、専用テナント、自社サーバー上の推論環境などの選択肢がある
• データ層。図面、手順書、不良報告、議事録、メール、基幹システムのマスタなど、AIに読ませる社内データを集め、整え、権限情報を付ける
• 検索・参照層。質問に対して社内データのどこを参照すべきかを決め、根拠として渡す仕組み。いわゆるRAGがこの層にあたる
• アプリケーション層。利用者が実際に触る画面と、既存業務への組み込み。チャット画面だけとは限らない
• 運用・ガバナンス層。誰が何を見られるかの権限、利用ログ、回答品質の評価、教育、モデル更新への追随

社内AI構築のプロジェクトが揉めるのは、たいてい層の話をせずに「いくらかかるか」を議論するからです。実行基盤層だけを比べれば選択肢は限られますが、費用の大半はデータ層と運用・ガバナンス層に発生します。

このうち検索・参照層の技術的な作り込みと費用感についてはRAG構築の費用と進め方で詳しく扱っています。本記事では、この層をプロジェクト全体のなかでいつ着手し、どれだけの予算枠を割くかという観点で扱います。

SaaS契約と何が決定的に違うのか

汎用の生成AI SaaSを契約することと、社内AIを構築することの違いは、機能の多寡ではありません。自社データが仕組みの中に入るかどうかです。

汎用チャットの契約は、優秀だが自社について何も知らない相談相手を全社員に配ることに近く、一般的な文章作成や翻訳では即座に価値が出ます。しかし「この不良、去年も似たのが出ていなかったか」「この客先の受入基準は何ミリだったか」という、製造現場で最も多い問いには答えられません。答えられるようにする作業がデータ層と検索・参照層であり、そこから先が社内AI構築の本体です。

内製・SaaS・ハイブリッドの選び方

3つの選択肢を定義する

言葉の定義を揃えます。

SaaS中心型は、外部ベンダーの生成AIサービスを契約し、その中に用意されたファイルアップロードや社内データ連携の機能を使う方式です。作るものはほぼゼロで、設定と運用ルールが仕事になります。

内製型は、モデルAPIまたは自社環境の推論基盤を土台に、データ連携、検索、画面、権限をすべて自社の設計で組み上げる方式です。ここでいう内製は「社内の情報システム部門が自分でコードを書く」という意味に限らず、自社が仕様の主導権を持ち、外部の開発パートナーと一緒に作る形も含みます。

ハイブリッド型は、汎用的な用途はSaaSに任せ、自社データを使う特定の業務だけを自社設計のアプリケーションとして作る方式です。2026年時点で、タイの日系製造拠点にとって現実的な着地点になることが最も多いのがこの形です。

3方式の比較

この表は優劣を示すものではなく、どの制約を受け入れるかの一覧です。SaaS中心型は速いが浅く、内製型は深いが遅く重い。ハイブリッド型は「速い部分」と「深い部分」を業務ごとに切り分ける発想です。

生成AIツールの選び方は機能表ではなく境界線で決まる

生成AIツールの選び方を検討するとき、多くの企業が機能比較表を作ります。要約できるか、日本語とタイ語に対応するか、ファイルを何個読めるか。しかし製造業で本当に判断を分けるのは、機能ではなく次の4つの境界線です。

第一に、自社データがどこへ行くか。アップロードしたファイルはどの国のどのリージョンで処理され、保存されるのか。学習に使われない契約になっているか。事業者の提供する管理者向けドキュメントで確認できる範囲を超える約束を営業担当が口頭でした場合は、必ず文書で取り直してください。

第二に、権限の粒度。生産技術の図面を購買部門が読めてしまう設計になっていないか。多くの汎用SaaSは、アップロードした人とその共有先という単位でしか権限を持てません。部門別・工程別に社内文書の閲覧範囲が分かれている企業では、この一点でSaaS単独の選択肢が消えます。

第三に、既存システムとの届く範囲。生産管理システムの実績データ、設備から上がってくる時系列データ、品質検査の記録。これらに触れられなければ、AIが答えられるのは文書に書いてあることだけです。

第四に、記録が残るか。誰がいつ何を聞き、AIが何を根拠に答えたか。顧客監査や社内監査で説明を求められたとき、ログがなければ「AIが言ったので」以上の説明ができません。

セキュリティとインフラ構成の選択肢そのものと、それぞれの費用についてはセキュア生成AI環境2026で3つの構成を比較しています。本記事では、この境界線の判断を構築プロジェクトのどの段階でどう固定するかに焦点を当てます。

社内AI構築プロジェクトの進め方

社内AI構築が「1年かけて1つのパイロットで終わる」形になるのは、たいてい順番の問題です。多くの場合、技術検証から入り、業務の選定と権限設計を後回しにしています。以下は、実際に本番運用まで到達しやすい順番です。

第0段階 業務の棚卸しと3件の選定

最初にやることはツール選定ではなく、業務の棚卸しです。部門ごとに「文書を探すのに時間がかかっている作業」「同じ質問が繰り返し来る作業」「翻訳と要約が挟まる作業」を洗い出します。タイの日系工場で毎回出てくるのは、客先規格書の該当箇所探し、過去不良の類似事例探し、タイ語作業手順書と日本語版の突き合わせ、そして日報の要約です。

洗い出した候補から、最初に取り組む業務を3件に絞ります。絞る基準は、頻度が高いこと、根拠となる文書がすでに電子化されていること、そして答えの正しさを人が確認できることの3つです。「うまくいけばインパクトが大きい」業務を最初に選ぶのは失敗の定石です。インパクトの大きい業務ほど、根拠データが紙に埋もれていて、正解の判定に専門家の時間がかかります。

第1段階 データの所在と権限の棚卸し

選んだ3業務について、AIに読ませる必要がある文書とデータの所在を特定します。ファイルサーバーのどのフォルダか、共有ドライブか、基幹システムのどのテーブルか、あるいは誰かのPCのローカルか。

同時に、現在その情報を誰が見られるのかを記録します。この作業をしないまま社内AIを作ると、AIが権限の抜け道になります。今まで生産技術部門しか開けなかったフォルダの内容を、AIが誰にでも要約して返す。これは技術的な不具合ではなく、設計の欠落です。なお、この段階で「フォルダの権限が誰にも把握されていない」ことが判明する企業は少なくありません。それ自体が、AI以前に整理すべき課題としての発見です。

第2段階 方式の決定と概算予算の確定

第0段階と第1段階の結果を持って、初めてSaaS・内製・ハイブリッドの判断をします。判断材料は揃っています。対象業務が3件、必要なデータの所在が分かっており、権限の分かれ方も見えている。

ここで決めるのは方式だけでなく、予算の層別配分です。総額をひとつの数字で承認すると、開発に寄りすぎてデータ整備が痩せます。後述する層別の費用構造に沿って、あらかじめ枠を分けて承認を取るのが安全です。

第3段階 1業務での実装と評価基準の設定

3件のうち1件を先に作ります。この段階で最も重要なのは、評価基準を実装より先に決めておくことです。

具体的には、想定質問を30問から50問用意し、それぞれについて正解と、正解の根拠となる文書の該当箇所を人が先に用意します。実装後、この問題集に対する正答率と根拠提示の正確さで判定します。「使ってみた感じは良さそう」で本番に進むと、後で品質を疑われたときに戻る基準がありません。

産業向けAIの統計では、初期実装の段階で検知結果の最大40%が誤検知になり得ると報告されています。異常検知と文書検索では性質が違いますが、チューニング前の出力をそのまま現場に見せてはいけないという示唆は共通です。この前提を持たずに現場に見せると、1回目のデモで信頼を失って二度と使われなくなります。評価と調整を経てから現場に出す。この順番は譲れません。

第4段階 現場展開と残り2業務への横展開

1業務目が評価基準を満たしたら、限定した部署で実運用に入れます。展開時に必ず用意するのは、使い方の説明ではなく「AIの答えをそのまま使ってよい場面と、必ず原本を確認すべき場面」の線引きです。この線引きが曖昧なまま広げると、現場は全員が過信するか全員が使わないかの両極に振れます。

1業務目で作った基盤、すなわちデータ連携、検索、権限、ログの仕組みは、2業務目以降で再利用できます。社内AI構築の投資対効果が改善するのはここからで、逆に言えば1業務で止めると最も割高な状態で終わります。

第5段階 定着とモデル更新への追随

半年ごとに、利用ログを見て使われていない機能と使われている機能を分けます。使われていない機能は削る。加えて、基盤モデルは年に数回更新されるため、更新のたびに第3段階で作った問題集を流し直す運用を決めておきます。この回帰テストがないと、ある日突然回答品質が変わったことに誰も気づけません。

社内AI構築の費用を層ごとに分解する

費用が動く要因を先に押さえる

社内AI構築の見積は、同じ「社内AIチャットボット」という名前でも桁が変わります。変動の主因は次の4つです。

• 対象データの整備状態。すでに電子化され、命名規則があり、最新版が特定できるならデータ層は軽い。紙とPDFスキャンと複数バージョンが混在していると、ここが最大の費目になる
• 権限の複雑さ。全社員が同じものを見てよいなら簡単だが、部門別・工程別・客先別に分かれるほど設計と検証の工数が増える
• 既存システム連携の本数。生産管理、品質、設備、人事のうち何本と繋ぐか
• 利用人数と使用頻度。ここが継続費用のほぼすべてを決める

層別の費用構造をモデル試算で示す

具体的に示すため、架空のモデル拠点で試算します。前提はすべて明示するので、自社の数字に置き換えてください。前提は、チョンブリ県の日系製造拠点、従業員400名、AI利用対象者120名、対象業務3件、社内文書は主要なものが電子化済みで基幹システム1本と連携する、通貨はバーツとします。

表の合計を取ると、ハイブリッド型で対象業務3件を立ち上げる場合の初期費用はおよそ180万から470万バーツ、自社構築部分の年間運用費はおよそ100万から215万バーツの範囲に収まります。汎用SaaSのライセンス費は含みません。幅が2倍以上あるのは見積の甘さではなく、データ整備状態の差がそのまま出るためです。

同じ前提で3方式の3年総額を比べると、選択の意味が見えてきます。SaaS中心型は1ユーザーあたり月額1,000バーツと仮定します。

ハイブリッド型の年間運用費が高く見えるのは、SaaSのライセンス費が上乗せされるためです。内訳は、層別表の年間運用費である100万から215万バーツに、120名分のSaaSライセンス144万バーツを加えた金額です。ただしハイブリッド型では、自社設計の部分を必要な部門だけに絞り、汎用SaaSのライセンスも全社員ではなく必要な人数に絞れます。上表は最も保守的に、SaaSを120名全員に配る前提で置いています。

費用対効果を工数だけで語らない

3年で1,000万バーツ規模の投資を、時間削減額だけで正当化するのは困難です。同じモデル拠点で、AI活用によって文書探索と翻訳・要約にかかる時間が1人あたり週30分減ると仮定します。120名では週60時間、稼働48週として年間で約2,880時間。ホワイトカラーの時間単価を300バーツとすると年間864,000バーツで、3年で約259万バーツです。これだけでは足りません。

不足分を埋めるのは、時間ではなく判断の質に効く部分です。過去の類似不良を数分で引き当てられることによる不良再発の減少、客先規格の読み違いによる手戻りの防止、退職者の暗黙知が文書として残ることによる立ち上げ期間の短縮。これらは金額に置きにくいものの、製造拠点にとっては工数削減より重い効果です。逆に言えば、こうした効果が見込めない業務にAIを充てているなら、投資判断は成立しません。

社内データ生成AI活用が失敗する5つのパターン

社内データ生成AI活用の現場で繰り返し起きる失敗を、原因とともに整理します。産業向けAIのパイロットの約30%が最初の1件から広がらないという統計の実体は、おおむねこの5つに収まります。

パターン1 データ整備を「後でやる」に回す

最も多い失敗です。デモは動く。整理済みの十数件のPDFを読ませているからです。本番になると対象は数千から数万件に膨らみ、そのうち相当数が旧版のまま残り、スキャン画像で文字が取り出せないものが混じり、名前が同じで中身の違うファイルが並びます。

この状態でAIが返す答えは、正しい形式で間違った内容です。しかも間違い方が自然なため、現場は気づきません。データ層は最初に予算を確保すべき層であり、削ってよい層ではありません。

パターン2 権限をAIが素通りする

第1段階で触れた問題です。人事評価の下書き、原価の詳細、客先ごとの取引条件。これらが同じ文書置き場に入っていて、AIが全部読んで全員に答える。事故が起きてから権限を後付けすると、索引の作り直しになり、初期構築と同程度の工数がかかります。

パターン3 正解を誰も定義していない

「精度が悪い」という報告が上がるが、何をもって正しいかが決まっていない。開発側は「そういう質問は想定外です」と答え、現場は「使えない」と結論づける。第3段階で述べた問題集を先に作っておけば、この対立は起きません。精度は測定できる形にして初めて改善できます。

パターン4 現場が使わない

導入から3か月後、日常的に使っている人が一部の担当者しか残っていない状態です。原因は3つに絞られます。既存の業務動線から外れた場所に置かれていること、答えの信頼度が分からないこと、そして質問の仕方が分からないこと。

対策は、業務システムの中に埋め込むこと、答えに必ず根拠文書へのリンクを付けること、そして部門ごとに「よく使う質問文」を10個作って配ることです。特に3つ目は効果が大きく、自由入力欄だけを渡された利用者の多くは最初の1週間で離脱します。

パターン5 作った人がいなくなる

外部ベンダーに一任し、社内に仕組みを理解している人がいない状態です。あるいは推進していた駐在員が帰任し、後任が引き継げない。基盤モデルの更新や社内の組織変更に追随できなくなり、1年後には誰も更新しないまま形骸化します。

これは技術ではなく体制の問題です。社内側で仕様を理解し判断できる人材の確保についてはAI内製化支援の選び方で必要な役割と育成の進め方を整理しています。後から追加するのが最も難しいのが人であるため、構築プロジェクトの立ち上げと同時に体制の話を並行させてください。

ガバナンスとアクセス設計

権限はモデルではなくデータ側で持つ

社内AI構築で最も設計をやり直しにくいのがここです。「AIに聞かれたら答えない」という指示で制御しようとする設計は必ず抜けるため、利用者ごとに参照可能な範囲を先に絞り込み、その範囲の中だけでAIが答える構造にします。実装上の要点は3つです。

第一に、利用者の所属と役割を既存の認証基盤から引き継ぐこと。AI側で独自の利用者マスタを作ると、異動と退職に追随できなくなります。第二に、文書を索引化する時点で権限情報を一緒に持たせ、検索の段階で参照範囲を絞ること。第三に、ある利用者が何を参照できる状態かを管理者が画面で確認できるようにすること。確認できなければ、監査で説明できません。

ログは質問・根拠・回答の3点を紐付けて残す

利用ログには少なくとも、質問の内容、AIが参照した文書と該当箇所、そして返した回答の3つを紐付けて残します。3つが揃って初めて、なぜこの答えになったかを後から追えます。回答だけを残しても原因の切り分けができません。保管期間は社内の情報システム規程に合わせますが、少なくとも顧客監査の周期を1回またぐ長さは必要です。

なお社内の利用ルールは、禁止事項の羅列ではなく判断基準の形で書いてください。たとえば「客先から受領した図面と仕様書は、秘密保持契約で第三者提供が制限されている場合があるため、AIへの入力前に契約条項を確認する」というように、理由と確認先まで書いたルールだけが現場で守られます。

タイ拠点でのAI導入に固有の論点

駐在員と現地スタッフの二層構造をどう扱うか

タイの日系製造拠点でAIプロジェクトが停滞する典型的な理由は、技術ではなく体制です。意思決定は日本人駐在員が行い、実務は現地スタッフが担う。駐在員の任期は3年から5年で、プロジェクトの立ち上げと定着の期間とほぼ重なります。

現実的な対処は2つです。ひとつは、仕様と判断の根拠を必ず文書として残し、引き継ぎ可能な形にすること。もうひとつは、現地スタッフの中から推進役を早い段階で指名し、外部パートナーとの打ち合わせに最初から入れることです。駐在員が帰任した瞬間に止まるプロジェクトは、駐在員だけが窓口になっていたプロジェクトです。

言語の扱いも設計事項です。回答言語を日本語・英語・タイ語のどれで返すかを利用者ごとに切り替えられるようにし、根拠として提示する文書は原本の言語のまま示します。翻訳された根拠だけを示すと、原本との差異を確認できなくなります。

現地スタッフのAIリテラシーは教育ではなく設計で埋める

タイ現地スタッフのAI活用が進まない原因を「教育不足」と結論づける前に、入口の設計を見直す価値があります。多くの場合、問題は理解力ではなく、日々の業務画面から離れた場所にAIがあることと、タイ語での質問例が示されていないことです。よく使う質問文をタイ語で用意してボタンにする、日報の入力画面に要約ボタンを置く、回答の下に「原本を見る」リンクを必ず付ける。集合研修を1回やるより、この3つのほうが利用率に効きます。

PDPAとデータの所在

タイの個人情報保護法であるPDPAは、個人データの収集・利用・開示に法的根拠を求め、国外移転についても規律しています。社内AI構築で問題になりやすいのは、意図せず個人データが混ざるケースです。従業員の氏名が入った勤怠記録や教育記録、面談メモ、来訪者記録、そして客先担当者の氏名と連絡先が入ったメールや議事録。これらが文書置き場に同居していると、AIの参照対象に自動的に含まれます。

対処の順番は、まず対象データに個人データが含まれるかを棚卸しし、含まれるものについては利用目的と法的根拠を確認し、そのうえでAIの参照対象に入れるか除外するかを決めることです。除外する場合は、フォルダ単位で機械的に除外できる構造にしておくと運用が安定します。国外のクラウドで処理する構成を採る場合は、移転先と移転の根拠を記録に残してください。

なお、この判断は法務の領域にかかるため、自社の顧問弁護士または現地の法務アドバイザーの確認を経ることを前提としてください。

BOIの技術高度化支援を投資計画に織り込む

見落とされやすいのが、BOI(タイ投資委員会)の優遇措置です。既存のBOI奨励企業向けの技術高度化支援(Activity 10.1)では、要件を満たす技術高度化投資に対して法人所得税の免除が3年間追加されます。対象となるハードウェアにはサーバー、GPU、コンピュータビジョン用カメラ、IoTセンサー、エッジコンピューティング機器が明示的に含まれており、社内AI構築で自社環境に推論基盤を置く構成は、この枠に該当し得ます。

加えて、給与総額の1%から3%をAI関連の人材育成に投資する企業には、投資比率に応じて1年から3年の追加免除が認められます。EEC(東部経済回廊)に立地する製造業では、これらを組み合わせて最大15年の法人所得税免除に到達し得ます。要件を満たす機器については輸入関税の免除も適用されます。

実務上の含意は明確です。社内AI構築の方式を決める段階で、BOIの適用可能性を検討に入れると、内製型やハイブリッド型の実質的な投資額が変わります。SaaSのライセンス費は基本的にこの枠に乗りませんが、自社に置く基盤とその人材育成は乗り得る。方式選定の前に、自社のBOI奨励の状況と申請可能なタイミングを確認しておく価値があります。適用可否は個社の奨励条件と申請内容によって判断されるため、BOIまたは申請代行の専門家に事前確認してください。

AIシステム開発の発注先をどう選ぶか

AIシステム開発の委託先を選ぶとき、提案書のモデル名やアーキテクチャ図で比較しても差はつきません。2026年時点では、どのベンダーも大手の基盤モデルを使い、構成の教科書的な部分は似通っています。見るべきは次の4点です。

• 対象業務のドメインを理解しているか。製造現場の帳票、検査基準、客先要求の構造を知らない相手には、データ層の設計ができない
• データ整備の工数を見積に計上しているか。ここが薄い提案は、後から追加請求になるか、品質が出ないまま完成扱いになる
• 評価方法を提案に含んでいるか。何をもって完成とするかを、契約前に問題集の形で合意できる相手が望ましい
• 引き継ぎを前提にしているか。設計文書、権限の一覧、運用手順が納品物に入っているか

タイ国内で完結させるか日本の開発会社を使うかについては、一律の正解はありません。判断の軸は、現地スタッフとの打ち合わせをタイ語で行えるか、現地の基幹システムとネットワーク構成に触れられるか、そして障害発生時に現地時間で対応できるかです。現場データに触れる部分ほど、現地で動ける体制の価値が高くなります。

よくある質問

社内AI構築の費用はどれくらいかかりますか

作る範囲によって大きく変わります。本記事のモデル試算では、従業員400名・利用対象者120名・対象業務3件のハイブリッド型で、初期費用がおよそ180万から470万バーツ、自社構築部分の年間運用費がおよそ100万から215万バーツという範囲になりました。ここに汎用SaaSのライセンス費を加えると、年間運用費は約244万から359万バーツになります。幅が生じる最大の要因は社内データの整備状態です。すでに電子化され版管理されている企業と、紙とスキャンPDFと複数バージョンが混在している企業では、データ層の工数が3倍近く違います。まず対象業務を3件に絞り、その業務に必要な文書だけの整備状態を確認すれば、見積の幅は大きく縮まります。

内製とSaaSはどちらを選ぶべきですか

判断は「自社データをどこまで使うか」で決まります。汎用的な文章作成や翻訳が主目的で、自社固有の情報を参照する必要が薄いならSaaS中心型で十分です。逆に、部門ごとに閲覧権限が分かれた社内文書や、基幹システムの実績データを参照させたい場合は、SaaS単独では届きません。2026年時点でタイの日系製造拠点に最も多く当てはまるのは、汎用用途はSaaS、自社データを使う特定業務だけを自社設計で作るハイブリッド型です。方式の決定は、対象業務とデータの所在を棚卸しした後に行ってください。順番を逆にすると、決めた方式に業務を合わせる話になります。

社内データを生成AIに使うとき情報漏洩は防げますか

技術的には制御可能ですが、設計しなければ防げません。要点は3つあります。第一に、データが処理・保存される場所と、学習に使われない契約であることを文書で確認すること。第二に、権限をAI側の指示ではなくデータ側に持たせ、利用者ごとに参照範囲を絞ってから回答させること。第三に、誰が何を聞き、AIが何を参照したかのログを残すことです。逆に言えば、この3つが設計に入っていない構成は、どれほど堅牢なインフラを使っていても社内の情報統制としては不十分です。

タイ拠点だけで社内AI構築を進められますか

可能ですが、条件があります。ひとつは、日本本社の情報システム部門が定めるセキュリティ基準とデータ取り扱い規程を先に確認すること。後から本社の基準に抵触して作り直しになるケースが実際にあります。もうひとつは、現地に推進役を置くことです。駐在員のみが窓口の体制は、任期満了とともに止まります。現地スタッフを早期に巻き込み、仕様と判断の根拠を文書化しておけば、拠点主導での構築と運用は十分に成立します。

社内AI構築にBOIの優遇は使えますか

既存のBOI奨励企業であれば、技術高度化支援(Activity 10.1)の枠で法人所得税の追加免除を受けられる可能性があります。対象ハードウェアにはサーバー、GPU、IoTセンサー、エッジコンピューティング機器などが含まれ、自社環境に推論基盤を置く構成は該当し得ます。またAI関連の人材育成に給与総額の1%から3%を投じる場合、投資比率に応じた追加免除が認められます。EEC立地の製造業では組み合わせにより最大15年の免除に到達し得ます。ただし適用可否は個社の奨励条件と申請内容次第であるため、方式を決める前にBOIまたは申請代行の専門家へ確認してください。

まとめ

社内AI構築を成功させる企業と、パイロットで止まる企業を分けているのは、モデルの選択でも予算の額でもなく、決める順番です。業務を3件に絞り、データの所在と権限を棚卸しし、それから方式と予算を決める。この順番を守れば、方式の選択は自然に定まります。

内製・SaaS・ハイブリッドの比較で本当に問われているのは、自社データをどこまで仕組みの中に入れるかです。入れないなら汎用SaaSで十分であり、入れるなら権限とログとデータ整備に相応の予算が要ります。費用の大半が実行基盤ではなくデータ層と運用・ガバナンス層に発生することを、予算承認の前に社内で共有してください。層別に枠を分けて承認を取ることが、後半の痩せを防ぐ最も確実な方法です。

タイ拠点で進める場合は、駐在員の任期を跨ぐ引き継ぎ設計、現地スタッフを入口の設計で支える工夫、PDPAに照らした個人データの切り分け、そしてBOIの技術高度化支援を投資計画に織り込むことの4点が、日本国内の案件とは違う実務になります。とりわけBOIの適用可能性は、方式選定の前に確認しておけば実質的な投資額を左右します。

自社の業務のうちどれを最初の3件に選ぶべきか、既存の生産管理システムとどこまで繋ぐのが現実的か、本社のセキュリティ基準との整合をどう取るか。こうした論点は拠点ごとに事情が異なり、一般論では答えが出ません。TOMAS TECHはタイの日系製造業向けに生産管理と現場データ活用の仕組みづくりを支援しており、方式も予算も固まっていない検討初期の段階でのご相談も承っています。まずは現在の文書とシステムの状況を伺いながら、どこから着手するのが現実的かを一緒に整理するところからで構いません。ご相談はお問い合わせページからお気軽にどうぞ。

参考情報

• Artificial Intelligence Statistics for Industry — The ROI of Reliability in 2026 — 製造業のAI本番展開率、業種別の内訳、パイロットが拡大しない割合、初期実装での誤検知率、12か月以内のROI到達率
• Thailand Artificial Intelligence in Manufacturing Market — タイの製造業向けAI市場規模の推移予測と成長率
• Thailand BOI Manufacturing Funding and Incentives — BOI技術高度化支援(Activity 10.1)の対象設備、人材育成投資による追加免除、EECでの合算上限、輸入関税免除
• PDPC タイ個人情報保護委員会 — タイ個人情報保護法(PDPA)の所管当局と関連告示
• Thailand Board of Investment — 奨励措置の申請手続きと最新の対象活動一覧