RPA開発とは何か？内製と外注の違いと進め方

RPA開発とは、日々の定型的なパソコン操作をソフトウェアロボットに任せられるよう、業務の処理手順を「シナリオ」として設計・実装していく一連の工程を指します。本記事では、RPA開発の内製と外注それぞれの向き不向き、基本的な進め方、つまずきやすいポイント、効果測定の考え方までを、現場に伴走する独立コンサルタントの視点で整理します。

RPA開発とは—「導入」と「開発」の違いを整理する

RPA開発とは、RPAツールを導入した後に、実際の業務を自動化するための処理手順（シナリオ）を設計・作成する工程を指します。単なるツールの導入と混同されがちですが、両者は明確に異なる段階です。

「RPA導入」がRPA製品を選定・調達する意思決定のフェーズを指すのに対し、「RPA開発」はその後、業務担当者が普段行っている操作を分析し、繰り返し処理や条件分岐を含む手順として定義し直す作業を意味します。総務省の資料では、RPAを「パソコン上の操作を認識・記録し、処理のルールを定義した『シナリオ』に沿って、複数のアプリケーションを使用する業務を自動化するツール」と説明しており（出典：総務省「自治体におけるRPA導入ガイドブック」令和7年7月、p.14）、この「シナリオ」の設計・実装こそがRPA開発の中核です。RPA開発は、DX戦略における業務自動化の位置づけの一部として語られる場面も増えています。

シナリオ設計・実装という開発工程の中身

シナリオ設計・実装とは、自動化したい処理をフローチャートのような形式で定義し、実際に動作する手順へ落とし込む作業です。

総務省のガイドブックでは、シナリオ作成の代表的な手法として「レコーディング」（画面操作を記録して自動生成する方法）、「部品化された機能の利用」（Excel操作や文字列処理などをパッケージ化した部品を組み合わせる方法）、「個別編集」（フローチャート上で処理順序や条件分岐を個別に設定する方法）の3つを挙げています（同資料、p.42）。実装したシナリオは、想定外の入力データや対象システムの応答遅延といったイレギュラーな状況を考慮したテストを経てから本稼働に移すのが基本の流れです。

システム開発との違い

RPA開発とシステム開発の最大の違いは、必要なコストと期間、そしてプログラミングスキルの要否にあります。

総務省の資料でも、業務システムの開発は大規模な内容だと1年以上の期間と、開発費やデータの移行等を伴う大きなコストが必要になる一方、RPAは数週間〜数ヶ月程度、比較的小〜中規模のコストで導入できるとされています（出典：同資料、p.14 表2-1）。既存の業務システムを改修するほどの処理件数がない業務や、複数のシステムをまたぐ操作を自動化したい場合に、RPA開発が選択肢となりやすいといえます。システム開発全体の流れとの関係については、システム開発とRPA開発の違いを解説した記事もあわせてご参照ください。

RPA開発の内製と外注、それぞれのメリット・課題

RPA開発は、社内人材が担う「内製」と、外部の専門事業者に任せる「外注」のいずれか、あるいは両者の組み合わせで進めるのが一般的です。どちらを選ぶかによって、必要な体制やコスト構造、定着のしやすさが変わります。

内製化に必要な体制・スキル

内製化には、シナリオ作成スキルを持つ人材の育成と、業務内容に詳しい担当者との連携体制が欠かせません。

総務省のガイドブックは、シナリオの作成・保守を「外部事業者に委託する」「情報システム部門の職員が内製化する」「業務担当部門の職員が内製化する」の3パターンに整理した上で、複雑なシナリオは外部委託で作成し、それ以外は内製を基本とするといった組み合わせも有効だとしています（出典：同資料、p.30）。また、シナリオ作成は視覚的に行えてプログラミングよりは平易とされる一方、繰り返し処理や条件分岐、変数の扱いといった基礎的な素養は必要になるため、内製化を目指す場合は継続的な人材育成と要員確保が前提になる、とも指摘されています（出典：同資料、p.31）。

自社開発（内製）の利点として、外部ベンダーへの発注コストがかからない点、トラブル発生時に社内ですぐに対応できる点が挙げられる一方、社内にRPAに精通した人材がいない場合は育成の時間と手間がかかり、外部委託に比べて開発自体に時間を要する可能性がある、という指摘もあります（出典：日立ソリューションズ「RPA開発は誰がする？自社開発可能かや手法、ポイント」）。

外注時に発生しやすい認識齟齬

外注時によく起きるのは、開発を依頼した時点の業務理解と、実際にシナリオが動く現場の業務との間にズレが生じ、引き継ぎの段階でつまずくというパターンです。

総務省の資料でも、実運用を開始する際は「特にシナリオ作成を外部事業者に委託した場合は、操作方法とあわせて確実に引き継ぎを受けるようにしましょう」と注意喚起しており（出典：同資料、p.44）、外部事業者に任せきりにしてしまうと、シナリオの仕様や操作方法が現場に正しく引き継がれないリスクがあることを示しています。将来的に内製化も視野に入れているのであれば、雛型となるシナリオの作成だけを委託し、以降の改修は社内で担うといった役割分担を、発注時点であらかじめすり合わせておくことが有効です。

RPA開発の基本的な進め方

RPA開発は、対象業務の選定、シナリオ設計、テスト、本稼働という順序で進めるのが基本的な流れです。

1. 対象業務の選定と適合性判断
2. 処理フローの整理とシナリオ設計
3. シナリオの作成とテスト
4. 実運用の開始と効果検証

対象業務の選定と適合性判断

RPA開発の成否は、自動化する対象業務の選び方によって大きく左右されます。

総務省のガイドブックが示す判断基準では、「定型的で複雑な判断を要しない業務」「大量の処理を繰り返し行う業務」「処理対象が安定しており変化が少ない業務」などが、RPAに適した業務として挙げられています（出典：同資料、p.28 表3-2）。反対に、判断のたびに例外対応が必要な業務や、対象システムの仕様が頻繁に変わる業務は、開発後のシナリオが不安定になりやすく、適合性が低いといえます。

シナリオ設計からテスト・本稼働までの流れ

シナリオの作成後は、必ず本番と同等の環境でテストを行ってから本稼働に移す流れが基本です。

総務省の資料では、テストの観点として「実データまたは実データに近いデータを使ったテストを行う」ことと「1件当たりの実行時間を計測する」ことを推奨しています（出典：同資料、p.43）。実際に、ある団体では1件あたりの処理に平均2分を要することが判明し、当初の想定件数をこなすためにRPAを追加導入した事例も紹介されており（出典：同資料、p.43 コラム）、想定以上に処理時間がかかるケースがある点は開発段階で織り込んでおくべきポイントです。

RPA開発でつまずきやすいポイント

RPA開発でつまずきやすいのは、開発時ではなく、稼働を始めたあとの運用フェーズであることが少なくありません。

対象システムの仕様変更によるシナリオ停止

RPAは操作対象のシステムの画面構成や仕様が変わると、シナリオが正常に動かなくなるという性質を持っています。

総務省の資料は「潜在的な不具合や外部の仕様変更により停止・誤作動が起きる可能性は完全には排除できない」と述べており（出典：同資料、p.51）、実際にRPA導入を取りやめた事例として「RPAを導入した業務は制度改正が頻発しており、シナリオの修正が追い付かず利用をやめてしまった」というケースも報告されています（出典：同資料、p.52）。制度改正やシステム更改の予定をあらかじめ把握し、対象業務の選定段階から見通しを立てておくことが、シナリオ停止のリスクを抑える手がかりになります。

RPA定着化を支援する独立コンサルタントの役割

RPA開発を一度きりで終わらせず、社内に定着させるには、開発と並行して運用体制を整える視点が欠かせません。

コンサルタントの歩み編集部が独立系コンサルタントへの取材で確認した範囲でも、RPA開発の相談で多く挙がるのは「作った直後」ではなく「担当者が異動した後にシナリオを保守できる人がいなくなった」という運用フェーズの悩みでした。総務省の資料でも、RPAを導入したものの取りやめた事例として「RPAを利用していた職員の異動後、後任の担当者に運用が引き継がれずRPAの利用をやめてしまった」というケースが紹介されています（出典：同資料、p.52）。

RPA開発の定着支援を担う独立コンサルタントの単価は、DX・IT領域のコンサルティング相場に近く、月額100万円台が中心的なレンジとされていますが、要件整理や体制設計まで含む上流工程を担う場合は150万円を超える水準に上振れすることもあります（出典：ドメイン知識ベース「DX・ITコンサルの月額単価相場」）。より詳しいRPA導入支援案件の単価感については、こちらの記事も参考になります。

現場担当者の運用スキル移管の進め方

運用スキルの移管は、外部事業者やITスキルの高い担当者だけにシナリオの保守を委ねず、複数人が扱える状態を作ることから始まります。

総務省のガイドブックは、外部委託を活用する場合でも「委託を完全に委ねるだけでなく、雛型となるサンプルシナリオの作成や、時間契約で助言を受ける、ハンズオン支援を依頼するなどの活用のしかたも考えられる」とし、将来的に内製化も視野に入れる場合は「外部事業者に任せきりにならない方法を検討するのが望ましい」と述べています（出典：同資料、p.31）。独立コンサルタントが伴走する場合も同様に、シナリオを丸ごと引き受けるのではなく、雛型の作成と操作方法の可視化・文書化を担い、日々の軽微な修正は現場担当者が対応できる状態に整えていく進め方が、定着化の観点では有効といえます。

RPA開発の効果測定の考え方

RPA開発の効果は、削減できた時間などの定量面と、業務の見直しが進んだかといった定性面の両方から把握する必要があります。

定量・定性の両面での効果把握

定量的な効果指標としては「年間削減時間」「業務時間削減率」「過誤の減少件数」などがあり、算定する際は自動化によって短縮された時間だけでなく、RPAの処理前後に発生する準備・確認作業の時間も見積もった上で判断する必要があります（出典：同資料、p.34-35 表3-3）。

一方で、業務プロセスの可視化が進んだことや、担当者の負担が軽減されたことなどの定性的効果は直接計測しづらいため、業務担当者へのインタビューやアンケートを通じて把握する方法が有効だとされています（出典：同資料、p.44）。実際にRPA導入で成果を上げている自治体の事例でも、人口規模の小さい町村から大規模な市まで幅広く年間数百時間規模の削減効果が報告されており（出典：同資料、p.15 表2-2）、定量的な効果を測る仕組みを最初に用意しておくことが、その後の投資判断や横展開の説得材料にもなります。

出典・参考情報

1. 総務省「自治体におけるRPA導入ガイドブック」（令和7年7月）（2026-09-08参照）
2. 株式会社日立ソリューションズ「RPA開発は誰がする？自社開発可能かや手法、ポイント」（2026-09-08参照）

本記事は2026年9月時点の情報に基づいています。