ページキャッシュについて

ページキャッシュについて詳しく紹介します。

ページキャッシュを有効にする

ページキャッシュを有効にするためには、いくつか条件があります。

  • DEBUG_MODEがオフであること
  • コンフィグ or コンフィグセットで キャッシュ設定がONであること
  • ログアウトしている時
  • 読者ユーザーがログインしている時(要設定)

コンフィグでページキャッシュを有効化

管理ページ > コンフィグ > キャッシュ機能 ページの「ページキャッシュ」にチェックをつけることで有効になります。



読者ユーザーでログイン中でもページキャッシュを有効化

通常ログインしているときはページキャッシュは有効化されませんが、読者ユーザーの場合はログインしていてもページキャッシュを有効化することができます。
たとえば、会員制サイトなどでログインしていても表示内容がそこまで変わらない場合に有用です。

有効化する方法

管理ページ > コンフィグ > キャッシュ設定 ページの「読者ユーザーの場合」にチェックをつけることで有効になります。


読者ユーザーでもキャッシュを有効化

読者ユーザーでもキャッシュを有効化

この機能を有効化すると、ログインしていてもページキャッシュが効いてしまいます。ログインしているユーザー固有の情報(マイページなど)や、 ログイン状況によって表示・非表示を切り替える箇所は、キャッシュしないように、マイページはキャッシュ設定をオフにしたり、JavaScriptで制御する対応が必要です。

ログイン状態に応じて表示・非表示を切り替える「組み込みJS」が用意されています。 ログイン状態に応じて表示・非表示を制御する

ページキャッシュ設定

ページキャッシュは、サイトの構造やサイトの更新頻度、アクセス数などによって、キャッシュの戦略が変わってきます。

設定箇所

ページキャッシュの設定は、管理ページ > コンフィグ > キャッシュ機能 で行います。
コンフィグなので、ブログ毎の設定または、コンフィグセットでの設定となります。



設定項目

ページキャッシュ

チェックをつけることにより、ページキャッシュ機能が有効化されます。

POST時のキャッシュクリア

チェックをつけることにより、エントリー保存した時やコンフィグ変更、モジュール変更などの更新系の操作(POST)をした時に、ページキャッシュをクリアをするようになります。
ただしエントリー詳細ページのキャッシュは、ここの設定にかかわらず、エントリー更新時に該当エントリーのキャッシュをクリアします。

キャッシュ有効時間

キャッシュの有効時間を秒数で設定します。この有効時間はエントリー詳細ページ以外のキャッシュ有効時間となります。

エントリーキャッシュ有効時間

エントリー詳細ページのキャッシュ有効時間を秒数で設定します。

キャッシュクリアの対象ブログ

このブログでキャッシュがクリアされた時に、他のブログのキャッシュもクリア対象にするか設定を行います。

実行ブログのみ : キャッシュクリアが実行されたブログのみのキャッシュをクリアします。

実行ブログと下階層のブログ : キャッシュクリアが実行されたブログと、そのブログの下階層ブログのキャッシュをクリアします。

実行ブログと親階層のブログ : キャッシュクリアが実行されたブログと、そのブログの親階層ブログのキャッシュをクリアします。

全ブログ : すべてのブログのキャッシュをクリアします。

サイト構造をみて対象となるブログを設定しましょう。たとえば設定ブログの情報が、そのブログのみで使われているのであれば「実行ブログのみ」で大丈夫です。
他には、設定ブログの情報が「ルートブログ」で利用されているのであれば「実行ブログと親階層のブログ」を選択しましょう。

クライアントキャッシュ設定

ブラウザに保存するキャッシュ有効時間を秒数で指定します。キャッシュヒット時はサーバーへのアクセスがないので、非常に高速にページ表示ができます。

クライアントキャッシュは、CMS側でクリアできないキャッシュとなります。有効時間が過ぎるか、エンドユーザーがブラウザのキャッシュを削除するしかありません。
なので、クライアントキャッシュに長い有効期限を設定するのはやめましょう。数分程度が推奨です。

キャッシュ戦略

ページキャッシュは設定項目も多いため、キャッシュ設定例を2つほど紹介します。

更新頻度が低い場合のページキャッシュ設定例

1週間に一回など更新頻度が少ないサイトであれば、キャッシュ有効時間を伸ばしPOST時にキャッシュをクリアするようにします。 更新頻度が少ないので、POST時のキャッシュクリアも頻繁に発生せず、キャッシュの有効時間も長いので、キャッシュヒット率もあがります。

  • ページキャッシュ: 有効
  • POST時のキャッシュクリア: 有効
  • キャッシュ有効時間: 2592000秒(30日間)
  • エントリーキャッシュ有効時間: 2592000秒(30日間)
  • キャッシュクリアの対象ブログ: サイト構成に沿って適切に設定
  • クライアントキャッシュ設定: 120秒

更新頻度が高く、アクセス数の多い場合のページキャッシュ設定例

更新頻度が高く、アクセス数の多いサイトの場合、POST時のキャッシュクリアはしないようにします。 更新頻度が高いので、その都度キャッシュをクリアしてしまうと、キャッシュのヒット率が下がってしまうからです。

またキャッシュクリアをPOST時にしてしまうと、キャッシュが一気に消え、瞬間的にキャッシュヒット率が極端に下がり、サーバーの負荷も上がってしまいます。 そこでキャッシュの有効時間を短くし、キャッシュの有効時間でばらばらにキャッシュがクリアしていくようにしています。

ただしエントリーのキャッシュ時間は長くし、エントリー更新時のみキャッシュがクリアされるようにしています。
注意点はエントリー詳細ページにエントリー情報以外の情報があると、その情報が更新されないので、JavaScriptなどでひっぱってくるなどの対応が必要です。

  • ページキャッシュ: 有効
  • POST時のキャッシュクリア: 無効
  • キャッシュ有効時間: 300秒(5分間)
  • エントリーキャッシュ有効時間: 2592000秒(30日間)
  • キャッシュクリアの対象ブログ: サイト構成に沿って適切に設定
  • クライアントキャッシュ設定: 120秒

Shoping Cart拡張アプリ アップデートのお知らせ 2025年11月


この記事では、ShoppingCart 拡張アプリ について、2025年11月17日にリリースした  Ver. 2.4.0 の内容について紹介いたします。

現在お困りの問題に該当する項目がありましたら、お早めにバージョンアップのご検討をお願いいたします。

Ver. 2.4.0 のリリースノート

Featured

  • a-blog cms 3.2 及び php 8.4 対応(a-blog cms 3.2 未満 の対応は廃止 )

  • Mypage 機能の廃止

主なリリースノート内容

ShoppingCart 拡張アプリ Ver. 2.4.0 の内容について一部紹介いたします。

a-blog cms 3.2 及び php 8.4 対応(a-blog cms 3.2 未満 の対応は廃止 )

Ver. 2.4.0 より a-blog cms Ver. 3.2.0 に対応いたしました。併せて、PHP の対応バージョンも8.1 ~ 8.4 に変更されております。

また、a-blog cms 3.2 未満 の対応は廃止いたしました。ShoppingCart 拡張アプリのアップデートの際はご注意ください。

Mypage 機能の廃止

ShoppingCart 拡張アプリに含まれていた Mypage 機能を廃止いたしました。今後は a-blog cms 標準の会員機能をご利用ください。

最後に

該当する問題がありましたら、お早めにバージョンアップのご検討をお願いいたします。また、迅速にご報告いただいたユーザーの皆さま、誠にありがとうございました。

今後もご報告いただいた内容に対して真摯に受け止め修正と改善を行ってまいります。 今後ともどうぞよろしくお願いいたします。

キャッシュドライバー

a-blog cms ではページキャッシュ、テンプレートキャッシュなどの複数のキャッシュが利用できますが、さらにキャッシュする場所や方式(ドライバー)も設定できます。

キャッシュドライバー

複数のキャッシュドライバーを用意しています。

データベースドライバー

データベース(MySQL)にキャッシュを保存します。 ある程度スピードも早く、複数台構成でもキャッシュを共有して利用できます。

ファイル キャッシュドライバー

ローカルのファイルシステムでファイルとしてキャッシュを行います。
他のAPCuやRedisなどのインメモリキャッシュに比べると低速になります。

PHPファイル キャッシュドライバー

PHPファイルとしてキャッシュします。OPcacheが有効だと高速に動作します。

メモリー キャッシュドライバー

メモリキャッシュになります。共有メモリではないので、アクセスの間だけ共有されます。

APCu キャッシュドライバー

APCu 拡張モジュールを使った、高性能な共有メモリキャッシュです。共有メモリに保存されるため、アプリケーションの性能を大幅に向上させることができます。

Redis キャッシュドライバー

Redis サーバーを使った 共有メモリキャッシュです。アプリケーションの性能を大幅に向上させることができます。複数台構成でもキャッシュを共有して利用できます。

設定変更方法

a-blog cms 設置ディレクトリに、.env ファイルを用意する必要があります。最初のパッケージに、env.txt ファイルがありますので、これを「.env」ファイルにリネームしてご利用ください。

ドライバーの変更

CACHE_xxxxxxx_DRIVER の値を変更することで、各キャッシュのキャッシュドライバーを変更することができます。
変更できる値は以下のものになっております。

  • database: データベース キャッシュドライバー
  • file: ファイル キャッシュドライバー
  • php: PHPファイル キャッシュドライバー
  • memory: メモリー キャッシュドライバー
  • apcu: APCuキャッシュドライバー
  • redis: Redis キャッシュドライバー

「コンフィグキャッシュ」「ページキャッシュ」に利用できるドライバーは下記3つのドライバーのみとなります。

  • database
  • file
  • redis

APCuを選択した場合、サーバー環境によっては、PHPプロセス毎にキャッシュがされてしまい、古いキャッシュが返ってきてしまう事があります。このような環境の場合は、他のキャッシュドライバーを選択ください。 * XSERVERの「Xアクセラレータ Ver.2」以外の場合、この環境となることを確認しています。

Webサーバーを複数台構成(プロフェッショナル以上)にする場合、キャッシュドライバーは「redis」をお勧めします。複数台で1つのキャッシュを参照でき、効率がよくなるためです。「Redis」が利用できない場合は、データベースキャッシュドライバーでもキャッシュを共有できますが、「redis」のほうがキャッシュ専用でパフォーマンスも出ますので「redis」が利用できる場合は「redis」をご利用ください。

CACHE_xxxxxxx_DRIVER には複数の値を「パイプ(|)」でつなげて設定することが出来ます。複数の値を設定した場合は、右から優先して利用できるドライバーがあったら、そのキャッシュドライバーを利用します。

CACHE_TEMPLATE_DRIVER=apcu|file

この場合、テンプレートキャッシュで、APCuが利用できる環境だとAPCuキャッシュを使用して、利用できない環境だとファイルキャッシュを使用します。

デフォルト設定

# キャッシュ設定
# Supported: apcu, php, memory, file, redis, database

# テンプレートのキャッシュをするドライバーを選択します
CACHE_TEMPLATE_DRIVER=file
CACHE_TEMPLATE_NAMESPACE=template
CACHE_TEMPLATE_LIFETIME=2678400

# フィールド情報のキャッシュをするドライバーを選択します
CACHE_FIELD_DRIVER=database
CACHE_FIELD_NAMESPACE=field
CACHE_FIELD_LIFETIME=86400

# モジュールのキャッシュをするドライバーを選択します
CACHE_MODULE_DRIVER=database
CACHE_MODULE_NAMESPACE=module
CACHE_MODULE_LIFETIME=86400

# 一時キャッシュで利用するドライバーを選択します
CACHE_TEMP_DRIVER=memory
CACHE_TEMP_NAMESPACE=temp
CACHE_TEMP_LIFETIME=10800

# コンフィグのキャッシュをするドライバーを選択します
# ページキャッシュに指定できるドライバーは、file, database, redis のみとなります。
CACHE_CONFIG_DRIVER=database
CACHE_CONFIG_NAMESPACE=config
CACHE_CONFIG_LIFETIME=2678400

# ページキャッシュをするドライバーを選択します
# ページキャッシュに指定できるドライバーは、file, database, redis のみとなります。
CACHE_PAGE_DRIVER=database
CACHE_PAGE_NAMESPACE=page

# redisのコネクション設定をします
CACHE_REDIS_HOST=
CACHE_REDIS_PASSWORD=
CACHE_REDIS_PORT=6379

Redis を利用するには、Redisサーバーの情報を設定する必要があります。
また、PHPの拡張モジュールとしてRedisが入っている必要があります。

CACHE_REDIS_HOST=
CACHE_REDIS_PASSWORD=
CACHE_REDIS_PORT=6379

a-blog cms Training Camp 2025 を開催しました


年に 1 度、 a-blog cms ユーザーが一堂に会するイベントとして開催している a-blog cms Training Camp 2025 は、おかげさまで無事終了いたしました。

昨年の開催では、「もうすぐ Ver. 3.2 が公開予定」「このような機能になります」 といった未来の展望にフォーカスした内容を中心にお届けしましたが、今年はリリースが秋となったことを受け、次の計画ではなく 実際の利用事例や成果の共有 に重きを置いた実践型セッションを多数実施いたしました。全 12 セッションという構成で、1つ 1 つはコンパクトな内容でありながら、多くの登壇者の皆さまにご協力いただき、大変充実したプログラムとなりました。

イベントは 2025年 11月 21日 (金) 13:00 〜 18:00貸し会議室 KUWAYAMA にて開催し、終了後は シルクロード 名古屋駅店 に場所を移して懇親会を実施いたしました。登壇者および参加者同士の交流も一層深まり、非常に有意義な時間となりました。

1. 実案件で失敗しない a-blog cms v3.2 へのアップデート術

宇井 陸登 さん / 有限会社アップルップル

今回の大きな変更点は、ユニット周りのCSSが従来のfloatから、現代的なFlex/Gridへと刷新されたことです。これは管理画面の使い勝手を良くし、デザインの自由度を本来の形に戻すための変更とのことです。

a-blog cms Ver. 3.2 がリリースされ、変わったところ、非推奨になったところなどを詳しく紹介がありました。実際、3.1 → 3.2 の変化は大きいのですが古い仕様のまま運用するのであれば、あまり問題なく運用は可能に作られています。

2. Web業界以外の人に、a-blog cms 3.2をおすすめしてみる(できるか?)

坂本 邦夫 さん / フォルトゥナ

いつも初心者に向けて、そしてこうなったらいいなを開発側に向けてのセッションを持ってきてくれる坂本さんの安定のお話でした。

Ver. 3.2 に合わせて全機能を精査し、ブロックエディター、監査ログ、自動アップデート、スマートフォンプレビュー の 4 点を S 評価として高く評価いただき、特に、表のコピー&ペースト対応やセキュリティ面での運用負荷軽減は、現場での実効性が高いとのコメントをいただきました。

さらに多くの関係者へ価値を届けるための改善案として、非技術者向けの短いデモ動画や、決裁者にも届く説明形式の動画の重要性についてもご提案をいただきました。ご提案を実施に繋げられるように頑張ります。

3. a-blog cmsで考えるレイアウトと文字組み

石川 寿刀 さん / Letoro* Design

a-blog cms Ver. 3.2 におけるブロックエディタと文字組み機能の検証結果が共有されました。実際のデモを通じて、1〜3 カラムの標準レイアウトは問題なく構築でき、見たまま更新 の操作性が大幅に向上していることが確認できました。

一方で、3分の1+3分の2 のような非対称分割や 4カラム構成は現状では実現が難しく、必要に応じて従来ユニットや新しいグループユニットについて組み合わせる必要がありそうとの内容でした。

4. a-blog cms cloud のサービス開始

平山 智則 さん / アルブストリクス株式会社
永富 敬千 さん / 有限会社アップルップル

今回のセッションでは、弊社の新しい取り組みとして、AWS 環境の構築から CMS 提供、運用保守までを一貫してサポートする a-blog cms cloud を発表しました。近年、信頼性や可用性の観点から AWS 環境での運用を求めるクライアントが増えており、a-blog cms を安全かつ安定した環境で利用したいというご要望も多く寄せられています。

これらのニーズに応えるため、弊社側で環境準備から継続的な保守体制までをワンストップで担う仕組みを整備しました。クライアントがインフラ面を気にすることなく、安心して Web サイトの運用に集中できる体制構築を目指しています。今後もサービスの拡充と品質向上に努めてまいります。

5. イベントサイトで今週のイベントを表示する

入交 昭 さん / HOOP Design

a-blog cms を活用したイベント機能の実装手法について共有いただきました。通常のエントリーとは異なる「時間軸」で管理する必要があるイベント情報を、今週の開始日・終了日とイベント開始日・終了日を用いてフィルタリングするアプローチが紹介されました。CMS のグローバル変数機能で週の境界を算出し、エントリーサマリーで条件抽出することで、現在から未来に向けたイベント表示が可能になります。

標準機能で対応できる範囲に加え、パートナーストアのイベントプラグインを利用することで不定期開催にも柔軟に対応可能とのことでした。現場で役立つ非常に実践的な内容で、参加者の関心も高いセッションとなりました。

6. FullCalendarを利用したイベントカレンダーの実装

小澤 琢磨 さん / 株式会社あんどぷらす

a-blog cms を活用したイベントカレンダー機能の実装事例をご紹介いただきました。イベントタイトル入力、複数イベント登録、期間設定という 3 つの要件を満たすため、標準機能の検討から FullCalendar を用いた代替実装までのプロセスが共有されました。

標準のスケジュール機能およびエントリーカレンダーモジュールでは、一部要件(期間設定や複数登録)に制約があることが確認され、開始日・終了日のカスタムフィールドを追加するアプローチを試行。しかし、表示範囲制御が難しいという課題から、FullCalendar を活用した API 連携方式へと舵を切り、全要件を満たす形でカレンダー実装が完了しました。

7. 少し変わったテーマ制作に役立ったver3.2の新機能

新 謙二 さん / 株式会社アイデアソース

a-blog cms Ver. 3.2 と htmx を活用した「スワイプ型 LP ページ」開発の取り組みが紹介されました。スマホ世代をターゲットに、YouTube ショートのような縦横のスワイプ操作を軸にした UI 構成が特徴で、中央にスマホレイアウト、左右に固定メニューや QR を配置する独自のデザインが印象的でした。

技術面では、新ブロックエディターをフル活用し、ユニットを使わずに構築。HTMX によるページ遷移のないフォーム処理や、郵便番号補完・バリデーション改善など、実務に直結する工夫も共有されました。管理機能の拡張性にも配慮されており、非常に参考度の高い内容でした。

8. a-blog cms Ver. 3.2 の V2モジュールと Twig記法を導入してみて

菅原 彩 さん / 有限会社アップルップル

Ver. 3.2 における Twig 導入と V2 モジュール の現状について報告を行いました。開発チームとしては、今後 Twig を積極的に推進していく方針である一方、従来記法の廃止予定はなく、移行を急ぐ必要はない旨が共有されました。

技術面では、テンプレート拡張子をすべて .twig に統一することはできず、管理画面用ファイルは一部 .html のまま保持する必要がある点や、V2 モジュールでは設定項目が整理され、制御の多くがテンプレート側へ移行した点が解説されました。また、セクション名やカスタムフィールド名ではスネークケースが必須となるなどの注意点も提示されました。

条件分岐の挙動改善、エラーメッセージ強化など、開発体験が大きく向上しており、次回案件での本格導入に向けて期待が高まる内容となりました。

9. Twigでパワーアップした校正オプション

田村 章吾 さん / ましじめ株式会社

Ver. 3.2 で導入された Twig フィルター機能 の実践的な活用例について共有しました。Twig テンプレートエンジンにより構成オプションの自由度が向上し、全 58 フィルターのうち約 39 種を利用できることで、より柔軟で直感的なテンプレート記述が可能になります。また、一般的なテンプレート記法であるため、AI からのサポートも得やすく、開発効率向上につながる点も大きなメリットとして紹介されました。

一方で、フィルター名と a-blog cms 標準の校正オプションの競合時には Twig が優先されるため、従来オプションを利用する場合は acms_ プレフィックスが必要となる点や、危険なタグを除外やそのまま出力する際の a-blog cms と Twig の raw・safe_html などの注意点も共有しました。独自校正オプション「読了時間算出」など拡張例も紹介され、今後の活用が期待される内容となりました。

10. 生成AIにa-blog cmsのテーマを作らせてみた

たにぐち まこと さん / H2O space

AI 統合型エディター Cursor を活用したテーマ開発の検証事例を共有しました。Cursor は VSCode をベースに開発された編集環境で、ChatGPT のような対話形式で開発依頼が行える点や、音声入力や UI 切り替え、Web リソースの取り込みなどの機能を備えています。今回は、事前知識を与えずにブログ CMS テーマの生成を依頼し、一覧ページや詳細ページ、ページネーションまで実装が進むなど一定の成果が確認できました。

一方で、スタイル未適用や一部機能の不足など、精度向上の余地も明確となりました。特に、作業前に計画を立てる プランモード の活用や、インストール全体を参照させるコンテキスト指定、ルール設定の事前準備が品質向上に有効であるという知見が得られました。

11. a-blog cmsについて質問ができるAIをgeminiのgemという機能を使って作ってみた件

三ツ石 皓太郎 さん / 株式会社ヘルツ

Gemini を活用した a-blog cms 専用 AI アシスタント構築についての発表が行われました。Gemini の強みである Google アカウントさえあれば利用できる利便性や、Google ドライブ/Gmail との高い連携性を活かし、独自のカスタムエキスパートを作成するプロセスが紹介されました。

初期段階では a-blog cms に関する回答精度に課題があったものの、カスタム指示の改善や、公式ドキュメント参照、HTMLファースト思想の追加により精度が向上。DeepResearch を使った自動リサーチも有効で、記事一覧の実装方法まで適切に回答できるレベルに到達したとのことです。AI 活用の可能性を強く感じる、非常に示唆に富んだ内容でした。

12. a-blog cms x MCP 試してみた

伊藤 淳 さん / 有限会社アップルップル

a-blog cms 向け MCPサーバー開発プロジェクト の進捗報告を行いました。MCP(Model Context Protocol)は Anthropic が 2024年11月に公開した AI と外部サービスを接続する新しいプロトコルで、弊社では CMSデータを正確に扱うための専用 MCPサーバーを Node.js で開発し、GitHub にて公開しています。NPX コマンドで実行可能で、ローカル環境のみで動作する構成です。

デモでは、Claude Desktop から CMS の実データへ直接アクセスし、ハルシネーションを抑制した正確な回答が得られることを確認しました。Cursor では、実データと Figmaデザインを組み合わせたテンプレート生成にも成功しました。今後は POST系API やマネジメント系API などの拡張に取り組み、より実践的な開発体験の向上を目指していけたらと発表がありました。

まとめ

今回の a-blog cms Training Camp 2025 では、Ver. 3.2 を活用した実践的な事例共有を中心に、現場での具体的な成果や知見を多数ご紹介いただきました。ユーザーの皆さまによるリアルな活用報告に加え、弊社としての新サービス発表・技術アップデートの進捗報告も行うことができ、CMS の可能性をさらに広げる充実したセッションとなりました。

ご登壇いただいた皆さま、ご参加くださった皆さま、本当にありがとうございました。今後も、現場で役立つ情報発信と、コミュニティの成長に貢献できる機会を継続して提供してまいります。

次回は 2026年11月20日(金) を予定(11月第3金曜日)しております。