コンテンツにスキップ

LP をAIエージェントと作って公開する

業務のデジタル化手順 /Webサイト・LP制作

制作ツールに Claude Code / Codex を繋いで作り、発注側が確認してから公開する順序を決める

工程

  1. 何を作るか決める確度 A

    構成・文言・CMS の項目と、守らせる見た目を先に決める。ここが決まらないうちに繋いでも回らない

    • DESIGN.md(Google Labs)視覚的アイデンティティをコーディングエージェントに渡す形式仕様。Apache-2.0。npm `@google/design.md` に lint / diff / export / spec の CLI がある。バージョンは alpha
  2. 制作ツール側で土台を作る確度 A

    ページ構造と CMS を用意する。エージェントが触る対象がここに載る

    • Framer Agents「Connect Claude & Codex to Framer」の項があり、Claude・Cursor・Codex との統合が案内されている
  3. エージェントを繋ぐ確度 A人が見る

    外部エージェントから何に触れるかを把握したうえで認可する

  4. 変更内容を先に報告させる確度 A人が見る

    適用してから確認するのではなく、何を変えるつもりかを言わせてから通す

  5. 発注側が受け入れてから公開する確度 A人が見る

    公開操作がエージェントから届く以上、公開の判断だけは人の側に残す

    この工程で使える製品は、この図書館ではまだ確認できていません。

  6. 公開後の更新を回す確度 B

    CMS 差し替えが中心になる。beta の仕様変更を追う担当を決める

    この工程で使える製品は、この図書館ではまだ確認できていません。

この手順の危うさは「公開まで届く」こと

Web 制作でエージェントを使う話は、たいてい作るのが速くなる話になります。この手順が扱うのはそこではありません。

Framer の公式ヘルプが、外部エージェントの対象として挙げているものを見てください。

  • Project sessions and project context
  • Page and canvas structure
  • CMS collections and CMS items
  • Code files and code components
  • Color and text styles
  • Assets and files
  • Localization data
  • Project metadata
  • Screenshots and SVG exports
  • Publishing information and publishing actions

最後の 1 行です。公開操作が入っています。

コードを書くだけでなく、サイトの中身を入れ替えて公開するところまで外部のエージェントから触れます。つまり 発注側が確認する前に公開できてしまう構造になっています。

これは 導入・受入れの工程で書いた原則——受入れテストの主体は発注側——と正面からぶつかります。だから工程 5 を独立させています。

Framer 自身が対策を書いている

公式ヘルプは 2 つ書いています。

Review changes before publishing.

Ask the External Agent to report what it plans to change before it changes anything(高影響の操作について)

2 つ目が重要です。 「変更を確認する」だけだと、変更後の状態を見ることになります。変えるつもりのものを先に言わせるなら、変える前に止められます。

これを工程 4 として独立させているのは、この 2 つが同じことではないからです。

  • 工程 4 = やる前に何をするか言わせる
  • 工程 5 = やった後に発注側が受け入れる

どちらか片方だけだと足りません。 4 だけなら宣言と実際がずれても分からず、5 だけなら壊れたものを見てから戻すことになります。

beta であること

同じヘルプが制限を明記しています。

The exact available operations depend on the project, permissions, and the current External Agents / Server API beta surface.

何ができるかは beta の現状に依存する、と公式が書いています。今日できたことが来月もできるとは限りません。

制作会社としてこれを使うなら、仕様変更を追う担当を決めてください(工程 6)。決めないまま案件に組み込むと、納品後の更新作業がある日動かなくなります。

MCP かどうかは断定しない

Framer の外部エージェント接続について、公式ヘルプは Framer Agent CLI と Server API を前提に書いており、「MCP が不要」とは書いていません。 検索結果の要約にはそう読める記述が出てきますが、ドキュメント本文では確認できませんでした。

別途、Framer のマーケットプレイスには MCP を使ってプロジェクトを AI アシスタントに繋ぐサードパーティのプラグインも存在します。公式の接続経路とプラグイン経由の MCP は別物なので、混同しないでください。MCP そのものの仕様は facts/claude-code/mcp.md にあります。

見た目を守らせるものを先に渡す(工程 1)

エージェントに作らせると、指示していないところが毎回「よくある AI のレイアウト」になります。 ページを足すたびに少しずつ違う見た目になり、後から揃え直すことになります。

これに対する形式仕様が DESIGN.md です。Google Labs が Apache-2.0 で公開しています。

A format specification for describing a visual identity to coding agents. DESIGN.md gives agents a persistent, structured understanding of a design system.

構造は 2 層です。

層中身
YAML front matter機械可読なデザイントークン
Markdown 散文なぜその値なのかと、どう当てるか

Tokens give agents exact values. Prose tells them why those values exist and how to apply them.

この 2 層構造が要点です。 色コードだけ渡しても、どこに使う色なのかは伝わりません。

トークンの区分

仕様が定めているのは 5 つです。

区分中身
ColorsCSS 形式の色
Typographyfont family / size / weight / line height / letter spacing / features / variations
Spacing寸法値、または単位なしの数値
Rounded角丸の寸法値
Componentsコンポーネント識別子とプロパティ値の対応(複合トークン)

最低限 primary カラーパレットの定義が必須です。

Sections can be omitted if they're not relevant to your project, but those present should appear in the sequence listed below.

節を省くのは可、順序を変えるのは不可という規約です。front matter の omitted フィールドで、意図的に省いた節に対する linter の警告を抑えられます。

alpha であることを必ず見ておく

Framer と同じ注意が要ります。仕様自身が書いています。

The DESIGN.md format is at version alpha. The spec, token schema, and CLI are under active development. Expect changes to the format as it matures.

さらに Components については個別に、

The components specification is actively evolving. The current structure provides intentional flexibility for domain-specific component definitions while the spec matures.

この工程とエージェント接続(工程 3)の両方が alpha です。 案件に組み込むなら、両方の仕様変更を追う担当が要ります(工程 6)。

道具

npm の @google/design.md に CLI があり、lint / diff / export / spec が用意されています。lint があることが実務では効きます——手で書いた DESIGN.md が仕様に沿っているかを機械で確かめられます。

配布されている DESIGN.md について

実在サイトを解析した DESIGN.md を集めたサードパーティのカタログが存在します(VoltAgent が運営する getdesign.md など)。この図書館ではそれらを出典にしていません。

理由は 2 つです。一部が有料で読者が中身を確認できないことと、alpha の仕様に対して作られたファイル群なので、仕様が動いたときに何が古くなったか追えないことです。使うなら lint を通してから使ってください。

案件に組み込むときに決めること

  1. 認可の範囲を誰が承認するか(工程 3)。公開操作まで含むので、制作担当の一存で繋がない
  2. エージェントに変更予告をさせる型(工程 4)。毎回言うのではなく、定型業務を1コマンドにするの形で固定する
  3. 公開ボタンを誰が押すか(工程 5)。エージェントに押させない運用にするなら、その旨を契約側にも書く
  4. beta の仕様変更を誰が追うか(工程 6)

この分野で分かっていないこと

  • 実名の導入事例が 0 件。 ツール側の機能は公式ドキュメントで確認できるが、それを使って何を作ったかの記録に辿り着けない
  • Framer 以外の制作ツールを調べていない。 STUDIO、Webflow、WordPress に同様の接続があるかは未確認
  • beta の範囲が分からない。 「現在の beta surface に依存する」とだけで、何が安定していて何が変わりうるかの一覧が無い
  • 料金と制限が不明。 Agents ページには "Start with agents for free" とあるが、無料の範囲は書かれていない
  • DESIGN.md が Framer で効くかを確認していない。 仕様はツール非依存だが、Framer のエージェント接続がこれを読む経路は公式ドキュメントに記載が無い。この 2 つを組み合わせた運用の記録は見つけられていない
  • DESIGN.md と AGENTS.md / CLAUDE.md の関係が仕様に書かれていない。 README はそれらに一切言及しておらず、単独の仕様として立っている。同じディレクトリに置いたときにどちらが読まれるかは未確認
  • 公開操作を制限する方法が分からない。 権限に依存すると書かれているが、「公開だけ外す」ができるかは確認できていない。この手順で最も埋めたい穴

この手順が跨ぐ工程

この手順が根拠にしているページ