【テンプレート付】RPAの要件定義｜機能要件・非機能要件チェックリストと進め方

RPAの要件定義とは

RPAにおける要件定義とは、自動化する業務プロセスを操作手順レベルまで分解し、対象アプリケーションの画面構造・例外パターン・処理件数・実行スケジュールを明文化する作業です。単なる「業務の効率化」ではなく、ロボットがどの画面のどのボタンを、どの条件で、どの順序で操作するかを定義します。あわせて、エラー停止時のリカバリ方法や有人確認の境界線まで決めておくことが、安定稼働するシナリオの前提条件になります。

なぜ要件定義でRPA導入の成否が決まるのか

RPAは人間の画面操作を模倣する仕組みのため、対象システムのUI変更や想定外データに極端に弱く、要件定義で例外と変動要因を洗い出せていないと本番で頻繁に停止します。自動化に向く業務かどうかの見極めを誤ると、開発したシナリオが「動くのに使えない」状態になります。

• 業務が標準化されておらず例外パターンが多いままシナリオ化し、保守不能な分岐だらけのロボットになる
• 対象システムのUI変更やWindows・ブラウザ更新で画面認識がずれ、誰も気づかないまま全件処理が停止する
• 処理件数や実行時間帯の見積もりが甘く、深夜バッチが終わらない・他業務とライセンスを奪い合う
• 現場が勝手に作った野良ロボットが乱立し、ID・パスワードや権限の管理が破綻してガバナンスが効かなくなる

要件定義で決める5つの範囲

1. 自動化対象業務 — 受注入力・請求書発行・在庫データ転記など、ロボット化する具体的な業務とその範囲を確定する
2. 操作対象アプリ — 基幹システム、Excel、Webブラウザ、メールなど、ロボットが操作する画面とその認識方式を特定する
3. 実行環境と方式 — デスクトップ型かサーバ型か、有人実行か無人スケジュール実行かを定義する
4. 例外・エラー処理 — 想定外データ、画面遅延、ログイン失敗時の停止・再試行・通知の挙動を定める
5. 運用・統制 — シナリオの変更管理、稼働監視、ID管理、内部統制対応など導入後の運用体制を含める

RPAは「人がやっている操作の置き換え」のため、対象業務の前後にある手作業の判断や紙の処理まで含めて範囲を切らないと、自動化が途中で分断されて効果が出ません。

要件定義の進め方：5ステップ

ステップ	内容	アウトプット
①	対象業務の棚卸しと選定。定型・大量・ルール明確の観点で自動化候補を洗い出し、ROIと難易度で優先順位を付ける	業務一覧と自動化優先度マトリクス
②	現行業務の操作手順を可視化。クリック・入力・転記の単位までToBeフローに分解し、例外分岐を列挙する	業務フロー図・操作手順書（PDD）
③	対象アプリの技術調査。画面要素の認識方式（属性指定・画像認識）、ログイン方式、処理件数・実行時間帯を確認する	対象システム一覧・技術制約メモ
④	機能・非機能要件の定義。シナリオ仕様、エラー処理、実行スケジュール、ID管理、監視方法を文書化する	要件定義書・ロボット設計書（SDD）
⑤	PoC・小規模検証。代表業務でロボットを試作し、認識安定性と例外発生率を実測して本番要件に反映する	PoC結果報告・効果試算の見直し

KPIは「削減工数（時間／月）」だけでなく、シナリオの稼働成功率・エラー停止からの平均復旧時間・1件あたり処理時間を必ず設定し、導入後の運用品質まで測れるようにします。

機能要件チェックリスト（RPAの核心）

RPAに求める代表的な機能要件です。自社の状況に照らして「必須／任意／不要」を判断してください。

大分類	主な要件項目
シナリオ作成・編集	ローコードのフロー設計画面, レコーディング機能（操作記録）, 変数・引数の定義, 共通部品（再利用ライブラリ）の管理
画面・要素認識	UI要素のセレクタ（属性）指定, 画像マッチング認識, OCRによる文字読み取り, 動的に変わる要素の待機・リトライ制御
アプリケーション操作	Webブラウザ自動操作, Excel・CSV読み書き, デスクトップアプリ操作, レガシー端末エミュレータ操作
データ処理・連携	Excel／DBからの読み込み, データ整形・突合, 入力値のバリデーション, 処理結果のファイル・DB書き出し
実行制御・スケジューリング	日次・時刻指定の無人実行, トリガー実行（メール受信・ファイル到着）, キュー管理による処理分散, 複数ロボットの並列・順次実行
例外・エラーハンドリング	業務例外とシステム例外の切り分け, 自動リトライ回数の設定, 異常時のスクリーンショット取得, 担当者への自動通知
ログ・監査証跡	操作ステップ単位の実行ログ, 処理件数・成功失敗の記録, 操作した値の証跡保存, ログの保管期間設定
集中管理・オーケストレーション	ロボットの稼働状況ダッシュボード, シナリオの集中配布・バージョン管理, ライセンス（実行枠）の割当, リモートでの起動・停止
資格情報・ID管理	ログインID・パスワードの暗号化保管（資格情報ストア）, 権限ロールの設定, 認証情報のロボットへの安全な受け渡し, パスワード定期変更への追従
有人連携（Attended）	従業員のPC上での手動起動, 処理途中での入力ダイアログ表示, 人の判断を挟むステップの設計, 業務システムとの画面共存

見落としがちな要件: 見落としがちなのは、二要素認証やCAPTCHAへの対応、画面ロック・スクリーンセーバー解除、複数ロボットが同一IDで同時ログインできない制約への対処です。これらは要件段階で対象システムの認証仕様を確認しておかないと、無人実行が成立しません。

非機能要件で見落としがちなポイント

機能だけに目が向きがちですが、非機能要件こそ稼働後の満足度を左右します。

区分	確認すべき要件（目標値の例）
性能	1シナリオの処理時間と1件あたり処理速度（例: 請求書1件30秒以内、夜間2,000件を5時間以内に完了）
可用性	実行サーバ・ロボットの稼働率と障害時の代替実行（例: 稼働率99%、特定ロボット障害時は別ロボットへ自動振替）
拡張性	ロボット台数・対象業務数の増加への対応（例: 実行ライセンスをサーバ無停止で追加でき、50業務まで集中管理可能）
セキュリティ	資格情報の暗号化と操作ログの保護（例: パスワードはストアで暗号化保管、ログは改ざん検知付きで90日保管）
運用保守	シナリオ変更の容易性と監視体制（例: UI変更時の修正を2営業日以内、稼働状況を管理画面で常時監視）
移行	既存の手作業・マクロからの移行と並行稼働（例: 1か月の人手との並行稼働で結果を全件照合してから切替）
コンプライアンス	内部統制・職務分掌への適合（例: ロボット操作を人手と区別して証跡化し、J-SOX監査で承認・実行の分離を説明可能にする）

RPAは対象システムのバージョンアップで突然動かなくなるため、非機能要件には「保守のしやすさ」と「UI変更検知の仕組み」を必ず含めます。

基幹・周辺システムとの連携要件

どのシステムと、何を、どの方式（API/CSV/EDI）で、どの頻度で連携するかを定義します。

連携先	主な連携内容
基幹システム（ERP・販売管理）	受注・請求データの画面入力と帳票出力をロボットが代行し、APIがない画面操作部分を自動化する
Excel・ファイルサーバ	台帳やCSVを読み込み、整形した結果を所定フォルダへ出力する。RPAの最も典型的な連携先
メール・グループウェア（Outlook等）	添付ファイルの受信をトリガーに処理を起動し、完了・エラー結果を担当者へ自動送信する
Webシステム・社外ポータル	金融機関サイトや取引先ポータル、行政の電子申請画面へログインしてデータ取得・登録を行う
OCR・AI-OCRサービス	紙の注文書・請求書をOCRで読み取り、その結果をRPAが基幹システムへ転記する
BIツール・データベース	処理実績や稼働ログをDBへ蓄積し、BIツールで削減効果や稼働成功率を可視化する

API連携が可能なシステムは、画面操作のRPAより安定するため、要件定義の段階で「API化できる部分はAPI、できない部分のみRPA」と切り分けることが重要です。

RFP（提案依頼書）に盛り込むべき項目

要件が固まったら、ベンダーへの提案依頼書（RFP）にまとめます。最低限、次の項目を含めます。

• 自動化対象業務の一覧と各業務の処理件数・実行頻度・対象アプリケーション
• 実行方式の要件（デスクトップ型／サーバ型、有人／無人、必要な同時実行ライセンス数）
• 対象システムの認証方式・UI変更頻度などの技術前提と既知の制約
• 求める機能要件（OCR連携、集中管理、資格情報管理、例外処理など）の優先度
• 保守・運用支援の範囲（シナリオ改修の対応時間、内製化支援、トレーニングの有無）
• ライセンス体系と総保有コスト（ロボット台数・管理サーバ・年間保守費を含む見積条件）

RFPには「対象システムのUI変更時にどちらが・どれくらいの期間で修正するか」という保守条件を必ず明記し、見積もりの前提を揃えます。

ベンダーを横並び比較する評価マトリクス

ベンダー評価は、製品の機能網羅性だけでなく、対象システム（特にレガシー端末や社外サイト）での認識実績、UI変更への保守体制、内製化支援の手厚さに重みを置いて配点します。価格の安さだけで選ぶと、運用フェーズの改修費用や停止リスクで結局割高になります。

PoCを評価プロセスに組み込み、自社の実業務でロボットが安定稼働するかを実測してから本契約に進むべきです。

RPA導入でよくある失敗と回避策

よくある失敗	原因	回避策
導入後すぐにロボットが頻繁に停止する	対象システムのUI変更や想定外データを要件で洗い出せておらず、例外処理が不足していた	PoCで実データを流して例外発生率を実測し、リトライ・通知・有人切替の挙動を要件に組み込む
効果が出ない業務を自動化してしまった	処理件数が少ない、または判断が多い非定型業務を、ROIを試算せず勢いで対象に選んだ	定型・大量・ルール明確の基準で対象を選定し、削減工数とライセンス費を比較してから着手する
野良ロボットが乱立し管理不能になった	現場主導で個別にシナリオを作り、変更管理・ID管理・棚卸しのルールを要件で定めていなかった	集中管理ツールでシナリオとアカウントを一元管理し、開発・本番の運用ルールを最初に整備する
内製化できず保守がベンダー丸投げになった	シナリオの設計標準やドキュメント（PDD・SDD）整備、社内人材育成を要件に含めなかった	命名規則・共通部品・設計書のテンプレートを要件化し、要件定義段階から社内担当者を巻き込んで育成する

チェックリストの使い方（テンプレートとして使う）

本記事の機能要件・非機能要件・連携要件・評価マトリクスの各表は、そのまま要件定義の雛形（テンプレート）として使えます。表をコピーして自社に必要な項目の「要否」「優先度」を記入し、ベンダー回答を並べて比較してください。

1. 各表で自社に必要な項目の要否（必須/任意/不要）と優先度を記入する
2. 不足する自社固有の要件を追記する
3. ベンダー回答（○標準/△設定・追加開発/×不可）を記入する
4. 評価マトリクスで重みと評点を入れ、加重スコアで横並び比較する

※ 記入と加重スコアの自動集計ができるExcelテンプレート（ダウンロード版）は近日公開予定です。