0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PostgreSQL だけじゃない 外部データベース対応のノーコード/ローコードプラットフォーム 5 選 비교

0
Posted at

オリジナルの公開場所:https://www.nocobase.com/ja/blog/5-no-code-low-code-platforms-supporting-external-databases-mysql-mongodb-api

この記事のポイント

既存データベースを活かして、CRM、ERP、承認、チケット管理などの本格的な業務システムを構築したいなら、NocoBase が最も適しています。複数データソースの管理、データソースをまたいだ関連付け、そして高度な業務モデリングに対応しているためです。社内ツールや操作画面をすばやく作りたいだけであれば、Retool、Appsmith、ToolJet のほうが立ち上がりは速いでしょう。承認やチケット管理のような、フロー中心のアプリを重視するなら、Budibase のほうが向いています。

はじめに

企業の業務ニーズがますます多様になるなか、多くのチームが既存のデータやシステムを土台にしながら、不足している業務アプリをすばやく補い、CRM、ERP、承認、チケット管理といった社内向けシステムを整備したいと考えています。こうした場面では、基幹システムを大きく変えずに既存のデータソースへ柔軟につなげられるノーコード/ローコードプラットフォームが、有力な選択肢になっています。

これまで私たちは、PostgreSQL をテーマに 2 種類の記事を公開してきました。1 つは実践寄りの 「PostgreSQL を使って実用的な CRM を構築する方法」、もう 1 つは比較・選定寄りの 「PostgreSQL をサポートする 6 つのノーコードツール」 です。後者では、各プラットフォームが PostgreSQL にどこまで深く対応しているかを、ネイティブ統合、リレーションモデリング、セルフホスティングといった観点から横断的に比較しました。

ただ、PostgreSQL はあくまで一般的な選択肢の 1 つです。実際には MySQL、MariaDB、MongoDB を使っているチームも多く、一部のデータはデータベースではなく、REST API や GraphQL を通じて提供されていることもあります。

そこで本記事では、外部データソースへの対応範囲と接続の深さ、複雑な業務関係やフロー・権限への対応力、業務システム構築のしやすさ、そして長期的な拡張性という視点から、主要なノーコード/ローコードプラットフォームを詳しく比較します。

注:本記事の情報ソース

本記事に含まれる製品機能やデータソース対応状況などは、主に各製品の公式サイト、公式ドキュメント、GitHub リポジトリ、および公開情報をもとに整理・要約したものです。


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


今回比較するのは、現在特に注目されている 5 つのノーコード/ローコード開発プラットフォームです。対象は以下のとおりです。

NocoBase

nocobase1.png

データモデルを軸にしたオープンソースの AI ノーコード/ローコードプラットフォームです。複雑なデータ関係、権限、ワークフロー、プラグイン拡張を 1 つの基盤に統合しており、既存データを活かしながら、企業向けアプリ、内部ツール、複雑な業務システムを継続的に構築していくのに向いています。

公式サイト:https://www.nocobase.com/

GitHub:https://github.com/nocobase/nocobase

データソース関連ドキュメント:https://docs.nocobase.com/data-sources/data-source-manager/

Retool

Retool1.png

社内チーム向けの操作画面やデータツールをすばやく構築できるプラットフォームです。データベース、API、ワークフロー、フロントエンド部品を組み合わせて、管理画面、運用パネル、データ処理ツールなどの内部ソフトウェアを効率よく作れます。

公式サイト:https://retool.com/

GitHub:https://github.com/retool

データソース関連ドキュメント:https://docs.retool.com/data-sources/

Appsmith

Appsmith1.png

開発者にとって扱いやすいローコードのフロントエンド寄りプラットフォームです。既存のデータベース、API、スクリプトの上に、CRUD アプリ、管理画面、カスタム内部ツールをよりスピーディーに構築でき、JavaScript や Git ワークフローによる制御もしやすいのが特徴です。

公式サイト:https://www.appsmith.com/

GitHub:https://github.com/appsmithorg/appsmith

データソース関連ドキュメント:https://docs.appsmith.com/connect-data/overview

Budibase

Budibase1.png

フォーム、承認、申請、フロー主導のアプリに強みを持つプラットフォームです。製品の重心が内部業務プロセスの自動化にあるため、サービス申請、チケット処理、承認フロー、データ収集といった、まず業務フローありきのシーンに適しています。

公式サイト:https://budibase.com/

GitHub:https://github.com/Budibase/budibase

データソース関連ドキュメント:https://docs.budibase.com/docs/data-sources

ToolJet

ToolJet1.png

複数データソースへの接続と、社内ツールのすばやい構築を重視するプラットフォームです。データベースだけでなく、API、SaaS、クラウドサービスにも幅広く対応しており、複数の既存システムを 1 つの統合操作画面にまとめたいチームに向いています。

公式サイト:https://www.tooljet.com/

GitHub:https://github.com/ToolJet/ToolJet

データソース関連ドキュメント:https://docs.tooljet.com/docs/data-sources/overview/

一、外部データソース対応と接続の深さ

プラットフォーム 対応するデータソースの種類 代表的なデータソース 接続の深さ
NocoBase リレーショナルデータベース、NoSQL、API、ファイル型データソース MySQL、MariaDB、PostgreSQL、MSSQL、Oracle、KingbaseES、REST API 単なる接続や読み書きにとどまらず、複数データソースの一元管理、データソースをまたいだ関連クエリ、既存データをもとにした継続的なモデリングにも対応
Retool リレーショナルデータベース、NoSQL、データウェアハウス、API PostgreSQL、MySQL、MongoDB、Snowflake、BigQuery、REST API、GraphQL、Google Sheets 既存データソースを 1 つの画面に統合し、クエリ、コンポーネント、ワークフローを通じて読み取り、更新、運用できる点に強みがある
Appsmith リレーショナルデータベース、NoSQL、検索エンジン、API PostgreSQL、MySQL、MongoDB、Microsoft SQL Server、Oracle、Redis、Snowflake、GraphQL 既存のデータベースや API をもとに、クエリ、画面、インタラクションロジックを構成し、アプリのフロントエンド層をすばやく形にしやすい
Budibase リレーショナルデータベース、NoSQL、キャッシュ、API、オブジェクトストレージ PostgreSQL、MySQL / MariaDB、MongoDB、MS SQL Server、Oracle、Redis、S3、Google Sheets 外部データソースへの接続に加え、クエリ、フォーム、フロー設定を通じてアプリにデータを取り込めるが、全体としてはデータ駆動型の画面とフローが中心
ToolJet リレーショナルデータベース、NoSQL、データウェアハウス、API、SaaS データソース PostgreSQL、MySQL、MongoDB、MS SQL Server、Snowflake、BigQuery、REST API、GraphQL 多様なデータソースを接続したうえで、読み取り、更新、統合操作を行うことに強く、SQL とビジュアル設定の両方でクエリを構成できる

ポイントまとめ

  • Retool、Appsmith、ToolJet は、既存のデータベースや API の上に、操作画面やツール層をすばやく作り、データを接続して、取得して、更新できるようにするタイプです
  • Budibase はその延長線上にありつつ、よりフロー型アプリに寄っています
  • NocoBase は、「既存データを土台にそのままシステムを育てていく」という方向性により近く、複数データソース管理、クロスソース関連付け、継続的なモデリングにおいてより高い拡張性があります

NocoBase2.png

二、複雑な業務関係、フロー、権限への対応力

プラットフォーム 複雑な関係への対応 フロー / 自動化 権限の粒度 適した業務の複雑さ
NocoBase 強い。複数テーブルの関係や複雑な業務オブジェクトに向く ワークフローを内蔵し、データ駆動型フローに対応 ロール、操作、データ、フィールド単位の権限管理 中〜高複雑度の業務システム
Retool 中〜強。内部ツールのロジック設計寄り ワークフローが成熟しており、多段階タスクに向く ロール権限、権限グループ、オブジェクト単位の制御 中程度の複雑さの社内ソフト
Appsmith 中程度。関係の表現は開発設定への依存が大きい クエリ、スクリプト、イベントでフローを構成可能 アプリ、ページ、クエリなど細かな制御に対応 中程度の複雑さのカスタムアプリ
Budibase 中程度。フォームやフローの関係に強い 承認、申請、状態遷移に向く ロール、データセット、フィールド単位の制御 中程度の複雑さのフロー型アプリ
ToolJet 中程度。ツール層の統合寄り ワークフロー、条件分岐、通知に対応 ロール、ワークスペース、カスタムグループ権限 低〜中程度の複雑さのツール

ポイントまとめ

  • 業務が複雑で、既存データベースをもとに CRM、ERP、承認、チケット管理などの本格的な業務システムを継続的に構築したいなら、NocoBase のほうが適しています
  • 要件がより軽く、まずは社内ツール、運用管理画面、またはフロー型アプリをすばやく作りたいなら、Retool のようなプラットフォームのほうが扱いやすいです

Retool2.png

三、業務ページ構築の効率

プラットフォーム ページ対応 構築方法 コードの関与 適したシーン
NocoBase テーブル、フォーム、詳細、カンバン、グラフ、操作ページ ブロック設定 + JS ブロック拡張 + アクション設定 + AI エージェントによる補助生成 低い。複雑な要件はスクリプトやプラグインで拡張可能 データ駆動型の業務ページ、複雑な管理画面
Retool テーブル、フォーム、グラフ、パネル、管理画面 キャンバス + コンポーネントのドラッグ配置 + コード 中程度。一般的な場面でも SQL や JS を組み合わせることが多い 操作台、データツール、内部管理画面
Appsmith テーブル、フォーム、グラフ、ダッシュボード、CRUD ページ ドラッグ&ドロップ + JS カスタマイズ 中〜高。開発者主導に向いている カスタム内部アプリ、開発者主導ページ
Budibase フォーム、テーブル、承認ページ、申請ページ、管理画面 ローコード設定 + フォームフロー 低〜中。複雑なロジックは追加設定で対応 フォーム駆動、フロー型ページ
ToolJet テーブル、フォーム、グラフ、ダッシュボード、内部ツールページ ドラッグ式フロントエンドビルダー 中程度。複雑なツールページではクエリやイベント設定が必要になることが多い 複数データソースのツールページ、運用管理画面

ポイントまとめ

  • Retool、Appsmith、ToolJet は、開発力があり、カスタマイズやロジック制御の余地を残したいチームにより向いています
  • Budibase は、技術的なハードルがそれほど高くなく、設定中心でページやフローをすばやく構築したいチームにより向いています
  • NocoBase はより柔軟で、WYSIWYG 型の設定に対応するだけでなく、JS ブロックAI エージェント によって、さらに構築のハードルを下げることもできます

Budibase2.png

四、長期的な拡張性

プラットフォーム 拡張方法 オープン性 維持・継続性 代表的な適用シーン
NocoBase プラグイン拡張、データモデルを軸にしたページ / ブロック / アクション / API 拡張 高い。マイクロカーネル + 完全プラグイン化 強い。段階的なモジュール追加と長期構築に向く 複雑な業務システム、フロー型アプリ、継続的に進化する企業アプリ
Retool モジュール再利用、カスタムコンポーネント、コード拡張、バージョン管理 高い。コンポーネントやクエリの再利用に加え、カスタム React コンポーネントにも対応 強い。複数人で継続的に改善する社内ソフトに向く 社内ソフト、運用ツール、データアプリ、継続改善型プロジェクト
Appsmith JavaScript カスタマイズ、カスタムコンポーネント、Git ワークフロー、パッケージ管理 高い。開発者が深く関与できる 強いが、継続的な保守は開発チームへの依存が大きい カスタム内部アプリ、開発者主導プロジェクト、継続改善型バックオフィスシステム
Budibase 自動化、カスタムプラグイン、カスタムデータソース、セルフホスト拡張 中〜高。セルフホスト環境ではプラグインやデータソース拡張の柔軟性が高い 中〜強。フローやアプリを段階的に拡張するのに向く フロー型アプリ、承認 / 申請システム、内部運営アプリ
ToolJet コンポーネント設定、クエリロジック、ワークフロー拡張、カスタムコンポーネント 中〜高。拡張は可能だが、全体としてはツール層の延長に近い 中程度。ページ追加やデータソース統合の継続に向く ツール型アプリ、複数システム統合、内部管理画面と運用ツール

ポイントまとめ

  • NocoBase のプラグイン機構は非常に強力で、高い制御性と深いカスタマイズ能力を求めるチームにより適しており、その後の保守や継続的な拡張にも十分な余地があります
  • Appsmith では、開発者がページやロジック制御により深く関われるため、継続的な改善やカスタマイズの面でも優れています

Appsmith2.png

五、AI 対応度

プラットフォーム 現在の AI 機能 業務データ / フローとの組み合わせ方 今後の AI 活用余地
NocoBase AI エージェントを内蔵し、業務要件に応じてシステム内で役割や能力を定義できる 現在のページ、データ、テーブル構造をもとに業務文脈を理解し、データベース照会、フォーム入力、データ更新などの実際の業務操作を直接実行できる 強い。既存の業務システムやフローに AI を組み込みやすい
Retool AI による app 生成、workflow 生成、Retool Agents に対応 Agents は外部システム、ワークフロー、データソースに接続でき、app / workflow から直接呼び出すことも可能 強い。内部ソフト、フロー、システム操作層に AI を取り込みやすい
Appsmith Appsmith AI によるクエリ機能を提供 アプリ層で AI 機能を呼び出し、文章生成、分類、分析などを補完する方向に近い 中〜高。既存アプリに AI インタラクションを加えるのに向く
Budibase Agents、Agent Chat、AI automation をすでに提供 Agent は automation flow に接続でき、workspace 内のデータやツールとも連携できる 強い。承認、申請処理、フロー型アプリに AI を組み込みやすい
ToolJet 自然言語による app / query / workflow 生成と OpenAI プラグインに対応 AI でアプリを生成し、ワークフローやデータソースと組み合わせてさらにロジックを補える 中〜高。構築の加速手段や補助機能として AI をツール層に取り込むのに向く

ポイントまとめ

Retool、ToolJet、Appsmith のようなプラットフォームでは、AI 機能はアプリ生成、クエリ生成、開発効率向上の方向に寄っています。

Budibase は、AI を業務ページやフローの中で実際に活用するのにより向いています。

NocoBase は、構築段階で AI を使って設定のハードルを下げることもでき、その後の業務ページやフローでも継続して AI を活用できます。

NocoBase3.png

まとめ

NocoBase は、データモデルとプラグイン機構を中核に持つプラットフォームとして、多様な外部データソースに対応するだけでなく、既存データベースを土台にしながら、CRM、ERP、承認、チケット管理などの本格的な業務システムを継続的に構築するのに特に適しています。さらに、今後は AI 機能も段階的にシステムへ取り込んでいく予定です。技術チームを持ち、既存データをもとにより深い制御やカスタマイズを行いたい場合、NocoBase は有力な選択肢になります。

Retool は、データベース、API、ワークフローをすばやく 1 つの内部操作層へつなぐのに向いており、内部ソフト、運用管理画面、データツールの構築効率に強みがあります。まず使える内部システムをすばやく作りたい、かつチームに一定の開発力があるなら、Retool のほうが扱いやすいでしょう。公式サイトでも、データ、システム、ルールを接続して内部ソフトを構築でき、データベース、API、ワークフロー、バージョン管理に対応していることが強調されています。

Appsmith は、開発者にやさしいローコードのフロントエンド寄りプラットフォームで、既存のデータベースや API の上にカスタム内部アプリをすばやく補完するのに向いています。チームが JavaScript、カスタムコンポーネント、Git ワークフローに対する強い制御力を維持したいなら、Appsmith のほうが適しています。公式サイトでも、既存システムの上にカスタムアプリを構築できるオープンソースのローコードアプリプラットフォームとして位置づけられています。

Budibase は、フォーム、承認、申請処理、フロー型アプリにより適しており、データとフローを軸に内部アプリをすばやく組み立てられる点が強みです。技術的なハードルがそれほど高くなく、承認、チケット管理、運営フローのようなアプリを重視するなら、Budibase のほうが自然な選択です。公式サイトでも、内部ツール、ワークフロー、業務プロセス自動化を中核に据えています。

ToolJet は、データベース、API、サードパーティシステムを 1 つのツール層の画面に統合できるため、複数データソースを扱う企業内ツールの構築に強みがあります。要件が複数システムの統合、運用管理画面、またはツール型アプリ寄りであれば、ToolJet はより直接的な選択肢になります。公式サイトでも、企業向けアプリを迅速に構築できるプラットフォームとして位置づけられています。

FAQ

  1. 単純な CRUD ではなく、より複雑な業務要件に対応したい場合は、どのプラットフォームを重視すべきですか?

NocoBase。 業務の中に複数テーブル間の関係、関連オブジェクト、役割ごとの違い、業務ごとの操作が多く含まれる場合、NocoBase はデータモデルを軸にシステムを継続的に構築していくのにより適しています。

  1. データソースが 1 つではなく、データベースと API が混在している場合、選定時に特に重視すべき点は何ですか?

そのプラットフォームが複数のデータソースを同時に扱えるか、データベースと API の両方を接続できるか、データソースが増えてもページやワークフローの保守が複雑になりすぎないか、さらに今後新しいデータソースを追加するときもスムーズに接続できるかを確認することが重要です。

  1. 今後、データベースにフィールドやテーブルを追加したり、リレーションが変わったりする可能性がある場合、何を基準にプラットフォームを選べばよいですか?

重要なのは、データ層とページ層がどれだけ強く結びついているかです。このようなケースでは、データモデル駆動型のプラットフォームのほうが一般的に適しています。たとえば NocoBase のような製品です。データ構造が変わっても、ページ、ワークフロー、権限を比較的柔軟に調整しやすくなります。

  1. まずは管理画面や内部ツールだけを作り、あとから承認、チケット管理、さらに多くのモジュールを追加していきたい場合は、どう選べばよいですか?

Retool は、既存のデータベースをもとに、まず管理画面やデータツール、内部アプリを素早く立ち上げたい場合に向いています。NocoBase は、その後もワークフロー、権限、各種モジュールを段階的に追加していきたい場合により適しています。もし最初の段階で、このプロジェクトが将来的により本格的な業務システムへ発展すると想定しているなら、NocoBase のように業務構造をしっかり支えられるプラットフォームを選ぶほうがよりおすすめです。

  1. 承認、依頼処理、チケット流転のような、ワークフロー中心のアプリケーションを作りたい場合は、どれを選ぶべきですか?

Budibase。 この種のアプリケーションでは、データベースはあくまで基盤となるデータソースです。実際の使いやすさを左右するのは、多くの場合、フォーム、ステータス遷移、ワークフロー自動化、権限設定に対するプラットフォームの対応力です。

  1. チームにすでに JavaScript の知見があり、開発者主導でページやロジックを制御したい場合は、どのようなプラットフォームが適していますか?

チームにフロントエンドや JavaScript の知見があり、開発者がページ、クエリ、操作ロジックを主導したいのであれば、AppsmithRetool のようなプラットフォームがより適しています。こうした製品は、既存のデータベースや API を活用しながら、開発者主導で内部ツール、運用コンソール、カスタムページを構築するのに向いています。

この記事で整理した公式サイト、ドキュメント、データソース関連のリンクを参考にしながら、各プラットフォームが現在のデータソースにどのように対応しているかを確認できます。そのうえで、自社の業務フロー、ページ要件、今後の拡張計画に合わせて、最適なプラットフォームを選ぶとよいでしょう。

関連読み物:

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?