RPAシナリオとは？作り方の基本と設計時の注意点

RPAシナリオとは、ロボットに実行させる処理手順と判断条件を具体的に記述したものです。良いシナリオは操作を再現するだけでなく、例外処理や保守のしやすさまで見込んで設計されています。本記事では特定のRPA製品の操作説明ではなく、コンサルタントの歩み編集部の独自調査・取材をもとに、業務プロセス側から見たシナリオ設計の勘所を整理します。

RPAシナリオとは何か

RPAシナリオとは、ロボットに実行させる処理手順と判断条件を、RPA製品の機能を使って具体的に記述したもののことです。

総務省がまとめた「自治体におけるRPA導入ガイドブック」（令和7年7月）は、RPAができる処理について、システム上の入力やボタン操作、データの照合・変換などを組み合わせて手順を定義できるとした上で、この処理手順や判断の条件を製品の機能で具体的に記述したものを「シナリオ」と呼ぶと説明しています（出典：同資料、p.26）。つまりシナリオは、単なる操作の記録ではなく、どの条件でどう分岐するかまで含めた設計図にあたります。

ロボットに実行させる処理手順の定義

シナリオには、画面操作の手順だけでなく、判断が必要な場面での条件分岐まで書き込む必要があります。

同ガイドブックが示す代表的な処理内容は、検索・参照、転記・登録、集計・集約、抽出・仕訳、加工・変換、照合の6種類です（出典：同資料、p.26）。実際の業務では、これらの処理を「システムを起動する」「検索画面に遷移する」「検索条件を入力する」「結果を確認する」といった細かい単位まで分解し、順番どおりに実行させる形でシナリオに落とし込みます。判断を伴う工程がある場合は、その判断基準をあらかじめ言葉で明文化しておくことも欠かせません。判断基準があいまいなまま設計に着手すると、想定していなかったデータに出会った時点でロボットが止まってしまいます。

マクロ・スクリプトとの違い

RPAシナリオは、特定のアプリ内だけで完結するマクロと異なり、複数のシステムをまたいだ操作を横断的に自動化できる点が異なります。

Excelのマクロ（VBA）は基本的にExcelというアプリケーションの中で完結する処理を得意とし、汎用スクリプト（PythonやPowerShellなど）はAPIやコマンドラインを介した処理に向いています。これに対しRPAシナリオは、業務システムの画面・Webブラウザ・Excel・メールなど、人が画面上で操作しているものをまたいで一連の流れとして自動化できる点が特徴です。

プログラミング未経験でも着手しやすい一方、条件分岐や繰り返し処理、変数といった考え方は共通して必要になるため、ある程度の設計能力は求められます（出典：同資料、p.42）。

シナリオ設計の基本ステップ

シナリオ設計は、対象工程を洗い出す棚卸しと、例外時の挙動を決める設計という2段階で進めるのが基本です。

製品の操作画面を開く前にこの2段階を済ませておくかどうかで、後戻りの量が大きく変わります。総務省のガイドブックも、シナリオ作成の前段階として現行の処理フローを紐解き、自動化後の処理フローをあらかじめ具体化しておくことで、シナリオ作成段階での手戻りを少なくできると指摘しています（出典：同資料、p.35）。

業務フローの棚卸しと対象工程の切り出し

棚卸しでは、現状の処理手順を工程ごとに分解した上で、判断を伴わず繰り返し発生する部分だけを自動化の対象として切り出します。

対象業務を選ぶ判断基準として、同ガイドブックは「定型的で複雑な判断を要しない業務」「大量の処理を繰り返し行う業務」「処理対象が安定しており変化が少ない業務」「入力情報が電子化されている、または電子化できる業務」の4点を挙げています（出典：同資料、p.28 表3-2）。反対に、都度の判断や例外対応が多い業務、仕様が頻繁に変わる業務は、シナリオが不安定になりやすい傾向があります。

コンサルタントの歩み編集部の独自調査・取材によれば、シナリオ設計でつまずく企業の多くは、製品の操作方法ではなくこの棚卸し工程を省略してしまうケースです。処理フローを具体化しないままシナリオ作成に入ると、画面のどの項目をどの順番で入力するのかという詳細が定まらず、作成途中で何度も設計をやり直すことになります。

下の表は、経費精算データの入力業務を題材にした棚卸しのイメージです（架空の例です）。

判断が必要な工程だけを人に残し、それ以外を機械的な処理として切り出すのが棚卸しの基本的な考え方です。対象工程を切り出す前提として、業務のやり方が担当者ごとにばらついている場合は、自動化の前提となる業務の型化を先に済ませておく必要があります。手順が担当者によって異なる状態のままシナリオ化すると、特定のやり方しか処理できないロボットになってしまいます。

例外処理・エラーハンドリングの設計

例外処理の設計とは、想定外の入力やシステムの停止が起きた際に、処理を止めて人の判断を挟む分岐をあらかじめ用意しておくことです。

総務省のガイドブックは、シナリオが思いどおりに動いたとしても、想定外の入力データや業務システムの停止・応答遅延といったイレギュラーなケースに備え、例外処理のシナリオをあわせて作成する必要があると述べています。その際、自動化する処理フローの内容に応じて、無理に処理を継続しようとせず、職員の判断を入れるなどの安全対策を取ることが推奨されています（出典：同資料、p.42-43）。開発標準としても、業務システムのデータ更新を伴うシナリオでは、更新前に入力データや画面表示をチェックし、想定外の状況では自動処理を止めて人に確認を求めるか、処理をスキップして後から確認できるようにする設計が挙げられています（出典：同資料、p.49 表4-3）。

例外処理を作り込まずに公開してしまうと、一見動いているように見えても、想定外のデータに出会った瞬間に誤った更新をしてしまうリスクが残ります。自動化によって得られる効果と、うまく設計できなかった場合に生じるリスクを、着手前の段階で整理しておくことが欠かせません。

シナリオ作成でよくある失敗

よくある失敗は、特定の担当者しか分からない手順のまま自動化してしまう属人化と、保守を考えない複雑な設計という2つに大別されます。

属人的な手順をそのまま自動化してしまう

属人的な手順とは、特定の担当者の頭の中にしかない判断基準や操作の癖を、確認しないままシナリオに埋め込んでしまう状態を指します。

総務省のガイドブックは、シナリオ作成・保守を内製化している場合、担当職員の異動や退職によって内部構造が分からなくなり、メンテナンスができなくなることがないよう準備が必要だと指摘しています（出典：同資料、p.46）。実際に、ある団体の事例として、RPAを利用していた職員の異動後に運用が引き継がれず、シナリオのメンテナンスができなくなって利用を中止したケースが、総務省「地方自治体におけるAI・RPA実証実験・導入状況等調査」の調査結果として紹介されています（出典：同資料、p.52）。

属人化を避けるためには、シナリオの仕様や操作方法を文書として残し、特定の担当者だけに依存しない体制にしておくことが重要です（出典：同資料、p.46）。設計段階でヒアリングする相手を1人に絞らず、複数の担当者から手順の揺れがないかを確認しておくことも有効な予防策になります。

メンテナンス性を考慮しない設計

メンテナンス性を考慮しない設計とは、1本の長大なシナリオに処理を詰め込み、変数名も分かりにくいまま残してしまう状態です。

総務省のガイドブックは、シナリオの完成度を高める観点として、繰り返し実行する処理をサブルーチン化して部品として呼び出しやすく定義し、シナリオの冗長化・長大化を避けること、処理や変数の名称を分かりやすいものにして作成者以外でも内容を把握できるようにすることを挙げています（出典：同資料、p.42-43）。開発標準としても、RPAの仕様や操作方法の文書化、変数の扱いや命名規則といった開発規約の遵守、動作を確認できる記録を残すことが定義されています（出典：同資料、p.49 表4-3）。

保守性を軽視して作られたシナリオは、一見完成しているように見えても、業務システムの画面が少し変わっただけで丸ごと作り直しになりかねません。1つの長い流れとして作るのではなく、工程ごとに部品化しておくことで、変更が必要な部分だけを直せる状態を保てます。

シナリオ設計を外部の専門家に依頼する場合の視点

外部の専門家に依頼する際は、操作手順だけでなく業務の目的まで伝えられるヒアリング範囲の設計が成否を分けます。

要件のヒアリング範囲

要件のヒアリング範囲とは、自動化したい操作そのものだけでなく、その処理が生まれた業務上の目的まで含めて確認する範囲を指します。

総務省のガイドブックは、シナリオ作成・保守の体制について、外部事業者への委託、情報システム部門による内製化、業務担当部門による内製化という3パターンを挙げた上で、複雑なシナリオは委託し、それ以外は内製化するといった組み合わせも有効だとしています。あわせて、業務の内容・プロセスに関する知見と、IT・RPAに関する知識・スキルの両方を融合させることが体制整備の要点になるとも述べています（出典：同資料、p.30-31）。外部の専門家に依頼する場合も同様で、操作手順の再現だけを請け負う関係では、業務側の目的が抜け落ちたシナリオになりがちです。

実務では、こうした設計支援を独立コンサルタントが単発で受注するケースも見られます。発注企業の規模によっては、担当者と直接契約するのではなく、エージェントを介した3者間契約という形を取ることが多いとされます（出典：ドメイン知識ベース「案件獲得の基本ルート」）。RPA案件を探す視点を持って複数のエージェントに登録しておくと、操作の代行だけでなく業務の目的まで聞き取るタイプの案件に出会いやすくなります。

運用保守を見据えた設計レビュー

運用保守を見据えた設計レビューとは、納品後に自社だけで直せるかどうかを、外部要因への対応力まで含めて設計段階で確認しておく工程です。

総務省のガイドブックは、RPAのシナリオ作成・保守を業務担当課の職員が担う場合、保守性や安全性の確保状況について、専門かつ第三者的な立場から内容を確認し検証を行うことが望ましいと述べています（出典：同資料、p.48）。また、開発のルールとして、シナリオ作成・保守に着手する時、本番環境でのテストを開始する時、実運用を開始する時のそれぞれで、報告と承認を要するタイミングをあらかじめ定めておくことも推奨されています（出典：同資料、p.49 表4-2）。

外部の専門家にシナリオ設計を依頼する場合は、納品物そのものだけでなく、この報告・承認の区切りと、保守を誰がどこまで担うのかという範囲を、契約前のレビュー観点として確認しておくと、納品後に「動かなくなったが誰も直せない」という事態を避けやすくなります。

まとめ：シナリオ設計は業務理解が9割

RPAシナリオ設計で最終的に問われるのは、製品の操作を覚える力ではなく、対象業務を理解し例外まで見通す力です。

良いシナリオは、業務フローの棚卸しで対象工程を的確に切り出し、例外処理まで含めて設計し、属人化と保守性の低さという2つの失敗を避けることで初めて成立します。外部の専門家に依頼する場合も、評価すべきは操作の再現力ではなく、業務の目的まで理解した上でヒアリングと設計レビューができるかどうかです。製品の操作を覚えることよりも、まず自社の業務プロセスを正しく理解することが、最も確実な近道になります。

出典・参考情報

1. 総務省「自治体におけるRPA導入ガイドブック」（令和7年7月）（2026-09-08参照）

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