先日、あるLinkly AIユーザーが、とても興味深い活用方法を教えてくれました。
WorkBuddyとLinkly AIを接続し、30分もかからずにWeComのグループチャットへ「AI同僚」を追加したというのです。
このAI同僚が担当するのは、具体的な仕事です。製品について質問されると、関連資料を探して回答します。
マーケティング原稿が完成したら、公開前に製品説明が正しいかをチェックしてもらうこともできます。
一つひとつは大げさな仕事ではありません。しかし、あまりにもスムーズだったため、このユーザーは初めて「チームのAgentが同じコンテキストを共有する」と何が変わるのかを実感したそうです。
ここからは、その構築手順と実際に使ってみた感想を紹介します。
Part 1：Agent時代なのに、なぜ私たちはまだ「人間API」なのか
チームのグループチャットでは、同じ質問が何度も繰り返されます。
- 「この機能はもう対応していますか？」
- 「この原稿の製品説明を確認してもらえますか？」
答えの多くは、すでに公式ドキュメントやチームのナレッジベースにあります。それでも問題が起きると、結局みんなプロダクト担当者を@メンションします。
いつの間にか、プロダクト担当者は社内の「人間API」になってしまいます。情報はとっくにデジタル化されているのに、実際に呼び出される知識インターフェースは、まだ人なのです。
Part 2：ナレッジベースを作り直さずにBotを持てるか
そこで考えたのが、「答えがすでに資料にあるなら、ナレッジBotへ直接聞けばよいのではないか」ということでした。
発想自体は新しくありません。製品資料を何件かBotへ渡し、「あなたは社内の製品アシスタントです。資料にもとづいて回答してください」と指示すれば終わりに見えます。
しかし実際に作ろうとすると、何かが足りませんでした。
プロダクトマネージャーが質問に答えられるのは、FAQを暗記しているからではありません。その背後にある仕事全体のコンテキストを持っているからです。
実務のコンテキストは、一つの社内ナレッジベースだけには収まりません。製品ドキュメント、リリースノート、会議記録、開発中の技術資料、さらには別のAgentが作った分析結果まで、回答に必要になることがあります。
こうした資料は、正式なナレッジベースへ整理される前から、すでに日々の判断に影響しています。
ちょうどその頃、WorkBuddyのCLIが利用できるようになりました。そこで、「製品チームがすでに持っているコンテキストを、Agentが直接読み、Botの回答に使えないか」と考えました。
試した構成は、Linkly AI + WorkBuddy + WeComです。
結果、30分もかからず「WeComのAI同僚」が動き始めました。
この構成では、Linkly AIがプロダクト担当者のPCに散在する資料を接続し、WorkBuddyのコンテキスト層になります。WorkBuddyはBotの実行を担当します。
新しいBotのために資料を複製する必要はなく、ナレッジベースが特定のAgentへ固定されることもありません。モデルや作業環境を変えても、同じ資料をそのまま使い続けられます。
Part 3：3ステップでWeComのAI同僚を作る
接続手順は3つです。
ステップ1：Linkly AIへローカル文書を接続する
共有可能なナレッジベースを作成し、ヘルプドキュメント、リリースノート、製品ブログなど、実際に使っているローカル資料を追加します。選択したナレッジベースをクラウドへプッシュすれば、ほかのAgentからも利用できます。
ステップ2：Linkly AIをWorkBuddyへ接続する
WorkBuddyへ、次の指示を渡します。
https://linkly.ai/docs/ja/agent-setup.mdを読み、Linkly AIのインストールと連携を案内したうえで、WorkBuddyが指定したクラウドナレッジベースを読めるかテストしてください。
ステップ3：WorkBuddyをWeComへ接続する
手順はシンプルです。WorkBuddy → アシスタントモード → アシスタント設定 → WeCom連携 → QRコードでログイン → 設定完了の順に進みます。
Botを設定してグループへ追加すれば、開始から30分以内に新しい「製品担当のAI同僚」が加わります。
Part 4：なぜLinkly AIを加えるのか
ナレッジベースBotは、昨年の時点ですでに数え切れないほどありました。
もし「製品について一つ聞けば、一つ答える」だけなら、この仕組みが何かを変えたとは感じなかったでしょう。便利さを実感したのは、マーケティング原稿のレビューでした。
公開予定の原稿について、機能の説明が正しいかをプロダクトチームへ確認する必要がありました。
通常の流れは、マーケティングが原稿を完成 → プロダクト担当者を@メンション → 一文ずつ確認 → 修正案を返す、となります。
今回は、マーケティング担当者が先に原稿全体をBotへ渡しました。Botは製品に関する記述を資料と照合し、一つずつ確認しました。その後、プロダクト担当者がBotのレビュー結果を再確認しましたが、問題は見つかりませんでした。
この瞬間、ナレッジベースが実際のワークフローに入ると、これほど役に立つのだとわかりました。
ここで、「WeComはもともとさまざまなナレッジソースを接続できるのに、なぜLinkly AIをもう一層加えるのか」と疑問に思うかもしれません。
チームの資料がすべてWeCom DocsとWeCom Driveに整理され、WeCom内で一つか二つのBotだけを使うのであれば、標準のナレッジセットで十分な可能性があります。Linkly AIを使うためだけに、システムを一層増やす必要はありません。
私たちの状況は違いました。
製品資料の一部はGitHubやローカルのプロジェクトフォルダーにあり、ほかはPDF、スライド、会議録音、過去バージョンでした。マーケティングチームには独自の企画、記事、ユーザーフィードバック、素材ライブラリがあります。実際の仕事に関わるファイルは、WeComへ整理済みのコンテンツよりはるかに多かったのです。
そこで問題は、「WeComのBotへ知識を与えるために、実務の資料をもう一度移すべきか」に変わりました。
このワークフローで、Linkly AIは主に二つの問題を解決します。
1. Agentのために資料のコピーをもう一つ維持しない
WeComのナレッジセットは、すでにWeCom Docsで管理されているコンテンツに適しています。文書が更新されれば、ナレッジセットも同期できます。
しかし、元の資料がローカルフォルダー、GitHubリポジトリ、Obsidian、PDF、画像、音声、動画にある場合は、アップロード、移行、再整理が必要になりがちです。その結果、チームは二つの資料を維持することになります。
- 実際の仕事で使う元ファイル
- Botに読ませるためだけに作ったナレッジベースのコピー
問題を減らすはずのAgentが、新しいメンテナンス作業を増やしてしまいます。
Linkly AIは、この重複を減らします。ファイルを元の場所に置いたまま、ローカルフォルダーにAgentが読めるインデックスマップを構築します。ファイルが変われば、Linkly AIがインデックスを更新し続けます。Agentは必要なときに、そのマップを使って最新情報を見つけられます。
どのファイルを接続するかは、引き続き人が判断します。Linkly AIが減らすのは、繰り返し発生するアップロード、移行、同期の作業です。
2. WeCom Botだけでなく、すべてのAgentへ同じコンテキスト層を提供する
WeComのナレッジセットは、WeCom内のBotへコンテキストを提供できます。しかし現在、チームが使うAgentは一つではありません。開発者はCodexやClaude Codeを使い、マーケティング担当者はWorkBuddyを使うかもしれません。
各自が自分のAgentへファイルをアップロードし、背景を説明します。別のAgentへ乗り換えると、同じ作業をまた最初から行います。
チームのコンテキストが同期されていなければ、Agentごとに異なる話をし始めます。開発Agentは最新版を読んでいるのに、マーケティングAgentは古い資料で原稿を書いている。結局、全員がグループチャットへ戻り、製品を最もよく知る人へ何度も質問することになります。
Linkly AIを接続すれば、チーム内のすべてのAgentが、継続的に更新される同じクラウドナレッジベースを利用できます。
直接得られるメリットは二つです。
- Agentごとに同じコンテキストを何度も与える時間を減らせる
- 情報の不一致によるAgentの誤判断を減らせる
Part 5：次からは、まずBotに聞く
この試みで最も直接的に変わったのは、次の二点です。
- マーケティング担当者は、原稿完成後に最初のチェックを自分で進められ、返信を待ち続ける必要がない。
- プロダクト担当者は、同じ説明を繰り返す代わりに、本当に判断が必要な仕事へ時間を使える。
次に同じような質問が出たら、まずBotへ聞きます。答えを見つけられなかったときに、初めて人へ聞きます。
AIネイティブなチームは、最初から数十のAgentが自分たちで会議し、意思決定する必要はありません。
もっと小さなところから始められます。以前なら必ず誰かを@メンションしていた場面で、初めてその人を呼ばずに済む。それが最初の一歩かもしれません。