自動化の仕組みを誰が保守するか：野良ロボット・野良ツール対策

野良RPA対策の出発点は、ツールを禁止することではなく「どこで何が自動で動いているかを把握し、一つひとつに保守の責任者を決める」ことです。現場で作られたRPAのロボット、Excelマクロ、Google Apps Script、Zapierのような自動化の仕組みは、それ自体が悪いものではありません。問題になるのは、作った人が異動や退職でいなくなり、誰も中身を説明できないまま業務の一部を担い続けている状態です。止まったときに気づけない、直せない、止めてよいかも判断できない。これが「野良」と呼ばれる状態の正体です。

この記事は、現場主導で自動化が広がってきた会社の情報システム担当者、業務改善の推進役、そして「あのロボットを作った人がもういない」という状況に心当たりのある管理職に向けて書いています。野良化が起きる仕組み、現状の棚卸しの手順、管理台帳に残す項目、作ってよいもの・届け出が必要なものの線引き、担当者不在でも止まらないための引き継ぎと監視の考え方を、順番に説明します。

読み終えたときに、自社の自動化ツールをどこから把握し、どんなルールで管理すれば現場の工夫を止めずに済むかを判断できることを目指しています。

野良RPA・野良ツールとは何か、なぜ問題になるのか

野良RPAとは、管理部門が存在を把握していない、あるいは保守の責任者が決まっていないまま動き続けている自動化ロボットのことです。用語の詳しい意味は野良RPA（野良ロボット）の解説ページにまとめています。この記事ではRPAに限らず、Excelマクロ、スプレッドシートの関数とスクリプト、ノーコードの連携ツール、個人のPCで定期実行されるバッチファイルなど、現場で作られた自動化の仕組み全般を「野良ツール」として扱います。

野良ツールそのものは、現場の工夫の成果です。毎日30分かかっていた転記作業をマクロで数秒にした、問い合わせが来たらチャットに通知が飛ぶようにした、といった改善は本来歓迎すべきものです。問題が表に出るのは、次のような場面です。

• 作成者が異動・退職し、ロボットが止まったときに誰も直せない
• 連携先のSaaSの画面や仕様が変わり、気づかないうちに処理が失敗し続けていた
• 個人アカウントのパスワードやAPIキーで動いていて、その人のアカウント停止と同時に止まった
• 誰も使っていないと思って止めたら、別部署の月次処理が回らなくなった
• 顧客情報を個人のクラウドストレージに書き出す処理が、承認なく動いていた

どれも「自動化したこと」ではなく「自動化の存在と中身が共有されていないこと」が原因です。社内で承認されていないIT利用全般を指すシャドーITと同じ構造で、便利さと引き換えに、見えないリスクが積み上がっていきます。

野良化が起きる仕組み：作る人と保守する人がずれる

野良化は、特定の誰かの怠慢で起きるわけではありません。多くの場合、次のような流れで自然に進みます。

1. 現場の担当者が、日々の作業を楽にするために小さな自動化を作る
2. 便利なので周囲も使い始め、いつのまにか業務の前提になる
3. 作った本人は「自分用のちょっとした工夫」のつもりで、手順書や説明を残さない
4. 担当替えや退職で、作成者がいなくなる
5. 後任は動いていることは知っているが、中身も止め方も分からない
6. ある日止まり、原因調査に何日もかかる

ポイントは2の段階です。個人の便利ツールが、組織の業務を支える仕組みに変わった瞬間に、本来は保守の責任者と手順書が必要になります。ところが、その切り替わりは誰も意識しないまま起きるため、保守の体制が後回しになります。

もう一つの要因は、自動化を作るハードルが下がったことです。ノーコードツールや生成AIの助けを借りれば、プログラミング経験のない人でも業務を自動化できるようになりました。現場の人が自ら仕組みを作る市民開発は、業務を最もよく知る人が改善を進められる点で大きな利点があります。一方で、作れる人が増えるほど、管理の仕組みがないと野良ツールも増えます。対策は「作らせない」ではなく「作ったものを組織の資産として扱う仕組み」を用意することです。

野良ツール対策の全体像：禁止ではなく可視化と責任の明確化

対策は大きく四つの層で考えると整理しやすくなります。

最初からすべてを整える必要はありません。まずは「把握」だけでも大きな前進です。何が動いているか分からない状態では、どれが重要でどれが放置してよいかも判断できないからです。

逆に、避けたいのは「今後、現場での自動化はすべて情報システム部門の承認制にする」といった一律の禁止です。承認の手間が重いと、現場は申請せずに作るようになり、かえって見えない野良ツールが増えます。影響の小さいものは自由に、影響の大きいものだけ届け出と保守体制を求める、という段階的なルールの方が守られます。

また、対策の担い手を一つの部署に集中させすぎないことも大切です。情報システム部門や業務改善の担当者は、台帳の形式と区分のルールを用意し、定期確認を呼びかける役割に徹します。個々の自動化の中身を理解し、止まったときに最初に動くのは、その業務を持つ部署の正副担当者です。管理部門がすべての自動化を自ら保守しようとすると、すぐに手が回らなくなり、結局「管理部門に聞けば分かるはず」という新しい属人化が生まれます。ルールは中央で、保守は現場で、という役割分担を最初に決めておきましょう。

野良ツールの棚卸しの進め方

既に野良化が進んでいる場合は、まず現状を洗い出します。棚卸しは次の手順で進めると、抜け漏れを減らせます。

1. 対象の範囲を決める：RPA、Excelマクロ、スクリプト、ノーコード連携、定期実行タスクなど、どの種類を対象にするかを最初に宣言する。範囲が曖昧だと回答がばらつく。
2. 技術的な手がかりから拾う：RPAツールの管理画面、ノーコードツールの組織アカウント、共有ドライブ内のマクロ付きファイル、サーバーやPCの定期実行設定、外部サービスに発行されたAPIキーの一覧など、システム側から見える情報を集める。
3. 部署ごとにヒアリングする：「毎日・毎週・毎月、自動で動いているものはありますか」「止まったら困る仕組みはありますか」と聞く。技術的な手がかりだけでは個人PCのマクロなどが漏れるため、両方からの確認が必要になる。
4. 業務フローとの対応を取る：見つかった自動化が、どの業務のどの工程を担っているかを紐づける。業務の流れから見ると、「この工程は手作業のはずなのに妙に早い」といった形で未発見のツールが見つかることもある。
5. 影響度で仕分ける：止まったときの影響（顧客対応、売上、締め処理、法令対応への影響）と、扱うデータの重要度で分類する。
6. 扱いを決める：継続（管理台帳に登録し保守担当を決める）、作り直し（正式な仕組みに置き換える）、廃止（使われていない・代替がある）のいずれかに振り分ける。

棚卸しでは、ヒアリングの雰囲気づくりが重要です。「勝手に作ったものを取り締まる」という空気になると、現場は申告を控えます。「止まったときに困らないよう、組織として面倒を見られるようにしたい」という目的を最初に伝えましょう。業務の可視化の進め方は業務可視化の方法でも詳しく扱っています。

管理台帳に残す項目

棚卸しで見つけた自動化は、管理台帳に登録します。台帳は高機能なツールでなくても、共有スプレッドシートで十分に始められます。大切なのは項目をそろえることです。

• 名称と概要：何をする仕組みか、一文で
• 種類と実行環境：RPA、マクロ、ノーコード連携など。どのPC・サーバー・クラウドで動くか
• 対象業務と利用部署：どの業務のどの工程を担っているか、誰がその結果を使うか
• 実行タイミング：毎朝9時、受注時、月末など
• 入力と出力：どこからデータを読み、どこに書き込むか
• 使用アカウント：どのアカウント・APIキーで動いているか（パスワード自体は台帳に書かない）
• 正担当・副担当：保守の責任者と、その代わりを務められる人
• 影響度区分：止まったときの影響の大きさ
• 手順書の場所：止め方、再実行の方法、よくあるエラーと対処
• 最終確認日：台帳の内容が正しいと確認した日

特に見落とされやすいのが「使用アカウント」と「最終確認日」です。個人アカウントで動いている自動化は、その人のアカウントが停止された瞬間に止まります。退職時のアカウント停止手続きと台帳を照合する運用にしておくと、退職と同時にロボットが止まる事故を防げます。また、台帳は作った時点から古くなっていくため、最終確認日を見て定期的に見直す仕組みが必要です。

作ってよいもの・届け出が必要なものの線引き

新しく作られる自動化をすべて管理部門が審査するのは現実的ではありません。影響度に応じた区分を決め、それぞれに求めることを明文化します。

区分を判断する基準は、次のような問いにしておくと現場でも判断できます。

• 自分以外の人がその結果を使っているか
• 止まったときに、顧客や取引先に影響が出るか
• 個人情報や取引情報を扱うか、社外のサービスにデータを送るか
• 月末・締め日など、止まると取り返しがつかないタイミングで動くか

一つでも当てはまれば、個人利用ではなくチーム利用以上として扱う、というように決めておくと迷いが減ります。生成AIを使った自動化が増えている場合は、データの入力ルールも合わせて整理しておくと安全です。

担当者がいなくなっても止まらないための保守の仕組み

台帳と区分を決めても、実際に止まったときに直せなければ意味がありません。担当者不在で止まらないための仕組みを、具体的に整えます。

正副の担当者を必ず決める

業務基幹の区分に入る自動化には、正担当と副担当を指名します。副担当は名前だけでなく、実際に一度は再実行や軽微な修正を経験しておくことが大切です。半年に一度などの頻度で、副担当が手順書を見ながら動作確認する機会を作ると、手順書の古さにも気づけます。

手順書を「止め方」と「再実行」から書く

自動化の手順書は、仕組みの解説より先に、止まったときに何をするかを書きます。止める方法、手動で代わりに処理する方法、再実行の方法、よく起きるエラーと対処、の四つがあれば、作成者がいなくても当面は業務を回せます。書き方の詳細は運用手順書（Runbook）の作り方で解説しています。

個人アカウントから共有アカウントへ移す

業務基幹の自動化は、個人のアカウントではなく、業務用の共有アカウントやサービスアカウントで動かします。認証情報はパスワード管理ツールなどで管理し、担当者の入れ替わりに合わせて引き継げるようにします。

実行結果を通知し、失敗に気づけるようにする

止まったことに気づけないのが、野良ツールの最大のリスクです。成功・失敗の結果をチャットやメールで通知する、一定時間実行されていなければ警告を出す、といった監視を入れます。失敗時だけ通知する設定だと、そもそも実行されなかったケースに気づけないため、「今日の処理が完了した」という成功通知も役に立ちます。

よくある失敗とその避け方

野良ツール対策でつまずきやすいポイントと、その避け方をまとめます。

• 一律禁止にして、申告されない野良ツールが増える：影響度に応じた区分を設け、個人利用の範囲は自由にしておく。届け出の手間を最小にする。
• 台帳を作って満足し、更新されない：最終確認日の項目を設け、四半期ごとなど決まったタイミングで正担当に確認を依頼する。人事異動の時期と合わせると漏れにくい。
• 副担当が名ばかりで、いざというとき動けない：定期的に副担当が実際に操作する機会を作る。手順書の更新もそのときに行う。
• 作り直すべきものを延命し続ける：画面操作型のロボットが頻繁に止まる場合は、API連携など安定した方式への置き換えを検討する。判断の考え方はRPAが止まる・使われなくなる原因も参考になる。
• 管理部門だけでルールを作り、現場が従わない：区分やルールは、自動化を作っている現場の担当者を交えて決める。現場の手間が見えていないルールは形骸化する。

具体的な場面の例

ここでは、架空の一般的な例で流れを示します。

従業員数十名の卸売の会社で、受注担当者が作ったExcelマクロが、受注メールの内容を販売管理システムへの取込用ファイルに整形していたとします。作成者は社内で「マクロに詳しい人」として知られていましたが、別部署へ異動しました。数か月後、取引先がメールの書式を変えたことでマクロがエラーを起こし、受注の取込が二日間止まりました。後任はマクロの存在は知っていたものの、どこを直せばよいか分からず、異動先の作成者に連絡して直してもらうまで手作業でしのぐことになりました。

この会社が取り組んだのは、まず全部署への「自動で動いているもの」のヒアリングと、共有ドライブ内のマクロ付きファイルの洗い出しです。見つかった仕組みを台帳に登録し、受注・請求に関わるものを業務基幹として正副の担当者を決めました。受注取込のマクロについては、止まったときの手作業での代替手順を先に書き、そのうえで取引先ごとの書式の違いに強い仕組みへの置き換えを検討しています。

このように、最初の一歩は大がかりなシステム導入ではなく、存在の把握と責任者の明確化です。

野良ツール対策のチェックリスト

自社の状況を確認するために、次の項目を点検してみてください。

• 自動で動いている仕組みの一覧が、どこかにまとまっている
• 一覧には、担当者・使用アカウント・実行タイミングが記載されている
• 止まったときの影響が大きい仕組みには、正副の担当者がいる
• 正副の担当者は、実際に再実行や修正を経験している
• 業務基幹の自動化は、個人アカウントで動いていない
• 退職・異動の手続きの中に、担当している自動化の引き継ぎ確認が含まれている
• 自動化の失敗や未実行に、翌営業日までに気づける仕組みがある
• 新しく作る自動化について、届け出が必要な条件が明文化されている
• 一覧の内容を定期的に確認するタイミングが決まっている

当てはまらない項目が多いほど、作成者の不在で業務が止まるリスクが高い状態です。全部を一度に整える必要はないので、影響の大きい仕組みから順に埋めていきましょう。

よくある質問

Q. 野良RPAは見つけ次第、止めるべきですか？

いきなり止めるのは避けてください。誰も使っていないように見えても、別の部署の業務がその結果に依存していることがあります。まず台帳に登録し、利用者と影響を確認したうえで、継続・作り直し・廃止を判断します。廃止する場合も、一定期間止めてみて問題が出ないことを確認してから削除するのが安全です。

Q. 情報システム部門がない会社でも管理できますか？

できます。管理台帳の作成と定期確認は、総務や業務改善の担当者が持ち回りでも進められます。大切なのは担当部署の有無ではなく、「台帳を誰が更新するか」「確認をいつ行うか」が決まっていることです。

Q. 現場で自動化を作ること自体を制限すべきでしょうか？

一律に制限すると、申告されないまま作られる仕組みが増える傾向があります。個人の作業範囲は自由にし、他の人が結果を使うもの、重要データを扱うものだけ届け出を求める、という段階的なルールの方が実効性があります。

Q. 野良ツールを正式なシステムに置き換える目安はありますか？

頻繁に止まって修正が追いつかない、扱うデータや利用者が増えて個人の工夫の範囲を超えた、監査や取引先のセキュリティ確認で説明が求められる、といった状況が目安です。置き換えの際は、現行の仕組みが何をしているかを先に文書化しておくと移行がスムーズです。

Otsumuに相談できること

自動化の数が限られていて、社内に仕組みを読み解ける人がいるなら、この記事の棚卸し・台帳・区分の考え方を使って自社で管理を始めることは十分可能です。まずは共有スプレッドシートの台帳と、影響の大きい仕組みへの正副担当の指名から始めれば、外部に頼まなくても状況は大きく改善します。

一方で、中身を説明できる人がいない仕組みが業務の重要な部分を担っている、頻繁に止まるロボットの置き換え方式を判断できない、複数のツールにまたがる自動化を整理し直したい、といった場合は、外部の視点と技術力を借りた方が早く進むことがあります。止まったまま手作業でしのいでいる時間も、見えにくいコストです。

Otsumuでは、現場で動いている自動化の棚卸しと業務フローとの対応づけから、管理ルールの設計、止まりにくい方式への作り直し、監視の仕組みづくりまでを一貫して支援しています。自らも事業を運営する立場から、現場の工夫を止めずに組織として面倒を見られる形を一緒に考えます。詳しくは自社サービス運用の自動化コンサルティングのページをご覧ください。

どこから手を付けるべきか判断がつかない段階でも構いません。30分の無料相談で、現状を伺いながら優先順位を整理するところからお手伝いします。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01