Back to Blog
レガシーシステムシステム近代化SupabaseAWSReactASP.NET個人開発ビジネス戦略

レガシー基幹システムを近代化する戦略と、個人開発者が地方でビジネスを作る方法

レガシー基幹システムを近代化する戦略と、個人開発者が地方でビジネスを作る方法

こんにちは、Chiapuruです。

ある財務システムのRPA開発をきっかけに、「レガシーシステムとはなにか」「モダンなシステムはどう作られているか」「自分でゼロから同じようなシステムを作れるか」を整理する機会があったので、技術的な考察をまとめておく。

1. レガシーシステムの技術的実態

某財務会計システム（ASP.NET Web Forms）を例に

RPAを開発した財務会計システムは、技術的に以下の特徴を持つ。

観点 内容
フレームワーク ASP.NET Web Forms
レンダリング サーバーサイドレンダリング（PostBack）
DOM構造 重複IDの <tr>、ViewState
イベント発火 通常の fill() では change イベントが発火しない

特に問題になるのがDOM設計の独自性だ。ASP.NET GridViewは複数の <tr> に同一IDを付与するため、document.querySelector では先頭しか取れない。Playwrightの locator を使う必要がある。

また、React/ASP.NETのカスタムコンポーネントは、JavaScriptのネイティブセッターを使わないとイベントが発火しない。

async def js_fill(page, selector, value):
    await page.evaluate(
        """
        ({ selector, value }) => {
            const el = document.querySelector(selector);
            const nativeInputValueSetter = Object.getOwnPropertyDescriptor(
                window.HTMLInputElement.prototype, 'value'
            ).set;
            nativeInputValueSetter.call(el, value);
            el.dispatchEvent(new Event('change', { bubbles: true }));
        }
        """,
        {"selector": selector, "value": value},
    )

これはレガシーシステムのRPA開発で必須のパターンだ。

なぜレガシーが生き続けるのか

技術的には明確にレガシーでも、置き換えが進まない理由は単純だ。

移行リスク > 現状維持コスト

会計・人事システムは誤作動が許されない
→ 動いているものを触りたくない
→ 調達・稟議サイクルが10〜20年スパン
→ ベンダー保守契約が継続している

「安定している」というユーザー評価は正しい。その安定は技術の新しさではなく、枯れた成熟から来ている。

2. モダンシステムの技術仕様（某勤怠管理SaaSを例に）

ある勤怠管理SaaSのDevToolsを確認すると、技術スタックが推測できる。

CSS変数から読み取れること

--sider-background
--sider-menu-background
--table-head-border
--table-td-stripe
--form-label

これらの命名は Ant Design のコンポーネント名と完全に一致する。Ant DesignはReactベースのUIライブラリなので、フロントエンドはReact + Ant Designと特定できる。

推定スタック全体

レイヤー 技術
フロントエンド React + Ant Design
状態管理 Redux or Zustand
アーキテクチャ SPA + REST API分離
認証 JWT or セッション
ビルド Webpack or Vite

レガシーとモダンの比較

観点 レガシー系（ASP.NET Web Forms） モダン系（React + Ant Design）
アーキテクチャ モノリシックSSR SPA + API分離
テーマ変更 困難 CSS変数で容易
RPAのしやすさ 困難（重複ID等） 標準DOM構造
テスタビリティ 低 高
世代 2000年代 2020年代

3. レガシーシステムの近代化戦略

ストラングラーフィグパターン

全面刷新は現実的でない。段階的に「包み込んで」置き換える。

[ユーザー]
    ↓
[新フロントエンド / APIゲートウェイ]
    ↓              ↓
[新モジュール]  [既存システム]（徐々に縮小）

銀行・保険の基幹システム近代化で主流の手法だ。

最も現実的な第一手：APIゲートウェイの追加

既存システムを触らずに、間にAPI層を挟む。

既存システム（無改修）
    ↓
スクレイピング or DB直接読み取り
    ↓
REST API層（新規開発）
    ↓
・新フロントエンド
・Excel連携
・RPA（Playwright不要になる）
・外部システム連携

RPAツールの開発実績はこの価値を証明している。Playwrightで実現できているなら、API化すれば更に安定・拡張できる。

推奨技術スタック

層 現状 提案
フロントエンド ASP.NET Web Forms Next.js + TypeScript
バックエンド コードビハインド ASP.NET Core（同ベンダー、移行コスト低）
DB そのまま 読み取りAPIを追加
自動化 RPA補完 公式API提供でRPA不要に

4. 個人開発でどこまで作れるか

One人事相当の勤怠管理システムをAIエージェント（Claude/Codex）をフル活用して作る場合の試算。

期間試算

スコープ AI活用なし AI活用あり
MVP（主要機能） 6〜12ヶ月 3〜6週間
フルスコープ 2〜3年 3〜6ヶ月

トークンコスト試算

フェーズ 推定トークン
設計・DB設計 500K
フロントエンド実装 3M〜5M
バックエンドAPI 2M〜4M
デバッグ・リファクタ 2M〜3M
合計 7M〜12M tokens

Claude API（Sonnet 4.6）換算で概算 $50〜$150（約7,000〜21,000円）。Claude Code Pro（$20/月）なら実質定額に近い。

AIが得意・不得意なこと

得意:
  Terraform/CDKのコード生成
  設定ファイルの雛形
  エラーの診断
  コンポーネント実装

不得意:
  障害時の根本原因特定
  コスト最適化の判断
  セキュリティ設計の責任
  業務ロジックの妥当性判断（労働法など）

5. Supabase vs AWS：正直なコスト比較

規模別コスパ

〜1,000ユーザー:
  Supabase Pro: $25/月
  AWS相当構成:  $160〜200/月
  → Supabase 圧勝

〜10,000ユーザー:
  Supabase: $25〜100/月
  AWS:      $150〜300/月
  → まだ Supabase 有利

100,000ユーザー以上:
  Supabase: $500〜数千ドル/月
  AWS:      チューニング次第で $300〜1,000/月
  → AWS の方がコスパ良くなり始める

1,000人規模（組織内システム）の場合

同時アクセスのピーク（朝8〜9時の打刻）
→ 実際に同時接続するのは 50〜150人程度

DB容量（1年分の勤怠データ）
→ 365レコード × 1,000人 = 36.5万行
→ 容量換算で 50〜100MB 程度
→ Supabase Free の上限（500MB）でも収まる規模

Supabase Pro（$25/月）で完全に十分。AWS + エンジニアはこの規模ではオーバーエンジニアリング。

Supabase の本質

Supabase が安い理由:
  インフラ管理・運用を肩代わりしてくれている
  → その分の「エンジニア工数」が不要

$25/月は「インフラエンジニアを雇わない費用」として見るのが正確

インフラエンジニアを雇う分岐点

指標 目安
ユーザー数 5,000〜10,000人
Supabase月額 $200超え
システムの年間売上 500万円以上

個人開発フェーズでAWSを選ぶのは「コスト節約」ではなく「学習投資」と捉えるべきだ。サービスが育ってから移行すれば十分間に合う。

6. 地方でのビジネス設計

ターゲット：社員5〜50人の中小企業

規模 意思決定者 スピード
1〜5人 社長本人 即日（予算が少ない）
5〜50人 社長 or 役員 1〜4週間（最良ターゲット）
100人〜 複数部門の承認 3〜6ヶ月（官公庁に近い）

狙い目業種

IT導入が遅れており、かつ勤怠・業務管理の需要が高い業種：

  • 建設・工務店（現場管理・勤怠）
  • 介護・福祉施設（シフト・勤怠）
  • 地方の製造業（中小工場）
  • 士業（税理士・社労士事務所）

大学・官公庁 vs 中小企業

大学・官公庁:
  一度入れば 5〜10年の継続契約
  初回営業に 6〜18ヶ月かかる
  担当者異動でリセットされるリスク

中小企業:
  意思決定が早い（1〜4週間）
  一社あたりの単価は低い
  成功事例が作りやすい

戦略は順序の問題：

Phase 1（0〜1年目）:
  中小企業で実績を 3〜5件 積む
  月30〜50万円の安定収益ベースを作る

Phase 2（2〜3年目）:
  「導入実績あり」で大学・官公庁へ
  中小企業収益で長い営業サイクルを耐える

Phase 3:
  1件取れたら一気に安定

ポジショニングの注意点

❌ 「IT何でもやります」
   → 価格競争・雑務の温床

✅ 「紙・Excelの業務をシステム化する専門家」
   → 課題から入ると単価が上がりやすい

最初は「便利屋」として入口を広く取り、実績ができたら専門家として再定義していく段階的なブランド戦略が現実的だ。

まとめ

今回の考察を一言で言うと：

RPAで「業務を自動化できる人間」はすでに希少。そこにインフラとフロントエンドが乗ると、大学・官公庁向けの業務システムを一人で受託できるエンジニアになれる。

AIエージェントの活用で個人開発のスピードは劇的に上がっている。インフラはSupabaseで割り切り、フロントエンド（React + Ant Design）とビジネスロジックに集中する。地方の中小企業という「競合が少ない市場」で実績を積み、大学・官公庁という「長期顧客」を獲得していく。これが現時点での最も現実的な戦略だと考えている。

Share:
View all posts