アイデアをコードにする速度は、もう大きな問題ではなくなりました。AIエージェントに要望を渡せば、会議が終わる前に画面が動くこともあります。時間がかかるのは、その一つ前です。何を作るのか、誰が使うのか、どこまでできれば完了なのか。ここが曖昧だと、エージェントは説明されなかった部分を自分なりに補います。

コードは間違えばエラーになります。企画とデザインは、間違っていてもそれらしく動いてしまいます。解いている課題が違う、既存サービスと雰囲気が合わない、判断の根拠が残っていない。こうしたズレは、実装が進んだ後に見つかるほど厄介です。

ここで取り上げる6つは、同じ用途のSaaSを比べたランキングではありません。コーディングエージェントの周りで、質問を増やすもの、判断を文書に残すもの、デザインルールを渡すもの、実装部品を探すものです。2026年8月7日時点の公式リポジトリとドキュメントを読み比べ、役割の違いを確認しました。同じ条件で性能を測ったベンチマーク記事ではありません。

巨人の肩は借りる。ただし全部を背負わない

ユーザーインタビュー、要求仕様、アーキテクチャ文書、デザインシステムは、誰かが長い時間をかけて失敗を減らしてきた結果です。それをAIエージェントが読める形にする試みには意味があります。だからといって、企画用と書かれたツールをすべて入れる必要はありません。

まず、足りないものを三つの層に分けます。

今、足りないもの 候補 作業後に残すもの
質問、範囲、実行順序 Superpowers、Spec Kit、BMAD 設計案、仕様、タスク、レビューの節目
共通の見た目と禁止事項 DESIGN.md、taste-skill 色、書体、余白、情報密度、避ける表現
プロジェクト内で直せる部品 shadcn/ui MCP エージェントが検索・導入し、手元で変更できるコード

多くの案件は、企画系を一つ、デザイン系を一つ選べば始められます。追加するのは、今の組み合わせでは解けない調整コストが実際に出てからで十分です。

曖昧なアイデアを作業可能な形にする3つ

1. Superpowers：書き始める前に、エージェントを一度止める

Superpowersは、エージェント用スキルとして配布される開発方法論です。公式の流れは「先に質問する」だけではありません。brainstormingで依頼を絞り、worktreeで変更を分け、計画を小さな作業にし、テストとレビューまでつなぎます。

たとえば「ダークモードを入れて」という一文を、そのままコードにしないために使えます。誰が必要としているのか、既存テーマのどこを守るのか、完了条件は何か、どの画面で確認するのかを先に決める。頭の中には案があるのに、まだ文書がない場面と相性がいい仕組みです。

一方、表記を一文字直すだけの変更に全部の手順を回すのは過剰です。複数エージェントを動かせば、トークンだけでなく人が読む時間も増えます。設計判断が必要な変更と機械的な修正を分ける責任は、人に残ります。

Superpowersの公式GitHubリポジトリ

質問、計画、テスト、レビューを一つの作業習慣としてまとめています。画面：公式GitHubリポジトリ。

2. GitHub Spec Kit：要求からタスクまで、変更の跡を残す

Spec KitはGitHubが公開するspec-driven developmentのツールキットです。中心になるのはSpecify、Plan、Tasks、Implementです。案件に応じてConstitutionで変えない原則を定め、Clarify、Checklist、Analyzeを挟めます。固定された「5段階メソッド」と見るより、判断のつながりを文書で追う仕組みと考えた方が正確です。

途中で要件が変わったとき、この跡が効きます。コードだけを直すのではなく、どの要求、計画、タスクリストまで戻るべきかを特定できます。新規プロダクト、複数人で共有する開発、後で説明責任が必要になる案件に向きます。

既存サービスの小さな修正には重いこともあります。コードの確認より文書の更新に時間がかかるなら、手段と目的が逆転しています。その場合はOpenSpecのような軽い仕様ツールか、短い作業メモで十分です。

GitHub Spec Kitの公式リポジトリ

原則、要求、計画、タスクを分け、変更がどこまで影響するかを追えるようにします。画面：公式GitHubリポジトリ。

3. BMAD Method：一人では抜けやすい視点を役割で補う

BMADは、分析、PM、アーキテクト、開発、QAといった役割にプロダクトの問いを分けます。公式の方法は、任意のAnalysisからPlanning、Solutioning、Implementationへ進みます。範囲の狭い変更にはQuick Flowも用意されています。

価値があるのは「AIチーム」を演出することではありません。一人で考えると抜けやすい問いを、役割の違いで表に出す点です。分析役は課題と対象者を疑い、PMは範囲と受け入れ条件を確認し、アーキテクトは制約を出し、QAは失敗の仕方を聞きます。関係者が多い案件では、この視点の切り替えが効きます。

当然、負担も増えます。複数のエージェントが同じ文書を読み直し、さらに文書を作り、トークンを使います。インストールが一行で終わっても、運用まで軽いわけではありません。作る文書がプロダクトより大きくなり始めたら、Quick Flowに落とすか、もっと小さな企画手順へ戻すべきです。

BMAD Methodの公式GitHubリポジトリ

プロダクト上の問いを役割とフェーズに分ける方法です。画面：公式GitHubリポジトリ。

見た目の基準と実装をつなぐ3つ

企画文書は「何を、なぜ作るか」を決めます。次の画面をエージェントが作るとき、見た目と振る舞いを同じ方向に保つには、別の情報が必要です。生成されたUIが似たものになりやすいのは、ブランドの言葉、情報密度、インタラクション、避けるべき表現が渡されていないからです。

4. DESIGN.md：エージェントが読み直せるデザインの前提

Google LabsのDESIGN.mdは、デザインアイデンティティをエージェントが読めるファイルに保存するalpha段階の形式です。YAML frontmatterには色、書体、余白などの構造化した値を置き、Markdown本文には採用理由、背景、境界を書けます。

利点は、画面を作るたびに同じ説明を繰り返さなくて済むことです。エージェントは一つのファイルに戻り、判断を同じ基準と照らし合わせられます。ただし、ファイルがセンスを作るわけではありません。どのコントラストや温度感がサービスに合うかは、人が決める必要があります。alphaという表示どおり、仕様や周辺ツールが変わる可能性も見ておくべきです。

Google Labs DESIGN.mdの公式リポジトリ

視覚的な値と、その値を選んだ理由を同じファイルに残します。画面：Google Labs公式リポジトリ。

5. shadcn/ui MCP：部品を一から描かず、必要なものを探す

shadcn/ui MCP Serverは、AIアシスタントをコンポーネントレジストリにつなぎます。エージェントは利用できる部品を一覧し、特定のコンポーネントを検索し、そのコードをプロジェクトへ導入できます。これは部品の調達経路であって、アートディレクターではありません。

状態や操作が整理されたコンポーネントを土台にでき、コードがアプリ側へ入るため後から直しやすいのが利点です。ただし、初期状態の部品を並べるだけでは、他のshadcnベースのサイトと似てきます。DESIGN.mdがルールを決め、MCPはルールに合わせて調整する材料を運ぶ。この順序を逆にしない方がいいでしょう。

shadcn/ui MCPの公式ドキュメント

設定したレジストリから、コンポーネントを検索・導入できるMCP Serverです。画面：shadcn/ui公式ドキュメント。

6. taste-skill：ありがちな生成UIを、作る前に止める

taste-skillは、コーディングエージェント向けのフロントエンド設計指針をまとめたポータブルなスキルです。何でも中央揃えにする、同じ形のカードを並べる、根拠のない数字をheroに置く、単調な配色にする、役割のない動きを足す。生成UIで繰り返される癖に名前を付け、先に避けるよう指示します。visual densityやmotion intensityを数値で指定する考え方も含まれます。

「安っぽく見えるから直して」という曖昧なレビューより、禁止事項を先に渡す方が修正は少なくて済みます。ただし、これは客観的なデザイン規格ではありません。v2はexperimentalと明記され、禁止事項には作者の好みも入っています。セリフ体を意図的に使うブランドなら、セリフ見出しを避ける規則は外すべきです。色を一つ変えるだけの作業に、ここまでの統制も要りません。

taste-skillの公式GitHubリポジトリ

完成品の質を保証する規格ではなく、エージェントに渡す判断の補助線です。画面：公式GitHubリポジトリ。

組み合わせるなら、この程度から

導入メモを書くなら、私は次の組み合わせから始めます。

状況 最初の組み合わせ 理由
アイデアだけあり、文書がない Superpowers + DESIGN.md 質問で曖昧さを減らし、最初のデザインルールを一つのファイルに残す
チームで新規プロダクトを作る Spec Kit + DESIGN.md + shadcn/ui MCP 要求、デザイン、部品調達までの流れが見える
複数のレビュー役が必要な案件 BMAD + DESIGN.md、その後taste-skill 早い段階で視点を増やし、実装後半で見た目の癖を確認する
既存プロダクトの一機能 企画系を一つ + 既存デザインシステム 変更理由だけ残し、二つ目の運用方式を持ち込まない

ツールを増やすほど、文書同士の食い違いも増えます。Spec KitのConstitution、BMADの企画文書、Superpowersの設計案が同時に「最新版」を名乗ることもあります。AIエージェントはその矛盾を安定して解けません。原則の正本を一つ、実行の正本を一つに絞る必要があります。

導入前に確認する4点

  1. 欠けている層を一つ言う。 質問、判断記録、デザインルール、コンポーネントのどれか。依頼自体が曖昧なのにMCP Serverを増やしても解決しません。
  2. 正本を決める。 文書が食い違ったとき、Constitution、DESIGN.md、別の仕様書のどれが優先されるかを明記します。
  3. 元に戻せる変更で試す。 登録フォーム一つで確かめる方が、トップページ全体を作り直すより判断しやすいものです。
  4. 人が読む時間も数える。 エージェントが、チームで確認できない量の文書を作るなら、作業は軽くなっていません。

どのツールも、誰のためのプロダクトか、なぜその人が使うのかまでは決めてくれません。できるのは、頭の中だけにあった前提を、質問、ファイル、ルール、部品に変え、人が確認できるようにすることです。それだけでも、実装が進んでから方向違いに気づくよりはずっとましです。

出発点は、結果を使う人です。誰が、何を済ませたくて、どこで失敗すると困るのか。この三行がないままでは、6つの道具を精密に使っても、違う問題をきれいに解くだけです。

参考にした資料