Liferay図鑑は非公式の情報サイトです。Liferay, Inc.・日本ライフレイ株式会社とは関係ありません。

Liferay図鑑

ブログ

  • Liferay DXP 2026.Q3 リリースウェビナーのリプレイ公開

    ニュースのポイント

    • liferay.devが、Liferay DXP 2026.Q3のリリースウェビナーのリプレイを公開した。
    • 主な新機能として、Design Libraries、CNE AWS Ready、Kubernetes Readyが挙げられている。
    • Betaを外れるモジュールとして、Liferay Data Platform、Digital Sales Room、AI Hubが GA、Content Marketing Platform が Release と記載されている。

    編集部コメント

    本記事はウェビナー動画の告知で、各機能の詳細な仕様や対象エディションは記載されていない。導入を検討する場合は、公式のリリースノートやドキュメントで条件を確認してほしい。

    2026.Q3を使う方は、上記の機能がご自身の構成に関係するかをウェビナーで確認しておくとよい。

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

  • Dummy FactoryとDXP MCPサーバーで環境構築を対話化

    ニュースのポイント

    • 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のヘッドレスを使うKotlin Multiplatformフレームワーク

    ニュースのポイント

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

    編集部コメント

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

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

  • AIでLiferayにTOTP二要素認証を追加する試み：lfr-totp-auth

    ニュースのポイント

    • 著者は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日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • Liferay DXP 2026.Q3リリースウェビナー：GA機能とDesign Libraries

    ニュースのポイント

    • 2026年8月26日に同内容のウェビナーが2回開催された（日本時間17:00の回を含む）。現在は録画が閲覧可能とページに記載されている。
    • AI Hub、Content Marketing Platform、Liferay Data Platform、Digital Sales RoomsがGAに移行し、新機能が追加される。
    • Cloud NativeではGCP ReadyとKubernetes ReadyのGAサポートが追加。新機能Design Librariesは、複数サイトでデザインアセットを作成・再利用できる中央の場所を提供する。

    編集部コメント

    具体的な変更点の詳細は告知ページには書かれていないため、導入前は公式のリリースノートで確認してください。

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

  • React Client ExtensionでHMRを自動設定するCLI liferay-cx-hmr-setup

    ニュースのポイント

    • 記事によると、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日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • Batch Engineのインポート状況を確認するBatch Import Audit

    ニュースのポイント

    • 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プラグインとDXPバージョンの対応表の使い方

    ニュースのポイント

    • 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日）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • DXP 2026.Q1のOIDCバックチャネルログアウト対応の解説

    ニュースのポイント

    • 記事によると、Liferay DXP 2026.Q1はOpenID Connectのバックチャネルログアウトに対応している。LiferayはRelying Party（RP）としてのみ動作し、Keycloak、Microsoft Entra ID、Oktaなどの外部OpenID Providerに認証を委ねる。
    • OPがサーバー間通信で署名付きLogout Tokenを送り、Liferayは/o/open_id_connect/backchannel_logoutで検証して該当セッションを無効化する。通常どおりOIDCを設定し、このエンドポイントのURLをOPに登録する。署名検証に失敗した要求は拒否される。
    • RP起点のログアウト（LiferayからOPのSSOセッション終了を依頼する方式）は将来のリリースで計画されているが、ロードマップは変更され得ると記事は述べている。

    編集部コメント

    運用上は、OPからLiferayのエンドポイントへ到達できること（リバースプロキシ、ファイアウォール、DNS、TLSなど）が前提になります。ユーザーのブラウザ上では即時の変化はなく、次にポータルを操作した時点でログアウトが反映されるとのことです。

    登録手順はOPごとに異なります。詳細は原文をご確認ください。

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

  • Liferay PaaSでModSecurityの有用なログを出す設定の要点

    ニュースのポイント

    • ModSecurityはwebserver/LCP.jsonのLCP_WEBSERVER_MODSECURITYにOff・DetectionOnly・Onを指定して有効にする。まずDetectionOnlyで始め、チューニング後にOnへ移行することが推奨されている。独自のmodsecurity.confを置くと既定設定が置き換わるため、必要な設定をすべて含める必要がある。
    • コンテナは入れ替わり得るため、SecAuditLogは/dev/stdoutにしてLiferay Cloud Consoleへ流す。SecAuditEngineはRelevantOnlyにして警告・エラー等のみ記録し、SecAuditLogPartsからレスポンスボディを記録するEを外すとログ量を抑えられる（著者の事例）。
    • NginxのerrorログにModSecurityのMatchedメッセージが出るため、error_log /dev/stdout warnを設定する。Cloud Consoleのログ保持は30日で、長期保存にはlcp logコマンドで定期的にダウンロードする運用が紹介されている。

    編集部コメント

    記事の出発点となる設定例（SecAuditEngine RelevantOnly、SecAuditLogParts ABIJDFHZK、SecAuditLog /dev/stdout、SecDebugLogLevel 3など）が示されています。Eを外してもレスポンスボディの検査自体が止まるわけではない（SecResponseBodyAccessで制御）点は注意が必要です。

    WAFをいきなり有効化せず、まず検知のみで運用してログを確認する、という進め方はPaaS以外でも参考になります。

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