チームのナレッジベースをSlack、Feishu、DingTalkに接続する方法 (2026年)

質問と回答が異なるアプリケーションに存在する

これがすべてであり、ありふれた事実です。質問とはチャットクライアント上で行われる社会的な行為です。ドキュメントを参照することは、ブラウザのタブ内で行われる孤独な行為です。同僚に聞くコストはメッセージ1通ですが、Wikiを確認するコストはコンテキストスイッチ、検索、そして何も見つからないリスクを伴います。

チームは、ピン留めされたメッセージ、チャンネルのブックマーク、毎週ハンドブックのURLを投稿するボットなどの「リンク」でそのギャップを埋めようとします。しかし、それらはどれも最終的に「さあ、これを読んでください」で終わります。切り替え（スイッチ）は依然として存在したままです。

ドキュメントはページを返し、質問には答えない

よくメンテナンスされたナレッジベースであっても、返されるのはドキュメントです。読み手はそこから情報を抽出する必要があります。ページをざっと読み、該当する段落を特定し、それが今でも有効かどうかを判断し、目の前のケースに対する回答へと翻訳するのです。

このステップは計画段階では見えませんが、実際には非常に大きな負担となります。だからこそ、「それはドキュメント化されています」という言葉と、毎月同じ質問が届くという状況が、これほどまでに平然と共存してしまうのです。情報は存在していますが、回答として組み立てられていません。検索（Retrieval）とメモリ（Memory）は同じ操作ではありません。その違いについては、why RAG isn't memoryで詳しく説明しています。

チャットプラットフォームの検索範囲は、そのチャットプラットフォーム内に限定されている

Slackはこの分野に投資しており、ドキュメント化された境界内では機能しています。Slackの言葉を借りれば、そのAI機能は「ワークスペース内のナレッジに裏打ちされて」います。回答は「検索結果を精査するのではなく、Slack内の関連情報に基づいて」行われ、「情報を得たソースメッセージやファイルを参照する引用が含まれ」ます。

ナレッジが他の場所にある場合、ドキュメント化された2つの制約が重要になります。1つはプランによる利用制限です。自動検索フィルターはProプラン以上、検索回答はBusiness+およびEnterprise+プランで提供されます。もう1つは、コーパスが自身がアクセス可能なコンテンツに限定されることです。「AIが生成する回答には、あなたがアクセスできる情報（パブリックチャンネルのメッセージやその他のコンテンツ、およびあなたが所属するプライベートチャンネルやダイレクトメッセージなど）のみが含まれます。」

外部へのアクセスは別の機能となります。「Enterprise+プランをご利用の場合、組織のオーナーまたは管理者は、エンタープライズ検索を有効にして、Google DriveやGitHubなどの他のソースからのコンテンツや情報を検索結果に含めることができます。」これは合理的な設計ですが、同時に、チャットアプリのアシスタントがドキュメントシステム内にあるランブックを引用できない理由でもあります。

チャットで共有される資料は、最もコンテキストが豊富で、最も耐久性が低い

多くのワークスペースで最も有用な成果物は、チャットに貼り付けられます。エラーのスクリーンショット、署名済みのPDF、誰かが深夜に再構築したスプレッドシートなどです。Slackはこれらを同じ履歴ウィンドウ内でカウントします。「ファイルには、クリップ、PDF、ドキュメント、画像、スクリーンショット、音声・動画ファイルなどが含まれます。」そして無料版では、「過去90日間のメッセージとファイルを閲覧・検索」でき、「1年以上経過した」データは削除されます。

つまり、チームのナレッジの最も豊かなレイヤーは、所有している中で最も永続性の低い場所に置かれており、Wikiの更新でそれがキャプチャされることはありません。貼り付けられたスクリーンショットをドキュメントだと考える人は誰もいないからです。

全員のプライベートアシスタントは、プライベートなコンテキストを持っている

人々が頼る回避策は、自分自身のAIサブスクリプションです。背景情報を貼り付けて、回答を得ます。これは1人のために1回だけ機能します。コンテキストは個人のアカウントに留まるため、共有の場所には何も蓄積されません。この分断については、cross-tool memory for knowledge workers（ナレッジワーカーのためのツール間メモリ）で説明されており、組織規模ではenterprise AI forgetting（エンタープライズAIの忘却）で説明されています。

すべてのチャンネルにハンドブックのリンクをピン留めする。 コストはかかりませんが、結局はコンテキストスイッチで終わります。また、ピン留めは誰も整理しない「整理されたはずのリスト」になってしまいます。

#handbook やお知らせチャンネルを作る。 ナレッジベースをフィードに変えてしまいます。フィードは、投稿されたその日にオンラインだった人によって一度だけ読まれるに過ぎません。

チャット履歴を対象とした検索ボット。 有用ですが、チャット内に限定されます。一度も投稿されたことのないドキュメントから回答することはできません。

全員に個人のAIサブスクリプションを購入する。 個人の処理能力は解決しますが、チームのナレッジは元の場所に取り残されます。サポートチームはこれを痛感しています。このパターンについては、when an assistant forgets your support tickets（アシスタントがサポートチケットを忘れるとき）で説明されています。

ナレッジオーナーを任命する。 正しい場合もありますが、失敗を排除するのではなく、1人のカレンダーに失敗を集中させることになります。

発想の転換：人々をナレッジベースに移動させようとするのをやめ、ナレッジベースをグループチャットに移動させます。具体的には、チャンネル内のボットが、汎用モデルの一般的な知識からではなく、指定されたメモリの本体から回答し、各やり取りを同じ場所に書き戻すことを意味します。

この後半部分こそが、チャットインターフェース付きの検索ボックスと本作を分けるものです。MemoryLakeのIM接続では、やり取りがメモリになるため、誰かがスケジュールを組まなければならないドキュメント作成スプリントからではなく、チームが実際に尋ねる質問からコーパスが成長します。セットアップは3つのステップで、プラットフォームの違いはすべてステップ2にあります。

ステップ 1: IM接続を追加する

コンソールで、MemoryLake → Workspaces を開き、メモリを公開したいワークスペースを開き、IM タブに切り替えて、プラットフォームを選択します。開始する前の2つの前提条件：メンバーは「連携を表示することも変更することもできない」ため、チームのオーナーまたは管理者ロールが必要です。また、ワークスペースには少なくとも1つのプロジェクトと、それにリンクされたエージェントが必要です。

ステップ 2: アプリの資格情報を入力する

各プラットフォームは異なるペアを発行し、それぞれ承認に関する現実が異なります。ここは計画を立てる価値がある部分です。

時間を大幅に節約できる2つの注意点。Slackでは、マニフェストからアプリを作成することで、スコープ、イベントサブスクリプション、DMの入り口、Socket Modeを1回の貼り付けで設定できます。その後、スコープやイベントを変更した場合は、効果を反映させるために Reinstall to Workspace（ワークスペースへの再インストール）が必要です。DingTalkには、オプションの3番目のフィールドである AI card template ID があります。これを空のままにすると回答ごとに1つのメッセージが送信され、設定すると文字ごとのストリーミングが行われます。

リクエストする前に注意すべき名前の罠が1つあります。「FeishuとLarkは2つの異なるプラットフォームです。」Feishuは中国版、Larkは国際版です。アカウントやアプリは相互に移行できず、特定のデプロイがどちらと通信するかは、連携ごとの選択ではなくデプロイレベルの設定になります。間違ったコンソールでアプリが作成される前に、管理者と確認してください。

ステップ 3: 作成して接続する

チャット側からのメッセージに回答するエージェントを選択し、メモリのスコープを設定します。ボットが取得および書き込みを行う1つの必須の読み書き（read-write）プロジェクトと、検索はできるが書き込みは行わない任意の数の読み取り専用（read-only）プロジェクトを設定します。

これを、セキュリティ上の決定として扱ってください。ドキュメントには「読み書きプロジェクトは認可の決定である」と明記されています。なぜなら、ボットにアクセスできる全員がそのプロジェクトに書き込み、すでにそこにある内容を読み取ることができるからです。機密情報が含まれるプロジェクトではなく、チームと共有することを意図したプロジェクトを指定してください。その後、連携を作成し、カードに Connected（接続済み）と表示されていることを確認します。

3つの率直な制限事項。ボットはチャット履歴を読み取りません。どのプラットフォームでも、自身に言及（メンション）されたメッセージのみを受信するため、チャンネルやグループ内の他の会話を見ることはできません。接続したプロジェクトから回答するため、最初の1週間の品質は、ロードした内容の品質に依存します。また、これは強制力ではなくコンテキストです。必ず真でなければならないことについては、メモリレイヤーではなく、ポリシーやチェックが保証となります。

その仕組みは、導入初日にチームが驚くような方法で分岐します。

ボットの注意を引く。 グループチャットでは、3つすべてで@-メンションが必要です。メンションのないメッセージは配信されません。DMは異なります。Slackでは、メンバーはサイドバーの Apps（アプリ）の下でアプリを見つけ、@なしで質問できます。FeishuのDMはアプリの利用可能範囲によって制御されます。DingTalkの連携はグループ利用を中心にドキュメント化されています。

回答が表示される場所。 Slackは質問の下のスレッドで返信するため、混雑したチャンネルの読みやすさが保たれます。Feishuはメッセージを引用し、あなたに@-メンションを返します。これにより、流れの速いグループでも回答が見失われるのを防ぎます。

回答のストリーミング方法。 Feishuは一文字ずつストリーミングします。Slackは同じメッセージをセグメントごとに編集することでストリーミングします。そのため (edited)（編集済み）マークが表示されるのは仕様であり、最初の約12秒を過ぎると更新頻度が低下します。DingTalkは、AI card template IDを提供していない限り、回答ごとに1つのメッセージを送信します。

ファイルやスクリーンショットの送信。 Slackでは、ファイルとメンションを1つのメッセージに含める必要があります。「チャンネルに単独で投稿されたファイル（メンションなし）は、ボットに届くことはありません。Slackがそれを配信しないためです。」Feishuのグループドキュメントに関するドキュメント化された手順は、ファイルを投稿し、そのメッセージに返信してボットを@-メンションすることです。DingTalkは、@ボット＋テキスト＋画像を1つのリッチテキストメッセージとして受け取ります。

コンテキストの保持期間。 Slackチャンネルはスレッド単位で期限切れはありません。1日後に同じスレッドに戻っても機能します。FeishuとDingTalkのグループはトピック単位でスコープが設定されます。8分間の沈黙の後、次の質問は新しいトピックを開始します。ファイルやスクリーンショットの直後は、同じ画像に関するフォローアップが機能し続けるよう、そのウィンドウが30分間に延長されます。

最初からやり直す。 FeishuとDingTalkでは、/new を送信します。Slackでは、リセットワードにスラッシュは不要です。クライアントが / で始まるものをスラッシュコマンドとして解釈してしまうため、DMでは単に new、スレッド内では @bot new と入力します。

誰がアクセスできるか。 アクセス権は、2つ目のホワイトリストではなく、チャットプラットフォーム側で決定されます。外部組織からのSlack Connectユーザーは静かに無視されます（クォータは消費されず、メモリへの書き込みも行われません）。DingTalkは、自組織のメンバーからのメッセージのみを処理します。Feishuでは、DMはアプリの利用可能範囲に従い、グループはグループメンバーシップに従います。

グループ内のプライバシー。 3つすべてにおいて、会話のコンテキストは個人単位です。同じグループやスレッド内であっても、ある人のやり取りが別の人のやり取りに現れることはありません。プロジェクトメモリは共有されますが、これこそが接続する目的そのものです。

所有しているすべてではなく、プロジェクトを接続する。 まずはチームが共同で知っておくべき内容にスコープを絞った1つのプロジェクトから始め、ボットが引用はできるが変更はできない資料用に読み取り専用プロジェクトを追加します。

ドキュメントライブラリではなく、すでに回答している質問をシード（初期投入）する。 頻出する20の質問と、その回答および理由を登録する方が、200ページのドキュメントよりも優れています。なぜなら、具体的な内容が変わっても、理由は生き残るからです。

1つのエントリにつき1つの主張を書く。 短く自己完結したエントリは、きれいに取得されます。長いドキュメントは丸ごと返されてしまい、情報の抽出作業を再び読み手に押し付けることになります。これはWikiが抱えていたのと同じ失敗です。

実際に活動しているプラットフォームを選択する。 質問が別の場所に届くのであれば、連携には何の価値もありません。DingTalkで運営されている会社において、完璧なSlackのセットアップは無用の長物です。

ローンチ日に2つのルールを周知する。 スレッドの返信を含め、毎回ボットをメンションすること、そしてファイルはメンションと同じメッセージに添付することです。「無視された」という報告のほぼすべてが、これらのいずれかに起因しています。

FeishuやDingTalkでは、まず管理者に相談する。 どちらもリリースと権限の審査が必要なため、月曜日に提出したリクエストが月曜日にボットの稼働につながるわけではありません。Slackは、午後の時間だけで自分自身で完了できるものです。

判断は人間に委ねる。 ボットはチームが確立した内容を返します。誰もドキュメント化していないケースにどう対処するかは、依然として人間が判断すべきことです。その境界線は、what AI memory actually is（AIメモリの真の姿）で引かれています。

ナレッジベースが失敗するのは、執筆時ではなく使用時です。質問がグループチャットで行われるのは、そこに同僚がいるからです。一方でドキュメントは、人々にそのウィンドウを離れ、検索し、自分で回答を組み立てることを要求します。チャットプラットフォームはそのギャップの一部を埋めました。SlacksのAI回答は、それが含まれるプランにおいて、各個人がアクセスできるコンテンツを対象に、Slackのコンテンツ上でうまく機能します。しかし、メッセージではなくドキュメントに存在するナレッジは、外部ソースにアクセスできるティア（プラン）にいない限り、その範囲外となります。

ナレッジベースを@-メンションの背後に配置することで、コンテキストスイッチと回答の組み立てステップの両方が排除されます。また、各やり取りを書き戻すことで、ドキュメント作成スプリントからではなく、実際の質問からコーパスが成長します。セットアップは短時間で済み、計画すべき部分は管理上の手続きです。FeishuやDingTalkで誰がアプリを承認できるか、そしてボットにアクセスできる全員にどのプロジェクトを閲覧可能にするかを決定します。これら2つを正しく行えば、Wikiは「読むように求められるもの」ではなくなります。