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

Liferay図鑑

ブログ

  • 技術的負債は経営議題に：Liferay公式ブログの整理

    ニュースのポイント

    • 技術的負債は開発者だけの問題ではなく事業上の議題として扱い、責任者と資金付きの計画を置くべきだと主張している。用語は1992年にWard Cunninghamが提唱したと紹介されている。
    • 規模を示す数字として、CAST 2025レポート（17か国・47,000アプリ・100億行超）の分析で世界の技術的負債は610億人日の修復作業に相当、Deloitteの2026年調査では技術的負債がIT支出の年間21〜40%を占めるとされている。
    • 対策として、チーム外に横断的な負債のオーナーを置く、負債をコストや納期など経営が追う指標で説明する、といった点を挙げている。顧客事例として、BRE（英国建築研究所）が81サイトをLiferay DXPで9サイト（88%減）に統合した例が紹介されている。

    編集部コメント

    こちらもベンダーブログで、プラットフォーム統合やアップグレードのしやすさを解決策として紹介する販売目的のコンテンツです。数字は外部調査の引用なので、そのまま自社に当てはめず参考値として読むのが安全です。

    Liferayのアップグレードやバージョン選定を考える際の、社内説明の切り口として使えます。

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

  • AI統合が企業ITで停滞する理由：Liferay公式ブログの解説

    ニュースのポイント

    • Liferay公式ブログは、AIはシステムを壊すのではなく既存の弱点を露呈させると述べ、レガシーERPにAIを組み込んだ開発者の投稿（Reddit）を出発点にしている。
    • 引用されている調査として、Boomiの2024年レポートでは英国組織の61%がレガシーな技術的負債がAI統合を阻害していると回答。IBMの調査では、AIの不具合による損失が大企業で年間約1億4,000万ドル、その約半分がガバナンス不足に起因するとされている。
    • 提言は、ツールではなく事業成果から始める、AIを中核業務のワークフローに組み込む、規模拡大の前にガバナンスを整備する、チームをリスキリングする、の4点。レガシーを置き換えずAPIファーストでヘッドレスな統合・体験レイヤーを重ねる方針も紹介されている。

    編集部コメント

    ベンダー（Liferay）自身のブログなので、製品を解決策として紹介する文脈を含みます。数字は記事が引用する外部調査のものなので、判断材料にする際は各調査の原典も確認してください。

    権限管理や監査証跡をどこで担保するかというAI導入時の論点は、Liferayのロール・権限の仕組みを理解しておくと整理しやすくなります。

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

  • AI時代のSEO再考：Liferay VPが語る「検索は置き換わらず加わる」

    ニュースのポイント

    • Liferay VP of Digital MarketingのSebastien Edgarへのインタビュー（聞き手はChristoph Ebert）。要旨は「AIは検索を置き換えるのではなく加えている」で、ChatGPTやAI Overviewsは新たな可視性の場を追加するとされる。
    • 多くのサイトで情報系のトップファネルのトラフィックが30〜60%減少したとされる一方、そのトラフィックは元々見込み度が低く、収益は大きく落ちていない企業もあるという。
    • 効果の高いレバーとして、サイト構造と内部リンク、デジタルPRと高品質なバックリンクを挙げている。計測は順位追跡を方向性の指標とし、プロンプト追跡は結果のばらつきが大きいため単一指標に頼らないよう勧めている。

    編集部コメント

    AEO/GEO（AI検索向け最適化）を考える際の、マーケティング責任者側の見解として読める記事です。数値は原文中の主張で、出典となる調査は本文からは確認できませんでした。

    記事の公開日と著者名は原文に明記されていません。Liferayで構築したサイトのSEOでも、サイト構造と内部リンクの整理が土台になるという点は参考になります。

    出典：Liferay公式ブログ（Sebastien Edgarへのインタビュー）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • Broken Trust Report 2026：不審なサイトに75%が競合へ流出

    ニュースのポイント

    • Liferayが2025年12月に外部調査プラットフォームPollfishと実施した、米国の18歳以上の成人1,000名へのオンライン調査。75%が、サイトが安全でない・挙動が不審だと感じると同じ目的で競合サイトに切り替えると回答。
    • 71%がサイトの安定性は企業を信頼できるかの判断要因になると回答。69%が詐欺への懸念から購入を途中で断念した経験あり。47%は、利用経験のあるサイトでもブラウザの警告が出ると即離脱すると回答。
    • 記事は対策として、SSL証明書の期限管理、HSTSの導入、ドメインの一貫性、不具合発生時の原因・修正内容・現在の状態の簡潔な説明などを挙げている。

    編集部コメント

    数字はLiferay自身の調査で、対象は米国のみです。日本のユーザーにそのまま当てはまるとは限らない点に注意してください。

    とはいえ、証明書の期限切れやリダイレクトの乱れは運用側で防げる項目です。Liferay運用でも、証明書管理と外部ドメインへの遷移の見直しは確認する価値があります。

    出典：日本ライフレイ ブログ（Liferay 2026 Broken Trust Report）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • クライアント拡張を複数バーチャルインスタンスへ展開する3方式

    ニュースのポイント

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

  • Liferay Hungary、NIS2監査を自主的に完了と発表

    ニュースのポイント

    • Liferay Hungary Kft.は、NIS2監査を自主的に完了し、内部プロセスが指令とハンガリーの法的枠組みに適合していることが確認されたと発表した。
    • 確認された領域は、ガバナンスとリスク管理、インシデント管理、サプライチェーンのセキュリティ、事業継続の4つ。
    • NIS2はEU 2022/2555として定められたサイバーセキュリティ枠組みで、加盟国の国内法化期限は2024年10月17日だった。顧客・パートナーには委託先デューデリジェンスの負担軽減などの利点があるとしている。

    編集部コメント

    これはLiferay側の組織(Liferay Hungary Kft.)の監査に関する発表で、Liferay DXP製品自体の認証を示すものではありません。

    EU域内の顧客に提供する場合は、委託先評価の資料として参照できるか、自社の要件と照らして確認してください。

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

  • Liferayサポートマネージャーインタビュー：日本向けサポートの今後

    ニュースのポイント

    • インタビュー対象は、日本のお客様向けサービスとカスタマーサポート部門を統括するRegional Support Managerの軒原翼さん。IT業界経験は25年で、Sun、BEA、Oracle、VMwareを経て2024年5月にLiferayへ入社した。
    • Liferayを選んだ理由として、カルチャーとミッションへの共感を挙げている。日本支社は約50名で意思決定が速いという。
    • 現状は技術的な問題を解決するテクニカルサポートが中心。今後は個々の顧客のプロジェクトを支援する仕組みを整え、日本の顧客ニーズに合った新サービスの展開を目指すとしている。

    編集部コメント

    日本でLiferayを導入・運用する際のサポート体制の方向性が分かる記事です。新サービスの具体的な内容や時期は、記事では触れられていません。

    サポート窓口の最新情報は日本ライフレイの公式サイトで確認してください。

    出典：日本ライフレイ ブログ（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • フロントエンドCXの静的アセットが無圧縮で配信される原因と対処

    ニュースのポイント

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

  • 日本ライフレイが解説するエージェント型AIの基本と課題

    ニュースのポイント

    • エージェント型AIは、最小限の人的介入で複雑なタスクを自律的に処理し、意思決定と実行を行うAIと定義されている。生成AIはプロンプトに応じてコンテンツを作成する点で異なるとされる。
    • ガートナーの予測として、2028年までに企業向けソフトウェアの33%にエージェント型AIが組み込まれ、日常的な業務判断の15%が自律的に行われるとされている。2024年時点の組み込み率は1%未満と記載。
    • 課題として、プロンプトインジェクションなどのセキュリティ、AI監視とデータガバナンス、構造化データの不足が挙げられている。Googleの調査では、自社データの品質に自信がある企業は44%にとどまるとされる。

    編集部コメント

    記事の末尾ではLiferay DXPのAI機能と他社AIとの統合が紹介されており、概念整理を目的とした入門的な内容。数値はいずれも原文が引用する第三者の予測・調査である。

    実際の連携方法に関心がある方は、今日掲載したMCPサーバー関連の記事もあわせてご覧ください。

    出典：日本ライフレイ ブログ（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）

  • CMS MCPサーバーでAIエージェントがコンテンツ移行を支援

    ニュースのポイント

    • 新しいLiferay CMSのコンテンツ構造はすべてLiferay Objectsのオブジェクト定義で、各定義にヘッドレスAPIが自動で備わると説明されている。
    • DXP MCPサーバーは2025.Q4から含まれ、現在はベータ版のフィーチャーフラグの背後にある。/o/mcp エンドポイントでStreamable HTTPを使い、エージェントは通常ユーザーとして認証され、そのユーザーの権限の範囲でのみ動作する。
    • エージェントは、Space内のコンテンツ構造の作成、元資料からのバッチ生成、文脈に応じたカテゴリ付けができるとされ、筆者の顧客プロジェクトで運用されていると述べられている。

    編集部コメント

    筆者はPortalworks社のマネージングディレクターで、自社の取り組みを紹介する記事である点に留意したい。MCPサーバーはベータ版のフィーチャーフラグ下にあるため、本番での利用前に公式ドキュメントで状況を確認してほしい。

    同じMCPサーバーを扱う liferay.dev の記事も今日紹介しているので、あわせて読むと全体像をつかみやすい。

    出典：Liferay公式ブログ（Marc Hermann、Portalworks）（この記事は出典をもとに編集部が要約・解説したものです。詳細は原文をご確認ください。）