キャンバスが隠していたレイアウトレイヤー
0.8.0 プレビューへのコミュニティからの返信が、エージェントネイティブなデザインの背後にある本当の問いを名指ししました：キャンバスが作業の単位でなくなるなら、ユーザーはどうやってレイアウトを理解し続けるのか？
有用なコミュニティの返信は、もっと大きなボタンを求めたりしません。欠けているレイヤーを名指しします。
それが Open Design 0.8.0-preview のディスカッションの下で起きたことです。ローンチのスレッドは 2 つのシフトを主張しました：キャンバスを主要な作業単位として扱うのをやめること、そしてエージェントを第一級のデザイン作業者にすること。ある返信はその方向性に同意し、それから難しい部分を指し示しました：キャンバスが消えても、ユーザーは自信を持って編集できるようになる前に、エージェントが何を作ったのかを理解する手段を依然として必要とする、と。
その返信の中のフレーズは「レイアウト理解レイヤー（Layout Understanding Layer）」でした。これは良い名前です。なぜなら、安易な答えを拒んでいるからです。エージェントネイティブなデザインは「スクリーンショットを信じろ」を意味することはできません。それには成果物の読みやすいモデルが必要です：セクション、意図、編集可能な部分、安定した参照、そして推奨される編集の手。この記事は、その返信を真剣に受け止める試みです ── そのようなレイヤーが何を運びうるか、Open Design のどこに宿るべきか、そしてなぜそれがロードマップの約束ではなくコントリビューションの道筋なのかを素描します。
キャンバスはデザイナーに空間的な自信を与えた
Figma のキャンバスは描画のためのサーフェスであるだけではありません。説明のためのサーフェスでもあります。ズームアウトして、ページの階層を見て、フレームをクリックし、制約を検査し、レイヤーの名前を変え、作業のある一片がどこで終わり、別の一片がどこで始まるかを理解できます。
キャンバスが消えると実際に何を失うのか
その理解は、失われるまで過小評価しがちです。生成されたランディングページは、サンドボックス化されたプレビューでは正しく見えても、依然として指揮するのが難しいことがあります。問題はピクセルではありません ── 人間とエージェントの間の共有された語彙の不在です。
「ヒーローをもっと自信に満ちたものにして」が有用なのは、エージェントと人間がヒーローとは何かで合意している場合だけです。「価格セクションを締めて」がうまくいくのは、成果物がリビジョンをまたいで安定したセクションのアイデンティティを運んでいる場合だけです。それがなければ、すべての指示は指差しへと退化します：デザイナーは領域をその位置で記述し（「上から 2 番目のブロック」）、エージェントはレンダリングされた出力から推測し、次の再生成がこっそりすべての番号を振り直します。キャンバスはかつてこのコストを静かに吸収していました。あなたのために各部に名前を付け、作業している間その名前を安定に保ち、記述することなく 1 つを選ばせてくれたのです。
単位が間違っていても、その明晰さは保つ価値がある
これは #DeFigma の議論のうち、注意を要する部分です。キャンバスはエージェントネイティブなシステムにとって間違った作業の単位かもしれません ── それはエージェントがファイルを書くのではなく、人間が長方形をドラッグすることを前提としています ── が、人々がキャンバスから得ていた明晰さは依然として価値があります。間違いは、「キャンバスを捨てる」と「キャンバスが提供していた理解を捨てる」を同じ決定として扱うことです。それらは同じではありません。Open Design はその明晰さを成果物のモデルへと移さねばならず、捨ててはなりません。レイアウトレイヤーは、その移転の名前です。
Open Design はすでに正しいプリミティブを持っている
この提案が Open Design に合う理由は、プロジェクトがすでに明示的な契約を中心に構築されているからです。スキルは SKILL.md ファイルです。デザインシステムは DESIGN.md ファイルです。プラグインは open-design.json のサイドカーを追加します。システム内のどれも、リバースエンジニアリングしなければならないバイナリの塊ではありません。契約はテキストであり、テキストはエージェントも人間も読めるものです。その仕組みは 31 のスキル、72 のシステム：Open Design ライブラリの仕組みでカバーされており、製品としての議論は なぜ Open Design を製品ではなくスキルレイヤーとして作ったのかにあります。
レイアウトレイヤーは同じパターンに従うべきです。それはエージェントが読めるテキストであり、UI がレンダリングできる状態であり、別のエージェントが再利用できるメタデータであるべきです。その 3 つを同時に満たせないなら、それは間違った形です。
リポジトリの言葉で言えば、それは 3 つのサーフェスを指し示します：
| サーフェス | 何を運ぶべきか |
|---|---|
| 成果物マニフェスト | セクション、コンポーネント、アセット、生成されたファイルの安定した ID |
| プラグインスナップショット | どのスキル、デザインシステム、入力、パイプラインの段階が成果物を生んだか |
| レビュー UI / ヘッドレス出力 | レイアウトマップ、編集可能な側面、推奨される編集の意図 |
重要な制約：このレイヤーは 2 つ目の独自のキャンバスになってはなりません。避けるべき失敗の形は、新しい名前のもとで Figma のシーングラフを再構築することです ── Open Design の UI だけがレンダリングでき、アプリを離れた瞬間に死ぬ、リッチでアプリ固有の構造です。レイアウトレイヤーは代わりに、ファイルとともに移動するプレーンな成果物マップであるべきです。そうすればコントリビューターはテキストエディタでそれを読め、別のエージェントは SDK なしでそれを消費できます。
レイアウトレイヤーの実用的な形
ここに、エージェントネイティブなデザインを今より不透明でなく感じさせる最小のバージョンを示します：
- 各生成された成果物は安定した意味的な ID を得る：
hero、proof-strip、pricing、faq、final-cta。 - 各 ID は意図の文を運ぶ：「上のセクション」ではなく「製品の約束を 1 画面で説明する」。
- 各セクションは編集可能な側面を列挙する：コピー、密度、レイアウト、色、メディア、モーション、データソース。
- 各生成されたファイルは、それを生んだセクション ID にさかのぼってリンクする。
- 各レビューのパスは推奨される編集の意図を発する：「ヒーローの見出しを短くする」「価格カードのコントラストを上げる」「証言ブロックを分割する」。
- UI はこれをナビゲーターとしてレンダリングし、一方ヘッドレスのユーザーは同じ構造を JSON または Markdown として受け取る。
マニフェストが実際にどう見えるか
書き下す意義は、その構造が平凡だということにあります ── まさにそれが、プライベートな仕掛けではなく公開された契約になりうる理由です。生成されたランディングページのマニフェストはこのように読めるかもしれません：
{
"artifact": "landing/index.html",
"producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
"sections": [
{
"id": "hero",
"intent": "Explain the product promise in one screen",
"editable": ["copy", "density", "media"],
"files": ["landing/index.html#hero", "landing/hero.css"]
},
{
"id": "pricing",
"intent": "Let a visitor self-select a plan without scrolling back",
"editable": ["copy", "layout", "data-source"],
"files": ["landing/index.html#pricing", "landing/pricing.json"]
}
],
"suggestedEdits": [
{ "target": "hero", "intent": "shorten headline to one line" },
{ "target": "pricing", "intent": "drop from three plans to two" }
]
}これらのキーのどれも風変わりではありません。sections はリスト、editable は列挙、files はバック参照です。価値はスキーマの賢さにあるのではありません ── ID が再生成を生き延びるという事実にあります。だからエージェントが 2 回書き直した後でも、同じ pricing ブロックは依然 pricing なのです。
それだけで、デザイナーは「pricing を 3 プランから 2 つに変えて」と言えるようになり、コードエージェントはピクセルから推測することなく正しいファイルにパッチを当てられるようになります。指示はセクション ID に解決され、セクション ID はファイルの集合に解決され、編集は意図された場所に着地します。
なぜこれが機能リクエストではなくコントリビューションの道筋なのか
これはコミュニティにきれいなコントリビューションの道筋も与えます。コントリビューターはここで手伝うために製品を再設計する必要はありません。1 つの成果物タイプのためのマニフェストを発するスキル、編集の意図を提案するレビューのアトム、他のスキルが読めるフィールドを追加するマニフェストの拡張、あるいはセクション ID が再生成をまたいで安定に保たれることをアサートするテストケースを書けます。そのそれぞれが、1 つの出力を今より不透明でなくする、小さくマージ可能な変更です ── そしてレイヤーがプレーンテキストなので、デッキとモバイル画面に取り組む 2 人のコントリビューターは、共有されたバイナリ形式を調整する必要がありません。レイアウトレイヤーは、アプリの中に埋もれたプライベートな能力ではなく、公開された契約になります。
次に何をするか
これがあなたが取り組みたい類の問題なら、1 つの成果物を検査しやすくする小さなスキルやプラグインをコントリビュートしてください。具体的な出力から始めてください：ランディングページ、デッキ、あるいはモバイル画面。安定したセクション ID を追加し、編集可能な側面を記述し、成果物のかたわらに JSON または Markdown として発し、そしてレビュアーが検査可能なレイヤーがもたらす違いを見られるように、ビフォー/アフターの成果物とともに PR を開いてください。
これは依然として方向性であって、出荷された機能ではありません ── 今それを名指しする価値は、プリミティブがすでに存在しているので、作業が書き直しではなく追加的だということにあります。
関連する読み物
- 31 のスキル、72 のシステム：Open Design ライブラリの仕組み — この提案の下にある、現在のファイル駆動のプリミティブ
- なぜ Open Design を製品ではなくスキルレイヤーとして作ったのか — 公開された成果物の契約を可能にする製品の形
- Figma のオープンソースの代替 — 「キャンバスを捨てる」が、キャンバスを中心に据えた既存勢力に対してどこに着地するか