Entersight

開発のこと

AI に毎回同じ部品を作らせないために、設計思想を公開した

2026.11.11

ライブラリを入れる時代から、設計思想を読ませる時代へ ── AI 駆動開発のためのコンポーネントカタログ

コードを書くコストは下がった

AI 駆動開発が当たり前になり、コードを書くという行為そのもののコストは大きく下がりました。ボタン 1 つ、フォーム 1 つを書くのに、以前ほど時間はかかりません。

これまでは、書く量を減らすためにライブラリを入れていました。UI ライブラリ、フォームライブラリ、コンポーネントカタログのツール。自分で書くより、誰かが作ったものを使うほうが安かったからです。

しかし今は、書くこと自体が安くなりました。ライブラリを入れる理由のうち、「書く量を減らす」という部分は、以前ほど大きくありません。むしろ、ライブラリが持ち込む依存、設定、バージョンの追従のほうが重く感じる場面が増えてきました。

でも、一から全部を AI に設計させるとうまくいかない

では、ライブラリを使わずに、全部を AI に一から作らせればいいのか。私たちが試したところ、それはそれで問題が出ました。

  • 頼むたびに、ディレクトリの構成や命名がばらばらになる

  • 既にあるものとよく似たコンポーネントを、また新しく作ってしまう

  • そのたびに「こういう構成で」「既存のこれを使って」と説明し直すことになり、やり取りもトークンも増える

コードを書くのが安くなっても、何をどう作るかという設計が毎回ぶれると、結局コストは下がりません。

ライブラリでも、ゼロからでもなく、「設計思想」を渡す

そこで私たちは、コンポーネントカタログについて、ライブラリではなく設計思想そのものをまとめ、公開しました。

https://github.com/TakakiMoriguchi/component-catalog-blueprint

使い方は、AI エージェントに次のように頼むだけです。

https://github.com/TakakiMoriguchi/component-catalog-blueprint を読んで、その SPEC.md に従ってこのアプリにコンポーネントカタログを作成してください。

インストールするものはありません。追加される依存は 0 パッケージ、0 MB です。AI が仕様を読み、アプリに合わせてカタログを書きます。導入のコストは、実質ゼロです。

何を決めているのか

仕様で決めているのは、AI が毎回迷わないための「型」です。

  • すべてのコンポーネントを atomic design の 5 つの階層に分ける。 「自分より下の階層しか使えない」という 1 つの基準で分類するので、誰が作っても同じ場所に入ります。

  • 表示パターン(fixture)をコンポーネントの隣に 1 回だけ書き、カタログとテストの両方で使う。

  • カタログの一覧には、検索欄を標準で入れる。

  • カタログは開発時だけ。本番には含めない。

使ってみて起きたこと

この仕様に沿って AI 駆動開発を進めたところ、変化がありました。

AI が、似たようなコンポーネントを毎回作らなくなりました。 カタログが階層ごとに整理された「部品の一覧」になっているので、AI は新しく作る前に、既にある部品を見つけて使うようになります。

トークンも減りました。 構成や命名を毎回説明し直す必要がなくなり、似た部品を作っては直すという往復も減ったからです。

どのスタックでも使えることを確かめた

設計思想なので、React に限りません。同じカタログを 10 個のスタックで実際に作り、すべて動くことを確かめました。

React、Vue、Svelte、Next.js、Angular、Ruby on Rails、Laravel、Django、Go、Phoenix です。

10 個のスタックで作った同じカタログの一覧

検証の詳細や、スタックごとにハマった点は、こちらの記事にまとめています。

仕組みとして公開した意図

ライブラリは、使う側がそのライブラリに合わせる必要があります。設計思想は逆で、それぞれのアプリに合わせて形を変えられます。だから、どの会社の、どのスタックのプロジェクトでも使えます。

AI 駆動開発が広がるほど、「何を書くか」より「どう設計するか」をそろえることの価値は上がっていくと考えています。その型を 1 社で抱えるより、公開して、使った人の気づきで磨いていくほうがいい。そう考えて、MIT ライセンスで公開しました。

使ってみて気づいた点があれば、GitHub の issue や pull request で教えてください。

まとめ

  • AI 駆動開発で、コードを書くコストは下がった。ライブラリで書く量を減らす意味は、以前より小さい。

  • 一方で、全部を AI に一から設計させると、構成がぶれ、似た部品が増え、説明のトークンもかさむ。

  • ライブラリでもゼロからでもなく、設計思想を読ませる。導入コストはゼロで、AI の出力がそろう。

← ブログ一覧へ