NocoBase を活用して既存の企業システムに AI を導入する方法

AI の活用範囲は企業ソフトウェアのあらゆる部分へ広がっています。コード生成やデータ分析から、Agent、自動化、業務支援まで、既存システムの使い方そのものを見直す企業が増えています。以前の記事では、企業向けオープンソース AI Agent プラットフォーム 10 選を取り上げ、自動化、Agent 構築、社内アプリといった観点から各種ツールを整理しました。企業が選べる選択肢は、以前よりかなり増えています。

しかし、すでに CRM、ERP、MES、SaaS、または自社開発システムを使っている企業にとって、実際に AI を導入することは簡単ではありません。既存システムは長年運用され、大量のデータを蓄積し、社内の業務フロー、権限、インターフェース、従業員の利用習慣と深く結び付いています。AI 機能を追加したいと思っても、システム全体をそのまま移行したり、作り直したりするのは難しいのが現実です。

最近、Reddit の r/CRMSoftware で、ある小規模事業者が自身の経験を共有していました。

その会社では 2019 年から Salesforce を使い始め、当初は 1 アカウントだけでしたが、現在は 12 人のチームまで成長しています。この 7 年間で業務に合わせた多くのカスタマイズを行い、Salesforce は次第に会社の中核業務システムになっていきました。

事業の拡大に伴い、自動化、複数プラットフォームとの連携、通話記録、財務同期、LLM 連携、フォームなど、さらに多くの機能が必要になりました。AI Agent、インテリジェント分析、AI を使った業務自動化も試したいと考えています。Salesforce を使い続けるには上位プランへの移行が必要で、API、Agentforce、その他のサードパーティツールにも追加予算がかかります。一方で移行する場合は、既存のカスタムオブジェクト、標準外のワークフロー、過去データ、切り替え全体に必要な時間とコストを考慮しなければなりません。

このような状況は多くの企業で見られます。比較的独立した新しい要件がある一方で、既存システム内のデータは引き続き利用する必要があります。全面移行には高いコストがかかり、すべてを作り直すと、その後の保守負担も増えてしまいます。

💬 NocoBase ブログへようこそ。NocoBase は、あらゆる種類のシステム、業務アプリケーション、社内ツールを構築できる、拡張性に優れた AI 搭載のノーコード／ローコード開発プラットフォームです。完全なセルフホストに対応し、プラグインベースの設計で、開発者にもやさしい構成になっています。→ GitHub で NocoBase を見る

より柔軟な方法として、まず AI と NocoBase を組み合わせて、新しい要件だけを独立した社内アプリとして構築する方法があります。AI にすべてをゼロから開発させる場合と比べても、企業アプリではデータ関係、権限、ワークフロー、長期的な保守性が必要です。NocoBase にはこうした基盤機能があらかじめ用意されているため、AI はその上で新しいアプリの構築を支援しつつ、既存システムのデータを引き続き利用できます。

この方法なら、最初からシステム全体の移行に取り組む必要はありません。新しいアプリが徐々に成熟した段階で、必要に応じてデータや業務を少しずつ移していくことができます。

たとえば、すでに Inventory Management System を利用している製造企業が、新たにモバイル棚卸しアプリを追加したいとします。倉庫担当者は現場で商品のスキャン、実数入力、差異処理を行いたい一方で、商品、SKU、倉庫、在庫データは既存システムをそのまま利用したいというケースです。このように範囲が明確で、既存データを再利用する必要がある要件は、AI と NocoBase を使ってまず独立したアプリとして構築し、実際の利用状況に合わせて段階的に拡張する方法に向いています。

以下ではこのシナリオを例に、AI と NocoBase を使って比較的独立した新しい要件を新たな社内アプリへ変え、さらに AI 分析や自動化機能を徐々に追加していく方法を紹介します。

01｜独立して試験導入できる業務シーンを選ぶ

まずは、範囲が明確で、効果を判断しやすく、独立して試験導入できる業務要件を選びます。

範囲が明確：業務オブジェクト、操作フロー、利用者が比較的明確で、このシーンを変更しても複数の基幹システムへ同時に影響しない。
効果を判断しやすい：アプリ導入後、処理時間、手作業、異常件数、業務効率などを直接確認できる。
独立して試験導入できる：1 部門、1 グループ、または 1 つの業務工程から先に利用しつつ、既存システムのデータは引き続き利用できる。

この製造企業では、すでに Inventory Management System を使って、商品、SKU、倉庫、現在庫、在庫変動を管理しています。

新しい要件は、倉庫担当者が現場で棚卸しを完了できるようにすることです。具体的には、タスクの受け取り、商品スキャン、実数入力、在庫差異の記録、異常結果の確認を行います。

そのため、既存システムと新しいアプリの役割は、まず次のように分けられます。

	アプリ	担当する内容
既存システム	Inventory Management System	商品、SKU、倉庫、現在庫、在庫変動
新しい要件	モバイル棚卸しアプリ	棚卸しタスク、スキャン、実数、在庫差異、差異理由、確認状態

モバイル棚卸しは、タスク受け取り、スキャン、数量入力、差異確認を中心に進みます。同時に、既存の Inventory Management System にある商品・在庫データを引き続き利用します。試験導入では、1 つの倉庫、1 グループの担当者、または 1 回の棚卸しタスクから始めることができます。導入後は、棚卸し効率、手作業量、差異処理時間などの指標を使って効果を判断できます。

02｜AI と NocoBase で新しい要件を社内アプリにする

業務範囲が決まったら、既存システム、業務ルール、新しい要件を整理し、AI を使ってアプリの初期構築を行います。

たとえば：

すでに Inventory Management System があり、商品、SKU、倉庫、現在庫を管理しています。新たにモバイル棚卸しアプリを追加し、倉庫担当者が棚卸しタスクを確認し、商品をスキャンし、実数を入力し、在庫差異を記録し、異常データを確認できるようにしたいです。

Coding Agent はこの要件をもとにアプリ構造を整理し、NocoBase 上でデータモデル、ページ、ロール権限、ワークフローを設定できます。業務担当者は、誰がタスクを受け取れるか、在庫差異をどう処理するか、誰が確認するかといった具体的なルールを確定します。

モバイル棚卸しの主要フローは次のように整理できます。

棚卸しタスク → 商品 / SKU → システム在庫 → 実数 → 在庫差異 → 差異理由 → 処理状態

倉庫担当者はタスクを受け取った後、商品をスキャンして対象商品を特定し、実数を入力します。在庫差異が発生した場合、その記録は確認待ち状態となり、担当責任者が原因と処理結果を確認します。作業担当者と確認担当者には、それぞれ対応するページと操作権限を設定し、リマインドや ToDo などの後続処理は NocoBase のワークフローで対応できます。

アプリ生成後も、フィールド、ページ、レイアウト、後続機能の変更は、引き続き Coding Agent を使って NocoBase 内で調整できます。

03｜既存システムのデータを引き続き利用する

商品、SKU、倉庫、現在庫、在庫変動は、引き続き元の Inventory Management System で管理します。NocoBase は外部データベースや API を通じてこれらのデータを読み取り、モバイル棚卸しアプリ内でそのまま利用できます。

📃 データソース - NocoBase

たとえば、倉庫担当者が「ブレーキパッドセット」を棚卸しするとき、元のシステムにある現在庫、安全在庫、最近の在庫変動を同時に確認しながら、モバイル棚卸しアプリ側では実数、在庫差異、差異理由、処理結果を入力できます。

データソース	棚卸し時に使用する情報
Inventory Management System	現在庫、安全在庫、最近の在庫変動
モバイル棚卸しアプリ	実数、在庫差異、差異理由、処理状態

棚卸し中の在庫変動が結果へ影響するのを避けるため、タスク開始時点のシステム在庫と時刻を記録し、その棚卸しの照合基準として利用できます。日常の在庫管理は引き続き元の Inventory Management System が担当します。

最終的に在庫差異が確認された場合、まずモバイル棚卸しアプリ上で差異理由の記録と確認を完了し、その後、既存フローに従って在庫調整を行えます。新しいアプリから元のシステムへ直接書き戻すかどうかは、既存システムが提供する API と権限によって決まります。

この方法なら、新しいアプリは棚卸しに関するデータとフローだけを追加し、商品、SKU、倉庫、在庫といった基礎データは既存システムをそのまま利用できます。重複管理も減らせます。

04｜アプリ公開後、AI を棚卸し業務へさらに参加させる

モバイル棚卸しアプリの利用を始めると、棚卸しタスク、実数、差異理由、確認結果が新しい業務データとして継続的に蓄積されます。個別レコードを見るだけでなく、責任者は全体の棚卸し進捗、長期間未処理のタスク、どの SKU で在庫差異が繰り返し発生しているかも把握する必要があります。

アプリ構築段階では、Coding Agent が主にアプリの構築と調整を支援します。公開後は、NocoBase の AI 従業員が既存データを使って、日常の棚卸し分析などへ参加できます。

📃 AI 従業員 - NocoBase ドキュメント

たとえば、AI 従業員に棚卸し概要を生成させ、完了率、正確率、在庫差異を集計し、優先して確認すべきタスクや商品を整理させることができます。

これらの結果はアプリ内の実データをもとに生成され、責任者はいつでも対応するタスクへ戻って詳細を確認できます。

差異が繰り返し発生する SKU については、AI 従業員が実際の棚卸し結果、差異理由、最近の在庫変動を組み合わせ、さらに確認が必要な問題を整理できます。

たとえば「ブレーキパッドセット」で数回連続して差異が出た場合、最近の入庫、出庫、移動記録を優先的に確認し、重複棚卸し、時刻差、入力ミスなどがないかを調べます。すぐに原因を確認できないケースは、確認待ちとして残し、責任者が継続して判断できます。

さらに、AI 従業員へ適切なスキルとワークフローを設定し、振り返りタスクの作成、担当者へのリマインド、棚卸しレポート生成などの後続処理も行えます。AI 従業員が閲覧できるデータや実行できる操作も、実際の職種や権限に合わせて設定できます。

💡 関連記事：内蔵ワークフローと AI 従業員で企業調査を自動化する

このように、最初は AI に要約や分析を任せ、業務ルールや利用方法が安定してから、より多くの日常処理へ段階的に拡張できます。

05｜試験導入の効果を検証する

モバイル棚卸しアプリを一定期間利用した後、実際の結果をもとに、この方法を続ける価値があるか、次に範囲を拡大するか、旧システムの一部モジュールを移行するか、それとも現在の役割分担を維持するかを判断できます。

手作業での記録や重複整理が減ったか
1 回の棚卸しに必要な時間が短くなったか
在庫差異を見つけて処理しやすくなったか
既存の在庫データを安定して利用できるか
AI 従業員が日常業務へ参加できる状態になっているか
新しいアプリが日常の棚卸し業務を安定して担えるか

これらの指標がおおむね期待どおりなら、この方法は実際の業務で利用できる状態にあり、その後は 2 つの方向へ進められます。

同じ方法を新しい業務要件へ広げる

企業内に、比較的独立していて、なおかつ既存システムのデータを利用する必要がある別の要件があれば、同じ考え方を再利用できます。明確なシーンを 1 つ選び、AI と NocoBase で新しい社内アプリを作り、引き続きテストと利用を進めます。

一度に 1 つの具体的な要件だけを扱えば、アプリの範囲や検証目標が明確になり、追加投資の価値も判断しやすくなります。

既存システムの一部モジュールを移行するか評価する

新しいアプリを継続利用すると、独自のデータや業務フローが徐々に蓄積されます。いくつかの機能が旧システムの業務を安定して引き受けられるようになったら、対応するモジュールを旧システムに残す必要があるかどうかを改めて評価できます。

モバイル棚卸しアプリが、タスク割り当て、棚卸し、差異処理、確認まで安定してカバーできるようになれば、元の Inventory Management System にある棚卸し関連データやフローを NocoBase へ移行するかどうかも検討できます。

まとめ

これまで、新しい業務要件が発生したとき、チームは SaaS の購入、既存システムの改修、個別開発のスケジュール調整といった選択肢から判断する必要がありました。どの方法でもコスト評価やリソース調整が必要で、効果を確認できるまでに一定の時間がかかることも珍しくありません。

すでに CRM、サプライチェーン管理、プロジェクト管理系 SaaS などを利用していて、既存ツールではうまく対応できない新しい要件がある場合、AI と NocoBase を使えば、範囲が明確で確認済みの要件から、より軽量な形で試し始めることができます。

NocoBase + AI Demo を体験： オンライン Demo を申し込む
自分で構築する： AI Builder ドキュメントを見る

関連記事：