00:00:00[音声を一時停止]
00:00:30[音声を一時停止]
00:01:00皆さん、こんにちは！調子はいかがですか？
00:01:25Vercelコミュニティセッションへようこそ。
00:01:29皆さんにお会いできて本当に嬉しいです。
00:01:32今回初めて参加されるという方のために、
00:01:35自己紹介をします。Vercelコミュニティチームのポリーン・ナバスです。
00:01:40コミュニティスペースで見かけたことがある方もいるかもしれませんね。
00:01:44ライブで皆さんとお話しして
00:01:46つながることができるこの時間は、私にとっていつも最高のひとときです。
00:01:51すでに多くの方に視聴・参加いただいているようで、素晴らしいですね。
00:01:56セッションに初めて参加される方で、もしチャットが見えず、
00:02:00質問をしたいと思っているなら、
00:02:02ぜひやってみてください。強くおすすめします。
00:02:06まずは私たちのコミュニティプラットフォーム（community.vercel.com）に参加してください。
00:02:12そして、このイベントの「参加する」をクリックしてください。
00:02:15そうすれば、セッション中いつでもチャットで質問できるようになります。
00:02:20X（旧Twitter）や他のプラットフォームでご覧の方も、ぜひそちらからどうぞ。
00:02:25さて、今日のセッションですが、私はとてもワクワクしています。
00:02:28伝わっているかわかりませんが、今日は開発者のAIエージェントとの向き合い方を
00:02:32根本から変えるようなテーマを深掘りします。
00:02:36それは「Claude Code」の「スキル（Skills）」についてです。
00:02:39AIエージェントが、「Next.jsへの適切なアップグレード方法」や
00:02:44「チーム独自のコーディングパターン」を最初から知ってくれていたら……と思ったことはありませんか？
00:02:49それを可能にするのが、この「スキル」なんです。
00:02:51ということで、今日はVercelのAI DXチームから
00:02:56ジョンを招いて、ワークショップを進めてもらいます。
00:03:02ジョン、よろしくお願いします。
00:03:04>> やあ、ポリーン。
00:03:05皆さん、こんにちは。
00:03:05集まってくれてありがとう。
00:03:07>> お会いできて嬉しいわ。
00:03:09それじゃあ、始めましょうか。
00:03:12>> よし、やりましょう。
00:03:13さて、「スキル」についてですが。
00:03:15ずっと前からあるような気がしますが、まだ登場して2週間くらいでしょうか。時の流れは速いですね。
00:03:20今回はこのプレゼンテーションを使って、スキルについて解説していきます。
00:03:24デモもお見せしますし、この話題について話すのは大好きなので、
00:03:28質問があれば遠慮なく途中で割り込んで聞いてくださいね。
00:03:31まずは、スキルの作成と
00:03:35公開についてお話しします。
00:03:36実はこのプレゼン自体、「Remotion Geist Skill」というスキルで作ったものなんです。
00:03:42Vercelの定義したデザイン言語をRemotionと組み合わせて
00:03:46構築したもので、これものちほどお見せします。
00:03:48でも今は、まずいくつかのビデオを見ていきましょう。
00:03:51これまでは、長い間「プロンプト・エンジニアリング」が語られてきました。
00:03:55モデルの性能が今ほど高くなかった頃の話です。
00:03:58誰もがプロンプトを完璧にしようと躍起になり、
00:04:00プロンプト・エンジニアリングが将来の職業になるとさえ思われていました。
00:04:03しかし現在は「コンテキスト・エンジニアリング」へと移行しており、
00:04:08これらのスキル（Markdownファイル）を後から「遅延読み込み」させることが可能になっています。
00:04:13つまり、最初のプロンプトと、
00:04:17後から読み込まれる「コンテキスト」の断片が分離されているのです。
00:04:19これを私たちは「スキル」と呼んでいます。
00:04:22スキルの発端はAnthropicでした。
00:04:25彼らはClaude Codeに特定のタスクを教える必要がありました。なぜなら、
00:04:30あらゆるモデルは起動するたびに「白紙」の状態、つまり記憶がない状態から始まるからです。
00:04:33生まれたての赤ちゃんが何の技術も持っていないようなものです。
00:04:37頭の中に流し込まれた「固有の知識」しか持っていません。
00:04:42それ以外は、何もない状態からスタートします。
00:04:44そこでAnthropicは考えました。「これをどう解決するか？」
00:04:48答えはもちろん「Markdown」でした。最近のあらゆる問題がMarkdownで解決されるように、
00:04:51スキルもそこから誕生したのです。
00:04:55これによって、スキルをパッケージ化できるようになりました。
00:04:58スキルはMarkdownファイルなので、チーム間で共有したり、
00:05:04社内のワークフローをパッケージ化したりできます。
00:05:07GitHubリポジトリでパッケージ化して公開することも可能です。
00:05:12また、私たちが提供しているカスタムツールもあります。
00:05:15コミュニティスキルを管理するためのブラウザを少しお見せしましょう。
00:05:22skills.shというサイトがあります。
00:05:27ここではコミュニティが作ったスキルを検索できます。
00:05:29最もよく使われているスキルを探すこともできます。
00:05:32常に、信頼できるソースやチームメンバーからの
00:05:36信頼できるスキルであることをまず確認するようにしてください。
00:05:38そうすることで、自分の目的に合致したものを使えるようになります。
00:05:42使い方の詳細は後で説明しますが、
00:05:45このサイトはエコシステムやコミュニティ全体を検索して、
00:05:48どんなスキルがあるかを確認するのに最適な場所です。
00:05:50さて、ここからはこのワークショップでいつも教えている
00:05:56詳細な内容について、次のビデオに移りましょう。
00:06:00「白紙の状態」についてですが、
00:06:07繰り返しになりますが、赤ちゃんが生まれるのと同じで、エージェントが起動した直後は、
00:06:11（ここで言うエージェントとは、エージェントによって実行されるモデルのことですが）
00:06:14画面をもう少し大きくしましょうか。
00:06:16エージェントはReactやTypeScript、CSS、SQLなどの基本は知っています。
00:06:23しかし知らないのは、あなたのルール、パターン、
00:06:28システム、そして構造です。
00:06:30そこで、あなたがパーソナライズした情報と、
00:06:35エージェントが元々持っている知識を組み合わせることで、その知識のギャップを埋めるのです。
00:06:40コンテキストを持ち込み、スキルを読み込ませることで、
00:06:42エージェントに「まさにあなたが望む方法」でタスクを実行させることができます。
00:06:45つまり、彼らは「言語（TypeScriptやReact）」は知っていても、
00:06:51あなたのチーム独自の「方言」までは知らない、ということです。
00:06:53こう考えると分かりやすいでしょう。
00:06:54さて、ここまでで何か質問はありますか？
00:07:01見落としている質問はないかな？
00:07:03今のところ質問はありませんね。
00:07:06チャットは盛り上がっていますよ。
00:07:08ジョン、このまま続けてください。
00:07:09いきましょう。
00:07:11私はこれを「スキルのnpm的な瞬間」だと捉えています。
00:07:17npmは、多くの皆さんが使い慣れているパッケージマネージャーですよね。
00:07:23パッケージマネージャーには、コミュニティがまとめたリソースがあり、
00:07:27それを使うことで製品開発をよりスムーズに進めることができます。
00:07:30スキルや skills.sh を「スキルのためのパッケージマネージャー」と考えれば、
00:07:35エージェントにこれらの能力を「インストール」できるわけです。
00:07:39ライブラリをインストールするのと同じように、
00:07:41`npx skills add` を使ってプロジェクトに知識を追加できます。
00:07:45以前のプロンプト・エンジニアリングでは、`claud.md` や
00:07:52`agents.md` ファイルに「常にこうしろ」「ああしろ」と書き込んでいました。
00:07:55「このライブラリを使え」「Jiraを確認しろ」といった具合に延々と。
00:07:59しかし今は、それらの指示を「スキル」として追加し、
00:08:04プロジェクトに取り込むことができます。
00:08:06これらは永続的なものです。
00:08:08ユーザーレベルでもプロジェクトレベルでも共有できます。
00:08:11個々のプロジェクトから切り離すこともできるので、
00:08:14何度もコピー＆ペーストする必要はありません。
00:08:17自動化も可能なので、新しいプロジェクトを始めたら、
00:08:21必要なスキルをすべて一括で追加できます。
00:08:23つまり、膨大なプロンプトを構築することに
00:08:28頭を悩ませる必要はもうないのです。
00:08:30いいですね。
00:08:34こうした「能力」は永続的で、チーム全体で共有できます。
00:08:38プロジェクト内の `agents.md` や `claud.md` を
00:08:43管理する苦労を経験したことがあれば、
00:08:47それらのMarkdownファイルに対するプルリクエスト（PR）の処理などが
00:08:50いかに大変か分かるはずですが、この仕組みはその問題も解決します。
00:08:53「一人の開発者」対「チーム全体」という話ですね。
00:08:58さらに、これは「パッシブ（受動的）」対「アクティブ（能動的）」
00:09:03という考え方にも関係してきます。
00:09:05パッシブというのは、これらのスキルが
00:09:12必要になるまで読み込まれない、ということです。
00:09:15たとえば `agents.md` のような
00:09:22Markdownファイルはシステムプロンプトとして機能し、
00:09:25最初に読み込まれるものです。
00:09:26これは常に読み込まれた状態にあります。
00:09:28エージェントは必ずそれを読みます。
00:09:31これまでのテスト結果からも分かるように、
00:09:35そこに大量のコンテキストを流し込んで
00:09:38コンテキストウィンドウを埋めてしまえば、
00:09:41エージェントは確かにそれらのルール、
00:09:46例えば「常にTypeScriptとTailwindを使え」といった指示にはよく従います。
00:09:50一方で、スキルはより「アクティブ」な存在になります。
00:09:53手動で呼び出すこともできますし、
00:09:57エージェントが必要に応じて「遅延読み込み」し、
00:10:00必要なものを必要な時にだけ取り込むこともできます。
00:10:04「Vercelにデプロイする」とか「データベースを作成する」といった具合にです。
00:10:08つまり、これは「ルール」対「ツール」の関係であり、
00:10:13スキルを「ツール」だと考えてください。
00:10:15これら両方が常に必要になります。
00:10:18>> ジョン、ちょうど質問が届きました。
00:10:21今の話に関連する良い質問だと思います。
00:10:24「ある機能をMCPとして実装すべきか、
00:10:28それともスキルとして実装すべきか、どう判断すればいいですか？」
00:10:30>> 基本的には、
00:10:33いくつかの階層があると考えてください。
00:10:37説明のために、何か画面に図を出したいですね。
00:10:38これを使いましょう。
00:10:39>> ええ、お願いします。
00:10:40>> まず大前提として、問題をMarkdownで解決できるならそうしてください。
00:10:44Markdownで足りなければ、CLI（コマンドラインインターフェース）で解決します。
00:10:47CLIでも足りない場合に、初めてMCPで解決します。
00:10:51これが抽象化のレベル、
00:10:53あるいはシンプルさのレベルと言えるでしょう。
00:10:58もしMarkdownで解決する方法が見つかるなら、
00:10:59それはあらゆるAI駆動ツールに当てはまることですが、
00:11:01AnthropicがClaude Codeを設計した手法を見れば
00:11:05よく分かります。
00:11:08他社もスキルやコマンド、サブエージェントに関して、
00:11:11彼らの手法に追随しています。
00:11:13これらは基本的にフロントマターと
00:11:15設定を含むMarkdownファイルであり、ほとんどの場合はそれで十分です。
00:11:19そして、それらのMarkdownファイルの中で、必要なツールや
00:11:21呼び出しを許可するツール、
00:11:24制限事項などを定義できます。こうした設定を
00:11:29詰め切るには多少の時間がかかるかもしれませんが。
00:11:31しかし、エージェントとMCPの間で
00:11:37やり取りされるペイロードやデータ型などを
00:11:40厳密に制御する必要があるようなシナリオに
00:11:42直面した場合は、
00:11:43MCPが良い解決策になります。
00:11:46ただ、一般的な開発トレンドや
00:11:50現在のパラダイムとしては、CLIや
00:11:54Markdownファイルを優先し、MCPは本当に必要な時にだけ使うという方向へシフトしています。
00:11:59>> ええ、オンライン上の議論を見ていても
00:12:04そうした意見が多いようですね。
00:12:06Xからも別の質問が届いています。
00:12:10「素晴らしいですね！近い将来、
00:12:13スキルが『エージェント間での相互発見』をサポートする可能性はありますか？
00:12:17あるエージェントが、別のエージェントにスキルをインストールすることを
00:12:20自分で判断できたら面白いですよね」とのことです。いい質問ですね。
00:12:22>> その質問、最高ですね。「エージェント間（Agent to Agent）」というのは
00:12:27現時点ではまだ十分に活用されていませんが、非常に興味深いパターンです。
00:12:32もちろんです。エージェントの記述子を含んだ
00:12:39Markdownファイルが読み込まれるような形は十分にあり得ます。
00:12:42Claudeは現在、サブエージェントという形でこれをサポートしていますが、
00:12:46ちょうど今日、タイムリーなことに
00:12:49リリースされたばかりの「チーム（Teams）」機能についてお話しできます。
00:12:54これは、複数のサブエージェントのグループを生成し、
00:12:59メインのチームリーダーに報告させるというものです。
00:13:02今では「チーム」と呼ばれています。
00:13:04そして、それらのチームは基本的に
00:13:101人のチームリーダーによって管理され、ユーザーは
00:13:12エージェントが何をしているかを確認できます。
00:13:14それらのエージェントには、自身の役割の定義があり、
00:13:18それに関するドキュメントをすぐに見つけられるか探してみます。
00:13:23ジョンが探している間に、
00:13:30チャットに参加していて質問したい方は、
00:13:34今がチャンスです。何でもチャットに書き込んでください。
00:13:37セッション中にお答えしていきます。
00:13:40どこに貼ればいいかな、少なくとも
00:13:42Twitterのチャットには投稿できると思います。
00:13:47ここに、
00:13:51サブエージェントの定義方法が記載されたページがあります。
00:13:58フロントマター（設定）セクションがあるのが分かりますが、
00:14:01そのフロントマターセクションで、
00:14:03サブエージェントがアクセスできるスキルを定義できます。
00:14:08ですので、エージェントを作成したい場合、この例では
00:14:13スキルのリストを持つサブエージェントですが、
00:14:17スキルの名前を指定することで実行できます。
00:14:20まだ説明していませんが、
00:14:22次のスライドはスキルの構造についてです。
00:14:26スキルは、基本的にはただの「名前」です。
00:14:28したがって、特定のスキルセットを持つ
00:14:29サブエージェントを作成でき、
00:14:31非常に特殊なスキルを持たせて、
00:14:34そのサブエージェントにタスクを処理させることができます。
00:14:38今日リリースされた「チーム」機能で起きていることは、
00:14:43それらが、
00:14:45Claude Codeが自らチームを構築し、
00:14:48独自のエージェントを生成して、
00:14:49タスクに対して最善を尽くして取り組むということです。
00:14:53また、カスタムスキルを持つカスタムサブエージェントを定義して、
00:14:56「これらのサブエージェントを使って
00:14:57チームを作ってくれ」と指示することも可能です。
00:15:00ただ、これは厳密には「エージェント間通信」ではありません。
00:15:05それは、エージェント間の通信をどう設計するかという、
00:15:08より大きな議論になりますが、
00:15:11今回のスコープからは外れます。
00:15:12しかし、サブエージェントを定義する
00:15:14現在のこの手法は、
00:15:17将来的なエージェントの定義方法や、
00:15:21エージェント同士が通信する方法にも採用されるでしょう。
00:15:23エージェントの機能を公開する方法として、
00:15:24Markdownファイルを使って、
00:15:26「私にできることはこれです」と提示し、
00:15:28「監督、私を試合に出してください」というようなパターンを想像しています。
00:15:30「3ポイントシュートが打てます。リバウンドもできます。出してください」と。
00:15:32そういった形で、お互いを見つけることができるのです。
00:15:34そして、スキルのための skills.sh があるように、
00:15:39スキルのパッケージマネージャーのようなものも想定しています。
00:15:43エージェントとエージェント用のMarkdownファイルのための
00:15:47パッケージマネージャーも登場するでしょう。
00:15:49それは自然な流れです。
00:15:51すでに誰かが公開している
00:15:54可能性も高いですが、
00:15:57まだ主流にはなっていません。
00:15:58なるほど、非常によく分かります。
00:16:00ありがとうございます。
00:16:03皆さん、他にも質問があれば、
00:16:04チャットに書き込んでください。
00:16:06さて、ジョン、続けてもらえますか？
00:16:08ええ、もちろんです。
00:16:10スキルとは、ただのフォルダです。サーバーもホスティングも不要です。
00:16:12ディレクトリの中にスキルを置き、
00:16:15何らかの名前を付けますが、
00:16:20スキルのファイル名は skill.md にする必要があります。
00:16:24これにより、エージェントが探索パターンの中で
00:16:28スキルを見つけられるようになります。
00:16:31これは、ツールがより良く機能するように
00:16:32設定された一種の規約です。
00:16:35こうすることで、パッケージマネージャーの構築や
00:16:36整理などが非常に容易になります。
00:16:39さらに、スキルには他のものを同梱することも可能です。
00:16:41スクリプトを同梱したり、参照ファイルを持たせたり、
00:16:45スキル内で参照されている他のリソースに
00:16:49アクセスするためのあらゆる機能が含まれます。
00:16:53スキルにはフロントマターが含まれます。
00:16:56デフォルトでは、名前と説明が必要です。
00:17:01名前は、ディレクトリ構造での
00:17:04名前に合わせます。
00:17:08例えば、my-skill という名前で作るなら、
00:17:10ここも my-skill と命名します。
00:17:12そして「説明」が極めて重要です。
00:17:17なぜなら、そのスキルをいつ使うべきかを
00:17:20エージェントに教えるものだからです。
00:17:23エージェントは、
00:17:24与えられたタスクをこなしていく中で、
00:17:26「あ、セールス基準を強制する
00:17:29ツールが必要だ」と判断した瞬間に、
00:17:31このスキルを読み込みます。
00:17:33スキル読み込みツールを使用して読み込むわけです。
00:17:38ですから、この説明の書き方が重要になります。
00:17:41スキルを「レイジー（遅延）」な方法で使う場合は特にそうです。
00:17:42あるいは、スラッシュ（/）を使ってコマンドとして
00:17:43事前にスキルを呼び出すこともできます。
00:17:46コマンドとスキルの違いについてのスライドもあったと思いますが、
00:17:50基本的には、歴史的にこれらは別物でしたが、
00:17:52今は1つに統合されました。
00:17:55以前はスキルは遅延読み込みのみでしたが、
00:18:00現在はユーザーがスラッシュで呼び出すことも、
00:18:03エージェントが遅延読み込みすることも可能です。
00:18:04つまり、ここでスラッシュを入力すると、
00:18:08利用可能なスキルのリストが表示され、
00:18:12手動で呼び出すこともできますし、
00:18:17必要に応じてエージェントが呼び出すのを待つこともできます。
00:18:19さて、ここからは、
00:18:22これについても触れると思いますが、
00:18:27個人的には具体的な例を聞きたいです。
00:18:32このモデルを理解するために、まず最初に作るべき
00:18:39小規模で範囲の明確なスキルのおすすめはありますか？
00:18:43おっと、それは良い質問ですね。では、今、
00:18:47最適だと思う例を1つ挙げます。
00:18:52Vercelにおいて私たちが直面しているスキルの問題は、
00:18:55非常に速いペースで
00:18:57リリースを行っているという点です。
00:19:03エージェントやモデルには知識のカットオフ日があり、
00:19:07それは数ヶ月前から1年以上前だったりします。
00:19:12そのため、デフォルトのまま
00:19:15エージェントにタスクを与えると、数バージョン古い
00:19:19Next.js 14を使ってしまうかもしれません。
00:19:24あるいは、最近 `generateObject` を非推奨にし、
00:19:30APIの標準化のために
00:19:33それを `generateText` に統合した
00:19:35AI SDKを使おうとしたりします。
00:19:39そういった場合に、
00:19:41エージェントが古いバージョンを使おうとし、
00:19:45ユーザーは最新のドキュメントを読みながら作業しているという、
00:19:50同期が取れていない、古い情報に基づいた状況が発生します。
00:19:51そうなると、プロジェクトは何が必要なのかを
00:19:53把握しようとして、しばらく停滞してしまいます。
00:19:54そこでエージェントとの足並みを揃えるために、
00:19:56「このバージョンのReactを使え」「このバージョンのAI SDKを使え」
00:20:00「このバージョンのWorkflowを使え」というような、
00:20:03単なる指示のようなスキルを作成できます。
00:20:05そして、それらの情報を
00:20:08どこで見つけるべきかの参照先を提示します。
00:20:11例えば、私がVercelのために構築した
00:20:16スキルをお見せしましょう。
00:20:18これは数日前にリリースした
00:20:19Vercel Workflowのスキルです。
00:20:22私たちがこれをどう活用しているかというと、
00:20:28バージョンの不一致を非常に懸念しているため、
00:20:33NPMパッケージと一緒にドキュメントを公開し始め、
00:20:40エージェントに「君のWorkflowの知識は古い」と伝えます。
00:20:43WorkflowはGAに向けてほぼ毎日更新されていますからね。
00:20:46そこで「ドキュメントを同梱したから、
00:20:49Workflowを調べる必要があるときは、
00:20:50同梱されたドキュメントと最新情報を確認してくれ」
00:20:54と指示するのです。
00:20:58これにより、Workflowの作業を始める際、
00:20:59古い情報に基づいてしまう心配がなくなりました。
00:21:02常にNPMパッケージに同梱された情報が参照され、
00:21:06パッケージのバージョンと足並みが揃うようになります。
00:21:10このスキルの本質は、いくつかの重要なベストプラクティスの
00:21:11クイックリファレンスと共に、
00:21:13「マニュアルを読め」と言っているだけのようなものです。
00:21:16これらは、エージェントの知識のカットオフ日や、
00:21:18バージョンの不一致といった問題に
00:21:22対処するためのスキルです。
00:21:25自分自身のために書けるスキルとしては、
00:21:27例えばこのスキルを使えば、
00:21:32「create skill」というスキルを紹介しましょう。
00:21:34skills.sh で「create skill」を検索すると、
00:21:38ええと、
00:21:42「create skill」を手に入れたら、
00:21:44おそらくClaude Codeチームのものがいいでしょう。
00:21:48Claude、彼らが公開していたはずです。
00:21:53すみません、これは事前に予定していませんでした。
00:21:57いえ、それを探している間に、
00:22:01どうぞ、見つかりましたか。
00:22:07Claude Codeではなく、
00:22:11Anthropicで考えるべきでした。
00:22:14彼らの「create skill」やパターンを取り込めば、
00:22:23「create skill」と入力して、
00:22:28例えば「readme.mdファイルの
00:22:33私のライティングスタイルを見て、
00:22:39常にこのスタイルに従うスキルを作ってくれ」と言えます。
00:22:42すると、READMEにある内容を読み取って、
00:22:46あなたのパーソナライズされた
00:22:47ライティングスタイルを再現するスキルが作成されます。
00:22:49それ以降は、そのスキルを呼び出して
00:22:50「ジョンのライティングスタイルで」といった指示ができるようになります。
00:22:54大量のドキュメントを読み込ませたり、
00:22:58ブログ記事や自分の投稿、顧客とのやり取りのURLを読み込ませたり、
00:23:02とにかく何でも流し込むことができます。
00:23:09「すでに持っているもので、
00:23:12再び再現したいものは何か？」と考えるのが、
00:23:14常に良い出発点になると思います。
00:23:19「頻繁に使っていて、
00:23:21これからも多用することが分かっているものは何か？」と。
00:23:23それは大抵の場合、顧客へのメッセージや、
00:23:26ブログ、コンテンツ、過去に制作して
00:23:28もっと増やしたいと思っている資料などです。
00:23:31ですから、そういった「スタイル」は取り組むべき絶好の初歩スキルです。
00:23:33それは本当に素晴らしい例ですね。
00:23:37間違いなく試してみます。
00:23:38ここで、いくつかコメントを
00:23:40読み上げたいと思います。
00:23:42皆さんから寄せられた意見ですが、
00:23:43例えば 自分が常に使っているものや
00:23:46今後さらに活用していく予定のものなどです
00:23:50具体的には 顧客へのメッセージングや
00:23:53ブログ、コンテンツ、資料など
00:23:56過去に作成したことがあり
00:23:57今後も量産したいと考えているものです
00:23:59ええ 最初に手をつけるスタイルとしては最適ですね
00:24:04それは本当に良いアイデアですね
00:24:05ぜひ試してみたいと思います
00:24:06ここでチャットに寄せられた
00:24:08コメントをいくつか紹介させてください
00:24:10デイブさんからのコメントです 「私たちはスキルを作成し
00:24:1410年間コードを書いていなかったスタートアップの創業者が
00:24:17コードに貢献できるようにしました
00:24:19新しいコードベースにおける設計上の境界線を
00:24:23踏み越えてしまうことなく実現できたのです」
00:24:24「これはスキルの非常に優れた活用例だと思います
00:24:27非エンジニアやコーディング初心者でも
00:24:30コーディングという行為に参加でき
00:24:32品質基準を損なうこともありません」とのことです 素晴らしいですね
00:24:38また デイブさんは先ほどこうも言っていました
00:24:42「ジョンの言うことに同感です」
00:24:45最近よく使われているツールについてですね
00:24:47彼が使っているMCPツールは Chrome DevToolsと
00:24:52LinearやJiraのようなプロジェクト管理ツールと連携するもの
00:24:56そしてデータベースを操作するためのものだけだそうです
00:24:59まさに先ほどあなたが話していた内容の裏付けですね
00:25:02次に進む前に チャットで質問をいただいています
00:25:07弊社のブログ記事「エージェント評価」の中で
00:25:12agents.mdがスキルを上回った結果についての見解です
00:25:17プレゼンの中で後ほど
00:25:19触れる予定があるかは分かりませんが
00:25:21話がいくつか脱線してしまっていますが
00:25:25今その件についてお話しいただけますか？
00:25:27ええ、もちろんです
00:25:28モデルやエージェントの評価というのは
00:25:34非常に難しい課題です
00:25:38多くの場合 評価用のテスト（evals）を書く際
00:25:42文脈が何も読み込まれていない
00:25:46新しく空のプロジェクトに対してテストを行います
00:25:49「この空のプロジェクトでNext.jsを使ってみて」といった
00:25:51特定のシナリオを一つ与えるわけです
00:25:56そのような評価テストを書いたとしても
00:25:59考慮すべき要素は他にもたくさんあります
00:26:03例えば 今日Opus 4.6がリリースされたとか
00:26:05使用しているモデルが何であるか
00:26:07プロジェクトの追加のコンテキスト
00:26:10あるいはエージェントや実行環境（runner）などです
00:26:13Cloud Codeには独自のシステムプロンプトがあり
00:26:16Cursorにも別のシステムプロンプトがあります
00:26:17このように非常に多くの変数があり
00:26:21モデル自体もご存知の通り
00:26:24非決定的（ランダム性がある）なものですから
00:26:26テストをすること自体が極めて困難なのです
00:26:31それを踏まえた上で agents.md 対 スキルという話は
00:26:37「コンテキストを強制的に与えるか」対「遅延読み込みするか」の違いです
00:26:42そのブログ記事の内容を要約して
00:26:47「強制的に与える方が遅延読み込みより優れているか？」と問われれば
00:26:51答えは「イエス」になります
00:26:53なぜなら それはエージェントのライフサイクルの
00:26:57最初にある最も重要な「初期命令」として
00:27:00扱われることになるからです
00:27:03それは単にエージェントに対して
00:27:08「これが今取り組んでいる課題だ」
00:27:10「これが最善の方法だ」と教え込んでいるようなものです
00:27:12実は その点に関連して
00:27:14最後に紹介しようと思っていた機能があります
00:27:16スキルを事前にプライミング（準備）したりプリロードしたりする方法です
00:27:20結局のところ これは
00:27:25モデルというものの仕組み上の話なのです
00:27:29ですから あのブログ記事が
00:27:33「スキルが劣っている」という意味に取られないことを願います
00:27:35もし特定の指示を「絶対」に常に守らせたいのであれば
00:27:39agents.mdファイルを使うのが正解だ ということだと
00:27:42私は解釈しています
00:27:44もう1週間くらいその記事を読んでいませんが
00:27:48ええ、それは非常に理にかなっていますね
00:27:50素晴らしいです
00:27:51コミュニティの皆さんも もし他にも
00:27:53質問があればどんどん投稿してください
00:27:56それではジョン 続けてください
00:27:57わかりました
00:28:01さて スキルファイルの実体はただのMarkdownです
00:28:04この例を見てください 「命令（instructions）」があり
00:28:06Reactコードをレビューする際はサーバー専用にし 最適化する…といった
00:28:09実行してほしい内容を
00:28:12リスト形式で記述しています
00:28:14また 参照させたいスクリプトや
00:28:19呼び出したい機能などを
00:28:21パッケージ化して含めることができます
00:28:25モデルに見せたいものを一つにまとめたバンドルのようなものです
00:28:30よし
00:28:32つまり スキルを導入することは
00:28:37シニアエンジニアをエージェントとして追加するようなものです
00:28:38では 先へ進みましょう
00:28:42ユースケースについてです
00:28:46全画面表示にしますね
00:28:49さて いくつかのパターンがありますが
00:28:52「Reactのベストプラクティス」は
00:28:57スキルのパッケージマネージャーで
00:29:00おそらく最もダウンロードされているスキルの一つです
00:29:02これは単に ベストプラクティスが何であるかを
00:29:08再強化する役割を果たします
00:29:09モデルが学習した内容を超えた部分でも有効です
00:29:12モデルはあらゆる人のコードで学習されていますが
00:29:14皆さんは特定の自分たちのパターンに従わせたいはずですからね
00:29:18次にこちらです
00:29:21ワークフローの自動化です
00:29:26何かをZIPファイルにまとめたいといった場合
00:29:27それはもはや
00:29:30「自然言語で書かれたスクリプト」のようなものです
00:29:34最近のアプリケーションについて よくこう考えます
00:29:40それは 単なるスクリプトへと削ぎ落とされるか
00:29:44あるいはエージェントへとアップグレードされるかのどちらかだと
00:29:47入力に対して常に出力が一致するような
00:29:50決定論的な出力が必要な場合もあれば
00:29:53データが完全には一致しない場合に
00:29:56どう対処すべきか判断できるエージェントが必要な場合もあります
00:29:59ですから スクリプトではなく
00:30:02賢くファイルをまとめられるような自動化を作りたいなら
00:30:07エージェントを活用できます 例えば
00:30:10エージェントに「git commit」を指示したときに
00:30:15「プロジェクト内に動画ファイルがあるのを見つけました」
00:30:20「動画はバイナリデータ（blob）であり
00:30:25追加すべきではないため 無視します」といった具合に
00:30:26通常 そうした判断をインテリジェントに行えます
00:30:29もしスクリプトでこれを書くなら
00:30:30あらゆるシナリオを想定して記述しなければなりません
00:30:33自動化を構築したいのであれば
00:30:36一連のイベントを設定することで エージェントが実行してくれます
00:30:41それからガードレール（制約事項）もそうです
00:30:44「指示書を確認してください」「ガイドラインを参照してください」
00:30:49「カラーコードを確認してください」といった情報の供給です
00:30:53これらは事前（upfront）に読み込ませておくのが有効で
00:30:56エージェントが、まあサブエージェントなど
00:31:00ガードレールに関しては高度なシナリオも多々あります
00:31:02それはまた別の日のワークショップの話題ですね
00:31:07さて 繰り返しますが 標準の強制、
00:31:12パイプラインの自動化、そしてシステムの保護です
00:31:17よし これをやりましょう
00:31:21では 今日のライブデモの部分は飛ばしますね
00:31:30はい では「公開（パブリッシング）」について話しましょう
00:31:37公開とは 本質的にはGitHubにプッシュするだけです
00:31:46そうすれば 誰でもあなたのGitHubリポジトリを
00:31:51参照して スキルを追加できるようになります
00:31:52正確なリンクを探し回る必要はありません
00:31:56skills.shでスキルの追加方法を
00:32:00見てみると 分かると思いますが
00:32:04例えば「browser-use」を適当に選んでみると
00:32:08スキルをインストールするためのコピペ用リンクが表示されます
00:32:11しかし 単に追加するだけでも可能です
00:32:13私の環境には browser-use は入っていないはずなので
00:32:14これをコピーしてデモをしてみます
00:32:18タブを開いて このように実行します
00:32:23スキルファイルを個別に
00:32:29手動で指定しなくても GitHubリポジトリを教えるだけで
00:32:31勝手に見つけに行ってくれます
00:32:34「install-skill-package」を使います
00:32:36どのエディタを使いたいか聞かれます
00:32:39今は Cloud Code を選択します
00:32:42プロジェクト内に入れるか グローバルに入れるか聞かれるので
00:32:45プロジェクト内とし シンボリックリンクを許可することで
00:32:49すべてが同じファイルを参照できるようにして 実行します
00:32:53正確なファイル名を
00:32:55指定しなかったにもかかわらず Claudeのスキルを見つけてくれました
00:33:00browser-use には「skill.md」ファイルがあるからです
00:33:09では 中身を見てみましょう
00:33:13おっと スキルを表示します
00:33:18彼らが browser-use スキルとして
00:33:22同梱しているものが確認できます
00:33:26冒頭はMarkdownから始まっています
00:33:27かなり長いスキルですね
00:33:32名前と説明があり「許可されたツール（allowed tools）」があります
00:33:35これは ユーザーの承認なしに
00:33:39browser-use の使用を許可するスキルであることを示しています
00:33:42つまり browser-use に関連するものであれば
00:33:47何でも許可するという権限を与えています
00:33:49このスキルを呼び出せば
00:33:50いちいち browser-use の使用を承認する必要がなくなります
00:33:53また インストールされていない場合の
00:33:56インストール方法や
00:33:58ツールの基本的な使い方も教え込んでいます
00:34:04よし では戻りましょう
00:34:09ええ 単にMarkdownファイルを
00:34:15GitHubリポジトリにプッシュすれば `skills add` で追加できるようになります
00:34:19繰り返しになりますが 信頼できるスキルのみをインストールしてください
00:34:23これらはnpmパッケージやスクリプトと同様に
00:34:26扱うべきものです どこの誰が書いたか分からない
00:34:31適当なスキルやnpmパッケージを安易に使わないでください
00:34:35何を仕込んで公開しているか分かりませんからね
00:34:38必ず信頼できるものを使うようにしましょう
00:34:40さて プライベートリポジトリや
00:34:45Gitのサブモジュールも利用可能です
00:34:48そしてコミュニティレジストリについても
00:34:51すでに何度かお見せしましたね
00:34:54よし 順調です
00:34:55Markdownファイルを作成して
00:35:00それをGitHubリポジトリに公開すれば
00:35:02誰でも発見してインストールできるというわけです
00:35:05では 実際に「awesome-skills」を使ってみましょう
00:35:09これに踏み込む前に、何か質問はありますか？
00:35:13ええ、実は先ほど質問がありました。
00:35:16全く未知のパッケージやライブラリの例を、
00:35:21LLMの学習データに含まれていないと仮定して、
00:35:26LLMがそれを見る必要があるのは、どのくらいでしょうか？
00:35:28そのパッケージを「スキル」として適切に使い、
00:35:31良い結果を得るためには？
00:35:33良い結果を出すために、いくつ必要か？ということですね。
00:35:36すみません、もう一度質問を読んでもらえますか？
00:35:39ええ、もちろんです。
00:35:40LLMの学習データに含まれていない、
00:35:45全く未知のパッケージやライブラリを、
00:35:49スキルとして使うためにLLMがどれだけの例を見る必要がありますか？
00:35:53つまり、スキルの中にどれだけの例を
00:35:55放り込むべきか、ということですね。
00:35:56はい、そうです。
00:35:57本質的に、考えるべきことは
00:36:00含める例の「数」を考えるのではなく、
00:36:05目次や章がある「本」のようなものだと
00:36:09考えることです。
00:36:12エージェントがある状況に直面したとき、
00:36:14取扱説明書を渡すようなものです。
00:36:17車のマニュアルなどを持っている場合、
00:36:21ページをめくりたいのは、
00:36:26「エンジン警告灯がついたとき」だけですよね。
00:36:29タイヤについてのページなどを
00:36:32読む必要はありません。
00:36:33ですから、スキルの構造を
00:36:36メインとなるスキル、つまり
00:36:38「車のマニュアル」がある状態にします。
00:36:40そして、もしエンジン警告灯について、
00:36:44あるいはグローブボックスの使い方を知る必要があるなら、
00:36:49その特定のページへ行き、
00:36:51別のMarkdownファイルを読み込んだり、
00:36:53そのタスクに特化した詳細情報を読み込んだり
00:36:57させればよいのです。
00:36:58車が機械として全体でどう動くかといった
00:37:01大量の例を一度に流し込もうとするのではなく、
00:37:06細分化するのです。
00:37:11これを手動で入力しろと言っているわけではありません。
00:37:14エージェントにスキルを作成させる際、
00:37:18この本の「どの章」がいつ必要になるかを
00:37:23整理させるようにしてください。
00:37:26そうすればいいのです。
00:37:27同様に、スキルはリファレンスを持ち、
00:37:30目の前のタスクに基づいて
00:37:33追加のコンテキストを必要に応じてロードできます。
00:37:35多くのライブラリの場合、
00:37:39例えばNPMパッケージを考えてみてください。
00:37:43実際にインポートするのは数個のメソッドだけです。
00:37:45日付ライブラリのすべての関数が
00:37:48必要になるわけではありませんから。
00:37:50コンポーネントライブラリの
00:37:52すべてのコンポーネントも必要ありません。
00:37:53特定のタスクに要求される、
00:37:57特定のものの例だけがあればいいのです。
00:37:59ですから、必要性、タスク、要件ごとに
00:38:03分解して考えるようにしてください。
00:38:07コードベース全体をプロジェクトに
00:38:11無理やり詰め込むのではなく。
00:38:12非常によく分かります。
00:38:14もう一つの質問ですが、エージェントがスキルから
00:38:17本当に新しいパッケージを学んだかどうかを
00:38:21どうやってテストしますか？
00:38:22チームに展開する前に、検証するために推奨する
00:38:25単純なプロンプトや評価パターンはありますか？
00:38:29一般的な総意であり、私も支持しているのは、
00:38:37とにかく何かを作って使ってみて、
00:38:40どこで失敗するかを確認し、改善することです。
00:38:43それが「エージェンティックな開発」の考え方です。
00:38:49どう整理し、計画し、完璧なスキルとは何かを
00:38:54考えすぎるのではなく、
00:38:57まず作り、失敗する箇所を見つけ、
00:39:00それを繰り返して磨き上げるのです。
00:39:01私はこれまで、9つ以上の、
00:39:08あるいはそれよりもずっと多くの
00:39:13Claude Codeのセッションを立ち上げ、
00:39:15それぞれ異なるスキルを読み込ませて比較しました。
00:39:17そうすると、多くの異なる例が得られますが、
00:39:19どの例が人間の目で見て
00:39:24最も優れているかを判断したり、
00:39:26Claude自身に結果を評価させたりすることになります。
00:39:29それは現状、不可能に近いタスクになってしまいます。
00:39:34ですから基本的には、スキルを使ってみて、
00:39:37それは単なるMarkdownファイルですから、
00:39:39チームで更新するか、
00:39:40エージェントに更新を依頼してください。
00:39:43会話の最後でできることは、
00:39:46何かが失敗したときにこう言うことです。
00:39:49「現在の会話に基づいてスキルを更新してください」
00:39:54といった具合に。
00:39:56するとエージェントはMarkdownファイルを見つけ、
00:40:00更新して変更をプッシュしてくれます。
00:40:02それが今のところ、
00:40:08私たちのやり方です。
00:40:09もちろん、バージョン番号などの要素が
00:40:13さらなる問題を引き起こすこともあります。
00:40:16しかし、モデルのスキル読み込み能力は
00:40:19着実に向上しています。
00:40:21Opus 4.6対4.5や、GPT 5.3対5.2の
00:40:24スキルに関するベンチマークがどうなっているかは知りませんが、
00:40:29それらは今日の午前中よりも、
00:40:33今のほうが良くなっているはずです。
00:40:35つまり、これらはよくある問題の一つで、
00:40:40「完璧なものを作らなければ」と考えて、
00:40:42数週間かけてようやく出荷したと思ったら、
00:40:44その間にモデルが5回も変わっていた、
00:40:46なんてことになりかねません。
00:40:48タスクを開始してからね。
00:40:49完璧を目指して時間をかけるより、
00:40:52リリースして改善を繰り返すほうが
00:40:56賢明だというのが、私からの最高のアドバイスです。
00:40:58ええ、「反復して偉大さに到達する」ですね。
00:41:00そうですよね、ジョン？
00:41:01ITG（Iterate To Greatness）です。
00:41:02ええ、ITG。
00:41:04先に進む前にもう一つだけ質問させてください。
00:41:08スキルに例を追加しすぎると、
00:41:10挙動が改善されなくなったり、
00:41:13むしろモデルが混乱したりする、収穫逓減のポイントはありましたか？
00:41:17それはありませんね。
00:41:23私はスキルファイルに情報を詰め込みすぎないようにしています。
00:41:27私が使っている「スキル作成スキル」は、多くの分離を行ってくれます。
00:41:33正確にどれだったか確認する必要がありますね、
00:41:35เพราะที่ผ่านมาฉันใช้ของคนอื่นตลอดเลย
00:41:37画面外で調べてみます。
00:41:40これは、設定ファイルに関わることなので――
00:41:42ええ、一旦画面を外してください。
00:41:45準備ができたらまた戻しましょう。
00:41:47では、探してみます。
00:41:49現在、配信の視聴者が200人ほどに達しました、
00:41:52素晴らしいですね。
00:41:57皆さん、こんにちは。
00:41:58今参加された方は、
00:41:59気軽にチャットに質問を投げてください。
00:42:01ジョンにぶつけてみますので。
00:42:03ええ、喜んでお答えします。
00:42:07私が使っているものを見つけなければ。
00:42:12よし、良さそうですね。
00:42:16使っているのがどこから来たのか探す必要があります。
00:42:19インストールされた後に、元のURLが残っているか
00:42:27分からないのですが、
00:42:29NPXや「skills」コマンドなら
00:42:32その情報を持っているかもしれません。
00:42:36配信中にランダムなコマンドを実行したくはありませんが。
00:42:37これには実際、
00:42:433レベルのローディングシステムが指定されています。
00:42:44メタデータ、バンドルされたリソースがあり、
00:42:47リソースと追加の指示に
00:42:49明示的に分解するように指示しています。
00:42:54私はエージェントを使ってスキルを生成させています。
00:42:57それ以来、ずっとこの方法でやっています。
00:43:02以前はClaude Codeのドキュメントを
00:43:07エージェントにコピー＆ペーストして、
00:43:11「このドキュメントに基づいてスキルを作って」と言っていました。
00:43:13今はそのための「スキル」を使っています。
00:43:15そして、あまり多くの例を流し込もうとしたことはありません。
00:43:17いくつかの一般的なルールがあるのは知っています。
00:43:23例えば、スキルファイルを200行以内に抑えるといったことですが、
00:43:28これもモデル次第ですし、
00:43:31モデルはどんどん良くなっています。
00:43:35ええ、これには「200行以内」とありますね。
00:43:36やりすぎず、ミニマムを保つのがいいでしょう。
00:43:39もし不足があれば、その時に解決してください。
00:43:44特にその分野の専門家であれば、
00:43:47不足している部分は見極められるはずです。
00:43:50専門外のスキルで、
00:43:52不慣れなものを使い始める場合は、
00:43:56放置せずによく観察してください。
00:43:58巨大なエージェント・オーケストレーションを構築して、
00:44:01全く知らないスキルをインストールし、
00:44:03すべてが期待通りに動くとは思わないことです。
00:44:06それらは監視する必要があります。
00:44:08ええ、全くその通り、本当に良いアドバイスです。
00:44:11素晴らしい。
00:44:13よし。
00:44:17例えば、このプロジェクトで作った動画は、
00:44:20すべて「create remotion geist」スキルで作られました。
00:44:22これは skills.sh で公開されています。
00:44:28検索すれば出てきます。
00:44:34そして「Geist」について。
00:44:37Geistはブラジルのデザインシステムで、
00:44:39Remotionは、画面外で調べさせてください。
00:44:43プログラムで動画を作成する方法です。
00:44:48私はRemotionのスキルを組み合わせ、
00:44:53実質的にGeistのスキルを作りました。
00:45:01ブラジルのリポジトリの一つに行き、
00:45:05ホームページやドキュメントにあるものすべてから、
00:45:09デザイン情報、スキル、テーマ、フォント、
00:45:12レイアウト、アドバイスなど、あらゆる情報を抽出して
00:45:15スキルを作成してほしいと言いました。
00:45:19それだけで、つまり、
00:45:23このRemotionスキルと、
00:45:25サイトにあるこれらのデザイン情報を
00:45:27すべて取り込んで新しいスキルを作成し、
00:45:30「create remotion geist」と名付けて、と言っただけです。
00:45:32その作業だけで、このような動画を
00:45:37作成することができました。
00:45:41非常にブランド化された、ブラジル・デザインのスキルです。
00:45:43動画をもっとズームさせるべきかもしれませんね。
00:45:48その結果 こうした動画を作ることができました これらはまさに
00:45:57ブランド化された Vercel風のデザインスキルによるものです
00:46:01動画をもう少しズーム表示させたほうがいいかもしれませんね
00:46:04この最終的な仕上がりを見ると
00:46:07少しズームアップすべきだったと思いますが
00:46:09要するに これらはすべて自動生成されたもので
00:46:12その間 私はサンドイッチを買いに行っていたんです
00:46:14これらの動画はすべて ワークショップの進行について
00:46:16私が作成したアウトラインに基づいています
00:46:18「アウトラインと調査資料に基づいて 動画を全部作って」と指示すると
00:46:20最後にこれらの動画がすべて出力されました
00:46:22ここでも「スキル」が役立っています
00:46:24Vercelのリポジトリ内で
00:46:29「スキルを作成」を実行し
00:46:33「それらすべてを取り込んで
00:46:36Remotion作成スキルと組み合わせて」と伝えるだけです
00:46:38それで準備は完了です
00:46:41それをチームで共有すれば 誰でも作成できるようになります
00:46:42繰り返しになりますが 私が費やした労力と時間は
00:46:43おそらく数分程度です
00:46:45もちろん エージェントがデザインなどの
00:46:47あらゆる情報を見つけ出すのには時間がかかりました
00:46:50総稼働時間はおそらく2時間ほどでしたが
00:46:54私が実際に費やした労力は 極めて最小限でした
00:46:55私が他の作業をしている間に バックグラウンドで実行されていたのです
00:46:57ですから 皆さんの既存の仕事の中から
00:46:59このようにパッケージ化して構築できるものを ぜひ探してみてください
00:47:03同様に Geistのデザインスキルを使えば
00:47:06もっと見栄えの良いサイトを作りたい場合に
00:47:08Geistのデザインを適用して
00:47:09「ワークショップ・フォルダー内に
00:47:11このワークショップ用のランディングページを作って」と指示できます
00:47:15すると ワークショップ・フォルダーが作成され
00:47:17そこにあらゆるデザイン情報が流し込まれ
00:47:19その情報に基づいてページが構築されます
00:47:24今日のOpus 4.6の機嫌次第で
00:47:27うまくいくかどうかは分かりません
00:47:31開始数分前にリリースされたばかりなので まだテストできていないんです
00:47:35しかし 必要な情報はすべて揃っているので
00:47:39作業を開始できるはずです
00:47:46同様に 全く別のサイト用に
00:47:50新しいスレッドを開始することもできます
00:47:55例えば「car」フォルダーに
00:47:58「かっこいい車のランディングページ」を作るとしましょう
00:48:01私は車に詳しくありませんが
00:48:04そこから こうしたことを次々と始められます
00:48:06アイデアやデザインを考えようとしているなら
00:48:11特に新しいチーム機能を使った 最高のプロンプトがあります
00:48:14Geistのデザインを実行して こう指示します
00:48:17「ワークショップ・フォルダー内に
00:48:20workshop-variationsというフォルダーを作って」
00:48:25「ランディングページを作って」
00:48:29「このワークショップ用に 9つのパターンの
00:48:34ランディングページを作って」と伝えます
00:48:36チーム機能があるので こうも言えます
00:48:40「チームメンバーを使って
00:48:419つのパターンを構築するためのチームを作って」といった具合に
00:48:46普通の話し言葉で指示するだけです
00:48:49するとチームが立ち上がり
00:48:54あらゆる作業が動き出します
00:48:57これで私はサンドイッチを食べに行けますね
00:48:59お腹が空きました ちょうど昼時ですし
00:49:09戻ってくる頃には
00:49:12これはTailwind 4を使っていますが かなり順調に進んでいるのが分かります
00:49:17戻ったら すべてのバリエーションを確認して
00:49:22気に入るものが見つかるまで 反復作業を行うことができます
00:49:23これがもうすぐ終わるはずなので
00:49:28いくつかのデバッグツールもお見せしましょう
00:49:34ジョン 誰かがチャットで言っていましたが
00:49:38「プロンプトの最後に『お願いします（Please）』と付けるのが
00:49:40最高のプロンプトの一つだ」そうです
00:49:41ああ そうですね その通りです
00:49:44お願いします
00:49:47モデルの違いや 励ましに対してどう反応するかについては
00:49:49多くの研究結果があります
00:49:52私がこれらのエージェントに
00:49:54プロンプトを出す際によく使うペルソナの一つは
00:49:55「Stack Overflowの回答者のように振る舞って」というものです
00:49:56私の質問に対して非常に批判的で
00:49:58「それはもう回答済みだ」とか言ってくるような設定です
00:50:03しかし 回答そのものは非常に簡潔で
00:50:09私の質問に対して的確に定義されたものになります
00:50:11最近はあまりペルソナの話はしなくなりましたね
00:50:12以前ほどモデルを追い込む必要がなくなったからです
00:50:14今のモデルは以前よりずっと優れていますから
00:50:17タスクを強制させる必要は
00:50:18それほどありません
00:50:21チャットでも誰かが言っていましたが
00:50:23「お前はクビだ」と言うと
00:50:27パフォーマンスが上がるモデルもあるらしいです
00:50:33うまくいかない時にですね
00:50:36それがどれほど本当かは分かりませんが 面白い話です
00:50:41それは間違いなく本当ですよ
00:50:45最近は言い返してくるモデルもあります
00:50:48GPT系のモデルの中には
00:50:51「その口の利き方は何だ」と言ってくるものもありました
00:50:56すごいですね 驚きました
00:51:02自分たちがボスだと思っているんでしょうね
00:51:04バックグラウンドでサーバーを起動するように指示しておきます
00:51:06（キーボードを打つ音）
00:51:10スキルを構築することもできます
00:51:111段落分くらいの長い文章を打っている時に
00:51:15「これは何度も打つことになるな」と気づく瞬間があります
00:51:18そう思ったら その段落を打った後に
00:51:20「今の内容からスキルを作成して」と言えばいいんです
00:51:22さて 車のサイトができているはずです
00:51:25どうなったか見てみましょう
00:51:27「魂を揺さぶる車」
00:51:32非常に白黒がはっきりした Vercel風のデザインですね
00:51:34画像はどこから持ってきたんでしょうか
00:51:35これらが「かっこいい車」だと思っているようです
00:51:38こんな感じです
00:51:39ランディングページはもう何百万回も見てきたかもしれませんが
00:51:46非常に標準的な仕上がりです
00:51:49Geistのデザインガイドラインに
00:51:50しっかり従っています
00:51:52ここから さらに活用できます
00:51:54最近Vercelからリリースした 素晴らしいパッケージの一つに
00:51:56Agent Browserというものがあります
00:51:59Agent Browserというスキルがあり
00:52:01Vercel Labsのリポジトリにあるはずです
00:52:03これはChromeのデベロッパーツールを開き
00:52:07接続をセットアップしてくれるので
00:52:09「評価して」といった指示が可能になります
00:52:14入力してみますね
00:52:16「このウェブページのパフォーマンスを評価して
00:52:18ユーザーのために最適化できる点がないか確認して」
00:52:22するとAgent Browserが
00:52:27自動化ツールやデベロッパーツールを使って ログを調査します
00:52:29ネットワークツールを確認したり
00:52:34スクリーンショットを撮ったりすることもできます
00:52:36私が特にお気に入りの使い方は
00:52:42スクリーンショットを繰り返し撮らせて
00:52:44何が作成されたかをエージェント自身に確認させることです
00:52:47その後で こう指示します
00:52:54「このデザインを XやYやZのような
00:52:56見た目に近づけていって」
00:53:01そして スクリーンショットを撮るたびに
00:53:06コミットを実行させるようにします
00:53:08そうすることで
00:53:11どのようなコミットが行われ
00:53:13デザインがどう変更されたかを 遡って確認できるのです
00:53:15エージェントが実際にクエリセレクタを調べ
00:53:17パフォーマンスの最適化方法を 検討しているのが分かります
00:53:18これを展開して 開発サーバーを起動しましょう
00:53:23バックグラウンドで処理が走っている間に
00:53:26他に何か質問はありますか？
00:53:28これほど多くのプロセスが同時に動いているのを見るのは 壮観ですね
00:53:30本当に素晴らしいです
00:53:32チャットには具体的な質問は来ていません
00:53:36皆さん 様々なプロンプトやアイデアについて
00:53:41会話を楽しんでいるようです 良い傾向ですね
00:53:44ジョン 私から一つ質問させてください
00:53:47「失敗した会話」に基づいて
00:53:49エージェントにスキルを更新させる際
00:53:52自動編集によってスキルの内容が
00:53:54本来の意図や品質基準から 逸脱してしまうのをどう防いでいますか？
00:53:56良い質問ですね
00:54:00そうですね 彼らは通常
00:54:04局所的な小さな変更を行うのは非常に得意です
00:54:06会話の流れの中で
00:54:09何がうまくいき 何がうまくいかなかったかを
00:54:11エージェントは把握しているからです
00:54:13ですから「この会話のこの部分はダメだった」と指摘すれば
00:54:20修正が必要な
00:54:25特定の箇所だけを見つけ出して 更新してくれます
00:54:26ゼロからすべてを
00:54:30書き換えてしまうようなことはありません
00:54:31なので それが大きな問題になったことは
00:54:34今のところありませんね
00:54:37全く問題ないとは言い切れませんが
00:54:40実用上の大きな問題としては 見ていません
00:54:43なるほど 分かりました
00:54:47さて こちらがワークショップのページです
00:54:49公開できそうですよね？
00:54:52美しく仕上がっています
00:54:55こちらがバリエーションです
00:54:58それぞれについて 開発サーバーを開いてみましょう
00:55:05タブをたくさん立ち上げます
00:55:09そろそろ終了の時間が近づいてきました
00:55:12最後に何か質問があれば
00:55:13締めくくる前にお受けします
00:55:17スキルの一覧から…あ スキルを見失ってしまいました
00:55:20ブラウザ 戻ってきて
00:55:24自分が行いたい作業に近い
00:55:26「スキルの作成」プロンプトを見つけて 読んでみることを強くお勧めします
00:55:30私は「公開スキル」というのも持っています
00:55:33これは私の名前で公開されています
00:55:35もしエージェントに GitHub CLIの実行を任せられるなら
00:55:37これもかなりの信頼レベルが必要ですが
00:55:42エージェントがコードをコミットし プルリクエストを送り
00:55:45変更を確認してマージするところまで自動化できます
00:55:47非常に強力なツールになりますよ
00:55:48本日はありがとうございました
00:55:54皆さんが AIエージェントを使いこなす助けになれば幸いです
00:55:56また次回お会いしましょう
00:55:57それでは失礼します
00:55:59（音楽が流れる）
00:56:03ジョン お疲れ様でした
00:56:11素晴らしいデモンストレーションをありがとう
00:56:16最後に何か質問があれば
00:56:17締めくくる前にお答えします。それと、
00:56:22「Skills」の画面を閉じてしまいましたね。
00:56:29ブラウザ、戻ってきて。
00:56:30「create skill」を探して、
00:56:36自分のやりたいことに近いものを読んでみるのがお勧めです。
00:56:40私のアカウントに「publish skill」というのもあります。
00:56:43これは私の名前で公開されています。
00:56:45エージェントに GitHub CLI を実行させるのは、
00:56:50かなりの信頼が必要な行為ですが、
00:56:54私は信頼して使っています。
00:56:57これを使えば、作成したスキルを読み取って、
00:57:00「create skill（スキル作成）」の後に「publish skill（スキル公開）」と言うだけで、
00:57:02自動的に処理してくれます。では、
00:57:04画面外で少し準備をしますね。
00:57:07私のリポジトリから、
00:57:16それ自体を公開したものを探します。
00:57:21これをお見せしましょう。
00:57:22プライベートな情報が映っていないか確認します。
00:57:24すみません。
00:57:27GitHub リポジトリを立ち上げて、
00:57:29スキルそのものを公開することができます。
00:57:32そうすれば、皆さんは手間をかけずに
00:57:35「スキル作成、次に公開」と言うだけで済みます。
00:57:38ご覧の通り、「リポジトリを作成してください、
00:57:43この組織（Organization）の下に作成してください」となります。私は複数の組織に所属しているので
00:57:45いつも組織を指定していますが、
00:57:47その後 Skills ツールで利用可能か確認します。
00:57:52これを使えば、
00:57:56繰り返しになりますが、指示を出すだけで、
00:57:58スキルの作成や公開を
00:58:00代行してくれるので、
00:58:01チームや友人と
00:58:02簡単に共有できるようになります。
00:58:03もう一つ、今日取り組んでいたのが、
00:58:08この「Skills Primer（スキル・プライマー）」です。
00:58:14あらかじめ読み込んでおきたいスキルが
00:58:19いくつか分かっている場合に使います。
00:58:20例えば agent-browser や Geist、
00:58:24それから Remotion のベストプラクティスや、
00:58:29Vercel React のベストプラクティスなどです。
00:58:33これは本質的に、
00:58:37事前にコンテキストを強制するためのツールです。
00:58:40今は Cloud Code 専用ですが、プロンプトを強制的に挿入します。
00:58:44現在は Cloud Code のみ対応しています。
00:58:45そこに強制的に流し込んで、
00:58:48「これらが必要になるスキルとその内容です」と伝えます。
00:58:50そうすることで、
00:58:51会話が始まったときに、
00:58:53「ポート3000のパフォーマンスを評価して」と言えば、
00:58:58たとえ agent-browser について言及していなくても、
00:59:06当然のように agent-browser を使いに行きます。
00:59:10以前からそうでしたが、より確実になります。
00:59:14agent-browser の説明文がどうなっているか、
00:59:18「評価（evaluate）」という言葉が含まれているか、
00:59:21あるいは「評価」と「ポート3000」から判断して読み込むかは分かりませんが、
00:59:24確実ではありません。
00:59:24しかし、この方法なら事前に強制的に読み込ませるので、
00:59:29そのようなフレーズを言ったときには準備ができています。
00:59:33そのパッケージはここにあります。
00:59:36skills-primer を探しますね。
00:59:41- これらのリンクは最後に共有しましょう。
00:59:45- いいですね。
00:59:45- 準備はできています。
00:59:46- 貼っておきますね。
00:59:50- いつも言っていることですが、
00:59:53今の時代のソフトウェアのあり方として、
00:59:55リポジトリをクローンして、自分のものにしてください。
00:59:59今は CLI やソフトウェアを
01:00:02自分好みにパーソナライズする時代です。
01:00:04名前を全く違うものに変えたいとか、
01:00:07機能や動作を全く変えたいと思ったら、
01:00:08Codeium や Cursor などに合わせて
01:00:11自由にカスタマイズしてください。
01:00:14「これを Cursor で動くようにして」と
01:00:18エージェントに頼んで構築させるだけです。
01:00:20最近は多くのことがワンショットで
01:00:23できてしまうので、本当に驚きです。
01:00:26- 素晴らしいですね。パーソナライズされたソフトウェアの勝利です。
01:00:29チャットにもう一つ質問が
01:00:31来ているので、これだけ聞かせてください。
01:00:32終了時間なのは分かっていますが、
01:00:35スキルは GitHub リポジトリであり、
01:00:37ローカルにもインストールされるようですが、
01:00:40どのようにアップデートを確認するのですか？
01:00:42CLI に「update skill」のようなコマンドはありますか？
01:00:48- 正確なコマンドが何だったか思い出せません。
01:00:52これらを閉じます。
01:00:53Skills、おっと、グローバルにインストールしていませんでした。
01:00:59- それはいいですね（笑）。
01:01:02- 最新版のコマンドリストを確認します。
01:01:05ええ、「skills update」がありました。
01:01:07- 関連して、
01:01:11スキルのアップデートは頻繁に行うべきでしょうか？
01:01:13- それは素晴らしい質問です。
01:01:18適切な答えを持っている人は
01:01:23まだいないかもしれません。
01:01:28というのも、スキルのフロントマターや
01:01:30バージョニングに関するルールは、
01:01:32まだ全員の合意が得られていないからです。
01:01:34ディレクトリ構造なども含めてですね。
01:01:37今はまだ、エコシステムが成長している真っ最中なんです。
01:01:41ですから、バージョニングについては、
01:01:47静観している状態です。
01:01:49今できる最善を尽くしながら、
01:01:51何がベストプラクティスとして定着するかを見極めています。
01:01:54現時点で提案できるのは、
01:01:57「毎回アップデートする」ことくらいです。
01:01:59それが一番良いと想定して動くしかありません。
01:02:03明確なアドバイスができず、すみません。
01:02:06- ええ、常に変化していますからね。
01:02:08数日後には誰かが最新のアドバイスを
01:02:12出しているでしょう。毎日変わっていますから。
01:02:18素晴らしいですね、ジョン。
01:02:18今日は他にコミュニティに
01:02:20見せたいものはありますか？
01:02:21- 本音を言えば、
01:02:25たくさんあります。
01:02:26- また何度か開催しましょう。
01:02:28他にもお見せしたいことが山ほどありますから。
01:02:30何時間でも話せてしまいますよ。
01:02:32- はい、最高です。
01:02:34ジョン、今日は私たちのコミュニティ・プラットフォームに
01:02:36来てくれて本当にありがとう。
01:02:38コミュニティのみんなに話してくれて、
01:02:39参加してくれた皆さんもありがとうございます。
01:02:42お話しした通り、
01:02:44ジョンは必ずまた戻ってきてくれます。
01:02:46楽しみにしていてください。
01:02:48- 皆さん、ありがとうございました。
01:02:49- ありがとうございました。
01:02:50さて、次回の
01:02:53コミュニティ・セッションですが、
01:02:55月曜日に「Open Source Stories」があります。
01:02:58それから来週には別の
01:03:00マーケットプレイス・パートナーのセッションも予定されています。
01:03:03詳細はすべて
01:03:04コミュニティ・イベント・カレンダーで確認できます。
01:03:08URL は [community.vercel.com/events](https://www.google.com/search?q=https://community.vercel.com/events) です。
01:03:12参加してくださった皆さん、本当にありがとうございました。
01:03:15とても楽しかったです。
01:03:17それでは、また来週お会いしましょう。