🧠

オレのmcpは頭が良い - fluorite-mcpで“いま結構いい感じ”の開発体験

に公開

最近、エディタに「Claude Code, Superclaude, serena, context7 …」とMCPサーバーを追加しながら、LLMと協働する“手触り”をひたすらチューニングしてきました。そこに「fluorite-mcp」を並べたら、いま結構いい感じのコーディング作業ができてるぜ!という手応えが出てきたので、今日はその理由とセットアップ、使い方をノーカットで共有します。

ちなみに、このmcpは僕が作ってます。

リポジトリ:
https://github.com/kotsutsumi/fluorite-mcp

ドキュメント:
https://kotsutsumi.github.io/fluorite-mcp/

ちなみに、あんまり丁寧にドキュメント作ってないですが、一応カタチだけでもと思い・・・。

fluorite-mcp は何者?

fluorite-mcp は「モデルに渡すコンテキスト(知識)を、あなたのプロジェクトに最適化して整理・供給する」ためのMCPサーバーです。特徴は次の3つ:

  • コンテキストを“仕様カタログ(YAML)”として管理できる
  • リソースURI(例: spec://@tanstack/react-query)で、必要な知識をピンポイント投入
  • ツール(list/upsert/stats/metrics)で、LLMに渡す情報をいつでも増やせる・見直せる

これにより、LLMが“自分の現場で必要な正解”を把握しやすくなり、返ってくるコードの設計や語彙が一段とプロジェクト寄りになります。

「オレのmcpは頭が良い」の正体

ポイントは「曖昧なプロンプト」をやめて、「構造化されたドメイン知識」を小出しにすること。fluorite-mcp はその“知識の搬送路”をMCPの標準プロトコルで提供します。

こうして「使うUIライブラリ」「APIクライアント」「データグリッド」「設計方針」「テスト戦略」…を、LLMが“常に参照できる”状態にします。これ、地味に強いです。

すぐ使える — セットアップ

# グローバルインストール
npm i -g fluorite-mcp

# コンテキスト/プロジェクトを指定せずに登録(全体有効)
claude mcp add fluorite -- fluorite-mcp-server

こんな感じで効く(実例)

  • 目的: 「React + TanStack Query + shadcn/ui + Storybook + Playwright で UI 実装」

  • LLMへの指示:

    1. spec://@tanstack/react-queryspec://shadcn/ui を参照
    2. spec://ui-component-quality のガイドラインに従って、atoms/molecules に分割
    3. Storybook の CSF3 と Interactions で主要状態を網羅、Playwrightで回帰テスト

この3点を最初に“構造化コンテキスト”として読ませるだけで、提案コードの品質がぐっと安定します(props設計・命名・腑に落ちる責務分けが増え、後から困らない)。

「このプロジェクトで採用している道具箱」をカタログ化しておけば、LLMはその前提で“最適解”を出しやすくなります。

正直、--all-mcpでぶん投げてもそれなりに参照してくれます。

メトリクスで振り返る

fluorite-mcp には診断系ツールもあります:

  • catalog-stats — カタログ件数や拡張子分布
  • server-metrics — 稼働メトリクス(uptime・メモリ・ハンドラ別平均時間など)

地味ですが「今日はどれだけ知識を足したか」「LLM に渡した前提が最新か」を見直すためのダッシュボードとして効きます。

これ自体を生成したので、「使うんか?」って気持ちもありますが、一応。

Claude Codeで“思った通りにならない”ときに

みなさんClaude Codeを使って開発していますか?

Claude Codeでのコード生成で苦しんでいませんか?思った通りにならないですよね?

それ、前提(コンテキスト)の解像度が足りない可能性が高いです。fluorite-mcp でプロジェクトの“合意事項”や“採用スタックの使い方”をYAMLで小分けにし、明示するだけで、やれることが一気に増えます。LLMに「この前提で書け」と言えるようになるからです。

いつ導入すべき?

  • 新規プロジェクトの0→1で、設計の“型”を固めたいとき
  • 既存プロジェクトで、レビュー時に「このルールどこに書いてある?」が多いとき
  • UI 実装の“迷い”を減らし、Storybook/Playwright で回帰を自動化したいとき

実は・・・

いままで、Claude Code CLIを利用していく中で、オレオレで~/.claudeに書いてたモノなどをもとに色々整理したまでで、まだぜんぜん完璧じゃないです。
動いてねーよとか、直したぜってあれば、Issueくれて気がついたら対応するかもしれません。

まとめ

fluorite-mcp を Claude Code, Superclaude, serena, context7 などと一緒に使ってみてください。コンテキストを資産化すると、LLMは一段と“頭が良く”なります。いま結構いい感じのコーディング作業ができてるぜ!と胸を張って言える、その一助になるはずです。

最近、実際にClaude CodeとかCodexとか使いながらガリガリ仕事で使って行っているのですが、なんで「こんなに早くできあがるのか?」「プロダクションまで使えないじゃん」「どうやってやってるんですか?」みたいな色んな意見もらってりもするんですが、基本説明するのめんどいので教えないんですけど、プログラミング全体に言えることですが、

適当にやっても、出来上がらないし、銀の弾丸じゃないんだから、上手くいくわけないやろ・・・

というのが正直な感想です。

Claude Codeのみならず、LLM系を思った通りに使いこなすには、それがそのものである必要十分条件をちゃんと提示できる、言語化できるスキルが必要かもしれませんね。
人にも適当に指示しても求めた結果が得られないのと似たような感じがします。
(プログラミングだから関係ないって言う人もいるんですが、人とおしゃべりもっとした方がいいかもね)

結果、僕はここ数ヶ月取り組んでて大成功というか、自分の実装速度を10倍以上に増やすことが出来て結構楽しんでます。
現在、会社内の開発フローやプロジェクトマネージメントまで膨らませて、生成のコンテキストエンジニアリングも含めた運用設計もお手伝いさせております。
興味のある方は、ご連絡ください。

みなさんが、「使えねぇ・・」からmcpを追加したりして Claude Codeとかで生成プログラミングを強化して、楽しめることを期待して。


質問/要望は Issue へどうぞ。仕様テンプレやスターターの追加もお待ちしています。

Discussion