AIエージェント導入2026｜PoC止まりの88%と何が違うのか

PoCは動いた、だが本番には行かない。AIエージェント導入で最も多い結末である。Anaconda／Forresterの調査では、エージェントのPoCの88%が本番に到達しない。原因はモデル選定でもツール選定でもなく、権限・データ範囲・監視・オーナーシップの4点を「試す前」に決めていないことにある。本記事では在タイ日系製造業を前提に、導入前に決める4つの設計、費用の内訳、90日の進め方までを整理する。

AIエージェント導入が「PoC止まり」で終わる構造

社内で誰かが試し、経営会議で議題に上がり、ベンダーからの提案も届く。ところが実際に本番運用まで到達している企業はごく一部である。まずこの落差の実態を数字で押さえる。

88%が本番に到達しない

Anaconda／Forresterの調査によれば、エージェントのPoCの88%が本番に到達しない。この数字はa16zやMIT SloanのCIOパネルでも同様の水準が再現されている。Gartnerはさらに厳しく、89%がPoC止まりだとする。調査主体も対象も異なるが、いずれも「9割近くが本番に行かない」という同じ結論に収束している。

同調査では、本番到達を阻む要因も特定されている。

注目すべきは、上位2つがモデルの性能とは無関係だという点である。評価基準の不備もガバナンス摩擦も、技術ではなく「決めていないこと」に起因する。3位のモデルの信頼性ですら、「どの水準なら合格か」を先に決めていれば評価基準の問題に還元される。つまり88%という数字は、モデルが未熟だから生じているのではなく、試す前に決めるべきことを決めずに試したから生じている。これが本記事の背骨である。

78%がPoCを持ち、14%しか全社運用に届かない

Digital Appliedが2026年3月に公表した調査（企業技術リーダー650名、2〜3月実施）は、この構造をさらに具体的に示している。

• 78%の企業が最低1つのPoCを保有している
• しかし14%のみが全社規模の本番運用に到達している
• PoC保有企業の64%が拡大を試みて6か月以上停滞している
• 停滞までの平均PoC期間は4.7か月

78%と14%の差、つまり64ポイントの落差がそのまま「スケールギャップ」である。重要なのは、64%が「失敗した」のではなく「停滞した」と表現されている点だ。動くものはできている。だが広げようとした瞬間に、PoCでは問われなかった論点が一斉に噴出する。

平均4.7か月という数字も示唆的である。半年弱かけてPoCを回し、拡大に着手し、さらに6か月以上動かない。合計すると1年近くが経過する計算になる。この期間、投じた人件費とライセンス費は回収されない。

業種で3倍近い差が出ている

同じ調査の業種別の本番到達率も見ておきたい。

直感的には「規制が厳しい業界ほど進まない」と考えたくなるが、金融は規制が最も厳しい業界の一つでありながら到達率が最も高い。

この逆転の読み方はこうである。規制の厳しい業界は、新しい仕組みを入れるときに「誰が承認し、何を記録し、どこまでを機械に任せるか」を決める手続きが既に存在する。監査対応も権限管理もログ保全も業務プロセスとして確立しているため、エージェントという新しい対象が来ても既存の枠組みに乗せられる。逆に、そうした手続きが無い組織ではゼロから議論することになる。決めるべきことのリストすら手元に無いため、議論は発散し、承認は下りない。ガバナンスは導入の障害ではなく、むしろ導入の速度を上げる装置なのである。

失敗の埋没コストは平均210万USD

Fortune 1000企業における失敗したエージェント案件の平均埋没コストは約210万USDとされる。もちろんこれは大企業の数字であり、タイの日系拠点でそのまま当てはまるものではない。しかし構成要素を分解すると、規模が違っても同じ費目が発生していることが分かる。

• ライセンス・API利用料（PoC期間中も課金は続く）
• 外部ベンダーへの委託費
• 社内の人件費（プロジェクトメンバーの工数）
• 連携開発（既存システムとつなぐための開発）
• データ整備（学習・参照させるためのドキュメント整理）

このうち最後の2つは、PoCが中止になっても資産として残る可能性がある。既存システムのAPI整備や社内ドキュメントの構造化は、エージェントを使わなくても価値がある。逆に言えば、埋没コストの大半を占めるのはライセンスと人件費であり、これは時間とともに単調に増えていく。停滞を6か月放置することのコストは想像以上に大きい。この構造を断ち切る唯一の方法が、PoC開始前に判断基準を決めておくことである。

「使えるか試す」から入ると必ず止まる

多くのプロジェクトは「まず使えるか試してみよう」から始まる。健全な出発点に見えるが、この入り方には構造的な欠陥が4つある。

第一に、合格ラインが無い。「使える」の定義が無いまま試すと、デモが動いた時点で満足するか、いつまでも「まだ精度が足りない」と言い続けるかのどちらかになる。前者は本番で破綻し、後者は永久に本番に行かない。

第二に、権限の議論が後回しになる。PoCでは担当者が自分のアカウントで動かすため、権限の問題が表面化しない。本番に移そうとして初めて「誰の権限で基幹システムを読むのか」という問いが現れ、そこで止まる。

第三に、データの範囲が曖昧なまま拡大する。本番では「どのフォルダまで読ませてよいか」「客先の図面は含めてよいか」を決めなければならない。この線引きは技術ではなく経営判断であり、決裁に時間がかかる。

第四に、誰の仕組みなのかが決まっていない。出力がおかしいとき誰が直すのか、業務が変わったとき誰が更新するのか。ここが空白だと、稼働直後から劣化が始まる。

この4つが、後段で扱う「権限・データ範囲・監視・オーナーシップ」に対応する。88%が止まる場所は、ほぼこの4か所に集約される。

62%が実験中、23%しかスケールしない｜日本とタイの現在地

前章は調査ベースの一般論だった。ここからは、日本企業とタイ拠点が実際にどの位置にいるのかを数字で確認する。自社の現在地を測る物差しとして使ってほしい。

McKinsey：62%が実験段階、23%がスケール

McKinseyの”The State of AI”（2025年11月版）では、62%の組織がAIエージェントの実験段階にある一方、全社で少なくとも1業務のスケール運用に到達しているのは23%にとどまる。

この62%と23%という組み合わせは、前章の78%と14%と構造的に同じである。調査対象も定義も異なるため単純比較はできないが、「試している企業は多数派、回している企業は少数派」という構図は複数の調査で一致している。

押さえておきたいのは、23%が「1業務でもスケールしていれば該当」という緩い基準である点だ。つまり2026年時点では、1つの業務でエージェントを安定運用できているだけで上位2割に入る。裏を返せば、大規模な全社展開を最初から狙う必要はない。1業務を確実に回すことが、そのまま競争上の位置につながる。

日本の生成AI業務利用率は55.2%

総務省の令和7年版情報通信白書によれば、生成AIの業務利用率は次の通りである。

日本だけが40ポイント近く低い。少なくとも「日本企業では、生成AIを業務で使うこと自体がまだ当たり前になっていない」ことは読み取れる。

この前提は重要である。エージェントは生成AIの上位レイヤーにある。人が指示を出す生成AI利用が定着していない組織に、自律的に判断して動くエージェントを入れるのは段差が大きい。まず特定業務での生成AI利用を定着させ、その業務の中で「人が毎回同じ判断をしている部分」をエージェントに委ねるほうが現実的である。

期待を大きく上回った日本企業は23%

PwC Japanの生成AI実態調査2025春では、生成AIの成果が「期待を大きく上回る」と回答した日本企業は23%である。

この数字は成果が出ていないという意味ではない。問題は残りの77%がどこに分布するかであり、それは導入時に置いた期待値の設定に大きく依存する。期待値を「業務が丸ごと自動化される」に置けばほぼ確実に下回る。「特定作業の所要時間が3割減る」に置けば達成可能な範囲に入る。期待値の設定は精神論ではなく、評価基準の設計そのものである。前章の「評価基準の不備64%」は、ここに直結している。

AI利用ポリシーの策定率は大企業50%、中小企業30%

日本企業のAI利用ポリシー策定率は、大企業で約50%、中小企業で約30%である。

つまり大企業でも半数はポリシーが無い状態でAIを使っている。「何を入力してよいか」「出力をどこまで信用してよいか」「誰が責任を持つか」が文書化されていないということだ。個人がチャットで使う段階なら、それでも大きな事故には至りにくい。

しかしエージェントは違う。エージェントは人が見ていない場所で、システムに対して読み書きを実行する。ポリシーが無い状態でこれを本番に入れると、事故が起きたときに「誰がどこまで許可したのか」を遡れない。ガバナンス摩擦57%という数字は、この不在が本番移行の直前で顕在化した結果である。

在タイ拠点の場合、さらに論点が増える。本社の日本語ポリシーがタイ拠点に適用されるのか、ローカルスタッフが読める言語で提供されているのか、タイの個人情報保護法（PDPA）との関係をどう整理するのか。ポリシーが日本語版しか無い拠点は珍しくないが、それは実質的にローカルスタッフには存在しないのと同じである。

市場は2026年に78億USD、企業アプリの40%に組み込まれる

供給側の動きも押さえておく。

• AIエージェントの市場規模は2026年に78億USD（前年比+50%）
• Gartnerの予測では、2026年末までに企業アプリケーションの40%がAIエージェントを組み込む

後者が実務上は重要である。エージェントは「導入するかどうか」を選ぶものから、使っている業務アプリの中に勝手に入ってくるものへ変わりつつある。生産管理、会計、グループウェア、CRM。これらのアップデートでエージェント機能が有効化される場面が増える。つまり権限とデータ範囲の設計を先送りできなくなる。自社で構築しなくても、既存アプリに組み込まれたエージェントが社内データを読むからである。

エージェント技術そのものの動向や、製造業での適用可能性の広がりについてはAIエージェント最新動向2026で整理している。本記事は「実際に入れるときに何を決めるか」に絞るため、技術動向の解説は繰り返さない。

タイ拠点特有のギャップ｜組織10.7%と従業員72%

ここからが本記事の核心の一つである。タイには、日本や欧米とは異なる特有の構造がある。この構造を理解しないまま日本本社の導入計画をそのまま持ち込むと、進まないか、逆に管理不能な状態になる。

組織10.7%、従業員個人72%という逆転

タイの数字を並べると、明確な断層が見える。

組織としての導入率は10.7%にすぎない。シンガポールの69%とは6倍以上の差があり、ベトナムの23%と比べても半分以下である。ところが、従業員個人の72%が業務で何らかのAIを使っている。この差は、組織の承認を経ていないAI利用が広く行われていることを意味する。

Microsoft Work Trend Index 2026も同じ構図を報告している。タイの労働者はAI活用で地域を先行しており、組織側が遅れている。現場が先に走り、会社が追いついていないのがタイの実像である。

この構造が生む3つのリスク

個人利用の先行それ自体は悪いことではない。むしろ新しい道具への適応が速いことは強みである。問題は、組織が把握していない状態が続くことにある。

第一に、情報の流出経路が見えない。従業員が個人アカウントの生成AIに、図面の寸法、客先の品番、原価情報、不具合報告を貼り付けている可能性がある。悪意ではなく、単に速く仕事を終わらせたいからだ。組織側にポリシーも代替手段も無ければ、この流れは止まらない。

第二に、出力の品質が誰にも検証されていない。個人が使っている限り、正しいかを確認するのは本人だけである。タイの調査では、61%の企業が「AI出力を解釈・検証・反証できる力」を今後の重要スキルに挙げている。裏を返せば、現時点ではその力が十分でないという認識が広くあるということだ。検証されない出力が報告書や客先回答に混ざる状態は、静かに進行する品質リスクである。

第三に、業務が属人化する。個人がAIを使って効率化した業務は、その個人の手元にノウハウが溜まる。プロンプトも確認の勘所も共有されない。その人が異動・退職した瞬間に業務は元の速度に戻り、組織の生産性としては何も積み上がらない。

タイのデジタル成熟度は2.12／4.0

タイ企業のデジタル成熟度は、平均で2.12／4.0である。2025年の1.56から上昇しており、方向としては前進している。

4段階の中間をわずかに超えた水準である。基盤となる業務システムがある程度デジタル化されている一方、データが横につながって意思決定に使われる段階には達していない組織が多数派だと解釈できる。

これはエージェント導入にとって重大な前提である。エージェントは判断材料になるデータにアクセスできて初めて価値を出す。在庫、生産計画、工程の進捗が紙やExcelに分散している状態では、与えられる材料が無い。

成熟度2.12という平均値は、「エージェント以前にデータ基盤の整備が必要な拠点が相当数ある」ことを示している。ここを飛ばしてエージェントの検討に入ると、PoCの段階で「読ませるデータが無い」という壁に当たる。前章の阻害要因にあった「ドメイン学習データ不足41%」は、まさにこの状態である。

在タイ日系製造業に固有の3つの論点

上記に加えて、日系拠点には固有の事情がある。

論点1：本社と拠点の意思決定の分断

AI関連の方針は本社のIT部門やDX推進部門が策定することが多い。一方、タイ拠点の業務実態は本社からは見えにくい。結果として、本社が承認したツールが現場の業務に合わず、現場は別の手段を使う。ポリシーは形骸化する。

対策は、拠点側が「どの業務にどう使うか」を先に具体化して本社に提示することである。「AI活用を進めたい」では本社の判断材料にならない。「納期回答業務で1日50件の照会に平均12分かかっている」まで落とすと議論が進む。

論点2：言語が3層に分かれている

タイの日系工場では、日本人管理者が日本語、ローカルスタッフがタイ語、客先や本社報告が英語という3層構造が一般的であり、エージェントが扱うドキュメントもこの3言語が混在する。

問題になるのは、同じ内容の文書が3言語で存在し、更新のタイミングがずれることだ。日本語の作業標準が改訂されたのにタイ語版が古いまま、という状態は珍しくない。参照元の優先順位を明示的に決めておかないと、出力が安定しない。

論点3：人員の入れ替わりを前提にした設計が要る

タイの製造現場では人員の入れ替わりが一定程度発生する。導入時に教育した人が1年後にいない可能性を前提にする必要がある。エージェントを使いこなすには「どう指示すれば意図した出力が得られるか」の勘所がいるが、これが個人に留まっていると担当が変わった瞬間に活用度が落ちる。指示の型をテンプレートとして残し、タイ語で手順化しておくことが定着の条件になる。

個人利用の先行を組織の資産に変える

タイの構造を悲観的に捉える必要はない。従業員の72%が既にAIを使っているという事実は、導入の抵抗が小さいことを意味する。日本本社で「AIを使ってみましょう」と呼びかけても反応が鈍い一方、タイ拠点では既に使っている人が多数派なのである。

必要なのは禁止ではなく、受け皿の提供である。具体的には次の順序が現実的だ。

1. 実態を把握する：誰がどの業務でどのツールを使っているかを、罰則抜きで聞き取る
2. 入力してよい情報の線引きを示す：禁止事項を並べるのではなく「これは入れてよい／これは駄目」を業務単位で例示する
3. 組織として使える環境を用意する：業務データを扱える環境を会社が提供すれば、個人アカウントに流れる理由が消える
4. うまい使い方を横展開する：個人が編み出した使い方を吸い上げ、テンプレート化して共有する

この4段階は、エージェント導入の前段としても機能する。個人利用の実態を把握する作業が、そのまま「どの業務をエージェント化すべきか」の候補リストになるからだ。

なお、タイ政府側でも支援の枠組みが動いている。デジタル経済振興機構（DEPA）のTH-AI Passportや人材育成への税制優遇がそれにあたるが、これは後段の90日ロードマップで予算計画と併せて整理する。

AIエージェントは何が違うのか｜生成AI・RPA・チャットボットとの境界

導入判断を誤らせる原因の一つに、用語の混同がある。「AIエージェント」という言葉が、チャットボットからRPAの延長まで、まったく違うものを指して使われている。ここでは境界を判断主体の所在で切り分ける。

判断を誰が持っているかで分ける

技術的な仕組みではなく、「業務上の判断を誰が持っているか」で分類すると、実務的な差が明確になる。

決定的な違いは最下段の「想定外への対応」である。RPAは想定外で止まる。エージェントは想定外で自分で別の手を試す。止まるものは何もしないから安全だ。自分で別の手を試すものは、うまくいけば人手を介さずに業務が進むが、間違った手を選べば誤った処理が実行される。「自律的に動く」という性質と「誤った判断が実行される」という性質は、同じものの裏表である。だからこそ、権限の範囲と監視の設計が導入の前提になる。RPAには不要だった議論が、エージェントには必須になる。

既存のRPA資産をどう扱うか

タイの日系拠点でも、RPAを導入済みの工場は少なくない。「エージェントを入れるならRPAは捨てるのか」という質問をよく受けるが、答えは捨てないである。

整理すると次のようになる。

最も費用対効果が高いのは2行目と4行目である。RPAが止まる原因の多くは「入力の形式が想定と違う」ことであり、ここに生成AIを挟むと安定する。既存のRPA資産をそのまま活かしながら、止まる頻度を下げられる。4行目も重要だ。エージェントに最後の実行までさせず下書きを作らせて人が確認して送る構成にすれば、リスクを大きく下げたまま工数削減の大半を取れる。

なお、ベンダー提案を評価するときは「シナリオを事前定義する製品か」「複数システムを横断できるか」「失敗したときに何が起きるか」の3点を確認すると実態が分かる。シナリオを事前定義する製品は実質的にワークフローツールであり、期待値をエージェント基準で置くと合わない。

また、社内文書や図面をエージェントに参照させる場合、その基盤としてRAG（検索拡張生成）の構築が必要になる。参照させるデータの整備は、エージェント本体より工数がかかることが多い。この部分の進め方と費用についてはRAG構築の費用と進め方で個別に整理している。

導入前に決める4つの設計｜権限・データ範囲・監視・オーナーシップ

ここが本記事の中心である。前章までで見た通り、PoCが止まる場所はほぼ4か所に集約される。この4点をPoC開始前に決めるだけで、成否は大きく変わる。

なぜ「前」に決めることが効くのか

Digital Appliedの調査には、決定的な数字がある。専任のAI運用体制を量的拡大の「前」に置いた組織は、事後に決めた組織と比べて成功率が5.7倍である。

同じ体制を作るにしても、先に作るか後で作るかで5.7倍の差が出る。この差は体制の有無ではなく順序が生んでいる。後から作る場合、既に動いているPoCに合わせて体制を設計することになり、PoCの制約がそのまま本番の制約になる。スケールを阻む要因の上位5つも、この文脈で読み直せる。

上位5つすべてが4つの設計のいずれかに対応する。技術的に難しいから止まっているのではない。決めていないから止まっている。

以下、4点を順に見ていく。

設計1：権限｜エージェントは誰の代理として動くのか

最初に決めるべきは、エージェントがどのアカウントの権限で、どのシステムに、読み取りだけか書き込みまで行うかである。

PoCではこの問いが表面化しない。担当者が自分のアカウントで動かすからだ。しかし本番では、エージェントは24時間動く可能性があり、複数の利用者から呼ばれる。「誰の代理か」が決まっていないと、権限設計が成立しない。

決めるべき項目を整理する。

最も重要なのは「実行主体」である。専用アカウントに強い権限を与えると設計は楽になるが、「本来その利用者が見られないデータを、エージェント経由で見られてしまう」という穴が開く。担当客先しか見られない設定の営業担当が、エージェントに聞けば全客先の情報を得られる。これは権限管理の破綻である。対策は利用者の権限をエージェントに引き継ぐ設計にすることだ。技術的には手間が増えるが、後から直すコストははるかに大きい。

書き込み権限は、最初は「下書き作成まで」に固定するのを推奨する。発注、出荷指示、客先への送信といった実行を最初からエージェントに委ねる必要はない。下書きまで自動化しても工数削減の大半は取れるうえ、誤実行のリスクはゼロになる。実運用で精度が確認できてから、影響の小さい範囲で実行権限を段階的に開放すればよい。

設計2：データ範囲｜何を読ませ、何を読ませないか

次に決めるのは、エージェントが参照するデータの範囲である。ここは技術の話ではなく、経営判断と法務判断が混ざる領域であり、決裁に時間がかかる。だから先に着手する必要がある。

まず、データを4つの区分に分けて整理する。

実務で最も揉めるのは2行目の「条件付き」である。客先図面を読ませてよいかは、客先との秘密保持契約の条項と、使用するサービスのデータ取り扱い条件の両方に依存する。「学習に使われないこと」が契約上要求されている場合は、サービスの契約形態まで確認する必要がある。

タイ拠点の場合、ここにPDPA（タイ個人情報保護法）の観点が加わる。従業員情報や取引先担当者の個人情報が含まれるドキュメントを参照範囲に入れる場合、取り扱いの根拠と範囲を整理しておく必要がある。日本本社の方針だけでは足りない。

そして4行目が実は最大の壁である。「ドメイン学習データ不足41%」の実体は、多くの場合「データが無い」のではなく「文書化されていない」ことにある。ベテランが頭の中で判断している基準はどこにも書かれておらず、エージェントは書かれていないものを参照できない。ここで必要なのは、すべてを文書化してから始めるのではなく、対象業務を絞り、その業務に必要な範囲だけ文書化するという判断である。全社のナレッジ整備を先に完了させようとすると、それだけで1年が消える。

データ範囲の設計は、実務的には参照ドキュメントの整備計画と一体で進めることになる。

設計3：監視｜劣化をどう検知するか

3つ目が監視である。「量産時の出力品質劣化58%」「監視の欠如54%」という2つの数字は、実質的に同じ問題を指している。品質は劣化する。検知できなければ気づかない。

なぜ劣化するのか。理由は3つある。入力の分布が変わる（PoCでは代表的なケースで試すが、本番では想定していなかった形式の問い合わせ、新製品、新しい客先が入ってくる。PoC時の精度は、PoC時の入力分布に対する精度でしかない）。参照データが古くなる（作業標準が改訂されたのに参照ドキュメントが更新されていない。この状態でエージェントは自信を持って古い基準を答える。間違いが「分かりません」ではなく「もっともらしい回答」として出てくる点が、この種の劣化の厄介さである）。利用者の使い方が変わる（使い慣れると当初想定していなかった用途に使い始める。それ自体は良いことだが、想定外の用途では精度が保証されない）。

したがって監視は、システム監視（動いているか）ではなく業務監視（正しいか）として設計する必要がある。最低限、次の4つを見る。

特に「利用者の修正率」は、最も実用的な指標である。利用者が毎回大幅に手を入れているなら、その業務ではエージェントが機能していない。逆にほぼ修正なしで使われているなら、実行権限の開放を検討できる。この指標は自動で取れるうえ、業務価値と直結する。

「想定外の入力」の記録も欠かせない。参照データに該当が無かった問い合わせは、そのまま次に整備すべきドキュメントのリストになる。監視は劣化を検知するだけでなく、改善の材料を生み出す装置でもある。

なお、週次でサンプル抽出して正誤を判定する作業は、業務量にもよるが月に数時間から十数時間を要する。この工数を誰の業務時間に入れるかを決めていないと、監視は3か月で形骸化する。これが4つ目の設計につながる。

設計4：オーナーシップ｜誰の仕組みなのか

最後がオーナーシップである。「組織オーナーシップの欠落49%」は、およそ半数の組織で「誰の仕組みか決まっていない」ことを示している。

決めるべきは、次の4つの役割である。

最も抜けやすいのが「データ担当」である。参照ドキュメントの更新は作業標準を書いている部門の仕事だが、その部門はエージェントの存在を意識していないことが多い。標準を改訂したときに参照先も更新するという手順が業務プロセスに組み込まれていなければ、鮮度は必ず落ちる。

「業務オーナーが情報システム部門になっている」のも典型的な失敗パターンである。出力の正誤を判定できない部門がオーナーになると、監視が機能しない。オーナーは必ず業務側に置く。

外部ベンダーとの関係も整理しておきたい。構築を外部に委託しても運用は自社に残る。運用まで丸ごと外注すると、業務変更のたびに費用と時間がかかり、改善が止まる。逆に最初から全部を内製しようとすると立ち上がりが遅い。現実的なのは、構築と初期運用を外部と組んで進めながら、運用の主体を段階的に自社に移す構成である。移管の対象は、監視の実施、参照ドキュメントの更新、問い合わせ対応の3つが中心になる。この移し方についてはAI内製化支援で段階ごとに整理している。

4つを1枚に落とす

4つの設計は独立ではなく相互に依存する。権限を決めればデータ範囲が決まり、データ範囲が決まれば監視項目が決まり、監視項目が決まれば必要な工数とオーナーが決まる。PoC開始前に、次の1枚を作ることを推奨する。A4で1枚に収まる分量で十分である。

• 対象業務：何を、誰が、いまどうやっているか
• 目標：何を何%改善するか（評価基準）
• 実行主体：どのアカウントで、どのシステムを、読み取りか書き込みか
• データ範囲：参照させるもの、させないもの、条件付きのもの
• 承認：どの操作に人の承認を挟むか、その閾値
• 監視：見る指標、頻度、判定する人
• 役割：業務オーナー、運用担当、技術担当、データ担当の氏名
• 中止基準：どの状態になったらPoCを終了するか

最後の「中止基準」を入れておくのが実務的に効く。4.7か月かけて停滞に入る構造は、止める判断ができないことから生まれる。「3か月時点で修正率が7割を超えていたら一旦止める」といった基準を先に置いておけば、埋没コストの拡大を防げる。

この1枚を作る作業は、関係者が集まれば2〜3回の打ち合わせで終わる。5.7倍の差を生むのは、この程度の作業である。

AIエージェント導入の費用と内訳（2026年）

費用の話に入る。ここで注意したいのは、AIエージェントの費用が「ライセンス費用」として語られがちなことである。実際には、見えている費用は全体の一部にすぎない。

3つの価格帯

導入形態は大きく3つに分かれる。以下は一般的な相場としての目安であり、対象業務、連携先システムの数、既存データの整備状況によって大きく変動する。自社の見積として断定できる数字ではなく、検討の出発点として見てほしい。

円換算の目安を添えると、1バーツ＝約4.5円で換算した場合、帯Aの初期が約45万〜225万円、帯Bが約360万〜1,350万円、帯Cが約1,350万〜6,750万円となる。為替は変動するため、あくまで桁感の把握として使ってほしい。

最初から帯Cを狙う必要はない。前述の通り、2026年時点では1業務でスケールできていれば上位2割である。帯Bで1業務を確実に回し、そこで得た知見をもとに広げるほうが、結果的に速く安い。

見えにくいランニングコスト3種

初期費用は見積書に載る。問題はランニングである。ここが見積の段階で過小に見積もられると、稼働後に「思ったより高い」となり、継続の判断が揺らぐ。

その1：トークン・API利用料

エージェントは1回の処理で、モデルを複数回呼び出す。目標を分解し、必要な情報を探し、結果を評価し、必要なら別の手を試す。1回の依頼に対して、対話型の生成AIの数倍から十数倍のトークンを消費するのが普通である。

見積のときは、次の式で概算する。

月額トークン費用 ＝ 1件あたりの想定トークン量 × 月間件数 × 単価

重要なのは、1件あたりのトークン量をPoCの実測値で置くことである。カタログ値や他社事例で置くと桁が変わる。また、参照ドキュメントが増えるほど1件あたりのトークンは増える。データ整備を進めるとランニングも上がるという関係を予算計画に織り込んでおく必要がある。

その2：監視の人件費

前章で述べた通り、監視は人の作業である。週次でサンプルを抽出し、正誤を判定し、傾向を記録する。この工数は、対象業務の規模にもよるが、月あたり数時間から十数時間を見込む。

見積書には載らないが、確実に発生する。この工数を業務時間として確保していない組織では、監視が3か月で止まる。止まった監視は、劣化が進行しても誰も気づかない状態を作る。

その3：再学習・参照データの更新

作業標準が変わる。製品が変わる。客先の要求が変わる。そのたびに参照ドキュメントを更新し、必要なら出力の型を調整する。この作業は初期構築ほどの工数ではないが継続的に発生する。年間で初期構築の10〜20%程度を保守・改善の予算として見込むのが一般的な考え方である。ここを見込まないと、1年後には「導入したが古い情報を答えるので誰も使っていない」状態になる。

3種を合わせると、ランニングは初期費用に対して年間で無視できない比率になる。3年間の総保有コストで比較しないと、帯Aと帯Bの判断を誤る。

失敗したときのコストを見積もりに入れる

前章で触れた平均埋没コスト210万USDは大企業の数字だが、考え方は規模を問わず使える。PoCが中止になった場合に、いくらが消えて、いくらが残るかを先に整理しておく。

結論は明快である。先にやるべきは「残る」側の投資だ。既存システムからデータを取り出せるようにする作業と業務ドキュメントを整理する作業は、エージェントが使い物にならなくても無駄にならない。逆にツール選定から入ると、消える側の支出が先に積み上がる。順序を変えるだけで、失敗したときの損失が変わる。

見積を評価するときの3つの確認点

ベンダーから見積を取ったら、次の3点を確認するとよい。データ整備の費目があるか（「お客様側でご準備ください」と一行あるだけなら、その工数は自社に残る。何人日かかるかを自社で見積もり直す）。ランニングの前提が書かれているか（月間件数と1件あたりトークン量の前提が示されていない月額は、根拠が無い）。運用移管の条件が書かれているか（どの作業を自社が引き取るかが曖昧だと、軽微な変更のたびに追加見積になる）。

製造業の現場で効く活用領域

抽象論を離れて、在タイ日系製造業で実際に効果が出やすい領域を整理する。共通する条件は、「人が毎日、似た判断を繰り返している」かつ「判断の材料がシステムの中にある」業務である。

領域1：生産管理・納期回答

客先からの納期照会に答える業務は、エージェント化の第一候補である。理由は3つある。件数が多い（1日数十件の照会が来る拠点は珍しくない）、判断の材料がシステムにある（在庫、生産計画、工程進捗、購買のリードタイム）、手順が定型的（複数のシステムを見て統合し、回答文を作る流れが毎回同じ）。

エージェントに任せるのは、在庫と計画を横断して照会し、回答の下書きを作るところまでである。送信は人が確認して行う。この構成なら、誤った納期を客先に伝えるリスクはゼロのまま、調べる時間を大きく圧縮できる。

注意点はシステム間のデータの鮮度差である。在庫がリアルタイム、生産実績が日次バッチ、購買が週次更新といった状態では、統合した回答の信頼性が下がる。エージェント導入は、データ鮮度の不整合を可視化する作業でもある。

領域2：品質・不良分析

不良発生時の初動調査もエージェントに向く。過去の類似不良の検索、該当ロットの製造条件の抽出、関連する是正処置の履歴の確認。人が手作業でやると数時間かかるが、材料はすべて記録の中にある。任せるのは「この不良項目について、過去1年の類似記録とそのときの対策を出す」という調査部分であり、原因の断定と対策の決定は人が行う。

前提条件は、記録が結合可能な状態にあることである。検査記録に設備IDが入っていない、システムごとに時刻がずれている、工程ごとにロット定義が違う。こうした状態では、エージェントに渡せるデータセットが作れない。「ドメイン学習データ不足41%」が製造現場で最も具体的に現れるのがこの領域である。

領域3：設備保全

設備の異常時に、過去の同種トラブルの対応履歴、該当設備のマニュアルの該当箇所、部品の在庫状況を横断して提示する用途である。保全業務は知識が属人化しやすい。ベテランは症状を聞いただけで原因の見当がつくが、その判断根拠は文書化されていない。エージェントを入れる価値は、この属人化の緩和にある。

ただし現実的には、過去のトラブル記録が「対応した」としか書かれていないケースが多い。症状、原因、処置、結果が構造化されて残っていなければ、エージェントは何も参照できない。この領域は、記録フォーマットの改善から始める必要があることが多い。

領域4：調達・購買

見積の比較、発注先の選定支援、納期遅延の兆候検知といった業務である。複数サプライヤーの見積を項目単位で比較し差分を整理する作業は、フォーマットがばらついているぶん人手がかかる。ここは生成AIの得意領域である。

発注の実行はエージェントに委ねない。金銭が動く操作は権限設計の原則通り下書きまでで止める。比較表を作るところまでを自動化するだけで、購買担当の工数は目に見えて減る。

領域5：多言語ドキュメント

在タイ拠点で最も導入効果が分かりやすいのがこの領域である。日本語の作業標準をタイ語に展開する、タイ語の日報を日本語で要約する、英語の客先要求仕様を日本語とタイ語の両方で整理する。単なる翻訳ではなく、社内の用語体系に合わせて訳せる点がエージェントの価値である。不良項目名、工程名、設備名を社内のコード体系に沿って統一的に訳せれば翻訳の品質が安定する。これは汎用の翻訳ツールでは実現しにくい。

運用上の要点は、正となる言語を決めておくことである。両方を正にすると、更新のたびに食い違いが生まれる。前章の「言語が3層に分かれている」論点は、ここで具体的な設計事項になる。

どこから始めるかの判断軸

5領域を並べたが、すべてを同時に始めるべきではない。選定の判断軸は次の4つである。

最初の1つは、件数が多く、材料がシステム内にあり、誤りの影響が小さく、部門が協力的な業務を選ぶ。多くの拠点では、納期回答か多言語ドキュメントがこれに該当する。最初から最も困っている業務を選ばないことが重要である。最初の目的は仕組みと体制の検証であり、成果の最大化ではない。困難な業務を選ぶと、検証すべき論点と業務固有の難しさが混ざり、何が原因で止まっているのか判別できなくなる。

在タイ日系製造業の90日ロードマップ

ここまでの内容を、実際に動かす順序に落とす。前提は「生成AIの個人利用は始まっているが、組織として導入していない拠点」である。タイの構造を踏まえれば、これが最も多いパターンである。

Day 0-30：ツールに触らずに決める

この30日でやることの大半は、ツールに触らない作業である。

• 個人利用の実態を聞き取る：罰則抜きで、誰がどの業務で何を使っているかを把握する。これが対象業務の候補リストになる
• 対象業務を1つに絞る：前章の4つの判断軸で選ぶ。2つ以上を同時に始めない
• 現状の工数を実測する：件数と1件あたりの所要時間をストップウォッチで測る。ここが後のROI計算の基準になる
• 4つの設計を1枚にまとめる：権限、データ範囲、監視、オーナーシップ
• 評価基準と中止基準を決める：何を何%改善したら合格か、どうなったら止めるか
• 参照データの棚卸しをする：対象業務に必要なドキュメントが、どこに、どの言語で、いつ更新されて存在するか

成果物は文書であり、動くシステムではない。この段階でベンダーに提示する資料が揃うため、見積の精度も上がる。

つまずきどころは、対象業務が絞れないことである。関係部門を集めると、それぞれが自部門の課題を持ち込み対象が膨らむ。「今回は1業務。次のサイクルで次の業務」と明示することで収束させる。なお、この30日は自社の工数だけで進められる。大きな支出が発生しないうちに、最も重要な判断を終えるという順序が、埋没コストを抑える最大の手段である。

Day 31-60：小さく回し、監視を実際にやる

対象業務に絞ってPoCを構築し、実際に業務の中で使う。ここでの目的は「動くこと」の確認ではなく、実測値を取ることである。

• 限定した利用者で運用する：数名の担当者に実務で使ってもらう。全員展開しない
• 監視を実際に実施する：週次でサンプル抽出し、正誤を判定する。この作業自体の工数も測る
• 修正率を記録する：出力をそのまま使えた割合と、手を入れた割合
• トークン消費量を実測する：1件あたりの実測値を取る。ランニング見積の根拠になる
• 参照データの不足を記録する：答えられなかった問い合わせを、そのまま整備リストにする
• 例外処理の運用を決める：エージェントが判断できなかったとき、誰にどう回すか

つまずきどころは監視である。「忙しいから今週はスキップ」が2回続くと、以降やらなくなる。監視の担当者と時間枠を、Day 0-30の段階で業務として確保しておく必要がある。もう一つの落とし穴は利用者を広げすぎることだ。使える人が増えると機能追加の要望が積み上がり、評価すべき対象がぶれる。Day 31-60は機能を固定して実測に徹するのが正しい。

Day 61-90：判断し、体制を確定する

実測値が揃ったら、本番移行の判断をする。判断材料は次の4つである。

1. 評価基準を満たしたか：Day 0-30で決めた基準に対して、実測がどうだったか
2. 修正率は許容範囲か：利用者が毎回大幅に手を入れているなら、本番移行は早い
3. ランニングの実測はいくらか：トークン実測値から年間費用を算出し、削減効果と比較する
4. 監視を継続できる体制があるか：担当者と工数が確保できるか

この4つのうち一つでも満たさないなら、延長ではなく一旦中止する判断も選択肢に入れる。中止基準を先に決めておく意味はここにある。

満たしている場合は、体制を確定する。

• 業務オーナー、運用担当、技術担当、データ担当を氏名で決める
• 参照ドキュメントの更新手順を、既存の文書管理プロセスに組み込む
• タイ語の操作手順書を作る
• 監視の記録様式と保管場所を決める
• 次の対象業務の候補を1つ決める

90日の終わりに得られるのは、完成したシステムではなく、判断材料と体制である。この順序を守るほうが、最初から全社展開を狙うより結果的に速い。5.7倍の差は、この90日の使い方に宿る。

DEPA・BOIの制度を予算計画に織り込む

タイ拠点ならではの補足として、公的な支援制度の確認を計画に組み込んでおきたい。

DEPAは、TH-AI Passport（規模16億バーツ、2026年6月5日登録開始）を進めているほか、Coding Thailand 2026を2026年3月16日にSiam Square SiamScapeで開始している。人材面では、人材育成関連の企業研修費に最大250%の税制優遇が用意されている。エージェント導入ではツール費用よりも人材育成がボトルネックになりやすいため、Day 61-90で運用体制を確定する際に教育費用の扱いを税制面から確認しておく価値がある。

BOIの恩典を受けている拠点であれば、デジタル関連投資の扱いも確認しておきたい。制度の適用条件・対象範囲・申請手続きは所管機関の最新情報によるため、ここでは予算計画段階の確認項目として挙げるにとどめる。制度ありきで計画を立てるのではなく、決めた計画に使える制度があるかを確認するという順序が実務的である。

効果測定とROIの出し方

投資判断のための計算方法を整理する。評価基準の不備が64%という最大の阻害要因である以上、計算式を先に決めておくことが直接の対策になる。

基本の考え方：4項目で見る

複雑にする必要はない。次の4項目で年間の便益を見積もり、費用と比較する。

投資判断の主軸は①に置く。②〜④は価値としては大きいが定量化の前提が多く、試算の説得力を下げる。①だけで回収の見通しが立つ範囲から始め、②〜④は「加えてこうした効果も見込める」という位置づけで添えるのが健全である。

具体的な試算例：納期回答業務

前章の領域1を例に、実際に計算してみる。以下は計算方法を示すための試算例であり、特定の実績を示すものではない。自社の実測値に置き換えて使ってほしい。

前提

• 対象業務：客先からの納期照会への回答
• 件数：1日50件 × 年間240稼働日 ＝ 年間12,000件
• 現状の所要時間：1件あたり平均12分（複数システムの照会＋回答文作成）
• 導入後の所要時間：1件あたり平均4分（エージェントが下書きを作成、人が確認して送信）
• 人件費単価：400THB／時間（管理系スタッフの総額人件費ベース）

便益の計算

• 現状の年間工数：12分 × 12,000件 ÷ 60 ＝ 2,400時間
• 導入後の年間工数：4分 × 12,000件 ÷ 60 ＝ 800時間
• 削減工数：1,600時間／年
• 金額換算：1,600時間 × 400THB ＝ 640,000THB／年

費用の計算

• 初期費用：900,000THB（帯Bの下限付近、既存システムとの接続を含む）
• 年間ランニング：258,400THB

– トークン・API利用料：約140,000THB

– 監視の人件費：月8時間 × 12か月 × 400THB ＝ 38,400THB

– 保守・参照データ更新：約80,000THB

回収の計算

• 年間の純便益：640,000 − 258,400 ＝ 381,600THB／年
• 単純回収年数：900,000 ÷ 381,600 ＝ 約2.4年

製造業の現場システムでは、2〜4年で回収できれば投資判断が通りやすいというのが一般的な感覚である。この試算は範囲内に入る。

試算で誤りやすい3点

上の計算は単純だが、実務では次の3点で誤りが生じやすい。

誤り1：ランニングを費用に入れていない

初期費用だけで回収年数を出すと、900,000 ÷ 640,000 ＝ 約1.4年となり、実際の2.4年と大きく乖離する。特にトークン費用と監視の人件費は見積書に載らないため、意識的に加える必要がある。

誤り2：導入後の所要時間を楽観的に置く

「1件12分が1分になる」といった前提を置きたくなるが、人が確認する時間は必ず残る。Day 31-60の実測値を使わずに机上で置くと、この部分が過小になる。

誤り3：削減した時間の使い道が決まっていない

1,600時間削減しても、その時間で何もしなければ財務上の効果は出ない。増員せずに増産に対応するのか、より付加価値の高い業務に振り向けるのか。ここが曖昧だと、稼働後に「楽にはなったが数字は変わらない」という評価になる。

評価基準は導入前に文書化する

計算式そのものより重要なのが、この計算をDay 0-30の段階で文書化しておくことである。

導入後に効果を測ろうとすると、比較対象となる導入前の実測値が無い。「なんとなく速くなった気がする」という評価しかできず、投資判断も継続判断も根拠を持てない。現状の件数と所要時間を測るのは、導入前にしかできない。

評価基準の文書には、最低限次の4つを書いておく。測る指標（所要時間、件数、修正率）、測り方（誰が、いつ、どう測るか）、合格ライン（どの水準なら本番移行するか）、中止ライン（どの水準なら止めるか）。

「評価基準の不備64%」という最大の阻害要因への対策は、この4行を書くことである。技術でも予算でもなく、文書化の問題である。

よくある質問（FAQ）

AIエージェント導入の費用はいくらかかるか

導入形態によって大きく異なる。一般的な相場としては、既製サービスの設定利用で初期10万〜50万THB程度、1〜2業務に絞った特化型の構築で80万〜300万THB程度、複数業務・基幹連携を伴う展開で300万〜1,500万THB程度が目安になる。ただしこれは対象業務、連携先システムの数、既存データの整備状況で大きく変動する。

見積を評価するときは、初期費用よりランニングを確認するほうが重要である。トークン・API利用料、監視の人件費、参照データの更新費用の3つは見積書に載りにくく、しかも継続的に発生する。3年間の総額で比較しないと判断を誤る。費用を抑えたい場合は、90日ロードマップの通り1業務に絞って始めることだ。設計を固めてから見積を取ると、範囲が明確なぶん金額のブレも小さくなる。

AIエージェントとRPAは何が違うのか

判断を誰が持っているかが違う。RPAは人が手順を全部書き、その通りに実行する。想定外の入力が来れば止まる。AIエージェントは目標を与えられ、手順は自分で決める。想定外の状況では自分で別の手を試す。

この違いは価値であり、同時にリスクでもある。止まるものは何もしないので安全だが、人が対応するまで業務は進まない。自分で判断するものは業務を進められるが、誤った判断も実行しうる。だから権限の範囲と監視の設計が必須になる。

実務的には、RPAを捨ててエージェントに置き換える必要はない。手順が完全に固定された業務はRPAのほうが安価で確実である。RPAが止まる原因の多くは入力形式のばらつきなので、そこに生成AIを挟んで形式を整える構成が最も費用対効果が高い場面も多い。

導入期間はどれくらいかかるか

1業務に絞れば、判断材料が揃うまでに90日が目安である。内訳は、実態把握と設計に30日、限定範囲でのPoCと監視に30日、本番移行判断と体制確定に30日となる。

注意したいのは、調査ではPoCの平均期間が4.7か月で、その後64%が6か月以上停滞している点である。期間が延びる主因は技術ではなく、判断基準が無いまま「もう少し様子を見る」を繰り返すことにある。開始時点で中止基準を決めておくと、この停滞を防げる。なお、参照させるドキュメントが未整備の場合はその整備期間が別途必要になる。対象業務を絞れば整備範囲も絞れるため、ここでも「1業務から」という原則が効く。

小規模な拠点でも導入できるか

できる。むしろ小規模な拠点のほうが有利な面がある。関係者が少ないため、権限とデータ範囲の合意形成が速い。オーナーシップも決めやすい。88%がPoC止まりになる原因の上位はガバナンス摩擦と組織オーナーシップの欠落であり、これらは組織が大きいほど深刻になる。

規模の面で不利なのは件数である。ROIは「1件あたりの削減時間 × 件数」で決まるため、件数が少ない業務では効果が出にくい。従業員数ではなく、対象業務の件数で判断するのが正しい。1日数件の業務なら、エージェント化よりも手順の簡素化のほうが効く。小規模拠点では、まず既製サービスの設定利用（帯A）から始め、効果を確認してから特化型の構築を検討する順序が現実的である。

タイ拠点でも日本語で相談できるか

可能である。TOMAS TECHはバンコクに拠点を置き、日本語・タイ語・英語で対応している。在タイの日系製造業では、日本人管理者が日本語で議論し、ローカルスタッフがタイ語で運用するという分業が一般的であり、この構造を前提に設計する必要がある。

実務上重要なのは、日本語だけで完結させないことである。ポリシー、操作手順書、参照ドキュメントがすべて日本語版しか無い状態では、実質的にローカルスタッフには存在しないのと同じになる。タイの従業員の72%が既に業務でAIを使っている状況を踏まえれば、ローカルスタッフが読める言語での整備は定着の前提条件である。

日本本社との関係でも同じことが言える。拠点側で「どの業務にどう使うか」を具体化して本社に提示するほうが、本社主導の抽象的な方針より議論が進む。

既存の基幹システムを入れ替えないと導入できないか

入れ替えは不要である。ただし、既存システムからデータを取り出せる状態にする作業は必要になる。スケール阻害要因の第1位が「レガシー連携の複雑さ63%」であることからも、ここが最大の技術的論点である。

現実的な進め方は、既存システムを触らず参照専用の経路を作ることである。データベースの参照権限、定期的なデータ抽出、APIの有無を確認し、読み取りだけで済む構成にする。書き込みを伴う連携は影響範囲が大きいため、後の段階に回す。なお、この作業はエージェントが使い物にならなくても資産として残る。先にやるべきは、この残る側の投資である。

情報漏洩のリスクはどう管理するか

管理すべき対象は2つある。組織が導入したエージェントからの流出と、組織が把握していない個人利用からの流出である。

前者は設計で管理できる。参照させるデータの範囲を明示的に区分し、人事・給与・健康情報などを除外し、除外できていることを実際に検証する。利用者の権限をエージェントに引き継ぐ設計にすれば、本来見られないデータが見えてしまう穴も塞げる。実行ログを残せば事後の追跡も可能になる。

実務上より深刻なのは後者である。タイでは従業員個人の72%が業務でAIを使っている一方、組織の導入率は10.7%にとどまる。禁止しても実効性は乏しい。組織として使える環境を提供することが、最も現実的な漏洩対策になる。あわせて、ポリシーを策定し、ローカルスタッフが読める言語で提供し、タイのPDPAとの関係を整理する。この3点は、エージェント導入の有無にかかわらず着手する価値がある。

まとめ

AIエージェント導入の成否を分けるのは、モデル選定でもツール選定でもない。PoCに入る前に「権限・データ範囲・監視・オーナーシップ」の4点を決めたかどうかである。88%がPoC止まりになるのは、この4点を後回しにして「使えるか試す」から入るためである。

本記事の要点を整理する。

• 88%が本番に到達しない。阻害要因の上位は評価基準の不備64%、ガバナンス摩擦57%、モデルの信頼性51%。上位2つはモデル性能とは無関係であり、決めていないことに起因する
• 78%がPoCを持ち、14%しか全社運用に届かない。64%が6か月以上停滞し、停滞までの平均PoC期間は4.7か月。失敗した案件の平均埋没コストは約210万USD
• 日本は生成AIの業務利用率55.2%で中国95.8%・米国90.6%・ドイツ90.3%に劣後する。McKinseyでは62%が実験段階、23%がスケールに到達。1業務でも安定運用できていれば上位2割である
• タイは組織10.7%に対し従業員個人72%という逆転構造にある。シンガポール69%、ベトナム23%と比べて組織の導入は遅れているが、現場の抵抗が小さいことは強みでもある。成熟度2.12／4.0という水準は、エージェント以前にデータ基盤の整備が要る拠点が多いことを示す
• 4つの設計が本体である。権限は「誰の代理として動くか」、データ範囲は「何を読ませ何を読ませないか」、監視は「劣化をどう検知するか」、オーナーシップは「誰の仕組みか」。専任体制を拡大の前に置いた組織は成功率5.7倍
• 費用はランニングで判断する。トークン・API利用料、監視の人件費、参照データの更新費用は見積書に載りにくい。先にやるべきは、失敗しても残る側の投資（既存システムのデータ取り出しと業務ドキュメントの整備）である
• 90日で判断材料を作る。最初の30日はツールに触らず設計と基準を文書にし、次の30日で限定範囲のPoCと監視を実測し、最後の30日で本番移行を判断して体制を確定する
• ROIは工数削減を主軸に置く。ランニングを差し引き、人の確認時間を残し、削減した時間の使い道を決める。評価基準は導入前にしか作れない

外部環境としては、2026年末までに企業アプリケーションの40%がAIエージェントを組み込むというGartnerの予測があり、市場規模も2026年に78億USD（前年比+50%）へ拡大する見通しである。自社で構築しなくても、既存アプリの中にエージェントが入ってくる。権限とデータ範囲の設計を先送りできる期間は、そう長くない。

最後にもう一度。試す前に、4つを決める。 これが本記事のすべてである。

4つの設計を決める作業は、ツールを契約する前に、対象業務の現状と参照できるデータを並べるところから始められます。TOMAS TECHはタイで、生産・エネルギー管理システムのPEGASUSをはじめとする現場システムの構築を通じて、工場のデータをどこから取り出し、どう業務の判断につなげるかという部分を扱ってきました。「どの業務から始めるのが自社に合うか」「既存の基幹システムからどこまでデータを取り出せるか」といった設計段階の論点だけでも構いませんし、まだ社内で検討を始めたばかりの段階でも問題ありません。拠点の状況を伺ったうえで、進め方の選択肢を整理してお伝えします。ご相談はお問い合わせフォームからお気軽にどうぞ。