amplesscms

article

ampless とは何か

エンジニアが TypeScript で自由にカスタマイズして、非エンジニアの編集者がポリッシュされた admin で運用する — そんな立ち位置の CMS。AWS Amplify Gen 2 を土台にしている前提と、MCP / AI エージェントをコエンジニアとして同居させる動線を辿ります。

ampless は、エンジニアがカスタマイズして使うことを前提にした CMS です。デフォルトのままでも非エンジニアの編集者がそのまま運用に乗れる作りにしてはありますが、本領は「テーマ・プラグイン・スキーマを TypeScript で書き換えながら自分のサイトを組み立てる」側にあります。土台は AWS Amplify Gen 2 上のサーバレス構成で、固定の管理サーバーは抱えません。

このサイト自体も ampless で動いています。下のスクリーンショットの紹介ホームは、my-docs というテーマで紹介サイトとドキュメントを兼ねるかたちに組んだものです。

ampless.heavymoons.net の紹介ホーム

別ドメインで動かしている ishinao.net も、同じコードベースから派生させたテーマです。土台になる投稿モデルやサーバレス構成はそのまま揃えつつ、見せ方の方向性だけはテーマ層で別物に振っています。

ishinao.net のホーム

立ち位置

ampless の主張をひとことで言うと、「エンジニア向けのカスタマイズベース CMS、ただし編集者の運用もちゃんと回る」 になります。役割の分担はおおむね次のようになります。

  • エンジニアcms.config.ts を編集し、テーマをフォークし、プラグインを npm dep として追加し、必要なら React コンポーネントや AppSync スキーマも触ります
  • 編集者(非エンジニア) — admin UI から投稿、メディア、サイト設定を扱います
  • AI(MCP 経由) — 上の両方をまたぐコエンジニアとして同居します。投稿の執筆だけではなく、テーマカスタマイズやプラグイン追加も担えます

これは、WordPress 的な「プラグインマーケットから何でも入れて非エンジニアだけで完結する」モデルとは別の路線です。プラグインは Astro integration や Next.js plugin と同じく、エンジニアが cms.config.ts で直接 import して使う npm dep という前提に振っています。

何ができるか

ブログ、プロダクト紹介、ドキュメント、社内ナレッジ、採用、イベント告知 — 用途は、投稿(Post)とタグ、テーマの三つを組み直すだけで切り替わります。投稿側は、format の四つの値(tiptap / markdown / html / static)と metadata.no_layout のフラグを掛け合わせて、五通りの公開挙動を一本の slug 体系に並べていく作りです。

format レイアウトモード 用途
tiptap テーマレイアウト リッチエディタで書く読み物
markdown テーマレイアウト git 派の開発者向け、GFM 対応
html テーマレイアウト デザイナー納品の HTML 素片
html metadata.no_layout: true <head> まで自前で組む単独ページ
static バンドル配信 LP やキャンペーン用の zip バンドル

この表でいちばん重要なのは、普通のブログ記事と、記事本文の枠に収まらないページを同じ管理画面で扱える点です。ふだんは tiptap や markdown で記事を書き、必要なときだけ html + metadata.no_layout で 1 枚 HTML のフルスクリーン作品を公開する。さらに HTML / CSS / JS / 画像をまとめた static の zip バンドルなら、複数ファイル構成のランディングページも 1 つの投稿として slug に載せられます。公開状態、slug、メディア、タグ、MCP からの更新という管理単位は記事のまま。見せ方だけを、テーマの本文レイアウトから外せます。

実例として、1470.net では 1 枚 HTML のフルスクリーンのライフゲームと、複数ファイル構成のランディングページを ampless の投稿として管理しています。前者は本文そのものを bare HTML として返し、後者は public/static/<slug>/ 以下の静的 bundle として配信する形です。どちらも管理画面や MCP から記事として扱いつつ、公開面では CloudFront の CDN キャッシュを効かせられます。普通のブログを書いているサイトの中に、たまに LP やブラウザゲームが混ざっていても、別システムを立てる必要はありません。

詳しくは post-formats を参照してください。

何ではないか

  • 任意のサードパーティプラグインを安全に動かす CMS ではありません。 v1 の trust framework(trust_level、IAM スコープ済みの Lambda、capability 宣言)は、エンジニアが審査して取り込むファーストパーティプラグインの code organization として機能しています。未審査のプラグインを自動で安全に動かすためのマーケットプレイス + ランタイムサンドボックスは、v2.0+ の探索項目で、v1.0 のコミット成果物には入っていません。
  • WordPress 互換を狙う CMS ではありません。 WXR データインポートはロードマップに残してあるものの、プラグインや Gutenberg ブロックは最初から互換対象に入れていません。
  • 複数サイトを 1 つの管理画面で束ねる CMS ではありません。 1 Amplify デプロイ = 1 サイトに固定していて、複数を並走させたいときは Amplify プロジェクトごと分ける運用になります(CDN キャッシュキーの都合上、こちらのほうが素直)。

設計上の特徴

マルチフォーマット投稿モデル

本文は、format ごとの素の形 — tiptap JSON、markdown ソース、HTML 文字列、static の manifest — のままで DynamoDB に保存します。HTML への変換はリクエスト時にテーマ側で組み立てて、できあがったレスポンスを CloudFront にキャッシュさせる流れ。事前に派生形式を生成して S3 に貯めておく、というようなパスは持っていません。投稿モデル自体は一種類のままなので、リッチエディタで書く人、Markdown で書く人、HTML を持ち込む人 — それぞれの記事が同じ slug 体系に並んでいきます。

テーマがレイアウトを担う

テーマは themes/<name>/ の形でプロジェクトに同梱します。公式テーマをまるごとコピーして themes/my-*/ に閉じ込めれば、公式側のアップデートを取り込みながら、サイトごとの色や構成だけは別軸で育てていけます。出荷時には 6 種類のテーマ(blog / corporate / dads / docs / landing / minimal)が入っていて、切り替えは管理画面から行います。再デプロイは不要です。

プラグインは npm dep として cms.config.ts から

プラグインは Astro integration や Next.js plugin と同じく、cms.config.tsplugins 配列に直接 import して並べる npm dep です。動的インストールはランタイムからは持たず、エンジニアがインストール前に各 dep を審査する前提に振っています。出荷時には SEO / RSS / Webhook といったコア寄りに加え、GA4 / GTM / Plausible(Analytics)、Cookie consent、Reading time、Schema JSON-LD、YouTube / X embed といった面のプラグインが揃っているので、まずはこの中から組み合わせて、足りないものを自前で書き足していく流れになります。

MCP 経由の AI コエンジニア参加

管理 UI が叩いているのと同じ AppSync スキーマを、MCP HTTP ハンドラも IAM (SigV4) で叩いています。アクセストークン(amk_...)の保管はハッシュ化された状態で、認可境界自体は Lambda の IAM ロールに置いてあります。トークンを持っていること = admin 相当の CMS アクセス、というモデルです。Claude / Cursor / Claude Code などの MCP 対応エージェントを、投稿の執筆だけではなく、テーマカスタマイズやプラグイン追加までを担うコエンジニアとして参加させられる、というのが他の CMS と大きく違うところです。この記事自体も、ここから投入しました。

trust framework はファーストパーティの code organization

プラグインは trust_level(untrusted / trusted)ごとに別々の Lambda 関数で動かし、IAM ポリシーで権限を絞ります。secretSettings を宣言したプラグインは trust_level: 'trusted' でないと definePlugin() 時に弾く、といった narrow hard gate も入っていますが、これらはエンジニアが審査した上で取り込むファーストパーティプラグインを整理するための仕組みです。WASM や V8 isolate のような marketplace-grade sandbox は v2.0+ の探索項目で、v1 ではコミットしていません。

リリース段階

ampless は alpha → beta → RC → stable の 4 段階で進めていて、いまは beta に入りました。

  • alpha — 完了。クローズドリポジトリでドッグフード駆動の開発を進めた段階
  • beta(現在) — リポジトリは GitHub で公開、npm パッケージは @beta dist-tag で配布。破壊的変更はまだあり得ます(changesets で明示)
  • RC — feature-complete、破壊的変更なし
  • stable (v1.0) — ampless 自身の紹介ページ(このサイト)と同時ローンチ

いま試す場合は npx create-ampless@beta を使います(@latest は v1.0 stable 用に予約)。具体的なセットアップ手順は getting-started を参照してください。

関連記事

ampless とは何か