これからNocoBaseを始める人のための基本ガイド — 何ができて、どういう考え方のツールなのか
はじめに
こんにちは、杉浦です。かなり久しぶりに DevelopersIO に記事を書きます。
2026年5月から、業務で NocoBase というオープンソースのノーコード／ローコード開発プラットフォームを運用するチームに参加しました。触り始めてからおよそ2ヶ月になります。
始めるにあたって日本語の情報を探したところ、NocoBase についてまとまった日本語記事はまだ少なく、公式の英語ドキュメントを読みながら手探りでキャッチアップすることになりました。そこで「自分が始めるときに欲しかった記事」を、シリーズとして書いていくことにしました。
- 第1回（本記事）: NocoBase の基本 — 何ができて、どういう考え方のツールなのか
- 第2回: NocoBase 2.x は何が新しいのか — バージョンの歩みと主要機能
- 第3回以降: ローカル起動、API、公式チュートリアル、AI機能などのハンズオン
この記事を読み終わったときに「NocoBase が自分（自社）の選択肢になるか」をざっくり判断できる状態になることをゴールにします。なお、私は 2.x 系から NocoBase に入っており、1.x 系の経験はありません。本シリーズの記述は 2.x を前提とします。
NocoBase とは
NocoBase は、オープンソースのノーコード開発プラットフォームです（公式サイトには日本語ページもあります）。ソースコードは OSS として GitHub で公開されています。開発元は「企業向け業務システムをすばやく構築するためのオープンソース AI + ノーコード開発プラットフォーム」（日本語READMEより）と説明しています。2026 年現在は「AI と人が協働して業務システムを作る」という点を前面に打ち出しています。
私が最初に押さえたのは、次の3点でした。
1. セルフホスト前提。 ノーコードツールと聞くと Airtable や kintone のような SaaS を連想するかもしれませんが、NocoBase は自前のインフラ（クラウドでもオンプレでも）に自分でデプロイして使います。データを自社の管理下に置けるのが最大の特徴で、その代わり DB やバックアップなどの運用は自分で面倒を見ることになります。
2. プラグインアーキテクチャ。 公式が「マイクロカーネル設計」と呼ぶ構成で、コアは小さく保ち、すべての機能がプラグインとして提供されます。標準機能もプラグインですし、足りない機能は共通ルールに沿った自作プラグインで拡張できます。GUI で作り切れない部分をコードで補える余地が最初から設計されている点は、エンジニアにとっての安心材料です。
3. OSS と商用の併存。 無料の OSS 版（Community Edition）に加えて、有償エディション（Standard / Professional / Enterprise）が併存するモデルです。コアのライセンスは、2026年2月の 2.0 正式リリースにあわせて AGPL-3.0 から Apache-2.0 に変更されました（公式アナウンス）。商用利用やカスタマイズがしやすいライセンスになったのは、これから始める人には追い風です。無料でどこまでできて、どこから有償なのかは、始める前に押さえておきたいポイントなので、後半で改めて触れます。
- 競合との比較は公式ブログの vs Airtable、vs NocoDB（いずれも日本語）が参考になります（公式視点なのは割り引いて読んでください）
NocoBase の基本概念 — データモデルと UI の分離
NocoBase を理解する上でいちばん大事なのは、「データモデル」と「UI」が分離しているという思想です。公式ドキュメントの How NocoBase Works（日本語版）で説明されている考え方を、実際に使うときの言葉に置き換えて整理します。
Excel やスプレッドシート型のツールでは「表」がデータでもあり画面でもあります。一方 NocoBase では、まずデータの構造を定義し、それをどう見せるかを別に組み立てます。流れとしては「コレクション → ブロック → アクション」の3段階です。
コレクション — データの構造を定義する
コレクションは、いわゆるテーブルです。コレクションにフィールド（文字列・数値・日付・選択肢など）を定義し、コレクション同士をリレーション（1対多、多対多など）でつなぎます。RDB のテーブル設計に近い感覚で、業務データの構造をそのまま表現できます。
また、NocoBase 自身が管理する DB だけでなく、既存の外部データベース（MySQL / PostgreSQL 等）をデータソースとして接続する機能もあります（こちらは有償エディション、Standard Edition 以上の機能です）。
コレクションを定義すると、そのデータを読み書きする REST API も自動的に使えるようになります。画面も API も同じデータモデルから作られるので、外部システムやスクリプトからも同じデータを扱えます（API はシリーズの後の回で詳しく扱います）。
ブロック — データの見せ方を組み立てる
ブロックは、ページに配置する UI 部品です。テーブル（一覧）、フォーム、詳細、カレンダー、チャートなど、同じコレクションのデータをさまざまな形で表示できます。
特徴的なのは、管理画面と利用画面が分かれておらず、実際に使う画面そのものを編集モードに切り替えて、その場でブロックを配置していく WYSIWYG 方式であることです。「設定画面で作って、プレビューで確認して…」という往復がなく、画面を見たまま組み立てられます。
アクション — 操作を付ける
ブロックにはアクション（追加・編集・削除・エクスポートなどの操作ボタン）を付けます。どのアクションを誰に見せるかも設定でき、「閲覧だけの一覧」「登録専用フォーム」のような画面が GUI だけで作れます。
権限・ワークフロー・プラグイン
この基本構造の周りに、業務システムに必要な機能が揃っています。
- 権限（ロール）: ロールベースのアクセス制御で、コレクション単位・フィールド単位・アクション単位で「誰が何をできるか」を細かく設定できます
- ワークフロー: 「レコードが追加されたら」「毎日この時刻に」といったトリガーで処理を自動化できます。条件分岐やデータ操作をノードとしてつなげていく方式です
- プラグイン: ここまで挙げた機能もすべてプラグインとして提供されており、管理画面から有効化・無効化できます
NocoBase は「テーブルを作る → 画面に配置する → 操作と権限を付ける → 自動化を足す」という積み上げ方で業務システムを組み立てるツールです。この考え方さえ頭に入れておけば、公式ドキュメントのどこを読めばいいかの見当も付きやすくなります。
どう使い始めるか
セルフホスト型なので、まず動かす環境を用意します。公式が案内している方法は3つです。
| 方法 | 向いている人 |
|---|---|
| Docker Compose | まず試したい人・本番運用（最短） |
| create-nocobase-app | Node.js プロジェクトとして扱い、プラグイン開発も視野に入れる人 |
| Git ソース | ソースコードから動かしたい人・コントリビュート目的 |
必要なものは、コンテナ実行環境（Docker など）とデータベース（PostgreSQL など）くらいです。ローカルの検証であれば、Docker Compose で DB ごと立ち上げてしまうのが手軽です。
本記事では手順には踏み込みません。シリーズ第3回で、実際に Docker Compose でローカル起動するところをやる予定です。
どんな用途に向いているか
2ヶ月使ってみた感触も踏まえて、NocoBase が向いているもの・不向きなものを考えてみました。
向いていると感じるもの:
- 社内業務システム: マスタ管理、台帳、申請と承認、ダッシュボードといった「社内の定番業務アプリ」はまさに得意分野です。コレクション＋ブロック＋権限の組み合わせで構築できます。
- データを自社管理下に置きたいケース: SaaS に載せにくいデータを扱う業務に向きます。セルフホストなので、データを外に出さずに活用できます。
- 既存の SaaS がはまらない特殊な業務があるケース: カスタマイズ性はかなり高いと感じます。プラグインを自作して拡張することもできるので、パッケージの枠に収まらない業務でも作り込みで対応できる余地があります。
慎重に検討したほうがよいもの:
- 運用リソースを確保できない場合: セルフホストの宿命として、インフラ・バックアップ・アップグレードの手間は継続的にかかります。「作って終わり」にはならないので、運用保守を続けられる体制かどうかが判断点です。
- 要件が特殊・大規模な場合: ノーコード基盤の共通論として、標準機能の枠を大きく外れるものはプラグイン開発量が増えていきます。拡張性の高さは良い面でもありますが、その開発コストは予想以上に大きくなることもあります。
kintone や Airtable と比べると、「SaaS として買うか、OSS を自分で運用するか」がいちばん大きな分かれ目です。ユーザー数課金の SaaS に対して、NocoBase は無料の Community Edition でもユーザー数やレコード数に制限がありません（公式の料金ページに明記）。一方で運用の人件費・インフラ費はかかります。どちらが安いかは規模と体制次第なので、「無料だから NocoBase」と飛びつくのではなく、総コストで比較するのがよいと思います。
始める前に知っておきたいこと（基本編）
導入を判断する前に知っておくと、後でつまずきにくくなります。
1. セルフホストの覚悟を持つ。 繰り返しになりますが、DB の運用、バックアップ、アップグレードはすべて自分たちの責任範囲です。マネージド SaaS の感覚で始めると、ここで最初のギャップを感じるはずです。裏を返せば、データを自分たちの管理下に置けることと、カスタマイズの自由度の高さが、セルフホストの良いところです。
2. OSS と商用の線引きを最初に確認する。 エディションは無料の Community に加えて Standard / Professional / Enterprise の有償3層があり、機能によって必要なエディションが異なります。たとえば外部データベース接続は Standard 以上、承認ワークフローは Professional 以上です（2026年7月時点）。ほかにも SSO・監査ログ・クラスタ構成などが有償側にあります。「作りたいものに必要な機能がどの区分か」を先に確認しておくと、あとから「この機能は有償だった」と設計をやり直さずに済みます。
3. 日本語情報はまだ少ない。 公式ドキュメントには日本語版が用意されていますが、翻訳にムラを感じる場面もあるため、細かい挙動を確認するときは英語版と実機での確認をおすすめします。コミュニティは、Forum で最も活発なのが中国語カテゴリ（トピック数は英語カテゴリの倍以上）、それに英語カテゴリが続き、日本語カテゴリもありますがトピックはまだわずかです。GitHub Issues でのやりとりは英語が中心です。私には中国語の敷居は少し高いので、英語カテゴリと GitHub Issues を追いかけています。
なお、「1.x と 2.x の情報の見分け方」「速いリリースサイクルとの付き合い方」といったバージョンまわりの事情は、次回・第2回のテーマとして詳しく書きます。
まとめ
NocoBase を判断する軸は、この3点に集約されると思います。
- データモデルと UI の分離: コレクション → ブロック → アクションの積み上げで業務システムを組み立てる思想
- プラグインアーキテクチャ: マイクロカーネル設計で標準機能もプラグイン。コードで拡張できる余地が最初からある
- セルフホスト: データ主権と引き換えに、運用責任を持つ
次回は「NocoBase 2.x は何が新しいのか」として、バージョンの歩み、AI 機能をはじめとする 2.x の主要トピック、1.x 情報との付き合い方を整理します。
フィードバックやリクエストがあれば、ぜひコメントで教えてください。
