2026.09.25 開発

NocoBaseとは：2.2系をDockerで立てる手順・API連携・ライセンスの注意点を解説

Q: NocoBaseの初期ログインのIDとパスワードは何ですか？

初期アカウントは admin@nocobase.com 、パスワードは admin123 です。公開された初期値なので、起動したらすぐに変更してください。インターネットから到達できるサーバーで初期パスワードのまま放置すると、誰でも管理者としてログインできる状態になります。

NocoBaseとは：2.2系をDockerで立てる手順・API連携・ライセンスの注意点を解説

NocoBaseは、データ構造を先に定義し、その上に画面と権限をノーコードで組み立てるオープンソースの業務システム開発基盤です。2026年9月24日時点の安定版は2.2.17で、2.3のベータ版と2.4のアルファ版が並行して開発されています。この記事では、Docker Composeでの起動から初期ログイン、コレクションを使った画面づくり、APIキーによる外部連携、プラグイン開発とアップグレードの運用までを設定例つきで整理しました。後半では、Apache 2.0に上乗せされた追加条項とエディション価格を読み解き、受託開発で使える範囲と採用を見送る場面を言い切ります。

まとめ：NocoBaseはデータモデルを先に決め、ライセンス条件で採否を判断する

NocoBaseで最初に決めるのは画面ではありません。コレクション（テーブル）と項目、そしてロールごとの権限です。画面はデータの上に載る「ブロック」として後から何枚でも作れるため、データ構造が固まっている業務ほど短期間で形になります。

運用面の前提は2つあります。環境変数APP_KEYを変えると発行済みのAPIキーがすべて無効になること。そして公式が「アップグレードのみ対応し、ダウングレードは不可」と明記していることです。本番ではイメージの版を数字で固定し、更新前にデータベースを必ず退避します。

採否を分けるのはライセンスです。Community版は無料で商用利用もできますが、ブランド表記の削除や、公衆向けのノーコードSaaSとしての提供は禁じられています。社内向けの業務システムに使うなら有力な選択肢、顧客へ配る製品の土台にするなら有償版の条件を先に確認する。これが2026年9月時点の結論です。

NocoBaseの定義と2.2系の版の位置、kintoneやRetoolとの違い

ノーコードツールは種類が多いため、NocoBaseがどの層を担う製品かを先に固定します。

GitHubで公開されるOSSのノーコード基盤と2.2.17時点のリリース系列

ソースはGitHubのnocobase/nocobaseリポジトリで公開されており、2026年9月24日時点のスター数は約2.4万です。GitHubのリリース記録では、安定版のv2.2.17が9月24日に公開されました。同じ日に2.3.0-beta.12と2.4.0-alpha.8も出ており、安定・ベータ・アルファの3系列を並行して更新する体制です。

パッチ版の間隔は短く、2.2系だけで9月19日に2.2.15、21日に2.2.16、24日に2.2.17と続きました。更新頻度が高いぶん、本番環境は自動で上がるタグを避けて版を固定する運用が前提になります。

データモデル駆動とプラグイン構成でUIとデータを分ける設計思想

NocoBaseの特徴は、データ構造と画面を切り離している点です。1つのコレクションに対して、表形式、カード、カンバン、フォームといった表示ブロックを必要な数だけ作れます。機能の大半はプラグインとして実装され、ページ、ブロック、アクション、API、データソースを後から追加する作りです。

kintoneのようなSaaS型との違いは、自社のサーバーに置いてデータベースまで自分で持つことです。Retoolのような社内ツール作成サービスとは、既存DBの上に画面を被せるだけでなく、NocoBase自身がデータ構造と権限の管理を担う点で異なります。ローコード製品の分類全体はローコードツールの用途別比較と選定基準で整理しているので、候補がまだ絞れていない段階ならそちらから読んでください。

Docker ComposeでNocoBaseを立ち上げ、初期ログインまで進める手順

インストール方法はDocker、create-nocobase-app、Gitソースの3通りです。ノーコード中心で使うならDockerが推奨されており、アップグレードもイメージの入れ替えで済みます。

PostgreSQL 16と組むdocker-compose.ymlの最小構成と環境変数

公式のDockerインストール手順では、データベースにPostgreSQL 16、MySQL 8、MariaDB 11の構成例が示されています。環境変数の並びを公式に合わせ、版を2.2.17に固定したPostgreSQL版の構成例です。

services:
  app:
    image: nocobase/nocobase:2.2.17
    restart: always
    depends_on:
      - postgres
    environment:
      - APP_KEY=change-me-to-random-string
      - DB_DIALECT=postgres
      - DB_HOST=postgres
      - DB_PORT=5432
      - DB_DATABASE=nocobase
      - DB_USER=nocobase
      - DB_PASSWORD=change-me
      - TZ=Asia/Tokyo
    volumes:
      - ./storage:/app/nocobase/storage
    ports:
      - "13000:80"

  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: nocobase
      POSTGRES_DB: nocobase
      POSTGRES_PASSWORD: change-me
    volumes:
      - ./storage/db/postgres:/var/lib/postgresql/data

起動はdocker compose pullでイメージを取得し、docker compose up -dで立ち上げ、docker compose logs -f appで初期化の完了を待つ流れです。ブラウザでhttp://localhost:13000を開き、初期アカウントの[email protected]とパスワードadmin123でログインします。初回ログインの直後にパスワードを変えてください。

本番では、ホスト側のNginxから127.0.0.1:13000へプロキシし、ドメインとHTTPSはホスト側で処理する構成が公式の推奨です。Docker Hubのタグには、画面用Nginxを含まない-no-nginx系や、追加ツールを含む-full系もあります。

APP_KEYとタイムゾーンを本番前に決めておく理由と変更時の影響

APP_KEYはトークンの署名などに使う秘密値で、APIキーの公式ドキュメントは「変更すると以前に追加したすべてのAPIキーが無効になる」と警告しています。外部システムとの連携が動き出した後に書き換えると、連携先がすべて認証エラーで止まります。検証環境と本番環境で別の値を持ち、本番の値は作成時に一度だけ決めて秘密情報の保管先へ入れておきましょう。

TZは公式例がEtc/UTCです。日付項目の表示と集計を日本時間で扱うならAsia/Tokyoに変えます。運用開始後に変えると既存データの解釈がずれるおそれがあるため、ここも最初に決める項目です。

コレクションを定義して画面を組み、APIキーでデータを外部から読む

起動できたら、データの定義、画面の配置、外部からの読み書きの順に進めます。

コレクションとブロックの関係、Excel台帳から移すときの項目設計

コレクションは業務データを入れる器で、項目の型、必須かどうか、他のコレクションとの関連を管理画面から定義します。画面はページの上にブロックを置き、どのコレクションを表示するかを指定して作る仕組みです。

Excelの台帳から移す案件では、シートをそのままコレクションにしないことが肝心です。1行に「顧客名・担当者名・案件名」が混在している台帳は、顧客と案件を別のコレクションに分け、関連項目でつなぎます。ここを分けておかないと、同じ顧客名の表記揺れがそのまま残り、後から集計できません。業務アプリをどの手段で作るかの判断は業務アプリの作り方3通りと内製・外注の判断基準で扱っています。

APIキーを発行してcurlでtodos:listを呼ぶ連携の手順と権限設計

外部から読むには、プラグイン管理で「Auth: API keys」を有効にし、連携用のロールを作って必要なコレクションだけに権限を与えます。そのうえで管理画面の/admin/settings/api-keysからキーを発行する流れです。APIは{baseURL}/{コレクション名}:{アクション}の形式で、一覧は:listをGET、作成と更新は:createと:updateをPOSTで呼びます。

# 一覧の取得（todos コレクション）
curl --location 'http://localhost:13000/api/todos:list' \
  --header 'Authorization: Bearer <APIキー>'

# レコードの作成
curl --location --request POST 'http://localhost:13000/api/todos:create' \
  --header 'Authorization: Bearer <APIキー>' \
  --header 'Content-Type: application/json' \
  --data '{"title": "請求書の発行"}'

# 主キー 1 のレコードを更新
curl --location --request POST 'http://localhost:13000/api/todos:update?filterByTk=1' \
  --header 'Authorization: Bearer <APIキー>' \
  --header 'Content-Type: application/json' \
  --data '{"title": "請求書の発行（済）"}'

注意すべきは、発行したキーが「現在のユーザーに属し、そのユーザーのロールを継承する」仕様です。管理者アカウントのままキーを作ると、連携先に全権限を渡すことになります。連携専用のユーザーとロールを用意し、そのユーザーでキーを発行してください。キーは発行時にしか表示されないため、その場で保管先へ移します。権限設計や野良アプリ化の防ぎ方はローコード開発のセキュリティリスクと対策も参考になります。

プラグイン開発とアップグレード運用で詰まりやすい箇所の潰し方

ノーコードの設定で届かない処理はプラグインで足します。同時に、更新の速い製品なので版の上げ方を最初に決めておきます。

yarn pm createで作るプラグインの雛形とtar形式での配布手順

公式のプラグイン開発ガイドは、create-nocobase-appかGitソースでインストールした環境を前提にしています。Dockerで動かしている本番とは別に、開発用の環境を用意するのが最初の作業です。

# 雛形の生成（packages/plugins/@my-project/plugin-hello に作られる）
yarn pm create @my-project/plugin-hello

# 開発モードで起動し、プラグインを有効化
yarn dev
yarn pm enable @my-project/plugin-hello

# 配布用にビルド（storage/tar/ に .tgz が出力される）
yarn build @my-project/plugin-hello --tar

生成される雛形はsrcの下にserverとclient、2系向けのclient-v2、localeを持ちます。サーバー側でAPIやデータ処理、クライアント側で画面の部品を実装する分担です。ビルドした.tgzは、別のNocoBaseアプリへ取り込んで使います。

画面の見た目を細かく作り込みたい要件が多い場合は、プラグインで無理に寄せるより、Reactの管理画面フレームワークで作るほうが素直なこともあります。比較対象としてRefineとreact-adminの違いと管理画面の作り方を挙げておきます。

ダウングレード不可の前提で組むバックアップとイメージ版の固定

Docker版のアップグレード手順は、docker-compose.ymlの版番号を書き換え、docker compose pull appとdocker compose up -d appで入れ替える方式です。同じページに「アップグレードのみ対応し、ダウングレードは不可」「データベースを必ずバックアップする」「本番では版番号を固定する」と書かれています。

# 1. 更新前にデータベースを退避（PostgreSQL の例）
docker compose exec -T postgres pg_dump -U nocobase nocobase > backup_2.2.17.sql

# 2. docker-compose.yml の image を次の版へ書き換えてから入れ替え
docker compose pull app
docker compose up -d app
docker compose logs -f app

戻せない更新なので、切り戻しは「古い版のイメージと更新前のダンプで作り直す」手段しかありません。ダンプの取得だけで満足せず、検証環境で実際に復元できるかまで確かめておきます。サードパーティのプラグインを入れている場合は、本体の更新後にそちらも上げる必要があり、プラグイン側が新しい版に追随していないと起動できないこともあります。プラグインを増やすほど、更新のたびの確認項目も増えると考えてください。

ライセンス条件とエディション価格から、受託開発で使える範囲を確認

ここが他の解説で抜けやすい論点です。NocoBaseは無料で使えますが、条件のないオープンソースではありません。

Apache 2.0に上乗せされた追加条項で禁じられている提供形態

リポジトリのLICENSE.txtは、Apache License 2.0を土台に独自の条項を加えています。オープンソース版で認められるのは商用目的での利用です。一方で、次の行為は禁じられています。

NocoBaseのブランド、名称、リンク、版番号、ライセンスなどの情報を削除・変更すること
コード内にあるNocoBaseの知的財産表示を削除・変更すること
ノーコード、ゼロコード、ローコード、AIプラットフォームのSaaS・PaaS製品を、形態を問わず公衆へ提供すること

自社の社内システムをNocoBaseで作って運用するのは、この範囲で問題ありません。判断が要るのは受託開発です。顧客の社内システムとして納品する場合でも、画面上のNocoBase表記を消したい要望が出たら有償版の話になります。NocoBaseの上に作ったものを誰でも使えるノーコード基盤として売る構想は、Community版では成り立ちません。

Community・Standard・Professionalの価格と機能差の読み方

公式の価格ページに掲載された2026年9月時点のエディションを整理します。

エディション	価格	主な追加機能
Community	無料	ユーザー数・アプリ数・件数は無制限
Standard	800ドル（一度払い）	ロゴの差し替え・外部DB接続
Professional	8,000ドル（一度払い）	顧客向けアプリ・SSO・承認
Enterprise	要問い合わせ	クラスタ構成・監査ログ

StandardとProfessionalはどちらも一度払いの永続ライセンスで、Standardは1年間のアップグレード期間つきと案内されています。受託開発で効いてくるのはProfessionalで、顧客向けアプリの開発、版管理、開発・テスト・本番の環境分離、全レコードの編集履歴がここから入ります。承認フローやSSOを要件に含む案件は、最初からProfessionalの費用を見積りに載せておくのが安全です。ライセンスの価格は将来変わりうるため、契約前に価格ページを取り直してください。

NocoBaseを採用してよい案件と、スクラッチやSaaSで作るべき場面

ここは判断を言い切ります。NocoBaseは「何でも速く作れる」道具ではありません。

社内向け業務システムでデータ構造が固まっている案件は採用する

採用を勧めるのは、利用者が社内に閉じていて、扱うデータの構造が業務として決まっている案件です。案件管理、備品管理、問い合わせ台帳、契約の更新管理のように、コレクションが5〜20個程度に収まり、画面が一覧・詳細・入力フォーム中心で済むものが該当します。

データを社外のSaaSに置けない事情がある組織にも合います。自社サーバーやクラウドの自社アカウントにDockerで立て、データベースまで自分で持てるのは、kintoneのようなSaaS型にはない利点です。ノーコード製品の選び分けはノーコードツールの用途別比較で横並びに確認できます。

顧客向けに配る製品や大量トランザクション系で採用見送りが妥当な条件

見送るべき場面は3つです。第一に、自社サービスとして不特定の顧客へ提供する製品の土台にする場合。ライセンスの追加条項に触れやすく、有償版を前提にしても画面の作り込みの自由度で行き詰まります。第二に、1日に数十万件の注文や決済を処理するような、性能と整合性の設計が中心になるシステム。第三に、データ構造がまだ決まっておらず、業務の流れを作りながら探る段階の案件です。構造が決まらないまま画面を量産すると、コレクションの作り直しのたびに全画面を直すことになります。

画面を独自に作り込みたいがデータ管理は既存の仕組みに任せたい、という要件なら、ヘッドレスCMS系のDirectusの特徴と機能や、PHPで管理画面を短工数で作るLaravel Filamentの構成と選択基準のほうが合う場合もあります。

社内で業務システムの立ち上げと保守を回しきれないときの外部相談の目安

Dockerでの起動自体は数分で終わります。手間がかかるのはその後で、コレクションの設計、ロールと権限の割り当て、APIキーを使った既存システムとの連携、版の更新とバックアップの運用が継続して必要です。ノーコードとローコードの範囲の違いを押さえておくならノーコードとは何かとローコードとの違いが前提の整理になります。

データ設計から任せたい、既存の基幹システムとつなぐ部分だけプラグインで作りたい、といった場合は、一創のノーコード・ローコードアプリ開発で、製品の選定から設計、運用手順の引き継ぎまでを一緒に進められます。

よくある質問

NocoBaseの導入検討でよく挙がる質問に、2.2系の仕様を前提に答えます。

NocoBaseは無料で商用利用できますか？

できます。Community版は無料で、ライセンスでも商用目的での利用が認められています。ユーザー数やアプリ数、レコード件数の上限もありません。ただし、画面やコード内のNocoBaseの表記を消すことや、公衆向けのノーコード・ローコードSaaSとして提供することは禁止です。表記を差し替えたい場合はStandard以上の有償版が必要になります。

NocoBaseで使えるデータベースは何ですか？

公式のDocker手順では、PostgreSQL 16、MySQL 8、MariaDB 11の構成例が示されています。新規に立てるなら、構成例が最初に挙がっているPostgreSQLを選べば困りません。既存の業務データベースを外部データソースとしてつなぐ機能は有償版の範囲で、OracleやClickHouseなどへの接続はEnterprise版の機能として案内されています。

NocoBaseの初期ログインのIDとパスワードは何ですか？

初期アカウントは[email protected]、パスワードはadmin123です。公開された初期値なので、起動したらすぐに変更してください。インターネットから到達できるサーバーで初期パスワードのまま放置すると、誰でも管理者としてログインできる状態になります。

NocoBaseのアップグレードで失敗したら元の版に戻せますか？

公式は「ダウングレードは不可」と明記しています。戻す手段は、更新前に取ったデータベースのダンプと、古い版のイメージで環境を作り直すことだけです。更新前のバックアップと、そのバックアップから復元できることの確認を、毎回の手順に組み込んでください。本番のイメージはlatestではなく版番号で固定します。

NocoBaseとkintoneはどちらを選ぶべきですか？

サーバーを自分で持てるかで決まります。サーバーの構築や更新、バックアップを担う人がいて、データを自社の管理下に置きたいならNocoBase。運用をすべてサービス側に任せたい、プラグインや連携の事例が国内に多い製品を使いたいならkintoneです。前者は利用人数が増えてもライセンス費用が増えにくく、後者は利用人数に比例して月額が増えます。