本記事では、当社のAIエージェント構築サービスで使用している、Macareux Atlas Framework の概要と実装例についてご紹介いたします。
本フレームワークが実現する最大の関心は、AIが「答えてよい範囲だけを答えること」です。Concrete CMS にはすでにログイン機能があり、ページ単位の権限設定があります。つまり、CMSは「どのコンテンツを、誰に答えてよいか」についてすでに知っているはずです。
WebサイトにAIアシスタントを導入する際、一般的にはベクトル検索やRAGの構築で対応すると思います。もちろん、多くのケースでそれは正しい選択肢ですし、弊社でもまずそれらの方法を検討します。しかし、「ユーザーによって使用して良い情報ソースが違う」というようなユースケースでは、埋め込み時点のスナップショットと実行時の ACL がずれたり、エージェントが CMS API を直接叩いて認可を再実装したりと、セキュリティ境界が曖昧になりがちです。
Macareux Atlas Framework は、その境界をはっきりさせるための CMS アダプターアーキテクチャとして開発されました。知識と認可は CMS のままにし、意図理解・再ランキング・回答生成だけを AI に任せる。アダプターは両者をつなぐ薄い HTTP 契約です。
知識は CMS に属する。理解は AI に属する。信頼は、その境界に属する。
仕様・OpenAPI・Concrete CMS 向けリファレンス実装は、GitHub の MacareuxDigital/atlas-framework で公開しています。
なぜ Atlas か
一般的な RAG は検索品質を上げやすい一方、ACL の同期・再索引・ドリフト監視のコストが大きく、権限付きコンテンツでは設計ミスが情報漏えいにつながります。Atlas は 既存の CMS 検索と権限をそのまま使い、知識をベクトルストアへ複製しない という別の選択肢を提供します。
CMS の検索機能と権限機能にすでに満足しており、あくまで追加でAI機能を付加したいという組織にとって最適な選択肢となります。
アーキテクチャの概要
認証・認可・取得は常に CMS／Adapter 側、セマンティックな理解は Core 側。Adapter が返したコンテンツだけが回答の根拠になります。公開リポジトリが定義するのは Browser → Adapter と Core → Adapter だけで、Browser ↔ Core は各プロダクトの裁量です。
エンドポイントは 3 つ
POST .../assistant/session/start
セッションの開始を担います。セッショントークンを発行します。
POST .../assistant/search-candidates
CMS内のコンテンツを検索するためのエンドポイントです。AIエージェントは、1回の回答のために複数回検索しても構いません。
POST .../assistant/feedback
会話品質のフィードバックを受け付けるためのエンドポイントです。
session/start はウィジェット用ヘッダー、Origin 許可リスト、CMS セッション Cookie、必要なら CAPTCHA を検証します。AIエージェントは、受け取ったトークンをパースも改変もせず Adapter へそのまま渡します。
AI → Adapter は共有シークレットの HMAC-SHA256（X-Atlas-Timestamp / X-Atlas-Signature）で保護します。シークレットはブラウザに出しません。エンドユーザー権限はセッショントークン、呼び出し元の正当性は HMAC、という二層です。
マシンリーダブルな定義は openapi/atlas-api.yaml にあります。
本番の実例：Concrete CMS マニュアルサイト
Concrete CMS マニュアルサイト では、この分離を次のように実装しています。
Concrete CMS には Atlas Adapter のみをインストールしています。チャットのオーケストレーションや LLM 連携は CMS サーバーには入れていません。
チャットインターフェースは Mastra で独立開発し、本番は EC2 上の Docker として動かしています。Mastra は AWS Lambda（コンテナ＋ Lambda Web Adapter）、Cloudflare Workers、Vercel（@mastra/deployer-*）なども公式サポートしているため、同じチャットを別ホスティングへ移すことも可能です。
ウィジェットは Preact で構築しており、Google Analytics のようにスクリプトの埋め込みで導入します。既存テーマを作り直さなくても、スクリプト追加とアダプター設定のみで載せられます。
-
埋め込みスクリプトがウィジェットを起動
-
ウィジェットが session/start でトークンを取得
-
発話は独立した Mastra Chat へ
-
チャットが Adapter 経由で権限付き候補を取り、回答を返す
この設計を採用すると「チャットとウィジェットを共通資産」にできるので、アダプターさえ開発すれば、チャットには何も変更を加えず、あとからCMSのみ WordPress や Drupal へ変更することすら可能です。この可搬性もAtlasフレームワークの大きな特徴です。アダプター実装の手順は docs/building-adapters.md を参照してください。
まとめ
当社は、権限管理されたコンテンツをCMSで管理したまま、セキュアにAIエージェントを導入するしくみを標準化するため、このフレームワークを公開いたしました。Concrete CMS へのAIエージェント導入はもちろん、他のCMSや Kintone, Salesforce などのビジネスツールへの導入も可能です。もし既存のチャットツールでは導入が難しいユースケースでお困りであれば、ぜひ当社のAIエージェント構築サービスをご検討ください。
