AIエージェントのススメ 第14回 スキルを使いこなす4：ナレッジスキル その2
ナレッジスキルの3分類のうち2つ目、「設計の指針」をスキルにする方法を紹介します。技術スタックの選定、CSS設計、テストの規約という3つの例を通して、AIエージェントに進むべき方向を示すスキルの考え方を解説します。
前回まで
前回は、ナレッジスキルを次の3種類に分けて整理するとよいのでは？ という提案をしました。
- 純粋なナレッジ
- 設計の指針
- ベストプラクティス
そして、その1つ目である「純粋なナレッジ」を紹介しました。
今回は2つ目の「設計の指針」を紹介します。純粋なナレッジが、AIの知り得ない情報そのものをスキルにするものだったのに対し、設計の指針は「どう作るか」の方針をスキルにするものです。
今回の話は、もしかしたら「AIは便利だけど、いろいろうまくやってくれない」と感じている方にとっては重要なトピックかもしれません。おそらく、自分もこの手のスキルを作っていなければ、AIの作ったものを信用できず、人の目ですべてをチェックしないとならないという考えから抜け出せていなかっただろうと思います。では、何がその安心感を作り出しているのか？ というところです。
本記事では、次の3つの例を通して紹介していきます。
- 例1. 技術スタックの選定
- 例2. CSS設計
- 例3. テストの規約
例1. 技術スタックの選定
設計の指針の1つ目の例は、技術スタックの選定です。前回の記事で、AIエージェントにTODOアプリを作らせる例として、次のように書きました。
筆者はこれをローカルで実行してはいませんが、最近のモダンなスタックでほぼ完璧にやってくれるはずです。試しに今ChatGPTへこれを聞いて、どの技術スタックを選ぶか尋ねてみたところ、Next.js、Vercel、AWSやResend、Google OAuth……といった構成で、非常に詳細なプランが返ってきました。実際に作らせたとしたら、たぶん何も言わずとも、サーバー側の設定ガイドというようなものまで作ってくれるでしょう。
ChatGPTはこう答えたわけですが、筆者がこのTODOアプリを実装するとしたら、おそらくCloudflareを選びます。認証にはBetter Authを使うことになるでしょう。メール送信は、ChatGPTの選択と同じくResendを使うと思います。
また、個人的なプロジェクトであれば、筆者はzfbという、Next.jsのミニ版みたいなものを作っているので、これを使います。ですが、プロダクションの開発であれば、より安定しており、十分にテストされたフレームワークのほうが合うでしょうから、Next.jsや、Astro + Reactというようなスタイルの開発を選ぶはずです。
ここで技術スタック論争を始めたいわけではありません。どれがよい／悪いという話でもありません。ここにあるのは、ただの「選択」です。そしてその選択はスキルにしておくことができます。次のような感じです。
技術スタック選定のスキル化依頼
/skill-creator このアプリの技術スタックのチョイスを /dev-basic-cloudflare-webapp としてスキル化。他の開発のスタート時に参照させ、使用ツール等の参照となるように設計して
これで、AIエージェント向けの簡単なセットアップガイドができあがります。この種のツールは頻繁に改善され、変化していくものなので、このスキルをメンテナンスしていけば、その後の開発の立ち上がりはぐっと速くなります。
たとえば次は筆者が作って使っているスキルです。
結構膨大だったので、日本語に訳させたものを次に別途置きました。
だいたい手元にある、自分で作ってきたWebアプリの構成がまとまっているので、このスキルで初期化すれば、似たような構成でセットアップが完了します。
これは前回紹介した「純粋なナレッジ」そのものではありませんが、近いものです。言ってみれば、ただの開発メモのようなスキルです。
例2. CSS設計
設計の指針の2つ目の例はCSS設計です。個人的には、AIの力を使う恩恵がかなり大きい領域だと感じています。というのも、これはAI以前から実現したかったことでありながら、実現がほぼ不可能だったことでもあるからです。まじめに取り組もうとすれば、人間が1つ1つ細かくチェックする必要があり、すべてのHTMLを手作業でメンテナンスし続けるには、コストがかかりすぎるのです。しかし今、そのコストはほぼ消えました。必要なのは「ルール」だけです。
この領域には書きたいトピックがたくさんあるのですが、ここではCSSのコーディング方法を1つ紹介させてください。筆者が「タイトトークン戦略」と呼んでいるものです。詳細は次のドキュメントにまとめてあるので、本記事では簡潔に書きます。
これはTailwind CSSの使い方のルールです。Tailwind CSSにはスペーシングのスケールが組み込まれており、ほぼ何もせずともp-1、p-2、p-3、p-4……という、paddingを設定するクラスが使えます。Tailwind CSS v4では、このスケールは0.25remの倍数なので、p-1はだいたい4px、p-2はだいたい8pxになります。Tailwind CSSに組み込まれた、デザインシステム的な振る舞いといえます。
この機能自体はよくできています。最初から「4pxの倍数で余白を制御できますよ」というルールです。ですがこれは、まだかなり自由な値の選択を可能とするものでもあります。AIエージェントはこれらのスケールを使ってスタイルを当ててくれますが、スペーシングのルールをもっとミニマルに保ちたい場合、それを維持するには努力が必要です。たとえば、「p-4のスケールは飛ばして、そこはp-3かp-5のどちらかにしたい、その次はp-8にしたい」……というような話です。
そこで、筆者の考えたタイトトークン戦略の出番です。タイトトークン戦略では、Tailwind CSSのデフォルトテーマを読み込みません。つまり、デフォルトのスペーシングはすべて失われます。その代わりに、次のようなトークンを定義します。
タイトトークン戦略によるスペーシング定義
@import "tailwindcss/preflight";
@import "tailwindcss/utilities";
@theme {
/* ========================================
* プロジェクトトークンのみを定義 — Spacing
* ======================================== */
--spacing-0: 0;
--spacing-1px: 1px;
/* 横方向の余白 */
--spacing-hsp-xs: 12px;
--spacing-hsp-sm: 20px;
--spacing-hsp-md: 40px;
--spacing-hsp-lg: 60px;
--spacing-hsp-xl: 100px;
--spacing-hsp-2xl: 250px;
/* 縦方向の余白 */
--spacing-vsp-xs: 8px;
--spacing-vsp-sm: 20px;
--spacing-vsp-md: 35px;
--spacing-vsp-lg: 50px;
--spacing-vsp-xl: 65px;
--spacing-vsp-2xl: 80px;
}
この設定によって、スペーシングは次のような使われ方になることを期待します。
pt-vsp-sm:20pxの上パディングpt-vsp-md:35pxの上パディングpx-hsp-md:40pxの左右パディングpx-hsp-lg:60pxの左右パディング
vspは「vertical spacing（縦方向の余白）」、hspは「horizontal spacing（横方向の余白）」の略です。このルールは、AIエージェントに非常に限定されたスペーシング値だけを使うことを強制します。縦横、基本としては「決められた6つの余白の中から選んで使ってね」という決まりです。これにより、自分の実現したい余白コントロールの実現に近づきます。
さて、そんなデザインルールはどう感じられるでしょうか？ 筆者は縦方向と横方向の余白を分けて考えると心地よく感じるのでこうしていますが、きちんと構造化されたデザインにとって、これが正しい方法なのかはわかりません。縦と横の余白は統合されているべきだと考える人もいるでしょうし、それもまたOK……というより、そちらのほうが一般的かもしれません。
ここでお伝えしたいのは、前項同様、どの技術スタックがよい／悪いという話ではなく、この種の設計の指針が、AIエージェントに対して非常に効果的に働くということです。Claude Codeに先ほどのタイトトークン戦略のドキュメントを読ませ、/dev-tight-token-strategyとしてスキルを作らせてみてください。それだけで、筆者のCSS設計のアイデアを再現できます。
例3. テストの規約
設計の指針の3つ目の例は、テスト戦略です。これも長い説明が必要なトピックなので、興味のある方は次のドキュメントを参照してください。本記事では、この考え方を本当に短くまとめます。
これは、AIエージェントがどのようにテストコードを書くべきかというガイドです。それ自体は、ごく一般的な開発のトピックです。AIエージェントにたくさんのアプリを書かせるようになったころ、筆者は、AIエージェントが「できました」と報告してきたのに、生成されたWebアプリを開くとエラーが出ている……ということがよくあるのに気づきました。この事実は自然と、テストをどう書いていくかを筆者に考えさせることになり、テストコードは増えていく結果になりました。単純にそのようにすると、ほぼAIの成果物は最初から動く状態になっていったのです。
しかし、それでも問題は残りました。アプリが大きくなるにつれてテストコードも膨れ上がっていったため、テストの実行時間は長くなり、結果としてそれらをどうするか考える必要が出てきました。
そんなわけで、「テストどうしよう問題」について筆者はClaude Codeと相談し、テストを6つのレベルとして定義することにしました。そして、なるべく低いレベルからテストを書くことを検討すべし、というルールを作りました。その6つのレベルが次のリストです。
- ユニットテスト／ロジックの検証
- DOMコンポーネント上での検証
- ビルド出力結果の検証
- ブラウザベースの検証
- 決定論的＋視覚的検証
- AIベース視覚検証
1〜3は軽量なテストです。4は一般的なPlaywrightのE2Eテスト、5も同じくPlaywrightを使いますが、ピクセル単位の正確な値の一致など、より精密な結果の確認に使います。6は、AIによるキャプチャ結果の比較テストです。この6つ目のレベルは、canvasベースのドローイングアプリの実行結果をテストしようとし、延々と失敗を繰り返したときに追加したものです。canvasの描画結果は、単純なDOMのレンダリング結果からはテストできなかったため、最後の砦として、ブラウザでのキャプチャ結果をAIに判定させて検証させるという段階を用意しました。
前のセクションと同じやり方で、先ほど挙げた2つのURLを与えて、/dev-test-levelsとしてスキルを定義してみてください。そして、何かをコーディングさせるときに、このスキルを呼び出すのです。すると、AIエージェントは適切なレベルのテストを選んでくれるようになります。
このような「どう実装してほしいか」というものもスキルにすることができます。AIのほうが自分よりも圧倒的に知識があるのだから、そのあたりもうまいことやってくれるんではと期待したくなりますが、すでにできあがっているコードベースがあると、その土台に合わせてしまう、こういうことはよく起こります。たとえばプロジェクトで使われているテストがPlaywrightのみで書かれていたら、それに倣ってPlaywrightのテストを書くでしょう。「テスト戦略を再考したい」などと相談すれば、新しいテストツールを提案してくるかもしれませんが、基本は今の状況をベースとするという具合にです。
そのように、何かテストがうまくいっていないみたい？ という状況に出くわしたとき、このようなテストの方針を固めたスキルを渡すと、既存のテストも含めて調整を試みさせることができます。
ただ、この「適切」も、単なる筆者一人の判断であるという点を認識しておいてください。おそらく半年後には何かしら手が加えられていると思います。そして、これはフロントのWebアプリを中心とした開発の中で生まれたものであり、その前提が変わればまったく異なる内容になるでしょう。前述した技術スタックやスペーシングの定義と同じ類の話であり、「筆者的にはこれでうまくいってるっぽいよ」程度のものです。
AIエージェントに与えるべきもの
「設計の指針」としてのスキルを今回は例を挙げて紹介しました。ここまで読んで、「なるほど、そういう教科書や辞書みたいなスキルを、ナレッジとして作ればよいんだな」と感じられた方もいるかもしれませんが、ニュアンス的にはちょっと違います。LLMはいかようにも情報を引っ張ってくることができるので、わかりきっていることを与える必要はありません。「いいですか、これがCSSのセレクターで、要素で、波かっこで、プロパティと値はこう書いて……」などとAIに教えるのは、まったく不要なこと、ただのトークンの無駄です。
ここでAIに与えたいのは、進む方向のコントロールです。LLMは、膨大なデータによるトレーニングの上で生み出された推論を使って、レスポンスを返します。しかし同時に、こちらの入力したプロンプトを尊重するようにも設計されています。ですので、ここで与えるべきは「そっちじゃなくてこっち。左の道じゃなくて右の道」というような、案内、ガイドに近いものです。ちょっと調べればわかるような内容が書き込まれた教科書や辞書は、彼らには必要ありません。
これはおそらく、人同士のコミュニケーションで言えば、バリバリにできるエンジニアへの最適な指示書に近いかもしれません。この連載で、「AIに対してボスとして振る舞う」と書いてきましたが、ここでも似たように考えているとよいかもしれません。自分はチームで動いていて、そして部下がいたとします。部下に仕事を任せて、書いてもらったコードを毎回すべて読むものでしょうか。それはもちろん、あらゆるケースで見なくてよいとは言いませんが、必要なことが共有できていて、そしてやってもらった結果も問題ない。これが繰り返されたら、「あいつには任せて大丈夫」となりませんかね？ この繰り返しを可能にするのが、今回紹介したようなスキルではないかと筆者は考えています。
今回は、ナレッジスキルのうち「設計の指針」のスキルを紹介しました。個人的には、この種のスキルは、AIを効果的に使ううえでとても重要なものだと考えています。AI以前の時代、この記事に書いたようなことは、自分の脳の中に入れておく必要があるものでした。短く言えば「経験」です。AI時代にやるべきことは、その「経験」を、AIが実行できる形式にしていくこと……。その手段の1つがスキルといえるのかもしれません。これはどことなく、経験を脳の外で育てるようなもののように筆者には感じられます。
次回は、ナレッジスキルの3つ目の分類、「ベストプラクティス」について紹介します。