カテゴリー: コミュニティ

ニュースのポイント

• オンプレ環境で1つのClient Extensionを複数のバーチャルインスタンスに展開するための、Liferay Workspaceのカスタマイズを紹介。Liferayの公式ナレッジ記事にある3つの方法を、インスタンス一覧から自動化する非公式の仕組み。
• Option 1はインスタンスごとにZIPを作る公式推奨の方式（-Pcx.custom.one-per-instance=true）。Option 2は1つのZIPにインスタンス別ブロックを生成するが、使用するvirtualInstanceIdは非推奨で将来削除の可能性がある。Option 3はOSGi設定ファイル（generateCXConfig）で登録する方式。
• インスタンスIDはheadless-portal-instances APIで取得でき、gradle.propertiesにcx.build.custom.env.instances[<env>]を書く方法もある。本カスタマイズは公式サポート対象外で、Workspaceアップグレード後はコード確認が必要と著者は注意している。

編集部コメント

マルチテナント（複数バーチャルインスタンス）構成でClient Extensionを使う場合の設計判断材料になる記事です。サポートされる方式を優先するならOption 1が基本で、ZIP数が増える運用負担とのトレードオフになります。

原文では、Liferayが複数バーチャルインスタンスへのデプロイを2027年ごろ再評価する予定で、チケットLPD-110276の進捗を確認するよう勧められています。採用前に公式ドキュメントも合わせて確認してください。

出典：liferay.dev（Daniel Carrillo Broeder、2026年10月21日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• themeCSS と customElement のクライアント拡張で、clay.css(731,706バイト)などがgzipされず配信される事象が報告された。圧縮設定自体は無効化されていなかった。
• 原因は古い liferay/caddy イメージ(Caddy 2.5.0同梱)。無圧縮レスポンスに Vary: Accept-Encoding が付かず、CDNが無圧縮版をキャッシュして全ブラウザに配信してしまう。Caddy 2.8.0で修正され、liferay/caddy 10.0.84以降に含まれる。
• 対処は各フロントエンドCXの再ビルド・再デプロイ（UAT→本番）と、Liferay CloudコンソールからのCDNキャッシュクリア。確認はHEADではなくGETで行い、キャッシュ回避のクエリを付ける。

編集部コメント

著者は、loadBalancer.cdn: false への変更や Vary ヘッダーの強制といった回避策は推奨していません。自分のコードに変更がなくても、再ビルドでベースイメージの修正を取り込める点が実務上の要点です。

Liferay Cloud上でクライアント拡張を運用している場合は、プロジェクトのDockerfileが古い liferay/caddy タグを固定していないか確認してみてください。

出典：liferay.dev（Maurice Sepe、2026年10月20日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• Liferay DXP MCPサーバーは2025.Q4でベータ提供され、2026.Q3でリリース機能に昇格したと記事は説明している。エンドポイントは /o/mcp で、Streamable HTTPに対応し、Basic認証またはOAuth 2.0のbearerトークンを使える。仮想インスタンスごとの設定で、デフォルトは無効。
• Dummy Factory 2.0はJSONのワークフロー文書で複数操作を順に実行でき、14種類の操作別ツールと、ワークフロー用4ツールを含む計18ツールを /o/mcp/ldf プロファイルとして公開する。例として createUsers に count:5 を渡し、demo-user1〜5を作成できる。
• 実装上の注意として、1リクエストあたりの件数は1000件に制限され、超過は切り捨てではなく拒否される。ワークフローAPIは企業管理者権限が必要。executeWorkflowはステップが失敗してもHTTP 200を返すため、操作別ツールは失敗時に422を返す。

編集部コメント

Dummy Factoryは開発・テスト用ツールで、本番環境には導入しないよう記事が明記している。作者の検証はClaude Codeとローカルのbasic認証環境のみで、リモートアクセスやOAuth 2.0は未検証とのこと。試す場合は検証環境で行い、設定手順や制限の詳細は原文を確認してほしい。

MCPサーバーの機能フラグ名や有効化手順も原文に記載されている。当サイトの図鑑ページとあわせて、DXPのAI連携の入口として参考にしてほしい。

出典：liferay.dev（Yasuyuki Takeo、2026年10月10日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• KDXPは、LiferayのヘッドレスAPI上に構築されたKotlin Multiplatformフレームワークで、Android、iOS、デスクトップ、Webの4つを対象とする。
• 記事によると、従来のモバイルライブラリは非推奨または削除されHeadless Deliveryに置き換えられたが、代わりの開発者体験は提供されていなかった。
• セットアップデモ動画では、ローカルのLiferayへの接続、OAuth設定、アプリケーションベースのサイト作成を扱う。著者はKDXPを完成品ではなく最初の一歩と位置づけている。

編集部コメント

記事にはバージョンや手順の詳細はなく、現時点では構想の紹介が中心です。採用判断は公開されているデモやリポジトリを確認してからにしてください。

出典：liferay.dev（Nestor Ledon、2026年8月5日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• 著者はChatGPTとCursorを使い、コードを直接書かずにTOTPベースの2要素認証OSGiモジュール「lfr-totp-auth」（Apache 2.0）を作成した。対象はLiferay 7.4 CE、2025.Q1以降など。
• パスワード検証後もユーザーは認証済みではなく、TOTP検証の後にセッションを作成する設計。秘密鍵とバックアップコード（5個、BCryptでハッシュ化）はExpandoフィールドに保存する。
• 著者は今後の課題として、レート制限・ブルートフォース対策、MFAイベントの監査、アカウント回復手順、2026.Q1への対応を挙げている。

編集部コメント

記事のコメント欄では、MFAはLiferay DXPのサブスクリプションに含まれる標準機能であり、独自開発より標準機能の利用が推奨されると指摘されています。認証まわりを自作する場合は、この点を踏まえて検討してください。

出典：liferay.dev（Eric Dariel、2026年9月12日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• 記事によると、React製Client Extensionは変更のたびにGradleでビルド・再デプロイが必要で、この往復に20〜30秒かかる。
• npmのCLI「liferay-cx-hmr-setup」を実行すると、ワークスペース内のViteベースCXを検出し、client-extension.dev.yaml、開発用プリアンブル、CORS、Liferay提供パッケージの外部化プラグインを自動設定する。ポートは5173、5174…と空きを順に割り当てる。
• 手順は npx liferay-cx-hmr-setup → deployDev → npm run dev。設定は開発専用で、本番用client-extension.yamlやCIのGradleビルドは変更されない。

編集部コメント

Client Extensionの開発で保存のたびに待たされている方には試す価値がありそうです。前提はViteを使うReact CXと、ローカルで到達できるDXP環境です。

Client Extension自体の考え方は、当サイトの図鑑ページもあわせてご覧ください。

出典：liferay.dev（Ankit Hadiyal、2026年8月1日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• Liferay Batch Engineの/batchエンドポイントによる一括インポートは非同期タスクとして処理されるが、標準ではそのタスクを確認するUIが無い。著者は大規模B2Bコマース案件で、PIMから連携したデータの一部が失敗した際に、ログやDBの調査が必要になったと述べている。
• Batch Import Auditは、コントロールパネルに「Monitoring」カテゴリとして追加されるツール。BatchEngineImportTaskとBatchEngineImportTaskErrorテーブルのデータを使い、Initiator・Execute Status・Class Name・External Reference Codeで絞り込んだ一覧を表示する。
• 詳細画面ではバッチサイズ、インポート戦略、整形されたリクエストペイロードを確認でき、失敗したタスクではどのレコードがなぜ失敗したかが分かる。Batch Engineの動作自体は変更せず、すでに記録されているデータを見せるだけ。コードはGitHubのvitaliy-koshelenko/liferay-batch-import-auditで公開されている。

編集部コメント

コミュニティ製のツールです。バージョン要件やインストール手順は記事に記載がないため、導入前にGitHubリポジトリで確認してください。

Headless Batch APIで外部システムと連携している案件では、失敗の切り分けに役立ちそうです。

出典：liferay.dev（Vitaliy Koshelenko、2026年7月29日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• Service Builderは特定のリリース系列のサービスAPIに依存したJavaコードを生成するため、プラグインのバージョンは、ワークスペースが対象とするDXPのバージョンに合わせる必要がある。記事には2023.Q3（1.0.463）から2026.Q2（1.0.532）までの対応表がある。
• gradle.propertiesのliferay.workspace.productで四半期リリースを確認し、com.liferay.portal.tools.service.builder.versionを固定する。例として、dxp-2024.q1.10-ltsは1.0.478、dxp-2026.q1.8-ltsは1.0.514、dxp-2026.q2.0は1.0.532が挙げられている。
• 誤ったバージョンで生成した場合は、生成済みクラスを削除してからblade gw buildServiceで再生成する。プラグインのバージョン変更だけでは再生成されず、service.xmlやimplクラスの変更時のみ対象クラスが再生成される。

編集部コメント

ターゲットプラットフォームを変更するたびに、Service Builderのバージョンも見直すのが安全です。記事は、生成コードと設定変更を同じコミットにまとめ、後から理由を追えるようにすることを勧めています。

Liferay Dev Toolsチームは、対象プラットフォームに応じたバージョン自動選択を検討中とのことです。

出典：liferay.dev（David H Nebinger、2026年7月30日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• Liferay DXP 2026.Q3で外部のConsent Management Platform（CMP）連携が導入された。設定場所はインスタンス設定の「Privacy」内にあるThird-party Consent Management Platformで、Provider Name、Script Tag、Consent Mapping Script、Enabledを指定する。
• CMPでの同意結果は、Consent Mapping ScriptでURLエンコードされたJSON形式のCookie「CONSENT_STATE」に変換する。キーはNecessary・Functional・Performance・Personalizationの4カテゴリで、Necessaryは常にtrue。Functionalがfalseなら、サインイン時にREMEMBER_MEが作られない。
• CONSENT_STATEが無い・不正・キー欠落の場合、該当カテゴリは「同意済み」として扱われる。記事は初期化時に意図した状態を設定することを勧めている。組み込みのConsent Managerと外部CMPを同時に有効にするとバナーが二重に出る可能性があるため、同時有効化は避ける。

編集部コメント

Cookiebot、OneTrust、Usercentricsなど7種のCMP向けにマッピングスクリプトの例が用意されているとのことですが、カテゴリIDやpurpose IDはテナントや案件ごとに異なり得るため、自社のCMP設定に合わせた確認が必要です。「同意情報が欠けると同意済み扱い」という既定の挙動は、実務で見落としやすい点です。

テストはシークレットウィンドウで毎回行い、CONSENT_STATEの中身と実際の挙動を両方確認する、という進め方が紹介されています。詳細な手順は原文をご覧ください。

出典：liferay.dev（David H Nebinger、2026年9月23日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

ニュースのポイント

• Free Tierは、Enterprise Subscriptionと同じコア製品を1つのダウンロードで提供するものです（2026.Q1リリース）。各四半期アップデートの初回リリースが含まれ、利用はActivation Keyで管理されます。ソースコードはLGPLで公開されたままだと説明されています。
• 入手手順は、liferay.com/downloads-community で最新の四半期リリースをダウンロードし、Marketplaceの Free Tier ページで「Get Activation Key」からフォームを送信してキーを発行する流れです。キーの有効期間は12か月で更新でき、特定のドメインまたはlocalhostに紐づきます。
• AI HubとLiferay Data Platform、プロフェッショナルサポートとSLA、セキュリティパッチ・ホットフィックス、補償などは含まれず、サポートはコミュニティとドキュメントのみです。学習・開発・小規模利用向けで、本番ではEnterprise Subscriptionが強く推奨されています。

編集部コメント

クラスタリングは同じデータベースを共有する最大3ノードまで追加のキーなしで使えるとされています。セキュリティパッチが含まれない点は、本番利用を考える際に特に押さえておきたい条件です。

Enterprise Subscriptionへはキーを差し替える形で移行でき、再インストールは不要と説明されています。詳しい違いは、当サイトの「エディションと提供形態・料金」のページも参考にしてください。

出典：liferay.com 公式ブログ（2026年9月18日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）