モジュールのGET API機能

モジュールIDが出力する変数をAPI（JSON）で取得できる機能です。 Ver.3.0から利用できます。

いままではJSONデータを取得する際に、JSON形式のテンプレートを作成して対応していましたがその手間を省くことができます（※2022年1月19日現在は、Json_2Tplモジュールでは使用できません）。

API機能を使うための初期設定

管理画面 > コンフィグ > API設定 からAPI機能の設定を行います。

API設定

API有効化

API有効化にチェックを入れる事で、API機能が有効になります。

X-API-KEY

APIを使用してHTTP通信をする際に必要になります。HTTPリクエストヘッダーに含める必要があります。
API-KEYはコンフィグセット毎に生成されるので、異なるコンフィグセットを設定しているブログが存在する場合は注意しましょう。

Allow-Origin

APIリクエストを許可するドメインを設定します。
同一オリジンでAPIを使用する際には Allow-Origin の設定は不要です。

APIの制限

APIリクエストを制限することが出来ます。何も設定しないと、 外部から想定していない使われ方をすることもあるので、出来るだけ設定しましょう。

HTTP リファラー

リクエスト元のHTTPリファラーで制限します。 ワイルドカード アスタリスク（*）が利用できるようになっています。

IP アドレス

リクエスト元のIPアドレスで制限します。 ブラウザ（JavaScript）からのリクエストはエンドユーザーによってIPアドレスが変わるので、 サーバーサイドから利用する場合に、IPアドレスで制限しましょう。

モジュールID設定

APIはモジュールIDを指定して、動作するようになります。上記の設定でAPIは有効になりましたが、利用するモジュールID側で、APIでの出力を許可するか設定する必要があります。

API出力したいモジュールIDの「条件設定」で、APIにチェックをつけてください。

モジュールIDでのAPI出力の許可

エンドポイント

エンドポイントとはAPIにアクセスするためのURIのことを言います。a-blog cmsでは URLコンテキストの末尾に /api/:module_id/ （:module_id は任意のモジュールID）を追加したURIがエンドポイントになります。

例えば、a-blog cmsを https://example.com というURLで使用していて、summary_index というモジュールIDを設定したモジュールの情報を取得する場合のエンドポイントは以下になります。

https://example.com/api/summary_index/

また、a-blog cmsの特徴であるURLコンテキストを利用することができます。
例えば、 summary_index のモジュールIDを設定したモジュールの情報のうち、カスタムフィールド「price」の値を「60000」で登録しているかつ2ページ目の情報だけを取得したい場合は以下のようなエンドポイントになります。

https://example.com/field/price/60000/page/2/api/summary_index/

API機能はモジュールIDを作成することができるすべてのモジュールに対応しています。

ハンズオン記事

以下の記事では、API機能を使って画面遷移なしでエントリーのフィルタリングをする方法を紹介しています。動画もあるので、ぜひご覧ください。

Ver. 3.2.10 & Ver. 3.1.63 リリースのお知らせ

a-blog cms Ver. 3.2.10 リリースのお知らせ

この記事では、2025年12月24日にリリースした Ver. 3.2.10 と Ver. 3.1.63 の修正内容について紹介いたします。

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

リリースノート

Ver. 3.2.10 の変更点

features

  • CMS-7455 ベンチマークモード時に Server-Timing ヘッダーを付与する機能を追加

  • CMS-6402 Form_Submit モジュールを利用したフォーム機能で自動返信メール送信前の HOOK を追加（beforeSendAutoReply）

fixed

  • CMS-7454 更新メニューの変更点のスタイル崩れを修正

  • CMS-7457 Entry_Bodyで、更新日時や投稿日時の変数が出力されない問題を修正

  • CMS-7456 Entry_Calendar モジュールで表示モードを 月表示 以外（week, days, until_days）

  • 設定すると、Undefined array key エラーが発生する問題の修正

  • CMS-7458 Entry_Body でグループユニット使用時に「続きを読む」でユニットが正しく表示さ

  • ない問題を修正

  • CMS-7441 グループユニットからテキストユニットを出し入れするとテキストユニットのデータ消えることがある問題の修正

  • CMS-7459 Ver. 3.2 よりエントリーのまとめて操作機能で確認画面に選択したエントリー一覧が表示されない問題の修正

  • CMS-7461 表側のエントリー編集画面で、左右の余白がない問題を修正

  • CMS-7462 値が空のユニットグループが選択できない問題の修正

  • CMS-7464 V2_Navigationモジュールの管理画面が表示されない問題を修正

Ver. 3.1.63 の変更点

fixed

  • CMS-7460 エントリー編集ページで、不要な管理ボックスUIが表示される問題を修正

  • CMS-7463 エントリーのユニット追加ページが表示されない問題を修正

リリースノートの補足

CMS-7455 ベンチマークモード時に Server-Timing ヘッダーを付与する機能を追加

ベンチマークモード有効時に、HTTPレスポンスの Server-Timing ヘッダーを通じてパフォーマンス情報を提供できるようにしました。これにより、API経由でもベンチマーク情報を取得できるようになります。

ブラウザの開発者ツールで確認
ブラウザの開発者ツールで確認

最後に

該当する問題がございましたら、できるだけ早めのバージョンアップをご検討ください。

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

今後ともどうぞよろしくお願いいたします。

簡単アップデート（手動）

基本的にはオンラインアップデートを推奨しておりますが、Ver. 2.x から 3.0.x のようなメジャーアップデートはオンラインアップデートに対応しておりませんので、手動でのアップデートをお願いします。

手動アップデートの際には簡単アップデートの利用を推奨しています。以前は、FTPソフトを利用して多くのファイルを上書きする必要がありましたが、現在では 簡単アップデート （バージョンアップ作業の簡略化をする PHP ファイル）を用意しております。このプログラムを利用することで、パッケージのダウンロードから、解凍、ファイルの更新、旧ファイルのバックアップまでを自動化できます。

1. 簡単アップデート のダウンロード

ダウンロードの簡単アップデート よりアップデート用のプログラムをダウンロードします。

2. update.php ファイルのアップロード

バージョンの指定

サーバーの最新版を自動で判定してダウンロードするようになっておりますが、サーバーによってはエラーになる環境もあります。もし、実行時にエラーになるような時には 13行目の # を外してアップデートしたいバージョンを個別に指定してください。

アップロード

バージョンアップをする a-blog cms が動作しているサーバーのディレクトリに1ファイル update.php ファイルのみ、a-blog cms の index.php が設置されている同じディレクトリにアップロードします。

#$ablogcmsVersion = "3.0.15";

3. update.php ファイルの実行

update.phpを設置したURL（例：http://domain.com/update.php）にブラウザからアクセスすると以下のような画面が表示されます。

アップデート作業の前に、以下のものの準備をお願いします。

  • CMS の管理者権限のユーザーID と パスワード
  • Ver. 2.x から Ver. 3.0 へのアップデートの場合には新しい license.php

アップデートの実行

アップデートの実行には、利用している MySQL のパスワードを入力してアップデート実行を行なってください。アップデート処理としては、具体的には以下の処理が自動で行われます。

  1. 変更するファイルのバックアップ
  2. サーバーのPHPのバージョンにあわせて a-blog cms のパッケージをダウンロード&解凍
  3. インストールファイルを置くべき場所への移動
  4. バックアップファイルから戻すべきファイルやディレクトリ（ 指定したテーマ、/php/ACMS/User、/php/AAPP、/private/config.system.yaml）を移動
  5. ダウンロードした必要の無いファイルの削除

※ バップアップについては、backup_年月日時分秒 の形式のディレクトリが作成されます。

以下の表示がされたら処理が完了しますので、次のステップへ進みます。

4. メンテナンスメニュー からデータベースのアップデート

サイトにアクセスし、メンテナンス画面が表示されることを確認してください。 メンテナンス画面から管理者権限の ユーザーID もしくは メールアドレスとパスワードを入力しログインします。

システムがバージョンアップの必要だと判定された際には「メンテナンスプログラムはアップデートの必要性を検出しました」と表示され「アップデート実行画面へ」のリンクが表示されます。

5. データベースの更新

セットアップ画面の[データベースの更新処理を実行]ボタンを押します。

6. セットアップディレクトリのリネーム

アップデートプログラムの実行が終了したら、FTPソフト等を利用して setup ディレクトリを推測されない名前に変更をしてください。削除しても構いませんが、場合によってインストールされている時と同様のバージョンの setup ディレクトリをアップロードする必要がある場合があります。

setup ディレクトリが存在するまではメンテナンスページが表示されます。

7. 表示確認と公開

a-blog cmsを設置しているアドレスにアクセスします。各ページの表示を確認し、問題が無ければ公開となります。 必要に応じてデバッグモードをONにすることで、各種エラーメッセージが表示されたり、キャッシュ機能が無効となるなど、動作確認のための状態となります。 サーバ上のファイル config.server.php 内の記述 「DEBUG_MODE」の値を確認の上、変更を行う場合は再度アップロードしてください。

デバッグモードON デバッグモードOFF
define('DEBUG_MODE', 1); define('DEBUG_MODE', 0);

以上でアップデートは完了です。

a-blog cms の開発リーダーになりました

こんにちは、appleple で a-blog cms の開発を担当している宇井です。
あけましておめでとうございます。2026年もよろしくお願いします。

少し改まったご報告になりますが、
本日 1 月 5 日 (月) より、a-blog cms の開発リーダーを担当することになりました。

年始のタイミングということもあり、今回はそのご挨拶と、今考えていることを少しだけ書いてみようと思います。

開発リーダーとしてのご挨拶

これまで a-blog cms を使っていただいているユーザーの皆さま、いつもありがとうございます。

立場としては「開発リーダー」という肩書きになりますが、いきなり何かが大きく変わる、というよりは、

今までやってきたことを、もう少し広い視点で考える役割になった

という感覚に近いです。

責任は増えますが、しっかり向き合っていきたいと考えています。

あらためて自己紹介を少し

早いもので、入社して 5 年目 になります。

よく「最初から CMS の開発をしていたんですか？」と聞かれるのですが、実は 入社 1 年目は社内の受託 Web 制作チーム に所属していました。

つまり当時は、

  • a-blog cms を使って

  • クライアントワークとして

  • 普通にサイトを作る側

でした。

「この設定どこだっけ？」
「この仕様、クライアントにどう説明しよう…」

今思えば、ユーザーさんとかなり近い立場で使っていたと思います。

その後、2 年目から本体の開発チームに異動し、そこから約 4 年間、a-blog cms の開発に関わってきました。

「使う側」と「作る側」の両方を経験している、というのは自分の中では結構大きくて、今後もこの感覚は大事にしたいと思っています。

これからの a-blog cms について考えていること

a-blog cms は、正直に言うともう十分すぎるほど機能があると考えています。

そのため今後は、

「とにかく新機能を増やす」という方向ではなく、

制作者も運用者もストレスなく利用できるか

そういった部分を、より良くしていきたいと考えています。

コンテンツ管理を、もっと楽にしたい

CMS の中心は、やはり コンテンツ管理 です。

  • 記事を書く

  • 更新する

  • 管理する

この一連の流れに手間を感じてしまうと、CMS を導入する意味がなくなってしまいます。

現時点では妄想段階ですが、以下のようなことができたら良いなと考えています。

  • コンテンツタイプ機能

  • 管理画面上のカスタムフィールド作成機能

  • バージョン比較機能

  • 承認フローの改善

  • ブロックエディターのカスタムブロック機能

制作者にとっても運用者にとってもストレスフリーなコンテンツ管理を目指して、基本的な部分から丁寧に見直していきたいと思っています。

管理画面の使いやすさについて

管理画面というと、運用者目線の話に聞こえますが、Web制作者の方にとっても大事だと考えています。

特に、運用者と制作者、どちらも最も触るエントリー編集画面については特に改善の余地があると考えています。

Web制作をする人が自信をもってクライアントに提供できる

そんな管理画面を目指して、UI / UX の改善も継続して進めていきます。

開発者・制作者の体験も大事にしたい

もう一つ、個人的に力を入れたいと思っているのが
開発者体験（DX） の部分です。

  • 調べたい情報が見つからない

  • 毎回同じところでつまずく

  • 本来いらない作業に時間を取られる

こういった「小さなストレス」を、
少しずつでも減らしていきたいです。

具体的には、

  • ドキュメントや学習コンテンツの整理

  • よくある質問・ハマりポイントの見える化

  • AI を使った開発補助の仕組みづくり

特に、昨今は 生成AI 時代なこともあり、マークダウン形式でのドキュメント提供や、MCPサーバー、Agent Skills など AI を使った開発をより効率的に行うための施策にも力を入れたいと考えています。

まだ構想段階のものも多いですが、「作る側が楽になること」は、結果的にユーザー体験にもつながると思っています。

Ver. 3.3 と、これから

今後は、次期バージョンとなる Ver. 3.3 のロードマップを整理していく予定です。

ユーザーとして使っていた頃の感覚を忘れずに、できるだけ皆さんと近い距離感で a-blog cms を育てていけたらと思っています。

気になる点や、「ここ正直どうなの？」といったフィードバックも、これまで通り遠慮なくいただけると嬉しいです。

少し長くなりましたが、
本年も、そして新しい体制の a-blog cms を、どうぞよろしくお願いいたします。

本件に関するお問い合わせ先

本件についてご不明点などありましたら以下のお問い合わせよりご連絡ください。

有限会社アップルップル
メールアドレス：info@a-blogcms.jp
お問い合わせフォーム：https://www.a-blogcms.jp/contact/

post include から htmx へ ― 2026 年版 a-blog cms における 部分更新のベストプラクティス

※本記事は、旧記事「post_include を次のレベルへ！ a-blog cms における htmx の活用法！」を、a-blog cms Ver. 3.2 以降の仕様に合わせて更新したものです。

2026 年、なぜ「 post include → htmx 」なのか

a-blog cms には、長年「 post include 」という部分更新の仕組みがあり、フォーム送信結果をページ遷移なしで差し替える用途で活用されてきました。

一方で、2025年9月にリリースされた a-blog cms Ver. 3.2 では、上位互換の位置付けとして htmx が「組み込み JS」に標準搭載されました。これにより、従来の「 post include 」は Ver. 3.2 から 非推奨 とされ、代替として htmx の利用が推奨されています。

ポイントは 2 つです。

  • htmx が「標準搭載」されたため、導入のハードルがほぼゼロになった

  • POST 限定の発想から脱却し、 GET を含む多様な UI を、HTML 属性中心で素直に組み立てられる

Ver. 3.2 からは「 htmx を読み込む設定」が基本的に不要

旧記事（2024 年版）では、 htm を使うために <head> で CDN から読み込む例を掲載していました。しかし Ver. 3.2 では、組み込み JS に htmx が含まれるため、HTML に hx-get や hx-post などの属性を書くだけで動作します（通常は事前設定不要）。

補足として、JavaScript で後から動的に hx- 属性を付与する等で「読み込みタイミングが不安定になる」ケースでは、事前に次の <meta> を入れて対応できます。

<meta name="acms-htmx" content="enable">

まず押さえる： post include の典型パターン（旧）

旧来の「 post include 」は、class="js-post_include" を付けたフォームをトリガーに、結果差し替えを行う設計が中心でした。

<form action="" method="POST" class="js-post_include" target="#result">
  <input type="text" name="keyword" value="">
  <input type="hidden" name="tpl" value="result.html">
  <input type="submit" name="ACMS_POST_2GET_Ajax" value="検索">
</form>

<div id="result">検索結果が表示されるエリア</div>

この仕組み自体は、今も「動く」ケースが多いものの、Ver. 3.2 以降は 非推奨 です。これから新規に作るなら、 htmx を前提に寄せておくのが安全です。

置き換え例 1：フォーム（検索）を htmx で書く

「 post include のフォーム」を、 htmx の属性に置き換えると、考え方がより一般化します。旧記事でも「置き換え例」を紹介していましたが、2026 年版では「標準搭載」を前提に、よりシンプルに扱えます。

<form
  method="POST"
  hx-post=""
  hx-target="#result"
  hx-swap="outerHTML"
>
  <input type="text" name="keyword" value="">
  <input type="hidden" name="tpl" value="result.html">
  <button type="submit">検索</button>
</form>

<div id="result">検索結果が表示されるエリア</div>

  • hx-post ：送信先（サーバー側は HTML フラグメントを返す）

  • hx-target ：差し替える領域

  • hx-swap ：差し替え方式（例では outerHTML ）

置き換え例 2：リンク（ GET ）で部分更新する

post include では「リンクから部分更新」はやりづらい（または実装が遠回り）でしたが、 htmx はリンクに hx-get を付けるだけで自然に書けます。

<a href="result.html" hx-get="result.html" hx-target="#result" hx-swap="outerHTML">
  クリックして差し替え
</a>

<div id="result">ここが更新されます</div>

この「リンクでもフォームでも同じ思想で書ける」点が、移行する価値のひとつです。

htmx の設定を追加する

標準の設定は js/config.js に設定されていますが、そこに設定を追加する際には、以下のような設定を追加します。この場合には、View Transition API を有効にする設定です。

<script>
ACMS.Ready(function() {
  ACMS.Config.htmxConfig.globalViewTransitions = true;
});
</script>

まとめ：2026 年の「部分更新」は htmx を主語にする

ここまでの整理を踏まえ、2026 年時点での a-blog cms における「部分更新」の考え方を、あらためて要点としてまとめます。

  • a-blog cms Ver. 3.2 から htmx は、組み込みJS として 標準搭載

  • その結果、 post include は Ver. 3.2 より 非推奨 、代替は htmx 推奨

  • フォームもリンクも同じ考え方で「HTML 属性中心」に組み立てられるのが強み

旧来の post include に慣れているほど、移行はスムーズです。まずは「検索フォーム」や「もっと見る」など、差し替えポイントが明確な箇所から htmx 化していくのがおすすめです。

ドキュメント

htmx | ドキュメント | a-blog cms developer
htmx | ドキュメント | a-blog cms developer
a-blog cms developer
a-blog cmsのドキュメントページ。a-blog cmsの基本のカスタマイズ方法を掲載しています。

イントロダクション

入門

コア概念

フロントエンド開発

機能ガイド

リファレンス

アップデート

拡張・カスタマイズ

ツール