社内RPA管理システム開発ノート：低コード×カスタムアプローチの教訓

プロジェクト背景と要件定義の落とし穴

当社では業務自動化の一環として、社内で複数稼働しているRPA（Robotic Process Automation）ボットの管理・モニタリングシステムを刷新する必要に迫られました。従来はExcel台帳で稼働状況を手動集計し、障害対応も都度エンジニアへ依頼する運用。「費用」工数が月間約100時間に達し、年間約¥5,000,000の運用コストが固定化されていたため、「予算」見直しの必要が明確となりました。
プロジェクトキックオフ時、要件定義フェーズでつまずいたのは、業務部門のRPA利用形態とエラー時対応フローを正確にヒアリングできなかった点です。結果として初期要件には「実行ログ閲覧」「障害再実行」「スケジュール変更」のみが記載され、エラー通知やアクセス権限管理など重要機能が抜け落ちる失敗を経験しました。この失敗から、要件定義書には業務フロー図とイベント図を併記し、ワークショップ形式でRPA担当者を巻き込む形に改善。「発注」前にギャップを徹底的に洗い出す手順を確立しました。

低コードプラットフォーム選定とPoC失敗の教訓

要件定義を終えた段階で、開発スピード重視のため低コードプラットフォームを採用検討。社内SEチームが候補に挙げたのは、Airtable＋Zapier、OutSystems、Mendixの三つでした。比較ポイントは「GUI開発の容易さ」「API連携力」「ライセンス費用の相場」です。
Airtable＋Zapierは低価格でPoCを1週間で完了できる見込みでしたが、複雑な権限管理やログ検索機能のカスタマイズが困難という課題が判明。OutSystemsは機能豊富で開発会社への「発注」先としても実績がありますが、年間ライセンスが¥1,200,000前後と「費用」負担が大きく、「予算」枠を超過する恐れがありました。MendixはUI/UXが優れるものの、社内に知見がなく導入教育コストが膨大になるリスクがありました。
PoCではAirtable＋Zapierを選択したものの、実運用を想定すると処理速度やログ検索性能が要件を満たさず、再検討を余儀なくされました。この経験から、低コード採用時は「短期で動くデモを作る」と同時に「長期運用フェーズでのカスタマイズ性・パフォーマンス」を必ず試験する必要があると学びました。

カスタム実装アプローチで解消した課題とチームコミュニケーション

PoC失敗を受け、部分的に低コードを残しつつ、ログ集計と通知機能をカスタムコードで実装するハイブリッド戦略にシフト。フロントエンドはReact＋Ant Design、バックエンドはNode.js＋ExpressでREST APIを構築し、RPAボットの実行状況はMongoDBに保存。ログ検索APIは全文検索エンジン（Elasticsearch）と連携し、ミリ秒単位でのクエリ応答を実現しました。
このフェーズで特に重視したのは、開発会社C社とのコミュニケーションです。C社は「選び方」の観点からRPA実績豊富で、要件定義～設計～テストまでを同一チームで一貫担当。週次でオンライン設計レビューを行い、GitHub Issuesで要件変更やタスク管理を透明化。Slackのチャンネルを機能別に分け、障害対応や仕様相談を即時に行える体制を構築しました。これにより、追加「費用」を抑えつつ、開発スピードと品質を両立できたのが大きな成功ポイントです。

パフォーマンスチューニングとインフラコスト最適化

カスタム実装後、予想以上にユーザーアクセスが集中し、Elasticsearchへの検索APIへの負荷が課題となりました。対応策として、キャッシュ層にRedisを導入し、頻度の高いクエリをTTL付きで保持。APIサーバーにはAWS Elastic Beanstalkを利用し、Auto Scalingでインスタンス数を動的に調整。
また、MongoDBはMongoDB Atlasのサーバーレスプランへ移行し、ストレージとクエリ量に応じた従量課金モデルに変更。「相場」感として、月額¥200,000→¥120,000へ削減でき、総TCOを15％圧縮に成功しました。開発チームでは「インフラ費用の見積り」を発注時に必ず盛り込み、試算を毎月レビューする運用ルールを制定しました。

テスト戦略と品質保証

テストフェーズでは、単なる動作確認にとどまらず、RPA管理システム特有の継続稼働性とデータ整合性を重点的に検証しました。まずユニットテストでは、ログ集計APIとElasticsearch連携層、通知機能、スケジューリング機能をJestとMochaで網羅的にテスト。モックデータと実データを比較してレスポンス内容の正確性を担保しました。次に統合テストでは、ステージング環境に実際のRPAボットを接続し、想定されるエラーケース（タイムアウト、重複実行リクエスト、無効ジョブIDなど）を30シナリオ以上作成。これらをCypressで自動化し、夜間バッチとして回すことで、一日に複数人が手動で検証していた工数を70％カットできました。さらに負荷テストにはk6を導入し、同時アクセス500ユーザーかつ障害通知発生時のリトライ処理を含めた1,000リクエスト/分のシナリオでCPU負荷とメモリ消費を測定。しきい値を超えると自動スケールアウトをトリガーするKubernetesのHPAs（Horizontal Pod Autoscalers）設定が適切に機能することも確認しました。セキュリティテストでは、認証漏れや権限エスカレーションを防ぐためOpenAPI仕様に基づくAPI監査、JWTトークンの改ざん耐性試験、XS S／CSRFテストを実施し、クリティカルな脆弱性はゼロに抑えられました。これらの取り組みにより、リリース前の品質保証工数は当初想定の150時間から200時間に増加したものの、本番障害による対応工数が半減し、結果として追加「費用」発生を最小限に抑えられました。

本番展開とロールアウト

本番展開はリスク管理を最優先に、段階的ローンチを採用しました。第1段階は管理者ユーザー50名限定でのクローズドリリース。ライブ稼働中のRPAジョブを対象に１週間の監視期間を設け、未検知だったエラーのログ妥当性や通知遅延を即時修正しました。第2段階では部門単位で対象ユーザーを拡大し、スケジュール変更や再実行がスムーズに行えるか業務フローを再検証。ここでは特定部門からジョブ実行履歴の検索性能に関するフィードバックがあり、Elasticsearchのインデックス設定を見直すチューニングを実施しました。最終段階は全社一斉リリースで、土曜深夜のメンテナンスウィンドウ2時間を確保し、DNS切り替え、Ingress設定更新、デプロイ済みPodのリプレースを無停止で行いました。リリース当日はSlack連携でリアルタイムログを開示し、運用チームとC社エンジニアが同時にモニタリング。予期せぬログパースエラーが1件発生しましたが、CI/CDパイプラインに組み込んだロールバック機能で前バージョンに瞬時に戻し、10分以内で全面復旧を実現しました。本番展開全体を通じて、ダウンタイムはゼロ、利用停止ユーザーは皆無で、ステークホルダーから高評価を得ました。

運用・保守体制の構築

リリース後は運用・保守フェーズへ移行し、C社との保守契約に基づく24×365サポートを開始。初動対応時間1時間以内、完全解決8時間以内というSLAを契約書に明記し、オンコール体制のシフトを整えました。モニタリングにはPrometheus＋Grafanaでメトリクスを収集し、ElasticsearchのKibanaでログ分析を行うハイブリッド体制を構築。毎朝の定例レポートでは「障害件数」「定期メンテナンス工数」「ジョブ実行成功率」をダッシュボードにまとめ、経営層と共有しています。障害対応では、GitHub Issuesと連携したワークフローでチケット化し、対応ステータスを可視化。ナレッジベースにはFAQとトラブルシューティング手順を蓄積し、サポート工数をリリース前比で50％削減できました。また、継続的な改善として月1回のリリースで、ユーザー要望や運用ログに基づく機能追加／バグ修正を実施。「費用」を透明化するため、月次の保守費用¥300,000に加え、追加タスクは時間単価¥12,000で契約しています。これにより、予算超過リスクを抑制しつつ、システムの堅牢性とユーザー満足度を維持しています。

効果測定とROI算出

導入から半年後の効果測定では、以下の成果を確認しました。

• 運用コスト削減：手動集計・対応工数100時間/月×¥5,000=¥500,000/月 → 自動化後10時間/月×¥5,000=¥50,000/月、月額約¥450,000、年間¥5,400,000削減

• サポート問い合わせ削減：月100件→月10件、チケット処理コスト年間¥1,080,000削減

• ユーザー満足度向上：社内アンケートで「使いやすさ80％→95％」を達成

• 追加売上効果：業務効率化により新規プロジェクト受注1件（約¥3,000,000）

初期開発費用¥6,500,000＋保守契約年間¥3,600,000に対し、年間効果は¥5,400,000＋¥1,080,000＋¥3,000,000=¥9,480,000。ROIは(9,480,000−3,600,000)÷6,500,000×100≒88％、約1.1年で投資回収可能と試算されました。これを根拠に、経営層から翌年度の「予算増額」と他システムへの横展開許可を獲得することに成功しています。

今後の拡張計画と学び

今後は以下の拡張を計画中です。

• RPAボット自動配置機能：Kubernetes上でスケジュールに応じた自動スケーリング

• AIログ分析：過去の障害データを機械学習で解析し、障害予測アラートを実装

• 多要素認証対応：ID管理強化のため、OAuth2.0＋OIDCでSSO連携

• チャットボット連携：SlackやTeamsで障害対応状況をリアルタイムに問い合わせ可能に

• グローバル対応：多言語UIとタイムゾーン自動変換で海外支社への展開

本プロジェクトで得られた教訓は、「要件定義の精度」と「開発会社との密なコミュニケーション」がコスト超過を防ぐ鍵であることでした。特にPoC段階で機能検証だけでなく、ライセンス費用や運用体制を含めたTCO試算を行うことが、失敗リスクを大幅に低減します。

ぜひ