デザインシステムMCPは「目隠しエージェント」で監査する：推測させず、作らせて、型チェックする

どんな問題を解決するか / いつ使うか

デザインシステムをMCP経由でコーディングエージェントに渡しているとき。「手で試したら動いた」で済ませると、エージェントだけが当て推量で埋めている盲点が残る。7shifts（Sous Chef）の事例では、目隠し監査で38件の問題が見つかった。

関連: Claude Code × Figma MCP で清書した画面は、文脈を持たない読み取り専用の検査役に「実測値」で全数検査させる、AI向けデザインシステムはコードを正にし、FigmaはMCPで作る「鏡」にする、歴史ある大きなプロダクトでは、まずDESIGN.mdに仮置きし、次にStorybookを「唯一の正」にしてAIに部品を選ばせる

具体手順

1. 目隠し消費者パス
   エージェントに「リポジトリもStorybookサイトも見えないプロダクトエンジニア」役を命じ、MCPのツール回答だけを与える。小文字名・typo・サブコンポーネント・アイコン・間違ったストーリー名など、実エージェントがやりそうな問い合わせをさせ、その回答だけでUIを組ませる。
2. 正本照合パス
   同じ回答を、LLM向け指示・Storybookマニフェスト・コンポーネント／ストーリー／MDXのソースと突き合わせ、「検証済み」は人手で確認する。1パス目は「何を信じたか」、2パス目は「それが正しいか」。
3. ビルドとコンパイル
   MCPの出力だけでフォーム入りモーダルやデータテーブル付きページなどを組ませ、tsc（必要ならJest）で通す。読むだけでは矛盾、作らせると欠落が見える。
4. 修正のたびに同じ手順で再監査
   直したあとにも同じ方法を回す。修正側が新しいバグ（JSXの空白落ち、重複importなど）を持ち込むことがある。

よく出る失敗例（記事より）:

• Markdown表の |（ユニオン型）が列区切りとして壊れ、props表が読めない
• ストーリーが {...args} に重要なpropsを隠し、完成したコピー例にならない
• ガイドラインとprops表が矛盾（存在しないsizeなど）
• サブコンポーネントやtoast関数がインデックスされず「Not found」

教訓の要約: 出力を監査する／目隠しエージェントをテストユーザーにする／作らせてコンパイルする／ストーリーはコピー可能なAPI文書として書く／import名でインデックスする／配信まで確認する／再監査する。

注意点

• 人間向けに「だいたい分かる」ドキュメントでも、エージェント向けにはコンパイル可能な例と実在するpropsが必要。
• MCPが十分に正確になると、ドキュメント通りに動いた結果としてコンポーネント本体のバグも露呈する（監査がライブラリのテストハーネスにもなる）。
• 記事は2026-11-02公開。手順の骨子は流用できるが、ツール名・パスは自環境に合わせる。

出典

• @kgsi · 2026-11-07
• Alex Andrade「Auditing our design system MCP」 alexandrade.dev（7shifts）