RPAの設計書の書き方｜記載項目と開発・運用で困らない作り方

RPA設計書は、ロボットの処理を「業務の目的」「処理の流れ」「例外時の動き」の3点で書き、開発後に運用担当が読んで直せる状態にしておく文書です。画面操作を1クリックずつ並べるだけでは、担当が替わった途端に誰も触れないロボットになりがちです。

本記事では、RPA開発を担当するエンジニアや業務担当の方に向けて、2026年10月時点の実務を前提に、設計書の役割、記載する項目、書き方のポイント、請求書処理とデータ転記の記載例、レビューの観点、更新の運用までを順に整理します。RPA開発そのものの基礎はRPA開発の基礎知識で解説しています。

RPA設計書の役割

RPA設計書とは、ロボットが何の業務をどの順序で処理し、うまくいかないときにどう振る舞うかを、開発者以外にも読める形で残した文書です。

開発と運用での使われ方

設計書は、開発では「何を作るか」の合意資料、運用では「止まったときに原因を探す地図」として使われます。

• 開発時：業務担当と開発者が、対象業務と処理範囲の認識を揃える資料になります。
• テスト時：期待する結果の基準になり、動作確認の観点を決める元になります。
• 運用時：エラーが出たときに、どの処理で何が起きたかを追う手がかりになります。
• 引き継ぎ時：作成者が離れても、保守担当が仕様を理解する唯一の窓口になります。

開発者本人は頭の中で補えるため、設計書が粗くても困りません。困るのは半年後に初めて触る保守担当です。設計書は、その人が読む前提で書くのが基本です。

他の設計書との違い

RPA設計書は、システム開発の設計書と違い、人が行っている画面操作を、ロボットが再現できる粒度に分解して書く点が特徴です。

操作対象の画面が変わるとロボットが止まるため、RPA設計書は「どの画面のどの項目を使うか」を、システム開発の設計書より具体的に書く必要があります。

記載する項目

記載する項目は、業務概要と対象範囲、処理の流れ、例外処理の3つを軸にすると、引き継ぎで困りにくくなります。

編集部の整理では、項目を増やすほど更新が追いつかなくなり、設計書が実態から離れていきます。そこで、運用担当が「止まった原因を調べる」「仕様を変える」ときに必ず参照する情報だけを残す、という基準で項目を選びます。

業務概要と対象範囲

業務概要には、ロボットが担う業務の目的と、担わない範囲を書きます。

• 業務名と目的：何のために行う業務か（例：月次の請求書を会計システムに登録する）
• 対象範囲：ロボットが処理する工程と、人が行う工程の境目
• 対象外：ロボットが扱わないケース（例：手書きの請求書、海外取引分）
• 実行条件：実行する頻度・時刻・起動のきっかけ
• 利用するシステムとアカウント：どの業務システム・ファイルを、誰の権限で使うか

対象外の記載は見落とされがちですが、「なぜこの請求書は処理されないのか」という運用上の問い合わせに、設計書だけで答えられるようになります。

処理の流れ

処理の流れには、入力から出力までの工程を、順番と分岐が分かる形で書きます。

• 入力：何を受け取って処理を始めるか（ファイル名の規則、保存場所など）
• 工程：1工程につき1つの目的を持たせ、番号を振る
• 判断：分岐の条件を、数値や文言で言い切れる形で書く
• 出力：処理後に何が残るか（登録された伝票、更新された一覧、通知メールなど）

全体像は業務フロー図で見せ、工程ごとの詳細は表で書くと、読む側が迷いにくくなります。

例外処理

例外処理には、想定外の入力や画面の変化が起きたときに、ロボットがどう振る舞い、誰に何を知らせるかを書きます。

例外の記載で最低限そろえたいのは次の4点です。

1. 発生する状況（例：読み取った金額が空欄だった）
2. ロボットの動き（例：その1件を飛ばして次の処理に進む／全体を止める）
3. 通知先と通知内容（例：担当者へメールで対象ファイル名を送る）
4. 人が行う復旧の手順（例：手入力で登録し、一覧の状態を「手動済」に更新する）

書き方のポイント

書き方の要点は、画面操作を読める粒度に整えることと、業務ルールを文章ではなく条件として書くことの2つです。

画面操作の粒度

画面操作は「1クリック単位」ではなく「1つの目的を達成する操作のまとまり」で書くのが、更新しやすい粒度です。

たとえば「メニューをクリック」「入力欄をクリック」「文字を入力」と並べると、画面が少し変わるたびに大量の修正が必要になります。「会計システムの伝票入力画面で、取引先コード・金額・日付を入力して登録する」とまとめれば、変更箇所を探しやすく、読む側も流れをつかめます。

一方で、ロボットがつまずきやすい箇所は、まとまりの中でも細かく書きます。

• 画面の読み込みを待つ条件（例：登録ボタンが押せる状態になるまで待つ）
• 入力欄を特定する手がかり（画面上のラベル名、項目名）
• ポップアップや確認ダイアログが出る場合の扱い

ルールの書き方

業務ルールは「担当者が適宜判断する」と書かず、条件と結果の組で言い切ります。

閾値や取引先コードのように、業務側の都合で変わる値は、設計書の中で1か所にまとめておくと、変更時の修正漏れを防げます。人が判断してきた暗黙のルールを引き出すには、実際に業務を担当している方へ「迷うのはどんなときですか」と聞くのが近道です。

記載例

記載例として、請求書処理とデータ転記の2つを、架空の業務を題材に示します。自社の業務に合わせて項目名や粒度を調整してください。

請求書処理の例

請求書処理の設計書は、取得・読み取り・入力・記録の4工程に分け、読み取り失敗時の分岐を明記すると、運用で迷いません。

例外は次のように書きます。

• 工程2で3項目のいずれかが読み取れない場合：その1件を飛ばし、「要確認」フォルダへ移動して担当者へメールで通知する。
• 工程3で会計システムが応答しない場合：3回まで再試行し、改善しなければ処理を止めて運用担当へ通知する。
• 同じ取引先・金額・期日の伝票がすでにある場合：二重登録を避けるため登録せず、一覧に「重複の疑い」と記録する。

データ転記の例

データ転記の設計書は、転記元と転記先の項目対応表を中心に据えると、仕様変更時に直す箇所がすぐ分かります。

項目対応表があれば、転記元の列が増えたり名前が変わったりしたときも、影響を受ける行だけを確認すれば済みます。

レビューの観点

設計書のレビューでは、例外の抜けと運用負担の2点を重点的に確認すると、公開後のトラブルを減らせます。

例外の抜け

例外の抜けは、正常に進む流れよりも「うまくいかない場面」を意図して洗い出すことで見つかります。

• 入力が空・想定外の形式・重複しているときの動きが書かれているか
• 対象システムが応答しない、ログインできないときの動きが書かれているか
• 処理の途中で止まった場合に、再実行しても二重処理にならないか
• 例外の通知先が、実在する担当者または共有の連絡先になっているか

運用負担

運用負担のレビューでは、ロボットが止まったときに人が何をする必要があるかを、設計書から読み取れるかを確かめます。

• エラー通知を受けた担当者が、最初に見る場所（ログ、処理結果一覧）が書かれているか
• 人が手動で補う手順と、補った後の記録方法が決まっているか
• 閾値や取引先コードなど、変更されやすい値の置き場所が分かるか
• 実行時間や実行頻度が、関連する他の業務やシステムの運用時間と重ならないか

レビューは、作成者ではない人が設計書だけを読んで「止まったときに自分で原因を追えるか」を確かめる形にすると、書き手の思い込みに気づけます。

更新の運用

設計書は作って終わりではなく、ロボットを変更するたびに同時に更新する運用を決めておくことが、形骸化を防ぐ条件です。

変更の記録

変更の記録は、設計書の先頭に「変更履歴」の表を置き、日付・変更内容・変更理由・担当者を1行ずつ残すのが簡便です。

変更理由まで残すと、後から「なぜこの条件になっているのか」を調べる手間が減ります。ロボットの修正と設計書の更新を、同じ変更依頼の完了条件にしておくと、更新漏れを防げます。

保守担当への引き継ぎ

保守担当への引き継ぎでは、設計書を渡すだけでなく、設計書のどこを見れば何が分かるかを一度説明する場を設けます。

• 設計書の構成と、止まったときに最初に見る箇所を説明する
• 過去に起きたエラーと対処を、例外処理の項に追記して渡す
• 業務側の窓口（ルール変更を知らせてくれる人）を明記する
• 実際に運用担当が設計書だけを見て手順を追えるか、引き継ぎ時に確認する

引き継ぎの範囲は、開発を外部に依頼しているかどうかで変わります。たとえば、準委任契約は業務の遂行に対して報酬が発生し、成果物の完成義務は負わない契約とされています（出典：コンサルチョイス、2026-10-08参照）。設計書を成果物として納めてもらうのか、作業の一環として作るのかは契約で異なるため、発注時に作成の範囲と更新の担当を確認しておくと安心です。契約内容の個別の判断は、専門家へ相談してください。

RPAの内製と外注の違いについてはRPA開発の内製と外注、ツール選定の評価軸はRPAツールの比較も参考になります。RPA領域の案件で関わり方を探す場合は、フリーコンサル向けエージェントの比較で各社の特徴を確認できます。

出典・参考情報

1. コンサルチョイス「フリーコンサルの契約形態ガイド」（2026-10-08参照）

本記事は2026年10月時点の一般的な実務の考え方を整理したものです。記載例は説明のための架空の題材であり、実際の設計書は利用するツールや社内ルールに合わせて調整してください。最終更新日：2026年10月8日