仕事ツールのナレッジグラフは実際どんなものか
仕事ツールのナレッジグラフはGoogleのファクトボックスとは違います。Linear、Slack、Figma、そしてスタートアップのツールスタックをつなぐと実際どのようなものになるかを解説します。
By Ellis Keane · 2026-03-14
1876年、メルヴィル・デューイはよく知っているはずの問題を抱えていました。図書館は本で溢れかえっていて、各施設がそれぞれ独自の分類システムを持っていました – もしくは、よくあることですが、まったくシステムがありませんでした。関連する3冊の本にわたって思考を追いたい利用者は、その本の存在を事前に知っていて、各本の場所を知っていて、棚から棚へと歩き回る午後の時間を確保しなければなりませんでした。デューイの十進分類法が画期的だったのは、本を並べたからではありません（それは何世紀もかけてやってきたことです）。それは主題間の関係性をエンコードしたからです – 熱力学、冶金学、蒸気工学は別の階に本が置かれていても、つながっているという考え方です。
150年後、私たちはどういうわけか、デューイ以前の無秩序な図書館を再び作り上げてしまいました。ただし、棚はSaaSプロダクトで、本はSlackメッセージになっています。仕事ツールのナレッジグラフは、その核心において、デューイが解決したのと同じ問題を解決しようとする試みです – 関係性のエンコード – ただし、現代のチームコラボレーションの混沌とした断片化された状況に対して。進歩ですね。
「ナレッジグラフ」という言葉は、「AI搭載」や「ブロックチェーン対応」と同じくらい無謀な自信を持って使われています – つまり、ほとんど誰も同じ意味で使っていません。Googleにはあります（ルクセンブルクの首都を検索すると教えてくれるボックスです）。Neo4jにもあります。あなたの会社のNotionウィキは断じてそうではありません – それを売り込んだコンサルタントが何を言おうとも。そして、このカテゴリの混乱の中で、実際に有用なアイデアが見失われ続けています: 仕事ツールのナレッジグラフ。Figma、Slack、Linear、GitHubなどのツール間でチームが行うことの関係性をマッピングするリビンググラフです。
霧を晴らしてみましょう。
「ナレッジグラフ」が実際に意味するもの（そして意味しないもの）
ここでカテゴリの混乱が本当に噛みついてきます。「ナレッジグラフ」と聞くと、ほとんどの人がGoogleのナレッジパネルを思い浮かべます – バラク・オバマの身長が188cmでホノルル生まれだと教えてくれるあのきれいなサイドバーです。それは静的な事実のウェブです。よりよい組版のブリタニカ百科事典です。確かに便利ですが、仕事ツールのナレッジグラフがすることとはほぼ関係がありません。
神話はこんな感じです: ナレッジグラフとは事実の大きなデータベースで、おそらく派手なビジュアライゼーション付きで、誰か（または何か）が組織の重要な情報をすべて丁寧に入力したものです。基本的にはウィキですが、ページとリンクの代わりに円と線があります。
メカニズムは違います。職場のナレッジグラフは事実を保存しません – シグナル間の関係性を保存します。すべてのSlackスレッド、すべてのFigmaコメント、すべてのLinearのステータス変更、すべてのマージされたPRはシグナルです。グラフの仕事全体は、これらのシグナルがどのようにつながっているかを記憶することです: この会話がその決定に影響し、そのチケットを生み出し、それがそのプルリクエストで実装され、3週間前のデザインクリットで最初の懸念を提起した同じ人がレビューした。
シグナルがノードです。接続がエッジです。そしてエッジこそがすべてです – それなしでは、ただの検索インデックスに過ぎません。
「エッジこそがこれをデータベースではなくグラフにするものです。それなしでは、個々のメッセージは見つけられますが、そのメッセージが属していた決定や、それを形成した6つの他の会話は見つけられません。」 – Chris Calo
（すでに検索インデックスはあります。それはSlack検索と呼ばれています。なぜそれだけでは不十分なのかは後で説明します。）
Notionウィキの大きな墓場
メカニズムのさらに深くに進む前に、少し亡くなったものに敬意を表しましょう。
私が仕事をしてきたスタートアップは – ひとつ残らず – Notionウィキを持っていました。そして、すべてが同じライフサイクルをたどりました: 誰か（通常はチームで最も整理整頓が得意な人、その気持ちはわかります）が週末にセットアップします。素晴らしいです。約3週間、人々が実際に使います。
そして現実が始まります。ウィキは、情報が自然に存在する場所 – Slackの会話、Figmaのコメント、Linearのチケット – から、ウィキが存在すべきと言っている場所へ、誰かが物理的に情報を移動させることを必要とします。それはチームが生成するすべてのコンテキストに対する手動のコピー&ペースト税です。そして言わせてください、誰もその税金を一貫して払いません。それを作った整理整頓が得意な人でさえも、なぜなら今や彼らは実際の仕事をするのに忙しすぎて、実際の仕事をするために建てた記念碑を維持できないからです。
6ヶ月後: ページの半分は古くなっていて、4分の1は矛盾していて、残りは誰かが「落ち着いたら」絶対に埋めるつもりだった空白のテンプレートです。（落ち着くことはありません。それがもう一つの神話です。）
ナレッジマネジメント業界は20年間、同じ壊れた約束を売り続けています: すべてをドキュメント化すれば、コンテキストを失わない。素晴らしい理論です。毎回同じ岩に難破します – 人間はリアルタイムでドキュメント化しません。そして、ようやくドキュメント化しようとする頃には、コンテキストはすでに失われ、歪められ、あるいは誰も見つけられないSlackメッセージに取って代わられています。
仕事ツールのナレッジグラフが実際に保存するもの
さて、メカニズムに戻りましょう。仕事ナレッジグラフは2つのものを保存します: ノードとエッジ。
ノード（もの）
- タスク – Linearのイシュー、GitHubのイシュー、Jiraチケット。ステータスとオーナーがあるもの。
- 会話 – Slackスレッド、Figmaのコメントスレッド、メールチェーン。個々のメッセージではなく、意味の単位としてのスレッドディスカッション。
- 人 – チーム、外部連絡先、ステークホルダー。各人はインタラクションからグラフが時間をかけて構築するプロフィールを持っています。（自分で記入して忘れるプロフィールではなく。実際のリビングプロフィール。）
- 決定 – チームがパスBではなくパスAを選んだ瞬間。これらはほぼ常に暗黙的で、3人が見て11人が見る必要があったSlackの返信に埋もれており、どんな決定ログにも明示されていません。良いナレッジグラフはとにかくそれらを浮かび上がらせます。
- 成果物 – PR、デザインファイル、ドキュメント、ミーティング録画。チームが生産するもの。
エッジ（関係性）
グラフはノードがどのようにつながっているかも保存します:
- このSlackスレッドはこのLinearイシューに情報を提供した
- この人はこの決定に参加した
- このPRはこのタスクを実装した
- このFigmaコメントはこのデザインレビューをブロックした
- このミーティングはこれら3つのアクションアイテムを生み出した
エッジこそがこれをデータベースではなくグラフにするものです。それなしでは、確かに個々のメッセージは見つけられますが、そのメッセージが属していた決定や、それを形成した6つの他の会話は見つけられません。
誰もドキュメント化せずにシグナルが知識になる方法
ここで神話とメカニズムが最も鋭く分岐します。神話は言います: ナレッジベースを構築して維持してください。メカニズムは言います: すでに起きていることを観察して自動的にマッピングしてください。
手動でメンテナンスしなければならないナレッジグラフは、別の名前のウィキです。3週間で終わります。（上記の墓場を参照。）
だからグラフは自動である必要があります。大まかにこのような仕組みです – 簡略化していますが、骨格は正しいです:
1. シグナルが入ってきます。 接続されたツールからのすべてのウェブフック、ポーリング、スクレイプはシグナルを生成します – Slackメッセージ、Linearのステータス変更、Figmaコメント。5〜6つのツールを使う10人チームは1日に数百のシグナルを生成します。ほとんどの人は、チームがどれほど多くのアンビエントコンテキストを生成しているか気づいていません。必要なときにそれが見つからないことだけを知っています。
2. シグナルが分類されます。 これは新しいタスクですか？既存のタスクの更新？決定が行われていますか？バックグラウンドノイズ？分類は可能な限りプログラム的に行われます – LinearイシューナンバーをリファレンスするGitHubのPRは明確です。ファジーなシグナル（プロジェクトに関するSlackメッセージかもしれないし、バナナブレッドのレシピを共有しているだけかもしれない）については、システムはエンティティ抽出とベクトル埋め込み類似性を使用して既存のグラフノードとマッチングします。SlackメッセージのエンベディングがEXISTINGのタスククラスターに十分近ければ、リンクはグラフのエッジとして作成されます – 正式な用語ではプロパティグラフ – 信頼度スコアが添付されます。しきい値以下？コンテキストとして保存されます。ふさわしくない接続には強制しません。
3. シグナルがリンクされます。 分類されたシグナルは既存のノードに接続します。誰かがSlackスレッドでLinearイシューを言及すると、その2つはリンクされます。FigmaデザインにコメントしたのとそれをPRで実装したのが同じ人であれば、それらの接続は自動的に形成されます。誰もドキュメント化する必要はありませんでした。誰もウィキを更新する必要はありませんでした。（これがSugarbugで私たちが構築していることの核心です – チームが普通に作業している間に、リンクはバックグラウンドで起きます。）
4. グラフは時間とともに賢くなります。 クロスツールの参照が蓄積するにつれて、グラフはチームが実際にどのように機能しているかのより豊かな全体像を構築します – 誰が誰とコラボレーションするか、どのツールがどの種類の決定を運ぶか、そしてコンテキストが確実に失われる場所。（私たちの経験では、それはほぼ常にデザインとエンジニアリングの引き渡し時です。毎回。そろそろ解決できているはずなのに。）
Slack検索、Zapier、ダッシュボードがこれではない理由
「でも〜でできるんじゃないの？」という人たちに簡単に答えましょう。（私も何年もその立場でした。あらゆるものを試しました。）
Slack検索は本当に過小評価されています。しかし、「検索可能」と「見つかる」は根本的に違います。Slack検索は、何を探しているか、だいたいいつ起きたかを知っているときに機能します。1週間にわたって複数のチャンネルで行われた決定を再構築しようとすると崩壊します。特定のメッセージではなく、会話間の関係性を探しているのに、Slackにはそのモデルがありません。
ZapierとMakeは基本的な接続を配線できます – 「LinearイシューがDoneに移動したら、Slackに投稿する」– しかしそれは配管であって、理解ではありません。Zapierは何かが起きたことを知っています。なぜか、またはそれが何に続いているかというコンセプトがありません。（これがワークフロー自動化ツールの根本的な悲劇です: それを最も必要としている人が、設定する時間が最もない。）
ダッシュボードはこう言います: オープンイシュー: 47、今週マージされたPR: 12。スループット測定には便利。因果関係には役立たない。ダッシュボードは「1 PRマージ済み」と言います。グラフはなぜを教えてくれます – Figmaレビューがバグを発見し、それはSlackスレッドで最初に報告されていて誰も見ていなかった。ナラティブのない数字は装飾に過ぎません。
これが実際に解放するもの
仕事ツールのナレッジグラフはメンテナンスするウィキではなく、チームが働くにつれて形成される関係性の自動マップです。価値は情報の保存にあるのではなく、個々のツールが見ることができないシグナル間の接続をエンコードすることにあります。
接続されたシグナルがあると – 実際には、取り込みから数日以内に有用な接続が見えてきます、数ヶ月ではなく – これらの個々のツールのどれもサポートしないことができます:
決定を見つける、メッセージだけでなく。 機能のLinearイシューを引き出し、それに触れたすべての会話と決定を見て、アプローチが最初に議論されたFigmaコメントまでスレッドを追う。以前は3人の同僚とコミットログを尋問する必要があったものが、接続されたノードの単純なトラバーサルになります。
考古学なしでミーティングに備える。 エンジニアとの1対1の前に、グラフは関連するすべてのものを浮かび上がらせることができます – 彼らが出荷したもの、詰まっているもの、参加していた会話、まだ宙に浮いている決定。速度メトリクスのダッシュボード（それはすべての人にとって憂鬱です）ではなく、実際に何が起きているかのナラティブ。4つの異なるツールからコンテキストを引き出すのに30分かけるのと、座ったときに準備ができているのとの違い。
見落としコンテキストが見落としタスクになる前に見つける。 3日前にFigmaレビューが要求されたのに反応がない？グラフがキャッチします。Linearイシューが1週間前に「進行中」に移動したのにそれ以来コミットがない？フラグが立てられます。これらは洗練された自動化ではありません – それらは接続されたデータのパターン認識であり、グラフがどのシグナルがどのタスクに関係するかを知っているためだけに機能します。
人間接着剤であることをやめる。 これが私に刺さります。ほとんどのスタートアップには、チームの結合組織として機能する人がいます（多くの場合はファウンダー、時には異常に勤勉なPM） – #design-feedbackの会話がバックログのチケットに関連していて、それは先週のスタンドアップで出てきたことによってブロックされていたことを覚えている人。その人は、一日中、頭の中で手動でナレッジグラフの仕事をしています。それは疲弊します、スケールしません、そして彼らが休暇に行くと、チーム全体のIQが10ポイント下がります。グラフは、休暇を必要としないものでその人間ルーティングレイヤーを置き換えます。
これが、私たちがSugarbugをもう一つのダッシュボードではなくナレッジレイヤーとして構築した理由です – ツールから数字を集計するのではなく、それらを流れるシグナル間の関係性をマッピングします。各新しい接続が既存の接続をより意味のあるものにします。デューイも承認したでしょう。（たぶん。他には時代遅れな見解もありましたが、分類の部分は確かでした。）
一人の人間がツール間の接続を頭の中で保持することに頼るのをやめましょう。Sugarbugが自動的に関係性をマッピングします。
Q: 誰かがSlackメッセージを削除したり、Figmaコメントを解決したりした場合、グラフはどうなりますか？ A: シグナルが取り込まれてリンクされると、元のメッセージが削除されたりコメントが解決されたりしても、グラフは関係性を保持します。SlackやFigmaから元のコンテンツが消えても、エッジ –「この会話がこの決定に情報を提供した」– は残ります。それこそがすべてのポイントです: グラフは個々のツールが廃棄するコンテキストを保全します。
Q: SugarbugのナレッジグラフはプライベートチャンネルやDMに対応していますか？ A: 明示的に接続したデータソースのみが取り込まれます。プライベートSlackチャンネルを接続すると、それらのシグナルはグラフに入り、Sugarbugワークスペースへのアクセス権を持つ誰でも見ることができます。特定のチャンネルを設定しない限り、DMはスクレイプされません。データはチームの環境内に留まります – Sugarbugは組織間でシグナルを共有しません。
Q: グラフはオフトピックのSlackチャットのようなノイズの多いシグナルをどう処理しますか？ A: 分類は信頼度しきい値を使用します。しきい値を超えて既存のグラフノードに一致するシグナルはリンクされ、それ以下のシグナルは接続に強制されるのではなく、リンクされていないコンテキストとして保存されます。時間が経つにつれて、グラフがより多くの参照ポイントを蓄積するにつれて、分類器はプロジェクト関連の議論と一般的な雑談を区別するのがうまくなります。私たちの経験では、最初の1〜2週間後にノイズとシグナルの比率が著しく低下します。
Q: ナレッジグラフを直接クエリできますか、それとも裏側でのみ使用されますか？ A: Sugarbugはタスクビューとミーティング準備画面を通じてグラフを公開しています – クエリを書かずに接続されたコンテキストを見ることができます。しかし、基礎となるデータはSugarbugのMCPサーバーからもアクセスでき、さらに深く掘り下げたい場合にカスタムインテグレーションを構築したり他のツールから使用したりできます。
Q: 新しいシグナルがグラフに表示されるまでどのくらい時間がかかりますか？ A: ウェブフック駆動のソース（GitHubやLinearなど）は数秒以内に表示されます。ポーリングされるソース（FigmaやNotionなど）はスクレイプ間隔に依存します – 通常、ソースに応じて30分から2時間ごとです。実際には、タスクを確認するために座るころには、関連するシグナルはすでにリンクされています。