はじめに

前の 2 記事で、MCP × bge-m3 のオフライン・ナレッジ基盤と、それをゼロ設定の VSCode プラグインに仕立てた話を書きました。今回はその上に乗せた「対話でコンポーネントページを生成する」MVP の話です。プラグインからナレッジ基盤までの一連を 1 週間で組み、デモできる状態まで持っていきました。

何ができるか

一言でいうと、テキストで会話すると、コンポーネントライブラリを使った標準ページが出てくる。
• 自然言語で「こういう画面が欲しい」と書く
• 4分後、出力はコンポーネントライブラリに準拠した 1 枚の標準ページ
• そのまま対話でスタイルを調整できる（「ここをもっと余白広く」「この列を右寄せに」など）

効いてくる場面

コンサル / 提案の現場
顧客の要望をその場でページに起こせます。会話しながら、見える形のページを即座に生成できるので、「言った／言わない」のすり合わせが画面ベースで進みます。さらに mock 上で操作もできるため、静的なモックより一段リアルに合意形成できます。
そして重要なのは、このページがそのまま開発チームに渡せること。開発チームはそれを土台に API を繋ぎ込めばよく、デザインと実装の間の翻訳ロスが減ります。
デザインチーム
Figma MCP を統合することで、デザインチームは自分のアイデアを直感的にコードへ落とせます。頭の中のレイアウトを、規範に沿った実装へ変換する道ができます。
新規コンポーネント開発
ある程度まで、コード規範に沿って新しいコンポーネントライブラリを開発することにも使えます。既存規範を学習した状態で生成するので、スタイルの逸脱が起きにくい。

モデル依存という現実

正直に書くと、効果はモデルへの依存が大きいです。
• 現状の MVP は GPT-5 mini（low）で、テキスト対話 → 規範準拠ページ生成を回しています
• 最新の Opus に差し替えると、生成品質は明確に良くなります。ただし Token が高い
つまり「品質」と「コスト」がそのままモデル選定のトレードオフになっていて、ここは用途ごとに割り切る前提で設計しています。
次のレイヤー：利用チーム向けの KB
MVP の次に用意しているのが、利用チーム自身が同じフレームワークの上で、自分のプロジェクト用 KB を作れる仕組みです。
ローカル KB は、その性質上そのまま特定プロジェクト向けの KB へ拡張できる。つまり、配布したプラグインがそのプロジェクトの KB へ育つ設計です。プロジェクト固有の文脈を取り込むことで、精度が上がり、幻覚（hallucination）が下がる——これが狙いです。

これからの課題

ここから先に積み残している論点を、正直に列挙します。
• ナレッジの蓄積：KB は中身が育って初めて価値が出る
• Skill / Agent のチューニング：生成の質を安定させる調整
• エンジニアリング・ガバナンス：hooks による門番（ゲート）、定時タスクなどの運用統制
「動く MVP」と「運用に耐えるツール」の間には、この辺の地味な治理が残っています。

最後に：層を積み上げた先

最初の構想どおり、層を一段ずつ積み上げて、最終的に会社レベルのプロジェクト・ナレッジ基盤にしたいと思っています。
個人的な野心として、フルパラメータの DeepSeek V4 を蒸留の核に据えた FastAPI を一度試してみたい。ここはまだ夢の段階ですが、楽しみにしています。

まとめ

ナレッジ基盤を作る → プラグインで使われる形にする → その上で「対話で規範準拠ページを生成する」MVP を乗せる。1 週間で通しで組んでみて分かったのは、生成の体験はモデルに強く依存する一方、価値の本体は “規範に沿った出力を、そのまま下流に渡せる” という連続性にあるということでした。