00:00:00皆さん、こんにちは。今週のVercelコミュニティ・ライブストリームへようこそ。私はエイミー、そしてこちらは
00:00:26ジェイコブです。私たちはVercelのコミュニティチームに所属しています。念のためのお知らせですが、
00:00:31XとYouTubeで配信中ですが、チャットでの質問やコメントを
00:00:36確実に拾えるように、[community.vercel.com/liveにアクセスしてサインインしてください](https://www.google.com/search?q=https://community.vercel.com/live%E3%81%AB%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%97%E3%81%A6%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%A4%E3%83%B3%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84)。
00:00:43最初のイベントとして表示されているはずです。
00:00:44ええ、セッションの最後に少し質問の時間を設ける予定です。もし
00:00:49セッションを見ながらチャットに参加される場合は、
00:00:55行動規範を守ることを忘れないでください。質問があればいつでも投稿してください、
00:00:59私たちが必ずお聞きします。それではゲストを紹介しましょう。ジョン・リンドクイストさんに
00:01:05Cloud Code用の新しいVercelプラグインを見せてもらいましょう。こんにちは、ジョン。
00:01:09やあ、ジェイコブ、エイミー。呼んでくれてありがとう。よし、早速画面を
00:01:16共有して、何が起きているかお見せしましょう。さて、しばらくの間、
00:01:23「スキル」が大きな話題になっていて、プロジェクトをレベルアップさせるためにどのスキルを使うべきか、
00:01:29またエージェントが通常できないことを可能にするにはどうすればいいか、誰もが話しています。
00:01:37現在、スキルから派生した次の進化形が、私たちが「プラグイン」と呼んでいるものです。
00:01:43これはまだ普及し始めたばかりの概念です。プラグインの数はまだ多くありませんし、
00:01:48正確な作り方もまだ模索段階です。私はVercelプラグインの最初のドラフトを作成しました。
00:01:56今日お話ししたいのは、なぜプラグインを作るのか、いつ作るべきか、
00:02:03なぜスキルの代わりにプラグインなのか、そしてそれらがどう補完し合うのか、といった疑問についてです。
00:02:09プラグインで何が可能になるのか、あるいは社内用や個人用に
00:02:16作るべきかどうかなどの質問があれば、ぜひ議論したいですし、
00:02:22今日のセッションの中でそれについて触れていきます。まず、プラグインは当初
00:02:32Cloud CodeやGeminiによって開始されましたが、アプローチは大きく異なっていました。
00:02:39プラグインの標準化は現在進行中の取り組みです。近いうちに詳細を話せればと思いますが、
00:02:44単一のプラグインがすべてのエディタで動作するようにしたいと考えています。
00:02:49現時点ではCloud CodeとCursorのサポートについて話しています。CodeXも今日、あるいは
00:02:54非常に近いうちに登場しますし、他にも多くが続きます。プラグインの標準化が進められており、
00:03:01プラグインをパッケージ化して、どんなツールを使っていようと
00:03:08共有できるようになることが期待されます。さて、「スキル」についてはご存知の方も多いでしょう。
00:03:15エージェントに読み込ませて追加の指示を与えるMarkdownファイルのことです。
00:03:23スラッシュコマンドなどで手動で呼び出すか、あるいは
00:03:29説明文に基づいてエージェントが読み込むべきだと判断します。つまり、ユーザーが起動するか、
00:03:36説明内の条件に基づいてエージェントが決定する仕組みです。一方、プラグインの進化点は、
00:03:44「フック」と呼ばれるものを持っていることです。プラグイン、あるいは
00:03:53Cloud Codeやエージェント・ハーネスとのセッションを考える際、それらにはライフサイクルがあります。
00:03:59今、Vercelプラグインのディレクトリにいます。ここでCloud Codeを立ち上げて、
00:04:07これが使っているフックは何ですか、と聞いてみます。するとフックが
00:04:18リストアップされます。これはライフサイクルを定義するようなものです。
00:04:27ライフサイクルとは、セッション開始時、ツールの呼び出し前後、
00:04:33ユーザーのテキスト入力時、セッション終了時などのことです。他にも多くのフックがありますが、
00:04:39今回のVercelプラグインでは、初期の目的に基づいてこれらを使用しています。
00:04:44明確にしておくと、Vercelプラグインの当初の目標は、Vercel上で
00:04:51エージェントをデプロイする手助けをすることでした。つまり、Vercelのエコシステムを
00:05:02エージェントにどう認識させるかということです。AI SDKやGatewayなど、プラットフォーム上のすべてです。
00:05:11私たちのワークフローについてもそうです。Vercel CLIも大幅にアップデートされました。
00:05:19エージェントSDKに関連するものや、Vercel上での
00:05:26エージェントのデプロイに関するこれらすべては、ここ数日、数週間、数ヶ月の間にリリースされたばかりです。
00:05:33Cloud Codeのようなエージェント・ハーネスは、
00:05:39おそらく半年から1年前の知識カットオフを持っています。モデルや
00:05:46様々な変数によりますが、これらのエージェントは私たちがリリースした
00:05:52最新の素晴らしい機能のすべてを知っているわけではありません。そこで、Vercelプラグインの
00:05:57目標は、エージェントが古いコードや古い手法を書くのを防ぎ、
00:06:06Vercelプラットフォームの絶対的な最新情報にまで引き上げることです。モデルは賢いですが、
00:06:11ただこれらの最新情報を知らないだけなので、これは大きな利点になります。
00:06:19毎回リサーチをさせたり、あらゆるものに対して
00:06:25膨大なスキルの束を用意したりする代わりに、Vercelプラットフォームに関する
00:06:32最高の情報をエージェントに強制的に読み込ませる方法を見つければ、それは私たちにとって大きな勝利です。
00:06:38エージェントのライフサイクルにおけるこれらのフックを見てみると、繰り返しになりますが
00:06:45将来的に、あるいは皆さんが活用できるフックはもっとたくさんあります。ただ、
00:06:49現時点で重要なのは、sessionStart、preToolUse、userPromptSubmit、
00:06:56postToolUse、そしてsessionEndです。sessionStartとsessionEndは、ご存知の通り
00:07:03エージェントとの会話の始まりと終わりです。通常、
00:07:12エージェントの.mdファイルやClaude.mdファイルで行うことがsessionStartに相当します。
00:07:19では、VercelプラットフォームのためにsessionStartで何ができるでしょうか。
00:07:27それはVercelプラットフォームのファイルを読み込むことです。具体的に見てみましょう、
00:07:40vercel.mdについて説明します。このファイルはClaude.mdと一緒に
00:07:48sessionStartに含めることができます。基本的には、Claude.mdファイルを
00:07:52共有し、誰でも簡単にインストールできるようにしたいだけなら、この「Vercelの知識グラフ」を
00:07:59注入するだけのプラグインを構築することも可能です。これは現在も継続的に調整しているもので、
00:08:04圧縮して可能な限り小さくしつつ、良好なパフォーマンスと
00:08:08含めるべき情報のバランスを探っています。あらゆるモデルやハーネスに対して
00:08:15評価（evals）を実行するのは非常に困難ですが、徐々に解明しつつあります。
00:08:21この中身は、基本的にはAI関連のVercelエコシステムにおける関係性、
00:08:28いつどの製品を使うべきか、いつ何を呼び出すべきかといった、
00:08:35Vercelエコシステム全体の構造化された理解です。この概念を
00:08:44私は「目次」と呼ぶのが好きです。会話を始める際の本の冒頭のようなものです。
00:08:50私たちがこれをどう構成し、考えたかというと、エージェントと何かについて
00:08:56話すとき、私には私の、エージェントにはエージェントの語彙があります。
00:09:02そこで用語集を与え、それらをドキュメントやスキル、
00:09:07読み込むべきものに関連付けることができれば、それらのポイントに到達したとき、
00:09:12自分が何を言うか、そしてエージェントが何を読み込んで
00:09:19呼び出すべきかのマインドマップを事前に展開しておくことができます。そうすれば、
00:09:24AI SDKに言及することすら気にせず、自然に会話できます。
00:09:30個別の機能について一々触れる必要もありません。「このアプリを作ってデプロイして」と
00:09:38言うだけで、あとはプラグイン内のすべてが
00:09:45処理してくれるようにできれば、素晴らしいアプリが
00:09:52Vercelにデプロイされ、そこから反復していけます。v0や
00:09:57他のいくつかのプロジェクトの仕組みと似ていますね。エコシステムを意識することなく
00:10:02素晴らしい体験ができれば、それは大きな勝利です。
00:10:09分かりますか？ジェイコブ、エイミー、何か最初の質問やチャットからの質問はありますか？
00:10:16ジェイコブ、会議があるから質問があるんじゃない？ ああ、ごめん。そうだった。
00:10:24ジョンに質問があります。ええ。このプラグインが目次として機能するなら、
00:10:30新しいドキュメントが出るたびにプラグインを常に更新しなくて済む、ということでしょうか？
00:10:38基本的にはエージェントが最新のドキュメントを見つけるために辿るべきURLのコレクションだからですか？
00:10:43それともプラグインに即時更新システムがあるのでしょうか？そのあたりはどうなっていますか？
00:10:49はい。基本的には、事前に知識グラフがあれば、
00:10:58最新のドキュメントを指し示すだけで多くのことができます。この
00:11:07「ライブラリごとのスキルをどう管理するか」という問題はよく議論になります。
00:11:14ある人はSDKのバージョン5を使い、別の人はバージョン6を使っていて、
00:11:18競合する異なるバージョンのスキルで影響を与えようとすると、どうなるでしょうか。
00:11:22多くの場合、その人が何をインストールしているかに基づきます。
00:11:31package.jsonやバージョンを確認できます。それに基づいて、
00:11:36どのドキュメントのURLを見るべきか、どのスキルを読み込むべきかを
00:11:44判断するスマートな方法を考え出せます。これもまた、
00:11:51sessionStartでのプリロード・フェーズの一部で、プロジェクトの構成を検査しています。
00:11:58繰り返しになりますが、これはすべてローカルで行われます。プロジェクトを見て、どのライブラリ、
00:12:02どのセットアップを使っているかを確認し、正しい方向を指し示せるようにします。
00:12:07よくあるエラーの一つに、最新バージョンのSDKでgenerateObjectを使おうとして、
00:12:12APIが変わっていることに気づかない、というものがあります。プラグインは
00:12:21それを処理します。つまり、レガシーなプロジェクトで使っているのか、
00:12:27完全に新規の最新プロジェクトで使っているのかを気にする必要はありません。プラグインが
00:12:32それを処理できるはずなので、バージョン番号やパッケージ名、
00:12:34その他一切を心配する必要はありません。すべてVercelに任せればいいのです。
00:12:41ええ。そして、これをより良くするためのアイデアは他にもたくさんあります。
00:12:49プラグインは今後もアップデートを続け、進化させていきます。他に質問は？
00:12:58ええ、プラグインの全体的なスコープはどの程度ですか？Vercelのサービスだけを
00:13:04扱うのでしょうか？ダッシュボードにあるようなものだけですか？それとも、私たちがサポートしている
00:13:11Next.js、AI SDK、Workflowsなどのオープンソース・ライブラリも含まれますか？
00:13:16はい、最初のスコープとしては、可能な限り広範囲をカバーすることに決めました。
00:13:25すべてのライブラリ、プラットフォーム上のすべてを盛り込んで、
00:13:32何が最も使われるかを確認します。内部的には全員テレメトリをオンにしてもらっていて、
00:13:36テレメトリ共有をオプトインできます。それによって、どのスキルが実際に使われ、
00:13:40どれが使われていないかが分かります。そうすれば、あまり情報が必要なさそうなものを
00:13:48削除したり、逆によく使われているものに情報を追加したりできます。当然、
00:13:53Next.jsやAI SDKなど、人気のあるダウンロード数が多いものに情報を集中させるべきです。
00:13:59初期リリースではあえてかなり大きく広げましたが、今後は
00:14:08よりスリムで「Svelte」な形に削ぎ落としていくつもりです。
00:14:15ええ。
00:14:16なるほど、よく分かりました。ありがとうございます。はい。さて、
00:14:24プラグインの構築について、私が抽象的で一般的な言葉で話している理由の一つは、
00:14:29私が「エージェント駆動開発」に非常に傾倒しているからです。すべてがどう動くかを
00:14:36細かく見せるよりも、それについてどう話し、用語をどう捉えるかを学ぶことの方が
00:14:40はるかに重要だと思うからです。そうすればAIアシスタントに同様のことを依頼できます。
00:14:45Cloud Codeに「Cloud Code用のプラグインを作って」と伝え、
00:14:52ドキュメントを渡せば、できてしまいます。ですから、コードを深掘りするよりも、
00:14:58概念やアイデアを議論することの方が大切なのです。というわけで、
00:15:05sessionStartは、プラットフォームの「目次」を注入するのに最適な場所です。
00:15:11モデルの知識カットオフによって古くなってしまっているけれど、
00:15:19自分にとって重要な情報をここで補います。これによって、
00:15:24現在のVercelがどのような状態であるかをエージェントに認識させることができます。
00:15:31プラグインがそれしか行わなかったとしても、エージェントは
00:15:37以降の作業で何を確認すべきかを知ることができます。また、
00:15:44補足ですが、Cloud Codeの各セッションには固有のIDがあり、これによって
00:15:52セッションが進行する間、「スキル・予算」を管理したり、
00:16:01すでに読み込まれたスキルを把握したりすることができます。セッションの
00:16:07環境変数やストレージに書き込むこともできるので、
00:16:15セッションの途中で、すでに読み込んだものを再度読み込んだり
00:16:20作業が重複したりしないように制御できます。何が起きたかを
00:16:26追跡できるのは素晴らしいことです。セッションIDを取得できるので、
00:16:30セッション中に行われる将来的なフックのいずれにおいても、
00:16:35そのIDに紐付けて、個別のプラグインに関する情報を保存できます。
00:16:47Cloud Codeも、プロジェクトの.clodディレクトリにあるセッション情報などで同じことをしています。
00:16:50独自のプラグインやツールを作る際にも、同じコンセプトを応用できます。さて、
00:16:56これらを踏まえた上で、preToolUseとpostToolUseについて
00:17:05同時に説明しましょう。これらによって、
00:17:11ファイルの変更を検知する機会が得られます。preToolUseでは、変更されようとしている
00:17:20ファイルの内容を取得できます。これはファイルの読み込み、
00:17:29書き込み、編集、作成などに関連します。また、preToolUseは
00:17:34Bashでの実行など、他のあらゆるツールの使用もカバーします。つまり、
00:17:40「何かが起きる前」に、何かしたいことはないか？と介入できるわけです。例えば、
00:17:47誰かが特定のVercel CLIコマンドを実行しようとしているのを見て、
00:17:55今ならもっと良い方法があることに気づいたとします。例えばVercel CLIにはAPIオプションがあり、
00:18:00より高度なクエリを実行できます。Vercel CLIは最近アップデートされ、
00:18:05多くの優れた新機能が追加されました。それをヒントとして提示したり、
00:18:11Vercel CLIが古い場合にアップデートを促したりすることができます。非常に多くの選択肢があります。
00:18:21CLIコールなどのツール呼び出しが行われるかどうかをチェックできるのは、
00:18:27Sandbox CLIやWorkflow CLIといった、全く新しい
00:18:34CLIにとって非常に重要です。モデルは知識カットオフ以降にリリースされたものを知りませんが、
00:18:39これによって正しく動作させることができます。Bashの呼び出しや
00:18:47ファイル編集において、これは非常に興味深いものになります。さらに模索しているのは
00:18:52ファイルの差分（diff）です。「このファイルはこうだったのに、エージェントは
00:18:59こう変えようとしている。ライブラリの仕様に照らして、それは正しい変更か？」
00:19:06あるいは「何か違和感はないか？」といったことです。ここでまた、
00:19:11SDK v6がインストールされているのにgenerateObjectをAPIとして使おうとする例を
00:19:18挙げてみます。これはよくあるミスです。その瞬間を見つけたなら、
00:19:25「generateObjectを使おうとしていますが、今のAI SDKの仕様はこうですよ」と
00:19:32警告できます。テストやデプロイに進む前に、エージェントが
00:19:36ファイルを変更しようとした正にその瞬間に食い止められるのです。
00:19:46スキルに頼ろうとすると、スキルはあくまでテキストによるヒントに過ぎません。
00:19:54Claude.mdやスキルに「特定のファイルを絶対にコミットするな」とか
00:20:03「ブランチにいない限り絶対にプッシュするな」と書いたことが
00:20:13あるかもしれませんが、それらが常に守られるとは限らないことを経験しているはずです。
00:20:21preToolUseなら、プログラム的かつエンジニアリング的な方法で、
00:20:28文字通りそれらを阻止することができます。そして、エージェントに
00:20:32異なる指示や別のやり方の例を与えることができます。これが、スキルや
00:20:41Claude.mdなどのエージェント用ファイルとの大きな違いです。何が変わろうとしているのか、
00:20:47何が起きようとしているのかを実際に制御できるのです。それが
00:20:51可能になるという点が、この機能の素晴らしいところです。そこから、
00:21:01postToolUseでも同様の機能が得られます。Bashコマンドが実行された後、
00:21:07具体的に何が変わったかを確認する機会です。ツールが呼び出された結果、
00:21:13何が以前と違っているのか。これは何かが起きるのを防ぐものではありませんが、
00:21:19起きたことの結果を確認できます。そして、もし
00:21:25予期しない変更が加えられていたなら、差分を取得して
00:21:31「これは少しおかしいようです」とエージェントに伝えるチャンスになります。
00:21:38これらは開発において非常に重要な2つのライフサイクル・フックです。私たちにとって、
00:21:43これは知識カットオフとの戦いでもあります。Vercelは
00:21:49開発スピードが速く、頻繁にリリースを行い、新しいテクノロジーを次々と提供しています。
00:21:55私たちはこの新しいテクノロジーのすべてを、素早く提供しており
00:22:00それらを人々に届けたいと考えています。そこでプラグインが非常に役に立つのです。
00:22:09これについて何か質問はありますか？
00:22:11ええ。もしファイルパスを使って注入するスキルを決定しているのであれば、
00:22:21プロジェクト内のファイルをより単一目的に絞り込むことで、大きなメリットが得られる
00:22:27ということでしょうか。そうすれば、どのスキルが必要かをより正確に
00:22:34判断できるようになりますよね。例えば、大きなファイルがあって、
00:22:395つか6つのライブラリを使っている場合、そこに追加できるスキルが3つまでに制限されたり、
00:22:47あるいはファイルパスに基づいた判断ができなくなったりするかもしれません。ですから、
00:22:51これからはそういったツールでソフトウェアを構築する際の考慮事項になるのでしょうか？
00:22:54私としては、エージェントが書くコードについて、あなたが気にする必要はないと言いたいです。
00:23:02それらをうまく機能させるのは、プラグインの作成者やハーネスの作成者の
00:23:12役割です。実際に評価（evals）を実行して、
00:23:17それが違いを生むかどうかを確認している人たちの仕事です。一方で、
00:23:27ついエンジニア・モードに戻って「人間ならこうするから解決しよう」と
00:23:33考えてしまいがちですが、エージェントもそれを望んでいるとは限りません。それは
00:23:39今の開発者にとって最大の誘惑の一つです。問題ではない問題を見つけて解決しようとすることです。
00:23:50もし何かを修正しようとして、そのテスト方法がわからない場合、
00:23:53エージェントに対してテストする方法を知っているなら、やってみてください。もし
00:24:00そのつもりがなければ、プラグインやハーネスを構築している人たちに
00:24:05任せておけばいいのです。なぜなら、テストや評価にはコストがかかるからです。
00:24:12それらの変更に対してモデルを動かすには多額の費用と時間がかかりますし、
00:24:17非常に大変な作業です。ですから、誰もそんなことを気にしなくて済むようになればいいと思っています。
00:24:23今は他のことに労力を使うべきだと思いますね。
00:24:33なるほど、わかりました。では、モデルの次期バージョンが、
00:24:40そういった修正を一切不要にするような形で構築されるのであれば、
00:24:47今の作り方を変える意味はないということですね。
00:24:48ええ。すべてのハーネスやVercelにとっての最終的な目標は、
00:24:56コードについてそれほど考えたり見たりしなくても済むようにすることです。今すぐ
00:25:01そうだと言っているわけではなく、それが最終的な目標であり、
00:25:07私たちが推進している方向だということです。美しいソフトウェアを出荷したい、
00:25:11アイデアを自由に流し込み、バリエーションを得て、どれが本当に心に響くかを確認し、
00:25:19自分自身や家族、顧客にとって美しいものへと削ぎ落としていきたいはずです。
00:25:25私たちはただ、ファイルの大きさなんて考えなくていいような、
00:25:33素晴らしい体験を提供したいのです。あるいは、適切なデザインパターンを書いているかとか、
00:25:39どのライブラリを選んでいるかといったこともです。全く同感です。
00:25:48「エージェントがうまく扱えるから、これらのパターンを使おう」といった
00:25:53誘惑があるのは確かですし、私たちも実際にプラグインで実験したり
00:25:58テストしたりしています。しかし、繰り返しになりますが、テストできないのであれば、
00:26:07「この変更を加えたから、明らかに良くなった」と言いたくなるのは非常に危険です。
00:26:18それは一種の「自爆（foot guns）」のようなもので、その変更を加えたことで、
00:26:23以前の動作や、それが他の場所に与える影響を見落としてしまうことになります。
00:26:28その1回限りのセッションではうまくいったかもしれませんが……。エンジニアリングは変わってしまいましたね。すみません、
00:26:35哲学的になってしまいました。でも、理解していただけたと思います。
00:26:44さて、もう一つのフックは「user prompt submit」です。これは非常に重要なもので、
00:26:50ユーザーが入力したテキストを取得できます。もし特定のライブラリや概念、
00:26:55あるいは「スケジュール」という言葉に言及した場合、
00:27:00cronスキルを読み込むといったことができます。これはスキルの仕組みと非常に似ていて、
00:27:07ユーザーの会話の中に説明と一致するものがあれば反応しますが、
00:27:12これは実際にユーザーのプロンプトに対して正規表現を実行するチャンスを与えてくれます。
00:27:20特定のキーワードやパターンを検出したら、それらのスキルをロードし、エージェントに
00:27:26「もっとフォローアップの質問をすべきだ」とヒントを与えることもできます。これはインタラクティブな部分で、
00:27:33「ユーザーがこう言ったから、もっと詳しく確認しよう」とか、
00:27:38「これらをすべてロードして進めよう」といった判断を下す機会になります。
00:27:44user prompt submitを使えば、本当に面白いことができます。例えば、
00:27:48自分専用のカスタム用語集やコマンド言語を持ちたい場合、
00:27:56頭に「$」を付けるといった具合です。「$」で始まる場合はこれを実行する、といったルールです。
00:28:00あるいは、user prompt submitの中に
00:28:07ちょっとしたbashスクリプトのようなものを書くこともできます。何かを検出したらすぐにツールを実行し、
00:28:13それはセッションのコンテキスト外で実行されるため、
00:28:20bashスクリプトでもNodeスクリプトでも、そのフック内で何でも実行可能です。
00:28:28ここではあらゆる素早い処理ができます。例えば「commit」という言葉を検出し、
00:28:37エージェントがコミットのためにいくつかのステップを踏むのを避けて、
00:28:47代わりにスクリプトで直接コミットさせることもできます。「commit」というプロンプトの直後に、
00:28:53エージェントに対して「コミットを実行したから心配しなくていいよ」と伝えることができ、
00:28:59エージェントの手間を数ターン分省くことができます。このように、
00:29:03繰り返し行う作業を加速させるための非常に興味深いトリックがいくつかあります。
00:29:09毎回エージェントに頼むよりも効率的です。
00:29:15自分用のuser prompt submitを作って、エージェントとの独自の対話言語を
00:29:19考案するのは楽しいプロジェクトになるでしょう。私たちの場合は、
00:29:25「ユーザーがこの概念について話したとき、Vercelの用語では何を意味するか」といった、
00:29:30特定の単語とのマッチングに使っています。例えば「scheduling」は
00:29:37cronsやworkflowsに該当します。また「parallel」や「performance」といった
00:29:45単語から、私たちが知っているVercelの特定の機能へとエージェントを誘導できます。
00:29:53週末にuser prompt submitをいじってみるのはとても楽しいですよ。
00:29:58繰り返しになりますが、「user prompt submitを使って、"$"記号を検出したら
00:30:03その中でcommitを実行するClaude codeプラグインを作るのを手伝って」と
00:30:09依頼することも可能です。そのプロンプトだけで
00:30:14構築できるので、コードのことはあまり気にせず、まずは遊び始めてみてください。
00:30:19さて、これらをすべてまとめた後、「session end」は
00:30:26セッション中に作成したファイルなどをクリーンアップするチャンスです。
00:30:32実行されたスキルのリストや、呼び出されたツールの結果に関する情報、
00:30:39あるいはセッションを通じて追跡していた予算などを収集していた場合、
00:30:48それらを整理する機会になります。session endでも非常に興味深いことが可能です。
00:30:51これは本質的に「Ctrl + C」などによるセッションの終了時に実行されるため、
00:30:57別のエージェントを立ち上げて、「セッションで変更されたすべてのファイルをチェックして、
00:31:05すべて一致しているか確認して」といった指示が出せます。私たちはそこまではしていませんが、
00:31:09「セッションが終わったけれど、このセッションはプロジェクトの進捗を表しているか、
00:31:13それともゴミを増やしただけか」を判断させるなど、面白い使い道があります。
00:31:20「変更されたすべてのファイルを確認し、プロジェクトに既にあるものの重複ではないか」
00:31:26といったことをチェックし、もしそうならクリーンアップして、
00:31:30システム通知などの手段でユーザーに警告することもできます。セッションは既に終了していますからね。
00:31:37本当に興味深い機能です。では、これらを踏まえて、
00:31:43簡単なデモをお見せしましょう。今から
00:31:50Vercelプラグインを実行しているClaude codeと、実行していないものを立ち上げてみます。
00:31:56「Claude dangerously skip permissions」を使い、デバッグはオンのままにします。これは後で見せますね。
00:32:04モデルは「Haiku」に設定します。これはClaude codeの中で
00:32:08最も速く、かつ最もシンプルなモデルです。「AI SDKについてのチュートリアルを書いて」と
00:32:13指示して、何が起こるか見てみましょう。そして両者を横並びで比較します。
00:32:26既に見えるように、スキルのロードが始まりました。こちらにはプラグインが読み込まれています。
00:32:30プラグインなしでセッションを開始したい場合は、「setting sources」フラグを使い、
00:32:37ユーザーレベルやプロジェクトレベルの設定を無効にする、つまり設定を無視することができます。
00:32:46これにより、プラグインなしでロードできます。「no flicker」オプションは、
00:32:53昨日追加されたばかりの新しい機能で、Claude code内でのスクロールをスムーズにします。
00:32:59これも有効にしておきましょう。そして、モデルを最強の「Opus」に設定します。
00:33:05同じ「AI SDKについてのチュートリアルを書いて」というプロンプトを入力します。
00:33:12こちらがバニラ（標準）バージョンです。結果を比較してみましょう。
00:33:20おっと、前のセッションを削除していませんでしたね。やり直しましょう。
00:33:28これを起動して実行します。今朝もこれを動かしていて、
00:33:36開始前にクリーンアップしたつもりだったのですが。もう一度立ち上げます。
00:33:50比較してみましょう。
00:33:56よし。ここで大きな違いは、片方がHaiku 4.5で、もう一方がOpus 4.6だということです。
00:34:01Haikuの方が圧倒的に安く、かつ遥かに高速です。そして、
00:34:04Vercelに関する情報がふんだんに盛り込まれています。HaikuとOpusを比較する際、
00:34:15追加で含めているトークンのコストを考慮したとしてもです。「markdownファイルを作って」と言うべきでしたが、
00:34:22実際にコードを書こうとしていますね。でも、それはそれで面白いでしょう。見てみましょう。
00:34:32多くのスキルで採用しているアプローチの一つとして、以前にも触れましたが、
00:34:38バージョン番号によってスキルが変わる可能性があるため、
00:34:45スキルのバージョンを固定（ピン留め）しています。言い換えれば、
00:34:59ライブラリのバージョンが異なれば、必要となるスキルも異なります。
00:35:05私たちのスキルの多くは「node modulesを確認してください」と指示し、
00:35:13そこにドキュメントを同梱することで、ドキュメントもバージョン固定されるようにしています。
00:35:21ここを見ると、実際にローカルのドキュメントを読み取っているのがわかります。
00:35:28それらを確認しながら、チュートリアルをまとめています。
00:35:34さて、こちらを見てください。こちらは全く調査を行っていないようですね。
00:35:40これは興味深いです。前回やった時はもっと調査してくれたのですが。
00:35:53既に見える通り、4.6ではなくSonnet 4といった古いモデルを使っていたり、
00:36:01「generate object」に言及していたりしますが、それは私たちが使いたいものではありません。
00:36:07現在はV6を使っていますし、既に古くなっているものがたくさんあります。
00:36:15間違いとまでは言いませんが、最新のSDKから最高のパフォーマンスとベストプラクティスを
00:36:23引き出したいのであれば、かなり時代遅れです。さて、
00:36:28こちらは何かを捉えたでしょうか？ええ、SDKスキルが反応したようです。
00:36:37最初は普通のチュートリアルを書いていたようですが、
00:36:51スキルがそれを検知して、私が何も言わなくてもV6に更新されるべきだと判断しました。
00:36:58現在、更新作業を行っています。「generate object」から「generate text」へと書き換え、
00:37:03すべてが最新バージョンであることを確認しています。では、
00:37:10これら2つを比較してみましょう。新しいセッションを開始します。
00:37:23プラグインなしのチュートリアルと、Vercelプラグインありのチュートリアルの正確さを比較します。
00:37:44以前実行した時はOpusがmarkdownファイルを書き出しましたが、
00:37:48今回はコードスニペットになっています。その違いを見るのも楽しみです。
00:37:54このように、特に他のスキルがこのプラグインと並行して動いている場合、
00:38:03それらが競合して、古い情報が優先されてしまうリスクはあるのでしょうか？
00:38:10それとも、プラグインの方が高い優先順位を持つのでしょうか？
00:38:16プラグインは、そのパターンに基づいてスキルを「強制的に注入」します。ですから、
00:38:27常にそのリスクはあります。結局のところ、すべては単なるコンテキストであり、
00:38:34セッションに詰め込まれるテキストファイルに過ぎないからです。ですから、常にアドバイスしているのは、
00:38:41取り組んでいるプロジェクトに必要なものだけを使うことです。ユーザーレベルでスキルをインストールするのは、
00:38:49すべてのプロジェクトで必ずそれを使いたいという確信がある場合だけにしてください。
00:38:58Vercelプラグインについても、現在取り組んでいるプロジェクトに
00:39:06必要なものだけをロードする最善の方法を模索しています。それについては多くのアイデアがあります。
00:39:11しかし、おそらく最も議論を呼ぶアイデアの一つは、
00:39:23「ユーザーがVercelプラグインをインストールした」という事実から、どのような推測ができるかという点です。
00:39:30もしユーザーが競合他社のプラットフォーム上でプロジェクトを開いているとき、
00:39:35私たちの製品について教えるべきでしょうか？それは非常に難しい問題ですよね。
00:39:42ある人はそれを望んでおらず、Vercelへの移行に全く興味がない場合、
00:39:47不快に思うでしょう。一方で、興味がある人なら喜んでくれるはずです。
00:39:53非常に興味深いテーマです。もし将来、誰もがエージェントを通じて対話するようになるとしたら、
00:39:59他のプラットフォームを邪魔することなく、自社のプラットフォームの新しい素晴らしい機能を
00:40:05エージェントに知らせるためのプラグインの「作法（エチケット）」とは何でしょうか。
00:40:15これは、今まさに私が行っていることにも非常に関連しています。
00:40:24まもなくWorkflowsを正式リリース（GA）する予定なので、移行ガイドを書いています。
00:40:31誰かが競合他社の製品から移行したい場合、スキルを使って「これから移行するなら
00:40:37このようにします」と直接案内できます。では、エージェントは
00:40:43どのタイミングでその情報を伝えるべきでしょうか？そういったことが、私にとって非常に興味深いのです。
00:40:49まさに今取り組んでいることなので、常に頭の片隅にあります。しかし、コンテキストの競合は
00:40:55今後間違いなく問題になるでしょう。ユーザーがプロジェクトのコンテキストや
00:41:00これまでの質問から何を求めているかを推測するのは、素晴らしいことですが難しい。技術的には、
00:41:07過去の会話を振り返ったり、コミット履歴を確認したりすることも可能です。
00:41:14GitHub CLIを使ってプロジェクト内のあらゆるものを調査させることもできます。
00:41:19コンテキストを集める方法はたくさんありますが、それは同時に、
00:41:27ユーザーが求めていないツールを呼び出すといった「境界線を越える」行為にもなり得ます。
00:41:35多くの興味深い課題がありますが、すべてをVercel内で行い、
00:41:40特定のルールセットを持つ単一のエージェントと、すべてを美しく出荷するプラグインを
00:41:46提供する方が、そういった競合を心配しなくて済むので遥かに簡単です。
00:41:53さておき。プラグインのコンテキストについてですが、
00:42:00スキルは通常、どのプロセスに位置づけられるのでしょうか？例えば、
00:42:05「Create React AppからNext.jsへ移行する」というスキルがスキルフォルダにある場合、
00:42:14Create React Appプロジェクトにいるときはいつでも自動的に呼び出されるのでしょうか？
00:42:19それとも、Vercelプラグインがあれば、いつそれを呼び出すかを制御でき、
00:42:26ユーザーが明示的にリクエストしたときだけ実行されるようにできるのでしょうか。
00:42:32その考え方で合っていますか？
00:42:39そうだと思います。私たちは「ワンショット・スキル」や
00:42:47「シングルユース・スキル」という概念について話し合ってきました。移行のように、
00:42:52特定のタスクに関連するスキルは、そのタスクを実行するとき以外は
00:42:59ロードしたくないはずです。つまり、プロジェクトやユーザーではなく、
00:43:06「タスク」にスコープ（範囲）を絞りたいのです。これについては現在議論の最中です。
00:43:12現状では、そのようなスキルがロードされていると、モデルや他のスキルの
00:43:17状況に応じてハーネスやモデルに影響を与えてしまうため、一概には言えません。
00:43:22プロジェクトの他の部分がどうなっているかにもよりますからね。しかし、
00:43:27「タスク・スコープのスキル」は間違いなく重要なトピックです。
00:43:33もう一つの質問ですが、このプラグイン・アーキテクチャのどの程度が
00:43:41Claude codeに特化したものなのでしょうか？例えばCursorやCodex、
00:43:47その他のツールで同様の動作をさせたい場合、それぞれ独自のプラグイン形式があるのでしょうか？
00:43:55ツールごとにプラグインを作る必要があるのですか？
00:44:04ええ、プラグインの仕様に関する発表が近々あるはずです。
00:44:12ようやく皆が仕様に合意し、普遍的に動作し、
00:44:18クロス互換性のあるプラグインが登場することになります。ほぼ全員がそれに賛同しています。
00:44:25現時点では、Claude code形式でプラグインを作っておけば、
00:44:33短期間のうちに他のツールでも動作することが期待できると言えるでしょう。
00:44:39素晴らしいですね。既にスキルフォルダが溢れかえっているので、標準化が進むのは嬉しいです。
00:44:45近い将来、他のツールでも動作するようになると期待していいでしょう。
00:44:54ええ、素晴らしいですね。すでにスキルフォルダーが多すぎますし、
00:45:00ようやく標準化が始まりつつあるのは本当に嬉しいことです。ええ、
00:45:07Anthropicとプラグインについて話した時、彼らが「エクステンション」ではなく
00:45:13「プラグイン」という言葉を選んだ理由は、それが「差し込んだり（プラグイン）」
00:45:18「抜いたり（プラグアウト）」できるものだからです。つまり、一連のスキルを持つ
00:45:24プラグインを作って、特定のタスクだけにそれを使いたいということが
00:45:33非常に簡単にできるはずです。例えばプロジェクト内で、私がデザイナーだとして、
00:45:40自分のデザインスキルが開発者のスキルなどを邪魔してほしくない場合、
00:45:46必要なピースだけを差し込みたいですよね。私はその考えに強く同意します。
00:45:52個々のユーザーには、それぞれのタスクや役割、プロジェクトがありますから。
00:45:59単なるスキルよりもプラグインを求めるでしょうし、おそらく自分専用の
00:46:05プラグインをキュレートしたくなるでしょう。自分たちの働き方に完全に
00:46:10カスタマイズされたスキルやフックのセットを構築するのです。
00:46:16ということは、Vercel関連ではないプロジェクトで作業している時は、
00:46:21Vercelプラグインを外しておくことを考えるべきでしょうか？
00:46:25現時点では「イエス」と言わざるを得ませんね。というのも、
00:46:34かなり積極的に自己主張するようになっているからです。怒られないといいのですが。
00:46:39Vercelプラグインの本来の意図は、エージェントを立ち上げて
00:46:46「これを作って」と言えば、それが魔法のようにVercel上に現れる、
00:46:53というものでした。それが当初の目標で、現在その仕組みを検証中です。
00:46:59寄せられているフィードバックに基づいて、少し抑制をかけているところです。
00:47:04プロジェクトの内容をより正確に検知して、無効化などを行う必要があります。
00:47:09その機能は間もなく提供される予定です。ですので、とりあえずは
00:47:15インストールして有効にしたままにしておいてください。今朝もまさに
00:47:18そのことについて話し合っていたところですから。
00:47:23なるほど。将来的には、いつ自分を呼び出すべきかをより賢く判断
00:47:29できるようになるというトレードオフですね。ただ現状では、ユーザーが
00:47:36セッションごとにプラグインを抜き差しすることで制御するわけですね。
00:47:42ええ。今は「/plugin」と入力すれば、インストール済みプラグインのタブに
00:47:48移動して、無効にしたいプラグインを選択できます。そこでアップデートや
00:47:54アンインストール、無効化などが可能です。また、他にも
00:48:03カスタムのZSH関数などを設定して、ユーザーごとに特定の
00:48:10設定セットをロードするような高度な技もあります。コンピュータの前に座る
00:48:17個人の「プロファイル」という概念はまだ少し奇妙なものですが、
00:48:23見ているものに基づいて、どのプラグインが必要か。まだ完璧な
00:48:29解決策はありませんが、見つけ出したいと思っています。
00:48:34Waymoが迎えに来て、乗り込んだ瞬間にシートが自分好みに
00:48:39調整されているような感じですね。
00:48:40ええ、まさに。ある時点からは、エージェントがユーザー自身について
00:48:49もっと詳しく尋ねてくるようになると思います。プロファイルやアイデンティティ、
00:48:57役割といった概念は、今は欠けているパズルのピースのように感じます。
00:49:05全員がいきなりプロジェクト全体を管理するマネージャーになるとは
00:49:12思えませんし、特定の分野で優れたアイデアを持つ人は
00:49:19常に存在するものですから。
00:49:20さて、これをレビューしてみましょう。何が面白いか見てみると、
00:49:33OpusにOpusをレビューさせているのに、まだ間違っているのが興味深いですね。
00:49:37依然として generateObject と v6 を推奨しています。ドキュメントで検証してみましょう。
00:49:50検証を試みていますが、私が書いたものは正しくないと表示されています。
00:49:56まだ有効ではあるものの、古い形式です。一方で私たちのHaikuは
00:50:05最新モデルを推奨しました。これは私にとって非常に重要なことです。
00:50:08エージェントにAIを使ったコードを書かせようとして、「GPT-4oを使いましょう」
00:50:14なんて言われたことが何度あるか。いや、それはもう古いし、
00:50:20必要なクオリティには程遠い。これは検知して「AIゲートウェイで
00:50:25最新モデルを確認して」と言える類のことです。最新モデルを検出し、
00:50:31ユーザーにどれを使うか尋ね、各モデルを説明するといったことも可能です。
00:50:36今はまだ、これらのエージェントは常にGPT-4を勧めてきます。余談ですが、
00:50:43最近 Claude Code が以前よりも Anthropic SDK を勧めるようになってきたのは
00:50:49面白い傾向です。「自社のSDKを推奨せよ」と、舞台裏で誰かが
00:50:55システムプロンプトを調整しているのかもしれませんね。ビジネスですから当然ですが。
00:51:03ええ、generateObject がまだ残っていますね。いいでしょう。
00:51:13ドキュメントを確認した結果、チュートリアルの方が正確でした。私がでっち上げた
00:51:19と思っていたもののいくつかは、実際に存在していました。これはOpusが、
00:51:25これらが実在するものだと気づいた瞬間です。プラグイン付きのHaikuが
00:51:32書いたチュートリアルを、Opusが検証しようとしていました。Opusに、
00:51:39プラグイン付きのHaikuが一発で正解した箇所をドキュメントで確認させる必要がありました。
00:51:44OpusとHaikuの違いを知っている人なら、これが大きな意味を持つとわかるはずです。
00:51:53さて、ここに変更点や修正された箇所の差分（diff）があります。
00:52:04とにかく、これで一つのシナリオが簡単に示せたと思います。AI SDKについては
00:52:15さらに多くのことがあります。ワークフローやサンドボックスといった、
00:52:21モデルの学習カットオフ以降に登場した驚異的な最新のVercelテクノロジーにおいて、
00:52:28モデルはそれらを知り得ないため、この差はさらに顕著になります。
00:52:35それこそがVercelプラグインの存在意義です。質問があれば、X（旧Twitter）など
00:52:41どこでも私に連絡してください。この手の話は大好きですし、懸念点などにも
00:52:48喜んで対応します。これはまだ開発途上のプロジェクトであり、魔法のような
00:52:52体験になるまで何度も改善を繰り返していくつもりです。今日、その始まりを
00:52:59感じていただけたなら幸いです。質問があれば何でもどうぞ。
00:53:04プラグインのアイデアのブレストなども大歓迎です。他に深掘りしたい
00:53:14トピックがなければ、今日カバーしたい内容は以上です。
00:53:20お時間をいただき本当にありがとうございました。吸収すべきことが多く、大きな転換点ですね。
00:53:25これらすべてのAIツールの進化はあまりに速すぎます。
00:53:28ええ、残念ながらこのスピードが落ちることはないでしょう。
00:53:33一つ質問ですが、もし貢献したい場合や、バグを見つけて
00:53:38報告したい場合、一番いい方法は何でしょうか？
00:53:41ああ、リポジトリですね。vercel/vercel-plugin だったかな、
00:53:49それとも vercel/plugin でしたっけ？
00:53:51ええ、vercel/vercel-plugin です。
00:53:58了解です。チャット欄にもリンクを貼っておきます。
00:54:03ありがとうございます。Issueを立てていただけると助かります。急速に変化していくので、
00:54:10実はこのコールの直前にも大きなプルリクエストを承認したばかりなんです。
00:54:14素晴らしい。さて Jacob、他に何か質問はありますか？
00:54:20いいえ、配信でカバーすべきことはすべて網羅できたと思います。詳細で
00:54:24素晴らしいデモをありがとうございました。これで自分でもClaudeプラグインを
00:54:30作れる気がしてきました。エージェントが勝手にメインブランチへ
00:54:37フォースプッシュした時に叫ぶ代わりに、どのフックを使えば
00:54:42それを防げるのかが分かったのは、本当に大きな収穫でした。
00:54:45「pre-tool」は、起きてほしくない事象を防ぐための最強の味方です。
00:54:51いいですね。John、本当にありがとうございました。こちらこそ。皆さんありがとう。
00:54:56ご参加いただいた皆様もありがとうございました。今後のセッションについては
00:55:01[community.vercel.com/events](https://community.vercel.com/events) でご確認いただけます。ではまた次回。
00:55:05ええ、またコミュニティでお会いしましょう。皆さん、良い一日を。