article
投稿フォーマットの選び方
tiptap、markdown、html、static の四つの format と `metadata.no_layout`。同じ投稿モデルのまま、普通の記事からデザイナー納品の LP まで扱うための選び方です。
ampless の投稿（Post）は、モデルとしては一種類だけです。本文の扱い方は format で切り替えます。tiptap、markdown、html、static の四つに、metadata.no_layout を組み合わせることで、公開のしかたを五通りに分けています。
リッチエディタで書いた読み物、Markdown のドキュメント、デザイナーから届いた HTML、zip で渡された LP。中身は違っても、公開 URL は同じ slug 体系に並びます。
公開挙動を決める主な要素は次の四つです。
| 設定 | 場所 | 効果 |
|---|---|---|
format |
エディター | 本文の保存・解釈方法（tiptap / markdown / html / static） |
metadata.no_layout |
format: 'html' のときのみ表示 |
本文をそのまま返し、テーマのクロームを被せない |
metadata.cache |
auto / deep / hot |
投稿ごとのキャッシュ戦略を上書き |
status / slug / publishedAt |
エディター | 公開可否と URL |
tiptap
tiptap は、リッチテキストエディタの構造化ドキュメントとして保存する形式です。ブログ記事やお知らせを管理画面で書くなら、まずここから選ぶのがわかりやすいです。
- 見出し、リスト、リンク、画像、コード、引用、表、タスクリストに対応
- 本文は JSON ノードツリー（
{ type: 'doc', content: [...] }）として DynamoDB に保存 - 公開時は、ランタイム側でリクエストごとに HTML へ変換して描画
WYSIWYG で見た目を確かめながら書きたい場面では、tiptap が向いています。
markdown
markdown は、プレーンテキストエリアに Markdown ソースをそのまま入れる形式です。GFM（テーブル、フェンス、タスクリストなど）も有効にしています。
- 開発者向け、git push 派の運用と相性が良い
- canonical は文字列として保存し、描画時に HTML へ変換
- この記事も
format: 'markdown'で書いています
仕様説明や技術メモのように、差分を見ながら直したい文章では扱いやすい形式です。
html
html は、プレーンテキストエリアに生の HTML を貼り込む形式です。本文は サニタイズせず、書いた内容をそのまま出力 します。
- カスタム HTML やインライン
<style>/<script>を入れたい場合 - WordPress から HTML を持ち込む場合
- HTML を直接書ける editor を信頼済みプリンシパルとして扱う設計
信頼モデルの詳しい話は mcp-http-transport に書いています。
no_layout — ベア HTML
format: 'html' に metadata.no_layout: true を立てると、テーマレイアウトをかけずに本文を返します。format は html のままで、公開時のレイアウトモードだけが変わります。
<head>の完全制御、トラッキングピクセル、独自フォント、独自レイアウトを置きたいときに向く- middleware が
/<slug>リクエストを内部のベア HTML ハンドラ（/raw/<slug>）へ書き換える - Next.js のルートレイアウトも、テーマのクロームも被せない
- ブラウザの URL は通常どおり
/<slug>のまま
slug: promo
format: html
no_layout: ☑
body: <!DOCTYPE html>
<html lang="ja">
<head>
<title>Promo</title>
<style>body { ... }</style>
</head>
<body>...</body>
</html>
no_layout チェックボックスは format: 'html' のときだけ表示されます。tiptap / markdown の本文は HTML フラグメントとして扱うため、このフラグを立てても意味がありません。
static — 静的バンドル
static は、HTML / CSS / JS / 画像 / フォントなどをまとめた .zip、または複数ファイルをそのままアップロードして使う形式です。
- LP、キャンペーンページ、デザイナー納品のマイクロサイト、ほかのジェネレーターから書き出した SPA など
- ampless がブラウザ側で zip を展開し、各ファイルを S3（
public/static/<slug>/...）に並べる - 公開 URL は
/<slug>が entrypoint、/<slug>/<相対パス>が各ファイル（middleware が/static/<slug>(/...)に書き換える） - 保存し直すと、バンドル全体を置き換える。差分マージはしない
アップロード時の検証は少し厳しめです。
- 絶対パス参照（
href="/style.css"、url(/img.png)）は弾く - protocol-relative（
//cdn/foo）、パストラバーサル（../）、null バイトも弾く - macOS / Windows のメタデータ（
__MACOSX/、.DS_Store、Thumbs.db）は自動で除去
create_post / update_post では format: 'static' を受け付けません。manifest と S3 の内容がずれるのを防ぐため、バンドル管理は専用ツール（upload_static_bundle / upload_static_file / delete_static_file / commit_static_post）に寄せています。
キャッシュ戦略
metadata.cache で、投稿ごとのキャッシュ戦略を変えられます。リクエストごとに middleware が Cache-Control を組み立て、CloudFront 側に効かせます。
| 値 | 挙動 |
|---|---|
auto（デフォルト） |
直近の編集（既定 1 時間以内）は no-store、それを過ぎると 5 分キャッシュ |
deep |
常に 1 時間キャッシュ。当面動かない解説記事に向く |
hot |
常に no-store。本文をリクエストごとに計算する投稿や、頻繁に書き換える投稿向け |
この三つは、no_layout や format から独立しています。テーマレンダリングでも、no_layout でも、static でも、同じ仕組みで扱います。
選び分けの目安
| ケース | format / metadata |
|---|---|
| ブログ記事をエディタで書く | tiptap |
| ドキュメントを git で管理したい | markdown |
| WordPress から HTML を持ち込む | html |
| 独自ヘッダーやトラッキングを仕込んだ単独ページ | html + metadata.no_layout: true |
| デザイナー納品の LP やキャンペーンサイト | static |
slug は共通の名前空間です。/promo をどの方式で配信するかは、後から format や metadata を変えれば切り替えられます。最初の選択に縛られすぎなくて大丈夫です。
関連記事
- ampless の全体像 → what-is-ampless
- サーバレス構成の内訳 → serverless-stack
- MCP 経由の投稿 → mcp-http-transport