AI コーディングからアプリケーションガバナンスへ：増え続ける社内アプリを企業はどう管理するか？

はじめに

2026 年 10 月下旬、Hacker News にこんな投稿がありました。あなたの会社でも「社内 vibe coding アプリ」の波が来ていますか？投稿者は The Pragmatic Engineer の記事を引用しています。ある送電線工事会社では、開発者ではない数名の社員が AI で工事計画アプリを作り、地籍情報を自動で照会し、線路が通る土地の所有者にメールを送れるようにした。別の製造業の企業では、社内向けのソーシャルネットワークを自作した、という内容です。

コメント欄では、AI によって社内ツールの開発コストが大幅に下がったという意見がある一方で、アプリが増えるほど、その後の保守・機能拡張・引き継ぎが新たな負担になるのではないかという懸念も挙がっていました。

部門ごとに CRM、チケット管理、承認ツールをそれぞれ開発し、顧客情報は重複して管理され、権限ルールは揃わず、保守の担当者すらはっきりしない。これが AI コーディング時代のアプリケーションスプロール（Application Sprawl）の姿です。CRM や承認ツールは数日で作れますが、これらのアプリは別々の人が別々の時期に作ったものです。CRM の顧客テーブルとチケットシステムの顧客テーブルは次第に食い違い、3 つのアプリがそれぞれ従業員名簿を持ち、どの承認フローが正式なものなのか誰も答えられなくなります。

社内アプリの開発がますます簡単になるなかで、企業は重複開発を減らし、これらのアプリを長期的に保守可能な状態に保つにはどうすればよいのでしょうか。本記事では、共通化できる機能、ガバナンスの進め方、効果の評価という 3 つの観点から考えます。

💬 こんにちは！NocoBase ブログをお読みいただきありがとうございます。NocoBase は、AI で業務システムを継続的に開発・運用するためのオープンソースプラットフォームです。Agent がコードを書いて実行し、NocoBase が基盤とガバナンス機能を提供し、人が意思決定を行います。→ GitHub で NocoBase を見る

01｜社内アプリの「共通化する部分」と「独立させる部分」の境界を決める

社内アプリは部門ごとに異なる相手にサービスを提供しており、業務ルールも操作の仕方もそれぞれ違います。アプリケーションガバナンスでまず明確にすべきなのは、どの基礎機能を統一的に管理する価値があり、どの部分を業務部門の判断に任せるべきか、という点です。

たとえば、CRM とチケットシステムはどちらも顧客情報を必要としますが、一方は営業案件を、もう一方は顧客からの依頼を管理します。両者は顧客マスタデータを共有しつつ、具体的な業務モデルや処理フローはそれぞれの特性を保てばよいのです。

この原則は、権限、ワークフロー、インフラにも同じように当てはまります。

観点	統一・再利用を推奨する機能	独立させておく業務部分
データ	マスタデータのソース、データ標準、アプリ間アクセスの規約	アプリ固有のデータモデルと業務レコード
権限	認証連携の規約、権限の基礎機能	各アプリのロール割り当て、操作権限、データ範囲
ワークフロー	フローエンジン、状態管理、通知機能	各アプリ固有の承認・業務フローのルール
インフラ	デプロイ規約、アップグレード、バックアップと復元	画面の操作性、部門専用の業務ロジック

統一されたアプリケーション基盤を使うからといって、複数の独立したアプリが自動的にデータベースやユーザーアカウントを共有するわけではありません。アプリ間のデータ連携や ID 管理は、実際のアーキテクチャに合わせて設計する必要があります。

NocoBase 3 では、NocoBase Core がフレームワークと依存パッケージの形で、認証、権限、ワークフロー、ファイル管理などの基礎機能を提供します。Coding Agent はこれらの機能を土台に業務画面、API、データモデル、業務ルールを開発し、そのコードは企業自身のプロジェクトリポジトリに保存されます。

こうすることで、業務アプリは既存の基礎機能を再利用でき、その後の変更も Git、テスト、コードレビューで管理できます。

NocoBase 3 のアプリケーション基盤

共通機能と業務部分の境界を引いておけば、チームは既存のインフラを再利用しながら、各業務アプリの独立性を保つことができます。

02｜既存の社内アプリを段階的にガバナンスするには？

2.1 ステップ 1：既存アプリと保守責任の棚卸し

項目	記入内容
アプリと用途	普段みんなが実際に呼んでいる名前、アクセス先の URL、そして業務の言葉での一行説明。例：「フィールドセールスが訪問と案件を記録する」。
所属と保守担当者	アプリが消えたら文句を言いに来る部門と、質問に答えて変更を承認できる具体的な担当者名。名前が書けない場合は「なし」と記入し、リスクとして扱う。
構築方法と稼働環境	どう作ったか（Coding Agent、手書きコード、SaaS の設定、マクロ付きスプレッドシート）、どこで動いているか、デプロイ用の認証情報を誰が持っているか、バックアップと復元ができるか。
主要なデータエンティティ	主なテーブルやオブジェクト：顧客、注文、従業員、チケットなど。他のアプリにも存在するものには印を付ける。
データソースと依存関係	どのアプリや外部システムとデータを読み書きしているか。方向も明記する：読み取りのみ、書き込みのみ、双方向。
ID と権限	会社の SSO と共有ロールを使っているか、独自のユーザーテーブルを持っているか。各ロールが何を閲覧できるか。
ワークフローと承認	すべての承認・自動化フロー、承認者、トリガーされる処理。他のアプリと重複している可能性があるものに印を付ける。
利用状況と変更履歴	おおよそのアクティブユーザー数、直近半年の変更回数。既知の弱点、たとえばデータの手動同期や、理解している人が一人しかいないこと。

最初の一巡では、答えが粗くてもよいので、すべてのアプリを一覧に載せることを優先します。詳細は限られていても全アプリを網羅した一覧のほうが、3 分の 1 だけを精密に埋めた一覧よりも役に立ちます。これは、新しく参加する Coding Agent が最初に読めるものにもなります。

2.2 ステップ 2：統一する価値のある基礎機能を見極める

一覧にあるアプリを 3 つの基準で採点します。

重複度： ある機能が複数のアプリで繰り返し実装されているか。
関連度： 同じ種類のデータを読み取ったり変更したりする必要があるか。
変更頻度： あるルールが頻繁に調整され、そのたびに複数のアプリへ反映が必要になっているか。

重複度が高く、関連が密で、変更の多い機能は、統一管理や再利用を優先的に検討します。たとえば、従業員と部門の情報は単一のソースにまとめ、CRM とチケットシステムは同じ顧客マスタデータを参照できます。

これらの機能は、共有サービス、外部データソース、再利用可能な業務モジュールのいずれかで実現できます。どの方式を採るかは、既存のシステムアーキテクチャと合わせて判断する必要があります。

関連が少なく安定して動いているアプリは、統一のために移行する必要はありません。余計な開発・保守コストを増やすだけになります。

2.3 ステップ 3：Coding Agent 向けの共通開発規約を整える

Coding Agent が継続的に開発に関わるようになると、企業にはもう一つ解決すべき課題が生まれます。新しい Agent は、既存のデータモデル、権限ルール、再利用できる機能をどうやって知るのか、という問題です。

この情報がなければ、Agent は新機能の開発時に既存のデータ構造を重複して作ったり、既存システムと一貫しない実装方法を採ったりするおそれがあります。

企業はプロジェクトリポジトリに AGENTS.md を置いて維持し、マスタデータのソース、共通機能、開発規約、変更時の要件を、Agent が読めるプロジェクトガイドとしてまとめることができます。

たとえば、次のような規約を加えられます。

開発前に既存のデータモデル、権限、ワークフローを確認し、既存の機能を優先して再利用すること。

顧客、従業員、部門などのマスタデータは指定されたソースを使い、重複して作成しないこと。

既存のプロジェクト構成と命名規則に従い、基盤を勝手に変更しないこと。

共有データ構造、ロール、API に関わる変更では、まず影響範囲を説明し、人によるレビューを待つこと。

コミット前に権限宣言、データマイグレーション、テスト結果を確認すること。

これらの規約はプロジェクトとともに継続的に更新する必要があります。特に共有ルールに関わる変更では、Agent がまず問題を提起し、担当者が確認してから開発を続けるべきです。

NocoBase Studio のタスクにある「あなたの対応が必要」カード：Agent が承認ルールの曖昧さに気づき、担当者の返答を待って停止している

NocoBase 3 はアプリの継続的な開発をどう支えるか？

開発規約があっても、Coding Agent には既存プロジェクトを理解し、そこにすでにある機能を活用する手段が必要です。NocoBase 3 は、アプリケーション基盤、開発規約、デリバリー管理の 3 つの面からこれを支えます。

NocoBase Core：再利用できるアプリケーションの土台。

Core はデータモデリング、ID と権限、ワークフロー、通知などの基礎機能を提供します。業務コードは統一されたプロジェクト構成で整理され、たとえばデータモデルは database/、画面は client/pages/、API は server/routes/ に置かれます。

Coding Agent は既存のデータ構造と業務コードを参照し、既存アプリの中で新機能を開発できるため、重複開発を減らせます。

AGENTS.md、Rules、Skills：開発をプロジェクト規約に沿わせる。

AGENTS.md は Coding Agent がプロジェクト規約を読む入口であり、.agents/rules/ にはアプリ自身の開発規約を、.agents/skills/ にはインストール済みのプラットフォーム機能に対応した開発スキルを置きます。

チームでの協働に向けて、NocoBase Studio ではナレッジベースに業務資料を保存し、プロジェクトメモリに確認済みのルールや意思決定の背景を記録することもできます。これらの情報は後続の開発タスクで再利用でき、担当者や Coding Agent が入れ替わったときの説明の繰り返しを減らします。

NocoBase Studio における Agent タスクの引き継ぎ

NocoBase Studio：開発・レビュー・リリースを管理する。

NocoBase Studio は、人と Agent が協働して開発するための商用プラットフォームです。チームは Studio でタスクを割り当て、開発の進捗を追跡し、コードチェック、独立したレビュー、プレビュー環境を組み合わせて変更結果を検証できます。

開発が完了すると、担当者はデリバリーレポートと受け入れ基準に基づいて結果を確認し、マージして次のリリース工程に進めるかどうかを判断します。

NocoBase Studio での人による受け入れ確認

これらの仕組みによって、Coding Agent は既存アプリを土台に開発を続けられ、チームは開発規約、変更プロセス、デリバリー結果をより明確に管理できます。

2.4 ステップ 4：新規要件から着手し、既存アプリを段階的に最適化する

新しい要件が出てきたら、まず既存の機能を再利用できるかを判断します。たとえば財務部門が経費審査機能を追加したいとします。従業員の ID、部門の関係、承認の仕組み、通知はすでに存在しており、本当に新しく作るのは経費データのテーブル 1 つ、審査フローの定義 1 つ、画面数枚、そして財務審査担当者向けのロール範囲だけです。Coding Agent は既存の開発規約に従い、Core が提供するデータ・権限・ワークフローの機能を再利用して、経費記録、審査フロー、関連画面を開発できます。従業員情報は実際のアーキテクチャに応じて既存のデータソースと関連付け、財務審査の権限はアプリ内で明示的に宣言します。新機能が完成したら、テストと人による受け入れ確認で結果をチェックし、そのうえでリリースするかを決めます。

新規要件での試行を終えたら、チームは実際の開発・保守の状況をもとに、既存アプリの調整が必要かどうかを段階的に評価していきます。安定して動いていて他システムとの関連が少ないアプリはそのまま残してよく、統一のために移行する必要はありません。

NocoBase Studio のリリースページ：プレビュー、テスト、バージョン、本番の状態

📃 導入事例：Sungrow は複数の業務モジュールを 1 つのシステムでどう管理しているか？

Sungrow（陽光電源）の海外チームは、AI と NocoBase 3 を活用し、約 2 か月で商談、プロジェクト、技術提案、見積、受注などの業務をカバーするシステムを構築しました。チームは NocoBase のデータ、権限、ワークフローの機能をそのまま再利用し、業務要件に基づいて AI に具体的な機能を生成させ、業務担当者が確認・調整を行いました。

これまでスプレッドシート、ファイル、コミュニケーションツールに散らばっていた業務情報を、今では 1 つのシステムで管理できています。各モジュールは関連データを共有しながら、それぞれの業務ルールも維持しています。要件が増えても、チームは既存システムの上で機能を拡張し続けることができます。

03｜アプリケーションガバナンスの実際の効果をどう評価するか？

共通基盤と開発規約を整えたあとは、これらの施策が本当に開発・保守コストを下げているのかを判断する必要があります。

企業は次のような観点から継続的に観察できます。

評価の観点	記録を推奨する指標
重複開発	新しいアプリで重複して作られたデータ構造と基礎機能の数
変更管理	変更の影響範囲を特定するのに要した時間と、リリース後に起きた想定外の問題の数
開発の引き継ぎ	新しい開発者や Agent がプロジェクトを理解するのに要した時間と、人が説明した回数
日常の保守	アプリ間でデータを手動同期した回数と所要時間
保守責任	明確な担当者がいない、またはバックアップ・復元の仕組みがないアプリの数
デリバリー品質	Agent の変更がレビューで却下された、手戻りになった、リリース後にロールバックされた回数

これらの指標は月次または四半期ごとに記録し、アプリ数、業務の複雑さ、実際の利用状況と合わせて比較します。

アプリケーションガバナンスの効果は、最終的には日々の業務に表れます。新機能の追加で重複開発が減ったか、既存システムの変更時に影響を評価しやすくなったか、新しい開発者や Coding Agent がスムーズに引き継げるようになったか、です。

おわりに

既存アプリにデータ一式、フロー 1 本、機能 1 つを追加するだけで問題が解決することもあります。Coding Agent に開発前から既存システムを理解させ、既存の機能を優先して活用させ、その後の変更と引き継ぎのために明確な根拠を残しておくこと。これが、増え続ける社内アプリの保守負担を減らす道です。

Coding Agent に既存の業務システムを土台として継続的に開発させたい方は、NocoBase 3 公式ドキュメントで、より具体的な開発方法とプラットフォーム機能の説明をご覧ください。

関連記事