---
title: "FusionAuthとは？Docker Composeでの起動手順とテナント設計・料金・Keycloakとの選び分け【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/18601/"
published: 2026-10-20
updated: 2026-10-20
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# FusionAuthとは？Docker Composeでの起動手順とテナント設計・料金・Keycloakとの選び分け【2026年10月】

FusionAuthは、ログイン画面・ユーザー管理・トークン発行をまとめて受け持つ認証基盤で、自社のサーバーへのセルフホストと、FusionAuth社のクラウドでの稼働の両方に対応する製品です。この記事では、公式のdocker-compose.ymlで手元に立ち上げる手順、Kickstartで初期設定をコード化する方法、ユーザー登録APIのリクエスト例をコマンド付きで示します。そのうえで、顧客企業ごとに会員を分けるテナント設計、無料のCommunityと有料プランの機能差を整理し、Keycloakとどちらを選ぶかを条件付きで言い切ります。

## まとめ：FusionAuthを採用する条件とKeycloakを選ぶ場面の結論

会員基盤をAPIから操作したい、テナントで顧客企業ごとに会員を分けたい、しかも運用担当は1〜2人という案件なら、FusionAuthは有力な選択肢です。Community版は無料でユーザー数の上限がなく、Docker Composeなら数分で管理画面まで開けます。2026年10月時点の最新版は1.69系（1.69.4・10月14日公開）です。

一方で、OSSライセンスであることが調達条件になっている案件、社内LDAPと連携した認証が必須の案件は、Keycloakを先に検討してください。FusionAuthはOSSではなく、LDAPコネクタは有料、SCIMはEnterpriseプランの機能です。

## FusionAuthの仕組み：アプリ本体とPostgreSQL・検索エンジンの3部品構成

FusionAuthを動かすのに必要な部品は、FusionAuthのアプリ本体、ユーザーや設定を保存するデータベース、ユーザー検索用の検索エンジンの3つです。

### アプリ本体・PostgreSQL・OpenSearchの役割分担とメモリ512Mの既定値

[公式のDockerインストール手順](https://fusionauth.io/docs/get-started/download-and-install/docker)で配られる構成は、`fusionauth/fusionauth-app:1.69.4`、`postgres:16.0-bookworm`、`opensearchproject/opensearch:2.11.0`の3コンテナです。管理画面もログイン画面もAPIも、アプリ本体の9011番ポート1つで提供されます。

| コンテナ                      | 役割              | 既定の公開ポート | メモリの既定値    |
| ------------------------- | --------------- | -------- | ---------- |
| fusionauth                | 管理画面・ログイン画面・API | 9011     | 512M（アプリ用） |
| db（PostgreSQL 16.0）       | ユーザー・設定の保存      | 公開しない    | 指定なし       |
| search（OpenSearch 2.11.0） | ユーザー検索の索引       | 9200     | 512m（検索用）  |

アプリ用の設定変数は`FUSIONAUTH_APP_MEMORY`で既定値が512M、検索用は`OPENSEARCH_JAVA_OPTS`でメモリ指定が512mです。アプリと検索エンジンにそれぞれ512MBを割り当てる前提なので、検証用のマシンでも2GB以上の空きメモリを見込んでおくと起動で詰まりません。

### OAuth 2.0・OIDC・SAML v2に対応するログイン画面とトークン発行

アプリ側から見ると、FusionAuthはOAuth 2.0とOpenID Connectの認可サーバーです。アプリはFusionAuthのログイン画面へリダイレクトし、戻ってきた認可コードをトークンに交換します。IDトークンの検証手順は[OIDCのIDトークン検証とOAuth 2.0との違い](https://www.issoh.co.jp/tech/details/6532/)と同じ考え方で実装できます。

SAML v2のIdPとしても動くため、SAMLにしか対応しない業務SaaSへのシングルサインオンも同じ基盤から張れます。パスキー（WebAuthn）は無料のLicensed Communityライセンスで有効になり、仕組みは[WebAuthnの登録・認証フロー](https://www.issoh.co.jp/tech/details/15375/)で解説しています。

## Docker ComposeでFusionAuth 1.69系を起動して管理画面を開く手順

ここからは手元のPCにFusionAuthを立ち上げます。前提はDocker 23以降です。

### 公式docker-compose.ymlの取得と起動コマンド、ヘルスチェックの確認

公式が配布する[docker-compose.yml](https://fusionauth.io/docs/docker-compose.yml)をそのまま取得して起動します。同じ場所に`.env`を置くと、`${NAME:-既定値}`形式で書かれた各値を上書きできます。

```
mkdir fusionauth && cd fusionauth
curl -o docker-compose.yml https://fusionauth.io/docs/docker-compose.yml

# .env（既定値を上書きする）
cat <<'EOF' > .env
POSTGRES_PASSWORD=change-me-root
DATABASE_PASSWORD=change-me-app
FUSIONAUTH_APP_MEMORY=1024M
EOF

docker compose up -d
docker compose ps

# 200が返れば起動完了
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9011/api/status
```

Compose側のヘルスチェックも同じ`/api/status`を叩いており、PostgreSQLとOpenSearchが healthy になってからアプリが起動する順序になっています。起動後に`http://localhost:9011`を開くと、最初の管理者を登録するセットアップ画面が表示されます。

### 本番前に差し替える既定パスワードとruntime modeの設定値

配布ファイルにはデータベースのパスワードが既定値として書き込まれています。`POSTGRES_PASSWORD`は`postgres`のままなので、検証環境でも外部から届くサーバーに置くなら必ず`.env`で変えてください。

もう1つが`FUSIONAUTH_APP_RUNTIME_MODE`で、既定値は`development`です。この配布構成は「ローカル開発用」と明記されており、OpenSearchのセキュリティ機能も`plugins.security.disabled: "true"`で切られています。本番は`production`へ切り替え、検索エンジンをネットワーク上に公開しない構成へ作り直す前提で読んでください。

### OpenSearchを省いてデータベース検索で動かす小規模構成の判断

[検索エンジンのドキュメント](https://fusionauth.io/docs/lifecycle/manage-users/search/)によると、ユーザー検索はデータベース検索とElasticsearch互換の検索エンジンのどちらかで動きます。データベース検索なら追加の部品は要らず、OpenSearchのコンテナを丸ごと外せます。

判断の目安は会員数と検索の細かさです。管理画面でメールアドレスや氏名を引ける程度で足り、会員が数万人規模に収まるなら、データベース検索で運用部品を1つ減らす方が保守は楽になります。あとからElasticsearch側へ移す場合、ユーザーの`data`フィールドに入れる値の型をそろえていないと再索引で失敗する、と公式に注意書きがあります。

## Kickstartとユーザー登録APIで初期設定と会員作成をコード化する手順

管理画面で手作業した設定は、別環境へ同じ状態を作れません。FusionAuthでは初期設定をJSONで書き、会員の作成をAPIで行うのが定石です。

### kickstart.jsonでAPIキーとテナントを初回起動時に作成する

[Kickstart](https://fusionauth.io/docs/get-started/download-and-install/development/kickstart)は、起動時に指定したJSONを読み、記載したAPIリクエストを上から順に実行する仕組みです。配布のComposeでは`./kickstart/kickstart.json`がマウントされる設定になっています。

```
{
  "variables": {
    "apiKey": "#{ENV.FUSIONAUTH_API_KEY}",
    "tenantId": "#{UUID()}"
  },
  "apiKeys": [
    { "key": "#{apiKey}" }
  ],
  "requests": [
    {
      "method": "POST",
      "url": "/api/tenant/#{tenantId}",
      "body": { "tenant": { "name": "customer-a" } }
    }
  ]
}
```

実行されるのは、APIキー・ユーザー・テナントがどれも存在しない空のインスタンスのときだけです。2回目以降の起動では何も起きないため、環境変数を設定したままでも安全です。使えるメソッドは`POST`・`PUT`・`PATCH`に限られます。

### ユーザー登録APIのPOSTで会員作成とロール付与を1回で行う手順

会員を作る処理は、[ユーザーと登録の結合API](https://fusionauth.io/docs/apis/registrations/create-a-user-and-registration-combined)を使うと1リクエストで済みます。FusionAuthでは「ユーザー」と「どのアプリを使えるかの登録」が別のオブジェクトで、登録のほうにロールを持たせます。

```
curl -X POST http://localhost:9011/api/user/registration \
  -H "Authorization: ${FUSIONAUTH_API_KEY}" \
  -H "X-FusionAuth-TenantId: ${TENANT_ID}" \
  -H "Content-Type: application/json" \
  -d '{
    "registration": {
      "applicationId": "'"${APPLICATION_ID}"'",
      "roles": ["member"]
    },
    "user": {
      "email": "taro@example.jp",
      "password": "Change-Me-123!"
    },
    "skipVerification": false
  }'
```

`roles`にはロールのIDではなく名前を書きます。パスワードを自社側で決めず本人に設定させたい場合、旧来の`sendSetPasswordEmail`は非推奨になり、1.59.0以降は`sendSetPasswordIdentityType`を使うよう案内されています。

## FusionAuthのテナント設計：顧客企業ごとに会員とテーマを分ける方法

BtoBのSaaSで「顧客企業ごとに会員を完全に分けたい」という要件があるとき、FusionAuthではテナントを使います。

### テナントで分かれる範囲：ユーザー・アプリケーション・パスワード規則

[テナントのドキュメント](https://fusionauth.io/docs/get-started/core-concepts/tenants)では、ユーザー・アプリケーション・グループをテナント単位で分けられると説明されています。同じ人物が2社の顧客企業に所属していても、テナントごとに別のアカウントとして扱えます。

パスワードの最小長や有効期限、確認メールのテンプレート、ログイン画面のテーマもテナント単位の設定です。顧客企業Aはパスワード12文字以上、顧客企業Bは8文字以上、といった規則の違いをアプリ側のコードに持たずに済みます。Defaultテナントは削除できないので、運用ではDefaultを管理者専用にし、顧客企業ごとのテナントを足していく形がわかりやすい構成です。

### X-FusionAuth-TenantIdヘッダとテナント限定APIキーの使い分け

テナントが複数あると、APIはどのテナントへの操作かを判別できなくなります。[API認証のドキュメント](https://fusionauth.io/docs/apis/authentication)のとおり、全テナントを扱えるAPIキーを使う場合は`X-FusionAuth-TenantId`ヘッダでテナントIDを渡します。

| APIキーの種類 | テナントの指定             | 向いている用途        |
| -------- | ------------------- | -------------- |
| 全テナント用   | ヘッダで毎回指定            | 自社の運用バッチ・管理ツール |
| テナント限定   | ヘッダ不要（付けるならキーと同じID） | 顧客企業ごとの連携処理    |

テナント限定のキーは、テナント間で共有される設定を読み取り専用でしか触れません。顧客企業向けの連携処理にはテナント限定キーを渡し、ヘッダの指定ミスで他社の会員を書き換える事故を仕組みで防いでください。

## FusionAuthの料金とプラン：Community無料版でできることと有料機能の境目

料金は[公式の料金ページ](https://fusionauth.io/pricing)、機能の区分は[Plans and Features](https://fusionauth.io/docs/get-started/core-concepts/plans-features)の2026年10月時点の記載で整理します。

### 無料版と有料3プランを比較する開始価格・ホスティング・追加機能の違い

Communityはセルフホストで無料、ユーザー数の上限もありません。有料の3プランはFusionAuth社のホスティングを含む形で掲載され、価格はどれも年払いの「Starting at」です。

| プラン        | 開始価格（月額・年払い） | ホスティング           | このプランで加わる主な機能           |
| ---------- | ------------ | ---------------- | ----------------------- |
| Community  | 無料           | セルフホスト           | OIDC・SAML・テナント・TOTPのMFA |
| Starter    | 162ドル〜       | basic hosting    | 高度なMFA・コネクタ・漏えいパスワード検出  |
| Essentials | 2,970ドル〜     | business hosting | 高度なOAuthスコープ・メールサポート    |
| Enterprise | 2,970ドル〜     | 高可用性hosting      | SCIM・脅威検出・テナント管理        |

表の「高度なOAuthスコープ」はAdvanced OAuth Scopes、「脅威検出」はThreat Detection、「テナント管理」はTenant Managerを指します。

料金ページの月間アクティブユーザー数の初期値は1,000で、会員数を増やすと金額が変わる設計です。見積もりは想定MAUを入れて画面で確かめてください。課金単位の考え方が近いAuth0との比較は[Auth0の料金とMAU課金の増え方](https://www.issoh.co.jp/tech/details/17297/)が参考になります。

### LDAPコネクタ・メールとSMSのMFA・SCIMが有料になる案件の注意

業務システムの案件で引っかかりやすいのは3点です。社内のActive DirectoryやLDAPに会員を置いたまま認証させる[コネクタ](https://fusionauth.io/docs/lifecycle/migrate-users/connectors/)は有料プラン限定で、Community版では使えません。メールやSMSで送るワンタイムコードのMFAもStarter以上です。

人事システムから入退社を自動反映するSCIMはEnterpriseの機能になります。Communityで作り始めて、本番直前にこれらが必要とわかると、月額2,970ドルからのプランへ一気に上がります。要件定義の段階で、この3点が要るかを先に確かめておくのが安全です。

## FusionAuthとKeycloakの選び分け：採用すべき条件と見送る場面の判断

セルフホストできる認証基盤の比較で、必ず並ぶのがKeycloakです。Keycloakは[GitHubで公開されているOSS](https://github.com/keycloak/keycloak)で、2026年10月時点の最新版は[26.8.1](https://www.keycloak.org/downloads)です。ここでは両者の分かれ目を言い切ります。

### FusionAuthを採用すべき条件：API中心の会員基盤を少人数で運用する

採用するのは、会員の作成・更新を自社アプリからAPIで行う、テナントで顧客企業を分ける、運用担当が少ない、の3条件がそろう案件です。配布されるComposeとKickstartで環境の再現が容易で、APIキーとヘッダだけで会員操作が完結します。

Keycloakでも同じことはできますが、realmやクライアントの設定項目が多く、管理コンソールの理解に時間がかかります。運用の手間の違いは[Keycloakのデータベース設定と権限モデル](https://www.issoh.co.jp/tech/details/3293/)と見比べると、設定や権限管理で必要になる作業の違いが具体的になるはずです。フロントがNext.js中心で画面部品まで任せたいなら、SaaSの[Clerk](https://www.issoh.co.jp/tech/details/18308/)も候補に入ります。

### FusionAuthを見送る場面：OSS必須・SCIM必須・LDAP連携の3条件

見送るのは次のどれかに当てはまる案件です。官公庁や大企業の調達でOSSライセンスの製品であることが条件になっている。SCIMでの自動プロビジョニングが必須なのに、Enterpriseの予算が取れない。社内LDAPのパスワードを移さずに認証させる必要がある。OSS条件とLDAP連携（User Federation）はKeycloakなら無償の範囲で満たせます。SCIMはKeycloakでも標準機能の対応範囲を版ごとに確かめる必要があるため、要件に含まれるなら両製品とも検証環境で動作を見てから決めてください。比較の詳細は[Keycloakとは：Auth0・Okta・Cognitoとの比較](https://www.issoh.co.jp/tech/details/7663/)にまとめています。

既存の会員DBからの移行、複数サービスの統合ログイン、テナント設計まで含めて基盤を選びたい場合は、[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)として製品選定の段階から相談を受けています。

## FusionAuthの導入前によくある質問：無料範囲・ライセンス・移行と運用

FusionAuthの導入検討でよく出る質問に、2026年10月時点の公式情報をもとに答えます。

### FusionAuthは無料でどこまで使えますか？

Community版はセルフホストで無料、ユーザー数の上限もありません。OAuth 2.0・OIDC・SAML v2のログイン、テナント、TOTPのMFAはこの範囲で使えます。パスキー（WebAuthn）は無料のLicensed Communityライセンスを取得して管理画面のReactorタブに入力すると有効になります。LDAPなどのコネクタ、メールやSMSのMFA、漏えいパスワード検出はStarter以上の有料機能です。

### FusionAuthはオープンソースですか？

オープンソースではありません。コンテナ定義の[fusionauth-containers](https://github.com/FusionAuth/fusionauth-containers)などはGitHubで公開されていますが、アプリ本体はFusionAuth社が配布する商用製品で、Community版を無料で使えるライセンス形態です。ライセンスの扱いは[Licensingのドキュメント](https://fusionauth.io/docs/get-started/core-concepts/licensing)に、有料ライセンスの有効化手順とあわせて書かれています。

### FusionAuthのバージョンはどう確認し、どの頻度で更新されますか？

公式の[リリースノート](https://fusionauth.io/docs/release-notes/)で確認できます。2026年9月から10月にかけては1.69.2（9月14日）、1.69.3（9月28日）、1.69.4（10月14日）と、公開の間隔はおよそ2週間です。Docker運用ならイメージのタグを`1.69.4`のように固定し、リリースノートを読んでから上げる手順にしておくと、意図しない更新を防げます。

### KeycloakからFusionAuthへ移行できますか？

できますが、パスワードの扱いが分かれ目です。ユーザー作成APIでメールアドレスや属性を移すこと自体は難しくありません。ハッシュ化済みパスワードをそのまま移せない場合は、移行後に本人へパスワード設定メールを送るか、ログイン時に旧基盤で認証して移す方式を選びます。後者のコネクタは有料プランの機能なので、移行方式は料金とあわせて決めてください。

### 本番環境でもDocker Composeで運用してよいですか？

公式の配布ファイルは「ローカル開発用」と明記され、OpenSearchのセキュリティ機能も切られています。そのまま本番に流用するのは避けてください。本番は`FUSIONAUTH_APP_RUNTIME_MODE`を`production`にし、データベースは冗長化されたマネージドサービスへ分けます。Kubernetesで運用する場合はHelmでの導入が公式にサポートされています。

## 関連記事

- [Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】](https://www.issoh.co.jp/tech/details/7663/)：FusionAuthと並ぶセルフホスト型認証基盤の比較と導入判断。
- [CIAMとは？顧客ID基盤の設計と会員DB移行・同意管理を実装視点で解説](https://www.issoh.co.jp/tech/details/16403/)：FusionAuthで組む顧客ID基盤の設計と会員DB移行の考え方。
- [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：セルフホストかIDaaSかを決める前の前提整理。
- [JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](https://www.issoh.co.jp/tech/details/13453/)：FusionAuthが発行するトークンをアプリ側で検証するときの基礎。
- [Clerk認証とは？Next.jsへの導入手順とCore 3の変更点・MRU料金・Auth0との選び分け【2026年10月】](https://www.issoh.co.jp/tech/details/18308/)：セルフホストせずSaaSで認証を外部化する場合の選択肢。

---

出典: [FusionAuthとは？Docker Composeでの起動手順とテナント設計・料金・Keycloakとの選び分け【2026年10月】](<https://www.issoh.co.jp/tech/details/18601/>)（株式会社一創）