RPA×生成AI連携2026｜自動化が止まるのは判断が混ざる場所

RPAを入れたのに、削減時間が途中で頭打ちになる。原因は例外の多さではなく、業務フローの中に「判断」が混ざっていることにある。本稿ではRPAと生成AIの連携を、置き換えではなく判断ノードへの接続として整理する。処理を5つのノードに割り、タイの日系製造業を想定したモデルで3ケースの投資回収を試算した。

RPA 生成AI 連携を考える前に、自動化が止まっている場所を特定する

タイの日系製造業でよく見る光景がある。数年前にRPAを導入し、いくつかのシナリオが動いている。導入直後は残業が減り、報告資料にも成果として載った。ところが2年目以降、削減時間の伸びが止まる。追加でシナリオを作ろうとすると「この業務は例外が多いから自動化できない」という結論になり、対象業務のリストがそこで止まる。

ここで出てくる診断はたいてい3つのどれかである。例外が多すぎる、現場が協力しない、ツールが古い。いずれも部分的には事実だが、原因の説明としては不十分である。なぜなら、この3つが正しいなら、例外を潰し、現場を巻き込み、ツールを乗り換えれば自動化率は上がるはずだからだ。実際には、それを全部やっても頭打ちの位置はあまり変わらない。

自動化が止まる場所には共通した性質がある。そこに判断が挟まっているという性質である。注文請書の単価が発注時の単価と3 THBずれている。数量が1個少ないが分納の連絡が来ていたかもしれない。品名の表記が「ステンレス板 t1.0」と「SUS板1.0t」で違う。こうした場面で人がやっているのは、ルールの適用ではなく、状況を読んで許すか止めるかを決めることである。RPAは条件分岐を実行できるが、条件そのものを作ることはできない。判断が言語化されていない業務に対して、RPAは構造的に無力である。

この見立てを裏づける調査がある。日立ソリューションズが2021年2月9日から15日にかけて実施した「RPA導入後のリプレイス（再検討）に関する意識調査」（RPA導入企業の決裁者・推進担当、回答100名）では、既にRPAを変更したか、追加・変更を検討していると答えた割合が93%に達した。そして変更を考える理由として40%が「自動化したい業務が自動化できない」を挙げている。これは2021年の調査であって直近のものではないが、5年前の時点で既に、RPAの限界が「使い方」ではなく「対象業務の性質」の側にあると認識されていたことを示している。

一方で、判断を機械に任せる話に飛びつくのも早すぎる。Gartnerは2025年6月25日に、エージェント型AIプロジェクトの40%超が2027年末までに中止されるという予測を公表した。中止の理由はコストの増大、価値の不明確さ、リスク統制の不足とされている。同じリリースでは、2025年1月に実施した3,400超の回答によるポーリング結果も併せて示されており、そこでは本格的な投資に踏み込んでいる組織が限られていることが読み取れる。ポーリングは予測そのものの標本ではない点に注意がいる。同時にGartnerは、エージェント型を標榜するベンダーが数千ある一方で、実際にその機能を持つのは130社程度だという見方（agent washing）も示している。判断ノードにいきなり自律エージェントを置く選択は、現時点では回収の見込みが立ちにくい。

本稿が取る立場は、その中間である。判断ノードを避けても自動化率は上がらないが、判断ノードを丸ごと機械に渡すのも早い。判断を下書きさせて人が承認するという形で挟むと、どこまで効いてどこから効かなくなるかが数字で見える。以下では、その効き方を工程の分解と金額で示す。

なお本稿で使う処理件数、時間配分、単価、費用はすべて本稿が置くモデル前提であり、特定の企業の実測値ではない。出典のある統計とモデル試算は、本文中で明確に区別して記述する。

業務を5つのノードに割る｜RPAが単独で担えるのは31%しかない

本稿がモデルとして置くのは、次のような組織である。これは試算のための前提であり、実在する企業の数字ではない。

• タイ・チョンブリ県に置く日系製造業の地域バックオフィス。3拠点分の受発注・請求処理を集約している
• 対象業務は、仕入先からの注文請書・納品書・請求書の照合と、基幹システムへの登録
• 月間処理件数は 8,000件、年間では 96,000件
• 現状の1件あたり所要時間は 8.0分。年間では 96,000 × 8 = 768,000分、すなわち 12,800時間
• 事務職の人件費単価は月給 25,000 THB、法定負担込みの係数を 1.25 と置いて 31,250 THB/月。これを月 160 時間で割り、31,250 ÷ 160 = 195.3 を丸めて 195 THB/時とする
• 現状の年間人件費相当は 12,800 × 195 = 2,496,000 THB

この8.0分を、「誰がやるか」ではなく「何が完了したか」で5つのノードに割る。担当者の行動で切ると、複数人が並行して動いたときに境界が曖昧になるためである。

比率は 12.5 / 37.5 / 31.25 / 12.5 / 6.25 であり、丸めれば 13 / 37 / 31 / 13 / 6 になる。

この表から読み取るべきことは一つである。RPAが単独で担えるのは N1・N4・N5 の合計 2.5分、全体の31%にすぎない。 残る約69%は「読む」（N2、37%）と「決める」（N3、31%）であり、どちらもRPAの守備範囲の外にある。

多くの企業がRPA導入時に感じる違和感の正体は、ここにある。RPAのベンダー資料には「定型業務の自動化」と書かれており、受発注処理は定型業務に見える。ところが実際に工程を割ると、定型なのは3割で、残りは非定型の「読む」と「決める」だった。自動化率が3割で頭打ちになるのは、シナリオの作り込みが甘いからではなく、最初からそこが上限だったということである。

そして重要なのは、この31%という上限が業務改善では動かないことだ。例外パターンを洗い出してシナリオに条件分岐を足していけば、多少は上限が上がる。しかし条件分岐を足すたびにシナリオの行数は増え、帳票フォーマットが変わるたびに保守が発生する。自動化率が35%に上がる代わりに保守工数が倍になるなら、それは前進ではない。RPAだけで攻める限り、自動化率と保守コストはトレードオフの関係から抜けられない。

なぜRPAは判断ノードで止まるのか｜例外の多さではなく構造の問題

「例外が多いから自動化できない」という説明は、実務では便利だが正確ではない。例外が多いこと自体は、条件分岐を書けば処理できる。RPAが止まる本当の理由は、判断ノードにおいて入力と出力の対応関係が事前に決まっていないことにある。

N3で人がやっていることを分解すると、性質の違う3種類の作業が混ざっている。

RPAが実行できるのは上の2つまでで、3つ目には手が届かない。そして現場で時間を食っているのは3つ目である。単価差が1%以内なら通す、という社内基準がある企業は珍しくないが、その基準が適用できない場面が必ず出てくる。原材料の相場が動いた直後、新規の取引先、為替でTHB建て金額だけがずれている場合。人はそこで「今回は通すが次回は確認する」といった、基準の外側の判断をしている。

この構造を無視して条件分岐を足し続けると、どうなるか。よくある帰結が野良ロボットである。担当者が自分の業務に合わせてシナリオを改変し、その改変が文書化されないまま運用に載る。作った本人が異動すると、なぜその分岐が入っているのかを説明できる人がいなくなる。監査で「この処理はどういう基準で通っているのか」と聞かれて答えられない状態になり、最終的にはシナリオを止めて手作業に戻す。RPAの再検討率が高い理由の一端はここにある。

もう一つの帰結が、例外の押し戻しである。RPAが処理できなかった案件は例外キューに積まれ、人が処理する。この例外キューは、自動化前の業務よりも扱いが厄介である。文脈が切れた状態で回ってくるため、担当者は帳票を最初から見直すことになる。RPAが処理した分の時間は確かに減っているのに、例外1件あたりの処理時間は増えている。全体の削減時間が想定より伸びない理由の多くは、この例外処理コストの増分にある。

したがって、自動化を次の段階に進めるための問いは「どうやって例外を減らすか」ではない。判断ノードを誰が担うかである。選択肢は3つしかない。人が担い続ける、ルールを完全に明文化してRPAに渡す、生成AIに下書きさせて人が承認する。2つ目は理想だが、基準の生成を伴う判断では成立しない。現実的な選択肢は1つ目と3つ目の比較になる。自律型のAIエージェントに丸ごと任せる選択については、統制の観点も含めてAIエージェント導入の実務をまとめた記事で扱っている。

生成AIを繋ぐ場所は3か所しかない｜抽出の補助・判断の下書き・例外の説明

生成AIを業務自動化に組み込むとき、最も避けるべき設計は「RPAを生成AIに置き換える」という発想である。N1・N4・N5は決まった手順の反復であり、ここはRPAのほうが安く、速く、結果が安定する。基幹システムへの登録を生成AIにやらせる合理的な理由はない。UiPathが整理しているように、生成AIが「読む・解釈する」を担い、RPAが「集める・登録する」を担うという役割分担が、実装上も費用上も素直である。

本稿の5ノードモデルで見ると、生成AIを繋ぐべき場所は3か所に限定される。

抽出の補助から見ていく。AI-OCRだけでも定型帳票の読み取りは成立するが、仕入先ごとにレイアウトが違う注文請書では、項目の対応づけで詰まる。「単価」という語がない帳票で、どの列が単価かを決める作業がそれにあたる。ここに生成AIを挟むと、周辺の語と数値の桁から列の意味を推定でき、帳票定義を1社ずつ手作りする工数が下がる。ただし読み取りの精度そのものはOCRエンジンの性能に依存するため、生成AIを足せばOCRが不要になるわけではない。エンジン選定の観点はAI-OCRの比較記事にまとめている。

判断の下書きが、本稿の中心である。ここで生成AIに出力させるのは「承認」でも「却下」でもなく、推奨と根拠のセットである。たとえば「注文単価 12.50 THB に対し請求単価 12.80 THB。差は2.4%で社内許容の1%を超過。ただし当該品目は前月に材料費改定の通知あり（メール2026-07-14）。単価改定の反映漏れの可能性が高く、購買への確認を推奨」といった形で出す。担当者はこの文面を読み、承認ボタンを押すか、差し戻すかを決める。担当者の作業は「調べて考える」から「読んで決める」に変わる。

この設計の要点は、生成AIに最終決定権を持たせないことである。決定権を人に残す限り、出力が間違っていても業務は止まらない。むしろ間違いは差し戻しのログとして残り、プロンプトや基準の改善材料になる。逆に決定権を渡してしまうと、間違いは検出されないまま基幹システムに入り、発見が数ヶ月後になる。Gartnerが挙げた中止理由の一つが「リスク統制の不足」であったことを踏まえれば、決定権を残す設計は保守的というより現実的である。

例外の説明は地味だが効く。例外キューに落ちた案件は、なぜ落ちたのかが分からないまま担当者に渡ることが多い。生成AIに「何と何がどう食い違ったか」を3行で要約させ、案件と一緒に表示する。それだけで例外1件あたりの処理時間は目に見えて下がる。前節で述べた「例外の押し戻しによる処理時間の増分」を打ち消すのは、この地味な接続点である。

なお、この3か所に繋ぐ前提として、業務データが構造化された状態でどこかに存在している必要がある。Excelに手入力された台帳が唯一の記録である工程では、生成AIを繋ぐ前にデータの持ち方の整理が要る。この順序についてはExcel作業のAI自動化を扱った記事を参照してほしい。

統制と証跡｜判断を機械に下書きさせるなら残すものが増える

判断ノードに生成AIを挟むと、記録しなければならないものが増える。これは費用として先に見積もっておくべき項目であり、後から追加すると設計のやり直しになる。

RPAだけの構成なら、証跡は「いつ・どのシナリオが・どのデータを・どのシステムに登録したか」で足りる。処理は決定的であり、同じ入力からは同じ出力が出るからだ。ところが生成AIは同じ入力から常に同じ出力を返すとは限らない。したがって「なぜその判断になったか」を後から再現するには、次の要素をセットで保存する必要がある。

多くの現場が最初に見落とすのが、モデル名とプロンプトのバージョンである。プロンプトを改善するのは日常の運用作業だが、改善のたびに判断の傾向は変わる。半年前の案件について監査で説明を求められたとき、当時のプロンプトが残っていなければ「当時はこう判断していた」と言えない。プロンプトはソースコードと同じ扱いにして版管理する、と最初に決めておくのが安い。

差し戻し理由の記録も、統制のためだけの項目ではない。生成AIの提案がどの程度そのまま通っているか、つまり判断の採用率は、この記録からしか計測できない。後述する感応度分析で採用率が投資判断を左右する以上、採用率を測れない設計は投資判断を測れない設計と同義である。承認画面には「承認」「修正して承認」「却下」の3つを置き、修正・却下には理由の選択肢を必ず付ける。

個人データの扱いも設計時に確定させる。取引先の担当者名やメールアドレスは個人データであり、タイではPDPAの対象になる。生成AIに帳票の全文を渡す構成では、これらが外部のAPIに送られることになる。実務的な打ち手は、必要のない項目を送信前にマスクすること、外部APIに送るデータの範囲を文書として定義しておくこと、そして委託先との間でデータ処理の取り決めを結んでおくことである。この3つは技術的には難しくないが、後から入れると全経路の手戻りになる。

費用を5層に分解する｜どの層まで買うかで回収が変わる

費用を層に分けるのは、途中で止める判断ができるようにするためである。一式の見積もりでは「これを買えばどこまでできるか」が見えず、効果が出なかったときに何を削ればよいかも分からない。以下は3拠点合算の前提で置いた5層である。金額はすべて本稿のモデル前提であり、実際の見積もりではない。

層の並びには意味がある。層1は他のどの層よりも先に来る。対象業務がノードに割れていなければ、RPAのシナリオもAI-OCRの帳票定義も、何を作るべきかが決まらないからである。層1の初期費用280,000 THBで得られるのは業務フロー図と例外一覧と判断基準の文書だけであり、機器もソフトウェアも増えない。この層を「調査費用だから削る」という判断が、後段の全ての層の見積もり精度を落とす。

層2のRPA基盤は、年間運用380,000 THBが初期620,000 THBに対して大きい点に注意したい。RPAは入れて終わりではなく、帳票フォーマットの変更や基幹システムの更新のたびにシナリオの手直しが発生する。運用費を見積もらずに導入すると、2年目に「保守の予算がない」という理由でシナリオが放置され、動かなくなったシナリオが積み上がる。

層4の生成AI判断層は、費用の中身が他の層と性質が違う。API利用料そのものは年間運用360,000 THBの一部にすぎず、大半はプロンプトの設計・改善と、承認画面の作り込みである。ここを「AIのAPIを叩くだけ」と見積もると必ず不足する。根拠の提示形式を業務に合わせて詰める工程が、この層の実体である。

層5の統制・証跡は、前節で述べた保存項目を実装する層である。単独では効果を生まないため削られやすいが、層4を買うなら層5は必須になる。判断を機械に下書きさせておいて証跡を残さない構成は、監査で説明できない状態を自ら作ることになる。

ただし層5は層4のためだけの層ではない。RPA単独の構成でも、シナリオの版管理、実行権限の管理、処理した個人データの取り扱いは必要になる。これを省くと、後述する野良ロボットが増える。したがって次節の3ケースは、いずれも層5を含めて計上している。

なお、この5層はどの構成でも全部買う必要はない。次節で見るとおり、どの層まで買うかで回収年数が変わる。受発注業務そのものをシステムとして持っていない場合は、この5層の前に基幹側の整備が入る。その範囲は受発注管理システムの記事で整理している。

3ケースの試算｜RPAだけを先に入れると最も回収が遅い

ここから金額の比較に入る。3つのケースを置き、それぞれが必要とする層と削減効果を突き合わせる。以下はすべて本稿が置くモデル前提に基づく試算であり、実測値ではない。

ケースA｜RPAだけを入れる。 自動化できるのは N1・N4・N5 で、削減は 2.5分。1件あたりは 8.0分から 5.5分になり、31%の短縮である。年間では 96,000 × 2.5 = 240,000分、すなわち 4,000時間。金額に換算すると 4,000 × 195 = 780,000 THB/年となる。

ケースB｜RPA＋AI-OCR。 ケースAに加えて N2 の8割を機械化する。3.0 × 0.8 = 2.4分が上乗せされ、累計削減は 4.9分。1件あたりは 3.1分になり、61%の短縮である。年間では 96,000 × 4.9 = 470,400分、すなわち 7,840時間。金額では 1,528,800 THB/年となる。

ケースC｜RPA＋AI-OCR＋生成AI（判断支援）。 さらに N3 の6割を生成AIの下書きで削る。2.5 × 0.6 = 1.5分が上乗せされ、累計削減は 6.4分。1件あたりは 1.6分になり、80%の短縮である。年間では 96,000 × 6.4 = 614,400分、すなわち 10,240時間。金額では 1,996,800 THB/年となる。

次に、各ケースが必要とする層と単純回収月数を並べる。

計算はいずれも初期投資を年間純益で割った単純回収である。Aは 1,220,000 ÷ 250,000 = 4.88年、すなわち 58.6ヶ月。Bは 1,640,000 ÷ 698,800 = 2.35年、すなわち 28.2ヶ月。Cは 2,200,000 ÷ 806,800 = 2.73年、すなわち 32.7ヶ月である。

この表が示す結論は、直感に反する。最も回収が遅いのは、最も慎重に見えるケースAである。 「まずRPAだけ小さく始めて、効果が出たら広げる」という順序は、意思決定として手堅く見える。しかし数字で見ると、Aは初期投資1,220,000 THBに対して年間純益が250,000 THBしかなく、回収に5年近くかかる。理由は明快で、Aは判断ノードにも抽出ノードにも触れていないため効果が31%で頭打ちになる一方、層2のRPA基盤と層5の統制という基盤コストは先に立つからである。基盤は先に払い、効果は上限で止まる。 これが最も回収の悪い組み合わせになる。

最短回収はケースBの28.2ヶ月である。AI-OCRで「読む」を機械に渡すと、削減が2.5分から4.9分へほぼ倍増する一方、追加の費用は層3だけで済む。分子と分母の伸び方の差が、そのまま回収月数の差になっている。

なお、この3ケースの効果は例外処理コストの増分を織り込んでいない。後述するとおり、自動化率が上がるほど人に回る案件は難しいものだけになり、1件あたりの処理時間は伸びる。織り込めばAとBの効果はさらに下がり、例外の要約を持つCが相対的に有利になる。つまり以下の比較は、Cに対してやや辛めの見方になっている。

ケースCは回収が32.7ヶ月とBより4.5ヶ月遅い。ただし年間純益は806,800 THBで3ケース中最大である。回収期間を最優先するならB、投下できる資本があり年間の利益額を最大化したいならCという整理になる。両者は優劣ではなく、資本制約と時間軸の置き方の違いである。

実務上の示唆は2つある。第一に、RPAだけで止めるという選択には合理性がないこと。Aが損だという意味ではない。初期1,220,000 THBに対して年間純益250,000 THBは出るので、回収後は純増になる。ただしBと比べれば資本効率は明確に劣る。同じ層1と層2を先に買うのだから、層3まで含めてBに進むほうが合理的である。第二に、Bを選ぶ場合でも層1を省略してはならないこと。業務棚卸とノード分解を飛ばすと、AI-OCRに読ませる帳票の範囲もRPAのシナリオの境界も決まらず、結果として層2と層3の見積もりが膨らむ。層1の280,000 THBは、後段の見積もり精度を買う費用である。

感応度｜判断採用率が46%を割ると層4は見送るべき

投資判断では、想定どおりに進まなかった場合を必ず置く。ここで注意したいのは感応度の掛け方である。「効果が7割しか出ない」という係数を全効果に一律で掛ける計算をしてはいけない。N1のメール取得やN2のOCR読み取りは、生成AIの出来とは無関係に効く。動くのはN3の項だけであり、そこだけを差し替えるのが正しい。

本稿が置く不発シナリオは、生成AIの判断採用率が60%から40%に落ちるケースである。提案の6割がそのまま承認される想定だったが、実際には4割しか通らず、残りは担当者が結局自分で調べ直している、という状態にあたる。

このとき N3 の削減は 2.5 × 0.4 = 1.0分となり、当初の1.5分から下がる。N1・N2・N4・N5 の削減4.9分は変わらないため、累計削減は 4.9 + 1.0 = 5.9分である。年間では 96,000 × 5.9 = 566,400分、すなわち 9,440時間。金額では 1,840,800 THB/年となる。

費用側は変わらない。層4も層5も実装済みで、年間運用の1,190,000 THBはそのまま掛かる。したがってケースCの年間純益は 1,840,800 − 1,190,000 = 650,800 THBとなり、回収は 2,200,000 ÷ 650,800 = 3.38年、すなわち 40.6ヶ月に伸びる。

ここで決定的なのは、この650,800 THBという年間純益が、ケースBの698,800 THBを下回るという点である。採用率40%では、層4に560,000 THBを投じて年間360,000 THBを払い続けるより、層4を買わずにBで止めておくほうが利益額が大きい。層4は「効果が薄れる」のではなく、ある採用率を境に投資として成立しなくなる。

その境目は計算できる。本モデルでは1件あたり1分の短縮が年間いくらに相当するかを先に出す。96,000件 ÷ 60 = 1,600時間／分であり、これに195 THBを掛けると 312,000 THBとなる。つまり1分の短縮は年間312,000 THBに相当する。採用率を r と置くと、ケースCの年間純益は 312,000 ×（4.9 + 2.5r）− 1,190,000 である。これがケースBの698,800 THBと等しくなる r を解く。

312,000 ×（4.9 + 2.5r）− 1,190,000 = 698,800 を整理すると 780,000r = 360,000 となり、r = 約46% が得られる。

したがって本稿の結論はこうなる。層4（生成AI判断層）への投資は、判断の採用率が約46%を超えるかどうかが分岐点である。 「5割前後は通るだろう」という感覚値ではなく、自社の業務でこの水準を超える見込みがあるかを、根拠を持って見積もる必要がある。

そして実務上重要なのは、この採用率が投資前に測れるということだ。層1の業務棚卸の段階で、過去の差異案件を数十件サンプリングし、生成AIに推奨を出させて現在の担当者の判断と突き合わせれば、採用率の目安は出る。層4に560,000 THBを投じる前に、この検証に数万THBを使うほうが順序として明らかに安い。採用率が46%を大きく下回るなら、層4は見送ってBで止め、判断基準の明文化を先に進めるという判断になる。基準が明文化されれば採用率は上がるので、層4は「買う」のではなく「成立が確認されてから買う」ものになる。

タイとベトナムで異なる制度の前提

ASEAN域内に複数拠点を持つ企業では、同じ仕組みを横展開する前に制度の前提を確認する必要がある。タイとベトナムでは、2026年8月時点で状況が大きく異なる。この2つを混同した情報が流通しているので、まず現状を正確に押さえる。

ベトナムは施行済みである。 AI法は2025年12月10日に国会で可決され、2026年3月1日に施行された。AIシステムを高・中・低の3段階でリスク分類し、提供者は運用開始前にどの区分に当たるかの評価を完了させる義務を負う。施行前から稼働していた既存システムには経過措置が置かれ、一般分野は12ヶ月、医療・教育・金融は18ヶ月の猶予がある。細則は政令 142/2026/ND-CP（2026年4月30日公布、5月1日施行）で定められ、リスク分類の詳細、AI生成物の表示義務、重大インシデントの 72 時間以内の報告が規定された。この政令はベトナム国内でAI関連活動を行う外国の組織にも適用される。

ここで限定詞を落とさないことが重要である。請求書照合や注文請書の突合といった社内バックオフィス用途は、通常「高リスク」には当たらない。高リスクの用途は、2026年6月30日の首相決定 33/2026/QD-TTg で 46 システムが分野別に列挙され、2026年8月15日から施行される。対象は運輸、民族・宗教、教育、医療、銀行、司法の6分野で、最も多い運輸が 31 システムを占める。重要なのは、これが一覧に載ったものだけを高リスクとして扱う方式だという点である。社内の経理処理を効率化する仕組みはこの一覧に含まれておらず、自動的に高リスク規制の対象になるわけではない。「AIを使えば必ず高リスク規制がかかる」という理解は誤りである。実務として必要なのは、リスク分類の評価を実施して記録に残すこと、AI生成物の表示義務が自社の運用に及ぶかを確認すること、そして重大インシデントの報告経路を72時間以内に回せる形で用意しておくことである。

タイはまだ成立していない。 AIに関する法律は草案段階にあり、2026年8月時点で施行されている包括的なAI法は存在しない。したがって、タイ拠点でAIを業務に組み込む際の法的な土台は引き続きPDPA（個人情報保護法）である。PDPCは 2026年2月17日 に「AIの開発・利用における個人データ保護に関するガイドライン」の草案を公開協議にかけた。このガイドラインは法的拘束力を持たないが、規制当局の期待水準と今後の解釈の方向を示すものとして扱うべきである。草案は、データ処理委託契約にモデル学習への利用禁止を含めること、高リスクなAI利用にはデータ保護影響評価を求めることなどに触れている。

PDPAの行政罰は条項によって上限が異なり、1,000,000 THB、3,000,000 THB、最大 5,000,000 THB の3段階が置かれている。本稿の想定するバックオフィス用途で問題になりやすいのは、同意なき目的外利用と、委託先管理の不備である。生成AIのAPIに帳票を丸ごと送る構成は、この2点に直接触れる可能性がある。

横展開の実務としては、統制・証跡（層5）の設計をベトナム基準に合わせておくのが安い。ベトナムのほうが要求が具体的であるため、そちらに合わせて作れば、タイのガイドラインが将来固まっても手戻りが小さい。逆にタイ基準で作ってからベトナムに持ち込むと、リスク分類の記録とインシデント報告の経路を後付けすることになる。

RPA 生成AI 連携が失敗する6パターン

ここまでの内容を、失敗の形として整理しておく。いずれも実務で繰り返し見られる型である。

パターン1｜RPAを生成AIに置き換えようとする。 N1・N4・N5の定型処理まで生成AIにやらせる設計は、費用が上がり、結果が不安定になり、証跡が増える。この3つのノードはRPAのほうが安く確実である。生成AIは置き換えではなく、RPAが届かないN2・N3に足すものである。

パターン2｜層1を飛ばして機器から入る。 業務棚卸とノード分解をせずにツールを先に決めると、対象業務の範囲が定まらないまま開発が始まる。結果として、シナリオの追加要求が際限なく出て、層2と層3の費用が当初見積もりを超える。280,000 THBを惜しんで数十万THBを失う典型である。

パターン3｜判断の採用率を測らずに層4を買う。 前節のとおり、採用率が約46%を割ると層4は投資として成立しない。採用率は投資前にサンプル検証で測れる。測らずに買うのは、回収の成否を運に任せることと同じである。

パターン4｜証跡の設計を後回しにする。 モデル名とプロンプトのバージョン、承認者、差し戻し理由を残す設計は、稼働後に足すと全経路の改修になる。しかも差し戻し理由を記録していない期間の採用率は事後的に復元できないため、改善のサイクルが1周分遅れる。

パターン5｜自律エージェントに判断を丸投げする。 Gartnerがエージェント型AIプロジェクトの40%超が2027年末までに中止されると予測し、その理由にリスク統制の不足を挙げていることを踏まえれば、承認を人に残さない設計は現時点で回収の見込みが立ちにくい。加えて、エージェント型を標榜するベンダーのうち実体を伴うのは130社程度というGartnerの見方もある。製品選定の段階で、何が自律で何が下書きなのかを明確に切り分けて確認する必要がある。

パターン6｜例外キューを設計せずに稼働させる。 自動化率が上がるほど、人に回る案件は難しいものだけになる。文脈の説明なしに例外が積まれると、1件あたりの処理時間が自動化前より伸びる。生成AIによる例外の要約は、この増分を打ち消すために置く。効果の見積もりに例外処理コストの増分を入れていない試算は、実績と合わなくなる。

90日の進め方

導入は層の順序どおりに進める。90日で全部を稼働させるのではなく、90日で層4を買うかどうかを判断できる状態にすることを目標に置く。

第1〜4週｜測る。 ここで改善に着手しないことが重要である。施策を打つとベースラインが取れず、後から効果を証明できない。実測の粒度は、1件ごとにN1からN5の開始時刻と終了時刻を取ることである。担当者の自己申告でよいが、月末の繁忙期と平常期の両方を含む期間を取る。この4週間で「うちは8.0分ではなく11分だった」といった実態が出てくるが、それでよい。本稿の数値はモデル前提であり、置き換えるべきものである。

第5〜8週｜採用率を検証する。 過去の差異案件を業務の性質に応じてサンプリングし、生成AIに推奨と根拠を出させる。それを当時の担当者の判断と突き合わせ、そのまま承認できたであろう割合を出す。この検証に必要なのは本番環境ではなく、帳票のサンプルと基準の文書だけである。ここで採用率が46%を大きく下回るなら、層4は保留してケースBで止める判断を取る。下回った原因が「基準が文書化されていないため推奨が的外れになる」であれば、基準の明文化を先に進めれば採用率は上がる。

第9〜13週｜基盤を作る。 層2のRPAと層3のAI-OCRを実装し、同時に層5の証跡設計を確定させる。層5を層4より先に置くのは、層4を買う場合に手戻りをなくすためである。この期の終わりに、実測に基づく削減時間と検証済みの採用率が揃うので、層4の投資判断を数字で出せる。

この90日で意図的に外しているのが、対象業務の拡大である。3拠点分を集約している前提でも、最初は1拠点・1帳票種別に絞ったほうが速い。範囲を広げるのは、層4の判断が済んでからでよい。

よくある質問（FAQ）

RPAと生成AIはどちらを先に導入すべきですか

本稿の試算では、RPAだけを先に入れるケースAが最も回収が遅く、58.6ヶ月となった。基盤コストが先に立つ一方、効果が31%で頭打ちになるためである。順序として推奨するのは、RPAとAI-OCRを同じ計画の中で設計し、生成AIの判断層は採用率の検証結果を見てから決めるという進め方である。ただし、どのツールよりも先に来るのは業務のノード分解（層1）である。ここが済んでいないと、RPAも生成AIも対象範囲が決まらない。

RPA 生成AI 連携の費用はどれくらいかかりますか

本稿のモデル（3拠点合算、月間8,000件）では、5層すべてで初期2,200,000 THB、年間運用1,190,000 THBという前提を置いた。層4の生成AI判断層を除いたケースBの構成なら初期1,640,000 THB、年間運用830,000 THBとなる。これは試算であり、拠点数、帳票の種類、既存の基幹システムの状態で大きく変わる。実際の見積もりを取る際は、層ごとに金額が分かれた形で出してもらうことを勧める。一式の見積もりでは、途中で止める判断ができない。

OCRとRPAの連携だけでは不十分ですか

不十分とは限らない。本稿の試算では、RPA＋AI-OCRのケースBが最短回収の28.2ヶ月であり、投資効率の観点では最も良い選択肢である。ただしケースBの1件あたり所要時間は3.1分で、そのうち判断ノードの2.5分がほぼ手つかずに残る。削減率は61%で止まる。この残り3.1分をさらに削るなら生成AIの判断層が要る、という関係になる。判断の採用率が約46%を超える見込みが立たないうちは、Bで止めておく判断に合理性がある。

入力業務の削減はどこまで見込めますか

本稿のモデル前提では、5層すべてを導入したケースCで1件あたり8.0分が1.6分になり、80%の削減となる。年間では10,240時間、金額換算で1,996,800 THBに相当する。ただしこれは判断の採用率を60%と置いた場合の数字であり、採用率が40%に下がると削減は5.9分（74%）、金額では1,840,800 THBになる。100%の自動化を目標に置くべきではない。判断ノードには必ず人の承認が残る設計にしたほうが、統制と回収の両面で結果が安定する。

野良ロボットを増やさずに自動化を広げるにはどうすればよいですか

野良ロボットは、担当者が判断ノードを条件分岐で埋めようとした結果として生まれることが多い。したがって対策は、シナリオの改変を禁止することではなく、判断ノードを条件分岐で埋めなくてよい構造にすることである。具体的には、判断は承認画面で人が行う設計に固定し、RPAのシナリオはN1・N4・N5の定型処理に限定する。そのうえで、シナリオの版管理と棚卸ルールを層5に含めて予算化する。改変を人手のルールだけで止めようとすると、繁忙期に必ず崩れる。

生成AIに判断させた場合、監査で説明できますか

説明できる設計にすることは可能だが、そのための保存項目を最初に決めておく必要がある。最低限、入力データと参照文書、生成AIの出力の全文、モデル名とプロンプトのバージョン、承認者のIDと承認時刻、差し戻し理由の5点である。最も落としやすいのがプロンプトのバージョンで、これがないと過去の判断を再現できない。プロンプトはソースコードと同じ扱いで版管理する。加えて、最終決定を人の承認に残しておけば、説明責任の所在が明確になり、監査対応の負荷は大きく下がる。

まとめ

RPAの自動化率が頭打ちになるのは、例外が多いからではない。業務フローの中に判断が混ざっているのに、RPAは判断ができないからである。本稿のモデルで処理を5ノードに割ると、RPAが単独で担えるのはN1・N4・N5の2.5分、全体の31%にすぎなかった。残る約69%は「読む」（N2）と「決める」（N3）であり、どちらもRPAの守備範囲の外にある。

生成AIを繋ぐ場所は3か所に限られる。抽出の補助、判断の下書き、例外の説明である。いずれも決定権を人に残したまま、担当者の作業を「調べて考える」から「読んで決める」に変える接続である。RPAを生成AIに置き換える設計には、費用の面でも統制の面でも合理性がない。

金額で見ると結論は逆説的になる。本稿のモデル前提では、RPAだけを先に入れるケースAの回収が58.6ヶ月で最も遅く、RPA＋AI-OCRのケースBが28.2ヶ月で最短、生成AIまで含めたケースCが32.7ヶ月で、年間純益は806,800 THBと最大になった。「まずRPAだけ小さく始める」という一見手堅い順序が、実は最も回収の悪い選択になりうる。基盤コストが先に立つ一方で、判断ノードを触らない限り効果が31%で止まるからである。ただしBを選ぶ場合でも、層1の業務棚卸を省略してはならない。

層4への投資は、判断の採用率が分岐点になる。本モデルでは1分の短縮が年間312,000 THBに相当し、ケースCの年間純益がケースBと並ぶ採用率は約46%と計算される。採用率が40%まで下がるとケースCの年間純益は650,800 THBとなり、ケースBの698,800 THBを下回る。この46%という数字は、投資前にサンプル検証で見積もれる。

制度面では、ベトナムのAI法が2026年3月1日に施行済みである一方、タイのAI法はまだ成立していない。ベトナムではリスク分類の評価と重大インシデントの72時間報告が求められるが、高リスクは首相決定33/2026/QD-TTgで列挙された46システムに限られており、請求書照合のような社内バックオフィス用途はこれに当たらない。タイの土台はPDPAであり、PDPCが2026年2月17日にAIに関するガイドライン草案を公開協議にかけた段階である。

自社の業務が実際に何分で、どのノードに時間が偏っているかを把握していない段階でも、進め方の相談は可能である。どのノードから測り始めるか、判断の採用率をどうサンプル検証するか、といった点だけでも整理しておくと、投資判断の精度は上がる。現場の条件に合わせた設計についてはお問い合わせから気軽に声をかけてほしい。

参考情報

• Gartner 2027年末までにエージェント型AIプロジェクトの40%超が中止されるとの予測
• 日立ソリューションズ RPA導入後のリプレイス（再検討）に関する意識調査 2021年2月実施、回答100名
• UiPath エージェンティックオートメーションにおけるRPAの位置づけ
• ベトナム 政令142/2026/ND-CP AI法の施行細則 英訳
• Atsumi & Sakai ベトナムAI法施行政令の要点
• ベトナム 首相決定33/2026/QD-TTg 高リスクAIシステム46件の一覧
• Tilleke & Gibbins タイのAIガバナンス枠組み
• タイPDPC AIにおける個人データ保護ガイドライン草案の公開協議