デザインこそがコードである

セルラーオートマトンの論理はエージェンティック・デザインシステムをどう変えるのか。そして、ウェブ開発の未来がすでに単純なルールで書かれているかもしれない理由

デザインシステム、人工知能、計算理論が交わる場所で、いま大きな変革が起きています。自律型エージェントの時代に「デザイン」とは何を意味するのか、その理解そのものを問い直すほど根本的な変化です。

私たちは何十年ものあいだ、デザインとコードを別々の領域として扱ってきました。デザインは人間の創造性と美的判断の領域、コードはそのアイデアを実行可能な形に機械的に置き換える作業、というわけです。しかしAIエージェントがユーザーインターフェースを自律的に組み立て、デザインシステムを機械可読なインフラとして使い、セマンティックトークンからコードを生成するようになるにつれ、私たちは収束点に近づいています。それは、計算理論のずっと古い考え方と響き合うものです。

その考えとは？ デザインこそがコードである、ということです。

これは単なるキャッチフレーズではありません。デザインシステムがセルラーオートマトンのように働き、単純なルールから複雑で創発的な振る舞いが生まれる世界へ、私たちが向かっているかもしれないという認識です。何かを「デザインする」ことと「プログラミングする」ことの区別が完全に消える世界。自律型エージェントがデザインシステムを 使う だけでなく、実際に動くデザインシステムそのものに なる 世界です。

このブログ記事では、セルラーオートマトン、創発的な振る舞い、そしてエージェンティック・デザインシステムの未来との深いつながりを探ります。フォン・ノイマンの自己複製機械から今日のAIエージェント群まで、理論的な基礎をたどっていきます。

また、Drupal や最新のCMSプラットフォームが、Schema.org Blueprints や Drupal AI といったモジュールを通じてAIをどのように統合しているかを見ていきます。そして、それがデザイナーや開発者、さらにはデジタルプロダクト制作の未来にとって何を意味するのかを考えます。

セルラーオートマトンと創発の論理

単純なルールの美しさ

1970年、数学者ジョン・コンウェイは「ライフゲーム」を発表しました。これは「プレイヤーのいないゲーム」で、計算理論の中でも特によく研究されるシステムの一つとなります。そのルールは驚くほどシンプルです。

1. 生きているセルは、隣接する生きたセルが2つ未満だと死ぬ（過疎）
2. 生きているセルは、隣接する生きたセルが2つか3つなら生き残る
3. 生きているセルは、隣接する生きたセルが3つより多いと死ぬ（過密）
4. 死んでいるセルは、隣接する生きたセルがちょうど3つなら生き返る（誕生）

わずかな二値条件で表されるこの4つのルールから、驚くほど複雑な世界が立ち上がります。グライダーは無限のグリッドを横切り、オシレーターは永遠のリズムで脈打ち、ガンはパターンの流れをセル空間へ撃ち出します。そして何より注目すべきは、ライフゲームが チューリング完全であることが証明されている点です。アルゴリズムで計算できるものなら何であれ、原理的にはコンウェイのこの単純なグリッドの中で計算できるのです。

図1:コンウェイのライフゲームにおけるゴスパーのグライダー銃。このパターンはグライダーを絶え間なく生み出し、単純なルールがいかにして無限に自己持続する複雑さを生み出しうるかを示している。

これがセル・オートマトンの最初の教訓です。複雑な振る舞いに、複雑な仕組みは必要ないということ。単純なルールを基盤全体に一貫して適用するだけで、誰も明示的にプログラムしていないパターンや振る舞いが立ち現れることがあるのです。

ラングトンのループと自己複製

1984年、クリストファー・ラングトンはこの原理をさらに推し進め、人工生命の本質的な原理を示す自己複製ループ、すなわちセル・オートマトンを生み出しました。創発する複雑さを見せるコンウェイのライフゲームに対し、ラングトンのループが見せるのは創発する自己複製.

です。各ループは環状の境界で構成され、その内側にセルの状態として符号化された「ゲノム」を抱えています。このゲノムはループの中を絶えず巡り、さらに伸びた構築アームへと流れ出て、151タイムステップをかけて娘ループを作り上げます。完成すると娘は親から離れ、双方がまた複製を続けていきます。

図2:初期配置のラングトンのループ。遺伝情報はループの中を循環し、伸びていくアームを通じて娘ループの構築を指示する。

「セル・オートマトンの中で自己複製する機械が可能なら、生命そのものも機械によって実現できるかもしれない。」

――クリストファー・ラングトン「セル・オートマトンによる人工生命の研究」(1986年)

この意味するところは深遠です。ラングトンのループは、自己複製に生物の細胞のような複雑さも、フォン・ノイマンの原設計が備えていた万能構築能力も必要ないことを示しました。必要なのは次の3つだけです。

• 単純な局所ルールの集まり
• 命令を符号化する仕組み
• その命令を実行するプロセス

ルールこそが生命体そのものであり、設計こそがコードなのです。

1999年、佐山弘樹はエヴォループを発表しました。これは構造の分解可能性と表現型どうしの相互作用を取り入れた変種で、突然変異や進化的なダイナミクスを自発的に生じさせます。これらのループは、複製の最中に起こる物理的な衝突を通じて進化し、遺伝子型の変異、形態的多様性の拡大、世代を超えた複雑さの増大をもたらします。複製が固定されたままのラングトンのループとは異なり、エヴォループは外部からの介入なしに、継承可能な突然変異を示します。

ルール110と万能計算

スティーブン・ウルフラムによる初等セル・オートマトンの探究は、驚くべき発見に行き着きました。ルール110は、最も単純な1次元セル・オートマトンで考えられるわずか256通りのルールのひとつでありながら、万能計算が可能なのです。

ルール110は、あるセルとその両隣のセルがとりうる8通りの組み合わせそれぞれに対する結果を指定するだけで、完全に定義できます。それでも、このごく単純なルール(8つの二値の決定)が、万能チューリングマシンをシミュレートできるのです。

図3:ルール110のセル・オートマトン。定義は単純でありながら、ルール110はクラス4の振る舞い(完全に安定しているわけでも完全にカオスでもない複雑なパターン)を示し、チューリング完全であることが証明されています。

「万能計算を行うのに、コンピュータのCPUのようなものは必要ない。必要なのは、このささやかなルールだけだ。」

- スティーブン・ウルフラム『A New Kind of Science』

2004年、マシュー・クックは、特定の繰り返し背景パターンを持つルール110がチューリング完全であることの証明を発表しました。この証明は、ルール110が循環タグシステムをエミュレートでき、その循環タグシステムがさらに任意のチューリングマシンをエミュレートできることを示しています。88通りある基本セル・オートマトンの本質的に異なるルールのうち、チューリング完全性が直接証明されているのはルール110だけです。

ウルフラムが提唱した計算等価性原理は、さらに過激なことを示唆しています。複雑さが一定の最小限のしきい値を超えたシステムは、計算能力の点で本質的に等価だというのです。人間の脳も、気象システムも、ルール110も、ある深い意味では計算的に等価なのです。

0E0Pメタセル:真の自己複製

2018年10月、アダム・P・ガウチャーは0E0Pメタセルの構築を完成させました。これはコンウェイのライフゲームにおけるパターンで、真の自己複製が可能です。近くに既存のコピーが必要だったこれまでのメタセルとは異なり、0E0Pメタセルは自身の命令テープも含めて、ゼロから自分自身のコピーを構築できます。

この成果は人工生命における画期的な出来事です。局所的なルールだけを使って、計算基盤の上で自らを増殖させていくシステムだからです。2013年11月23日には、デイヴ・グリーンがライフゲームで、命令テープを含む自分自身の完全なコピーを作る最初のレプリケータを構築しました。コンウェイの単純な2状態オートマトンでさえ、際限のない自己複製を支えられることを示したのです。

計算基盤としてのデザインシステム

アトミックデザインからエージェンティックデザインへ

ブラッド・フロストが2013年に提唱したアトミックデザインの手法は、デザインシステムの捉え方を一変させました。インターフェースを、アトム(ボタンや入力欄などの基本要素)、モレキュール(単純な組み合わせ)、オーガニズム(複雑なUIセクション)、テンプレート(ページレイアウト)、ページ(最終的な実装)に分解することで、アトミックデザインは複雑さを管理するための階層構造を提供しました。

しかし、今振り返ると注目すべき点があります。アトミックデザインは、すでにセル・オートマトンの原理を体現していたのです。それを明確に意識していたわけではありませんが。

「デザインシステムが退屈なものであれば、デザイナーや開発者は新しいことに取り組み、新しい課題を解決する自由を得られる。退屈な部分はデザインシステムが引き受けてくれるので、デザイナーや開発者がそれを背負う必要はない。」

- Josh Clark「The Most Exciting Design Systems Are Boring」

2023年2月、Brad Frost は「Design Systems in the Time of AI」でこう書いた。

「AIは、デザインシステムの自然な利用者だ。…実際のところ、デザインシステムのコンポーネント作業の多くは、機械的で予測のつくものだ。私たちはすでに PlopJS のようなツールを使って、ライブラリ全体の形に合ったコンポーネントの雛形を一気に生成している。ありふれた定型コードの生成をAIが手伝ってくれるなら、大歓迎だ。」

- Brad Frost

デザインシステムが機械的で予測可能であるという性質こそ、セル・オートマトン的な動き方に向いている理由だ。ルールが明確で、局所的で、一貫して適用されるなら、エージェントは自律的に動ける。コンウェイのライフゲームのセルが、グライダーや振動子を生み出すのに中央のコントローラーを必要としないのと同じだ。

機械可読性という必須条件

Storybook MCP（Model Context Protocol）の取り組みは、この方向への重要な進化を示している。2025年後半に発表された Storybook MCP は、既存の Storybook 環境から得た機械可読なコンポーネントのメタデータを、AIコーディングエージェントに提供する。

重要なのは、エージェントに必要なのは生のコードでも視覚的なドキュメントでもないという点だ。必要なのは次のものだ。

• コンポーネントマニフェスト: すべてのコンポーネントについての構造化されたメタデータ。props、バリアント、デザイントークンとの対応付け、使用例などを含む
• 意味を持つ命名: 値だけでなく、エージェントに意味を伝える、意図のこもったトークン。たとえば action.primary.confirm のようなもの
• 検証ループ: テストを実行し、失敗を確認し、自ら修正する能力

「Storybook MCP は、エージェントがあなたのパターンに従い、テストに通るコードを書く手助けをする。これまでエージェントが持っていなかった2つのもの、つまり機械可読なコンポーネントのメタデータと、ミスを自己修復するための反復ループを与えてくれる。」

- Storybook チーム

Storybook MCP には自律的な修正ループが含まれている。エージェントがコンポーネントのテスト（インタラクションとアクセシビリティ）を実行し、失敗した箇所を確認して、自分でバグを直せるようになる。開発者が介入するのは、テストが通った後だけだ。プロンプトのお守りはもう要らない。

これはまさに、デザインに応用されたセル・オートマトンのアーキテクチャだ。局所的なルール（コンポーネント仕様）、隣接するものとの相互作用（コンポジションパターン）、そして反復的な更新（検証と自己修正）である。

ゲノムとしてのコンポーネントマニフェスト

コンポーネントマニフェストがどう機能するかを考えると、ラングトンのループとの比較はさらにしっくりくる。ラングトンのシステムでは、循環するセルにコード化された「ゲノム」が、新しいループを作るための指示を含んでいる。機械可読なデザインシステムでは、コンポーネントマニフェストが、インターフェースを組み立てるための指示を含んでいる。

コンポーネントマニフェストは、たとえば次のように指定できる。

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

このマニフェストは、設計仕様書であると同時に実行可能なコードでもあります。より正確に言えば、実行可能なコードを生成できる指示書です。このマニフェストを読み込むエージェントは、人間的な意味での美学やユーザー体験を理解する必要はありません。ルールに従い、制約に沿って要素を組み合わせ、有効な出力を生成できればよいのです。

YAML形式を採用するというブラッド・フロストの考えに、私も賛成です。

Drupalのコンポーネントは、すでにYAML形式を使っています。たとえば次のような形です。

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

デザインはコードそのものである。

• バリアント
• トークン
• プロパティ

• 制約(コンポーネントに追加できるかもしれません)

• スロットのルール(ほかのスロットに置けるもの、または自分のスロットに置いてよいもの)

• ルール

• 例 

• アニメーション  (使用が許可されている、または推奨されているもの)

そのうえで、動作を観察し、試してみましょう。

例: https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

環境変数としてのデザイントークン

デザイントークンは、パズルのもう一つの重要なピースです。セルオートマトンでは、セルは身近な環境、つまり隣接するセルの状態に反応します。デザインシステムでは、コンポーネントはデザイントークン、つまり見た目や振る舞いを決める文脈上の値に反応します。

最新のトークン設計では、複数のレイヤーを使います。

• コアトークン: 次のような生の値 color.blue.500: #3B82F6
• セマンティックトークン: 意図にもとづく参照 color.action.primary: color.blue.500
• コンポーネントトークン: 用途を限定した適用 button.background.primary: color.action.primary

エージェントがButtonコンポーネントを生成するとき、「primary」が青を意味することを知っている必要はありません。参照するのは button.background.primary だけで、あとはトークンシステムが正しい値に解決してくれると信頼すればよいのです。情報を持っているのは環境(トークン層)であり、コンポーネント(セル)はそれに応答するだけで十分です。

次のようなツール: Tokens Studio は、デザイントークンを、リゾルバーを備えた計算グラフとして扱うように進化してきました。リゾルバーとは、文脈に応じてどのベーストークンを使うかという意味的な判断を下すノードです。これにより、デザイントークンは静的な値から、動的でルールにもとづくシステムへと変わります。

DrupalエコシステムとAIの統合

AIをコンテンツ管理システムに統合することは、「デザインはコードである」という原則を探るうえで、まさにうってつけの実験場です。Drupalのような CMS は、構造化されたコンテンツタイプ、フィールド定義、リレーションシップ、組み合わせのルールといった中核的な概念を、すでに備えています。

こんなことを言える日が来るとは思ってもみませんでした。私にとって、これは最高峰の技術でした。

 手に入れられる究極のコンピューターのセットです。未来の『スタートレック』からやって来たような開発者たちが、コンピューターに話しかけて、代わりにプログラムを書かせるのです。

エージェントエクスペリエンス(AX)と新しいユーザー

機械のためのデザイン

2025年の初め、NetlifyのCEOであるマティアス・ビールマンは、「エージェントエクスペリエンス」(AX)という概念を提唱しました。これは、AIエージェントが製品やプラットフォームとどう関わるかに焦点を当てた、新しい分野です。

これは根本的な転換です。数十年にわたり、UX(ユーザーエクスペリエンス)は人間の認知、知覚、行動に最適化され、DX(開発者エクスペリエンス)はソフトウェアを作る人間の開発者に最適化されてきました。AXは、エージェントがデジタルシステムの主要なユーザーになりつつあることを認識するものです。そして彼らには、まったく異なるニーズがあります。

• 彼らは見た目の美しさを気にしません。必要なのは、構造化された解析可能なデータだけです
• 彼らはインターフェースを操作しません。APIを呼び出し、マニフェストを読み込みます
• 彼らは人間のようにドキュメントを読みません。必要なのは、機械が読み取れるコンテキストです
• 彼らは主観的な判断をしません。ルールと制約に従います

「AIエージェントは人間ではありません。ボタンの大きさも、文字の読みやすさも、ウェブサイトの美しい配色も、アプリの派手なアニメーションも気にしません。では、AIエージェントは何を『気にかける』のでしょうか。この問いに、今のところ明確な答えはありませんが、これからの数年でますます重要になっていくでしょう。」

- AXリサーチ

答えは、明確なルール、予測可能な振る舞い、きちんと構造化されたデータ、そして自らの行動を検証して修正できるフィードバックループです。

二つのインターフェースという課題

AXをデザインするとは、二つのインターフェースを同時に作ることです。

1. 人間からエージェントへのインターフェース: 人間がエージェントの振る舞いを見守り、承認し、編集し、導く場所。いわば「ミッションコントロール」の層です。フォームやボタンではなく、ダッシュボードや承認キューを思い浮かべてください。
2. エージェントからシステムへのインターフェース: エージェントがAPI、データベース、ツールとやり取りする場所。いわば「実務」の層です。堅牢で、しっかり文書化され、機械にとっての効率を最優先に最適化されている必要があります。

これはセルオートマトンの構造とよく似ています。そこでは二つの異なる視点が共存しています。

• ローカルな視点: 各セル(エージェント)は、すぐ隣のセルに基づく単純なルールに従います
• グローバルな視点: 複雑なパターンが現れますが、それは大きなスケールで見たときにだけ見えてきます

「エージェント体験デザイン(AX)は、エージェントにとって、そしてエージェントによる、優れた使いやすさをもたらすものでなければなりません。つまり、優れたAXは優れたユーザー体験(UX)につながります。AIエージェントが、壊れたプロセスやプロトコル、あるいはシステム間で表現が食い違っている状況に出会うと、そのタスクを実行できません。それはエージェントにとって悪い体験であり、ひいては顧客や従業員にとっても悪い体験につながります。」

- Kat Holmes、Salesforce チーフ・エクスペリエンス・オフィサー

UXからAXへ:デジタルデザインの進化

スティグマジーと間接的なコミュニケーション

群知能のなかでも特に強力な概念のひとつが、スティグマジー、つまり環境に残された痕跡を介した間接的な協調です。アリは餌の場所を直接伝え合うわけではありません。フェロモンの道しるべを残し、ほかのアリがそれをたどります。環境そのものがコミュニケーションの媒体になるのです。

エージェント型のデザインシステムでは、スティグマジーは次のような形をとります。

• 共有コンポーネントライブラリ: エージェントは、どのコンポーネントが存在し、どう使われてきたかを「見る」ことができます
• デザイントークン: デザイン上の決定を、環境の事実として表現するセマンティックな値です
• パターンドキュメント: 後続のエージェントにとってフェロモンの道しるべとなる使用例です
• テストスイート: 有効な出力の範囲を制約する検証ルールです
• Gitの履歴: エージェントが参照できる、過去の意思決定の記録です

エージェントがコンポーネントを使ってUIを生成すると、コードベースにも、ドキュメントにも、確立されたパターンにも痕跡が残ります。似たタスクに取り組む後続のエージェントはその痕跡の影響を受け、どのエージェント単体も持ち得ない、集合知のようなものが生まれます。

エージェント型デザインパターン

Andrew Ngらは、エージェント型AIシステムの四つの重要なパターンを挙げています。

1. リフレクション: AIが自らの出力を評価し、繰り返し改善します
2. ツールの利用: AIが外部のツール、API、システムとやり取りします
3. プランニング:AIはまず複雑なタスクをサブタスクに分解し、それを順番に実行していきます
4. マルチエージェント: 複数の専門エージェントが協力して、複雑なタスクに取り組みます

これらのパターンは、セルオートマトンの概念にそのまま対応します。

デザインはコードである――より深い読み解き

「デザインはコードである」が本当に意味すること

「デザインはコードである」と言うとき、私たちは同時にいくつかの主張をしています。

1. 意味的な等価性

デザイン上の決定は、適切にエンコードされれば実行可能になります。デザイントークンは単なる値ではなく、命令です。コンポーネント仕様は単なるドキュメントではなく、プログラムです。エージェントがこうした成果物を取り込むとき、デザインを実装しているだけでなく、デザインそのものを実行しているのです。

2. 生成する力

ルール110が計算可能なものをすべて計算できるように、十分に完成されたデザインシステムは、あらゆる有効なインターフェースを生成できます。システムは、有効な表現のすべてを可能性として内に含んでいます。何が立ち現れるかは、初期条件(要件)とルール(制約)だけで決まります。

3. 創発する複雑さ

最も洗練されたインターフェースは、トップダウンで設計されるのではなく、単純なルールを一貫して適用することから生まれます。よく設計されたボタンを一貫して使えば、誰もその一貫性を明示的に計画しなくても、まとまりのある視覚言語が生まれます。

4. 計算還元不可能性

デザインの結果には、実際にシステムを動かしてみなければ予測できないものがあります。エージェントが組み立てるインターフェースがどんな姿になるかは、実際に組み立てさせてみるまで分かりません。これは、ウルフラムの計算還元不可能性の原理をデザインに当てはめたものです。

5. 自己修正

複製の途中で変異するエボループのように、エージェントに対応したデザインシステムも、使われることで進化していきます。エージェントが生成したコンポーネントはライブラリの一部となり、将来のエージェントが利用します。システムは学び、適応し、成長するのです。

拡張されたセルオートマトンのメタファー

メタファーを超えて:現実の収束

しかし、これは単なるメタファーではありません。この収束は現実のものであり、今まさに起きています。

• Storybook MCP はコンポーネントライブラリを、エージェントが実行できる機械可読な命令へと変えます
• Model Context Protocol はエージェントがツールやコンテキストにアクセスする方法を標準化し、エージェンティックな処理のための普遍的な基盤をつくります
• マルチエージェント・アーキテクチャ は、アーキテクト、コーダー、レビュアーといった専門エージェントに役割を分担させます。彼らはプロトコルに従ってやり取りし、機能が分化した細胞のように振る舞います
• 自己修復ループエージェントがテストを実行し、エラーを検出し、反復できるようにします。これは、セルオートマトンが安定した構成へと進化するために用いるのと同じフィードバック機構です
• Schema.org Blueprintsはコンテンツ構造を機械可読かつ意味的に明確なものにします
• Drupal AIはAIエージェントがコンテンツを自律的に作成・変更・管理するための基盤を提供します

私たちは「デザインはコードである」を哲学的な立場として捉えているわけではありません。技術的なインフラとして構築しているのです。

示唆と今後の道筋

デザイナーにとって

デザイナーの役割は「長方形をつくる人」から「ルールを定義する人」へと変わりつつあります。Brad Frost はこう述べています。

「自分の仕事を長方形をつくることだと考えているデザイナーやデベロッパーは、大いに不安を抱くべきでしょう。しかし、自分の仕事は問題を解決することであり、そのために必要なら長方形を作ったり扱ったりもする、と考えているデザイナーやデベロッパーなら、恐れることはずっと少ないはずです。」

- Brad Frost

エージェントの時代には、デザイナーは次のことを担うようになります。

• セマンティックトークンとその関係性を定義する
• コンポジションの制約とパターンを確立する
• エージェントが満たすべき検証ルールを作る
• 創発を支配するルールを磨き、進化させていく
• 自己修正を可能にするフィードバック機構を設計する
• どのアウトプットが許容されるかを決める「適合度関数」を形づくる

これは一段高い抽象度でのデザインです。デザインそのものではなく、デザインを生み出すルールを設計するのです。セルオートマトンで、一つひとつのセルを描くのではなく、そのルールを定めるのに似ています。

デベロッパーにとって

デベロッパーはエージェントシステムのアーキテクトになります。Anthropic はこう説明しています。

「ソフトウェア開発の分野では、LLMの機能が驚くべき可能性を示してきました。その能力はコード補完から、自律的な問題解決へと進化しています。」

デベロッパーには次のことが求められます。

• エージェントとシステムの間をつなぐ機械可読なインターフェースを作る
• フィードバックループと検証の仕組みを設計する
• 創発的な振る舞いが生まれる足場を築く
• 最終的な判断者として、人間による監督を維持する
• エージェント同士が通信するためのプロトコルを定義する
• 異なるエージェントシステムをつなぐ「グルーコード」を実装する

Web開発とCMSプラットフォームにとって

Drupal のようなプラットフォームへのAIの統合は、次のような未来を指し示しています。

• コンテンツモデルがエージェントに利用しやすくなる（Schema.org のような標準を通じて）
• 編集ワークフローがエージェントに支援される（AIによる下書き作成、モデレーション、最適化を伴って）
• 検索が進化する（キーワードマッチングから、エンベディングとベクターデータベースによる意味理解へ）
• パーソナライゼーションが自律化する（エージェントがユーザーの好みを学習し、コンテンツをリアルタイムに適応させて）
• 開発が加速する（エージェントがコンポーネント、テスト、ドキュメントを生成することで）

Drupal エコシステムが、Drupal AI、Drupal Canvas、Schema.org Blueprints、そしてAIプロバイダー連携といったモジュールを通じてAIを積極的に取り入れていることは、この未来がすでに形づくられつつあることを示しています。

組織にとって

競争優位は、デザインシステムが最も「エージェント対応」している組織のものになるでしょう。エージェント対応のシステムには、次の特徴があります。

• コンポーネントの状態とバリアントを網羅している
• 意図が伝わるセマンティックな命名
• 機械可読なドキュメントとコンテキスト
• 検証とテストのインフラ
• 有効なアウトプットの範囲を限定する明確な制約
• エージェントによる利用を前提に設計されたAPI（AXファースト）
• Schema.org ファーストのコンテンツアーキテクチャ

デジタルプロダクトの未来のために

行き着く先は、いわばデジタルの生態系だ。無数のエージェントがそれぞれ局所的なルールに従って動き、誰ひとり、デザイナーも開発者も計画しなかったインターフェースが創発する。それでも全体がまとまって見えるのは、根底にあるルールが健全だからだ。

これは聞こえるほど突飛な話ではない。生物のシステムが動く仕組み、都市が育つ仕組み、市場が機能する仕組みと、まさに同じである。問われているのは、この状態に到達するかどうかではない。移行期をどう乗り切るかだ。

結論:コードは生きている

セルオートマトンを考案した博学者ジョン・フォン・ノイマンは、ある根源的な問いに突き動かされていた。自己複製に必要な最小限の複雑さとは何か? 彼が出した答え、フォン・ノイマンの万能構成器は、自己複製に生物的な仕組みは要らないことを示した。必要なのは、自らの適用方法そのものを記述したルールだけである。

それから70年を経て、同じ原理がデザインシステムにも当てはまることがわかってきた。UIの自律生成に最低限必要なのは、汎用人工知能でも人間並みの創造性でもない。エージェントが実行できる、完全で一貫した、機械可読なルールの集合である。

ラングトン・ループがセルの格子上で増殖していくとき、私たちはループが新しいループを「デザインしている」とは言わない。複製とは、ルールが生み出す結果にすぎない。それでも、自己相似なパターンが際限なく広がっていくコロニーは、紛れもなく生成的であり、ある機能的な意味で創造的だ。

AIエージェントがデザインシステムのコンポーネントからインターフェースを組み立てるとき、セマンティックトークンと構成上の制約に従う彼らも、同じようなことをしている。「創造性」が宿るのはエージェントではなく、彼らが実行するルールのほうだ。ルールを設計したのは人間だが、いまやそれは自律的に動いている。

私たちは、デジタル創造の新しい時代の入口に立っている。エージェントはすでにここにいる。プロトコルは形を成しつつある。デザインシステムは、人工生命の基盤になろうとしている。

デザインはコードである。
そしてコードは、命を宿しはじめている。

主な記事とプロジェクト

• Design Systems in the Time of AI - Brad Frost
• Storybook MCP Sneak Peek - Storybook
• Introducing AX: Why Agent Experience Matters - Mathias Biilmann
• Building Effective Agents - Anthropic

Drupal AI Resources

• Drupal AI

• Schema.org Blueprints Module

   

セルオートマトンの資料

• Conway's Game of Life Lexicon - 約1500種類の図形
• A Working Turing Machine in Game of Life
• Langton's Loops - Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online - Stephen Wolfram
• Cellular Automata - Nature of Code

計算理論、デザインシステム、人工知能、ウェブ開発が交わるところにあるアイデアを探りました。

 ここで述べた見解は、現れつつある潮流についての推測的な探究であり、確かな未来の予言ではありません。

私たちは、ループの中で動き、さらに別のループの中で他のAIエージェントとやり取りするAIエージェントを作りつつあるのだと思います。

デザインはコードである。それは、選ばれたキャンバスとルールの集合のなかで、システムが生涯のループのように循環して動いているときの話だ。