Transcript
00:00:00皆さん、こんにちは。
00:00:19Vercelコミュニティセッションへようこそ。
00:00:22今週はMaltaとMattが参加してくれています。皆さんにお願いですが、
00:00:27チャットに参加される際は行動規範に従ってください。ですが、
00:00:31Chat SDKに関する質問はいつでも歓迎します。
00:00:34ようこそ。
00:00:35最高ですね。
00:00:36呼んでくれてありがとうございます。
00:00:37皆さん、こんにちは。
00:00:38Mattです。
00:00:39今日はMaltaと一緒にChat SDKのすべてについてお話しします。
00:00:45まだ詳しくない方のために説明すると、これは私たちが開発したオープンなTypeScriptライブラリで、
00:00:50どんなプラットフォームでもユーザーにエージェントを届けることができます。
00:00:55まずは、その誕生秘話を聞かせてください。
00:00:58一体どこから始まったのでしょうか？
00:01:00そうですね。
00:01:01改めて、Maltaです。
00:01:03私はVercelのCTOであると同時に、Chat SDKの作者でもあります。
00:01:07今日はその役割でここにいます。
00:01:11戦略に関する質問はしないでくださいね。
00:01:14Chat SDKの誕生は、本質的には2025年を通して形作られました。
00:01:23私たちはSlackボットへの投資をますます強めていました。
00:01:26そこで常に「Slack以外のプラットフォームにも展開できるか？」という疑問がありました。
00:01:32しかし、結論としては常に「ノー」でした。かなりの手間がかかる割に、
00:01:39得られる価値が少ないからです。
00:01:40それに、自分たちで管理するとなると、さらに難しくなってしまいます。
00:01:44だから、結局やらなかったんです。
00:01:46私がそれらのアプリを見ていたとき、「一度でこれらを構築する良い方法はないか？」といつも考えていました。
00:01:53でも、すべてのアピを見てみると、
00:01:57構築するのはとても恐ろしいことのように思えて、本当に怖かったんです。
00:02:04それらは非常に難しく、多面的に見えたからです。
00:02:10昨年末に話を戻すと、Opus 4.5がリリースされて、「今だ！」と思いました。
00:02:16自分のタイミングだと。
00:02:17ホリデー期間中でしたね。
00:02:18そう、ホリデー期間中。
00:02:19ええ。
00:02:20私が「Malte、これはどうなるの？」と聞いて、
00:02:23どうやってやるんだい？
00:02:25あなたが回答の代わりに、実際にライブラリを作ってきて答えてくれたんです。
00:02:31そうですね。
00:02:32そうでした。
00:02:33あれこれとハックしていたんです。
00:02:37この手の開発は、やはり作るのが非常に苦痛です。
00:02:43なぜなら実際のAPIが存在し、学習データにはあまり含まれていないからです。
00:02:46だからこそ、自分で多くのことを理解しなければならない。
00:02:50少なくとも作業の大半はカバーされました。
00:02:55それで、よし、やってみようと決めて、ホリデー期間中にChat SDKの最初のバージョンを作りました。
00:03:01それがChat SDKです。
00:03:02公開できる準備をするまでには、その後1ヶ月ほどかかりました。
00:03:07それが誕生秘話です。
00:03:08必要であることは明白でしたが、作るにはあまりに難しかったということですね。
00:03:12そしてAIが私たちを後押ししてくれました。
00:03:15その通り。
00:03:16Vercelの誰もがビルダーですから。
00:03:17さてAmy、最初の質問から始めてくれますか？
00:03:20ええ。
00:03:21新しいオープンソースプロジェクトが出るたびに、よくある質問があるのですが、
00:03:26どれくらいオープンなのか？という点です。
00:03:29Vercel専用にロックされているのでしょうか？
00:03:32VercelのAIインフラを使わなければならないのか、それともどこでも使えるのか？
00:03:37間違いなくどこでも使えます。
00:03:38特にChat SDKに関しては、単なるTypeScriptライブラリであり、
00:03:44特定のフロントエンドやバックエンドのフレームワークにも縛られません。
00:03:48どんなJavaScriptアプリケーションでも使用できます。
00:03:53JavaScriptがホストできる場所ならどこでもホスト可能です。
00:03:55Chat SDKは、Webhookイベントを処理するためのサーバーレス関数さえあれば、
00:04:03クラウドの他のプリミティブに縛られることはありません。
00:04:07Maltaはどう思いますか？
00:04:08そうですね。
00:04:09サーバーレス関数でさえも必須ではないんです。
00:04:10文字通り、ただのライブラリですから。
00:04:13Reactのようなもので、どこでも使えますし、
00:04:19特定の構造に縛られることは一切ありません。
00:04:23Chat SDKはエージェントそのものではないと考えてください。
00:04:27Webhookイベントを受け取り、あなたが選択したフレームワークで作ったエージェントに
00:04:33コンテキストを渡すためのレイヤーに過ぎません。
00:04:38良い例として、最近Microsoft Teamsチームが、私たちが作ったアダプターの最初のバージョンを
00:04:42引き継いでくれました。
00:04:52そう、その通りです。
00:04:53これには本当に感謝しています。私はTeamsを動かすのに苦労していましたから。
00:05:00彼らはメンテナンスを引き継いでくれただけでなく、アダプターを書き直してくれました。
00:05:05彼らは新しいAPIを出荷したばかりで、既存の実装をその新しいAPIに移植してくれたのです。
00:05:13これは彼らにとっても利点があると思います。
00:05:15新しいAPIで展開でき、旧来のものよりユーザーも少なくなるはずですから。
00:05:20サポートするすべてのプラットフォームで最高のものにするには多大な努力が必要なので、本当に感謝しています。
00:05:25開発者にとっても大きな勝利です。
00:05:27新しいMicrosoft Teams APIを学ぶ必要はなく、自分たちのエージェントが
00:05:32新しいアダプターの恩恵を受けられるのですから。
00:05:37コードの変更は一切不要です。
00:05:38ええ。
00:05:39これは完全に後方互換性があるものです。
00:05:41Chat SDKをアップグレードするだけで、何もしなくても新しいAPIの利点を活用できます。
00:05:47そうですね。
00:05:48彼らには多少のユースケースがあったかもしれませんが、彼らは実際のTeamsチームですから、
00:05:51自分たちのAPIをどう使うのがベストかを知っています。
00:05:56Chat SDKのユーザーとしては、それを知る必要は必ずしもありません。
00:06:00ところで、Chat SDKの価値の一つは、マルチプラットフォームで使えることですが、
00:06:05おそらくほとんどのユーザーは実際にはそう使っていないと思います。
00:06:08ただ、一度に一つのプラットフォームで使っているだけでしょう。
00:06:11しかし、APIというのは、
00:06:16ドキュメントが不十分だったり、TypeScriptエコシステムで自然に使えるように
00:06:23設計されていなかったりすることが多いんです。
00:06:28ですから、
00:06:29たとえアダプターの一つだけでも、Chat SDKを使うほうが簡単だと感じる人が多いんです。
00:06:35ええ。
00:06:36そうですね。
00:06:37v0で私たちがしたことがそれです。
00:06:38v0はChat SDKを使ってSlack用に作りました。
00:06:41最高なのは、別のプラットフォームに移行しようとした場合、
00:06:47非常に簡単なエンジニアリングで移行できるということです。
00:06:51さて、よく聞かれる次の質問はJSXについてです。
00:06:56Chat SDK以前にSlackエージェントをたくさん作りましたが、BlockKitを使わなければならず、
00:07:04私はReactに慣れていたのでJSXが好きでした。
00:07:06それがChat SDKで最大の利点の一つであり、ワクワクした点でした。
00:07:11一体どんな感じだったのですか？
00:07:13そうですね。
00:07:15Chat SDKの進化がそれでした。
00:07:22インタラクティブな要素をサポートしたかったので、まず最初に考えたのは、
00:07:28Chat SDK内でどのように適切に抽象化するかということでした。
00:07:36私の頭の中にあったのは二つのことでした。
00:07:42一つは、素晴らしいMarkdownサポートが必要だということ。なぜならChat SDKは非AIアプリケーションでも使えるからです。
00:07:48しかし、本質的にはエージェントに接続して使われることを想定しています。
00:07:53そのためにMarkdownは非常に重要でした。
00:07:55もう一つは、TypeScriptのエンジニアにとって素晴らしい体験を提供したいということ。
00:08:01そこで、さまざまなチャットボットにレンダリング可能な、
00:08:08UIの内部表現を持たせることにしました。
00:08:16そして、その中間表現をBlockKitのような基盤となるAPIにマッピングする。
00:08:22もう一方では、エンジニアが使うフロントエンド表現を持たせる。
00:08:30それが再利用可能であること。
00:08:32Markdownなどがそれにあたります。
00:08:33MarkdownをAST（抽象構文木）に解析して、
00:08:35BlockKitにレンダリングする、あるいはJSXを使う。
00:08:42それは中間表現に直接マッピングされるようなものです。
00:08:47JSXをよく知らない方のために説明すると、JSXは本質的に
00:08:55関数呼び出しの構文糖衣（シンタックスシュガー）です。
00:08:58この関数呼び出しは、要素の名前を最初の引数に取り、
00:09:03次にpropsを取るcreateElement関数です。
00:09:07これはH1、H2、パラグラフタグのようなものです。
00:09:10その通り。
00:09:11これはH4ですね。
00:09:12しかし実際には、やりたいことは何でもできる。
00:09:17単なる関数呼び出しですから。
00:09:18だから、そのcreateElement関数を上書きして、Chat SDKの中間表現から
00:09:28要素を作成するように変えることもできます。
00:09:33これを構築する上で少し複雑なのは、
00:09:37既存のReactアプリケーション内で動くようにする必要がある点です。
00:09:41JSXは名前空間がないため、何らかの方法でインポートするわけではありません。
00:09:47Next.jsやRemixなどを壊さないようにする必要があります。
00:09:55同時に、ReactやJSXが何なのか全く知らないアプリケーションでも
00:09:59使えるようにする必要があります。
00:10:00これら両方のケースをサポートしています。
00:10:02既存のJSXアプリケーションと調和し、そうでない環境でもJSX構文を導入できるのです。
00:10:08サポートされていない場所でも。
00:10:11コミュニティへの挑戦として、JSXを使ったチャットプラットフォーム向けの「ShadCN」を見てみたいですね。
00:10:18それができたら最高です。
00:10:20誰かがすでに構築中だと思いますが、見るのが待ちきれません。
00:10:24そうですね。
00:10:27最初のコミュニティからの質問ですが、SDKを実装する際、開発者が意識すべきプラットフォーム固有のケースはありますか？
00:10:34JSXに関する質問としても素晴らしいですね。
00:10:37SlackのBlockKitにはリッチでインタラクティブなUIがたくさんありますが、
00:10:44他のプラットフォームでは同じようにレンダリングされるわけではありません。
00:10:52私たちがこれを構築したとき、非常に優れたフォールバックをサポートしました。
00:10:57他のプラットフォームが対応していない方法でChat SDKを使っても、
00:11:04素晴らしいデフォルトとフォールバックを用意しています。
00:11:08その通りです。
00:11:10複数の要素があります。
00:11:13レンダリングレイヤーもその一つです。
00:11:16しかし、もともとChat SDKが「スレッド」のあるプラットフォーム向けに設計されていたことは、最も大きな違いです。
00:11:23そうですね。
00:11:28もちろん、それを使っていても全員がスレッドを使っているわけではありませんが。
00:11:33考慮すべき点ではありますが、そのように設計されていました。
00:11:37それから人々はWhatsAppやTelegramを強く求めました。
00:11:39将来にはiMessageなども追加されるでしょう。
00:11:43すべてを含めていくことになります。
00:11:46そのような世界では、チャットアプリを使う異なるパラダイムがあることを理解する必要があります。
00:11:55これはChat SDKレイヤーで完全に抽象化することはできません。両方をサポートする必要があるからです。
00:12:01両方を、ですね。
00:12:05WhatsAppに取り組むなら、こうしたメッセージはコンテキストフリーであることを理解する必要があります。
00:12:11それが一つの点です。
00:12:14そうですね。
00:12:15Chat SDK全体として、大きな差異をfavor（推奨）するようなものではありません。
00:12:21UIに関しても、同じコードを書いてどこでも動くようにしようと試みています。
00:12:26それがすべての環境でうまくいくように。
00:12:31実際には、とてもうまく機能していると思います。
00:12:37サポートしたい要素は実際、非常によくサポートされています。
00:12:43多少の手動テストは必要でしょうし、すべてが期待通りに動くか確認する必要はありますが、
00:12:50クロスプラットフォームの面で皆が本当に困っているというケースはあまり見ていません。
00:12:57これこそオープンソースの良いところです。
00:12:59実際どういう意味を持つのか、コミュニティが助けて示してくれるはずですから。
00:13:04その通り。
00:13:06間違いありません。
00:13:07あちこちに問題が見つかることもあるでしょうから、ぜひ報告してください。修正します。
00:13:15ええ。
00:13:16次の質問です。
00:13:18Chat SDKは、軽量でスタックに依存しないパラダイムによって、
00:13:24チャットをエージェントのハーネスの残り部分から分離しているようです。
00:13:28他のモダリティの進歩により、ビデオチャットSDKのようなものが可能になる未来は見えますか？
00:13:34興味深い質問ですね。
00:13:36まず、指摘は正しいと言わせてください。
00:13:38Chat SDKはAI SDKではなく、AI SDKはChat SDKではないと、何度か繰り返してきました。
00:13:45Chat SDKはAI SDKではなく、AI SDKもChat SDKではありません。
00:13:51AI SDKはエージェントの構築を支援するものです。
00:13:55Chat SDKはそのエージェントを複数のプラットフォームに展開するためのものです。
00:13:59つまり、軽量でスタックに依存しないパラダイムなのです。
00:14:05ビデオチャットSDKについてはどう思いますか？
00:14:09非常に興味深いと思います。
00:14:13ビデオチャットSDKの前に、まずはオーディオチャットSDKが登場するでしょう。
00:14:19私の考えでは、Chat SDKのような抽象化は、似たような実装を何度か繰り返した後に初めて
00:14:31素晴らしい価値を生み出すものだと考えています。
00:14:36私たちはビデオチャットを構築したことがありません。
00:14:38振り返ってみる必要がありますね。
00:14:44まだその時ではないようです。
00:14:45特に、よりハードウェアに近いレベルで制御する必要がありますから。
00:14:50このような課題のほとんどは、AIモデルとの通信部分にあると考えています。
00:14:55フロントエンドや、リアルタイムでやり取りするユーザーとの通信部分の課題はそれほど大きくありません。
00:15:02なるほど。
00:15:03素晴らしい。
00:15:04わかりました。
00:15:05次の質問です。Opus 4.6で固定回答を学習させて、コストをかけずに無料で回答させることはできますか？
00:15:11無料で回答させることは可能ですか？
00:15:13この質問は、Chat SDKとは何か、何ではないのかという点を浮き彫りにしていますね。
00:15:20Chat SDKをトレーニングすることはありません。
00:15:24Chat SDKに回答を作成させるためにプロンプトを書く必要もないのです。
00:15:30それはAI SDKや他のエージェントフレームワークの役割です。
00:15:36エージェントフレームワークでツールやプロンプトを作成し、ワークフローを設計します。
00:15:44Chat SDKは、プラットフォームとエージェントをつなぐレイヤーに過ぎません。
00:15:51これで疑問が解消されると良いのですが。
00:15:54YouTubeからの次の質問です。Chat SDKを使ってSlackとJIRA間の機能を追跡・管理できますか？
00:16:00SlackとJIRAですね。
00:16:02いい質問ですね。
00:16:04JIRAの話が出ましたが、現時点ではLinearアダプターはあります。
00:16:09JIRAアダプターはまだありません。
00:16:11追加することにやぶさかではありません。
00:16:13コミュニティの皆さん、どうでしょうか。
00:16:14LinearやGitHubについてもいくつか質問がありましたが、
00:16:20Chat SDKの本来の目的は「チャット」です。
00:16:28LinearやJIRAというのも、よく考えてみればチャットアプリケーションのようなもので、
00:16:33それを異なる形式でレンダリングしているに過ぎません。
00:16:37それこそが目的です。
00:16:40Chat SDKを使ってSlack上の会話を読み取り、それをJIRA APIの呼び出しにマッピングして、
00:16:49JIRA上で好きな操作を実行することは間違いなく可能です。
00:16:58しかし、Chat SDK自体はJIRAの操作までは管理していません。
00:17:04もちろんメッセージを投稿することもありますが、
00:17:07ラベルを追加したり、タスクのステータスを変更したりすることもあるでしょう。
00:17:11担当者を割り当てるとか。
00:17:12その通りです。
00:17:13これらすべてはChat SDKの機能ではありません。
00:17:16Chat SDKはあくまでチャット通信のためのもので、複雑な操作を行いたい場合は
00:17:20そのプラットフォームのネイティブAPIを直接利用すべきです。
00:17:23はい。
00:17:24素晴らしい。
00:17:25さて。
00:17:26次の質問です。Facebook Messengerはサポートしていますか？
00:17:32どうでしょうか。
00:17:33プルリクエストがあるかもしれませんね。リリース以来、多くの関心と
00:17:39素晴らしいプルリクエストをたくさん頂いています。ここで「コミュニティアダプター」と
00:17:46私たちが公式にビルド・サポートしているアダプターの違いについて話すと良いかもしれません。
00:17:53そうですね。
00:17:54良い質問です。
00:17:56第3のカテゴリーとして「ベンダー公式」というものがあります。
00:17:59はい。
00:18:00一般的にChat SDKに同梱されるものは、SlackやDiscordのような、
00:18:07ユーザー数が10億人規模のプロダクトであるべきだと考えています。
00:18:151億人くらいでも良いかもしれませんが、非常に広く利用されている
00:18:20プラットフォームであることが基準です。
00:18:23Facebook Messengerはまさにそのカテゴリーに入ります。
00:18:26彼らが自らベンダー公式アダプターを提供してくれるとは期待していませんが、
00:18:31もしFacebookがそうしてくれたら嬉しいですね。
00:18:32歓迎しますよ。
00:18:36なので、Facebookはその対象になります。
00:18:39また、メッセージングサービスやコンテキスト管理を
00:18:45提供している企業もたくさん見受けられます。
00:18:49いくつか見かけましたね。
00:18:50それも一つのカテゴリーです。
00:18:51ええ。
00:18:52詳細は別途お話しできますが、例えば独自のiMessageサービスを持っている場合などですね。
00:18:56そうですね。
00:18:57Sendblueのような。
00:18:58Sendblueですね。
00:18:59彼らならベンダー公式を作るでしょう。
00:19:01「これはSendblueによる、Sendblueのためのもの」というように、
00:19:07責任を持って継続的にメンテナンスするというコミットメントがあります。
00:19:10その通りです。
00:19:11そして第3のカテゴリーは、ここに参加している皆さんが作るアダプターです。
00:19:15少しコストをかけて作ればいいのです。
00:19:19難しいことではありませんし、好きなものに接続できます。
00:19:23メインのChat SDKに含めるほどのユーザー規模ではない、
00:19:29小さなアプリケーションの場合などが当てはまるでしょう。
00:19:35あるいは、私たちがメインのChat SDKに加えない特定の機能が必要な場合などですね。
00:19:41誰もそれを止めることはできません。
00:19:44フォークして自分で作ればいいのです。
00:19:48アダプターは完全に疎結合なので、独自のバージョンを作ることができます。
00:19:52そろそろ、始め方についてお話ししましょう。
00:19:56オープンソース初心者の方もいるかもしれません。
00:19:58プルリクエストを投げたことがなくてもアダプターをビルドしたい場合、どう始めれば良いか。
00:20:04どうすれば良いですか？
00:20:06そうですね。
00:20:07アダプターを作る際は、カテゴリーを意識することが重要です。
00:20:111億人規模のプロダクトなら、Chat SDKに対してプルリクエストを送るのが正解です。
00:20:16そうであれば、Chat SDKにプルリクエストを送ってください。
00:20:20もっとニッチなものの場合は、GitHubのリポジトリを確認してください。
00:20:27Chat SDKのリポジトリを見て、私たちがどのようにアダプターを構築したかをエージェントに調べさせ、
00:20:33実際に作ってみてください。
00:20:37すべてのアダプターは基本クラスを継承しており、
00:20:43最終的には「post message」のような関数を実装します。
00:20:49これは、ネイティブSDKを使うか、あるいはAPIへの単純なfetch呼び出しで
00:20:55サポートしたいプラットフォームに通信する形になります。
00:20:58なるほど。
00:20:59素晴らしい。
00:21:00残り数分ですね。
00:21:04次は複雑なプロジェクトにおける複数のプロバイダーやアプリの使用についてです。
00:21:09意思決定に人間が関与する必要がある場合などです。
00:21:11Human in the loop（人間が介入する仕組み）はChat SDKでどう見えますか？
00:21:15Chat SDKでの人間介入の仕組みはどうなっていますか？
00:21:19RedditのAMAで回答しましたが、AI SDKには「needs approval（承認が必要）」というパラメータがあります。
00:21:25AI SDKで構築しているとしましょう。
00:21:28「needs approval」というパラメータがあります。
00:21:32人間の承認が必要なツールを作成する場合、そのストリームをリッスンします。
00:21:38承認が必要な場合はその旨が型として返ってきます。
00:21:42そこでChat SDKの出番です。JSXを使って必要な承認UIを書くことができます。
00:21:49JSXコンポーネントはどのプラットフォームでもレンダリングされます。
00:21:57一度承認用UIを作れば、どのプラットフォームでも使い回せます。
00:22:04よくある質問ですが、エージェントに権限を与えつつ、人間が介入するタイミングを制御するにはどうすれば良いかという問題ですね。
00:22:11権限を与えつつ、最終判断を人間が行う仕組みです。
00:22:17そうです。
00:22:18そうですね。
00:22:19実用的な回答と、少し理想的な回答ができるのですが、まずは実用的な方からお話しします。
00:22:27Chat SDKでHuman in the loopを実装する一般的な方法は、
00:22:32エージェントにツールを使わせたいと委譲することです。
00:22:43そしてツールが実行される際に、回答を求めます。
00:22:50質問に答えるツールですね。
00:22:51その通りです。
00:22:52ある段階でエージェントが「承認が必要です」という状態になります。
00:22:55そうです。
00:22:56エージェントはSlackなどの使用中のプラットフォームにメッセージを投稿します。
00:23:02作業中の場所ですね。
00:23:03「ユーザーさん、エージェントがこのアクションを実行しようとしています。」
00:23:08「承認しますか？」
00:23:09ここでJSXのボタンを2つ、「はい」と「いいえ」で使うことができます。
00:23:14コールバックURLのプルリクエストも来ています。
00:23:17ええ。
00:23:18マージされたかは分かりませんが。
00:23:19まだマージされていませんが、より理想的なアプローチです。
00:23:22はい。
00:23:23今はコールバックを受け取って、
00:23:27サーバー側で「承認済み」と判断すれば、
00:23:31その時点でエージェントの操作を再開する形になります。
00:23:34これが一般的なパターンです。
00:23:38チャット画面にUIを表示してユーザーがインタラクションを行い、承認を得て処理を進めるのです。
00:23:45作業を継続するという流れですね。
00:23:48現在開発中なのは、ボタンがクリックされるたびにWebフックを呼び出す仕組みです。
00:23:54より汎用的に使えるようになります。
00:23:58なるほど。
00:23:59もちろん、あらゆるWebフックシステムで使用可能ですが、
00:24:03ぜひ皆さんに注目してほしいのは「workflow-deficit」におけるWebフックの考え方です。
00:24:08ワークフローの定義ですね。
00:24:14はい。
00:24:15workflow-deficitについて詳しく説明する時間は取れませんが、これは
00:24:20長時間実行可能なエージェントを書くための耐久性のあるコンピューティングシステムです。
00:24:27何時間も続くような作業です。
00:24:30Workflow Deficitにおいて非常に洗練されている点の一つは、
00:24:35文字通りコードを書き、Webhookを作成して別の場所に送信し、
00:24:39そのフックを「await（待機）」させることができます。
00:24:44ユーザーがクリックするまで5週間かかるかもしれませんが、
00:24:47ワークフローなら本当にそれが可能なのです。
00:24:51そのWebフックをChat SDKのJSXに渡すことができます。
00:24:57ユーザーがクリックすると魔法のようにawaitが解消され、
00:25:03エージェントが次に進みます。
00:25:05最初にこれを見たときは感動しましたね。
00:25:10エージェントとの最初の対話で「サインインしてください」と言われるのが一般的です。
00:25:13以前はサインインが完了したかどうかをポーリングで監視し続けなければなりませんでした。
00:25:18大変でしたね。
00:25:19バグも多くてひどいものでしたが、Webフックを使えば成功するまで待つだけです。
00:25:2530秒後でも、数日後でも、数週間後でも。
00:25:28魔法のようでした。
00:25:29うまく動作しました。
00:25:30Webフックとコールバックの活用事例として最高のものの一つです。
00:25:34ええ。
00:25:36わかりました。
00:25:37そろそろ時間ですね。
00:25:38締めくくる前に何か言っておきたいことはありますか？
00:25:44特にありませんが、これはあくまでオープンソースライブラリです。
00:25:49私たち自身が必要で作ったものです。
00:25:51反応を見る限り、多くの需要があることが分かりました。
00:25:55皆さんの貢献に感謝します。
00:25:58特に大規模アダプターのラインナップを充実させるためにも。
00:26:05まだまだこれからですね。
00:26:11iMessageは難しいかもしれませんが、RCSメッセージング、WeChatなど、
00:26:21その国で好まれているものなど。
00:26:25どこにでもスレッドはありますから。
00:26:26いいえ、もうスレッドである必要はありません。
00:26:29会話が成立する場所ならどこでも。
00:26:30会話ができるあらゆる場所ですね。
00:26:32皆さん、ありがとうございました。
00:26:34皆さんの時間をいただき感謝します。Chat SDKで何が作られるのか楽しみです。
00:26:39ありがとうございました。
00:26:41参加してくれた皆さん、ありがとう。
00:26:44チャット欄も非常に盛り上がっていますね。
00:26:46ぜひ使ってみて、フィードバックをください。
00:26:50何が必要か、どんなアダプターが欲しいか教えてください。
00:26:57プルリクエストを待ちしています。
00:26:58ぜひ見せてください。
00:26:59ありがとうございました。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video