ライセンス

ObjectOS Enterprise のデプロイメントは、OS_LICENSE_KEY にライセンスを設定して、ライセンスされた Enterprise イメージを実行します。イメージで何が有効になるかはライセンスが決めます。このページでは、ライセンスの入手方法、2 つの検証方法、ランタイムが下した判断の読み方、更新の方法、そして終了したライセンスが何をオフにするかを説明します。契約のオプションはライセンスと料金にあります。

ライセンスを入手する

ライセンスは契約に基づいて ObjectStack が発行します。営業にお問い合わせください。セルフサービスでの購入はありません。ライセンスのメールには次のものが含まれます。

1. リリースのイメージダイジェスト。タグは動かせますがダイジェストは動かせないので、ダイジェストでインストールします（理由）。
2. パッケージの読み取り権限を持つレジストリのプルトークン。オフラインバンドルからインストールする場合は不要です。
3. ライセンス：ObjectStack が署名した 1 行のテキストです。ランタイムは起動時に、イメージに組み込まれた公開鍵で署名を検証するため、1 バイトでも変更されたライセンスは無効として拒否されます。
4. デプロイバンドル。リリースの Compose スタック、環境テンプレート、スクリプトが含まれます。

ライセンスは、OS_AUTH_SECRET と同じようにシークレットとして保管してください（本番環境への準備）。ライセンスの発行時に 3 つのことが固定され、どれも変更できる設定ではありません。

• AI シート：契約で購入する数で、25 以上です（maxAiSeats）。
• モード：オンラインまたはエアギャップです（後述）。
• 種類：終了日のあるサブスクリプション、または保守終了日のある永続ライセンスです（後述）。

Enterprise ライセンスで有効になるもの

ObjectOS Enterprise はひとつのエディションです。契約で機能が明示的に列挙されていない限り、Enterprise ライセンスは以下のすべての機能を許可します。起動バナーの features の行に、あなたのライセンスが許可するものが表示されます（後述）。

Enterprise がひとつのエディションになる前に発行されたライセンスでは、エディション名が business になっている場合があります。そのライセンスは終了するまで販売時の条件（1 ノード、最大 25 AI シート、製品内の AI と AI ガバナンス、オンライン検証）を保ち、更新時には Enterprise ライセンスとして更新されます。

各行の意味と、その範囲は次のとおりです。

• 製品内の AI。 「ask」エージェントは、含まれていてサポートされるエージェントです。AI Builder は契約の対象外のプレビューとして提供され、起動バナーにもそう表示されます。プラットフォーム管理者がユーザーに AI シートを割り当て、その数はライセンスが決めます（AI シートを割り当てる）。モデルとキーは持ち込みです。
• AI ガバナンス。 すべての AI ツール呼び出しの監査証跡（誰が AI に何を頼み、AI が何に触れたか）、AI がレコードの権限を回避する手段にならないよう各回答に対して行う権限チェック、AI のツールが取得するデータ内の機密フィールドのマスキング、そして目に見える割り当て超過の拒否です。ユーザーが貼り付けた会話履歴は再マスキングされません。
• 複数のノード。 契約で数が設定されていない限りライセンスはノード数を制限しませんが、高可用性の製品ではありません。複数のレプリカにまたがる高可用性は開発中で、リリースされるまで提供されません。デプロイバンドルは現在 1 つのノードで動作し、クラスタードライバーが設定されるまで、ランタイムは 2 つ以上のレプリカを拒否します。ライセンスがない場合、ランタイムはレプリカ 1 つで動作し、それ以上を宣言したデプロイメントは起動を拒否します。
• 階層セキュリティ。 事業単位のツリーに基づくレコードの表示範囲です。単位、単位と配下、本人と部下という読み取りスコープがあります（階層による表示範囲）。
• 複数の組織。 ひとつのデータベース上の、組織ごとの分離の壁です。マルチ組織を参照してください。
• 顧客管理の鍵。 シークレットのフィールド、データソースの認証情報、暗号化された設定は、エンベロープ暗号化によって、自社の AWS KMS、Azure Key Vault、または HashiCorp Vault（transit）の鍵のもとで封印されます。各値には新しいデータキーが使われ、それがあなたの鍵でラップされます。あなたの鍵が KMS の外に出ることはありません。鍵を失効させると、それらのシークレットはすぐに読めなくなります。設定されているのに到達できない KMS や、ライセンスされていない KMS は起動を拒否します。ランタイムがローカルの鍵にフォールバックすることはありません。業務フィールド、メタデータ、添付ファイル、監査ログはこの機能では暗号化されず、保存時の暗号化はディスクまたはデータベースの暗号化に依存します。単一環境の形態と合成の形態に適用され、アーティファクト固定の形態では拒否されます。インストール時に選んでください。有効にする前に書き込まれたシークレットは移行されず、無効にすると、この機能が封印したシークレットは読めなくなります。顧客管理の鍵は、4.3.1 より新しい Enterprise のリリースに含まれます。

AI シートを割り当てる

AI シートがあると、ユーザーは製品内の AI とチャットできます。デプロイメントが持てるシートの数はライセンスが決め（maxAiSeats）、各シートは 1 人のユーザーに割り当てられます。

プラットフォーム管理者は、誰かが割り当てなくてもシートを持ちます。 これは、admin_full_access 権限セットを持つすべてのアカウント（単一組織のデプロイメントでは、最初に作成されたアカウントがそれを持ち、後でそれを付与された人も同様です）と、アドレスが OS_PLATFORM_OWNER_EMAIL に記載されているすべてのアカウントです。後者は、アカウントが存在しアドレスが確認された時点でシートを得ます。複数の組織があるデプロイメント（OS_TENANCY_POSTURE=isolated または group）では、OS_PLATFORM_OWNER_EMAIL のアカウントがプラットフォーム管理者です。

これらの自動のシートは maxAiSeats に数えられます。5 シートのライセンスにプラットフォーム管理者が 2 人いれば、割り当てられるのは残りの 3 つです。ただし、自動のシートが拒否されることはないので、上限を超える場合でも、デプロイメントが管理者を AI から締め出すことはありません。

それ以外の人は、プラットフォーム管理者からシートを受け取ります。1 人ずつです。

• アプリで：Setup → Users でユーザーを開き、Assign AI Seat を選びます。Revoke AI Seat はシートを取り戻し、ほかの人のために空けます。この 2 つのアクションが見えるのはプラットフォーム管理者だけです。

• API で、プラットフォーム管理者のセッショントークンを使って：

  curl -X POST -H "Authorization: Bearer $TOKEN" \
    "$BASE/api/v1/actions/sys_user/assign_ai_seat/usr_123"
  curl -X POST -H "Authorization: Bearer $TOKEN" \
    "$BASE/api/v1/actions/sys_user/revoke_ai_seat/usr_123"

シートは、ユーザーのレコードやデータ API で編集できるフィールドではありません。変更する方法はこの 2 つのアクションだけで、AI エージェントはそれらを呼び出せません。拒否されるのは次の場合です。

この 2 つのアクションと、OS_PLATFORM_OWNER_EMAIL のアカウントの自動のシートは、4.3.1 より新しい Enterprise のリリースに含まれます。

オンラインかエアギャップか

ライセンスのモードは、その検証方法を示します。どちらのモードも、まずローカルで署名と終了日を検証します。

2 つの組み合わせは、起動時に自動的に判断されます。

• OS_CLOUD_URL=off のオンラインライセンスは決して検証できないため、ランタイムは両方の設定を名指しして起動を拒否します：✖ FATAL: this deployment has an ONLINE-mode OS_LICENSE_KEY but no control plane to validate it against。切断されたサイトには、エアギャップのライセンスを依頼してください。
• 複数の組織が公開済みのアプリの背後でひとつのデータベースを共有する合成の形態は、OS_CLOUD_URL=off のエアギャップライセンスのみを受け付けます。

完全な組み合わせの表とその理由は、エアギャップデプロイメントにあります。

オンラインライセンスで初めて起動するとき、エンタイトルメントがまだキャッシュされていない段階では、そのブートで Enterprise の機能をマウントできるよう、ランタイムはコントロールプレーンを最大 10 秒待ちます。それより後に検証が成功した場合、ランタイムは検証済みですが、すでに Community として構成されています。ログにそのことが記録され、Enterprise の機能は次の再起動時にマウントされます。その後の猶予期間内の再起動では、待たずにキャッシュされたエンタイトルメントからライセンスされます。

起動バナーが示すもの

起動のたびに、ランタイムは自分が下した判断を示すバナーをログに出力します。たとえば、ライセンスされたデプロイメントは次のように出力します。

────────────────────────────────────────────────────────────────
  ObjectOS Enterprise — LICENSED
    customer  : Example Corp
    customerId: cus_0123
    org       : (none)
    licenseId : lic_0456
    seats     : up to 50 AI seat(s)
    nodes     : unlimited
    expires   : 2027-06-30T00:00:00.000Z
    features  : aiStudio, clustering, hierarchySecurity, scim, governance, multiOrg, customerManagedKeys
    in-UI AI  : ENABLED (AI Builder + ask)
    preview   : AI Builder（预览，不在合同范围内）; ask is the included, supported agent
    mode      : ONLINE (validated by the control plane)
    validated : 2026-11-07T09:12:44.000Z
    ent expiry: 2026-11-10T09:12:44.000Z
    refresh   : 2026-11-08T09:12:44.000Z
    runtimeId : rt_0789
────────────────────────────────────────────────────────────────

いくつかの状態はバナーの先頭に出るので、最初に目に入ります。

• ⚠ GRACE — the control plane has not confirmed this license recently と、それに続く、猶予期間が終わる日付を示す degrades の行。
• 永続ライセンスでは、license の行がその状態を示します：PERPETUAL — in maintenance until …、または PERPETUAL — VERSION-LOCKED (maintenance ended …) と updates : none — newer images run as Community; renew maintenance to update。⚠ BUILD STAMP UNUSABLE は、イメージが自分のリリース日を証明できないことを意味します（後述）。

使えるライセンスのないデプロイメントは、代わりに Community のバナーを、理由と対処法とともに出力します。

────────────────────────────────────────────────────────────────
  ObjectOS Community mode — NO valid Enterprise license
    reason    : no license (OS_LICENSE_KEY unset)
    in-UI AI  : DISABLED (AI Builder + ask)
    data      : available via the open MCP server — bring your own AI client
    to enable : set OS_LICENSE_KEY to a valid Enterprise license token
────────────────────────────────────────────────────────────────

アーティファクト固定の形態（OS_ARTIFACT_URL）では、イメージ自身の設定が実行されないため、バナーはなく、バナーが報告するもの（AI シート、AI ガバナンス、階層セキュリティ）もマウントされません。

起動せずにライセンスを確認する

デプロイバンドルの license-check.sh は、ネットワークのないコンテナでイメージ自身の検証機能を実行し、どこにも何も送信しません。顧客、エディション、期間、モード、上限を出力し、ライセンスそのものは決して出力しません。このイメージがあなたの .env でライセンスされた状態で起動する場合にだけ、終了コード 0 で終わります。

./license-check.sh                       # the license in .env, against the running image
./license-check.sh --file new.txt        # a license you have not stored yet
./license-check.sh --image <new digest>  # against the image you are about to upgrade to

エディションは enterprise と表示され、Enterprise がひとつのエディションになる前に発行されたライセンスでは business と表示されます。サブスクリプションの終了の 30 日前になると、チェックは警告します。

更新

更新とは新しいライセンスのことで、どちらのモードでも、終了日がより後になった新しい 1 行のテキストです。現在のライセンスが終了する前にインストールしてください。

./license-check.sh --set ./renewal.txt   # stores it in .env as OS_LICENSE_KEY and checks it
docker compose up -d                     # applies it

Kubernetes では、ライセンスを保持する Secret を更新し、Pod を再起動します。ライセンスはデプロイメント全体に適用され、すべてのレプリカが同じライセンスで動作します（Kubernetes）。

永続ライセンスでは、アップデートを受け取り続けるには保守を更新します。保守の更新は保守終了日がより後になったライセンスで、現在のものより後にリリースされたイメージにアップグレードする前に必要です。

ライセンスが終了したとき

ライセンスは、その種類によって 2 つの方法のいずれかで終了します。どちらもランタイムを止めたりデータに触れたりはしません。ただし、後述の 3 つの例外があります。

サブスクリプション

契約で永続と定められていない限り、Enterprise ライセンスはサブスクリプションです。終了日の後の次の起動時に、ランタイムはライセンスがないものとして扱い、Community として動作します。

• 製品内の AI と AI ガバナンスはオフになります。
• 階層の読み取りスコープは何も許可しなくなります。
• SCIM はデフォルトで有効ではなくなります。
• データはそのまま残り、オープンな MCP サーバーは動作し続けるので、自分の AI クライアントからは引き続きアクセスできます。

サブスクリプションはバージョンロックしません。終了日の後に Enterprise の機能を保つイメージはありません。更新のライセンスをインストールすると、次の起動時に機能が戻ります。

永続

永続ライセンスは買い切りで、契約でのみ販売され、保守の終了後もバージョンを保つ唯一の種類です。終了日はありません。代わりに保守終了日があり、保守料を支払っていた期間にリリースされたバージョンを保ちます。

• 保守の終了前にリリースされたイメージは、実行し続ける限り、製品内の AI を含むすべての Enterprise の機能を保ちます。保守の終了後は、バナーと license-check.sh に VERSION-LOCKED と表示されます。
• 保守の終了後にリリースされたイメージは Community として動作します。アップグレードの前に ./license-check.sh --image <new digest> を実行してください。そのイメージが対象かどうかを示し、対象でない場合は ./upgrade.sh preflight が停止します。
• アップデート、パッチ、サポートは保守とともに終了します。

イメージは、リリースマニフェスト /etc/objectstack/ee-release.json によって、いつリリースされたかを証明します。このファイルやそのディレクトリの上に何もマウントしないでください。マウントするとランタイムはそれを使えず、ライセンスはサブスクリプションと同じように保守の終了時に失効します。オンラインの永続ライセンスは、保守の終了後も、同じ 7 日間の猶予期間でコントロールプレーンを必要とします。デプロイメントがそれに依存してはならない場合は、エアギャップの永続ライセンスを依頼してください。バナーと license-check.sh の VERSION-LOCKED の状態は、4.3.1 より新しい Enterprise のリリースに含まれます。それより古いイメージは、永続ライセンスでライセンスされた状態で起動します。

3 つのデプロイメントは代わりに起動を拒否する

3 つの構成は、存在するために有効なライセンスを必要とします。そのため、ライセンスが終了しているか欠けている場合、Community として動作するのではなく起動を拒否します。データはそのまま残り、有効なライセンスがあれば元に戻ります。

• 複数の組織（OS_TENANCY_POSTURE=isolated または group）：組織間の分離はライセンスされた機能であり、それを求めたデプロイメントは、ライセンスなしにトラフィックを処理することはありません。マルチ組織を参照してください。
• 顧客管理の鍵（OS_CRYPTO_PROVIDER に KMS を設定）：シークレットはあなたの鍵のもとで封印されているため、ランタイムがローカルの鍵にフォールバックすることはありません。
• 複数のノード（OS_CLUSTER_REPLICAS が 1 より大きい）：マルチノードのライセンスがない場合、ランタイムは協調しないレプリカを動かすのではなく、宣言されたトポロジーを拒否します。

これらの更新は、証明書の更新と同じように計画してください。ライセンスのチェックは 30 日前に警告し、日付はすべての起動バナーに表示されています。

次へ

• マルチ組織：複数の組織が共有するデプロイメントでのライセンス。
• エアギャップデプロイメント：切断されたサイト向けのライセンスモード。
• Docker → Enterprise で追加されるもの：ライセンスに伴うレジストリ、検証、アップグレードの手順。