エージェントで拡張しながらコミュニティの人間らしさを保つ

Vercelにおいて、開発者コミュニティは私たちのあらゆる活動の中心です。私たちが構築するものを利用する人々に最も近くあり続ける方法であり、その源泉です。 コミュニティの成長に伴い、自動化は規模拡大を支えてくれました。しかし、質問が見落とされることは依然としてあり、ルーティングには時間がかかり、コンテキストスイッチングによって、実際に専門知識を必要とする本質的な作業から私たちの注意力がそがれてしまいました。そして自動化は、最も重要な瞬間――誰かと真につながり、その人を助けるような瞬間――には決して役立つことができません。心から気にかけてくれる人と話す感覚を、AIで再現することはできないのです。 そこで私たちは、人間を必要としないルーティング、トリアージ、フォローアップを担当するエージェントを構築しました。これを「Community Guardian」と呼びます。その機能、構築方法、そして非エンジニアを含む誰もが同様にエージェントを開発（ship）できる方法について説明しましょう。 **Community Guardian オペレーション層** 新しい投稿が入ると、Guardianはそれを分析し、重複をチェックし、適切な専門性とキャパシティ（bandwidth）を持つチームメンバーに割り当てます。各メンバーは最大10件の質問を処理し、その後は新しい質問が別のメンバーに回されるため、タイムゾーンを跨いでワークロードのバランスが保たれます。 見落としは一切ありません。質問が48時間回答されない場合、Guardianはそれを再割り当てします。さらに情報待ちの状態ではリマインダーを送信し、会話が解決された時点を検知します。 内部では、GuardianはAI Gatewayを介してClaudeを利用し、Vercel Workflows上で動作しています。これにより、10分ごとにチェックインし、サイクル間はリソースを消費せずにスリープすることが可能です。 これでオペレーション面は処理されましたが、私たちのチームが適切に対応するためには、より優れたコンテキストが必要でした。 **インテリジェンス層: リサーチアシスタント c0** Guardianが物流（ロジスティクス）を管理する一方で、c0は深く調査を行うエージェントです。私たちのチームが普段から作業しているSlack内に存在します。 チームメンバーがスレッドの背景情報（コンテキスト）を必要とする時、c0はナレッジベース、ドキュメント、GitHub issues、過去の議論を検索し、コンテキストパッケージをまとめます。このパッケージにより、チームは個人の記憶に頼る代わりに、より速く、より正確に対応できるようになります。 個々のスレッドを超えて、c0は製品チームとのフィードバックループを完結させるのにも役立ちます。コミュニティの感情や繰り返し発生する技術的課題を追跡するため、誰かが一週間分の投稿を監査するのに何時間も費やす代わりに、c0に「主要な製品フィードバック」を尋ね、製品に関する会議に実際のデータを持ち込むことができるのです。 **人間の集中力を取り戻す** 導入初めの23日間で、このシステムは281人のユニークユーザーを支援しました: | メトリック | 成果 | | :--- | :--- | | **初期コンテキスト収集** | チームメンバーが到着する前に、4,716件の初回応答で問題をトリアージしログを収集 | | **スレッド復活** | 8件に1件の「放置（ghosted）」されたスレッドが復活し、23件の解決が確認された | | **オペレーション規模** | 最近の2週間で、古くなったチェックから自動解決まで、1,400回以上のエージェント実行 | | **重複検出** | ベクトル類似性により4つの重複スレッドを検出、うち3つは95%以上の信頼度で自動クローズ | すべての本質的な回答は、今も私たちのチームから発信されています。エージェントは、それらの回答を取り巻く他のすべての作業を処理します。トリアージや追跡といった反復作業から解放された私たちのチームは、複雑なペアデバッグや関係構築、広範なコミュニティ向けのコンテンツ作成、あるいは大切にしている開発者たちとただ楽しむことに、時間を費やすことができるようになりました。 **自分自身で構築する** このようなものを構築するために、開発者である必要はありません。必要なのはアイデアだけです。私はエンジニアではありません。コミュニティを管理し、開発者と対話するのが仕事です。確かに、私たちが解決しようとしている問題は理解していますが、毎日プロダクションコードを書いているわけではありません。 私のアイデアは、チューリッヒでの講演で私たちのコミュニティワークフロー自動化について話した時に生まれました。しかし当時は従来型の自動化、つまりスクリプトとルール、「if-this-then-that」のロジックに頼っていました。機能はしましたが、脆い（brittle）ものでした。あらゆるエッジケースに対して新しいルールが必要だったのです。 もっと賢いものが欲しかったので、私はコーディングエージェントを使い、「新しい投稿が到着する」と「アクションを取る」の間のステップである「思考層」を追加する実験を始めました。「投稿に『billing』が含まれていたら課金チームにルーティングする」のではなく、「この投稿を読み、その人が実際に必要としていることを理解し、それから判断する」ようにしたのです。 この思考層は、各投稿を見るもう一人のDXエンジニアのようなものです。ユーザーが「動かない」と言った時の行間を読み、3ヶ月前のGitHub issueと点と点を結びつけ、誰かが苛立っているのか単に混乱しているのかを理解し、エスカレートすべき時と、より多くのコンテキストを収集すべき時を見極めることができます。この方法で構築することで、私は平易な英語で欲しいものを説明し、動作するコードを受け取り、実際のコミュニティスレッドでテストし、反復改善することができました。 私は、異なるタスクに異なるモデルを使い分け、エージェントに私たちのドキュメントやコミュニティを読むアクセス権を与え、何か失敗した時に中断、再開、回復できるようにしたかったのです。すべてをゼロから構築する代わりに、必要なものをコーディングエージェントに説明し、既にそうした複雑さを扱えるAI Gateway、AI SDK、Vercel Workflowsにたどり着きました。 **それを構築したプロンプトたち** 最初のプロンプトは核心となるアイデアでした：「投稿の割り当てやフォーマットなど、コミュニティの日常業務を助けるエージェントを構築してください。現時点でどのモデルが最適かはわかりませんが、新しいAPIキーなしで簡単に切り替えられるようにしてください。エージェントにはAI SDKを使用してください。」 そこから、構築するものについて理解が深まるにつれ、プロンプトはより具体的になっていきました。「そして10分ごとにトリガーし、最新のスレッドをチェックしたい」。最初はcronジョブを使っていましたが、この目的ではVercel Workflowsに切り替えました。耐久性のある実行（durable execution）により、エージェントはチェック間で中断し、中断した場所から正確に再開できるようになったのです。 「4時間ごとに担当をローテーションするようにしてください」。それぞれのプロンプトが次の疑問を解き放ちました。私はチュートリアルやドキュメントに従っていたのではありません。会話をしていたのです。そしてシステムはその会話から成長していきました。 適切な専門用語やコーディング方法を知っている必要はありません。自分の問題を十分に理解して説明でき、何かが期待通りに動かない時に反復改善する意思があればいいのです。思考層は、自動化を「これらの厳密なルールに従う」ことから、「状況を理解し、判断を下す」ことに変えるのです。 **心を込めて構築する** コミュニティとは、結局のところ人に関するものです。私たちは、チームメンバーが完全に参加する時間とエネルギーを持ち、コミュニティ内の開発者と共に、開発者のために構築し続けることを望んでいます。 もし同様のものを構築したいのであれば、私たちはc0をChat SDKで、またSlack、Teams、Discordなどでエージェントを構築するための統一されたTypeScript SDKを使用して構築しました。Guardianは耐久性のある実行のためにVercel Workflowsを利用しています。コミュニティで何か構築したら、ぜひ共有しに来てください。私たちが学んだことを通じて話す機会は、いつでも歓迎です。

エージェントで拡張しながらコミュニティの人間らしさを保つ

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト