AI開発はコードを書く時代から仕様設計へ。Claude CodeとDESIGN.mdが変えるエンジニアの役割

プログラミングの終焉。僕らが書くのは「仕様」だけになる

コードを書く作業が、開発の主役から引きずり下ろされる。

AIがコードを書くのは当たり前だ。

これからは「いかにAIに正しく仕様を伝えるか」。

その設計図こそが、プロダクトの本体になる。

DESIGN.mdの登場とSpec-as-Appという概念。

これがエンジニアの日常を変える。

これから起きるパラダイムシフトの正体を解説する。

Google Labsが放った「AIのための共通言語」DESIGN.mdとは

Google Labsが、これまでクローズドな環境で使っていたDESIGN.mdの仕様をOSS化した。

ライセンスはApache 2.0だ。

これはAIコーディングエージェントに、ブランドの魂を伝えるための専用フォーマットだ。

これまで、Claude CodeやCursorといったAIツールにデザインを指示するのは苦労が伴った。

DESIGN.mdは、構造化されたデータ層と自然言語による文脈層の2層構造になっている。

構造化データ層では、バージョン情報、ブランド名、カラーパレット、タイポグラフィを定義する。

トークン参照が使える点も特徴だ。

ボタンの背景色を定義する際、カラーパレットの変数を参照できる。

一箇所変えればアプリ全体のトーンが同期する。

自然言語の文脈層では、ブランドの哲学を書く。

「このブランドは信頼性とプロフェッショナリズムを重視する」といった「振る舞いのルール」をAIが読み取る。

さらに強力なのが、同時に公開されたCLIツールだ。

lintコマンドを使えば、アクセシビリティ違反やトークンの不整合を自動でチェックできる。

diffコマンドを使えば、2つの仕様ファイルの間で何が変わったかが一目でわかる。

exportコマンドを使えば、定義したDESIGN.mdを、Tailwind CSSの設定ファイルや、W3Cの標準フォーマットであるDTCG形式に変換できる。

しんたろー：
Googleがこれをオープンにしたのは驚いた。
共通言語ができるのは歓迎だ。
これでAIとのすれ違いが減る気がする。

コードが消える。「仕様書＝アプリ」という新世界

DESIGN.mdがデザインの標準なら、ロジックの標準はどうなるのか。

ここで登場するのがSpec-as-App（仕様としてのアプリ）という考え方だ。

リポジトリには、PythonもJavaScriptも、一切の実行コードが存在しないケースがある。

あるのは、Markdownファイルだけだ。

システムは毎日動いている。

外部記事を収集し、インデックスを更新し、品質チェックを行い、キュレーションを実行する。

Claude CodeのようなAIエージェントが、Markdownに書かれた「手順」をそのまま実行しているからだ。

AIが文書を直接読み、その場で「推論」という形で実行する。

仕様書を更新すれば、システムの挙動が変わる。

実装という翻訳作業が消滅した状態だ。

この構造において、Markdownは単なるドキュメントではない。

AIという新しいランタイムのためのソースコードだ。

リポジトリのルートにあるCLAUDE.mdが、システムのエントリーポイントになる。

このSpec-as-Appパターンにはメリットがある。

1つは、データ層とロジック層が同じGit履歴に乗ること。

2つ目は、ビジネスロジックの変更が一瞬で済むこと。

しんたろー：
僕も自分の開発で、この構成を取り入れ始めてる。
以前ならシェルスクリプトで書いてたようなバッチ処理を、全部Markdownの指示書に変えた。
メンテナンスが楽で、もう元には戻れない。

開発者の役割は「AIへの指示」から「構造の設計」へ

AIが仕様を直接実行するようになると、エンジニアの仕事は変わる。

求められるのは、「AIが迷わないための構造化能力」だ。

ここで重要になるのが、「事実」と「推測」の厳密な分離だ。

AIに指示を出す際、「観測された事実」と「AIに考えてほしい推測」を一つの文書に混ぜてはいけない。

最新の知見では、この問題を解決するために3層のMarkdown構造が提唱されている。

1つ目は、VANILLA.md。対象を観察して得られた生のデータだけを記録する。

2つ目は、INTERPRETED.md。事実に基づき、AIがその意図やパターンを解釈した内容を記述する。

3つ目が、DESIGN.md。最終的に「どうあるべきか」という意思決定をまとめる。

また、ガードレールの設計も不可欠だ。

Markdown内に制約（Constraints）というセクションを設ける。

「アクセシビリティスコアは必ず90以上を維持すること」といった制約を明文化し、AIに守らせる。

コードで実装する代わりに、言葉で統治する。

しんたろー：
エンジニアの本質は「論理的な構造を作る人」だ。
使う道具がプログラミング言語からMarkdownに変わるだけ。
構造化が得意な人にとっては、面白い時代だ。

実務への影響：今すぐ僕らが始めるべきアクション

この潮流に乗るために、明日から何を変えればいいのか。

まず、プロジェクトのドキュメントを「AIが読む前提」で書き直すことだ。

プロジェクトのルートにCLAUDE.mdを置き、現在のスタック、ディレクトリ構造、命名規則を明文化する。

次に、デザインシステムの定義にDESIGN.mdを導入してみる。

Google Labsが公開したCLIツールをインストールし、自分のプロジェクトのカラーやタイポグラフィをDESIGN.mdに書き出してみる。

そして、「仕様書＝実装」というマインドセットを持つこと。

機能が「何を達成し、どんな制約があり、どんな手順で動くのか」をMarkdownで完璧に書き上げる。

そのMarkdownをAIに渡し、「これを実行可能なタスクとして処理して」と命じる。

最後に、AIの「推測」を疑う仕組みを作ること。

事実層、解釈層、決定層。

この3層構造を意識するだけで、AIとの共同開発における事故は減る。

しんたろー：
実際にこのフローで開発してみると、エンジニアの脳みそをフル回転させないと追いつかない。
AIは加速装置であって、ハンドルを握るのは依然として僕らだ。

FAQ

Q1: DESIGN.mdはFigmaの代わりになりますか？

DESIGN.mdはFigmaを置き換えるものではなく、Figmaで定義されたデザインシステムを「AIエージェントが理解可能な形式」に変換・配布するための仲介レイヤーです。

Figmaは視覚的なデザインを構築・レビューするためのツールとして最適です。一方で、AIエージェントはFigmaの複雑なキャンバスを直接理解することは困難です。そこで、Figmaで確定したデザインをDESIGN.mdという構造化されたテキスト形式に書き出すことで、Claude Codeのようなツールがブランド規則を遵守したUIコードを生成できるようになります。

Q2: Spec-as-Appで開発する場合、テストはどうすればいいですか？

Spec-as-Appでは、テストもまたMarkdownで定義し、AIエージェントに検証させます。

仕様に対する期待値をMarkdownに記述し、それをClaude Codeが実行して確認するフローに置き換わります。例えば、DESIGN.mdのlintコマンドのように、仕様に対するガードレール（制約）を記述します。コードのテストを書く代わりに、「仕様に対する制約」を記述するスキルが重要となります。

Q3: AIの推測と事実を分離するメリットは何ですか？

AIが「どこまでが確定情報で、どこからが自分の補完か」を明確に判断できるようになり、生成物の品質と一貫性が向上します。

事実と推測が混ざった文書をAIに渡すと、後続のAIプロセスがその推測を「確定した事実」と誤認し、誤った実装を積み上げてしまうリスクがあります。情報をメタデータ層（事実）と解釈層（推測）に分離することで、AIは「事実に反する推測」を避けることができ、人間も「AIが勝手に決めた部分」を容易に特定して修正できるようになります。

仕様がプロダクトになる時代を楽しもう

AI開発の最前線は、「どんなコードを書くか」という議論を超えている。

「どんな仕様を定義し、どうAIに実行させるか」。

この新しいルールを理解した者が、これからの開発をリードしていく。

DESIGN.mdを試し、Spec-as-Appの可能性を探り、自分の開発フローを再構築してみてほしい。

僕もClaude Codeと一緒に、この新しい開発の形を磨き続けていく。

また面白い発見があったら共有する。