ThreadWeaver v3は、ツール横断的なリネージエンジンであるCausal Work Graphをリリースしました。これにより、AIによるクエリは単なるドキュメントだけでなく、Slackのチャット、Jiraのチケット、GitHubのコミット、その他のアーティファクトを紐付ける、証明可能な証拠の連鎖を返すことができます。これを導入したチームは、「なぜこれが構築されたのか？」という問いに対し、推測に基づく文章ではなく、可視化されたサブグラフを用いて答えることが可能になります。
コンテキスト：散在するデータ、失われたつながり
今日のエンジニアリンググループは、乱立するプラットフォームの中で活動しています。顧客の苦情はチケット管理システムに、その後の議論はチャットアプリに、設計上の決定はプロジェクト管理ボードに、コードはリポジトリに、そしてリリースノートはドキュメントツールに存在します。生の情報はそこにありますが、それらの間の因果関係は見えません。プロダクトマネージャーが「なぜこの機能がリリースされたのか」と尋ねたとき、その答えはメッセージ、イシュー、コミットの網の中に隠れてしまいます。従来の検索ツールは、類似したキーワードを含むアイテムを提示することはできますが、どのアイテムが実際に次のアクションを引き起こしたのかを特定することはできません。
なぜ重要なのか：プロベナンス（由来）対 ハルシネーション（幻覚）
ほとんどの大規模言語モデル（LLM）は、意味的な類似性を照合することで回答を生成します。Slackチャンネルに言及しているJiraチケットは関連しているように見えるかもしれませんが、モデルはそのチャットがチケットの原因であることを証明することはできません。その結果、「ハルシネーション（幻覚）」、つまりもっともらしく聞こえるが検証可能なソースを欠いた回答が生じます。規制の厳しい環境や、説明責任が重要となる場面では、このギャップは大きなコストとなります。Causal Work Graphは、推測を、タイムスタンプ、アクター識別子、関係性のタイプ、および信頼度スコアといった具体的な証拠に裏付けられたグラフに置き換えます。
Causal Work Graphの仕組み
- イベント中心のモデリング – 各ノードは静的なドキュメントではなく、イベント（例：Slackメッセージ、Jiraイシューの作成）を表します。
- 明示的な関係性 – エッジ（枝）は、裏付けとなる証拠とともに、具体的な因果関係（「Slackでの議論がPMの決定に影響を与えた」など）をエンコードします。
- プロベナンス・メタデータ – すべてのエッジは、ソース、ターゲット、タイムスタンプ、アクター、信頼レベル、および主張を実証する元のアーティファクトへのポインタを保存します。
- 不確実性の処理 – システムが関連するイベントを見つけられない場合は、接続を捏造するのではなく、「不明（Unknown）」を返します。
- 権限を考慮した公開 – ユーザーは、自身が閲覧権限を持つアーティファクトに関連するエッジのみを表示できます。閲覧できないSlackメッセージがある場合、対応するエッジは単に非表示になります。
- リポジトリではなく、解釈器としてのLLM – 言語モデルはグラフを自然言語の説明に変換しますが、グラフ自体は信頼できる唯一の情報源（Source of Truth）として保持されます。
ユーザーが「リリースの経緯は何ですか？」と尋ねると、エンジンは以下のようなサブグラフを組み立てます。
- 顧客の苦情 → Slackでの議論（タイムスタンプ、ユーザー）
- Slackでの議論 → PMの決定（Jiraチケット）
- PMの決定 → GitHubのコミット（コード変更）
- GitHubのコミット → リリース（アーティファクト）
レスポンスには、正確なSlackメッセージやJiraのコメントへのリンクが含まれており、質問者は各ステップを検証できます。
まとめ
ThreadWeaver v3のCausal Work Graphは、散在するエンジニアリングのアーティファクトを、単一の監査可能な因果関係の連鎖へと変貌させます。すべてのリンクに証拠を求めることで、純粋なLLMによる回答に付きまとうハルシネーションを回避し、チームがすべてのリリースの背後にある「なぜ」を追跡するための具体的な手段を提供します。