RPA・ローコード/ノーコード開発 | 中小企業診断士1次試験経営情報システム

Excelで毎月まる1日かかっていた集計作業が、RPAを入れたら5分に縮んだ——そんな話を聞いて、最初は「プログラマーじゃないとできないのでは？」と思っていました。でも調べてみると、ノーコードで動かせるものもあって、この分野の広がりに驚きました。

RPAとローコード/ノーコード開発は、経営情報システムの中でも近年出題頻度が上がっているテーマです。「自動化」という言葉の裏にある仕組みと、開発スタイルの違いをきちんと押さえておくと、選択肢の絞り込みがぐっと楽になります。この記事では、それぞれの定義・比較・活用場面・試験ポイントを一緒に整理していきます。

RPAとは何か——「ロボット」が作業を肩代わりする仕組み

WHAT

RPAの定義

Robotic Process Automationの略。人間がPCで行う定型的な操作（クリック・入力・コピペ・ファイル転送など）をソフトウェアロボットに代行させる技術。物理的なロボットではなくソフトウェアが「ロボット」の役割を担う。

POINT

プログラミングなしで始められる

多くのRPAツールはGUIベースで操作を記録・再生できる。複雑なコーディングなしに「この順序でこの操作を繰り返す」という手順をツールに覚えさせることができる点が特徴。

SCOPE

活用される現場

経理・人事・営業サポートなど、繰り返しのデータ入力・集計・転記が多い業務に強い。システム間のデータ連携が難しい場合（API未整備の旧来システム同士）でも、画面操作を橋渡しできる。

もし毎月末に「A社の受注データをExcelに転記 → 別システムに手入力 → 集計レポートを作成」という流れを繰り返しているとしたら、その一連の操作をRPAロボットに任せることができます。担当者は月末の半日をそのルーティンから解放されることになります。

RPA・EPA・CAの3タイプ——自動化の「賢さ」の違い

RPAには発展段階があります。試験では「Class1〜3」や「RPA/EPA/CA」という区分で整理されることがあります。「賢さが増すほど名前が変わる」とざっくり理解しておくと覚えやすいです。

タイプ	別名	特徴	判断能力
RPA（Class1）	Robotic Process Automation	定型的なルール操作のみ自動化。手順が決まっていることが前提	なし（ルールどおりに動くだけ）
EPA（Class2）	Enhanced Process Automation	AIや機械学習を組み合わせ、非構造化データ（文書・画像など）の処理も可能	部分的あり（パターン認識・分類）
CA（Class3）	Cognitive Automation	自律的な判断・学習・最適化が可能。人間の判断に近いレベルの業務処理	高い（状況に応じた自律判断）

Class1（RPA）は「決められた道を走るだけ」、Class2（EPA）は「道を多少外れても戻れる」、Class3（CA）は「地図なしで目的地まで自分で考えて辿り着ける」——そんなイメージで差を押さえておくと試験での選択肢整理に使えます。

RPAが得意な業務の5条件——「向く仕事」と「向かない仕事」

RPAはすべての業務を自動化できるわけではありません。「向く業務」には共通した特徴があります。5つの条件が揃っているほど、RPAの効果は高くなります。

ルールが明確

「この条件のときはAをする」という判断基準が例外なく文章化できる業務。曖昧さやグレーゾーンがある業務はRPAには不向き。

人間の判断が少ない

状況を読んだ判断・交渉・クリエイティブな対応が要らない業務。「この番号をここに入力する」という操作の連続で完結できるもの。

デジタルデータの入力・転記

紙書類の手書き読み取りよりも、システム画面・メール・ExcelなどデジタルなインプットがあるほうがRPAは機能しやすい。

大量・高頻度

月1回・数件では自動化のコストが見合わない。毎日数百件、毎月数千件といった量があってはじめてROIが成立する。

繰り返し・定型

同じ手順が繰り返される業務。毎回内容が異なる・属人的な判断が必要な業務には不向き。

ローコード・ノーコード・フルコード——開発スタイルの3区分

RPAと並んで試験に出るのが「ローコード/ノーコード開発」です。「どれくらいコーディングが必要か」で3タイプに整理できます。

開発スタイル	コーディング量	担当者	柔軟性	代表例
ノーコード	ゼロ（不要）	非エンジニア・現場担当者	低い（テンプレート範囲内）	Notion・Airtable・Google Forms
ローコード	最小限（部分的に記述）	業務担当者＋一部エンジニア	中程度（拡張は可能）	Power Apps・Salesforce・kintone
フルコード	全て手書き	エンジニア専任	高い（自由度が最大）	Java・Python等による開発全般

「コーディングが少ない = できることが限られる」という関係があります。ノーコードは誰でも使えますが、テンプレートの範囲からははみ出せません。ローコードは現場担当者が中心になれますが、複雑な処理は少しだけコーディングが必要です。この三角形のどこに位置するかで、「誰が作るか」「何ができるか」「どれくらい時間がかかるか」が変わります。

DX推進との3段階——自動化はゴールではなくスタートライン

STAGE 1

業務自動化（Automation）
RPAやローコードツールで定型業務を機械に任せる。「人手の作業をソフトウェアに代替させる」段階。この段階ではプロセスはほぼ変わらない。

効率化 → デジタルデータが蓄積される

STAGE 2

デジタル化（Digitalization）
蓄積されたデータを活用して業務プロセス自体を見直す。アナログな申請・承認フローをデジタルに置き換え、業務の流れを変える。

プロセス変革 → ビジネスモデルの変革へ

STAGE 3

DX（Digital Transformation）
デジタルを前提にビジネスモデル・組織・文化そのものを変革する。単なる効率化を超えて、新しい価値創出・競争優位を実現する段階。

RPAは「STAGE 1」に位置します。試験では「RPAを導入すればDXが達成できる」という誤解を問う選択肢が出ることがあります。自動化はDXの入り口であり、それ自体がDXではない——この関係を押さえておくことが重要です。

導入失敗の3パターンと対策——現場でよく起きること

失敗パターン 01

「とりあえずRPAを入れた」問題

業務の棚卸しをせず、現状の非効率なプロセスをそのまま自動化してしまう。「悪いやり方を高速で繰り返す機械」ができあがる。

対策：導入前にプロセスの見直し（業務改善）を先に行う

失敗パターン 02

「システム変更のたびに壊れる」問題

画面の位置やボタンのIDに依存したロボットを作ると、システムのUI変更だけで動かなくなる。メンテナンスコストが想定外に膨らむ。

対策：変更頻度の低い安定した業務から導入を始める

失敗パターン 03

「属人化・担当者退職で止まる」問題

ロボットの設定・修正を特定の担当者だけが行える状態に。その担当者が異動・退職するとメンテナンスできなくなり、組織の負債となる。

対策：複数担当者が管理・更新できる体制とドキュメント整備

試験での出題ポイント——ここを押さえると選択肢が絞れる

RPAの定義と対象業務

「ソフトウェアロボットが定型業務を自動化する」が基本定義。「物理的なロボット」「AIによる判断を必ず含む」といった誤りを含む選択肢に注意。適用に向く業務条件（ルール明確・大量・繰り返し）も問われる。

RPA/EPA/CAの3段階の違い

「Class1のRPAはAIを使わない」「Class2（EPA）は機械学習を組み合わせる」「Class3（CA）は自律的判断が可能」という段階の差が問われる。名称と特徴の対応を整理しておくこと。

ローコード/ノーコードの位置づけ

「コーディング不要＝ノーコード」「最小限のコードで開発＝ローコード」「柔軟性が最も高いのはフルコード」という関係。「ノーコードは柔軟性が高い」という逆転した選択肢に注意。

RPAとDXの関係

RPAはDXの手段の一つであり、「RPA導入＝DX達成」ではない。DXは「デジタルを活用してビジネスモデル・組織・文化を変革すること」であり、自動化はその入り口に過ぎない。

まとめチェックリスト

RPAはソフトウェアロボットが定型業務を代行する技術（物理ロボットではない）
Class1（RPA）→ Class2（EPA：AI組み合わせ）→ Class3（CA：自律判断）の順に高度化する
RPAに向く業務：ルール明確・判断少・データ入力・大量・繰り返しの5条件が揃う業務
ノーコード（コードゼロ）＜ローコード（最小限）＜フルコード（全記述）の順に柔軟性が高まる
自動化（RPA）→ デジタル化（プロセス変革）→ DX（ビジネスモデル変革）の3段階を区別する
RPA導入前に業務プロセスの見直しが必要。非効率なプロセスをそのまま自動化しない

U のメモ

「ローコードとノーコードを逆に覚えてしまいそう」と感じる方は、「コードがノー（=ゼロ）」という言葉の意味で覚えると混乱しにくくなります。試験の選択肢では「ノーコードはカスタマイズの柔軟性が高い」といった逆転した記述がよく出ます。柔軟性はフルコード > ローコード > ノーコードの順、という方向性を確認しておくと安心です。