Appsmithとは？OSSの社内アプリビルダーをDockerで建てる手順とRetoolとの選び分け

Appsmithは、社内のデータベースやAPIにつないだ管理画面を、ウィジェットの配置とSQL・JavaScriptで組み立てるオープンソースの開発基盤です。この記事では2026年10月時点の公式情報をもとに、画面が組み上がる仕組み、ワークスペース単位で人数を数える料金体系、Docker Composeで版を固定して自社サーバに建てる手順を順に追います。暗号化パスワードとバックアップ、prepared statementが外れるSQLの書き方まで具体的に示し、Retool・ToolJet・コードで作る管理画面との選び分けを言い切ります。

まとめ：Appsmithは自社サーバで動かせるApache-2.0の社内アプリビルダー

Appsmithで作るものの中心は、社員が使う一覧・検索・編集・承認の画面です。PostgreSQLやREST APIを「データソース」として登録し、SQLやAPI呼び出しを「クエリ」として書き、表やフォームの「ウィジェット」に結果を流し込みます。

Retoolとの最大の違いは配布の形です。AppsmithはApache-2.0で公開されており、Community版を自社サーバで動かす限り、ライセンス費用も利用者数による課金も発生しません。カスタムロールや監査ログ、SAMLによるSSOが要る段階で、初めて有償プランの見積もりが必要になります。

採用してよいのは、利用者が社内に限られ、Dockerのサーバを自分たちで保守できるときです。社外の顧客に公開する画面や、業務ロジックが画面側に大きく膨らむシステムは、コードで作る構成を選びます。

Appsmithの定義とデータソース・クエリ・ウィジェットで社内画面を組む仕組み

Appsmithの画面は、接続先・データの取り方・見せ方の3層を別々に定義し、二重波括弧の式で結ぶ作りです。この配線を押さえると、手で書くべき箇所がSQLと短いJavaScriptだけだと分かります。

データソースを登録しクエリの結果をウィジェットの表へ流す画面の作り方

最初に登録するのはデータソースです。PostgreSQL・MySQL・MongoDB・REST API・GraphQLなどの接続先を、接続情報ごとワークスペースに登録します。セルフホスト版では、この接続情報が後述の暗号化パスワードで暗号化されてAppsmith側に保存されます。

次に、データソースに対するクエリを書きます。公式のクエリオブジェクトの解説によれば、クエリのdataプロパティには直前に成功した実行の応答が入り、表ウィジェットのデータに{{ getOrders.data }}と書くと、ページを開いたときにクエリが自動で走ります。

ウィジェット側は、表・フォーム・セレクト・ボタン・モーダルといった部品をドラッグで置くだけです。表で選んだ行はTable1.selectedRowで参照でき、フォームの初期値にそのまま渡せます。

JSオブジェクトとrun()で更新クエリを順番に実行するコード例

ボタン1つで「更新してから一覧を取り直す」といった順序のある処理は、JSオブジェクトに書きます。JSオブジェクトはexport defaultで1つのオブジェクトを書き出す形式で、その中の関数の呼び出し元はボタンのonClickです。クエリのrun()は引数のオブジェクトを受け取ってPromiseを返すため、awaitで順番を保証できます。

// JSオブジェクト「OrderActions」：選んだ受注を承認して一覧を取り直す
export default {
  async approve() {
    await updateStatus.run({ id: Table1.selectedRow.id, status: "approved" });
    await getOrders.run();
    showAlert("承認しました", "success");
  }
}

-- クエリ「updateStatus」：run() に渡した値は this.params で受け取る
UPDATE orders
SET status = {{ this.params.status }}, updated_at = now()
WHERE id = {{ this.params.id }};

公式は、run()をウィジェットのデータプロパティの中では呼べず、onClickなどのイベントから呼ぶよう定めています。表のデータ欄に更新クエリのrun()を書いて動かない、という詰まり方はこの制約が原因です。

コードを書く範囲がSQLと短いJavaScriptに収まるため、Appsmithはノーコードではなくローコードの側に入る製品です。両者の線引きと向き不向きはノーコードとローコードの違いと限界で整理しています。

Appsmithの料金体系とCommunity版・商用版のイメージで変わる機能差

Appsmithの費用は、どのイメージを動かし、どのプランで何人をワークスペースに入れるかで決まります。無料で始められる範囲が広い分、有償機能の線引きを先に確かめておきます。

Free・Business・Enterpriseの単価とワークスペース単位の人数の数え方

公式の料金ページを2026年10月29日に確認した内容を並べます。

課金の単位になるユーザーは、料金ページのFAQで「インスタンスのワークスペースに追加されたメンバー」と定義されています。Retoolのように作る人と使う人で単価を分けないため、利用者40人の部署でBusinessを選ぶと月600ドルです。100人を超える組織はEnterpriseの月額2,500ドルからの見積もりになり、エアギャップ版はEnterpriseのアドオンです。

ライセンス費に加えて、サーバ代と保守の人件費まで含めた総額の比べ方はローコード開発の費用相場とスクラッチの5年総額比較で扱っています。

Community版appsmith-ceと商用版appsmith-eeの選択基準

セルフホストのDockerイメージは2種類あります。公式のDocker導入手順は、無料プランを持ち有償プランへ切り替えられる商用版appsmith-eeを推奨し、Community版はイメージ名をappsmith-ceに替えて使うよう案内しています。

判断はシンプルです。将来カスタムロールや監査ログを買う可能性があるなら、最初からappsmith-eeで建てます。Apache-2.0の範囲だけで使い続けると決めているならappsmith-ceを選びます。GitHubのappsmithorg/appsmithはApache-2.0の表記で公開されており、ソースを読んで挙動を確かめられる点は、ソースが非公開のRetoolには無い利点です。

セルフホスト版AppsmithのDocker Compose導入手順と8GBのメモリ要件

社内ネットワークの中でAppsmithを動かすなら、公式のDocker Compose構成を使います。ここでは検証環境を1台に建て、本番に出せる状態まで設定を詰める作業を追います。

docker-compose.ymlで版を固定し新規登録を止めるまでの初期設定

公式手順の前提は、Docker 20.10.7以降とDocker Compose 1.29.2以降です。既定の構成はMongoDB・Redis・PostgreSQLを1つのコンテナに同梱するため、ホストに8GB以上のメモリを求めます。Retoolのセルフホスト版が64GiB以上を求めるのと比べると、小さな仮想マシン1台で検証を始められます。

# docker-compose.yml（latest ではなくリリースタグで固定する）
version: "3"
services:
  appsmith:
    image: index.docker.io/appsmith/appsmith-ce:v2.6.0
    container_name: appsmith
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./stacks:/appsmith-stacks
    restart: unless-stopped

# 起動する（初回は立ち上がるまで最大5分ほどかかる）
docker-compose up -d

# 最初の管理者を作ったあと、stacks/configuration/docker.env に追記する
APPSMITH_SIGNUP_DISABLED=true
APPSMITH_DISABLE_TELEMETRY=true

# 設定を反映する
docker-compose restart

公式はイメージをリリースタグで固定するよう求めており、タグを省いたlatestは本番に勧めていません。公式の環境変数の一覧では、APPSMITH_SIGNUP_DISABLEDをtrueにすると新しいアカウントの作成を止められ、テレメトリは既定で有効なためAPPSMITH_DISABLE_TELEMETRYで止めます。社内の誰もが自由に登録できる状態のまま公開しないことが、最初の守りです。

閉じたネットワークに置く場合も、cs.appsmith.comへの外向き通信は許可が必要です。ファイアウォールの申請に入れておきます。

暗号化パスワードとappsmithctlのバックアップで復旧できる状態を保つ運用

stacks/configuration/docker.envにあるAPPSMITH_ENCRYPTION_PASSWORDとAPPSMITH_ENCRYPTION_SALTは、データソースの接続情報を暗号化する値です。サーバを作り直すときにこの2つが手元に無いと、登録済みの接続情報を使えません。docker.envはstacksと同じ場所に置くだけでなく、パスワード管理の仕組みへ別に控えます。

# コンテナ内で appsmithctl を実行し、パスワード付きのバックアップを作る
docker exec -it appsmith appsmithctl backup

# ホスト側の保存先を確かめ、別のストレージへ退避する
ls ./stacks/data/backup/

公式のappsmithctlの解説によると、対話で実行したバックアップは入力したパスワードで暗号化され、コンテナ内の/appsmith-stacks/data/backup/、ホストでは./stacks/data/backup/に置かれます。パスワードを忘れると復元できません。版を上げる前には必ずこのバックアップを取り、復元はappsmithctl restoreで行います。

ほぼ毎週出るリリースとv2.6.0のワークフロー基盤移行に合わせた更新計画

Appsmithのリリースは間隔が短く、GitHubのリリース一覧では次のように出ています。

5週で5版が出ています。追いかけ続けるより、月に1回など更新日を決めてタグを書き換え、検証環境で動作を見てから本番に適用する運用が現実的です。

2.6系への移行には注意点があります。v2.6.0のリリースノートは、ワークフローの実行基盤が新しいエンジンに替わるため、商用版の利用者はまずv2.5.1へ上げ、承認待ちを含む既存のワークフロー実行をすべて終えてから2.6系に進むよう求めています。ワークフローを使っている環境では、v2.5.1を経由する2段階の更新として計画してください。

DB直結の社内アプリで情報漏えいを防ぐAppsmithの権限設計とクエリの守り

Appsmithは本番データベースへ直接つながるため、クエリの書き方と権限の切り方を誤ると、画面を開けた社員に全件の参照や更新を許すことになります。守りはSQL・データベース・ワークスペースの3段で組みます。

Use Prepared Statementが外れる動的SQLの書き方とIN句の置き換え

公式のprepared statementの解説によると、PostgreSQL・MySQL・SQL Server・Oracleのクエリには「Use Prepared Statement」の設定があり、二重波括弧の値はパラメータとしてデータベースに渡ります。これがSQLインジェクションへの防御です。

問題は、この設定が使えない書き方がある点です。テーブル名や列名を式で切り替える、WHERE句やJOINを丸ごと式で組み立てる、配列をIN句に流し込む、といったクエリは事前にコンパイルできないため、設定を外すしかなくなります。外した瞬間に入力値が文字列としてSQLへ連結されるので、本番の更新系クエリでは外さない書き方に寄せます。

-- 動かない：配列を IN 句へ流し込むと prepared statement にできない
SELECT id, status FROM orders
WHERE status IN ({{ StatusSelect.selectedOptionValues }});

-- PostgreSQL では = ANY に書き換えれば設定を有効のまま使える
SELECT id, status FROM orders
WHERE status = ANY({{ StatusSelect.selectedOptionValues }});

MySQLにはこの書き換えが無く、公式は設定の無効化を案内しています。MySQLで複数選択の絞り込みが要る画面は、選択肢ごとにクエリを分けるか、データベース側のビューに寄せます。コメントアウトした行の中の二重波括弧もパラメータとして扱われるため、使わない式は行ごと消してください。

接続用DBユーザーの最小権限とワークスペースの既定ロール3種の割り当て

データソースに管理者ユーザーを登録すると、クエリを1本誤っただけで全テーブルに手が届きます。画面の用途ごとに専用のユーザーを作り、更新できる列まで絞ります。

-- Appsmith の受注管理データソース専用のユーザー（PostgreSQL）
CREATE ROLE appsmith_orders LOGIN PASSWORD 'change-me';
GRANT USAGE ON SCHEMA public TO appsmith_orders;
GRANT SELECT ON orders, customers TO appsmith_orders;
GRANT UPDATE (status, updated_at) ON orders TO appsmith_orders;

列単位のUPDATEはPostgreSQLのGRANTの仕様どおり列名を括弧で並べて付与します。「自分の部署の行だけ見せる」まで求めるなら、条件をクエリに書くだけでは書き忘れで全件が返るため、データベースの行レベルセキュリティの設定例のようにデータベース側で外枠を固めます。

Appsmith側では、公式のロールの解説にある既定のワークスペースロールを使い分けます。データソースを作り変えられるAdministratorとDeveloperは作る人だけに付け、使う社員はApp Viewerにして読み取り専用でアプリを開かせます。料金ページではFreeプランで使えるのはこの既定ロール3種までとされ、部署ごとに細かく権限を切るカスタムロールと監査ログはBusiness以上です。野良アプリの棚卸しを含めた全体の対策はローコード開発のセキュリティリスクと権限設計にまとめています。

Appsmithの採用条件とRetool・ToolJet・コード製管理画面との選択基準

採否は機能の多さでは決まりません。誰が使い、サーバを誰が保守し、どの有償機能が必須かで判断します。

自社サーバで利用者課金なく社内CRUD画面を回すならAppsmithを採る基準

Appsmithを選んでよいのは、次の条件がそろうときです。利用者が社内の社員で、画面の中心が一覧・検索・編集・承認であること。Dockerのサーバを月1回更新し、バックアップを取る担当を置けること。そして、カスタムロールやSAMLのSSOが当面は必須でないことです。この3つを満たせば、利用者が200人に増えてもライセンス費は0円のままです。

典型的なのは、営業事務が受注の状態を更新する画面や、倉庫の担当者が在庫の引当を解除する画面です。Retoolで同じ画面を作った場合の費用構造と権限設計はRetoolの構成とDB直結の権限設計で扱っており、並べて読むと差がはっきりします。既存システムとの接続やサーバの運用まで含めた構成の相談は、ノーコード・ローコードアプリ開発で受け付けています。

有償機能の多用や社外公開で採用を見送る場面と代替手段の比較表

反対に、次の場面ではAppsmithを見送ります。SAMLのSSOと監査ログが初日から必須で、結局Enterpriseの見積もりになる場合。サーバの更新とバックアップを担う人がいない場合。顧客や会員が使う公開サイトの画面を作る場合です。JSオブジェクトのコードが数千行に膨らみ始めたら、画面ビルダーで抱える範囲を超えた合図と捉えてください。

OSS同士の比較では、ライセンスの違いが効きます。Appsmithは改変の公開義務が無いApache-2.0、ToolJetはネットワーク越しの利用にも改変ソースの公開義務がかかるAGPL-3.0です。手を入れて社内で使う前提なら、Apache-2.0のほうが法務で確認する負担は軽いという判断です。既存のコードベースに管理画面を足すなら、React-adminで管理画面を作る方法やLaravel Filamentの構成とNovaとの選択基準のように、同じリポジトリで型とテストを共有できる構成が保守で勝ります。製品ごとの用途の違いはローコードツールの比較と選定基準で整理しています。

よくある質問

Appsmithの検討段階でよく出る疑問に、公式の料金ページとドキュメントの記述をもとに答えます。

Appsmithは無料で使えますか？

使えます。自社サーバでCommunity版を動かす場合、Apache-2.0のライセンスでライセンス費用も利用者数による課金もかかりません。クラウド版はFreeプランで5ユーザーまで無料です。負担になるのはサーバ代と更新・バックアップの保守の手間で、カスタムロールや監査ログが要る段階からBusinessの1ユーザー月15ドルが発生します。

Appsmithのセルフホストにはどの程度のサーバが必要ですか？

公式のDocker手順では、MongoDB・Redis・PostgreSQLを同梱した既定の構成でホストに8GB以上のメモリを求めています。Docker 20.10.7以降とDocker Compose 1.29.2以降が前提です。通信の設定では、80番と443番の公開に加え、cs.appsmith.comへの外向き通信の許可も必要です。データベースを外部に分ければ、Appsmithのコンテナ側のメモリは抑えられます。

Appsmithを使うとデータはどこに保存されますか？

画面で扱う業務データは、接続した自社のデータベースに残ります。Appsmithのコンテナ内に保存されるのは、アプリの定義やユーザー、データソースの接続情報です。接続情報はAPPSMITH_ENCRYPTION_PASSWORDとAPPSMITH_ENCRYPTION_SALTで暗号化されるため、この2つの値とappsmithctlのバックアップをセットで保管してください。

Appsmithで作ったアプリを社外の人に使わせられますか？

料金ページのFreeプランにも公開アプリの項目があり、仕組みのうえでは可能です。ただしワークスペースに追加したメンバーは有償プランで課金の対象になり、AppsmithのUIは社内ツール向けの作りです。取引先の担当者数名に限るなら選択肢に入りますが、不特定多数の顧客が使う画面はスクラッチ開発を選びます。

AppsmithとRetoolはどちらを選べばよいですか？

判断の軸は、サーバを自分たちで持つか、運用ごと任せるかです。自社サーバでライセンス費用をかけずに動かし、ソースを読める状態を保ちたいならAppsmith、AI機能や監査ログを含めてクラウドに任せたいならRetoolです。Retoolのセルフホスト版はEnterprise限定で、64GiB以上のメモリを求める点も比較の材料になります。

関連記事

• Retoolとは？社内管理画面を短期間で作る構成とDB直結の権限設計、内製の限界：Appsmithの主な比較先となる商用製品。
• ノーコードツール比較｜業務アプリ・Web・EC用途別の代表製品と選び方：業務アプリ用途での比較先。
• Refine（React）とは？react-adminとの違い・v5の使い方と管理画面の作り方：コードで作る管理画面の別の選択肢。
• Power Platformとは？5つのサービス・できること・料金と内製の判断まで解説：Microsoft 365環境で社内アプリを作る場合の比較先。
• ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：権限の棚卸しと野良アプリ対策。