コーディングエージェントのUI実装精度を劇的に高める「構造化」の技術

「コーディングエージェントにUI実装を任せたら、デザインシステムを無視したスパゲッティコードが生成された」。この絶望的な経験は、現代のフロントエンドエンジニアなら一度は通る道ではないだろうか。MOSH社が直面した課題もまさにこれだ。デザインデータはFigma、ガイドラインはNotion、コードはStorybookという「情報の分断」が、AIにとっての最大のノイズ源となっている。AIは文脈を理解する能力に長けているが、それはあくまで「与えられた情報が整理されている」ことが前提だ。情報の置き場所がバラバラであれば、エージェントは推論という名の「当てずっぽう」を繰り返し、結果としてプロダクトの整合性を破壊するコードを吐き出す。

MOSHの事例が極めて示唆に富んでいるのは、彼らがAIの能力を過信せず、むしろ「AIが迷わないための環境整備」に徹底的にリソースを割いた点にある。具体的には、StorybookのJSDocにFigmaとNotionのURLを埋め込むという、極めて泥臭い作業を断行した。これは単なるリンク集ではない。MCP（Model Context Protocol）を介してエージェントがコンポーネントの定義を参照する際、その「正解」へのポインタを明示的に与えるという、エンジニアリングの基本に立ち返ったアプローチだ。我々がコードレビューで「このコンポーネントの仕様はどこにある？」と問うように、AIにもその地図を渡さなければならない。この「情報の紐付け」こそが、AI生成の精度を底上げするための第一歩であると私は確信している。

さらに、実装とデザインの乖離という、多くの組織が抱える「負の遺産」に対しても、彼らは正面から向き合っている。AngularからReactへの移行期にshadcn/uiを採用し、デザインが後追いで定義されたことで生じた「ハックせざるを得ない現場」の苦悩は、痛いほど理解できる。しかし、そこで安易にAIに丸投げするのではなく、design-contextやdesign-reviewといった「Agent Skill」を定義し、AIに「実装方針の提案」と「ガイドラインに基づくレビュー」という役割を与えた点は特筆すべきだ。AIを単なるコード生成機としてではなく、デザインシステムの番人として機能させる。この視点の転換こそが、AI時代の開発組織が持つべき生存戦略ではないだろうか。

AIの生成精度を上げるために最も効果的なのは、実は「自由度を奪うこと」である。MOSHが採用したLinterのカスタムルール（GritQL）による制約は、まさにこの真理を突いている。例えば、Badgeコンポーネントにおいて「classNameでのbg-*指定を禁止し、専用Propsを強制する」といったルールは、AIに対して「このコンポーネントをどう使うべきか」という明確な境界線を引く行為だ。AIは往々にして、Tailwind CSSのユーティリティクラスを無限に組み合わせるという「悪魔の誘惑」に負け、デザインシステムを破壊する。これをCIレベルで機械的に弾くことで、AIの生成物に対する信頼性を担保している。

また、よくあるレイアウトを自動生成する仕組みとしてPlopを用いた「add-route」コマンドを導入した点も非常に賢い。これは、AIにゼロから画面を構築させるのではなく、あらかじめ定義された「正解のテンプレート」を複製させるというアプローチだ。shadcn/uiの思想を応用し、テンプレートを複製した後は各ページが所有権を持つことで、柔軟性と保守性を両立させている。この「テンプレート駆動開発」は、AIのハルシネーションを物理的に封じ込めるための強力な防波堤となる。AIに「創造」させるのではなく、我々が定義した「型」を「適用」させる。この主従関係を明確にすることが、実務におけるAI活用の鍵だ。

以下に、MOSHが導入した主な制約ルールの一部を整理する。これらは単なる制限ではなく、デザインシステムをコードとして強制力を持つ形で実装するための「契約」である。

これらのルールを導入することで、AIは「何をしてはいけないか」を学習し、結果として「何をすべきか」という最適解に収束していく。我々エンジニアが明日から取り組むべきは、AIを賢くすることではなく、AIが間違えようのない「制約の檻」を設計することだ。あなたのプロジェクトのコードベースには、AIが迷い込む余地がどれだけ残されているだろうか？その余地こそが、技術的負債の温床になることを忘れてはならない。

MOSHの取り組みを俯瞰して感じるのは、AI時代になればなるほど「設計者の役割」が重要になるという逆説的な事実だ。AIはコードを書く速度を劇的に向上させるが、そのコードが「正しいか」を判断するのは依然として人間のエンジニアである。デザインシステムを整備し、それをコードとして型定義し、Linterで強制する。この一連のプロセスは、AIが台頭する以前から我々が理想としてきた「堅牢なフロントエンド開発」そのものだ。AIは、我々がサボっていた「設計の不備」を容赦なく暴き出し、同時に「設計の正しさ」を加速させる触媒として機能しているに過ぎない。

読者であるエンジニア諸君に問いたい。あなたのチームのデザインシステムは、AIが読み解けるほどに構造化されているだろうか？Figmaのトークンとコードの変数は、1対1で対応しているか？もし答えがNoなら、AIを導入する前に、まずは「ドキュメントとコードの同期」という、最も退屈で最も重要な作業から始めるべきだ。AIは魔法の杖ではない。それは、あなたが積み上げてきた設計の質を、そのままの倍率で増幅させる増幅器である。ゴミのような設計をAIに食わせれば、ゴミのようなコードが高速で生成されるだけだ。

最後に、明日から実践すべき処方箋を提示する。まずは、現在利用しているコンポーネントライブラリのStorybookに、デザインデータへのリンクを埋め込むことから始めよ。次に、AIが頻繁に間違えるパターンを特定し、それをLinterのカスタムルールとして定義せよ。そして、AIを「コードを書く奴隷」としてではなく、「ガイドラインを遵守させるためのレビュアー」として活用するフローを構築せよ。AIに実装を任せるのではなく、AIと共に「設計の整合性」を維持する文化を育むこと。それが、この激動の時代を生き抜くシニアエンジニアの矜持ではないだろうか。AIに仕事を奪われることを恐れる前に、AIを使いこなすための「設計の言語」を磨き上げているか？その問いに対する答えが、あなたのエンジニアとしての市場価値を決定づけることになるだろう。