AI時代に試したものと所感

技術系のものは Zenn に書いてたので、気づけばこのブログ一年くらい放置していた。苔とか生えてそう。

AI 関係で色々試したり触ってた

世はまさに大 AI 時代なのは周知の事実で、誰もが口を開けば MCP とか Cursor とかの話をしてる。

そういう自分も例外ではなく、ここ最近は色々と触ったり作ったりしてた。 その知見をもとにして仕事でも使う機会も増えてきた。

蓄積されてきた感じがあるので、一回吐き出しておこうかなと思う。

作った / 独自 rules の複製用 CLI ツール

"airules" という名前で、AIエディタ用の個人用 rules を管理するためのCLIツールをDenoで作った。

これはJSRで公開してある。開発はすべて Agent に書かせて、自分ではほぼコードは書いてない。

https://jsr.io/@mugi-uno/airules

https://github.com/mugi-uno/airules

自分はいまのところ Cursor を課金してメインで使っている。

Cursor では .cursor/rules に *.mdc ファイルを置くと、Agent 実行時に読み込んでくれる。プロジェクトで rules を用意するケースもあると思うが、自分好みでカスタマイズさせたい、ということも珍しくない。

たとえば私の Cursor はピカチュウになっている。

ピカチュウは絶対「ピカチューだよピカ！」とは言わない気はするが、気にしたら負けです。

それはさておき、こういった独自ルールについては、現状 Cursor (0.49) だとエディタ自体の設定で保持する以外の方法がない。

参考: Cursor – Rules

シンプルなものであればそれで良いのだが、プロジェクトや作業の種類によっては、こういった独自のプロンプトの内容を切り替えたくなる。

自分の場合は rules の *.mdc や *.md のみを記録したリポジトリを用意して、そこから都度 .cursor/rules にコピーしているのだが、これが手間に感じてきた。

ということで、ポチポチとファイルを選ぶだけで簡単にコピーされるようなCLIツールを作ってみた、という話である。ファイル単位だけでなく、見出し単位でもピックアップできるようにもしてみた。

正直、独自ルールのファイルはまだそれほど用意していないのだが、今後は "必要に応じていい感じのプロンプトをサッと出せる" というのも一つのスキルになる気がしてるので、これを酷使しながら蓄積していきたい。

作った / Splatoon 3 MCPサーバー

一回は自分でMCPサーバー作ってみないとな、ということで作ってみた。

外部APIなら何でも良かったのだが、せっかくなら自分がテンション上がるものがいいなと思って、趣味というか日課みたいにプレイしている Splatoon のステージ情報を返すMCPサーバーを作ってみた*1。Splatoon3については、サーモンランを全ステで野良カンストしています。

なお、実験用に作ったので運用とかする気はまったくない。

llms-full.txt が便利

MCPの作り方/作ってみた記事は無数にあるのでここでは省略するが、とりあえず Anthoropic が公開している llms-full.txt というファイルが超便利、という情報だけ残しておく。

Building MCP with LLMs - Model Context Protocol のチュートリアルでも冒頭で紹介されてるので、知ってる人も多そう。

ファイル自体は以下で公開されている。

🔗 https://modelcontextprotocol.io/llms-full.txt

これは簡単に言うと、LLM向けのMCP情報がすべて載ってるテキスト、と思えばいいと思う。仕様からサンプル実装まで載ってる。

これを NotebookLM に食わせれば不明点を質問するのも容易。なお、Cursor とかの Agent に読ませる場合、ファイルが大きすぎて上手く読めないこともあるので注意が必要。

自分の場合は https://github.com/modelcontextprotocol/typescript-sdk のドキュメントなども合わせて読ませることで Agent にうまいこと実装させることができた。

失敗 / Cline での学習用プリント作成ツール

CLINEに全部賭けろ を見て「俺も全部賭けなきゃ…!!!」と思ってやってみた。

小学生の娘がいるので、「漢字とかの学習用のプリントを作るWebアプリ」をClineで作ってみようとした。

10ドル上限でどこまでいけるか、というのでトライしてみたのだが、自律型AIエージェントの扱い自体に慣れていなかったのもあって、微妙なものが仕上がって終わった。

それっぽくは見えるが、普通に各所がぶっ壊れていて使い物にはならないし、問題も全然期待通りに出てこない。

プランニングが大事ということを体感した

雑な指示をした場合、Clineはまさに暴走特急と呼ぶにふさわしい挙動だった。一気に完成まで走り切ろうとするのだが、依頼したスコープが非常に大きかったのもあり、終わるまでも長い。そして長くなればなるほど前提となる情報も大きくなり、コンテキストウィンドウと私のクレジットを湯水のように消費して終わった。こいつは人の金をなんだと思ってるのか、という気持ちになった。

そして、やはり一発では全然意図通りに上手くいかない。暴走→止める→大幅にやり直す、みたいなループになってたのが非常に良くなかった。

まず粒度が小さくなる形でプランニングをさせて、かつ段階的に作業をさせるのが重要ということを学んだ。

また、一回のセッションで走り切るのも無理があるので、プランニングは適宜外部ファイルなどに出力し、別セッションで個々のタスク単位で実行できるように導いてやる必要があった。

先に挙げた CLI ツールや MCPサーバーは、このClineでの失敗を活かして実装したので、わりと上手くいった。

お仕事 / Design System & Figma の MCP サーバー

副業でお手伝いしている先で、Ubieさんの以下の事例を参考に、似たようなことができないか検証してみてほしい、という依頼を受けた。

https://zenn.dev/ubie_dev/articles/f927aaff02d618

スプラトゥーンのMCPサーバーを作ってて良かった、と思った瞬間であった。

該当の記事自体にはMCPサーバー自体がどういう形で実現されたのか、という情報は無かったので、雰囲気で察してやってみた。（もしかしたら、今ならどこかに公開されてるのかもしれない）

「Design System の情報が一覧・検索できて、サンプル実装とかがわかればええんやろ」と予想し、幸いにも Storybook はきちんと整備されていたので、次のようなツールを持つMCPサーバーを作成した。

• Design System のコンポーネント一覧を返す
• コンポーネントの詳細を返す（ソースコードおよびStorybookのコードも返す）
• デザイントークンの一覧を返す

なお、後日公開されていた LayerX さんの事例とかなり類似していたので「やっぱこうなるよな」と安心してた。

https://zenn.dev/layerx/articles/7e9f87fca65e94

Figma 上では Design System のコンポーネントと名称が紐づく形でデザインされてるので、これで指示したらうまくいくはずである。

ということで実際試してみたみたが、結果としては、ほぼ完璧なUIが一発で出力された。（さすがに画面は貼れない）

想像していたより遥かに上手く行ったので、これは結構驚いた。

このMCPのユースケースの話になると、毎回「これってMCPである必要あるんか？？」という話になるのだが、実際のところ「現状だとなんかよくわからんけどMCPにしたほうが上手く情報を使ってくれる」という肌感である。

将来的にはMCPである必要もなさそうなので、現段階としては

• とりあえずコスト低くMCPサーバー立てられるなら使っても良さそう
• テキスト情報でLLMに渡せるドキュメントを充実させておく

の2つを意識しておくといいんだろうな、と思った。

いろいろ試してみての所感

完全に個人の感想です。個人ブログなので許されるはず。

テキスト書いといたほうが良さそう

LLM自体もだが、それを取り巻くツールの進化が異様に速い。数週間たつとトレンドが変わっているみたいな印象を受ける。

たとえば、現状自分は Cursor を使ってはいるが、数ヶ月後にもこれを使っているか？と言われると非常に懐疑的である。

Design System の MCP についても、しばらくしたら MCP を使わずともコードベースをまるごと読ませて OK とか、何なら GitHub リポジトリを教えればそれでもう完璧に動くみたいな世界が来るような気もする。

この流れの中でずっと使えるものって何？って考えると、シンプルにLLMに渡す情報そのものでは、という気がする。

積極的にアーキテクチャ情報やナレッジなどは扱いやすい形（Markdownとか）で残しておくのが懸命かなと思う。

ドキュメントや rules を作成する際にも Agent を上手く使えると良さそう。たとえば Cursor なら /Generate Cursor Rules とかを使えば簡単に rules を出力できる。

上手く扱えると間違いなく速い

上手いこと動作をコントロールして扱えると、現状のAI Agent でもかなり効率的にコードを書けるな、という感覚になってきた。

作成したものの一つであるCLIツールの "airules" を例に見ても、これを自分でゼロから作ったらもっと長い時間がかかったはず。

Deno ですべてを作ったのだが、単発のスクリプト程度でしか使っていなかったし、周辺ライブラリの使い方などを調べるだけでも苦労したと思われる。

また、Rust, Go, Node, Deno などでの実装の比較から依頼し、かつ Deno でどういったライブラリが使えそうかのリサーチもさせたが、正直自分で調査したらそこまで深く調べられたかは怪しい。（面倒なので慣れてる Node で作る判断をしたかも）

使ってるうちに「こういう作業は上手くやってくれるんやな」というのがわかってくる感覚があった。

とにかく試してみたほうが良さそう

触り続けてるうちに得た多くの知見が、

**「なんだかよくわからんが、こういう感じでやればこういう風に動きやすい気がする」 **

という、なんともハッキリしないものばかりだった。

頑張れば人に伝えられそうだが、正直なところ感覚的なものも多くて、言葉にして説明されたところで、同じように皆がやれるかは怪しいと思う。

いろんな記事を読んでみるのもいいが、いろいろ試してみて思ったこととしては「いろいろ試してみたほうがいいな」ということです。

(個人の感想) AI 関係のアウトプットのモチベが上がりにくい

少し毛色が変わる話で、まさに所感というか個人のお気持ちなのだが、こういったAI系の「やってみた！」系の記事のアウトプットのモチベーションがなんとも上がりづらいな、と感じている。

過去をふりかえると、AIじゃないものについてはそういうのも気軽に投稿してた気もする。

なんでだろう？と考えてみたのだが、最近は「これ LLM にドキュメント食わせて書かせただけでは…？」みたいな記事も溢れかえっていて、 従来は自分でも書いていた「こういうのを見て、こういう流れでやったよ！」みたいな How to の部分は、完全一致とは言わずとも、7-8割くらいは被ってしまうんですよね。

そうなると、自分が書く記事の差分って何？というのは「おもったこと」みたいな、実体験に基づく部分がメインになってくると。

その部分ってそれほど量無くても書けちゃうので、Xとかで「〜が良かった」みたいなポストをして、それで終わっちゃう傾向にあるのかもしれない。

とはいえ、それはそれであんまり健全では無い気もするので、ある程度溜まった段階でこういった個人ブログとかで吐き出しておくくらいが丁度いいな、と思い至ったのであった。

ともあれ、進化は速いなと思いつつも、なんだかんだ楽しみながら色々試せているので、また色々知見がたまったら記事として書いていきたい所存です。