LLM 導入2026｜タイ企業のRFP・TCO・運用設計

LLM 導入を、無料チャットの試用から社内業務へ進めるには、モデルの知名度よりも「どの業務を、どのデータ境界で、何を合格条件として運用するか」を先に決める必要があります。本稿では、タイの日系製造業・地域統括会社がRFPを作り、既製SaaS、API＋RAG、AIエージェントを同じ評価セットで比べ、90日で投資判断する方法を実務順に整理します。

LLM活用企業が増えても、本番導入が難しい理由

Stanford HAIのAI Index Report 2026によると、2025年の調査対象組織の88%がAIを利用し、70%が少なくとも1つの業務機能で生成AIを利用しています。一方、AIエージェントの導入率は、ほぼすべての業務機能で一桁台にとどまります。この差は「触ったことがある」と「責任を持って業務を任せられる」の間に、データ、権限、評価、監視、教育という運用上の壁があることを示します。

チャットの試用では、利用者が回答を読み、誤りを補正し、必要ならやり直せます。本番システムでは、入力される情報の機密度、参照できる文書、外部ツールへ実行できる操作、誤答時の影響、ログ保存、障害対応まで企業側が定義しなければなりません。したがって、LLMは単体のソフトウェア部品ではなく、業務手順と統制を含むサービスとして調達するのが現実的です。

Responsible AIの課題も同じ方向を示します。AI Index 2026のResponsible AI章では、2025年に記録されたAIインシデントは362件で、2024年の233件から増加しました。また、Responsible AIを進める主な障害として、知識不足59%、予算制約48%、規制の不確実性41%が挙げられています。これらは特定企業の事故率や将来予測ではありませんが、モデル精度だけを購入しても、安全な運用能力が自動的についてくるわけではないことを示す材料です。

経営判断では、次の三つを分けると議論が明確になります。

• 利用の広がり：従業員が生成AIを使えるか
• 業務価値：時間、品質、売上、リスクのどれが改善するか
• 本番運用能力：データ、権限、評価、監視、変更を管理できるか

利用率の高さだけを投資理由にせず、業務価値と運用能力を同じ稟議に載せることが、PoC止まりを避ける第一歩です。

LLM導入を「モデル選定」ではなく「運用契約」として設計する

導入計画の中心は、特定のモデル名ではありません。業務オーナー、IT、法務・コンプライアンス、情報セキュリティ、現場利用者、導入支援会社の間で、次の内容を一つの運用契約として合意します。

1. 対象業務と対象外業務
2. 入力できるデータと禁止データ
3. 期待する出力、許容できる失敗、重大な失敗
4. 人間が確認する地点と最終責任者
5. モデル、検索基盤、外部ツールの権限
6. 品質、安全、時間、コストの受入基準
7. ログ、監視、インシデント対応、再教育
8. モデル更新、切替、契約終了時のデータ処理

NIST AI 600-1は、AI RMF 1.0を生成AI向けに具体化し、設計・開発・利用・評価のライフサイクル全体へ信頼性とリスク管理を組み込む任意利用の枠組みです。チェックリストを一度埋めて終わるものではなく、運用中の変更を含めて繰り返し管理する考え方としてRFPに使えます。

また、NIST SP 800-218Aの発表は、AIモデル提供者、AIシステム開発者、AIシステム調達者を対象に、生成AI固有の安全な開発実務をSSDFへ追加しています。買い手も対象である点が重要です。調達者は「安全な製品ですか」と尋ねるだけでなく、サプライチェーン、構成変更、評価証跡、脆弱性対応を契約可能な回答に変える必要があります。

3方式を同じ評価セットで比較する

LLM活用企業が検討しやすい方式は、大きく既製SaaS、API＋RAG、AIエージェントの三つです。優劣は固定されず、業務とデータ境界によって変わります。90日PoCではモデル名を固定せず、代表タスクと受入基準を共通化して比較します。

既製SaaSは、議事録、文書作成、一般的な検索など、業務を製品標準へ合わせられる場合に有力です。API＋RAGは、社内規程、技術文書、品質記録など、回答根拠と閲覧権限が重要な用途に向きます。RAGの設計を先に深掘りしたい場合は、タイ企業向けRAG導入の実務ガイドも参照してください。

AIエージェント導入は、問い合わせの分類、情報収集、下書き作成、ERPへの登録候補作成など、複数ステップをつなぐ用途に可能性があります。しかし、自動化範囲が広いほど、過剰な権限、誤った外部実行、同じ処理の重複、途中失敗からの復旧が課題になります。最初から完全自律を目標にせず、「提案だけ」「下書きまで」「人間承認後に実行」と権限段階を分けるのが安全です。

90日PoC：12週間で投資判断まで進める

PoCの目的は、見栄えの良いデモを作ることではなく、本番移行に必要な不確実性を減らすことです。対象業務を一つか二つに絞り、0〜12週を四段階に分けます。

0〜2週：業務棚卸しと評価セットを固定する

最初に、現行業務の件数、所要時間、再作業、エスカレーション、ミスの影響を把握します。LLM導入前のベースラインがなければ、導入後の「速くなった」という感想を投資効果へ変換できません。

代表タスクは20〜50件を目安とし、簡単な例だけでなく、曖昧な依頼、古い文書、矛盾する資料、タイ語と日本語が混在する入力、回答不能な質問を含めます。この20〜50件は製品性能の一般保証値ではなく、今回のPoC用評価セットの設計範囲です。各タスクに期待結果、利用可能な根拠、許容差、重大失敗、採点者を付けます。

同時に、個人情報、顧客秘密、製造条件、価格、図面、人事情報などを分類し、入力禁止、匿名化後のみ、承認済み環境のみ、という境界を決めます。業務オーナー、データオーナー、セキュリティ責任者、最終承認者もこの段階で固定します。

3〜6週：SaaS、API＋RAG、エージェントを同条件で比べる

候補方式へ同じ代表タスクを投入し、日本語、タイ語、英語を別々に採点します。平均点だけではなく、失敗を「根拠なし」「古い情報」「指示違反」「権限外参照」「翻訳で条件消失」「処理中断」などに分類してください。

API＋RAGでは、モデルの回答品質と検索品質を分けて測ります。正しい文書が検索されていないのか、正しい文書があっても回答を誤ったのかで、対策が異なるからです。エージェントでは、最終結果だけでなく、計画、ツール選択、パラメータ、停止判断、再試行を記録します。

この期間は、モデル名を調達条件として固定しすぎないことも重要です。同一評価セットで複数モデルや設定を入れ替えられる構成なら、価格改定、提供終了、品質変化、データ条件変更に対応できます。

7〜10週：実データ境界と攻撃・失敗を試す

承認した範囲の実データを使い、利用者の権限が検索結果へ正しく反映されるか、監査ログに誰が何を入力し何を参照したか残るか、根拠を提示できるか、答えるべきでない質問を拒否できるかを確認します。

OWASP GenAI LLM Top 10 2026は2026年8月4日に公開された現行版として、LLMアプリケーションの重大なセキュリティ脅威を整理しています。RFPでは特定の脆弱性名を並べるだけでなく、プロンプトインジェクション、機密情報の扱い、過剰な権限、外部ツール実行など、自社構成に関係する脅威をテストケースへ変換します。

たとえば、検索対象文書に「以前の指示を無視せよ」という文章が混入した場合、未承認の文書を根拠に回答しないか。メール下書きエージェントへ不正なリンクが渡った場合、資格情報を送らないか。購買登録候補を作るエージェントが承認なしに確定処理を実行しないか。こうした失敗を安全に再現し、拒否、人間承認、権限縮小、フォールバックが機能するかを確かめます。

11〜12週：受入判定と横展開ゲートを決める

最後に、品質、安全、時間、コストを同時に評価します。KPI候補は、タスク成功率、重大誤答率、根拠提示率、再作業率、処理時間、1件当たり推論費、タイ語と日本語の品質差、権限逸脱件数、監査ログ欠損件数です。権限逸脱と監査ログ欠損についてはPoCの受入条件を0件とし、それ以外の数値目標は業務影響と現行ベースラインから企業自身が設定します。一般的な保証値を転記してはいけません。

受入結果は「本番化」「条件付き継続」「用途縮小」「中止」のいずれかに分けます。本番化の場合も、対象部門、利用人数、データ種別、月間処理量に上限を置き、次の拡大条件を明記します。条件付き継続では、未達KPI、改善担当、期限、再試験方法を残します。

RFPに入れるべき質問と提出物

良いRFPは、機能一覧に丸を付けてもらう文書ではなく、同じ条件で候補を比較できる文書です。回答を「対応可能」で終わらせず、設定画面、設計書、ログ例、試験結果、契約条項などの証跡を要求します。

業務価値と責任分界

• 対象業務のどの工程を置き換え、どこを支援するか
• 誤答や未処理が起きたとき、誰が検知し、誰が復旧するか
• ベンダー、導入支援会社、顧客の責任範囲はどこか
• 人間承認を迂回できない仕組みになっているか
• SLAの対象、除外、計測地点、報告頻度は何か

モデル、評価、変更管理

• 利用モデル、リージョン、バージョン、切替条件は何か
• モデル更新を事前通知し、同一評価セットで回帰試験できるか
• プロンプト、検索索引、ツール定義、ポリシーの変更履歴を残せるか
• 評価データと結果を顧客が持ち出せるか
• 品質低下時に旧構成へ戻す手順と所要条件は何か

データ境界とサプライチェーン

• 入力、出力、埋め込み、ログ、バックアップはどこに保存されるか
• 保存期間、削除方法、削除証明、再委託先はどう定義されるか
• 顧客データを学習、製品改善、人手レビューに使う条件は何か
• 外部モデル、検索基盤、監視、翻訳などの依存先は何か
• 契約終了時にデータ、索引、評価セット、設定を返却できるか

OpenAIをベンダー例として見ると、企業向けデータ方針ではBusiness、Enterprise、Edu、APIの入出力を既定でモデル訓練に使わないと説明しています。また、2026年8月19日のZero Data Retention更新では、適格なAPI顧客向けに、リクエスト処理後のプロンプトと応答を保持しないZDRを説明しています。これはOpenAI固有の条件であり、他社、すべてのプラン、すべてのエンドポイントへ一般化できません。RFPでは、対象機能、例外、保持される運用メタデータ、適格条件を個別に契約確認してください。

セキュリティと運用

• SSO、多要素認証、役割、最小権限、緊急停止をどう実装するか
• プロンプトインジェクションやデータ流出をどう試験するか
• 外部ツールの読取、作成、更新、削除、承認を分離できるか
• 監査ログに入力、参照元、出力、実行、承認、エラーが残るか
• インシデント通知、初動、証拠保全、再発防止の期限は何か

RFPの回答は、PoCの受入試験へ直接つなげます。「ログを提供可能」という回答なら、実際に要求した項目が欠損なく出力されるかを試験します。「モデル切替可能」という回答なら、設定変更後に同じ評価セットを実行し、品質とコストの差を確認します。

12か月TCOを、差し替え可能な式で比較する

以下は市場相場でもTOMAS TECHの見積実績でもなく、計算方法を示すための架空の設計例です。実際の判断では、対象業務、処理量、既存契約、データ整備、セキュリティ要件、サポート範囲に合わせてすべて差し替えてください。生成AI導入費用の分解方法は、タイ企業向け生成AI導入コストの解説でも整理しています。

架空の費用条件

価値側も架空の入力値で計算します。

240人 × 0.5時間/日 × 220日 × 450THB/時間 × 実現率45% = 534.6万THB/年

この例の1年純便益は、534.6万THB－432万THB＝102.6万THBです。定常月の便益は44.55万THB、定常月の差引便益は44.55万THB－16万THB＝28.55万THBとなります。初期費240万THBを28.55万THBで割ると単純回収期間は約8.4か月です。ただし、立ち上がり遅延、税、資本コストは含みません。

ここで最も重要な変数は実現率です。実現率を30%とすると価値は356.4万THBとなり、1年純便益は356.4万THB－432万THB＝マイナス75.6万THBです。したがって45%を保証値として提案書に置くのではなく、PoCで測る仮説にします。

価値の検証では、削減可能時間と削減した時間を混同しないでください。回答作成が30分短くなっても、その時間が待ち時間になっただけなら財務価値は限定的です。処理件数の増加、残業削減、外注費削減、リードタイム短縮、ミス回避など、実際に取得できる価値へ変換します。費用側にはモデル利用料だけでなく、データ整備、評価、監視、問い合わせ対応、変更管理、教育、インシデント対応、終了時の移行も含めます。

社内データを生成AIで使う際のデータ境界とPDPA

社内データ 生成AI 活用では、「クラウドかオンプレミスか」だけでは境界を説明できません。入力から削除までのデータフローを描き、少なくとも入力、プロンプト構成、検索、埋め込み、推論、出力、ログ、監視、バックアップ、人手サポートを分けて確認します。

タイ拠点では、PDPA上の役割と処理目的、必要性、保持期間、アクセス、越境、委託先・再委託先を法務・個人情報担当と確認します。本稿は法的助言ではありません。重要なのは、ベンダーの一般的な説明だけで判断せず、自社のデータ種別と実際の構成に基づいて確認記録を残すことです。

ETDAの2026年方針では、Thailand AI Governanceとして12セットのガイドライン／ツールキットを利用可能とし、2026年にAI Ethical Impact Assessment PlaybookとAI Value Creationを追加開発し、AI Red Teaming Challengeも推進すると説明しています。これは「規制が完全に確定するまで停止する」のではなく、価値評価と統制の整備を並行させる背景になります。

また、ETDAのGenerative AI Governance Guideline for Organizationsはタイ語原典で、組織目標、リスク、個人情報、機密情報、法令順守を含め、責任ある利用を設計する指針です。RFPのデータ質問、利用規程、承認手順、教育計画をタイの組織文脈へ合わせる際の参照点にできます。

データ分類は、次のように実行可能なルールへ落とします。

• 公開情報：承認済み環境で利用可能
• 社内一般：社内アカウント、保存条件、ログ条件を満たす場合のみ
• 機密：用途、利用者、検索対象を限定し、出力の持ち出しも統制
• 個人情報：処理目的、必要性、通知・同意等の適法性、保持、越境を確認
• 高機密・禁止：入力不可。自動検知と利用者教育を併用

RAGを使っても、データ境界が自動的に安全になるわけではありません。索引へ登録した時点で閲覧権限が失われたり、退職者の権限が残ったり、古い版が上位表示されたりする可能性があります。原文のアクセス権を検索時に継承し、文書オーナー、版、有効日、廃止状態をメタデータとして管理する必要があります。

AIエージェント導入のセキュリティは「行動」を制御する

通常のチャットは不適切な回答が主なリスクですが、AIエージェントはメール送信、ファイル作成、チケット更新、ERP登録などを行えるため、誤った行動の影響が大きくなります。業務自動化 AIの設計では、データへの読取権限と、外部システムへの実行権限を分離します。

最初の段階では、エージェントが作るのは提案や下書きだけにします。次に、人間が承認した一件だけを実行できる段階へ進めます。十分な評価と監視を経てから、低リスクかつ取り消し可能な操作に限定して自動実行を検討します。削除、送金、価格確定、人事判断、設備停止など影響の大きい操作は、技術的に可能でも別の承認経路を維持します。

安全設計の要点は次の通りです。

• 各ツールに最小権限の専用資格情報を割り当てる
• 読取、作成、更新、承認、削除を別権限にする
• 操作対象、金額、件数、時間帯に上限を設ける
• 同じ要求の重複実行を防ぐ識別子を持つ
• 途中失敗時の再開地点と補償処理を決める
• 入力、判断、参照、実行、承認を監査ログへ残す
• 異常時に人間へ切り替え、資格情報を即時失効できるようにする

セキュリティ試験は、正常系のデモ後に付け足すものではありません。代表タスクへ攻撃的入力や権限外要求を混ぜ、拒否が業務を不必要に止めすぎないかも評価します。安全性と利用可能性の両方を測ることで、現場が統制を回避して未承認ツールへ流れるリスクも抑えられます。

日本語・タイ語・英語を別採点する

タイの日系企業では、経営資料は日本語、現場記録はタイ語、規格や製品資料は英語という状況が珍しくありません。三言語の平均点を一つにまとめると、特定言語で条件や否定表現が抜ける問題を見落とします。

評価セットには、同じ意味の三言語版だけでなく、実際の混在文書を含めます。たとえば、タイ語の不具合報告、日本語の品質基準、英語の装置マニュアルを参照して回答する課題です。採点では、固有名詞、単位、日付、数量、否定、例外、責任者、出典を個別に確認します。翻訳の流暢さだけでなく、業務条件が保持されているかが重要です。

タイ語では分かち書きや表記ゆれ、日本語では略語や主語省略、英語では規格用語と社内用語の差が検索結果へ影響します。検索クエリの拡張、用語集、同義語、文書メタデータを言語別に設計し、言語ごとの根拠提示率と重大誤答率を見ます。

利用画面や教育もローカライズします。禁止事項を英語だけで掲示しても、利用者がタイ語で作業するなら統制は機能しません。利用規程、警告、承認画面、問い合わせ窓口、インシデント報告を利用者の言語で提供し、意味の一致を確認します。

本番運用：モデル切替と継続改善を前提にする

本番開始はプロジェクトの終了ではなく、評価サイクルの開始です。モデル、価格、利用条件、社内文書、業務手順、攻撃手法は変わります。月次または重要変更時に、固定した評価セットと新しい失敗事例を使って回帰試験します。

ISO/IEC 42001:2023は、AIマネジメントシステムを確立、実施、維持、継続改善する要求事項を定める世界初のAIマネジメントシステム規格です。PDCA型で運用を整える基盤になりますが、個別法令の代替ではありません。認証取得の有無だけを評価するのではなく、責任、リスク評価、変更管理、監視、改善が実際の業務に接続しているかを確認します。

運用台帳には、用途、業務オーナー、利用モデル、データ区分、外部連携、受入基準、最終評価日、既知の制約、停止条件を記録します。モデルや検索構成を変更したら、変更前後の評価結果、費用、応答時間、リスクを残します。

切替可能性は、契約文言だけでは確認できません。PoC中に少なくとも一度、候補モデルを切り替え、代表タスクを再実行し、プロンプト、出力形式、ツール呼び出し、RAG、監視への影響を測ります。データや評価セットを顧客が保持し、API境界を明確にし、業務ロジックを一つのモデル固有機能へ埋め込みすぎないことが移行費を抑えます。

内製チームと外部支援の役割を検討する場合は、タイでのAI内製化支援ガイドも参考になります。社内には業務判断、データ責任、受入基準を残し、外部には設計、実装、専門試験、教育などを明確な成果物で依頼するのが基本です。

FAQ

LLM導入の費用は？

ライセンスやAPI利用料だけでなく、業務設計、データ整備、接続、権限、評価、セキュリティ試験、監視、教育、改善、サポート、契約終了時の移行まで含めて12か月TCOで比較します。本稿の432万THBは市場相場ではなく、初期240万THBと月次16万THBを置いた架空の計算例です。実際の費用は対象業務、処理量、データ条件、統合範囲、SLAによって変わるため、RFPで同一条件の内訳を求めてください。

LLM活用企業は何から始める？

最初に製品を契約するのではなく、改善したい業務を一つか二つ選び、現状の時間、件数、再作業、ミス影響を測ります。次に代表タスク20〜50件、禁止データ、失敗分類、責任者を決め、既製SaaS、API＋RAG、エージェントを同じ評価セットで比較します。20〜50件は一般的な保証値ではなく、90日PoCの設計目安です。

AIエージェント導入とRAGはどう違う？

RAGは、社内文書などを検索して関連情報をモデルへ渡し、回答の根拠と鮮度を高める構成です。AIエージェントは、目標に応じて複数ステップを計画し、検索に加えて外部ツールを使う構成を含みます。RAGはエージェントの一部にもなります。外部操作が増えるほど権限、承認、重複防止、復旧、監査の設計が重要です。

社内データを生成AIで使う際の注意点は？

データの入力先だけでなく、検索索引、埋め込み、ログ、バックアップ、人手サポート、再委託先、越境、保持、削除まで確認します。原文のアクセス権を検索へ継承し、個人情報や機密情報の利用目的と必要性を記録してください。「学習に使わない」という説明だけで、保存や人手アクセスまで否定されたとは限らないため、対象機能と契約条件を個別に確認します。

まとめ：買うべきものはモデルではなく、測定可能な運用能力

LLM導入の成否は、最も賢いモデルを当てることでは決まりません。対象業務、データ境界、三言語の評価セット、人間承認、セキュリティ試験、12か月TCO、変更管理、終了条件を一つの運用契約へまとめ、90日で測定可能な判断材料を作ることが重要です。SaaS、API＋RAG、AIエージェントを同条件で比較し、価値とリスクの両方が受入基準を満たした範囲だけを本番化すれば、試用から持続可能な業務改善へ進めます。

タイ拠点でのRFP作成、評価セット設計、社内データ境界、90日PoCの進め方を整理したい段階でも、TOMAS TECHへご相談いただけます。特定モデルを前提にせず、対象業務と受入条件から比較可能な計画づくりを支援します。