Aurant Technologies（自社）｜業務システムを自社専用のWebアプリで。ノーコードの業務アプリから移した社内ERP

本事例は、当社（Aurant Technologies）の社内の取り組みを、社内の設計書と移行の記録をもとにまとめたものです。当社は、案件・顧客から請求、稟議や経費などの申請、採用、グループの税理士事務所の業務までを、自社専用に作った業務アプリの基盤（Webアプリ。以下、社内ERP）で動かしています。業務システムを、ノーコードの業務アプリではなく Webアプリとして作ることを検討する際の参考にしていただければ幸いです。

アプリが増えて、全体が見えなくなっていた

当社は、2026年7月まで、社内の業務をノーコードの業務アプリ作成サービスで回していました。業務ごとにアプリを短い期間で作れる一方で、アプリは108、項目は3,010まで増えていました。役割の重なるアプリや旧版のアプリが残り、画面に埋め込んだスクリプトによる改造や、アプリごとにばらばらの権限の設定も増えていました。

業務の上で困っていたことは4つです。案件・請求・工数は別々のアプリにあり、事業部ごとの売上と利益率を1枚にまとめるには、CSV を出して表計算で突き合わせていました。検索は1つのアプリの中に閉じていて、アプリをまたいで探せません。権限の設定はアプリの単位だけで334件あり、誰が何を見られるかを1つの画面で確かめられませんでした。顧客と案件の記録も、会社の側と税理士事務所の側で別々のアプリに分かれていました。

自社専用の業務アプリの基盤を作る

作り直す目的は3つです。顧客・案件・稼働・請求・会計を1つのデータベースに集め、アプリをまたいで集計・検索できるようにすること。権限を「アプリ・レコード・項目」の3層で一本化し、画面・API・CSV・AI のどの経路でも同じ判定を通すこと。状態を変える操作について、誰が・いつ・何を・どの要求で変えたかを残し、人が読める場所に出すことです。

作ったのは、アプリ・項目・レコードをデータとして定義して動かす、社内専用の業務アプリの基盤です。項目には、文字列・数値・日付・選択肢・利用者・ルックアップ・明細の表などの型をそろえました。顧客や料金プランのようなマスタも、ふつうのアプリとして持ちます。

ただし、以前のサービスを画面ごと再現するものにはしていません。誰でも画面からアプリを作れる仕組みにはせず、アプリの新設や廃止、テーブルの構造、承認の流れの定義、権限の仕組みの変更は、レビューと検査を通してから本番に出します。項目の必須や選択肢、共有の一覧、アクセス権、通知といった日々の設定は、アプリの管理者が画面から変えられ、その変更も記録に残ります。

進め方も、書類の設計書から入るのではなく、動く画面を先に作り、それを見ながら決めていきました。要件定義書と設計書は、稼働している実装を書き起こす形でまとめ、IPA の「共通フレーム」「非機能要求グレード」「安全なウェブサイトの作り方」を参照しています。開発は少人数で、AI のコーディング支援を使いながら進めています。

権限・承認・記録は、基盤の側で持つ

権限は、アプリ（開けるか）、レコード（どのレコードが見えるか）、項目（どの項目を読めるか・書けるか）の3層で判定します。どの規則にも当たらない人は見られない「既定は拒否」とし、上の層で拒否されたものを下の層で広げることはできません。画面で隠した操作も、API の側で同じ判定をやり直します。原価や時給のような項目は、項目の層で隠すと一覧の列にも検索の条件にも出ず、CSV に書き出すときも、その項目を読めるかを確かめます。

部署ごとにデータを分けることはしていません。全アプリを1つの一覧に置き、「この部署の人だけが使うアプリ」は、そのアプリに部署あての許可を1本置いて表します。グループの税理士事務所の業務も、同じ基盤の中で、見える人をアクセス権で分けています。

稟議・出張・交通費・書籍購入・経費などの申請は、レコードの状態として扱います。申請・承認・差し戻しを、誰がいつ行ったかとあわせて残し、承認者は申請ごとに指名します。状態が変わると、チャットツールに知らせます。いまは1段の指名承認で、代理承認や多段の承認は次の段階で扱います。

記録は3層で残します。レコードの作成者・更新者と日時、版の履歴（いつ・何が・どう変わったか）、監査のログ（権限の変更、書き出し、設定の変更など、レコードの外で起きたこと）です。1つの記録でほかの記録の代わりにはしません。監査のログと版の履歴は、書き換えたり消したりする経路を作っていません。レコードの削除も論理削除にして、版を残します。

アプリをまたぐ集計は、項目をドラッグして組み立てる横断レポートで行います。ルックアップでつながったアプリは自動で結合し、結合で行が増えても合計を二重に数えません。共有されたレポートでも、見る人が読めないレコードや項目は集計に出ません。

業務データは AI からも使えます。社員は自分の AI のツールから MCP（AI がほかのシステムのデータを扱うための共通の仕組み）でつなぎ、本人の権限の範囲で読み書きできます。つなぐための鍵を使っても、権限は増えません。社内ERPの中で AI に質問する機能は読み取りだけで、出典の無い答えは返さず、外部の生成AIに送るのは「公開」と「社内」の区分の項目だけです。

作らないと決めたものもあります。請求書と見積書の PDF は社内ERPでは作らず、会計のクラウドサービスで発行します。請求の予定は社内ERP、発行した請求書と入金は会計のサービスを正本とし、会計の側で直したものは自動で追いかけずに差異として残します。発行の実績がほとんど無い納品書などの帳票や、任意のプログラムをサーバーで動かす拡張の仕組みも作っていません。

業務ごとに切り替え、全項目を照合する

全アプリを一度に切り替えることはしていません。2026年7月に、以前のサービスから設定（アプリ・項目・一覧・権限）とレコードを取り出して一括で移し、そのあと業務ごとに入力先を切り替えました。業務ごとに、新しい入力が入っている側を正本と判定し、表にして管理しました。

7月にリードの受付、8月に稟議や経費などの申請と承認、9月には表計算で管理していた営業の案件と予実、という順に移しました。工数・勤怠や税理士事務所の業務のように、しばらく以前のサービスで入力を続けた業務は、差分を取り込みながら並行して動かし、9月に以前のサービスとの連携を終えて、すべて社内ERPを正本にしました。8月末の時点で、以前のサービスの108のアプリのうち移したのは48です。名前に「旧」などが付いたアプリも名前だけでは捨てず、件数・参照元・担当者を確かめて移すかどうかを決める方針にしました。

移したデータは、照合の道具を作って全項目で突き合わせました。48のアプリの約1,360万の値を比べ、差は251個でした。いずれも書式の違い、表記の日本語化、移行のあとで直したもの、のどれかで、移行で失った値はありませんでした。添付ファイルも、中身のハッシュ値がすべて一致しています。照合で見つかったルックアップのつながりの欠けは張り直し、その後はデータベースの側でつながりをそろえる仕組みにしました。

請求は、未入金と表示されていた請求書を会計のサービスと全件で照合しました。会計の側で取り消した請求書が未入金のまま表示されていたずれが見つかり、取消の状態を反映するように直しています。

使いながら直したこと

使い始めてから見つかったことは、同じことが起きない仕組みにして直しています。

2026年8月、請求書のアプリで、許可の規則が1本も無いままアクセス権が公開され、管理者のほかは誰も開けなくなりました。「既定は拒否」の設計どおりの結果ですが、別のアプリでも同じことが起きたため、公開中のアプリで許可が0本になっていないかを機械で見つけるようにしました。

作成者と作成日時は、データとしては初めから持っていたのに、画面にも API にも出ておらず、「誰がいつ入れた顧客か」を追えませんでした。2026年8月に全アプリの詳細の画面で常に出すようにし、退職した人の名前も記録から消えない出し方に変えています。

特定の組織にだけ見せたいアプリを、一度はデータの置き場所を分けて隠す形にしましたが、誤りとして戻しました。いまは、見せるかどうかをアクセス権だけで表します。また、原価を見せるかどうかの判定が画面と API で分かれていて、API からだけ見えない人がいたことがありました。同じ値を見せるかどうかの判定は1か所にまとめ、画面・API・集計のどの経路もそれを呼ぶ決まりにしています。

本番に出す前には、権限を越えた読み書きをデータベースの側でも拒めるかの試験を含む検査を、最後まで通しています。

業務システムの作り直しや、以前の仕組みからの段階的な移し方は、基幹システムの刷新・レガシー移行のページで紹介しています。

当社で AI を使い、記帳や議事録、問い合わせへの返信の下書きなどを自動にしている取り組みは、AI で社内の業務を自動化した事例で紹介しています。

※本事例は、当社の社内の設計書と移行の記録をもとに構成しています。図は構成を簡略化して描いたもので、画面や実際のデータではありません。記載の会社名・製品名は、各社の商標または登録商標です。